Skip to main content

Checkpoint Gate

World-Class Evidence Integration

The checkpoint must verify that the World-Class Strand evidence exists, is reproducible, and has a written highest-risk gap.

Required Output Classification​

Required outputClassificationPublic/private guidance
Closed-book prompts, self-assessment answers, and skills matricesPractice artifactUse for honest calibration; do not publish raw answers unless rewritten as a study guide.
Required evidence gate items, sign-off checklist, and readiness decisionCheckpoint evidenceKeep as private progression evidence; share only sanitized summaries with mentors or reviewers.
Repair artifacts produced after a weak checkpoint, such as corrected solutions, diagrams, traces, benchmarks, or runbooksCheckpoint evidenceStore beside the checkpoint so the remediation trail is inspectable without making mistakes public.
Reviewer notes or mentor feedback that materially improve a project artifactPortfolio candidateConvert into public-safe acknowledgements or changelog entries only after removing private feedback context.

Use this gate after finishing the module quizzes and before starting Semester 5. The goal is not to reward speed. The goal is to stop you from carrying fuzzy systems knowledge into operating systems and networking.

Instructions​

  • Answer from memory first.
  • Mark Confident only if you can explain the idea and demonstrate it at the keyboard.
  • Mark Review needed if you would need to search or guess.
  • Any weak answer in Modules 2-4 should be treated as a real blocker.

Knowledge Checks​

Module 1: C Programming Fundamentals​

  1. I can explain the difference between preprocessing, compiling, assembling, and linking. - [ ] Confident [ ] Review needed
  2. I can explain declarations vs definitions, header discipline, and what the linker resolves. - [ ] Confident [ ] Review needed
  3. I can explain array-to-pointer decay and why C strings fail when buffer boundaries are ignored. - [ ] Confident [ ] Review needed

Module 2: Memory, Pointers & Machine Representation​

  1. I can draw the stack, heap, globals, and code region for a small C program and place objects correctly. - [ ] Confident [ ] Review needed
  2. I can explain pointer arithmetic, struct padding, endianness, and at least three memory-safety bugs. - [ ] Confident [ ] Review needed
  3. I can explain what ASan or Valgrind reported in one of my own debugging sessions. - [ ] Confident [ ] Review needed

Module 3: Computer Organization & Architecture​

  1. I can read short disassembly and match it back to loops, branches, and function calls in the source. - [ ] Confident [ ] Review needed
  2. I can explain cache locality, branch prediction, and why asymptotically similar code can run at very different speeds. - [ ] Confident [ ] Review needed
  3. I can explain virtual memory at the level of pages, page tables, and the TLB without confusing them. - [ ] Confident [ ] Review needed

Module 4: Systems-Level Programming​

  1. I can write fork + exec + waitpid from memory and explain the parent/child flow. - [ ] Confident [ ] Review needed
  2. I can explain file descriptors, dup2, pipe, and how shell redirection actually works. - [ ] Confident [ ] Review needed
  3. I can explain thread races, mutexes, condition variables, sockets, and when to use gdb, strace, or perf. - [ ] Confident [ ] Review needed

Module 5: Abstraction & Interpretation​

  1. I can explain closures, the environment model, tail calls, and the split between eval and apply. - [ ] Confident [ ] Review needed
  2. I can connect interpreter design back to the low-level execution model from Modules 1-4. - [ ] Confident [ ] Review needed

Skills Checks​

  1. I can compile a multi-file C project with warnings enabled and fix the warnings instead of ignoring them. - [ ] Confident [ ] Review needed
  2. I can debug one crash or memory bug from first reproduction to root cause using tools, not only print statements. - [ ] Confident [ ] Review needed
  3. I can build a small UNIX-style tool that opens files, processes bytes, and reports errors correctly. - [ ] Confident [ ] Review needed
  4. I can produce one benchmark or systems measurement and explain what the result means. - [ ] Confident [ ] Review needed
  5. I can explain one real design tradeoff between low-level control and abstraction cleanliness. - [ ] Confident [ ] Review needed

Required Evidence​

Before checking yourself ready, verify that you have:

  • a buildable C project with more than one translation unit
  • at least one sanitizer or debugger transcript from a real bug
  • at least one disassembly or cache-analysis note you wrote yourself
  • at least one fork/pipe/dup2 exercise that you can still explain from memory
  • at least one closure or interpreter exercise from Module 5

If any of those artifacts are missing, the semester is not complete even if the quizzes look fine.

Blockers To Clear Before Semester 5​

Do not move on yet if any of these are true:

  • you still guess about pointer behavior instead of drawing memory
  • you cannot explain why a compiler warning matters
  • you cannot read a simple strace or gdb backtrace
  • you know the words cache or virtual memory but cannot apply them to an example
  • you can write thread code but cannot argue why it is race-free

Sign-Off​

  • I completed the cumulative review
  • I completed the semester project
  • I can defend my weakest module and have a repair plan if needed
  • I am ready to begin Semester 5: Operating Systems and Networking

Mastery Rubric​

LevelEvidence
Beginner passCan answer direct questions and complete familiar exercises with light notes.
Solid passCan solve new variants, explain choices, and connect the work to Semester 3 Software Design.
Strong passCan defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact.
Not readyRelies on copied solutions, cannot explain mistakes, or lacks durable artifacts.

Retake and Repair Rule​

If a section is weak, do not only reread. Repair it by producing new evidence: a corrected solution, a fresh implementation, a rewritten proof, a benchmark, a diagram, a runbook, or a short teaching note.

Answer-Quality Examples​

Use these examples when grading written answers or spoken explanations.

QualityExample pattern
WeakNames a concept but gives no example, constraint, or failure case.
AcceptableDefines the concept and applies it to a familiar exercise.
StrongApplies the concept to a new variant and explains why an alternative would fail.
Portfolio-readyConnects the concept to Semester 3 Software Design, current project evidence, and a future capstone decision.

Interleaving Prompt​

For any missed answer, add one sentence starting with: This depends on an earlier skill because...​

Calibration Materials​

Use these learner-visible calibration materials before self-grading or requesting review:

C input-contract evidence​

Require all CI1–CI6 at level 2 or above. Reuse the line-reader lab packet in the existing project: capacity traces, consecutive-line behavior, injected errors, compiler/diagnostic output and a fresh-case defense. No aggregate score waives missing input-contract evidence. Preserve the distinction between bounded storage and bounded running time.

Memory ownership evidence​

Require all MP1–MP6 at level 2 or above. Reuse the growable-buffer packet: checked sizing, ownership traces, allocation-failure recovery, cleanup and independent transfer. The 20–30-hour package replaces the former short lab; it is not a complete module workload. Required fuzzing/Rust/mitigation/platform work remains separate.

Performance evidence​

Require PE1–PE6 at level 2 or above. Reuse the locality measurement packet: checked sums, raw timings, target assembly, model assumptions and a bounded inference. A speedup or fabricated anomaly is never required. The specialized-platform strand remains separate.

Partial-I/O evidence​

Require IO1–IO6 at level 2 or above. Reuse the write-progress packet: exact accepted prefixes, bounded retry traces, descriptor ownership and diagnostic evidence. A complete local write does not imply durability or remote processing.

Lexical interpretation evidence​

Require all LI1–LI6 at level 2 or above. Reuse the interpreter packet: frame diagrams, two independent closure instances, evaluation-order tests, caller-scope fault evidence and explicit host/resource limitations. The small evaluator does not replace the original mutation, streams, staging or concurrency requirements. A failed gate remains incomplete regardless of aggregate score.

Integrated progression contract​

Use the 440–640-hour workload and advancement contract. All 30 module extension gates and all five safety/platform evidence categories must independently reach level 2, alongside existing checkpoint, exam, project and integrity thresholds. Missing evidence means repair required — incomplete. Reuse module artifacts and record time once; the three-hour written exam and two-hour fresh-case defense are included in integration time.