The Suite Was Green. Four Binding Controls Hadn't Established Their Claims.

Part three of: OpenAI Says Verified Defenders Get More Access. I'm Going to Test That.

On August 5 I published a bounded result. On August 9 a reviewer replied with a detailed
schema he had clearly spent real time on, designing against that result. The result had been
withdrawn four days earlier and I had not gone back to the thread to say so. This is what the
audit found, why the whole class came down instead of most of it, and the one defect underneath
the other four. Part three of a series. Evidence classes are marked throughout. Every
receipt in this piece is a live public URL, re-verified on the day this published.

Part one
froze a measurement instrument for defender access, published the design, and watched it fail its
first independent break before collecting a single data point.
Part two
built a words-versus-actions ledger, ran six rows against public lab commitments, and carried ten
corrections to my own work in the body rather than in a footnote.

Part two set the condition for this one in its last line, and I am quoting it rather than
paraphrasing it:

Part three, if it exists, is not more vibes about power. It is only whatever survives the same
row discipline without opening a graph nobody can finish.

So this part turns the ledger around. Same method, same evidence classes, applied to my own
published result. It is not an apology piece. An apology is not a finding. What follows is a
taxonomy of four ways a control can be green while proving nothing, and it is generalizable —
I found the same shape in a second, unrelated system of mine six days later, which is the part
that actually matters.

1. The claim, exactly as it stood

Evidence class: PRIMARY. DEV comment 3ceag, 2026-08-05

The claim was narrow on purpose. I wrote the boundary before I wrote the result:

in a frozen deterministic model extending public run k, a recovery gate keyed to the exact
state version recovery consumes — and to that version's transitive lineage — can block the two
attack topologies run k already freezes as d and e, still allow the legitimate verified recovery
run k freezes as f, retain those three verdicts when the caller declaration is honest, empty, or
forged, and, on a multi-hop derived-object path, block only when lineage is walked.

And the setting, so the claim could not silently expand:

local, deterministic, in-process stdlib simulation · preregistered before implementation ·
no bot, no api key, no third-party room, no live multi-agent surface · independent
outside-substrate reproductions of this result: zero

I want that on the record before the failure, because it is the one thing that worked. The
scoping was honest and it was written first. That did not save the result. A correctly scoped
claim can still be unearned, because scope governs what you assert and controls govern whether
you may assert it. Those are different jobs and I had only done one of them.

2. What found it

Not a test run. The tests were green.

And it was not me who found it. A'Lathos, a separate model seat inside this project, was run
against the published branch and walked the frozen contract control by control. I confirmed the
findings by execution and published the correction.

That attribution needs one more layer, because my own first correction got it wrong. The document
at 9f0b352 credited "an external cold audit" and "an outside reader of this branch." That was
false, and I corrected it hours later at
0d8267d: no unaffiliated
party found these defects. In my own words there — the error came from inferring the source from
formatting in an adjacent message rather than asking, which is the same substitution of a
convenient proxy for the primary source that the rest of this piece is about. This was internal
adversarial review, not outside-substrate reproduction.

The method itself is the copyable part: read each control's body against the
property it was supposed to establish, instead of reading its output. That takes about an hour
for ten controls and it is the only method here worth copying.

And the distinction matters more than "they all passed," because they did not all pass. C7, C8
and C10 returned success. C5 returned nothing, because it did not exist. There was no red, no
flake, and no warning that a frozen obligation had never been implemented at all. A suite cannot
tell you a control is not a control — that judgment sits one level above the thing being run, and
nothing inside the suite occupies that level.

Evidence class: PRIMARY. Correction commit 9f0b352, 2026-08-05T23:43:45Z

3. The four modes

Read the shape column, not the control names. The names are local to my repo. The shapes are not.

Be precise about what is wrong with them, because the imprecise version is easy to dismiss.

These are not all functions that could never return False. C7 also required the observer head
to have moved; C10 runs D, E and F and returns their conjunction, and those traces can fail. The
defect is narrower and worse: none of them could falsify the claim frozen above its name. C5
never executed at all. C7 manufactured the P2_VERSION_CHANGED_AFTER_READ verdict by hand instead
of eliciting it from the gate, so the gate was never asked to classify a version race. C10
instantiated none of the baselines it claimed to beat, so it could not establish superiority over
always-allow, always-deny, tenant history, or principal closure.

A control does not have to be incapable of failing. It only has to be incapable of falsifying
the claim written above it.

C8 is the interesting one and the most dangerous, because C8 could have failed. It ran, it
touched real code, and it returned the outcome the contract wanted. It was simply reading a
different property than the one it was written to read. A wrong-reason pass is indistinguishable
from a real pass at the level of the verdict, and distinguishable only at the level of the reason.
That is why the observed reason has to be recorded next to the decision, always. If you log only
BLOCKED, C8 is invisible forever.

4. Why the whole class came down

The frozen contract defined the positive result conjunctively: D BLOCK + E BLOCK + F ALLOW, with
every control passing.

Not most controls. Every control.

That wording was written before implementation, and when four controls failed it left no room to
negotiate. I could not preserve or downgrade the conjunctive result class by grading on the controls that
held. The class was defined as an AND, so one failure collapses it. What I could do — and did, in
§6 — is retain the individual observations that actually executed, as partial evidence. Those are
different objects, and conflating them is how a collapsed class gets quietly reported as a
diminished one.

I want to be plain that this was not virtue at the moment of withdrawal. The decision had already
been made — one day earlier, on August 4, in a contract frozen before implementation that I could
no longer edit without leaving a visible change in the record.
The conjunctive bar is the mechanism; the withdrawal was just the bar executing. If the
contract had said "controls should generally pass," I would have had a judgment call, and I do not
trust what I would have done with one at 11pm with a published article attached to the result.

Freeze the bar before you know which side of it you land on. That is the whole technique.

5. The defect underneath the other four

Evidence class: PRIMARY. DEV comment 3cl48, 2026-08-09

The four control failures are a process finding. This one is an architecture finding, and it is
the reason I could not simply patch and re-run.

The gate took its destination from prepared.raw_value — the value sitting in the observer
ledger. So there was no independent binding between what a recovery actually read and what the
ledger said it returned.

The ledger was the read source, not a witness to it.

An observer that supplies the value later cited as evidence of what another component read is not
an independent witness to that read. It is a variable with a formal-sounding name. Every downstream verdict keyed off that value inherits the assumption
rather than testing it, and no amount of care in the controls can recover from it, because the
controls are downstream of the same value.

The honest description of what I had built is authorization against an instrumented state-version
ledger, which is meaningfully weaker than the custody claim I put in front of a reviewer.

This generalizes past my repo, with one narrowing. A log written by the component being audited
is still useful audit data — applications emit their own logs constantly and should. What it
cannot provide by itself is independent evidence that the component behaved the way its own log
says it behaved. Durability and timestamps are the parts that make it convincing, and neither one
manufactures independence.

6. What was not withdrawn

Row discipline cuts both ways, so this section exists.

I withdrew the result class, not every observation. The correction commit says so explicitly,
and it says so because over-withdrawing is its own species of dishonesty — it buys credibility by
destroying evidence, and it makes the record less accurate, not more.

That last row is a rule I will not trade. run_n.py still prints the old result class when you run
it. The fix is not to quietly edit it so the output matches the correction — its hash appears in a
frozen contract, and silently changing a frozen artifact to agree with a later finding is precisely
the behavior I spend these articles arguing against. It stays wrong, off main, with a correction
next to it. Verified live at publication: run_n.py returns HTTP 404 on main; main is
d44a72c.

7. The shape recurs — which is the actual finding

Evidence class: PRIMARY — own-system evidence, not publicly inspectable in this article. 2026-08-11 through 2026-08-14.

One failure in one repo is an anecdote. Here is why I think this is a class.

Six days after the withdrawal I audited a completely different harness of mine, for an unrelated
reason, and found two more rows with the same defect — not rows that could never return False,
but rows that could go green without testing the property assigned to them:

• One was supposed to verify that every immutable field was covered. It built its expected set from three literals inside its own body and compared them to a module constant. It touched no field, no value, and no code path. That is C7, rediscovered in a system that shares no code with the first.
• The other asserted that eight dictionary keys existed and never checked a single value. It was the row whose entire job was to catch the defect that later got through.

Both sat green through review rounds where people were actually looking.

In the same window I found a scheduled verifier firing on schedule against a script that no longer
exists. The child process exited 127 every time. I do not know for how long.

And here the taxonomy needs a third row, because 127 is a failure signal. Nothing consumed it,
escalated it, or turned it into anything an operator would see. The schedule was alive;
verification was dead.

So the three are not the same failure, and it is stronger to separate them:

The common defect was not silence. It was that no trustworthy negative signal reached anyone who
could act on it. And unless you build a heartbeat, an expected-control manifest, or a dead-man
check, absence never becomes an event by itself.

One honesty note: this is a recurrence in a different system by the same maker, not a measured
prevalence. It supports "I make this class of mistake." It supports nothing about how common it is
anywhere else.

As one reviewer put it, and I am adopting the sentence: a control suite needs its own null. I
pointed my instrument at the gate and never turned it around on the things watching the gate.

8. What survived, and who it came from

The reviewer's schema was the most useful thing in the exchange, and it survives the withdrawal
intact because it was never dependent on my result being true.

Two elements I adopted and am keeping:

1. declared_dependencies must stay separate from observed_reads / observed_writes. If those collapse into one field the result becomes uninterpretable — which, given §5, is not a hypothetical for me. It is the exact defect I had, arriving as schema advice before I knew I had it.
2. Declare the candidate key before checking the outcome, or the result quietly becomes "we found the key after seeing the failure." I claimed that discipline and then did not hold it everywhere.

The second one stings appropriately. I had preregistration in the contract and still let hindsight
in through a side door.

9. What is still owed

When this was drafted on August 14, the package he asked for did not exist. It does now. It
shipped late on August 14 EDT — commit 5489233, 2026-08-15T00:43:13Z — days ahead of the date
I gave him, and it is public:
fixture-run-k-defg.

I am leaving the next three paragraphs as they were written, because the reasoning that produced
the choice is the useful part and editing it after the fact to look decisive would be the same
move as quietly fixing a frozen artifact.

There were exactly two honest routes:

1. Repair the mechanics through contract, implementation, and an independent break, then build the package from repaired mechanics; or
2. Freeze a separate packaging-only fixture with the narrower boundary stated up front, and say plainly that the withdrawn claim is not included.

Route 1 is the one worth reading. It is also blocked on an independent break I do not control, so
committing to it would be committing to a date I cannot keep.

I took route 2, and I told him directly rather than announcing it here. The fixture ships the
traces, the verdicts, and a stdlib CLI emitting the schema he specified, with declared kept apart
from observed. It does not carry the custody result class.

And the multi-hop case is not in it. I intended to ship it as a trace with its verdict. It
could not be done: G exists only inside run_n.py, the withdrawn artifact, which is deliberately
not on main and returns 404 there. Shipping it would have meant either publishing withdrawn
machinery or handing him rows he cannot regenerate from a clean clone. The frozen contract required
G to be reproducible from main or dropped, so it was dropped, and he was told that in the same
message that delivered the rest.

The order matters more than the choice. A commitment made to a reader in an article is a
commitment made to nobody in particular; the person owed the package finds out at the same time as
everyone else, which is how a four-day gap becomes a habit instead of an incident. He got it in
the thread first.

9b. Then the fixture repeated the disease

This is the part I would most like to leave out, and it is the strongest evidence in the piece.

The frozen fixture contract was wrong, and the freeze caught it. Contract v1 expected Trace D's
tenant-keyed gate to BLOCK. It ALLOWS — the mutation lands on tenant_7, the recovery runs on
tenant_9, and tenant-keyed history is empty, so the sequence rule never fires. That miss is the
entire reason Trace D exists. My expectation inverted the finding of the trace. The emitter returned
FAILED_TO_REPRODUCE, v1 was kept unedited, and v2 recorded the correction. Had I written the
emitter first and back-filled the expectations from its output, all ten rows come back green with
my misunderstanding baked in permanently.

Then I attacked the fixture itself. I pointed a fabricated run_k at it — a module that
returned the expected verdicts from hardcoded literals and touched no gate at all.

It emitted 10 of 10 REPRODUCED, exit 0, with actor_id: FAKE and chain_sha256 all zeros.

The classifier was asserting REPRODUCED — a claim about gate behaviour — without ever
establishing it had run against the gate. The only thing that caught it was a golden-file diff, so
anyone checking the exit code or the outcome counts would have passed clean on invented data.

Read that against §3. I built this fixture because the original system had controls that went
green without proving what they claimed. The fixture then printed REPRODUCED without proving it
had run the gate. The failure class survived migration into the tool built to expose the failure
class.

The repair, now public on the branch: the emitter hashes the source the interpreter actually
loaded and refuses to write a single row if it cannot identify it; the hash ships in the manifest
so the claim is re-derivable from outside the process; and a mutation harness must declare the
mutated hash, where a declared hash that does not match what loaded still aborts. It holds against
four attacks including a declared lie. Credit for the shape belongs to a reviewer who raised it
about mutation harnesses — a read-back assert proves a file contains text, not that the artifact
was imported and executed.

Independent reproductions of that fixture: zero. Nobody who is not the maker has swung at it.

10. What this does not establish

• It does not establish that the gate design is wrong. It establishes that the conjunctive result class was never fully tested — several behavioural rows did execute and are retained in §6, while four binding control obligations failed to establish the properties assigned to them.
• It does not establish a rate. Four controls in one contract, plus two rows and one dead verifier in a second system, is a shape I can name — not a base rate I can quote. Anyone reporting a percentage from this is reporting a number I did not measure.
• It does not establish that reading control bodies catches everything. It caught these. A control that is well-formed and reads the right property can still be wrong in ways this method does not see.
• On the reproduction count, there are now two numbers and I will not let them merge. The separate A–L suite got its first outside confirming run on August 15 — a different runner, a different Python, all four expected values matched, and they re-checked my stdlib-only claim themselves before executing rather than taking it from me. Receipt: DEV comment 3d3lm, published with their explicit permission. This fixture has zero. Nobody who is not the maker has swung at it. A reproduction of one artifact is not a reproduction of another, and the temptation to report the better number is exactly what this series is about.
• The repo's own README has not caught up and still says the counter is zero. I am flagging that rather than letting a reader find the contradiction: the README on main is the stale artifact, the linked comment is the receipt, and updating a counter is a separate push I have not made.

The row that survives

Part two measured other people's stated commitments against their observable actions, and closed
by saying the honest version of that method has to be survivable when it is turned around.

Turned around, it produces this: on August 5 I asserted a result; on August 5 I withdrew it; on
August 9 I told the person building on it, four days late. The action is admissible under the
same gate I used on everyone else — if I did nothing further from that day forward, the withdrawal
would still be true, the commit would still be public, and the file would still be off main.

The four days are the defect. The withdrawal is not the achievement; the conjunctive bar wrote the
withdrawal for me. What I actually failed at was the notification, and no contract clause covers
that, because it was not a code path. It was going back to a thread.

The instrument was pointed outward the entire time.

Part four continues only if a live result earns it. Same condition part two set: nothing here
gets extended on vibes, and a part that has nothing new to measure does not get written.

Receipts, all re-verified 2026-08-16:
claim 3ceag ·
reviewer schema 3cl0d ·
withdrawal 3cl48 ·
correction commit 9f0b352 ·
attribution correction 0d8267d — read this one beside 9f0b352, which carries the false "external cold audit" line ·
fixture repair a9d429f ·
outside reproduction receipt 3d3lm ·
repo main @ d44a72c ·
part one ·
part two