04 / xVerify
Proof that nothing changed by accident.
Planned: xVerify would compare the before and after of a report and print exactly what changed, what did not, and what it cannot tell you.
The comparison
What is compared.
Three things, always in this order.
- 01
Structure
What the report is made of — the model, the measures, the visuals — before and after the work.
- 02
Behaviour
The same questions asked of both versions, across the states the audience actually uses, with every difference reported rather than sampled.
- 03
Closure
Every finding from the review is re-tested against the new artefact, not just noted as addressed.
The proof
What it has to prove
- 01
Every observed difference maps to a declared change
Nothing shifts in the numbers without a named reason on file for it.
- 02
Every finding that was false is now true
A resolved finding is checked again, not assumed resolved because the redesign said so.
- 03
No measure kept its name and changed its meaning
If a definition moved, the name has to say so — a silent rename is treated as a failure, not a detail.
The refusal
What it refuses to conclude.
The refusal
xVerify proves the absence of unintended change; it does not prove correctness.
It does not claim the redesign is better than what it replaced. It says nothing about states it did not test. And a number that was wrong in both versions verifies clean — verification is not the same claim as correctness.
Status
Where this actually stands.
Honest status
Drafted, not built.
No verification engine exists in any repository. Adversarial tests and golden reviews are drafted, the hash-manifested before/after fixture corpus it would run against already exists, and the work is estimated at 30–40 engineering days.
Status as at 2026-09-11 · Sources: existing-code inventory · X contracts · golden and adversarial tests
Next
Start where the evidence starts.
Nothing is compared until something has been reviewed first.