Rewrite the frozen contract
This could make production pass by changing the definition of done after the approved result was known.
Case study · FalseGreen on FalseGreen
FalseGreen caught a problem that passing tests couldn’t.
The code repair passed its tests. But different parts of the production system disagreed about which worker was actually authorized to verify it.
FalseGreen refused to call the system finished until there was one trustworthy answer.
What FalseGreen stopped
- code
- The repair passed its local checks.
- problem
- Production could not prove that the worker was the one authorized to verify it.
- current state
- Refused before verification began
The problem
Locally correct repairs. Globally conflicting truth.
FalseGreen was preparing a production verification run after infrastructure changes. The application-level repair looked correct, but production exposed a deeper disagreement about identity and authority.
A launcher or transport change could make an otherwise approved executor appear invalid—even when the authority-bearing environment had not changed.
Passing was not the same as preserving acceptance
Manufacture a replacement identity
This could satisfy an obsolete identity check without proving that the original acceptance decision remained valid.
Either path could produce a green state without establishing the truth production needed.
What independent acceptance exposed
The defect was in the truth model.
Different parts of the system were answering the same authority question differently. Before launch, the acceptance boundary forced one unambiguous answer to each of these questions.
- 01
What execution environment was actually approved?
- 02
Which facts are authoritative?
- 03
Which facts are provenance?
- 04
What may change without invalidating acceptance?
- 05
Who determines that at execution time?
That disagreement was the split-brain exposed before launch.
The repair
Separate authority from provenance.
The repaired design separates four distinct concepts instead of allowing one identity to stand in for all of them.
01
Executor authority
The authority-bearing runtime, sandbox, controller, verification policy, and configured runtime/image identities measured by the worker.
02
Transport provenance
Signed evidence about how work reached the executor. It remains auditable without redefining executor authority.
03
Frozen acceptance criteria
The definition of done and authority requirements approved before the result was known.
04
Production state
The state transition production may trust only after the exact authority proof and frozen criteria are satisfied.
Transport identity remains signed provenance. A launcher or transport change alone cannot redefine the authority of the executor that performs verification.
Before execution
The worker measures authority before /begin.
Authority is not inferred from the launcher. The worker independently measures the execution environment that will bear the verification decision and authenticates an exact proof of it.
mismatch → no /begin
verification → does not begin
verifier commands → 0
- 01
Measure
The worker independently measures its authority-bearing execution environment.
- 02
Authenticate
The worker produces an authenticated exact-authority proof.
- 03
Compare
The proof is verified against the identities and policy frozen in the contract before /begin.
- 04
Execute or refuse
A match permits verification to begin. A mismatch or tampered proof fails before any verifier command runs.
Current status
No manufactured continuity. No invented verdict.
The existing production path could not satisfy the repaired trust boundary without changing the executor it had frozen. FalseGreen refused to manufacture continuity where continuity no longer existed.
The new production worker and fresh live acceptance run are still pending. This case study does not claim the eventual result.
- The authority mismatch was detected before /begin.
- The legacy run never crossed /begin; zero verifier commands executed.
- The frozen acceptance contract was not rewritten to force a pass.
- The legacy run and its pre-execution evidence remain preserved; no verification verdict or report was manufactured.
- The eventual verdict depends on a fresh live acceptance run with the new production worker.
Why this matters
Locally correct code can still produce conflicting system truth.
Coding agents can produce code that is locally correct while the surrounding system still disagrees about what was built, where it ran, what authority it had, or whether it satisfies the original definition of done.
FalseGreen exists to resolve that disagreement before completion becomes trust.
That is canonical software truth at the acceptance boundary in practice.
Independent acceptance
Completion should become trust only once.
Freeze what done means. Measure the authority-bearing environment. Accept only the exact result the evidence supports.