03 / xBuild
The build is judged on what it hands over.
An implementation is only as good as the evidence that comes with it — the files that changed, the checks that ran, and the proof nothing else moved.
The evidence
What is handed over.
Four things, every time — a checklist, not a maturity ladder.
- 01
The changed files
Exactly what moved, named, so a reviewer can see the boundary of the work without guessing at it.
- 02
The validation output
What ran against the change, and what it reported — not a description of tests that exist somewhere else.
- 03
The rendered evidence for every batch
A real screenshot or export from the actual build, for each batch of work, not a description of what it should look like.
- 04
The tie-out re-run against what was actually built
The same reconciliation the redesign promised, run again against the finished artefact, not against the design that preceded it.
The rule
No silent substitution.
The rule
Anything in the approved design that could not be implemented is listed with the exact blocker.
A simpler technique is never quietly swapped in for a harder one without saying so.
Status
Adopted, not claimed.
Where the work comes from
Free tooling, adopted where it already does the job.
Where the platform already does a piece of this work well, it is adopted rather than re-implemented and re-branded as something original.
The differentiator is the judgement and the proof that come with the build, not who authored the underlying tooling.
One implementation-blueprint screen exists inside the review prototype. Separately, four PBIR/TMDL mutation scripts exist as benchmark evidence — untested, bound to a single fixture, and not product code. Nothing here builds a customer report today.
Status as at 2026-09-11 · Sources: existing-code inventory · benchmark artefacts
Next
Check what the build changed.
The build's only real claim is that the tie-out survives it.