- What it does
- Holds a change to a fixed sequence of review, quality assurance, release and sign-off, and denies the merge outright if a stage is missing, has expired, or does not bind to the change it claims to cover.
- The control
- The denial itself. Each stage leaves a tamper-evident receipt chained to the one before it.
- Failure
- Where agents write production code, nobody can otherwise show that the review happened.
- Unit of work
- Evidence produced as a by-product of doing the work, rather than assembled afterwards for an auditor.
- Authority
- Named systems
- Client has not disclosed the stack
- Claims
- The mechanism, which is verifiable: a merge that skipped a stage is denied by a receipt chain bound to the same commit. At scenario inputs of 10,000 changes a year, 40 minutes of evidence reconstruction per change and $150 an hour, a separate enterprise sensitivity model values released assurance capacity at approximately $1 million a year.
- Non-claims
- Any defect-cost multiple. The figures in circulation are old and softly sourced, and would not survive a buyer checking them.
- Evidence held
- Run on one production software project, with receipts emitted inside the ordinary delivery path.
- Status
- In production
Evidence that the process was followed
Where agents write production code, the governance question arrives immediately: how does anyone know the review actually happened.
The same ten fields, with the arguments behind them.
Built into the delivery path, not added after it.
On the project behind this case, every change passed through the same receipt chain. The evidence was emitted while the work moved, so nobody had to reconstruct the sequence when a release was challenged later.
Map
Name the stages, and their order.
Review, quality assurance, release, sign-off. A fixed sequence is what makes a missing stage detectable at all.
Build · Receipts
Tamper-evident, and chained.
Each receipt binds to its predecessor, so the sequence cannot be reassembled out of order after the fact.
Build · Binding
Bound to one commit, with a clock.
A receipt covering a different change, or an older state of this one, fails rather than passes quietly.
Chaining and binding are separate properties, and a chain without a binding proves only that four notes were written in order
Ship
The gate denies the merge.
Not a warning, not a status. The merge does not happen.
A missing, expired or unbound receipt denies the merge
Run
Evidence accumulates without anyone assembling it.
The receipts are a by-product of the work, so there is never a moment where somebody prepares them for an auditor.
Before and after.
| Measure | Before | After |
|---|---|---|
| Changes reaching merge with no recorded review | Possible; the process recorded no enforceable proof | While enabled, the gate refuses any change without a bound review receipt |
| Assembling the evidence for one change | Manual reconstruction after the work | Receipts emitted during delivery are the evidence, so no separate reconstruction is needed |
Measured on one production software project. Deliberately excluded: any defect-cost multiple.
A million dollars of assurance capacity before incident risk is counted.
The implementation record above covers one production project. For a delivery estate moving 10,000 changes a year, removing 40 minutes of evidence reconstruction from every change releases 6,667 hours. At a $150 fully loaded hourly cost across engineering, security and assurance, that is approximately $1 million of annual capacity.
| Assumption | Model |
|---|---|
| Production changes | 10,000 a year |
| Reconstruction removed | 40 minutes per change |
| Capacity released | 6,667 hours |
| Annual capacity value | Approximately $1 million |
This is a sensitivity model, not the project’s measured saving. Defect avoidance, audit findings and incident cost are excluded because the receipt chain proves process, not causation.
What this case does not claim.
No defect-cost multiple, no bugs prevented, and no quality figure of any kind. The gate proves a process ran; whether the process was any good is a separate question and this system has no view on it.
No claim that one project’s denial rate generalises to another. The workflow and receipt binding travel; the count does not.
No claim that it stops a determined person. Somebody with the right access can turn a gate off. What they cannot do is turn it off invisibly.