Say exactly what the evidence establishes
Proposed behavior, reported tests, and reproduced results support different readiness claims.
A project summary says “complete,” a test report says “passed,” and an acceptance matrix still contains untested rows. Those statements may describe different scopes, but a reader cannot tell unless the report names what was completed, what the tests exercised, and which conditions remain unverified.
Readiness reporting needs more than a confident adjective. It needs an artifact, a requirement, an environment, and evidence that connects them. The same feature can be implemented in source, covered by a unit test, and untested on the hardware or workflow a user intends to use.
The retained technical blueprint for Cassette, a project for running and managing models, illustrates the distinction. It reports an implementation ledger and a 42-of-42 test suite for an Apple-silicon Mac environment (arm64 macOS), while explicitly stating that the suite was not independently rerun for that report. It also identifies live hardware, storage, model, setup, and commercial questions that remained unproven at the source date. Those limits belong beside the test claim.
Use evidence states precisely
A proposed behavior is something the design says should happen. A reported result is something a source says happened. A reproduced result is something exercised again under identified conditions with inspectable evidence. These states are useful because each supports a different degree of confidence and a different next action.
Keep the actor visible. “The report records a passing suite” is a different statement from “I reran the suite.” A generated summary cannot upgrade a report into a reproduction merely by omitting the attribution, because the later writer has added no new observation of the artifact, its execution, or the conditions that produced the reported result. When the underlying artifact is unavailable, preserve that gap instead of borrowing certainty from an earlier narrative.
A reproduction also has a boundary. Passing a small test in one environment does not establish broad product readiness. Record the artifact revision, dependencies, inputs, command or procedure, result, and relevant environmental conditions. The reader should be able to identify what would need to change for the evidence to stop applying.
An illustrative readiness review
Consider a hypothetical application that exports a report. Its specification requires a correctly formatted PDF with source citations. A developer reports that all unit tests pass. A reviewer can inspect the source but has not opened an exported file. The supported status is that unit-test success has been reported; visual export acceptance remains unverified.
The reviewer then runs the export on a known input and opens the resulting PDF. Citations are present, but a table is clipped. Record the export failure against that artifact revision and retain the reported unit-test result separately. One observation does not erase the other, and averaging them into a general percentage would obscure the reason delivery is blocked.
After repair, rerun the export and inspect the new artifact. The old screenshot cannot approve the changed file. If the repair affects only layout, the relevant factual checks still need enough coverage to establish that content was preserved. This sequence is illustrative and contains no claimed production outcome.
Now imagine two status documents disagree. Preserve the disagreement with their dates and scopes, inspect the underlying receipts where available, and update the summary only after reconciliation. If the necessary evidence cannot be recovered, mark the current state unknown. Choosing the more optimistic document is not a verification procedure.
Write reports that support a decision
Lead with the decision the evidence permits. A feature may be ready for a limited internal trial while remaining unready for unrestricted release. Explain the tested scope and the next missing condition in ordinary language. Readers need to know what they can responsibly do with the result.
Avoid making test counts carry more meaning than they have. Many narrow tests can leave a critical user path untouched. One well-designed acceptance test can expose a failure across several components. Report the requirements covered and the failure modes exercised, with counts as supporting detail.
Keep unknowns distinct from failures. An unrun test says that evidence is absent. A failed test establishes an observed defect under stated conditions. Both may block a release decision, but they require different next actions and should remain distinguishable in the work queue, where an engineer needs to know whether to arrange a missing test or investigate an observed failure.
For the next readiness report, select one consequential claim and trace it to its exact artifact and receipt. If the trace stops at a proposal or another summary, revise the wording to that evidence level. Then perform the authorized missing check, or name the specific input, environment, or approval needed to complete it.
Source notes
Based on the August 2026 Cassette Technical Commercialization Blueprint and its explicit distinction between reported tests and unproven acceptance conditions. The report-export scenario is hypothetical.
