Release the exact application you tested

A passing candidate is a file with observed behavior. “The latest code” is a moving target. If you ask the agent to tidy the file after testing, you have a different candidate and must check it again.

This lesson ties the release decision to the exact bytes tested, then runs those bytes in a fresh disposable environment.

Follow the release decision

If your C1 candidate passed, run:

python3 factory.py release runs/c1-build-01/candidate.py --contract c1 --out runs/c1-release-01

If you are following the worked-solution path, use:

python3 factory.py release reference/c1.py --contract c1 --out runs/c1-reference-release-01

These are different evidence claims. The first checks your generated candidate. The second checks a hand-authored reference. Keep their provenance visible.

Expected result for an accepted release: "passed": true and "released": true, exit 0. Open the run’s report.json and promotion.json.

The controller first freezes the candidate in the run folder and computes its SHA-256 digest. It runs the full selected contract. Only after those checks pass does it create another application, simulator and test client, using the same frozen candidate. It repeats the checks there. It writes a promotion record only if both stages pass.

This “release” is local and disposable. It does not publish an internet endpoint or change a production system. Containers and their temporary data volumes are removed when the command finishes; the evidence files remain.

Inspect behavior and identity together

The digest identifies the candidate; it does not prove correctness. The checks observe selected behavior; they do not identify every possible implementation that would pass. Keeping both lets you say which artifact produced the observed results.

Evidence	Question it answers
Candidate hash	Which source bytes did this run use?
Acceptance checks	Did those bytes satisfy these cases?
Independent effect ledger	Did the receiving system actually record the expected writes?
Fresh-environment checks	Did the same candidate pass after being deployed again?
Promotion record	Did this controller permit that candidate to proceed?

Inspect restart_preserves_receipt. The application container restarts while its state volume remains. Repeating an earlier confirmed request should return the original receipt without another external write. A container restart with a completely empty database would test a different condition.

Know what a green result leaves open

The checks cover a single process, synthetic accounts and a small set of controlled dependency behaviors. They do not establish multi-replica coordination, performance at scale, access control for real customers or a recovery plan for your production database. There is no 24-hour observation claim.

For a customer handover, include the contract and its exclusions, the tested artifact identity, the receiving system’s failure semantics, the evidence location and the person who can stop or expand the workflow. Saying “the agent built it” explains none of those things.

Check your understanding

Question: The candidate passes, and then you change only a logging statement. Can you reuse the promotion record?

Answer: No. The record identifies the previous source bytes. The edit may be harmless, but the earlier evidence does not establish that. Run the new candidate and retain its own record.

Question: Does a missing promotion.json always mean the implementation failed a behavioural check?

Answer: No. Setup, execution or evidence-writing may have failed first. Read the report and resolve the failure. The absence of permission to release is not a diagnosis of its cause.

Your evidence: Point to the candidate hash in both the report and promotion record. Name one important behavior outside this exercise’s contract before continuing.

Continue to reconciliation and the faulty-change exercise.