Method · The standard we hold work to
Generation got cheap. Proof didn't.
For fifty years the expensive part of software was writing it. That cost has collapsed — but what got cheap is generating a plausible draft, not delivering a correct system. The work moved to the two things generation cannot do for you: deciding precisely what to build, and proving that what got built is right.
The shift
The bottleneck didn't vanish. It moved to the ends.
The old project was fat in the middle: a little deciding, a great deal of building, a little checking. Building is what firms like ours sold. The new project is fat at the ends. The middle — producing a first draft — is now the cheapest and least differentiated part of the job, the part your team can also buy for the price of a few tool seats.
So we stopped selling the middle. What a senior engineer is scarce for now is specifying precisely enough that a machine can act on it, and proving rigorously enough that you can rely on it. Everything below is how we do the second half.
The rules
Four rules we don't break under deadline.
A method with no teeth becomes a style guide everyone admires and nobody follows the first time a date leans on it. These four break the build. Bypassing one takes a dated, written waiver from a named person — never a quiet skip.
The spec is what we check against
Work is verified against the specification you agreed, never against the code that was generated. A requirement too vague to test is not a requirement yet, so ambiguities come back to a human before anything gets built on top of them.
Nobody verifies what they built
Independence is a rule about artifacts, not about people. One engineer can build one thing and verify a different thing. No one signs off on the piece they produced, and the builder's own tests are a build-time check — never the acceptance gate.
Conformance, not green tests, means done
Passing tests tell you the code does what its tests say. They do not tell you it does what was approved. We put the delivered thing beside the approved thing, list every difference, and close each one. While a gap is open the status is in progress, not done.
When a decision moves, everything downstream re-checks
A late change to a business rule can leave acceptance criteria encoding the old behaviour — and those stale criteria will pass an implementation the current design forbids. Green and wrong is the worst state a system can be in, so a changed decision re-opens every artifact that consumed it.
The gates
Seven layers, cheapest first, nothing skipped in silence.
A change is not done until every applicable layer is green. The ordering exists so that expensive human judgement is spent only on what survived everything below it. If a layer genuinely doesn't apply, that is recorded as not applicable with the reason — a gap you've named is a decision, a gap you've hidden is a defect waiting for your users to find.
- L01 Static analysis Does it build, do the types check, is the schema valid. Every change
- L02 Unit and property tests Logic in isolation, plus rules checked against many generated inputs rather than three hand-picked ones. Every change
- L03 Integration Components together, against a real datastore rather than a mock. On merge
- L04 Acceptance End-to-end scenarios written from the spec's criteria, by a chain that did not write the code. Merge to main
- L05 Reconciliation Output diffed against a trusted answer — the legacy system, a reconciled dataset — where one exists. Where an oracle exists
- L06 Independent review A fixed panel of reviewer roles, each prompted to find fault rather than to approve: spec conformance, adversarial correctness, security, domain logic. Invariant and critical-path changes
- L07 Human sign-off A named owner, and in regulated work a credentialed domain expert, putting their name to the result. The last gate, always
The cadence is layered on purpose. Anyone claiming to run end-to-end acceptance, ground-truth reconciliation and a full review panel on every single commit is either not doing it or not shipping.
What you're handed
The evidence ships with the software.
Verification that stays inside our team is worth something to us and nothing to you. These artifacts are part of the delivery, and they are what a scope dispute gets settled against instead of whoever is more senior in the room.
The honest edges
What this does not buy you.
Prove is a standard of evidence, not a guarantee. When we say we prove something, we mean independent, spec-traceable evidence strong enough that a named person puts their signature against it. We do not mean mathematical proof. Testing shows the presence of defects, not their absence.
Correctness is not the same as your business result. We can prove a system does what the spec said. Whether that made your workflow faster or your revenue higher depends on your users, your data and your market. We prove what we control, and we name and bound the rest in the contract rather than quietly promising it.
The strongest gate isn't always available. Reconciliation against a trusted answer is the sharpest check we have, and it needs a trusted answer to exist. On replacement and modernization work it usually does. On genuinely new features it often doesn't, and there the correctness claim rests on the quality of the spec and on human judgement. We say which case you're in rather than letting the silence read as coverage.
FAQ
The obvious objections, answered.
Isn't this just testing with a longer name?
Doesn't all this verification make you slower and more expensive?
Your engineers are distributed. Why should I trust work I can't see?
Do you use AI to write the code?
Can you guarantee the outcome?
Ask us how we'd prove it.
Bring the piece of work you're least sure about. 30 minutes, no deck — we'll tell you which gates apply, which don't, and what evidence you'd get.