There is a difference between installing a system and proving that it is operating.
We learned that the hard way.
The project started with an attempt to equip Codex with a large Claude-derived harness: hooks, memory systems, ledgers, safety gates, self-tests, and supporting organs. The first question was simple:
Can the harness actually run?
The first answer was encouraging but incomplete.
A read-only copy was preserved. A separate writable runtime was created for state and ledgers. The configured hook registry replayed successfully. The organ battery produced 50 passes and 2 failures. A behavior probe produced 8 passes and 2 failures.
That was useful evidence—but it was not proof that Codex had become a native host for the Claude lifecycle.
The harness could run as an external exoskeleton. That was different from proving that Codex itself executed the same lifecycle natively.
There were also concrete gaps.
The action gate blocked a recursive Unix-style delete but missed the equivalent PowerShell shape. Another conscience check missed two strong-claim cases. A memory test contained a stale fixture expectation. A security test passed its assertions but encountered a Windows teardown problem afterward.
So I asked for another test.
The fresh proof pass caught a problem in my own test: Sentinel had moved from RED to YELLOW, but my probe still expected it to remain RED. That meant the probe was testing a frozen assumption instead of testing the live state machine.
The correction was simple but important:
A valid test should verify that the system reports its current state, not demand that the state remain unchanged.
Then came the more important request: build a Codex-native version.
The Claude clone stayed preserved as the specimen. The Codex adaptation lived in its own workspace. It used the same principles, but with Codex- and PowerShell-aware gates, explicit preflight and final-check entry points, and tests aimed at the holes the first pass had exposed.
The first run scored 9 out of 10.
The failure was not a safety bypass. The final-check expression was too rigid. It accepted a verification block only when it appeared in one exact format. The repair broadened the accepted evidence shape without weakening the requirement that evidence be present.
The second run reached 10 out of 10.
The adapted layer now blocked recursive deletion of the protected harness, remote fetch-and-execute patterns, force-pushing a Git branch, and strong completion claims without an explicit verification or receipt block.
That result was meaningful, but it still did not mean the entire Claude organism had been reproduced. The original transplant still had two meaningful behavior failures. The Codex-native layer was a smaller, explicit enforcement surface for Codex’s own runtime.
That distinction matters.
A passing test can still be misleading if the test is stale. A configured hook can still be inactive. A visible memory file can still be unobserved. A wrapper can still claim failure after the underlying process succeeded.
The standard became:
- configured is not loaded
- loaded is not trusted
- trusted is not executed
- executed is not automatically correct
- correct is not complete until the real receipt is inspected
The second-pass report was therefore more honest than the first one. The initial verification was mostly right, but underpowered. It proved that the transplanted harness could run and exposed real gaps. The new self-harness proved that Codex had its own tested enforcement layer.
That is the lesson I would carry into every AI system:
A feature is not real because its files exist. It is real when the runtime demonstrates the behavior, the negative case behaves correctly, and the final claim is backed by evidence.
The goal was never to make the system sound more alive. The goal was to make it more accountable.
And accountability begins with a simple rule:
Don’t tell me it is installed. Show me that it ran.
Top comments (1)
The 9/10 → 10/10 repair is the most instructive part of the writeup, because it names a fix but not the trap sitting right next to it: broadening the accepted evidence shape is exactly how a gate quietly stops gating.
The repair — "the final-check expression was too rigid; it accepted a verification block only in one exact format; the fix broadened the accepted evidence shape without weakening the requirement that evidence be present" — is the right instinct. But broadening's failure mode is not that the requirement weakens; it's that a shape-match stops implying a semantic match. A block in the new accepted format can reference nothing real: a verification section naming a check that never ran, a receipt pointing at state that was never touched. Your own first pass shows the same drift in gates: the action gate blocked the recursive Unix delete but missed the PowerShell shape — the gate wasn't missing, it was parsing a different representation of the same destructive action. Shape and semantics had drifted apart, and only a differently-shaped probe exposed it.
So the rule that falls out of your own chain: when you broaden the accepted evidence shape, re-run the negative cases under the new shape. After a broadening the fixtures should be a triplet:
That's "the negative case behaves correctly" applied to the evidence shape itself, not just the behavior. Your probe bug is the same lesson one level up: the probe expected RED when Sentinel had moved to YELLOW — the test was reading a frozen model of the system instead of the live state machine. The stale fixture wasn't in the memory test; it was the test itself.
And "correct is not complete until the real receipt is inspected" — the receipt has to be real in the same sense: produced by the thing it claims to verify, or by a channel outside it. A self-report in the accepted format is a receipt in shape only. The 10/10 is trustworthy because the re-probe existed, not because the shape was broadened.