KN-13 · Delivery evidence
A build stage owes the reviewer two things. Write a claim before the work starts, then hand over an artifact they can open to check it. A green run helps when the test answers the same question as the stage.
Write the claim beside the artifact in the requirement or work card. A test records what its assertions cover. Use it as evidence when those assertions match the stage claim. A reviewer needs an agreed reference such as a design, a sheet or a requirement so they can inspect the build independently of the builder’s report.
| Stage | What the reviewer opens | What it establishes |
|---|---|---|
| Idea | Dated request and proposed question | Names the claim to investigate |
| Proof of concept | Smallest real input, command and output | One claim under stated conditions |
| Picture | Pinned page, sheet or schema | Requester accepts the shape |
| Prototype | Real data through the real path | Design holds under observed constraints |
| Finished v1 | Product in use and a one-page owner guide | Independent acceptance against the agreed frame |
| Live | Dated runs and failure records | Continued operation over observed runs |
An idea names a question without establishing demand or feasibility. A proof of concept tests one narrow risk in its stated setting. It leaves safety, cost, maintenance and other inputs for separate evaluation. A picture establishes the requester’s preference when they explicitly accept it. Feasibility and cost remain open.
A prototype exercises the whole path with real inputs, within the time, cost and machine constraints that matter. List its rough edges and operator dependencies. A finished v1 serves its intended user, has independent acceptance against the agreed frame, and has a one-page guide naming what it is, where it runs and who owns it. Live operation adds dated evidence and failure records. Each run covers its own observation window.
Figure 01Delivery framework
Open the dated request.
It names the question to investigate. Demand and feasibility remain open.
Open one real input, command and output.
It tests one claim under stated conditions. Keep other risks open.
Open the pinned page, sheet or schema.
Requester approval establishes the intended shape. Feasibility and cost still need evidence.
Follow real data through the real path.
The run shows how the design behaves under observed constraints. Record rough edges and operator dependencies.
Open the accepted product and owner guide.
Independent acceptance checks the agreed frame. The guide names where the product runs and who owns it.
Open the dated runs and failure records.
Name the revision and observation window. Continued operation is supported only across the runs observed.
One team’s working framework, informed by three field cases. The stages describe different kinds of evidence.
The inputs can go to another agent as reviewer too. A claim and an artifact give that agent the same comparison to make.
The ladder comes from one team’s October 2026 requirements discussions and three reported cases. The cases illustrate how the team assigned names and checked evidence. There was no controlled measurement, and the work was not rerun for publication. The one-page handover is the team’s working definition of readiness for its owner.