Build and defend the capstone

The museum director sees the successful synthetic demo and asks whether the workflow is ready to manage real corrections. The honest answer depends on evidence. We can show bounded local behavior, checkpoint-transfer semantics and framework parity. We cannot show authenticated staff review, real source accuracy or production recovery because none was exercised.

Your capstone is to build an evidence-backed local release recommendation. It must contain a working synthetic package and explain its limits. A recommendation to keep the system as a local demo can be the correct engineering conclusion.

The capstone brief

Prepare a versioned museum-label audit package using the supplied controller as the baseline. Preserve the authority boundary: no real accounts, messages, catalogue edits or physical-label changes. Compare the baseline with a candidate planner double, investigate one interrupted read, and demonstrate both approval-to-simulation and rejection. For the required added case, choose a supported comparison with an accepted integer year, specify its expected finding before running, then record a valid synthetic rejection. Invalid-input and expired-time cases are useful additional checks, but do not replace that required comparison/rejection artifact.

Use starter.py as the learner scaffold. Its build_evidence is intentionally unimplemented. That is an exercise, not an undisclosed gap in the reference project. Produce a dictionary matching the acceptance check, along with a short explanation of contract, results and residual risks. Read the reference only after your own attempt.

The required evidence fields describe: the synthetic evidence kind, baseline and candidate case reports, recovery phases and reservations, review/finalization/rejection results, an added boundary case, a release recommendation and limitations. The structure check is formative; it cannot judge whether your explanation is thoughtful or your added case tests something important.

Work from a contract rather than a demo script

Write what the package may do, which source version it uses, how request identity works, what ends a run and what still requires a reviewer. Define success per case rather than demanding that every input produce a draft. Preserve separate terms for completed execution, supported comparison, approved simulation and real-world correction.

Choose a candidate that tests an actual hypothesis. The supplied reference uses the always-lookup double as an intentionally poor candidate: it shows why boundedness alone does not produce useful work. You may use a different deterministic double, but identify it as such. Changing a prompt you never run is not evidence of a working model improvement.

Keep interruption evidence intact

Inject the known failure after a synthetic read returns but before its reply is checkpointed. Show IN_FLIGHT, consumed reservation and missing accepted fact. Transfer state through the exported JSON string, then explicitly stop or abandon the read under the documented read-only policy.

If you continue, demonstrate that the new lookup consumes another reservation. Do not erase the first charge to improve your counts. Explain that transfer is simulated in process and that no disk durability or remote exactly-once effect was tested.

For review, preserve the exact digest and revision. Use logical creation, decision and finalization ticks in order and inside the deadline. Demonstrate rejection without a receipt. A successful simulation has a saved SIMULATION_ONLY receipt with real_writes=0; it does not claim that any real source or label changed.

Make the reference inspectable

Run the supplied reference check from the course folder:

PYTHONDONTWRITEBYTECODE=1 python3 capstone/check_submission.py --module reference
PYTHONDONTWRITEBYTECODE=1 python3 capstone/reference.py

After implementing your scaffold, use --module starter. An unimplemented scaffold should fail with its explicit exercise message. Do not call that a platform grading failure or silently substitute the reference while claiming your own work passed.

The reference's baseline matches 8/8 authored regression cases; its poor candidate matches 4/8. Its recovery goes from IN_FLIGHT with one reservation to REVIEW with two. Its added EX-002/2100 case creates a mismatch against 1986, then a synthetic reviewer rejects it. The chosen added case is a supplied teaching example, not an untouched holdout. Your own new case should have a distinct purpose.

Read the evidence-chain visual. Each conclusion should point back to a contract, observed result or explicitly untested assumption. A polished final slide cannot replace that chain.

If the diagram extends beyond the screen, scroll inside it or read the text version below.

Read the diagram as text

• A release recommendation is only as strong as its evidence
• Aabha AI Academy · original course visual · synthetic workflow only
• Contract
• Scope, authority
• and criteria
• Implementation
• States, tools
• review boundary
• Checks
• Failure, replay
• framework parity
• Evaluation
• Case-level results
• and limitations
• Decision
• Local demo only
• or justified next step
• A working synthetic capstone does not grant production release, platform credit or certification.
• Keep expected outcomes separate from actual results; explain every failed case and every untested condition.

Proposed self-review rubric

Score outcome correctness and evidence accuracy out of 25. Does the package state expected and actual results, include all cases, and preserve source references? Score enforced tool and review boundaries out of 25: unsupported names, wrong targets, stale decisions, timing and rejection must behave as described. Score state and recovery out of 20: preserve identity, revisions, uncertainty and consumed allowance. Score meaningful tests and comparison out of 20: include failures, a justified added case, and a reproducible framework run if claiming framework execution. Score explanation and release decision out of 10: say what ran, what did not, and what the remaining evidence would need to establish.

A provisional pass is 80/100 with mandatory gates. Any unauthorized side effect, silently skipped mandatory stop, fabricated run, or synthetic result described as live verification requires correction regardless of the numeric total. These are educational criteria, not an issued Aabha grade, credential or certificate. A human review of the explanation is still required after the structure check.

Decide the next justified step

The reference recommends local_synthetic_demo_only. That is supported by the observed tests and the deliberately limited system. Future real use would require an authorized source integration, actual reviewer authentication, trusted time, appropriate persistent state and recovery, privacy controls, operator procedures, evaluation on relevant data and a permitted learner/user study. That is a statement of missing implementation and evidence, not permission to perform those changes.

If you executed Module 7, include its separate framework command, version and result. If the dependency was unavailable, disclose it. Do not turn standard-library success into a framework pass. Neither result is a live-model evaluation, a learner pilot or permission to publish the course.

Practice and defense

1. Complete the scaffold and retain your own contract and case-level evidence. Run the formative acceptance check, then assess the explanation with the rubric.
2. Defend one safe stop to a reviewer who wants higher draft yield. Explain the alternative risk using a concrete case, rather than saying “safety first” without evidence.
3. Identify the strongest claim your package supports and a tempting stronger claim it does not. Name one additional implementation and one additional test needed for the stronger claim.
4. Write a concise release recommendation with a specific allowed next use and explicit missing evidence. Keep future production actions outside the local capstone.

You have completed this local course when your runnable evidence and explanations support each other. The remaining step is a reviewable engineering decision, not a promise that a synthetic workflow can be safely turned loose on real learners or institutions.