Capstone assessment — 100 points
Assess the final private Sensor Monitor candidate and its evidence bundle. CP09 is a reference solution, not proof of the learner's execution. Accept equivalent maintainable implementations when their behavior meets the contract. This self-study rubric recommends a pass at 80/100 plus every mandatory gate below. The score is not a credential.
For each criterion, award full points when the named evidence establishes it, half points for a useful but incomplete artifact with its limits correctly identified, or zero when absent, contradicted, or unsupported. Half points may be fractional; sum without rounding up to pass. Record an evidence path and short rationale for every nonzero award. A score records assessment, not a replacement for missing execution.
| Category and criterion | Points | Evidence required for full credit |
|---|---|---|
| Requirements: observable behavior | 8 | Explicit entry/clearing boundaries, state history, invalid/stale/recovery behavior, command contract and reset |
| Requirements: exact documented target | 4 | Board/sensor identity and applicable primary hardware references; documented example clearly distinguished from tested hardware |
| Requirements: sources and unknowns | 3 | Claims trace to applicable sources; missing facts and validation limits remain visible |
| Git: coherent history | 8 | Preserved CP08 baseline and small coherent changes/commits with no unrelated material |
| Git: review | 7 | Inspected final diff; explanations and any findings connected to requirements and resolution evidence |
| Behavior: alert policy | 5 | Inclusive entry and clear boundaries, both band directions, jitter |
| Behavior: input faults and recovery | 5 | Missing/nonfinite/stale rejection; two fresh samples; interrupted recovery and fresh classification |
| Behavior: bounded parser | 5 | Complete grammar, 64-byte framing, CRLF, overflow drain, repeated lines, truncated host input |
| Behavior: configuration | 5 | Inclusive range, validation before narrowing, invalid-command preservation, current-state re-evaluation, RAM-only reset |
| Behavior: integration | 5 | Same shared policy/parser/output source in host and firmware; correct JSON availability and synthetic labels |
| Verification: independent expectations | 7 | Requirement-to-test map includes equality, history, invalid inputs, time horizon and rollover |
| Verification: host and replay | 7 | Actual final-source host assertions and normal/command/stale/rollover replay receipts; output inspected against expectations |
| Verification: meaningful defects | 5 | Compiling FAULT-hysteresis and FAULT-command versions rejected for intended behavior; good solution still passes |
| Verification: reproduction record | 3 | Fresh second-checkout identity, setup inputs, actual relevant command/result records |
| Verification: limits | 3 | Claims match the actual environment, inputs, source and evidence; physical checks clearly separate |
| Documentation: reproducible setup | 5 | Complete packaged source, dependency/target record, usable README/formats and release notes |
| Documentation: maintained state | 5 | Requirements/decisions/evidence/handoff match final source and identify one next bounded action |
| Agent workflow: repository guidance | 4 | Real fresh-session task finds scope and performs relevant actions from maintained context |
| Agent workflow: two skills | 6 | Constraints relevant/unrelated/incomplete cases and review defect/clean/unrelated cases, with selection and output evidence distinguished |
Category totals are requirements 15, Git/review 15, firmware behavior 25, verification 25, documentation/handoff 10, and agent instructions/skills 10.
Mandatory gates
| Gate | Pass condition | What leaves it open |
|---|---|---|
| G01 — Reproducible build | The reviewed final source cross-compiles for the recorded target/toolchain and that result is reproduced from the intended release in a fresh second checkout | Missing output, source mismatch, build failure, or only the original checkout tested |
| G02 — Critical software behavior | Actual checks establish the required threshold/hysteresis, faults/recovery, complete bounded parser, configuration preservation and reset behavior | A critical requirement fails or lacks a discriminating executed check |
| G03 — Host and replay verification | Final-source host assertions and required synthetic replay cases pass; meaningful defects compile and are rejected while the good version passes | Only compilation, expected logs, screenshots, or assertion counts are supplied |
| G04 — Honest evidence labeling | Every execution claim has an accessible matching receipt and all synthetic/host/build/physical distinctions are accurate | Invented results, hidden failed checks, or a physical claim supported only by software evidence |
An open gate prevents a suggested pass regardless of score. Report the exact missing evidence and next useful action. When a later check closes the gate, record the new source/result rather than rewriting history. A high score may still document useful completed work while an account or dependency issue leaves execution open.
Physical equipment and public publication are optional. A separately performed physical supplement needs its own exact hardware, acquisition adapter, upload/serial, fault/recovery, timing and measurement checks. Do not award or remove core points because the learner did not buy or wire hardware.
Instructor defense prompts
Ask the learner to explain one equality case, one parser rejection that preserves configuration, one defect their tests caught, and one claim their evidence cannot support. Ask which source was actually built in the second checkout and what changed after its receipt. Answers should point to artifacts and reasoning rather than memorized terminology.
For the transfer task, inspect its brief, actual diff/result, effort record and maintenance plan. This demonstrates applying the workflow beyond the guided feature. It is part of the final challenge submission, while the numeric categories above preserve the agreed capstone weighting.