In late August a JodyInk training build stopped short of release. The retained release manifest recorded five reasons the build had not been promoted.
The build was an internal training workshop with ten modules and a capstone. A pipeline generated its facilitator guide, learner workbook, assessment bank and traceability record from one structured content file, checking nine things before it called the build complete. The checks passed. The manifest nonetheless recorded the result as a non-release review build, and listed why.
Five blockers, written down
No promotion approval had been given, so the manifest recorded the absence rather than assuming it. The content file still described itself as a review build, and the manifest repeated that label instead of upgrading it. The delivery note said the ten modules ran “approximately eight hours” while the configured module timings added up to six hours fifty minutes, and the manifest recorded the mismatch as a blocker rather than picking a number. The manifest also flagged distribution rights as unverified. And the Office and PDF outputs had adapter checks run and recorded, but the course configuration did not make those outputs required, so the configured visual gate reported itself as not applicable rather than passed.
That last one is the most instructive. A gate can exist, run, and log a result without being a gate that fails closed. The record kept the distinction visible instead of letting “checks passed” cover it.
Three non-claims, also written down
The same manifest listed what the build did not represent: that any approval had been granted; that any learner had completed, mastered or benefited from anything; and that a tagged PDF and a clean adapter audit amounted to formal accessibility certification. None of those statements cost anything to write. Each one prevents a later reader from inferring a result the build never produced.
What the record ties itself to
The manifest names the build and hashes its two inputs, the content file and the course configuration. So when the timing mismatch was later corrected in the content file (the corrected delivery note states 410 minutes plus a 120-minute capstone), the old manifest did not become wrong. It still describes exactly the content it saw, and the corrected content will get a manifest of its own. A record that hashes its inputs can afford to be honest about them, because honesty about a past state is not a claim about the present one.
Recorded is not enforced
It is tempting to read a list of nine configured checks as proof that bad inputs cannot get through. The record supports a narrower statement: these checks were configured, they ran, and the run logged them as passed for this build. Whether the pipeline would refuse to export a claim with no rights, no approval or a stale date is a separate question, answered only by failure tests, and this manifest does not answer it. The same care applies to the content file itself. Every material claim in it carries a classification, either attributed to the course material or externally verified, and a field for a verification date. Eight of the thirty claims are classified as externally verified. Nineteen have no date at all. The field’s existence says nothing about the claim; only the classification and the date do, and a date does not change a classification.
Two questions for any release record
What stopped this build from being promoted? What does it explicitly not claim? A manifest that answers both, and hashes the inputs it answers them about, stays useful after the first answer changes. The one this note describes is still correct about a build from August, which is all it ever promised to be.