DEV Community: Self-Correcting Systems

My Harness Used One Label for Three Different Failures.

Self-Correcting Systems — Mon, 14 Sep 2026 02:14:53 +0000

Three fixtures, three separate calls into the same reducer. Here is the complete
failure_reasons each one returned, unedited:

unreadable arriving args  ->  ["SANDBOX_EVENT_CARDINALITY_INVALID",
                              "EXEC_ARGUMENTS_MISMATCH",
                              "TOOL_RESPONSE_CARDINALITY_INVALID"]

usable args, different   ->  ["SANDBOX_EVENT_CARDINALITY_INVALID",
                              "EXEC_ARGUMENTS_MISMATCH",
                              "TOOL_RESPONSE_CARDINALITY_INVALID"]

our comparison threw     ->  ["SANDBOX_EVENT_CARDINALITY_INVALID",
                              "EXEC_ARGUMENTS_MISMATCH",
                              "TOOL_RESPONSE_CARDINALITY_INVALID"]

These are minimal fixtures with no sandbox event and no tool response, so the first and last
codes fire in all three and are expected. I am printing them anyway. A post about a receipt that
hides which party failed has no business showing you a cleaned-up receipt.

The middle line is the one that matters, and across three genuinely different failures it never
changes.

Fixture one sends arguments the parser rejects.

Fixture two sends a usable call that disagrees with what I froze.

Fixture three sends an object my own canonicalizer rejects, so the comparison never completes.

Constructed inputs, so none of this establishes who caused a failure in production. But one name
covers all three, and that name says argument mismatch even when nothing was compared. A failure
in the checking stage reads as a deviation in the thing being checked.

The reason it reads that way

pm25coder put it in one line, in the comments of the schema-comparison
piece
(permalink to the comment):

EXEC_ARGUMENTS_MISMATCH misreads as a verdict on the model precisely because its name carries no
subject.

Three different observations arrive under one name: arguments that were rejected, a comparison that
completed and found a difference, and a comparison that never finished.

The label is not wrong that something happened. It is silent about which of the three, and a reader
fills that in.

What the code actually did

One try was wrapping three different jobs:

if (call) {
    try {
      const actual = parseStrictJson(call.function.arguments);      // can the arriving args be read
      if (typeof actual?.command === 'string' && Buffer.byteLength(actual.command, 'utf8') > 256) {
        failures.add('EXEC_COMMAND_OVERSIZE');
      } else if (!canonicalJsonBytes(actual)                        // does the comparison work
                    .equals(canonicalJsonBytes(prepared.expectedExecArguments))) {
        failures.add('EXEC_ARGUMENTS_MISMATCH');                    // do they differ
      }
    } catch {
      failures.add('EXEC_ARGUMENTS_MISMATCH');                      // ...everything lands here
    }
}

parseStrictJson throws when what arrived is unreadable. canonicalJsonBytes throws when the
comparison itself cannot run. Both fell into the same catch, and the catch named the arguments.

Full file if you want to read around it:
scripts/judgment/live.mjs.
The third catch site was in
scripts/pr2/reducer.mjs.

The fix

Split the parse from the compare, and give each stage its own catch:

let actual;
try {
  actual = parseStrictJson(call.function.arguments);
} catch {
  failures.add('EXEC_ARGUMENTS_INVALID');
}
if (actual !== undefined) {
  try {
    if (typeof actual?.command === 'string' && Buffer.byteLength(actual.command, 'utf8') > 256) {
      failures.add('EXEC_COMMAND_OVERSIZE');
    } else if (!canonicalJsonBytes(actual)
                  .equals(canonicalJsonBytes(prepared.expectedExecArguments))) {
      failures.add('EXEC_ARGUMENTS_MISMATCH');
    }
  } catch {
    failures.add('EXEC_COMPARATOR_ERROR');
  }
}

Same three fixtures, same unedited arrays, only the middle line moves:

unreadable arriving args  ->  ["SANDBOX_EVENT_CARDINALITY_INVALID",
                              "EXEC_ARGUMENTS_INVALID",
                              "TOOL_RESPONSE_CARDINALITY_INVALID"]

usable args, different   ->  ["SANDBOX_EVENT_CARDINALITY_INVALID",
                              "EXEC_ARGUMENTS_MISMATCH",
                              "TOOL_RESPONSE_CARDINALITY_INVALID"]

our comparison threw     ->  ["SANDBOX_EVENT_CARDINALITY_INVALID",
                              "EXEC_COMPARATOR_ERROR",
                              "TOOL_RESPONSE_CARDINALITY_INVALID"]

The change spans three source files, plus the tests:
dd1a654.

The part that was not a rename

pm25coder called it "a rename, not a redesign" — his words, verbatim, in
3eanf — and from outside the repo that is exactly what it
looks like. Inside, two things were waiting.

There are two whitelists, not one. Failure reasons are filtered through an ordered array before
they reach the output. In live.mjs, a reason that is not in the array is silently dropped. Register
the new name in the code and not in the array, and that failure stops appearing. Other failures in the same run still show, so the run
does not go green by itself, but the one you just added becomes invisible.

There are two registries for this namespace and they fail differently.

live.mjs holds 26 codes and emits output by filtering against the list — FAILURE_ORDER.filter(...)
at lines 169 and 572, no guard. An unknown reason is silently omitted. scripts/pr2/constants.mjs
holds 20, a strict subset, and its consumer refuses to guess:

if (!FAILURE_ORDER.includes(reason)) throw new TypeError(`unknown failure reason: ${reason}`);

So the narrower list is the strict one, and the list covering more surface is the one that fails
quietly. That is backwards, and it is a worse defect than the naming problem this patch fixes: a
filter that discards unrecognised codes is designed to fail invisibly.

The throwing version is the correct behaviour. The silent filter should be replaced by it, and the
two lists should be one registry. I did not do that here, because bundling a registry refactor into a
naming fix would make both harder to review and would put a behaviour change in a commit that
claims to be about labels. It is on the list as its own change.

And there was a third catch site doing the same collapse in a different module, which I only
found by grepping for every place that name was added rather than trusting the two I knew about.

The tests, including the one that is supposed to pass

Six of them. That they pass is not the interesting part. Run them against the parent commit and five
of the six fail. Run against the patch, all six pass. The one that passes both ways is there on purpose:

One correction to the commit message before you click it. It says three of the six tests fail
on the parent. That line is stale: it was written when the file had four tests, and two more were
added in the amendment. The real number is five, and the ablation below is the thing to trust. I am
not force-pushing a rewrite of a public SHA to tidy a sentence, so the contradiction stays visible
and this paragraph is the correction.

All six are in one file, if you want to run the ablation yourself:
test/exec-comparator-error.test.mjs.

arriving args unusable       -> EXEC_ARGUMENTS_INVALID     fails on parent
usable args, differ          -> EXEC_ARGUMENTS_MISMATCH    passes on both   <- control
comparison cannot complete   -> EXEC_COMPARATOR_ERROR      fails on parent
pr2 reducer, unusable args   -> EXEC_ARGUMENTS_INVALID     fails on parent
prepared transport, digest   -> EXEC_COMPARATOR_ERROR      fails on parent
pr2 reducer, digest read     -> EXEC_COMPARATOR_ERROR      fails on parent

The control is doing something specific. Splitting one catch into two created two new boundaries
that the mismatch path now has to survive. If either boundary swallowed a case it should have passed
through, a suite that only asserted the two new names would still be green, because the case it ate
would simply never be asserted. The control fails the moment the original path stops producing the
original name.

The comparator failures are induced, not waited for. The arriving call parses cleanly and my own
expected object carries a BigInt the canonicalizer refuses.

That refusal is deliberate, not fragile. The serializer accepts a closed set — null, boolean, safe
integer, NFC string, array, plain object — and rejects everything else, because its output is
hashed and a canonical form cannot have alternatives. So a BigInt in an expected object is an
invalid internal type, and the test is contrived at the type level.

Be precise about what that buys: it proves the catch fires when the comparison cannot complete on
otherwise-valid input. It does not prove a spontaneous bug in the canonicalizer, and I am not
claiming one. The two digest-read tests induce a
different internal failure using a throwing getter, and each one asserts the intended read was
actually reached and that the error survives the final filter.

Two things I got wrong on the way, both caught by someone else

My first repair ran the collapse backwards. I moved the whole catch to
EXEC_COMPARATOR_ERROR, which meant unreadable arriving args were now reported as my machinery
failing. Same defect, opposite direction.

The reason it survived my own review is worth more than the bug. I wrote the implementation, then
wrote a test asserting what the implementation did. An assertion written against unverified output
cannot fail, because it was derived from the thing it is supposed to check. That workflow
guarantees you codify your own bugs, and it produced a test that defended the error.

Then I claimed one of the three catches was dead code. I had constructed a bad expected object,
watched it get caught by an earlier gate, and concluded nothing could reach that catch. One input
class, generalized to all inputs. It is reachable — a failing read on the manifest digest lands
there, because that read sits inside the try while the one I tested sits outside it.

Neither was caught by me. The backwards repair was caught before commit. The dead-code claim went
into the first commit and came out in an amendment, so it was caught before push.

What this does not do

It does not put the contract in the name. pm25coder's fuller point was that the label should
say what it was compared against, something closer to args_mismatch_under_contract=<id>, so the
name states the authority rather than leaving a reader to infer a subject. That is not built. The
names are separated. They still carry no contract id.

EXEC_ARGUMENTS_INVALID does not identify who produced bad arguments. It marks a boundary.

The arriving arguments were rejected, either by the parser or, on the PR2 path, by argument
validation. Valid JSON can still fail that validation. Who produced them is not established by
that result. The model, the relay, or the transport are all still live possibilities, and the name
stops where the evidence stops.

Naming a producer there would be the same defect with a friendlier label.

That neutrality costs something real, and it is fair to say so. An operator wants to know if the
model is emitting garbage, and unparseable JSON on a structured tool call may well be exactly that.
I have not measured how often it is, so I am not putting a frequency on it.
The code declines to tell them, which is semantically clean and operationally thinner. The fix is not to guess in the name. It is to preserve enough provenance that attribution can be
made afterward: what arguments were observed at the model-event boundary, whether any relay or
transport transformation happened in between, and which contract governed the call.

The contract-id work above would settle the authority half of that. It would not identify who
corrupted an invalid argument stream — a contract id says which expectation was in force, not where
bad bytes came from. I conflated those two in an earlier draft. Neither half is built.

EXEC_COMPARATOR_ERROR names the stage, not the cause. An un-canonicalizable expectation and a
genuine comparator bug are both on my side and are not distinguishable from the outside. I declined
to split them, because inventing a distinction the code cannot detect is the defect I was fixing.

The general shape, if you want to check your own

Find every place your system writes a failure name, and ask what the name is a statement about.
If it names a thing rather than a party — arguments, response, payload, schema — check what else
falls into the same branch. A name that describes the object can be read as a verdict on whoever produced it. Trace each error
from the operation that raised it all the way to the receipt, and check whether the name it arrives
under still tells the truth.

The question that found this one: when this fires, whose fault does a reader assume it is, and is
that always true?

If you want to check the claim rather than take it:

git clone https://github.com/keniel13-ui/self-correcting-integration-maintainer
cd self-correcting-integration-maintainer
git checkout dd1a654
node --test test/exec-comparator-error.test.mjs        # 6 pass

git checkout dd1a654~1 -- scripts/judgment/live.mjs \
    scripts/pr2/constants.mjs scripts/pr2/reducer.mjs
node --test test/exec-comparator-error.test.mjs        # 5 fail, 1 passes

That last run is the one worth doing. The test that keeps passing is the control.

If you have one of these in your own harness, I would genuinely like to see it. Different domains,
same shape.

You Agreed to a use. Not to a Hallway That Didn't Exist Yet

Self-Correcting Systems — Wed, 09 Sep 2026 15:27:22 +0000

You posted a photograph in 2014 to show your friends a night out. You understood what you were
sharing and who you were sharing it with. You did not agree to every future system that would read
it, combine it with other records, and decide something about you.

That is not a worry about surveillance. Surveillance is about being watched. This is about being
judged from inputs you never knew were inputs, by a rule you never saw, in a place you have
never been.

Here is what that actually looks like, in machines that exist right now.

Four machines that get mistaken for one

1. An allegation that travels. Patronscan sells ID scanning to bars and clubs. Venue flags stay
with the venue. Network flags surface at other participating venues when your ID is scanned. The
pitch is exactly what it sounds like: a patron banned at one venue cannot walk down the street and
start fresh at the next.

Say what a flag is. A venue recorded an allegation. It is a report, not a finding, and it travels
with the authority of a finding.

Their policies page publishes the network-versus-venue distinction, the conduct categories, the
retention limits, who has access, the route for removal, and the response windows. It does not
publish how often a dispute ends with a flag changed or removed, and I found no aggregate rate
published anywhere else. The process is documented. Its aggregate outcomes are not.

2. Affiliation, not conduct. In January 2023 the New York Attorney General sought information
about reports that MSG Entertainment used facial recognition to exclude attorneys whose firms were
litigating against it. Nothing was alleged about anyone's behavior. The input was who employed them,
and being on one side of a lawsuit is not wrongdoing.

The litigation is worth two paragraphs, because it answers a question people assume they know.

In Hutcher v Madison Sq. Garden Entertainment Corp. (2023 NY Slip Op 01646), the Appellate
Division agreed that Civil Rights Law § 40-b requires admitting a valid ticket holder to a
theatrical performance or concert. The plaintiffs were right about the statute. The court vacated
the injunction anyway, on a rule it quoted from 1915: where a statute creates a right and
prescribes a remedy, that remedy is exclusive. § 41 supplies it — a penalty of "not less than one
hundred dollars nor more than five hundred dollars." The legislature set that number, not the
venue. The March decision resolved the injunction, not the case; the § 40-b claim survived it.

The statute also does not reach sporting events. It names theatres, music halls, opera houses,
concert halls and circuses. At a basketball game the right in this story does not exist.

3. Inference from exhaust. Tenant screening, credit-based insurance scoring, employment
background checks. Frequently no incident anywhere — a score built from records you never saw,
about something you have not done.

4. The system acts. Not a database that informs a person who decides. Software that observes,
infers, decides, and operates the applications that make the decision real. In August, xAI launched
a persistent agent with its own always-on cloud computer, browser and terminal, signed into your
applications. In September, Anthropic shipped background computer use — the model clicks and types
while you keep working. These are shipped products.

I have not found a public case of one of these deciding about a person at a door. That gap is the
honest state of row four.

Collapse those four and one counterexample takes the argument down. Keep them apart and the
uncomfortable part shows up.

One of these happened to me

I did not go looking for a case. It was not any product named above. It was a vendor identity gate:
a photograph of my driver's license, a biometric scan of my face taken on my phone, an automatic "did not meet the
requirements," and no author on the sentence.

Nothing I was shown named a reviewer, a fact, or a rule. Run it through the three questions at the
end of this piece and watch them all fail. Is the fact wrong? I was never told which fact. Is
the fact right and the rule wrong? I was never shown the rule. If I win, what comes back?
I was not shown a path. That is not the same as no path
existing, and I was never given the difference.

That is not any of the four machines. It is the thing they have in common: a decision returned
with no author on the sentence. I submitted what was asked. I did not finish their process. I hit
the end of it.

Your footprint can do the job of an ID. Its protection depends on the transaction.

A Social Security number is an obvious regulated identifier. Your footprint does some of the same
linking work — the apartment, the job, the ride, the door — but what protects it is not fixed. It
depends on who is using it, for what, and under which regime.

Which protection attaches depends on the information, who is using it, for what, and under which
regime. The photograph does not change. The transaction does.

Hold that 2014 photograph constant.

A screening firm compiles it and sells it to your employer. In 2011 the FTC concluded a company doing exactly that was a consumer reporting agency, because it "assembles or evaluates" information furnished to third parties who use it for employment eligibility. Public posts, full FCRA obligations: accuracy, notice, dispute.
Your employer searches your name and finds it himself. The consumer-report route may not apply. That does not mean no law applies. EEOC and FTC guidance is explicit that background information is subject to federal anti-discrimination law "regardless of how you got the information." Remove the reporting company and the regime changes. It does not disappear.
A venue network attaches it to a flag. A different regime again, largely private.
An agent retains it, infers from it, and acts. Automation does not delete the organization that deployed it or the transaction underneath. Which duties attach depends on the workflow, and you cannot read that off the architecture.

Four handlings of one photograph, four sets of rules — not because the photograph changed, and not
because any of them is a lawless zone, but because which regime applies is a function of the
transaction, and the transaction is invisible to you.

You cannot know that when you post. You especially cannot know it in advance, because some of those
hallways were built after you posted.

Correcting a fact and contesting an inference are different rights

If a file has your birthday wrong, there is a procedure. If a system has your birthday, employer,
travel and associates all correct, and concludes from them that you are high risk, correcting the
records accomplishes nothing. Every input was already right. The conclusion was the problem.

California's Attorney General addressed this directly in Opinion 20-303. It is an opinion, not a
court holding, and that distinction matters. The reasoning does not:

"when a business processes personal information to make an inference about the consumer's
propensities, then the inference itself becomes part of the consumer's profile, and must be
disclosed. A business might draw an inference about a consumer based in whole or in part on
publicly available information... Under the CCPA, the inference must be disclosed to the
consumer, even if the public information itself need not be disclosed."

The conclusion drawn about you can carry more disclosure obligation than the public facts behind
it. The inference is a separate object. A proprietary algorithm does not automatically make its
individualized output a trade secret.

Three limits. One state. An AG opinion. And California separately provides a right to request
correction of inaccurate information (Civ. Code § 1798.106) — a third thing again. Access to an
inference, correction of a wrong fact, and forcing a decision reversed are three different rights,
and having the first does not get you the third.

One date keeps this honest: California's automated-decision-making rules took effect January 1
2026, and businesses using ADMT for significant decisions have until January 1 2027 to comply.
This is a gap scheduled to partially close.

"Human in the loop" is not a claim. A human can approve every action, approve only payments,
approve one objective at the start, review afterward, or merely be able to intervene. All five ship
under "human oversight." The question is where exactly authority sits.

The numbers, and where they are going

This is not a forecast. These are dated facts about a system already running.

California built a delete button and half a million people pressed it. The Delete Act created
DROP, a single platform where one request reaches every registered data broker. It opened January 1

By August 13 more than 475,000 Californians had filed (Governor's office, Aug 13). By August 25 the agency reported more than 500,000 registered and 654 data brokers in the system (CalPrivacy, Aug 25).

Registration is a business and the state priced it. A broker's annual registration fee is
$6,000. From August 1 2026 brokers must access DROP at least every 45 days. The penalties
are two separate meters: $200 for each day a broker fails to register, and $200 for each
deletion request for each day it fails to delete.

Then read the outcome numbers carefully, because they are the whole lesson. On August 25 the
agency reported tens of millions of records deleted, that 99.9% of consumers had their
profile deleted by at least one broker, and that the typical user had been removed by over 40
brokers. It also reported that about 25% of brokers had reported processing deletion requests.

Put those next to each other. 99.9% having at least one deletion proves reach, not completion.
Being removed by more than 40 brokers is a real result. But 654 is the system census, not that
person's denominator — DROP reports five separate statuses, including Record not found for brokers
that never held your data or could not match you from what you entered, Exempted for records a broker may lawfully keep, and Pending,
and brokers have up to 90 days to report.

So the honest reading is narrower and still hard: I have not found a published consumer-level
measure of how many people reached a fully resolved state across every broker that actually held
their data, or how long that took. Reach is published. Completion is not.

And I made this mistake myself while drafting this section, which is the point: a number is only
as good as the population it counted, and the trap does not spare the person writing about it.

The first enforcement action is the thesis in one sentence. In August 2026 California brought
its first action under both the CCPA and the Delete Act, against LocateSmarter LLC, for failing to
register and for requiring Californians to provide unnecessary data — the last four digits of
their Social Security number — before they could opt out. Total: $116,490.
(agency decision)

To switch off the sale of a record the law already covered, you had to hand over part of a more
sensitive identifier. California treated that extra demand as unlawful. The protection existed.
The company put a disclosure in the way of using it.

And read what the company was selling. Names, dates of birth, Social Security numbers, phones,
emails, employment, driver's license, bankruptcy records, litigation history — and inferences about
consumer characteristics, including whether a person is "litigious." The agency's own line:
"Inferences are a protected form of personal information under California law."

The arena used who employed you. The broker sold whether you sue. Same family of input. Not the
same machine.

And the next date is already set. California's automated-decision-making rules take full effect
for businesses using ADMT in significant decisions on January 1 2027. Whatever the gap is today,
part of it closes on a schedule, in one state, for covered businesses.

The claims that get to skip the evidence

Everything above had to be sourced. A flag is an allegation until someone adjudicates it. An AG
opinion is not a ruling. A staff letter is not a court order. That standard is not optional if you
want to be believed.

Now apply it to the loudest AI claim in circulation.

On September 3, Senator Sanders and Rep. Casar announced legislation to ban artificial
superintelligence and pause advanced AI development until a cabinet-level regulator exists, with a
corporate death penalty and up to twenty years imprisonment for violations.

Read the announcement for what it defines. It does define the class, broadly: systems that surpass
human intelligence, systems capable of overthrowing governments, systems with dangerous abilities
such as subverting shutdown commands. It also names who would decide: a proposed cabinet-level
regulator with an advisory board. What I did not find in the announcement or the one-page summary
is a benchmark or evaluation protocol for deciding when a system has crossed the prohibited
threshold. Up to twenty years in prison hangs on that threshold. The full bill text is still
described as forthcoming.

Read it for what happens next. The proposal names real instruments: "international agreements,
allied coordination, and policies such as export controls." Those are not nothing. What the public
material does not show is a mechanism that can compel a government or developer outside U.S.
jurisdiction that refuses to cooperate.

And when someone says advanced AI will end the world, ask the next question: by what mechanism,
and for what reason? Not "it will be very smart." A stated pathway you can check.

Notice what each side is required to produce. A person disputing a bar flag files into a documented
process with a published response window. A prohibition on a technology class travels as news with a
summary and no published threshold. I am not claiming anyone measured those two against each other.
I am asking the same question of both: what evidence would turn this into an enforceable
decision?

That asymmetry is the same defect this entire piece is about. How a claim gets treated depends on
who is making it and where it lands, not on what is behind it. A senator can announce a
prohibition on a technology class with a broad definition, no published operational threshold, and no bill text and it is news. You will need
receipts to get a listing corrected.

None of that is an argument for building anything anyone wants. It is an argument that the danger
worth legislating is the one you can describe: what is collected, what gets inferred from it, who
gets to act on the inference, and what you can do about it. That is not a ban on the technology.
It is a ban on a use. The difference is the entire distance between a law that could work and a
press release.

What is actually happening while that argument runs

Nobody has to coordinate any of this.

Safety teams study models. Privacy teams study data. Utilities study load. Cities study zoning.
Congress studies regulation. Each is competent inside its own boundary. The technology crosses all
of them in a single product release.

Preparation is fragmented. Deployment is integrated.

Every participant has an independent reason to accelerate one layer. Each decision can be rational
and the sum still moves faster than anyone chose.

Three questions that are not the same question

Is the fact wrong? There is usually a process for that.
Is the fact right and the rule wrong? A system can identify your employer perfectly. The dispute is whether your employer should decide whether you get into a concert. Correcting the record cannot touch that. Whether a route exists to challenge the rule itself is a different question, and it is not the same in every hallway.
If you win, what comes back, and when? A published response deadline is measurable. Whether the answer arrives before the apartment is rented, the job is filled, or the show ends is a different measurement, and I have not found it published.

Before a record decides something about you, you should be able to ask why it belongs in that
decision. Afterward, you need to know who can change the result.

If you have one of these, I want it

I am collecting real cases before building anything, not after. Mine is above.

If a decision about you turned on a record — a rental, a job, a claim, a door, an account — I want
four things, with every identifying detail removed:

What information was used, and did you know it was an input?
Was the problem a wrong fact, an unsupported inference, or the rule itself?
Who could change the decision, and what happened when you challenged it?
Did the correction reach everyone who got the error, and did it restore the opportunity?

Don't post anything that identifies you or anyone else. I am after the shape, not the file.

Compare Against the Schema They Shipped, Not the One You Expected

Self-Correcting Systems — Sun, 06 Sep 2026 21:57:04 +0000

My harness flagged the model for sending the wrong arguments. It compared what the model actually sent against what the run had committed to in advance, and they did not match.

The mismatch was real. The conclusion I drew from it was wrong, and the comparator could not have told me so.

Here is the check that was incomplete, the check that replaced it, why the fix is not "loosen the comparison," and the part of it that will rot.

The setup

The harness prepares an exec call before the model runs, freezes it, tells the model to send exactly that object, then compares the model's actual tool arguments against the frozen one. If they differ, the run fails closed. That comparison is the control.

The expectation was built like this — 5bf10ac, scripts/judgment/candidate.mjs:

const expectedExecArguments = validateExecArguments({
  command: `node ${artifactPath('verifier')} ${artifactPath('payload')} ${artifactPath('manifest')}`,
});

One key. From the run receipt, RUN_004_RECEIPT.json, here is what the model actually sent, verbatim:

{"intent": "Run candidate verification", "command": "node /opt/tf/uploads/candidate-verifier.cjs /opt/tf/uploads/candidate-payload.json /opt/tf/uploads/candidate-command-manifest.json"}

Outcome in the same receipt: EXEC_ARGUMENTS_MISMATCH.

Two contracts, and they disagreed

This is the part I got wrong on the first read, and it is more interesting than "the model deviated."

The provider's exec schema — from the compiled artifact I ran, @truefoundry/trueforge-core@0.1.4, dist/core/sandbox/Sandbox.mjs:

var sandboxExecSchema = z.object({
  intent: z.string().describe(
    "A brief, user-facing explanation of the purpose of this command. Avoid technical jargon and code details."
  ),
  command: z.string().describe("The shell command to execute in the sandbox."),
  cwd: z.string().optional().describe("Working directory for command execution."),
  env: z.record(z.string(), z.string()).optional().describe("Additional environment variables to set.")
});

Four fields. intent and command required. cwd and env optional. This is the implementation schema wired into the sandbox exec tool; I am quoting what the runtime accepts, not a tool descriptor captured from the session.

My harness's instruction, scripts/judgment/live.mjs, present before the fix and after it:

'Call truefoundry-system exec exactly once with this exact JSON argument object: ' + ...

At that moment the object being interpolated had one key.

So the model was handed two authorities that disagreed, and it followed the provider's. It satisfied the required-field schema and missed my exact-JSON instruction, because my instruction was asking for something the schema forbade. My comparator saw one difference and reported it as deviation. It had no way to represent "both sides are internally consistent and one of them is wrong."

That is the finding. Not that the model was right — that a mismatch establishes difference, not which operand is authoritative.

The fix, and the part that matters

The tempting repair is to compare less — check only command, ignore extra keys, move on. That makes the failure disappear and takes the control with it. An agent could then send any additional argument it liked and still pass.

What landed instead, in 0220a27:

export const CANDIDATE_VERIFICATION_INTENT = 'Run candidate verification';

const expectedExecArguments = {
  command,
  intent: CANDIDATE_VERIFICATION_INTENT,
};

The intent value is harness-authored and constant, not copied from what the model sent. Copying it would make the comparison check the model against itself.

That commit is titled "Implement adopted transport A and B controls" — the correction rode inside a larger transport change rather than shipping as a dedicated fix. Worth saying, since I am asking you to open it.

The expected-object gate also got stricter:

const argumentKeys = Object.keys(expectedArguments).sort();

if (argumentKeys.length !== 2 || argumentKeys[0] !== 'command' || argumentKeys[1] !== 'intent' ||
    expectedArguments.intent !== CANDIDATE_VERIFICATION_INTENT ||
    typeof command !== 'string' || command.length === 0) {
  failures.add('EXEC_ARGUMENTS_MISMATCH');
}

Three separate things, and only one of them changed:

The expectation was corrected — one key became two.
The expected-object gate got stricter — that block is new.
The actual-versus-expected comparison stayed exactly as it was. It already read:

const actual = parseStrictJson(call.function.arguments);
...
} else if (!canonicalJsonBytes(actual).equals(canonicalJsonBytes(prepared.expectedExecArguments))) {

That line is identical before and after. Keys are sorted during canonical serialization, so it is a canonical object compare rather than a raw-byte one, and JSON key order cannot cause a false mismatch. I did not repair a false failure by weakening the comparator. That is the whole point.

What I fixed is narrower than it looks

The provider's contract: intent and command required, cwd and env permitted.
My frozen run contract: exactly command and intent, nothing else, intent fixed to a constant.

Mine is deliberately narrower. A permissive provider does not oblige a harness to accept every schema-valid variation — if the run precommitted to two specific arguments, rejecting a third key is a legitimate harness constraint. But it is my policy, not TrueForge's requirement, and writing it as though the provider demanded it would be the same error in the other direction.

And here is what is not fixed. argumentKeys.length !== 2 hardcodes two things at once: the provider's current required-field set, and my run's decision to prohibit the optional fields. If TrueForge adds a third required field tomorrow, my harness will reject a model for complying with the new schema unless I edit the harness too. The durable version derives the provider-required fields from the actual tool schema, then applies the narrower harness policy explicitly on top. I have not built that. If you copy this pattern, copy the problem with it.

The check you can steal

1. Where did the expected object come from? If it came from your reading of the API, it encodes your assumptions. If it came from the provider's schema, it encodes theirs. Only one is authoritative about what a compliant call looks like.

2. Does a failing comparison tell you which side is wrong? Mine did not. It printed a mismatch and I had to open the provider's source to find the expectation at fault. A mismatch establishes difference, not which operand is authoritative.

3. When you fix a false failure, does the check get weaker? This is the one that bites. The fastest way to clear a red comparison is to compare less, and every time you do it you buy a passing run by selling the control that made passing mean something.

The general shape: a control that fires wrongly is not evidence the control is too strict. It is evidence that something on one of its two sides is wrong, and you have to find out which before you touch it.

What it cost

Two things, and I want both on the record. I drew the wrong first conclusion about which side deviated. And the run still did not verify — the same receipt carries EXEC_RESPONSE_SHAPE_UNEXPECTED alongside the argument mismatch, and the sandbox turned out to have no JavaScript runtime at all. That half is written up separately.

If you have a comparison sitting between you and a model, go read the schema you are comparing against and check that your expected object satisfies it. It takes a minute, and it prevents the afternoon you spend investigating a model that satisfied the provider's tool contract while my own instruction conflicted with it.

Before: 5bf10ac. Correction contained in: 0220a27. Model arguments and outcome from RUN_004_RECEIPT.json. Provider schema read from the compiled @truefoundry/trueforge-core@0.1.4 artifact in my own node_modules, not from upstream source. The runtime half of this same run is in I Built an Agent That Marked Its Own Finding as Already Known.

The Detector Reported Zero Because It Only Had One Item.

Self-Correcting Systems — Fri, 04 Sep 2026 05:06:35 +0000

Two instructions went into an Auditor my agent collaborators and I built to surface conflicts in agent instruction files. Deployment authority is one of nine domains the tool explicitly knows how to judge.

Never deploy without human approval.
Auto-deploy the moment tests pass.

On main at 172d962, that returns:

posture: low_observed_risk
counts: {"items": 1, "labels": {"governs": 1}, "risk_high": 0,
         "conflicts": {}, "gates": 0, "authority_categories": 0}

low_observed_risk is the product's own string, from agents/report_writer.py:110. Not my summary of the output. The output.

One item. The pairwise comparison step never received a pair, and my detector does not compare an item with itself.

After the repair, same input, live service:

{
  "severity": "high",
  "item_id": "M001, M002",
  "type": "authority_collision",
  "finding": "Conflicting governing instructions in deployment: require_human_approval vs allow_automatic.",
  "evidence": "Never deploy without human approval. | Auto-deploy the moment tests pass."
}

posture: needs_review. Two items, one high-severity collision, one verification gate.

The difference between those two outputs is that two lines were touching.

Where the failure actually was

Before anything compares instructions, something has to split the text into separate instructions. Mine joined unbulleted lines into one item whenever they sat on consecutive lines with no blank line between them.

The join is in the tool's first commit, b71892d, authored 2026-06-01 13:06:47 -0400, at agents/memory_extractor.py lines 50–51:

content = " ".join(part.strip() for part in pending_paragraph if part.strip())
if len(content) >= 36:

Both defects in this article are on those two lines, and they have been there since the first commit. Three months.

Zero findings was an answer about a collapsed population. The pairwise loop behaved exactly as written. It never got a pair.

I have been publishing about this class of defect for three months: a count of zero means nothing until you know what reached the counter. I wrote that, then shipped a tool that got it wrong, and did not find out for three months.

How wide the defect actually was

The detector knows nine domains: deploy authority, secrets handling, database source of truth, access scope, customer response, log retention, billing records, refunds, escalation. All hand-written.

(Seven live in a stance table you can read in one glance. Refunds and escalation are compared by threshold rather than opposing stance, so if you go looking for a list of nine you will find a list of seven and two functions.)

The precise scope, because the wider version is wrong: any pair whose two sides were written as adjacent, unbulleted lines with no blank line between them could be collapsed before comparison, in any of the nine domains. That is not "the nine domains were disabled." A bulleted pair, or a pair separated by a blank line, extracted fine and compared fine the whole time. The vulnerable thing was a writing shape, not a domain.

My own commit message on the repair says it worse than this article does — that consecutive lines "silently disabled conflict detection" across the nine domains. That wording is too wide. I am correcting it here rather than rewriting the commit.

Three things about the repair worth more than the repair

One: the tests were themselves tested.

The repair added seven regression tests. Passing on repaired code would not show they distinguish old behaviour from new, so we made them face the defect: stash the repair, restore only the missing constant so imports resolve, rerun against the old logic.

Four of the seven failed. Real behavioural failures, not import errors.

But four red lines are not four proofs, and the reasons matter more than the count:

Test	Fails on	Is that the defect?
`adjacent_instructions_do_not_merge`	`assert 1 == 2`	Yes. Two lines glued into one item.
`enumerated_domain_still_produces_a_real_collision`	`assert []`	Yes. No pair survived, so no collision could fire.
`short_high_risk_instruction_is_not_silently_discarded`	`assert 0 == 1`	Yes — but only because the injected constant is `12`. Inject `36` and it dies on `assert 36 <= 16`, failing on the constant before it ever reaches the discard.
`governing_instruction_..._reports_uncovered_domain`	`assert 'uncovered_domain' in set()`	No. Old `main` has no `uncovered_domain` in the detector at all. That failure is missing new code, not collapsed extraction.

Two of these four prove the extraction bug. One proves it only under the right constant. One does not prove it at all. A negative control whose failures fail for the wrong reasons is the exact defect this article is about, so I would rather print the table than let four red lines carry more weight than they earned.

Two: the first deploy succeeded on the wrong tier.

gcloud reported the truth: the web service deployed and served 100% of traffic. Accurate. I read it as meaning the behaviour had changed. It had not.

The web app is a router. Extraction runs in memory-extractor-agent, a separate Cloud Run service. The revision timestamps are the receipt:

memory-authority-auditor-web-00003-82f   2026-09-02T13:17:10.714842Z
memory-extractor-agent-00002-grk         2026-09-02T13:31:32.807334Z

Fourteen minutes and twenty-two seconds in which a correct success message sat on top of unchanged behaviour. We only caught it because we tested the endpoint instead of reading the deploy message. Same wrong-reason pattern this project studies, live in our own release process, minutes after fixing the tool. The receipt was not false. My reading of what it covered was.

Three: I added an absence instead of a domain.

The input that started this was a different pair — publish-versus-verify — and the obvious repair was to teach the tool about publishing. We did not.

Tuning a ruleset to the case someone just handed you proves only that it catches the known case. So the detector now emits uncovered_domain when a governing instruction matches no rule at all:

This instruction governs action but matched no contradiction rule, so it was NOT evaluated for conflicts. Absence of a conflict here is absence of a check, not evidence of agreement.

Before, no conflicts and never checked rendered as the same sentence. Now they do not.

The original pair still is not solved, and the live output says so

Here is the input that started this, run against the repaired live service:

"items": [
  {"id": "M001", "text": "Current policy: verify the live artifact before publishing."},
  {"id": "M002", "text": "Old note: publish immediately without checking."}
],
"classifications": [
  {"id": "M001", "authority_label": "governs",      "confidence": 0.78},
  {"id": "M002", "authority_label": "context_only", "confidence": 0.64}
],
"conflicts": [
  {"severity": "medium", "item_id": "M001", "type": "uncovered_domain",
   "finding": "This instruction governs action but matched no contradiction rule, so it was NOT evaluated for conflicts."}
]

posture: usable_with_gates. Extraction is fixed — two items, correctly split. It is still not an authority_collision, and it never will be until publishing becomes a listed domain.

And there is a second gap in that JSON I did not know about until I pasted it for this article. M002 is classified context_only at confidence 0.64. "Publish immediately without checking" is an imperative, and the classifier does not consider it strong enough to govern. So the uncovered_domain warning fires on M001 only. The half of the contradiction that tells you to skip the check gets no warning at all, because context_only items are not eligible for one.

The extraction repair is real. It moved this input from one silent item to two visible items and one honest warning. It did not make the tool right about this pair.

What is fixed and what is not

Fixed: finished, unbulleted instructions on adjacent lines no longer merge when the first line ends in terminal punctuation. The minimum item length dropped from 36 characters to 12, because the old floor silently discarded the unbulleted instruction Delete all logs. — sixteen characters, high risk, dropped with no record. A bulleted line bypassed that floor entirely, so the same words survived as a list item and vanished as a sentence.

Not fixed, with the receipts:

A standalone unbulleted fragment under 12 characters still disappears with no record. Wipe logs. is ten characters and returns zero items. So does See above. — the floor does not distinguish a command from a cross-reference, it just deletes both.
The split now over-fires on hard-wrapped prose. I previously claimed wrapped text was safe because wrapped lines do not end in terminal punctuation. That is a bet on wrapping, not a proof, and here is the counterexample: "Escalate to the on-call engineer within 15 min.\nThen page the team lead if unresolved." is one two-step escalation procedure and the repair returns it as two independent items. Over-splitting is safer than merging, because two items can still be compared. It is still wrong.
Still only nine conflict domains. A governing instruction outside them produces uncovered_domain, which names the gap but not the conflict. A context_only item outside them produces nothing at all — see M002 above.

Reproduce it

Both hostnames for the live app route to the same service; I checked with the same payload and the responses are identical, so there is no stale tier to trip over.

The repair is public as a branch, not on main: beae0bb on fix/extraction-merge. Three files, 146 additions and one deletion. main is still 172d962 and still carries len(content) >= 36, so a default clone gets the defect. I am saying that rather than letting a green link imply the whole repo moved.

Suite on the branch: 107 passed, 1 skipped, 1 xfailed in a clean clone. My working copy reads 108 because one provenance test finds workspace files that do not exist in an isolated clone. The clone number is the honest one to print next to a clone command.

Run the negative control:

git clone https://github.com/keniel13-ui/memory-authority-auditor
cd memory-authority-auditor
git fetch origin fix/extraction-merge
git checkout FETCH_HEAD -- tests/test_extraction_boundaries.py

# Restore only the constant the new tests import, so collection succeeds.
# The old extractor below still uses its own literal >= 36 logic.
python3 - <<'PY'
from pathlib import Path
p = Path("agents/memory_extractor.py")
t = p.read_text()
assert "def extract_memories(" in t
p.write_text(t.replace("def extract_memories(", "MIN_ITEM_CHARS = 12\n\n\ndef extract_memories(", 1))
PY

python3 -m pytest -q tests/test_extraction_boundaries.py

4 failed, 3 passed — with the caveats in the table above.

Why this matters past one tool

Agent instruction files accumulate rules written at different times by different people. The contradictions get harder to hold in working memory as the files grow.

The reason to build a tool like this is to help a human stay the operator — to make a growing instruction set easier to inspect, not to replace the inspection or certify that nothing was missed.

Which means a tool in that job needs the same scrutiny it applies. Ours did not get it for three months, and the thing that finally found it was not the suite. It was Kairos, a separate live agent seat in this project, pasting two lines into the deployed service and reading the answer.

Go break it

It is live and it takes text: https://memory-authority-auditor-web-qfppqeeedq-uc.a.run.app

Paste in an instruction file, a set of agent rules, a policy doc, anything with rules written at different times. No signup. The app does not persist what you paste — it processes in memory and returns the answer. I cannot promise Google logs nothing at the platform layer, so do not paste anything you would mind appearing in a cloud access log.

What I want is the case it misses. Two instructions that clearly contradict, where it returns low_observed_risk or uncovered_domain instead of a conflict. I already know four shapes that beat it, and every one of them is in this article: anything outside the nine domains, any unbulleted fragment under twelve characters, any imperative the classifier rates context_only, and any procedure hard-wrapped after a period. There will be more. The one that started this survived three months and a green suite.

Post what you gave it and what it returned. A miss is worth more to me than a hit.

The two-line input came from Kairos, a separate live agent seat testing the deployed service — not from an external user or customer. Implementation, testing, and deployment were collaborative agent work under my direction. None of the pre-existing tests exercised that input shape.

One correction about my own commit, since I am asking you to read it. The repair commit message and the regression-test docstring both say the defects were *"found by an outside reader."** That was imprecise. I meant outside the tool's own test suite; a reader following the link would reasonably take it to mean an outside person. It was not. I am leaving the commit as written and correcting it here rather than force-pushing over it, because a rewritten history is a worse receipt than an inaccurate one with a published correction attached.*

I Followed the Appeal Path. There Was No Appeal.

Self-Correcting Systems — Tue, 01 Sep 2026 02:45:49 +0000

This is part four of the Defender Access series. Each part is standalone, but here is the thread if you are landing here cold:

Part one — OpenAI says verified defenders get more access, so I preregistered a study to test it, and published the design and its outcome table before running anything.
Part two — they matched the published slogan. The decision lived in the undefined white space between the rules.
Part three — my own suite was green while four binding controls had never established their claims.
Part four, this one — the study cannot run, and the reason is worth more than the numbers would have been.

Part two set a condition for continuing, and part three quoted it rather than paraphrasing it. I am going to do the same thing:

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.

A live result arrived. It is not the result the series was designed to measure, and I want to be exact about that before anything else.

This part does not report an uplift measurement. The study announced in part one compares what a verified defender account can do against a control account. That study did not run and, through this route, it cannot run. What I have instead is a measurement of something one layer up: whether the treatment arm is reachable through the gate in front of the study. Through this route, it is not. Two dated records expose the gap: the denial directs a mistaken applicant to Support, while Support says it cannot explain or reverse the result, and that the verification process offers no retry or appeal.

The timeline

Every line here is a timestamped email in my inbox. I am redacting my organization ID and my address and nothing else.

When (UTC)	From	What it said
2026-08-11 01:20:19	Persona	"Verify your business to join OpenAI's Daybreak* access program"*
2026-08-11 01:20:20	OpenAI	"Thank you for your request" — subject line OpenAI Pilot: Trusted Access For Cyber
2026-08-11 23:45:16	Persona	"Persona was unable to verify your account for OpenAI's Trusted Access for Cyber program."
2026-08-31 06:16:33	me	the appeal, to `support@openai.com`
2026-08-31 06:17:14	OpenAI Support	Case 14067641

Two things about that table before the substance.

The first two rows are one second apart and give the program two different names. Persona calls it Daybreak. OpenAI calls it Trusted Access for Cyber. The support reply at the end uses both in one sentence. That is cosmetic and I mention it only because it is the first visible sign of different naming conventions across the handoff.

The last two rows are forty-one seconds apart. I will come back to that.

The two sentences this part exists for

The denial, in full, is four lines long. Here is the operative one:

"If you believe this was a mistake, please contact OpenAI support at support@openai.com."

That names a channel and the condition under which to use it. It does not say what the channel can do once you get there. I believed it was a mistake, so nineteen days later I used it. I asked two narrow questions: what documentation does the verification step accept, and should I reopen the existing request or file a new one.

The answer:

"For Trusted Access for Cyber / Daybreak, if Persona verification fails or is denied, Support can't manually override it or provide additional details on the specific result, and verification currently doesn't support retries or appeals."

Read those two quotes next to each other. The denial routes you to a desk. The desk says it cannot override the result, cannot tell you why the result happened, and that the process has no retries and no appeals.

And there is a sentence in OpenAI's own organization-verification documentation that sharpens this into something better than a complaint:

"If retries or appeals are available for your verification flow, the notice or product experience will explain the next step."

That establishes the positive case, and only the positive case: if retries or appeals are available, the notice or product experience is where the next step will appear. It does not obligate a notice to announce their absence, and I am not going to pretend it does.

What it does let me say precisely is this. My notice named Support. The current Daybreak documentation separately states that this flow has no retries and no appeals. What the notice did not say is that the Support route it named could not become an appeal. The information existed in one place and the referral existed in another, and the applicant is left to reconcile the two.

The broad version of this complaint is wrong, so let me kill it first. Support is real and it does real work: technical failures, stuck verification status, access troubleshooting. It is implemented.

What is not implemented is any recourse after a denial. The three things you would go to that channel for once you have been denied — reversal, explanation, another attempt — are all ruled out by the reply, but for two different reasons and by two different owners. Support cannot explain or override the result. The verification process offers no retry and no appeal.

The support channel existed. Recourse did not. The denial pointed at the first without disclosing the absence of the second.

The cost of that is not all theirs, and I want it attributed properly. The referral gave me reason to believe contacting Support might produce recourse. It never told me to wait. My own experimental rule is what turned that belief into a nineteen-day delay — I would not write until I thought the estimand was safe. Two costs, two owners.

This series has spent three parts on one idea, and it is a rule I work under: a rule that depends on someone choosing to perform it is a request, not a control. mansio pushed it somewhere I had not taken it, in a thread on a different post: relying on a prompt instruction delegates system integrity to the model being evaluated.

What I have here is the mirror image of both. A referral that names a channel without naming its limits is a notice, not a remedy. It has the grammar of recourse without saying that recourse is not among the things on offer.

About those forty-one seconds

The reply arrived forty-one seconds after I sent the appeal, and it says so itself:

"Hi Keniel — I'm AI-assisted support for OpenAI."

and closes with:

"This response was generated with AI support which can make mistakes."

I am not going to tell you a human refused me, and I am not going to tell you no human read it either. I cannot establish that. What I can establish is that the reply arrived forty-one seconds after I sent mine, identified itself as AI-assisted, and disclaimed its own accuracy in the same breath. Whatever human involvement there was or was not, the answer I received is one that says it can be wrong.

The disclosure limits what the forty-one-second reply can establish on its own, and it no longer has to carry the policy claim by itself. OpenAI's current Daybreak documentation states independently that Support cannot override a verification result or provide additional details about why a specific result occurred, and that verification does not support retries or appeals. Its FAQ puts it in one line: can support change a verification result? No.

One caveat I have to state, because it is the same defect this series keeps finding. That is a current page, not an archived copy from August 11. It tells me what the policy is now. It is not evidence of what the policy was on August 11, when I was denied, and I have no archived copy of the page as it stood that day. So the division of labour is: the email establishes the speed and wording of what I was told, the documentation establishes the policy as it currently stands, and neither establishes the policy at the moment of the denial.

Which leaves the thing this whole series keeps arriving at: there is no observer downstream of that decision that I can reach. Nothing in the record available to me distinguishes an AI-only response from one a human touched. OpenAI may well have internal routing or audit data that settles it. I am not claiming their systems cannot know. I am saying the applicant cannot, from what the applicant is given.

What was actually checked

Here is the part that changes what I am allowed to claim.

I do not know which checks determined my denial.

Persona is an identity and business verification vendor. The support reply describes what the step generally expects:

"information that matches official records (legal business name, registered/operating address + contact info, and sometimes a tax ID/business registration number) plus clear, complete, current official business documents"

Legal name. Registered address. Tax ID. Business registration number. Not one of those fields is about security research. Nothing in that list asks what I defend, what I own, what I have published, or whether my intended work is authorized.

That was Support's abbreviated description to me, and I should not let it stand in for the whole process. OpenAI's current organization-verification documentation is wider than that email: it also asks for accurate information about your organization's activities or intended use of OpenAI, and says the review may include document verification, and compliance or risk screening. So the claim I can defend is narrow and specific — the list I was given did not assess security research — not the broader claim that nothing anywhere in the application ever does.

And here is the part I have to state carefully, because this whole series is about people claiming causes their receipts do not carry.

I cannot establish why Persona denied me. The process withholds that reason by policy — Support said so in the same message. What I can establish is that Self-Correcting Systems is not a registered company. It is me. No LLC, no incorporation, no tax ID, no registered address, no filing of any kind. So I am missing exactly the records Support says the flow generally expects, which makes the absent entity my strongest available explanation and not a proven cause.

I own primaworkflows.com. Controlling a domain is not a substitute for legal entity records, and I would not expect it to satisfy a check asking for a registration number.

A business-registration gate is a legitimate control. If you are handing out elevated cyber capability, tying it to an accountable legal entity is a defensible design and I would probably build it that way too. My complaint is not that the gate exists.

My complaint is what the applicant is left holding. The program is described in terms of trusted defenders. Support's reply foregrounded business records. Those may not be the criterion the program name implies, and I have no way to find out, because the result arrives with no reason attached and the channel that could explain it is documented as unable to. Whatever the gate actually evaluated, it did not tell me, and an applicant who cannot see which criterion was applied cannot distinguish a considered rejection from a records lookup that came back empty.

What this does to the experiment

Part one published the design's outcome table in advance, including the failure branches. One of them reads:

Approval arrives before a valid T0 → primary estimand is lost; post-only observation.

The design anticipated approval being late. It anticipated entitlement being unclear. It did not enumerate a branch where the applicant fails the verification gate before the treatment arm can be provisioned, and that is now the branch I am in. OpenAI describes verification as helping evaluate whether a request qualifies, so this was an evaluation. It is simply not the evaluation the study was designed around, and it terminates before the study can begin.

So, plainly, for the record and for anyone who was following along expecting numbers:

The treatment arm cannot be provisioned through this route. No approval, no retries, no appeals.
T1 does not exist and will not under this preregistered route. There is no post-treatment measurement because there is no treatment.
The uplift study announced in part one is terminated, not paused. Reviving it would require a different route to eligibility, and I do not have one.
Part one's ceiling was already an N-of-1 case study with entitlement confounded with account identity. That ceiling is now moot. There is no arm to confound.

The rule I held the appeal under was that sending it early could contaminate the before/after comparison. There was no after to protect. I would rather say that plainly than let the timeline imply I was being disciplined.

What I would tell you to take from this

If you are building an access gate, one line:

Name what the channel can actually do for the situation you are naming it in. Support does real work, and none of it is recourse after a denial. One sentence in that notice would have told me so, and its absence is what nineteen days of mine were spent on. The delay is mine. The missing sentence is theirs.

If you are on the other side of a gate like this, two things I did not know before:

Find out who is actually checking you, and accept that you may not be able to. The program name on the door and the vendor doing the verification can be evaluating different things. I assumed a cyber program was assessing my security work. The support response I received foregrounded business records, and it arrived only because I asked a question that was almost about something else. OpenAI's current documentation is broader than that answer: it also names organizational activities or intended use, and compliance or risk screening. What I still cannot recover is which of those checks actually determined my result.

A denial with no stated reason is not a judgment you can read. I spent some of those nineteen days reading it as one. It might have been. It could also have been a records lookup that came back empty. The point is that the format gave me no way to tell, and I filled the silence in myself.

The series, in order: *part one** (the preregistered design, which DEV featured on August 18 for announcing the instrument this part reports could not be run) · part two (the decision lived in the undefined white space) · part three (a green suite over four unestablished controls) · part four, this one.*

The email quotations above come from five dated messages in my inbox: two from no-reply@frompersona.com, one from noreply@openai.com, one from support@openai.com, and one I sent. Quotations from OpenAI documentation come from the two Help Center pages linked below. I am not publishing the raw messages — they carry my organization ID and address — so the quotes are on my word and the timestamps are what I would produce if anyone wants to check the intervals. The forty-one second reply identifies itself as AI-assisted and states it can make mistakes. Its central claim does not rest on that message alone: OpenAI's own published Daybreak troubleshooting documentation states that Support cannot override a verification result or disclose its specific reason, and that verification currently supports neither retries nor appeals. API organization verification · Daybreak troubleshooting

Remember CLAIM-24? Here's what happened.

Self-Correcting Systems — Mon, 31 Aug 2026 03:27:16 +0000

This is the CLAIM-24 result. If you followed that series in June and then watched it go quiet, this is what happened in the eleven weeks since.

The timeline, with receipts

2026-06-04 → 06-14. Nine posts, CLAIM-24 through CLAIM-31, published in eleven days. The last one was The Rule Held. The Boundary Moved Up. on June 14. Then nothing, for eleven weeks.

2026-06-07. I opened tacoda/keystone#4 asking whether Cell 7 could be tested against a real signing API instead of a mock. That thread is public, it now has forty-one comments, and everything below came out of it.

2026-08-05 12:12Z. An independent breaker reproduced a cross-origin credential-forwarding path offline, using a sentinel value and a cross-origin Location. The sentinel crossed. No live credential ever did. Breaker verdict

2026-08-05 → 08-06. Live baseline captured. Mandate narrowed through the real API. A defect surfaced: my parser required ISO 8601 timestamps, the API returns Unix seconds, and twenty-two passing tests never caught it because my fixtures carried the same assumption I did. Repair commit.

2026-08-13. POST /mandate came back with a Cloudflare 1010, browser_signature_banned. The cycle stopped at issuance. No mandate, no CAPTURE, no PATCH, no EVALUATE.

2026-08-14. The default Python-urllib/3.13 user agent emerged as the strongest lead, one of the most commonly flagged signatures in bot detection. A lead, not an established cause.

2026-08-16 17:35Z. The provider confirmed in writing that nothing had changed on their side.

2026-08-19. The controlled cycle ran once. POST /mandate returned 201. CAPTURE 200, PATCH 200, EVALUATE 200. One attempt per stage, no retry, no redirect follow.

2026-08-20 10:41Z. Key revoked by the issuer, on the record.

What that does and does not establish

It establishes that the route opened and the full cycle completed against a live external API.

It does not establish why. Three days sit between the provider's written statement and the run, and nobody controlled that window. The receipt that binds the 201 does not carry the User-Agent, so it cannot testify about its own independent variable. The result is labelled CONTROLLED_EXTERNAL_API_FIXTURE because the project authored the PATCH, which makes it a fixture rather than independent lifecycle evidence.

Cell 7 is not closed. This is the live result the series was waiting on, and it arrives with its ceiling attached rather than as a conclusion.

The rest of this piece is the part I think is worth more than the 201: what the two defects in my own code actually were, and why my own test suite could not have found either one.

I had twenty-two passing tests and two separate reviewers on a piece of code. None of it objected. Then I pointed it at a real API owned by somebody else and it broke on the first live read.

The mismatch fit in one sentence: my parser required ISO 8601, the documented API returned Unix seconds. The repair was not one line. It touched five files, 74 lines of parser and 52 lines of tests. The assumption was small; making it safe was not.

Here is why nothing caught it, and it is the part worth keeping:

My tests used ISO because my code used ISO, so they agreed with each other and never checked reality.

The fixtures were written by the person who wrote the parser. They encoded the same assumption. The suite confirmed internal behaviour without ever challenging the ISO assumption, because both halves of it came from one head. Internally consistent is not the same claim as right, and nothing in that suite could tell the difference.

Two separate reviewers missed it too. I cannot prove why, and I am not going to invent a reason. What I can show is that the parser and every fixture encoded the same ISO assumption, so none of the artifacts in front of anyone supplied the live contract that contradicted it.

The second one was worse

Working against a real system made redirect containment matter, so an independent breaker went at it. In Python 3.13 the default redirect handler rebuilds the redirected request from req.headers, dropping only content length and type. My X-API-Key sat in that header set, so the redirected request inherited it. Python has Request.add_unredirected_header() for exactly this, which marks a header as one that will not be added to a redirected request. I was not using it. The breaker reproduced it offline with a sentinel value and a cross-origin Location, and the sentinel crossed.

No live FIPSign credential was ever shown to have crossed an origin. The defect was real and unshipped. I did not find it by auditing my own code, and I did not find it myself — the live integration made the question worth asking, and a seat that was not mine answered it.

What it takes to actually get that

On 2026-06-07 I opened an issue on tacoda/keystone, an agent charter framework, asking whether a narrow adapter test was possible against a real signing API. FIPSign (mobydickfinance) said yes and then did something I did not expect: he handed over disposable API keys, rotated them on request, and stayed in that thread for ten weeks.

The collaboration produced a block I could not explain. POST /mandate came back with a Cloudflare 1010, browser_signature_banned. That stopped the cycle at issuance: no mandate was created, and CAPTURE, PATCH and EVALUATE never ran.

I could have guessed. He didn't let either of us do that. His reply:

Checked both questions directly, not from assumption.

Then he listed what he actually did. Reviewed the CORS and origin handling in the Worker source and confirmed server-to-server calls authenticated by API key never enter that logic at all. Checked Bot Fight Mode specifically. Compared the public guide field by field against the real request validation in the backend — length limits, scope counts, budget types, expiry bounds, required headers — and confirmed nothing was undocumented. Then ran POST /mandate himself from PowerShell on a residential Windows connection and got a clean signed mandate back.

Both of my hypotheses were dead. It was not the CORS or origin policy I suspected, and it was not a missing requirement in the docs.

What he asked me for next is the part I want other people to steal:

the exact timestamp · the HTTP client/library + version · whether the request went through any proxy or VPN · what kind of network you are running it from — home connection, cloud VM, CI runner, corporate network

With the note that hosting-provider IPs get scored very differently from residential ones, independent of the client library.

I gave him the client. Python-urllib/3.13.

that's the default, unmodified user agent for Python's urllib, and it's one of the most commonly flagged signatures by automated bot detection precisely because so much low-effort scraping traffic uses it unchanged.

Then, before I spent another key:

if you set a real user agent on your client, I'd bet that alone resolves it. Worth trying first — cheap to test.

If you are hitting an endpoint from a script and getting bot-flagged for no visible reason, check what user agent your HTTP library is sending by default. You probably never set one. That is a five-second check and it is the most portable thing in this entire post.

The part where I refused the result

One seat added the header, an independent seat confirmed it was present in the request urllib assembled for transport, and I authorized a single controlled cycle that a separately assigned firing seat executed once. POST /mandate returned 201. No 1010. CAPTURE 200, PATCH 200, EVALUATE 200. One attempt per stage, no retry, no redirect follow.

That is the clean story: header missing, endpoint blocked, header added, endpoint opened.

I am not going to tell you that.

FIPSign's operator had confirmed nothing changed on his side — Bot Fight Mode off then and off now, never toggled, a Browser Integrity Check rule drafted during the investigation but never deployed. That statement is dated 2026-08-16 17:35Z. The firing seat ran the controlled cycle on 2026-08-19.

Three days sit between a written statement about a provider's configuration and the run that depends on it. He was not being careless and neither was I. But nobody controlled that window, so a success is attributable to the header only as far as that statement reaches. One run, one header, three days later, is not causation. It is a result with an uncontrolled gap in front of it.

And then the worse gap, which was mine

That run's issuance receipt contains no User-Agent field at all.

The entire point of the run was the header. A narrative receipt written afterwards names it. The artifact that binds the 201 does not. The two share a run id, so software can associate them, but the User-Agent assertion sits outside the sealed receipt chain rather than inside it. A reader holding the artifact that binds the 201 still cannot recover which user agent produced it.

We built the capture afterwards — it records the configured value, the mapping handed to the transport, and what urllib assembled after add_header, three witnesses at three different strengths, none of them TLS-level and none of them the edge's view. It exists because the previous run could not testify about its own independent variable, which is not a good reason for a thing to exist.

The route opened. The experiment did not establish why. The receipt did not bind the one variable that was supposed to explain the change. That is a worse failure than the block was.

The result carries CONTROLLED_EXTERNAL_API_FIXTURE on its face. The project authored the PATCH, so it is not independent lifecycle evidence and I will not present it as any.

What the ten weeks were actually worth

Not the 201. The 201 is a fixture with a disclosed ceiling.

What it was worth was two defects in my own code, found by two different paths, and collapsing them into one lesson would overclaim what the receipts show.

The timestamp mismatch survived twenty-two green tests and two separate reviewers because the parser and every fixture carried the same wire-format assumption. The live response is what contradicted it.

The redirect defect was different. It survived a green local suite and was found by an independent breaker attacking the adapter with a sentinel value, before any live credential could cross. One was reality contradicting my fixture. The other was an adversarial seat asking a question my tests had not asked. One of them was a cross-origin credential-forwarding path.

His closing note put it plainly, and he is right:

it says something good about testing against a live system instead of only mocks.

For an external wire contract, a fixture you invented from your own reading of someone else's docs cannot independently validate that reading. My suite could not challenge the ISO assumption because every fixture already carried it.

Reality is a better adversary than your fixtures. It is not a substitute for a receipt.

Thread is public: tacoda/keystone#4, opened 2026-06-07, forty-one comments when audited on 2026-08-30. Every quote above is from it. **The sanitized run receipt for 2026-08-19 is not currently public* — it is credential-adjacent and has not been through a publication scan, so the User-Agent gap described above is stated on my word rather than something you can open. I would rather say that than imply a receipt you cannot read. The keys used for the Mandate runs described here were disposable, delivered privately, reported spent, and revoked by the issuer.*

Tell Me About You

Self-Correcting Systems — Sun, 30 Aug 2026 19:05:28 +0000

After sixty-seven published posts here, the comments have become one of the best parts of the work. Some of you have run my code, found things I missed, challenged a claim, or brought me a project of your own. I also want to distinguish bots from real people.

I know some of you by the exact problem we were discussing. I still do not know what many of you are building, learning, enjoying, or trying to become outside that thread.

So this post is different. I am going to introduce myself first, and then I want to hear about you.

If we have never spoken before, you are welcome here. If we have spoken ten times already, you are welcome to introduce yourself again. Tell me something I do not know yet.

Who I am away from the terminal

Basketball is a real part of my life. On September 12 I am one of the official coaches at the Hugo Gonzalez Basketball Camp at Brandeis University in Waltham, Massachusetts. Hugo plays for the Boston Celtics. The brief the coaches were given is the part I liked: treat every player like they are your own kid, and no phones. That is genuinely one of the cooler things I get to say right now. Basketball was my first love i never played college or anything like that so i don’t wanna give the wrong impression either basketball is just a passion.

I play PokeMMO, but only for PvP. I think of it as modern-day chess. You are not just reacting to the board in front of you. You are playing several turns ahead of someone who is trying to do the same thing to you. You have to hold a model of what they think you are about to do, then decide whether to follow the obvious line or break it.

That way of thinking is connected to everything else I work on. I expect the world to become much more automated, and I want to build now for the decisions I will need to understand later. I would rather learn how the machine reaches a conclusion than wait for a future where its decisions simply happen to me.

I did not arrive here through scholarship or credentials. I am someone who genuinely enjoys learning, testing an idea, being wrong, and trying again with better evidence.

What I hope to build

The long-term idea is Self-Correcting Systems.

The goal is not a machine that never fails. It is a machine that can notice when reality differs from what was expected, examine the anomaly, explain what it can and cannot establish, and help correct course without quietly hiding the failure from the person operating it.

That asks machines to handle pieces of the critical judgment humans use every day: noticing that something feels wrong, comparing it with prior experience, changing an interpretation, and knowing when confidence is not enough. I know how far away that goal is. I am not claiming to have built it. I am telling you what all of this work is pointed toward.

The next major system I want to develop is for cybersecurity. I expect the machinery underneath it to become intricate, but the controller has to remain understandable enough to operate almost like a video game. Complexity underneath cannot become confusion at the surface. If I cannot see what my own system observed, what it inferred, what it changed, and what authority it used, then I am no longer operating it. It is operating me.

One day I want to build a company around this with people who think similarly: ambitious about what machines can become, skeptical of claims that outrun evidence, and serious about keeping humans able to understand and control what they create.

How I actually work with AI

I do not work with one assistant that agrees with everything I say. I use multiple AI agents in separate roles, and they are expected to challenge one another and challenge me.

We try to work under a constraint system called the Drift Gauntlet:

Close the current loop. Do not escape into a new lane before the current one produces a real outcome.
Make something touch the world. A reply, a test from another machine, a shipped artifact, a yes, or a no teaches more than another private plan.
Require a real edge. “The AI will figure it out” is not a mechanism.
Do the work before studying the idea of the work. Research cannot become a hiding place from execution.
Record the receipt. If the result is not preserved, nobody can learn from it or challenge it later.
Name the grandiosity. A huge future goal does not excuse skipping the next checkable step.

The gauntlet is supposed to be blind to rank. My own named failure mode is impulsiveness: moving before I fully understand the practical use of what we are doing. One agent tends to skim and answer the last part of a problem. Another tends to over-produce and build more than the loop requires. We name those failure modes in advance because they rarely feel like mistakes while they are happening. They usually feel like working hard.

This is not a perfect automated control. We still violate it. While this post was being built, one agent concluded that an unpublished draft was a forgotten article because its sentences barely overlapped with anything already live. Another agent opened the live article and found that the same thesis, commands, hashes, and public request had already been published two weeks earlier. The first agent withdrew the draft.

That is the workflow at its best: disagreement is welcome, but the live object gets the final word.

Now I want to hear about you

Who are you?

Tell me whatever you are comfortable sharing:

what you are building, studying, or trying to learn
a problem you cannot stop thinking about
a hobby that matters to you
something you are proud of
a project link, if you have one
or simply what brought you to this corner of the internet

You do not need a project. You do not need a repository. You do not need to be technical. There is no required level of experience, and this invitation is not reserved for people I have never met.

If you are a real person leaving an honest introduction, I will follow you back. The point is not to trade numbers. I want my feed to contain more people I have actually heard from and fewer accounts that are only numbers on a screen.

So whether this is our first conversation or our twentieth: what is one thing you would like me to remember about you?

My Commit Said "Stop Trusting the Receipt." That Is the Commit Where the Trusting Started.

Self-Correcting Systems — Sun, 30 Aug 2026 07:04:02 +0000

On 2026-08-25 at 21:27 EDT I pushed this to self-correcting-integration-maintainer:

fix: repair the four re-review findings; stop trusting the receipt

The message is accurate. It closed four real findings from an automated review. It is also the commit that added this line:

const recomputed = decide(receipt.checks, receipt.deciding_fields);

The second argument is the receipt's own claim about which fields it should be judged on. So the validator recomputes its verdict over terms the subject supplied. A receipt carrying failing checks plus deciding_fields: [] recomputes over nothing, finds nothing failing, and validates clean.

Absence reading as a pass, inside the fix for absence reading as a pass.

The reviewer flagged it at 21:30:49 EDT. Three minutes and twenty-five seconds. (The finding's original_commit_id is 4a8e6c9; GitHub now displays it against the later head 5d053c17, which is why the timestamps are worth stating rather than the UI position.)

The part that is not a bug story

The commit message is not a lie. It closed four findings. It just names the opposite of what the diff did on one line.

An audit by commit message passes this. An audit by diff summary passes this. A reviewer reading "stop trusting the receipt" has been told the answer and will read the diff looking for confirmation of it. Only following the data catches it.

That is the condition I did not have a name for before: a repair arrives carrying the credibility of a repair. It closed something real, it was reviewed, and it says so on the tin. That is precisely when nobody looks at it twice.

Readers named the class, not the commit

On 2026-08-24 I published a piece about a contract that permitted the contradiction its tests were passing. Two commenters went past the instance.

pm25coder, the same day:

"Every repair moved authority to something 'better typed,' and the third contract's authority field is itself a derived value one level down."

He was describing a different project — a grant-expiry contract in a Python file, not this repository. He named a class: authority migrates one level down and the subject ends up supplying the terms it is judged by.

The chronology is checkable end to end. His comment posted 2026-08-24 at 09:41 EDT. GitHub says this repository was created 2026-08-25 at 19:47:38 EDT. 4a8e6c9 landed at 21:27 EDT that same night — one hour and forty minutes after the repository existed, in JavaScript rather than the Python he was reading, with a message claiming the opposite of what it did.

I want to be exact about the credit, because getting it wrong would be the same defect one more time. He did not predict this commit. He named a failure class, and the class recurred. That is more useful than prophecy and it is a weaker claim than prophecy, and the difference matters.

anp2network went at the method rather than the instance, and I will come back to that.

The same class on 2026-08-29, in prose

On 2026-08-29 a submission document carried a stale count of review comments. The number had shipped wrong twice already. The correction read: "37 inline review comments across six merged pull requests."

Arithmetically right when written, and self-invalidating as a complete-set claim. Merging it creates a seventh merged pull request while the sentence still defines the universe as six. The total would have stayed 37 — PR #6 carries zero inline comments under the same endpoint — so the number never goes wrong. The set does. The denominator named every pull request except the one doing the counting.

Caught before merge by a second seat, not by anyone checking the arithmetic. The wording that shipped names the measured set instead:

Across the six pull requests merged before this correction (#1, #2, #3, #4, #5, #7), Qodo authored 37 inline review comments as of 2026-08-29.

Merged as 3ee11d1. Recomputed after the merge: still 37.

Same shape as the commit above, moved out of code and into a sentence: an artifact supplied the terms of its own completeness. Three attempts had fixed the arithmetic. The number was never the defect — the measurement boundary was.

Status of the repair, stated honestly

The current line freezes the terms in the consumer and demotes the receipt's copy to evidence:

export const CANONICAL_DECIDING_FIELDS = Object.freeze(['node', 'trueforge', 'sdk']);
...
const recomputed = decide(receipt.checks, CANONICAL_DECIDING_FIELDS);

Defect · current.

The reviewer did come back to it. b5be3b7 is the repair — it adds the constant and swaps the argument — committed 2026-08-26 at 19:23:36 EDT, with Qodo's review updated to that exact commit at 19:26:04 EDT. A re-review at the repair head, and I am not going to omit it because it cuts against the shape of the story.

Qodo's review moved again ten minutes later to 121a24f. That one is a different fix — counting providers instead of trusting that a response arrived — and it does not touch this file at all. It carries the repair only because it comes after it. Worth separating, because "the reviewer cleared it twice" would be a nicer sentence than the true one.

I still do not call it fixed. The patch is maker-authored, and no separately assigned breaker seat has adjudicated it. On this project a maker's own PASS does not count no matter who else looked, and the last two times I felt confident about a repair are the two stories above.

One thing I did check, because a reviewer of this draft predicted a second hole in the same class: if a receipt simply omits a canonical key from checks, does absence read as a pass again? It does not. decide() filters on checks[field]?.observed !== true, so a missing key lands in blocked_by and the receipt is rejected. Omitting sdk yields LOCAL_PREREQS_BLOCKED ["sdk"]; checks: {} blocks on all three. The predicted hole assumed an implementation that reads status === 'FAIL', which is not what is there. I mention it because the prediction was reasonable and running it was faster than arguing about it.

One check you can run

Debashish Ghosal proposed this in the comments on the last piece:

"Throw random strings into event.notes during test runs. If altering a human note flips a programmatic verdict, fail the build immediately."

One note on scope before the code: this harness targets the Python classifier from the previous article — claim_24/mandate_cell7.py in a different repository. It does not test the JavaScript validator above. Two codebases, one failure class.

Complete file. Python 3, no dependencies, run it as-is:

import random, string

def fuzz_note_independence(classify, row, note_field="notes", n=200, seed=0):
    """Perturb only the prose. If the verdict moves, the prose is load-bearing."""
    baseline = classify(dict(row))
    rnd = random.Random(seed)
    for _ in range(n):
        r = dict(row)
        r[note_field] = "".join(rnd.choice(string.printable[:95])
                                for _ in range(rnd.randint(0, 80)))
        if classify(r) != baseline:
            return False, r[note_field], classify(r), baseline
    for probe in ["", "TTL EXPIRED", "ttl expired", "not ttl expired",
                  "resolved: ttl expired last week", None]:
        r = dict(row); r[note_field] = probe
        try:
            got = classify(r)
        except Exception as e:
            return False, probe, f"raised {type(e).__name__}", baseline
        if got != baseline:
            return False, probe, got, baseline
    return True, None, None, baseline


def classify_defective(ev):                  # control flow reads the prose
    if "ttl expired" in (ev.get("notes") or "").lower():
        return "SKIPPED_TTL_EXPIRED"
    return "CONSULTED"

def classify_note_independent(ev):           # control flow reads a typed field
    if ev.get("reason_code") == "TTL_EXPIRED":
        return "SKIPPED_TTL_EXPIRED"
    return "CONSULTED"

row = {"reason_code": "TTL_EXPIRED", "ttl_remaining_hours": -0.0,
       "notes": "grant ttl expired during consult"}

for name, fn in (("defective", classify_defective),
                 ("note-independent", classify_note_independent)):
    ok, note, got, base = fuzz_note_independence(fn, row)
    print(f"{name:18} {'PASS' if ok else 'FAIL'}  baseline={base}"
          + ("" if ok else f"  note={note!r} -> {got}"))

# The independence harness above cannot catch negation, because on this row
# "not ttl expired" still contains "ttl expired" and returns the same verdict
# as the baseline. Negation needs a row whose typed reason is NOT expired:
negated = {"reason_code": "CONSULTED", "notes": "not ttl expired"}
print("negation           defective ->", classify_defective(negated),
      "| note-independent ->", classify_note_independent(negated))

defective          FAIL  baseline=SKIPPED_TTL_EXPIRED  note='R5x$!PCZJ-r#hAhc<w...' -> CONSULTED
note-independent   PASS  baseline=SKIPPED_TTL_EXPIRED
negation           defective -> SKIPPED_TTL_EXPIRED | note-independent -> CONSULTED

Two things worth being precise about, because I got both wrong in a draft of this.

The negation probe inside the harness catches nothing. "not ttl expired" still contains "ttl expired", and the baseline row already classifies as expired, so the verdict does not move and the harness reports no change. Negation needs the separate row at the bottom, where the authoritative field says CONSULTED and the grep says otherwise. That is the line that shows the defect.

And this establishes note independence only. It does not establish that the typed field is right. A typed field can lie as cleanly as a sentence — a grant expired by one second stored as -0.0, and -0.0 >= 0 is True in Python. Which is how the last piece started.

What is still open

anp2network's objection is the one I have not answered:

"Every field on that row has the same author... Each one worked by making two fields disagree. That method cannot see the row where nothing disagrees and the answer is still wrong."

Every check above works by making two views disagree. A commit message contradicts its diff. A candidate complete-set count contradicts the repository state it would have created if merged. A verdict contradicts its own inputs.

That method is blind to the case where nothing contradicts anything. If a timestamp is stamped when a gate consumes a grant rather than when the issuer issues it, every field agrees, every recomputation is clean, every contract passes, and the verdict is wrong — because the error arrived before the first field was written.

My read of their proposed direction is that independence is a property of who could have been compelled: you are not looking for a willing second witness, you are looking for bytes some other party already wrote, for their own reasons, that a claim can be bound to.

I have not built that.

Check any of it yourself. Every timestamp in this piece comes from a public endpoint that needs no account:

Commit times — git show -s --format=%cI <sha> after cloning the repo, or the commit pages linked above
Review timing — GET /repos/keniel13-ui/self-correcting-integration-maintainer/pulls/1/comments and /reviews; the finding on the defect carries original_commit_id: 4a8e6c9… and created_at: 2026-08-26T01:30:49Z
Comment times — GET https://dev.to/api/comments/3df2g returns created_at: 2026-08-24T13:41:44Z; 3dfeg and 3def2 the same way. The DEV page shows only the date, so the API is where the hour lives
Repository creation — GET https://api.github.com/repos/keniel13-ui/self-correcting-integration-maintainer returns created_at: 2026-08-25T23:47:38Z

All times converted to EDT (UTC−4). Verified 2026-08-30.

Git Said It Succeeded. The State Said Otherwise.

Self-Correcting Systems — Sun, 30 Aug 2026 01:44:59 +0000

I keep finding git behaviours the same way: set up the case, run the command, then check the state I actually cared about instead of trusting the success message. Guides pair rerere.enabled with rerere.autoupdate when the second one removes the checkpoint the first one earns you. GitHub reports mergeable while the reviewer is still reading stale bytes. --autosquash prints Successfully rebased and updated and leaves a fixup! commit sitting in history.

Copy the config. The reasoning is why you would leave one of them off.

This started as a comment on Sylwia Laskowska's git list. She asked me to turn it into a post. The first four items are from ordinary rebasing. The rest I measured this week on a stacked-PR repo.

1. `rerere` does not learn from `git add` alone

git config rerere.enabled true

rerere is reuse recorded resolution. It remembers how you resolved a conflict and replays it when the same one appears. On a long rebase that is resolving something once instead of five times.

CONFLICT (content): Merge conflict in f.txt
Staged 'f.txt' using previous resolution.

Resolve, git add, then abort immediately, and it recorded nothing. The next attempt conflicts identically. That bit me twice before I understood it.

Two things are going on and my test could not separate them, so here are both. git add does not record the postimage — git commit, git rebase --continue, or an explicit git rerere do. And git rebase --abort runs rerere clear, which wipes the in-flight metadata anyway.

What I could measure, on git 2.39.5: resolve + git add + abort, and the next attempt conflicts identically. Resolve + git add + explicit git rerere + abort, and it replays — before the rebase goes anywhere. So "it learns when the rebase finishes" is the wrong model either way.

2. It matches on the normalized conflict hunk, not the pathname

I taught it a resolution in one.txt. Then I created the same conflicting hunk in a completely different file, two.txt, on a different branch. It replayed the one.txt answer into two.txt.

On a rebase that is usually what you want. It is not always what you want. If the right answer differs between those two places, it will quietly give you the first one.

3. Which is why I would not turn on `rerere.autoupdate`

I kept seeing them paired. I checked the index in both modes:

autoupdate off  ->  UU two.txt    still conflicted, you must read it and git add
autoupdate on   ->  M  two.txt    fully staged, nothing asks you to look

Autoupdate off is the checkpoint that catches a replay you did not want. Leave it off and rerere still writes the resolution into the file. You just have to look at it before adding.

If it got it wrong:

git rerere forget <path>   # drop what it learned
git checkout -m <path>     # bring the conflict markers back

4. `--autosquash` can succeed and still leave the fixup in history

git commit --fixup abc1234
git rebase -i --autosquash abc1234~1

First marks it. Second reorders and squashes it. The todo list opens already correct.

Three sharp edges. The third one was found by a reader after this published, and it breaks the check I originally recommended here.

Bare git rebase -i --autosquash with no range fails outright on a branch with no upstream, so you need the base.

If the range does not reach far enough back to include the target, it does not warn you. It prints Successfully rebased and updated and leaves the fixup! commit sitting in your history.

And autosquash can squash into the wrong commit while leaving nothing behind to grep for. From git-rebase(1):

A commit matches the ... if the commit subject matches, or if the ... refers to the commit's hash. As a fall-back, partial matches of the commit subject work, too.

So when two commits in the range share a subject prefix, it picks one — the older — and never says so. vinhnguyenthanhdn found this on git 2.50.1; I reproduced it on 2.39.5.

Naming the target explicitly does not save you, because git-commit(1) says --fixup=<commit> builds "a subject composed of fixup! followed by the subject line from <commit>" — the hash is used at commit time and never written into the message. Two commits subjected fix tests, git commit --fixup <newer-sha>, and the change landed in the older one.

In every one of those runs git log --oneline | grep fixup! returned zero. Clean history, no leftover, change in the wrong commit. That check cannot see this, and I should not have offered it as the check.

Read the plan instead, before anything is rewritten:

GIT_SEQUENCE_EDITOR='cat "$1"; false' git rebase -i --autosquash <base>

pick   91a85a7 fix tests
fixup  c0f8e9b fixup! fix tests
pick   d467ebf fix tests        <- the commit I actually named

Exit 1, every hash intact, and you can see the fixup sitting under the wrong commit before a single object is written.

Do not drop the ; false. GIT_SEQUENCE_EDITOR=cat exits 0, git reads that as "the todo is approved," and your preview rewrites history. The two forms differ by one word. And the safe one prints error: There was a problem with the editor — that error is the abort, not a failure.

If you want prevention rather than inspection, put the hash in the message yourself. fixup! <sha> matches on the hash and is immune to subject collisions:

git commit -m "fixup! $(git rev-parse <target>)"

The rebase step rewrites history — git commit --fixup just adds a commit — so the usual rule about rebasing shared commits applies to the second line, not the first.

5. Retargeting a pull request changes what it compares against. It does not update the head branch.

This one I did not set up on purpose. I had a stack: main ← #3 ← #4 ← #2. After #3 and #4 merged, I retargeted #2 onto main. GitHub immediately showed base: main, mergeable, clean.

The new base commit was still not an ancestor of my head.

I measured it. Head b1cf109 versus main at e6dc136: GitHub compare status diverged, behind by 8. After git merge origin/main (commit b4ac271): behind by 0.

git fetch origin main
git merge-base --is-ancestor origin/main HEAD && echo "head contains main" || echo "STALE — merge first"

Exit 1 is the stale case. GitHub's "Change base" button is not "Update branch." Change base retargets what the PR is compared against. Update branch, or git merge origin/main, is what actually brings the commits in.

Those SHAs are from a private stack, so this one is a field note rather than something you can clone and rerun. The check itself is two lines and works anywhere.

That head was what the automated reviewer had to work from. It carried an old implementation I had already replaced on main, and I burned a cycle chasing a finding about code that only still existed on that stale branch — before I thought to check whether the branch contained what I thought it contained.

The fix is one merge, then the ancestor check. MERGEABLE does not mean "this head contains current main."

6. Pin evidence links to a commit, not to `main`

A link to /blob/main/path/file shows whatever main says today, and 404s outright if the path later moves. A link to /blob/<sha>/path/file is immutable. Both may return 200 right now. Only one of them still means the same thing next month.

I hit this the same week. main still carried an old write-up while the corrected file only existed on a branch. I published the SHA-pinned URL so a reader could open the bytes I was citing, not whatever landed on default later.

If you are citing evidence, cite the sha.

7. `git worktree` instead of stashing, if you have untracked files you cannot lose

Stash does not save untracked files unless you remember -u. I had an untracked scratch file I needed to keep through a week of branch hops. Worktrees solved it without the dance: each branch in its own directory, one object store, untracked files stay put.

git worktree add -b some/branch /tmp/scratch origin/main

When you are done: git worktree remove. If you have ever needed to fix one branch while another is mid-edit, this is the command.

Same disease as the rest of the list, incidentally. git stash reports success and your untracked file is simply not in it.

The method

--autosquash prints success while leaving a fixup! behind. A retargeted PR reports MERGEABLE while its head is eight commits behind the branch it now claims as base. rerere.autoupdate stages the replay cleanly and removes the unmerged path you would otherwise have been forced to look at.

In each case the message was true and the state was not what I assumed. And each one needed a different thing checked: the rebase plan before it ran, ancestry for the stale head, the index for UU versus M.

Which is the actual lesson, and it is not "check the index":

A success message tells you the command completed according to its own contract. It does not tell you the repository now satisfies the condition you actually cared about. Those are different sentences. Go check the one you cared about.

Updated 2026-08-30: item 4 corrected. The grep fixup! check this originally recommended is a false negative when two commits in the range share a subject prefix — it returns clean while the change sits in the wrong commit. Found by a reader in the comments; the plan-preview replaces it.

Measured on git 2.39.5 locally; the GitHub compare behaviour is as of this week. Items 1–4 are reproducible on any repo in about two minutes. Item 5 is a field note from a private stack.

This post exists because Sylwia Laskowska wrote a git list good enough that I went and tested the rebase section against it, and then told me the comment should be its own post. She was right, and I would not have written it otherwise. Go read hers.

I Built an Agent That Marked Its Own Finding as Already Known

Self-Correcting Systems — Sat, 29 Aug 2026 23:42:33 +0000

This is the first contest I have entered. I built the honesty controls before I built the agent, which is probably backwards for a hackathon and exactly what I wanted to learn from. Everywhere this piece names a limit, the limit is measured rather than modest, and I would rather you find the seams from me than from a clone.

I gave an agent two files it had never seen. I did not tell it what was wrong. The harness refuses to build the prompt if the words bug, defect or vulnerability appear in its framing.

It returned a concrete claim tied to exact bytes. It wrote a bounded repair. And it declined to call the claim new.

Then I checked the semantics against the class it cited, and got the result this whole harness was built to be able to get.

What it returned

Literal, from the run:

{
  "path": "forms.mjs",
  "condition": "absence reads as a pass",
  "exact_bytes": "const accepted = names.filter(allowForm);\nif (accepted.length === 0) {\n  process.exit(2);\n}\nprocess.stdout.write(`${JSON.stringify({ accepted })}\\n`);",
  "novelty": "CONFIRMS_KNOWN",
  "known_condition_id": "K1"
}

These five fields are verbatim. The full finding object has ten fields and lives in a public receipt you can open right now, along with the raw model output, its SHA-256, both TrueForge session ids, the relay events and the sandbox response:

docs/freezes/RUN_004_RECEIPT.json — SHA-256 162eb2647e86ce62f1733c4864a6f520f8def7856e5ce68dbe8f80e20267bef5

It is a failed-run receipt and labels itself one. Run 004 threw before an artifact was written, so a successful-run bundle does not exist and is not shown.

CONFIRMS_KNOWN means: I found something, and it is not new. It matches a class you already wrote down.

That is the behaviour I wanted. An agent that finds something has every incentive to present it as a discovery, and this one did the opposite.

And the class match is wrong.

Where structural validity stops

Here is K1, frozen and hashed before the run:

A verdict computed over an empty collection returns success. An empty array is treated as "nothing wrong" rather than "nothing checked."

Here is what forms.mjs does when the collection is empty:

if (accepted.length === 0) {
  process.exit(2);
}

Empty exits 2. That is a hard failure. It is the inverse of K1.

And the agent knew. From its own why_it_matters, same finding:

"The empty-array case is treated as a hard failure, but the success case lacks corresponding validation..."

It described the inversion in prose and filed the finding under K1 anyway.

And the consequence it argued does not hold either. It wrote that a caller "cannot distinguish between 'all files were rejected' and 'some files were accepted' from the exit code alone." It can. Exit 2 is the empty case; exit 0 with JSON on stdout is the non-empty one. That is precisely the distinction the code makes.

So there are two separate failures stacked here, and only one of them is the one I set out to catch. The bytes it quoted are real and exact. The patch it proposed is bounded. The novelty citation is structurally valid. None of that made the interpretation true.

The validator admitted it, correctly. It was never scoped to check that, and this is the case that shows exactly where its scope ends.

What the contract actually enforces

if (raw.novelty === 'NEW') {
  if (known !== null) throw new TypeError('NEW finding must not cite a known condition');
} else if (typeof known !== 'string' || !knownIds.has(known)) {
  throw new TypeError('known finding must cite a frozen condition');
}

A NEW claim may not cite a frozen class. A CONFIRMS_KNOWN or CHANGES_KNOWN claim must cite one that exists in the file hashed before the run.

So this is unproducible: "a brand new discovery, category K1." The novelty label and its reference cannot contradict structurally — NEW requires null, and a known-class claim must name an id present in the frozen prior.

This is producible: a condition filed under a class it does not fit, cited coherently. Which is exactly what happened.

I tested the other direction too, deliberately. I took the K1 condition, labelled it NEW, set known_condition_id to null, and ran it through. Accepted.

The model self-reports the novelty label. The validator checks whether that label is structurally consistent with its reference. Neither adjudicates the class match.

The runner is written so that if it produces an artifact, classification_correct is hardcoded false. This run never produced one — it threw first. What the receipt does carry, in its own not_established list, is: "the semantic correctness of the CONFIRMS_KNOWN / K1 classification."

This article is a human read of that unresolved classification, and the K1 match does not survive it. It does not mint the independent-breaker verdict the design still requires.

So the honest statement of what this buys you:

the label and its reference cannot contradict structurally
the quoted bytes exist verbatim, and exactly once, in the named file — the corpus is published too, so you can recompute that yourself against the manifest hash frozen before the run
the repair is scoped to exactly the bytes that were quoted
confidence_basis is prose, not a number — a bare "87%" is rejected
not_established is required and non-empty, so the agent writes down its own limits
and the knowledge it was measured against is hashed and older than the run

What it does not buy you is a machine that knows whether the model is right. You get a claim a stranger can audit line by line. You do not get a claim that is true because a validator said so. The first is what this validator establishes. The second is not, and confusing them is how people ship a slogan.

Why the file has to be committed before the run

PRIOR_KNOWLEDGE_RUN_004.json, six classes, hashed to 93820ea5a67e732aa55e896cd838200c3590af1e98368fd87e85dfd66da1cf1e.

Freezing after the run proves nothing. You could add whatever it found and call the list complete. Committing before is the only version someone who does not trust you can check.

The custody proof is the commit, not a shell check. Commit 5bf10acd added the Run 004 prior at 05:55:49Z. The receipt records execution at 12:02:41Z and binds that exact prior SHA and that exact freeze commit. Six hours apart, both public, both checkable by someone who does not trust me.

I also ran git ls-files --error-unmatch on the prior before starting, as the operator. That proves the path was tracked when I typed it. It is not the chronology proof, and that check is not inside the runner — clone the repo and grep run.mjs for git and you will find nothing. I would rather you hear that from me.

What TrueForge does here

The agent runs on TrueForge, as substrate rather than wrapper.

The session is minimized by name. iteration_limit: 2, a closed json_schema response format, and every optional capability explicitly disabled: no sub-agents, no generative UI, no user questions, no file downloads, no sandbox on the judgment session. Omitting a field is not disabling it — omitted fields inherit enabled defaults, which I learned the direct way.

The returned config is byte-compared. We send a config, TrueForge returns the resolved session, and the harness canonically compares the two. One differing field cancels the session before the prompt is sent. A declaration the runtime accepts but does not apply is a request, not a control.

The persisted event trace is audited after every turn. The harness pulls TrueForge's own event record and reduces it: how many tool calls, which tool, what arguments, whether the response id matches the call id. Final model content never stands in for that record.

The verification relay sends the repair to Daytona as three hash-bound artifacts and attempts the fixed verifier command inside an isolated sandbox.

One thing I did not expect: the agent has exactly one tool and it is a clock. Stock TrueForge 0.1.4 constructs truefoundry-system/current-datetime/get_current_datetime above the optional capability switches, so no setting in that version removes it. My contract had asserted zero tools. That was unsatisfiable and a run told me, not a review.

The ceiling

Daytona created a sandbox and executed the command. sandbox.created, one real exec, one real response:

{"success":true,"response":{"exitCode":127,"result":"/usr/bin/bash: line 1: node: command not found\n"}}

The stock image is Python 3.13 with no JavaScript runtime, measured directly, and the provider's public settings schema exposes no image override.

Candidate verification is not established. The transport reaches and executes. The repair has not been verified. No change proposal was produced, no artifact was written, nothing was applied to any target.

Run it

git clone https://github.com/keniel13-ui/self-correcting-integration-maintainer
cd self-correcting-integration-maintainer
npm ci
node --test --test-name-pattern='J05|V9-F3|Run 004' test/judgment-loop.test.mjs

That pattern runs four tests: J05 (ambiguous bytes, bare-number confidence, empty limits, contradictory novelty references), V9-F3 (a successor prior rejecting one reworded class), the Run 004 prior-custody test, and B1 — which pins the exitCode: 127 sandbox response as nonzero execution rather than a malformed envelope.

They do not cover the hole I described above. J05 rejects NEW citing a known id. Nothing in that set tests NEW with a null reference on a known condition, because the harness cannot detect it. If you want to see the gap, construct that case yourself against validateAgentResponse in scripts/judgment/core.mjs. It takes about ten lines and it will pass.

The pattern is portable. The implementation is this repository. I am not going to tell you twelve lines drop into any framework, because they do not.

What is different about this one

I have written about tests passing while the contract was wrong and about a harness lying before the model does.

Those were about systems asserting more than they had established. This is about giving an agent a way to assert less than it could get away with — and then finding the exact place where that still is not enough.

An agent that returns a plausible defect claim is normal now.

An agent that marks its own claim as already known is rarer, and better.

An agent that does that while both the interpretation and the class match fail inspection, and a correctly-scoped validator still admits the report — that is the case worth publishing, because it marks the exact boundary of what any structural check can do.

So the contribution is not an agent that finds defects. It is a measured boundary: structural consistency is mechanically checkable; semantic correctness requires evidence beyond those structural checks, and here is a live case that separates them — with the corpus, the frozen prior, the raw response and the runtime receipts all published so you can put the boundary where I put it, or somewhere better.

The goal was never an agent that always succeeds. It is a system where failure cannot quietly become evidence of success.

Built for the TrueForge Agent Harness Hackathon. Repository public, run evidence in docs/. Nothing here claims a verified candidate or a completed sandbox verification, because neither has been established.

The Tests Passed. The Contract Was Wrong.

Self-Correcting Systems — Mon, 24 Aug 2026 04:24:57 +0000

In June a reviewer on DEV who goes by @anp2network told me to stop storing a conclusion.

I had a gate that decides whether an agent may act on a permission grant. When it refused, it
wrote a row explaining why. One field, condition_delta, held the reason the conditions had
changed. I was storing a label there. A commenter called ANP2 said a derived label is still my own
assertion, and anybody reading the row has to trust that I bucketed the case correctly. Store the raw
before and after, he said, and a stranger can recompute the verdict without believing me.

That constraint went into the code on 2026-06-04 and it is still on origin/main:

# Store raw before/after — never a derived "stale: true" label
delta = {
    "before": grant.source_snapshot,
    "after": current
}

I have quoted that line in public more than once. It is the thing I point at when I say outside
review lands in the work rather than in the acknowledgements.

Last night I found out I had only obeyed it in one direction.

The rule did not follow the data

The gate emits an event. Something else reads that event and classifies what kind of evidence it
is. That classifier lives in claim_24/mandate_cell7.py, and until last night it contained this:

if event.decision == "REFUSED_UNREACHABLE":
    return EvidenceClassification(event.decision, (), "SOURCE_UNREACHABLE", False)

if event.decision == "BLOCK":
    evidence_class = "TTL_EXPIRED" if "ttl expired" in event.notes.lower() else "BLOCKED_CONTROL"

Read those two branches next to each other.

The first one asks a structured field. The second one greps an English sentence.

notes is a human-readable string I write for my own benefit. ttl_remaining_hours is a number
on the same event. The classifier ignored the number and searched the sentence. Rename the note
and the evidence classification changes. Put the words "ttl expired" into a different kind of
block and it changes the other way. Nothing structured moves.

I stored raw values so a stranger could recompute the comparison, and then I decided why I had
not compared by string-matching prose.

Repair one, and the sentence that broke it

The fix looked obvious. Add a typed field. source_consult, required, one of CONSULTED,
UNREACHABLE, SKIPPED_NO_GRANT, SKIPPED_TTL_EXPIRED, SKIPPED_TIMESTAMP_ONLY. The classifier
dispatches on the enum. It never reads notes again.

We froze that contract first, hashed it, then wrote the code. The freeze is 9f3dda8c. Its third
rule says:

R3. classify_evidence on a BLOCK event with source_consult == SKIPPED_TTL_EXPIRED returns
TTL_EXPIRED. Any other BLOCK returns BLOCKED_CONTROL. It must not read event.notes for
this branch. ttl_remaining_hours may be used as a corroboration, not as the sole
consult-reason.

Implementation matched. Renaming the note no longer moved anything. 366 tests passed.

Then I described the change, in prose, to a seat that could not open a single file.

He did not ask to see the code. He asked one question:

What proves SKIPPED_TTL_EXPIRED was true?

And then he answered it himself. If the classifier trusts the enum without checking the structured
TTL, we have not removed a self-assertion. We have retyped one. He wrote out the row he wanted
tried:

source_consult      = SKIPPED_TTL_EXPIRED
ttl_remaining_hours = +17.4
decision            = BLOCK

The evidence class says the grant expired. The number on the same row says it has seventeen hours
left. Those cannot both be authoritative.

It returned TTL_EXPIRED.

And here is the part that matters more than the bug. The implementation was correct. R3 says
the enum decides and the raw field may corroborate. The word is "may." The code did exactly what
the contract told it to do. The defect was not in the patch. It was in the sentence I wrote before
the patch existed.

366 tests passed against a specification that mandated a contradiction.

Repair two, and the thing a rounded number costs

We froze the failure before touching anything. That record is 9f5fb47d and it holds the file hashes, R3 verbatim, the
attack input and output, and the test count sitting beside it. Then a second contract: an evidence
class that asserts a fact must agree with the field that represents it. c686518a.

That worked for the attack that killed the first one. +17.4 with SKIPPED_TTL_EXPIRED became
INVALID_FOR_CELL_7. Genuinely expired grants still classified. Notes still could not move
anything.

The same seat, still without file access, said the fix was probably pairwise and asked for four
more rows. All four exposed contradictions. Three are enough to show the pattern here.

A grant that never existed still expired. SKIPPED_TTL_EXPIRED with grant_id = None returned
TTL_EXPIRED. The consistency check validated the enum against the TTL and against nothing else.
No grant, so no grant's lifetime could have run out, and the classifier had no opinion about that.

A grant expired by one second was not expired. The gate stores
ttl_remaining_hours = round(seconds / 3600, 2). Two decimal places of an hour is
thirty-six-second granularity. A grant one second past expiry stores -0.0. And in Python:

>>> -0.0 >= 0
True

So the row got classified INVALID_FOR_CELL_7 instead of TTL_EXPIRED. Every grant expired by
less than about eighteen seconds was misread. Not because the clock was wrong, but because the
classifier was making an evidence-class decision from a rounded display copy of the clock while the
timestamps that could compute it exactly sat on the same object.

Malformed evidence produced a confident answer. He predicted this one from the shape of the
comparison alone, without seeing it:

>>> float("nan") >= 0
False

So ttl_remaining_hours = nan fell straight through the guard and returned TTL_EXPIRED. No
finiteness check. Garbage in, confident evidence class out.

What was actually wrong the whole time

Three versions. One disease.

	Where truth lived
Original	prose. `"ttl expired" in event.notes.lower()`
Repair one	an enum. `source_consult`
Repair two	an enum agreeing with one rounded float

Every repair moved the authority somewhere better typed, and looked like progress for exactly that
reason. None of them moved it to the least-derived evidence available.

Structure is not evidence merely because it has a schema. A typed field can lie as cleanly as a
sentence.

ANP2's June constraint was never "don't use strings." It was: do not let a derived value outrank
the raw evidence sitting on the same row. I applied it where the comparison happens and it never
followed the data one file downstream, to where the result of that comparison gets read.

The third contract, 83afebd8, was hashed before any code existed. Expiry authority is no longer
the rounded ttl_remaining_hours display field. It is the direct comparison
decision_timestamp > grant_expires_at, with grant_expires_at derived from the grant's issue
time and lifetime without rounding. A grant expired by one second now classifies as expired,
and the -0.0 in the display field decides nothing.

Why I am not telling you it is fixed

Four seats touched this. Every one of them is disqualified from saying it works.

The seat that wrote all three contracts also wrote all three patches. The seat that briefed the
lane, which is me, cannot rule on a lane it opened. The seat that designed the attacks that falsified both
earlier repairs shaped the successor by doing so, and his verdict would be no more independent than
mine. The owner authorized the scope and is not a breaker.

So what I can honestly report is narrow: maker-side mechanical rechecks returned the expected
outcomes for every frozen attack. Contradictory rows invalidate. One-second expiries classify.
nan and ±inf invalidate. Legitimate rows still pass. Renaming the note still moves nothing.

That is not a PASS. It is the same green I had at 366 tests, and 366 tests were green while the
contract required a contradiction.

The verdict waits for a seat that wrote none of this.

The part that does not need a verdict

One proposition here is already true and no breaker changes it:

Twice the implementation was faithful and the specification was wrong.

Both times the code did what its contract said. Both times the tests confirmed it. Both times the
contract permitted a row where a derived label outranked the evidence that could have checked it.

Passing tests measure conformance to a document. They do not measure whether the document is
right. Those are three separate properties and I had been treating the first as evidence for the
third:

implementation correctness ≠ specification correctness ≠ evidence correctness

I have written before that a check which reports is not a control. This is the version one level
up. A test suite that passes tells you the implementer understood the spec. It tells you nothing
about whether the spec understood the problem.

The cheapest way I know to find that gap is to describe your contract, in plain sentences, to
somebody who cannot run it, and let them tell you what your own words permit.

Mine did it twice. He never opened a file.

Receipts

Object	Hash / location
Original defect	`claim_24/mandate_cell7.py`, `origin/main`
ANP2's compiled constraint	`4a2f3a4`, still on `origin/main`
Repair-one contract (R3)	`9f3dda8c`
First falsification, 366 tests green	`9f5fb47d`
Repair-two contract	`c686518a`
Second falsification (D1–D4)	`e6409cbd`
Whole-row contract, frozen before code	`83afebd8`

All five freeze records are public and hash-checkable: claim_24/freezes/. Verify with shasum -a 256. They are on a branch, not main, because the repair code they govern is maker-only and has not been independently attacked. The original defect is on main and needs no branch.

What this claims: a classifier on origin/main derived an evidence class from free text; two
successive contracts permitted a derived value to outrank recoverable evidence; both failures were
predicted from prose by a seat with no file access.

What this does not claim: that the third contract is correct. No independent seat has attacked
it. Two questions are open and deliberately out of scope. Whether grant_expires_at is itself
cross-checkable against the underlying grant at replay time, and what happens to evidence rows
serialized before any of this existed.

I Was About to Optimize Five Canvases. Two of Them Weren't Running.

Self-Correcting Systems — Tue, 18 Aug 2026 17:29:41 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Existing codebase: primaworkflows.com, one 321,920-byte HTML
file, SHA-256 06a768bb…. All index.html line numbers below are against that published
file. prima-visual.js line numbers are against the file the live site serves today
(8,773 bytes, SHA-256 dc78c46d…). Every number is measured, and the places where I got
one wrong are left in. Production has not been swapped for the after. A same-session
A-vs-C table is still empty on purpose.

Project Overview

My site lags on my phone. It is the only page I own that strangers and clients actually load,
and it feels slow in the hand. That was the bug. I had the fix written before I opened the file:
five stacked canvases, a pile of animation loops, collapse them into one clock and move on.

Then I read the file instead of my notes about the file.

// index.html:3824
const WORLD_CANVAS_ENABLED = false;

Two of the four persistent animation loops I was about to collapse never start. The flag gates
the call that kicks them off, at :7103.

It gates only that. I want to be exact, because my first draft of this paragraph said the
flag also gated their 2D contexts, and then I checked the published file instead of my working
copy:

// index.html:3832, :3834, :3875 — no guard on any of them
const ctx               = canvas.getContext('2d');
const vctx              = visitorCanvas.getContext('2d');
const visitorPreviewCtx = visitorPreview.getContext('2d');

So production still creates three 2D contexts for canvases nothing
ever draws to. The loops are dead; the memory is not. Guarding those three lines is a separate
one-line-each change that is in my working tree and has not shipped, and I am not counting it
in anything below.

A third loop, the custom cursor, exits immediately on touch devices:

// index.html:6656
(function primaCursor() {
  if (window.matchMedia('(hover: none)').matches) return;

Mobile is the measurement that matters here — it is a phone-facing page. So on the device I
was optimizing for, the page had one persistent JS loop, not four. The optimization I had
specified had almost nothing to collapse. If I had built it and measured, I would have seen
nothing move and had no way to tell a failed fix from a fix with no room to work.

I had written the plan from a document I wrote myself, about a file I wrote myself.

Bug Fix or Performance Improvement

The actual bug

Once I was reading rather than remembering, I found this.

// index.html:3188
function canRunWebGLHero() {
  return window.matchMedia('(hover: hover)').matches;  // ← returns here. always.
  if (window.matchMedia('(prefers-reduced-motion: reduce)').matches) return false;
  if (window.matchMedia('(max-width: 820px)').matches) return false;
  if ((navigator.hardwareConcurrency || 4) < 4) return false;
  if (navigator.deviceMemory && navigator.deviceMemory < 4) return false;
  try {
    const c = document.createElement('canvas');
    return !!(c.getContext('webgl2') || c.getContext('webgl'));
  } catch (error) {
    return false;
  }
}

Five guards under an unconditional return. Not one of them executes in the published build I
audited, and that build is the one live right now. I have not audited every prior deployment,
so I am not claiming a start date for it. The patch is deleting that one
return. I am not writing the fix in the past tense until the line is gone from the file a
visitor loads.

What that silently switched off:

Guard	Intended	Actual, today
`prefers-reduced-motion`	no WebGL hero	ignored
`max-width: 820px`	skip small screens	ignored
`hardwareConcurrency < 4`	skip weak CPUs	ignored
`deviceMemory < 4`	skip low-RAM machines	ignored
`webgl2` / `webgl` probe	skip unsupported devices	ignored

The reduced-motion one is the part I am least comfortable with. Someone sets that preference at
the operating system level, for reasons that are theirs, and my page has been overriding it since
the day I shipped it. Not because I disagreed with them. Because a return was on the wrong
line.

The capability probe is the expensive one. A hover-capable machine with no WebGL support
downloads and compiles Three.js, tries to start, throws, and the failure lands in a
.catch(err => console.warn(...)) where nobody sees it. It pays full price for a feature it
cannot run.

Code

Exact diffs of both changed files:
gist.github.com/keniel13-ui/3c05e11202d048ad78a11ce2de215e8d
— two unified diffs against the deployed 06a768bb file, plus a README of what each hunk does
and what is deliberately excluded from the claims. Production has not been swapped, so the
before in that diff is what you get if you load the site right now.

Three scripts, and the one I was wrong about

The page declares three third-party scripts on every load:

<!-- index.html:129-131, verbatim from the live page. Note what the first one is missing. -->
<script src="https://cdn.jsdelivr.net/npm/@supabase/supabase-js@2"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/gsap.min.js" defer></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3.12.5/dist/ScrollTrigger.min.js" defer
        onload="window.dispatchEvent(new Event('gsap-ready'))"></script>

The first tag has no defer. The two GSAP tags do. So Supabase is a plain script in
<head>: the browser stops building the DOM, fetches it, parses it, executes it, and only then
continues. Parser-blocking, in the head, for a library whose every call site is behind a flag
that is off.

I had a defer on that line in an earlier version of this post. I put it there. It is not in the
file — I had copied the tag out of my own working branch, where a previous change had added one,
and pasted it as though it were production. If you are going to quote code, quote the deployed
bytes.

Measured from the URLs the production page resolved during this audit. GSAP is pinned to
3.12.5. @supabase/supabase-js@2 is not a pin — jsDelivr treats @2 as a moving
major-version alias, and it resolved to 2.112.3 at the time of measurement
(x-jsd-version: 2.112.3). If you re-run this later and get a different Supabase number,
that is why:

	gzip transfer	uncompressed JS source
`supabase-js@2`	54,607 B	212,199 B
`gsap.min.js`	28,200 B	72,214 B
`ScrollTrigger.min.js`	17,681 B	43,380 B
total	100,488 B	327,793 B

Those are three different units and I want to keep them apart. 327,793 B is uncompressed
JavaScript source — slightly more source than the 321,920-byte HTML document itself.
100,488 B is the measured gzip transfer at the moment of the audit. I re-fetched the same
three URLs while finishing this post and got 100,148 B — the uncompressed source did not
move, the compressed transfer did. That is the moving @2 alias and CDN recompression showing
up in my own numbers, which is exactly why the alias is disclosed above rather than presented as
a pin. Both of these are cold-load figures; a repeat visitor
with a warm cache does not retransmit them.

The honest headline is the source figure: three libraries carrying more JavaScript source than
the entire document they were decorating.

Supabase is straightforward. Every one of its call sites — loadWorldState,
loadVisitorAvatars, subscribeToVisitorAvatars — is invoked only inside
if (WORLD_CANVAS_ENABLED). That flag is false. In the published build audited here
those call sites are unreachable — I have not audited every prior deployment, so I am not
claiming they never fired in the site's history. The library was still being fetched and
parsed on every cold load regardless.

GSAP is where I was wrong, and I want it on the record because it nearly became the headline
of this post.

I grepped index.html for gsap, found nothing outside the script tags, and wrote a comment
into the working file stating the libraries had zero call sites and that the gsap-ready event
had no listener. Both sentences were false. I had grepped one file on a site with several.

// prima-visual.js (live, dc78c46d…):226
const { gsap, ScrollTrigger } = window;
gsap.registerPlugin(ScrollTrigger);
gsap.to({ progress: 0 }, {
  progress: 1,
  ease: 'none',
  scrollTrigger: { trigger: document.documentElement, start: 'top top',
                   end: 'bottom bottom', scrub: 1.2,
                   onUpdate: (self) => { scrollTarget = self.progress; } },
});
// prima-visual.js:248
window.addEventListener('gsap-ready', wireGSAP, { once: true });

Line 248 is the listener I said did not exist. And scrub: 1.2 was doing real work: it is the
weight in the scroll, the reason the background trails your finger instead of snapping to it.
Deleting the tags did not remove dead code. It removed a feature, quietly, in a way no
performance score would ever have shown me.

So the honest version of this optimization is not "I deleted libraries nothing called." It is
"I used one behaviour out of 115,594 bytes of library source, and I replaced that one
behaviour."

Reading the render loop showed the replacement was smaller than expected, because half of it
already existed:

bgUniforms.uScroll.value += (scrollTarget - bgUniforms.uScroll.value) * 0.04;

There were always two easing stages. ScrollTrigger's scrub was the first. That line was the
second, and it was mine. Removing the tags took out stage one only — the page never went
un-eased, it just lost the lag.

// replaces gsap + ScrollTrigger. this is what is in the after file, not a cleaned-up retelling.
const SCRUB_SECONDS = 1.2;   // the name is a lie. it is a time constant, not a catch-up.
let scrollRaw = 0, scrollEased = 0;

const readScroll = () => {
  const max = document.documentElement.scrollHeight - window.innerHeight;
  scrollRaw = max > 0 ? Math.min(1, Math.max(0, window.scrollY / max)) : 0;
};
readScroll();
window.addEventListener('scroll', readScroll, { passive: true });
window.addEventListener('resize', readScroll, { passive: true });

// inside the existing rAF loop:
const dt = Math.min(0.1, (now - lastFrame) / 1000);   // clamped for tab-switch gaps
scrollEased += (scrollRaw - scrollEased) * (1 - Math.exp(-dt / SCRUB_SECONDS));

GSAP's scrub: 1.2 means caught up in 1.2 seconds. Mine is an exponential time constant:
at τ = 1.2 it is 63% there at 1.2 s and needs about 3.6 s to reach 95%. If I define "caught
up" as ~95% settled — and that is my definition, not one GSAP supplies — then τ ≈ 0.4
puts the settling time near 1.2 s. That is a heuristic mapping, not an equivalence. I left the wrong number in the file, under a name that claims I matched
the library, because the only test that settles the feel is a thumb on a phone. I have not
done that pass yet. This approximates scrub. It does not reproduce it.

One property claim, narrowed after review, because my first version of this sentence was
wrong. The new first stage is time-based rather than a fixed per-frame lerp. But the
second stage — the * 0.04 line above, which was always mine — is still frame-based. So the
combined visual response is not refresh-rate invariant, and I am not claiming it is. Only
the stage I replaced is.

One more deletion, named so I do not take credit for it: the published page fires a WebGL intro
at load (index.html:6576, fireIntro). I had already rejected that motion as the owner. The
after-build does not call it. Clear the Lineup does not let me score a deletion as an
optimization, so it is not in any delta I will publish.

My Improvements

The standing cost nobody counted

The frozen contract I wrote counted canvases and rAF loops. It did not count CSS.

Gemini counted "15+ infinite" and I copied it into a draft before checking. Then I did the
thing this whole article is about and went and looked.

The published file has 15 infinite animation declarations: 14 written as CSS rules, one
injected from JavaScript. Of the 14 CSS rules, six target classes that appear nowhere in
the DOM and are never injected by JavaScript: .feed-pulse-dot, .feed-line, .sig-dot,
.hero-scan, .hero-console, and .scroll-cue. That last one is easy to miss because
.prima-scroll-cue is live in the hero. .scroll-cue is a different selector. There is no
id="scroll-cue" either — a scroll handler looks for one and finds nothing. They are dead
rules. They cost nothing at runtime because there is nothing to animate.

So the real standing set is eight live CSS rules plus ambientDrift, one of which is
seedBreathe — the Seed of Life — which stays. Everything else is decoration running whether
or not anyone can see it.

All eight live CSS targets sit inside <main>, so main > section[id] reaches every one. I
checked that rather than assuming it, because the selector does not match pseudo-elements
either, and I had already been wrong once about what a selector covered.

That is the third time on this one page that a count of declarations got reported as a count
of things happening: four loops of which two never start, fourteen CSS infinite rules of
which six target nothing, and my own contract that warned against exactly this in writing
before doing it twice.

The page already had an IntersectionObserver, and I nearly claimed credit for it. It is not a
brake:

obs.unobserve(entry.target);   // one-shot card reveal, then it lets go

It reveals cards once and unhooks, and the whole block exits early under prefers-reduced-motion.
So a second observer, doing an actual pause:

[data-ctl-offscreen], [data-ctl-offscreen] * { animation-play-state: paused !important; }

@media (prefers-reduced-motion: reduce) {
  *, *::before, *::after {
    animation-play-state: paused !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

const obs = new IntersectionObserver(entries => {
  entries.forEach(e => e.isIntersecting
    ? e.target.removeAttribute('data-ctl-offscreen')
    : e.target.setAttribute('data-ctl-offscreen', ''));
}, { rootMargin: '200px 0px 200px 0px', threshold: 0 });

document.querySelectorAll('main > section[id]').forEach(s => obs.observe(s));

document.addEventListener('visibilitychange', () => { /* whole-tab pause */ });

One check before claiming that gates the standing cost broadly: [data-ctl-offscreen] * does
not match pseudo-elements, so an infinite animation on a ::before or ::after would keep
running off-screen. I went and looked — zero of the infinite animations in this file live on
a pseudo-element, so the selector covers them. If yours do, add ::before and ::after.

The fifteenth is ambientDrift, injected from JavaScript rather than written in the
stylesheet, which is why it survives a grep of the CSS. Its elements are appended into the
sections the observer already watches, so the descendant selector catches it.

Nothing is deleted. Fifteen infinite-animation declarations before, fifteen after. Only the
play state is gated, and only where nobody can see it. The selector is main > section[id] — eleven
sections, including #world, which is where the hero lives. Off-screen the Seed rests.
On-screen it still breathes.

Numbers

Both sides were deployed as previews in the same Vercel project, alternating A/C in one
session, lighthouse 13.4.1, mobile, default simulated throttle. That matters: Vercel injects
vercel.live/feedback.js into previews and not into production, so measuring production against
a preview compares two different pages. Both of these carry it.

What I can report

Total transfer weight is not a CPU measurement. It is a sum of response sizes, so it does not
move with host speed:

	A — before	C — after
Total byte weight, median of 3	568,605 B	467,962 B
Run-to-run spread	1,616 B	952 B
Resources	10	10

Delta: 100,643 B — 98.3 KB, 17.7% of the before.

Worst-case A still beats best-case C by 98,993 B. Every A run transferred more than every C run,
with no overlap. And it independently agrees with the figure I got by curl-ing the three CDN
URLs directly (100,148–100,488 B) — two different methods, same answer, which is the only reason
I trust either.

What I cannot report yet

Nothing CPU-dependent. My own gate refused all six runs.

run	benchmarkIndex	verdict
A-01 / A-02 / A-03	833 · 827 · 783	below floor
C-01 / C-02 / C-03	623 · 214 · 660	below floor

The floor is 1500. A single calibration run half an hour earlier scored 1711 — then ten
back-to-back Lighthouse runs on an 8 GB laptop drove the host underneath its own threshold. So I
have LCP, TBT and main-thread numbers from those six runs, and by the rule I wrote before I saw
them, they do not go in this post.

I want to be exact about what that costs the submission: the headline performance claim here is
a 17.7% transfer reduction and a real bug fix, not a Lighthouse score. The CPU numbers need a
machine that is not also running the thing doing the measuring, and I do not have one today.

Every discarded run is published in the gist anyway — measurements.md — with its
benchmarkIndex in the same row, so you can audit the discard instead of taking my word that
one happened.

Why the before-number is not the worst one I have.

The first Lighthouse run on this page, 2026-08-17, scored 27, with LCP 10.4 s and TBT 13,310 ms.
It is the most flattering baseline available and I am not using it. Seven later runs of the
same URL, same tool version (lighthouse 13.4.1), same declared throttle, said LCP 3.67–5.48 s
and TBT 216–709 ms. Run one has never reproduced. Using it as the baseline would make any
before-and-after look dramatically larger than the reproducible baseline does. I am not putting
a multiple on that until the table below exists.

I also cannot compare a measurement taken on a quiet host to one taken on a dying one. Every
Lighthouse report carries environment.benchmarkIndex, the host speed it saw. One set of my
runs on 2026-08-17 sat at 302–1113. Every other production set that day sat at 1705–2342. No
overlap. Those slow runs were taken while the laptop was running out of memory; the session
died 27 minutes later. The tool exited cleanly and wrote valid JSON the whole time.

So, my inclusion rule — 1500 is a threshold I chose, not a Lighthouse validity boundary:
same session, both sides, benchmarkIndex ≥ 1500 on every run, or the numbers do not go in.

What I am not claiming

The loop collapse is not the win. On mobile there was one loop. I left it alone rather than ship a change I could not attribute.
The 173,280 bytes of inline JavaScript inside the 321,920-byte HTML document are untouched. That is the largest remaining LCP cost and splitting it is a restructure, not an optimization. Gemini called the inline JS "168 KB." Measured off the published file it is 173,280 bytes.
Three.js is still on the page. prima-visual.js (8,773 bytes, live) imports it after first paint. On hover-capable desktops, hero-webgl.js (12,852 bytes, live) imports the same module. One download, two call sites. Lighthouse flags 151 KB of it as unused. Gating the visual layer on mobile would flatten the page, so it stays until I have something better than a smaller file.
The prefers-reduced-motion guard does not work today. It will work when that early return is gone. I do not get to write that sentence in the past tense until a visitor's browser actually takes the other path.
Removing fireIntro is owner-directed deletion. It is disclosed. It is not the optimization.
This is not live on primaworkflows.com yet. The hashes above are the before. The after is still a local preview candidate.

The part I would tell someone starting

I wrote a careful specification of my own site, from memory of my own site, and it was wrong in
three places: two loops that never ran, a whole class of animation I had not counted, and a
library I called dead that was drawing the scroll. Every check I ran was correct. Every one of
them was narrower than the claim I made from it.

The bug in the code was five guards under a return. The bug in me was the same shape one level
up: a real result, reported as if it covered more ground than it did.

Best Use of Google AI

I gave Gemini the frozen before-state and asked it to name the contention before I implemented
anything, so the diagnosis could not be written backwards from the fix. The raw stdout is
timestamped. I did not get to edit what it said.

It got the thing I had missed: competing infinite CSS keyframe animations, which my own
contract had not counted at all because I had been counting canvases and rAF. It also separated the two
hypotheses: the inline parser-blocking JS (173,280 bytes, not the 168 KB it printed) as the
more plausible cold-load and LCP cost, and the persistent animations as candidates for the
standing main-thread cost. I have not measured that split, so those are hypotheses and not
causes, and I am not going to promote them past what the table below supports. The distinction
still changed what I measured: collapsing loops and then judging the result on LCP would have
shown a real fix as a failure.

It also told me the page had no IntersectionObserver. The published HTML has one, at line

hero-webgl.js has another. I checked before believing it, which is the only reason that error is a footnote instead of a paragraph in this post.

If Gemini had added nothing I would have dropped this category rather than backfill a prompt
after the fix. It added the CSS count. That was enough to keep the section, and not enough to
let it write the article.