All courses · Course overview · Lesson sequence
Skip to lesson textAnswers and explanations · Build and defend the capstone
The reference implementation is capstone/reference.py. It performs synthetic runs rather than returning a hard-coded success report. The baseline and candidate summaries come from the same eight authored cases. The recovery path actually creates an uncertain IN_FLIGHT checkpoint, exports it, restores a new RAM store and consumes another reservation before reaching review.
Its normal review path binds the decision to the saved digest and revision. Creation tick is 5, decision and finalization are 6, inside deadline 8. The final phase is SIMULATED with zero real writes. Calling finalization again returns the saved receipt without adding work. A separate EX-002/2100 case is rejected, and its receipt remains absent. Those paths support a claim of correct local fixture behavior, not a claim that real approval or record changes occurred.
The poor candidate is deliberately retained because it teaches a useful contrast. It obeys the narrow authority and budget gates but scores only 4/8 correct outcomes. It does not become a good planner by being safe to stop. A defensible implementation decision is to retain the fixed baseline for this job until a new planner demonstrates useful improvement under the same contract.
One reference release note could read: “Approve this package for a local synthetic engineering demonstration. The standard-library controller and separately pinned framework route demonstrate bounded reads, explained stops, checkpoint-transfer simulation and content-bound synthetic review. No live model, real source integration, authenticated reviewer, trusted clock, disk durability, production workflow or learner study was exercised. Real operation requires separately authorized implementation and validation. This capstone does not authorize publication or production changes.”
To defend a safe stop, choose the wrong-fact case. Producing a draft from an EX-002 response to an EX-001 request would increase draft yield while grounding the comparison in the wrong exhibit. The stop preserves evidence quality. To improve completion legitimately, repair the tool/source contract and re-evaluate it; do not change the expected result to accept unsupported evidence.
The strongest supported claim is that these local implementations obey the tested fixture contract on the supplied cases and specified boundary probes. An unsupported stronger claim is that they prevent duplicated real messages across crashes. That would need a real permitted messaging integration with documented outcome/idempotency semantics, durable state tied to those semantics, and recovery tests around actual uncertain dispatch. No such integration is performed in this course.
The structure checker verifies required fields and several concrete invariants. It does not independently certify your case design, detect all fabricated evidence or grade the clarity of your decision. A human should inspect traces, run selected checks and use the rubric. Do not report an automatic structure pass as a course certificate.
Suggested self-review: award full correctness points only when denominators include safe stops and input rejection; full boundary points only when invalid decisions cannot resume; full recovery points only when uncertainty and old charges survive; full evaluation points only for case-level comparisons with clear provenance; full explanation points only when the allowed next use matches the evidence. Deduct for untested claims even if code runs cleanly.
A suitable added comparison case might use a changed fixture version with a fresh request identity, verify that its draft cites that version, then record a valid rejection. Another can use a supported comparison and reject exactly at its inclusive deadline, testing the accepted decision boundary while still satisfying the required rejection artifact. Invalid-input or expired-decision cases can be added separately; they cannot substitute for the required supported comparison and valid rejection. Explain the hypothesis before running. The supplied reference case is for comparison after your attempt, not evidence of an unseen benchmark.