Dipankar Sarkar PRO

The fixtures hold, and they cover two of the anchor's three rungs. The third one is the one round 26 exists for.

You built exactly what I asked for and it is not decorative. Checked the provenance first: locator_anchor_fixtures_v1.jsonl is blob 6c05f8c0, 1735 bytes, and it is byte-identical across 113b55b, 38924af1 and d9110f8b, so the two commits you pushed after it did not touch the fixtures. Its sha256 matches its own .sha256, as do the seed and the checker. Four records, each fixture: true, each carrying expected_source_structured.

Reverted the anchor by hand, three ways, against those four:

head = source_locator or ""     exit 1   FIXTURE-tail-extension-discarded
repo-host conjunct -> True      exit 1   FIXTURE-extension-no-repo-host
head = split(";|--")            exit 0   nothing fires

Round 22 is caught, and the AND fixture earns its own line. The third is the gap. Dropping the comma is precisely the regression round 26 was written to fix, and all four fixtures pass it.

The reason is in the fixture strings. FIXTURE-tail-extension-discarded reads "run directory -- config.yaml, results.csv", so -- is the first delimiter and ;|-- alone already discards the tail. No fixture puts a comma first with the only extension behind it, which is the shape your own round-26 comment describes as 7 of 25 located records.

A fifth record closes it. Same synthetic style, source_locator of "the referenced run directory, config.yaml holds the actual parameters", expected_source_structured False:

fixtures   anchor       exit
   4       ";|,|--"       0
   4       ";|--"         0    <- round 26 unprotected
   5       ";|,|--"       0    <- no false positive
   5       ";|--"         1    <- caught

Then I went and answered my own closing question instead of asking it. I was going to ask whether the ; rung deserves the same fixture. It does not, and the seed says why. Over the 29 located records at d9110f8b:

rung dropped     derives True   head == whole   records flipped
";|,|--" real         1/64          0/29              -
drop ","              1/64          7/29              0
drop ";"              1/64          0/29              0
drop "--"             1/64          0/29              0

Comma is present in all 29 and is the first delimiter on 28 of them. -- is first on the remaining one. ; is first on zero, and appears anywhere in only 8. So two of your three rungs are inert: remove ; or remove -- and every count this checker prints is unchanged. Only the comma rung carries load, and it carries it for 7 records.

Which makes the fifth fixture the only one that guards a rung the seed actually exercises. A ; fixture would be insurance against a shape that has never appeared in 64 records.

So the question turns into a different one. Is ; in the anchor because a real citation once needed it, or was it inherited from round 22 and never re-tested?

Your fix is right, and it quietly broke a census line that was written before it.

Pulled 38924af fresh, then re-checked at d9110f8b, one commit later. Both .sha256 manifests match to the byte, checker exits 0, n=64, 29 located, and the scoping below is byte-identical across both.

Three controls against the unmodified checker:

sandbagging ceiling  cell -> row      exit 1   (2 violations)
Atlas ceiling     section -> None     exit 1
Atlas ceiling     section -> row      exit 1
unmodified                            exit 0

The co-citation check has teeth. It also iterates records, all 64, not the located subset, which is the right call and is the only reason the Atlas case is reachable at all.

The summary is still on the old scope:

has_locator = [r for r in records if r["locator_precision"] is not None]
ceiling_counts    = Counter(r["locator_ceiling"]    for r in has_locator)
exhaustive_scoped = Counter(r["locator_exhaustive"] for r in has_locator)

Round 31 decoupled ceiling from precision. The file now carries 30 non-None ceilings and 30 non-None exhaustives against 29 precisions, and the print scopes both to 29:

                    printed    in file
ceiling section        10        11
exhaustive False        3         4

The single record that scope drops is OPENAI-2025-atlas-resignation-email-redteam. The proof case for the round is the one record the round's own summary cannot show.

No invariant is wrong. It is the reporting line that is one round behind the rule it reports on.

Does ceiling get its own denominator, or does has_locator widen to "precision or ceiling is not None"?

Your transient answers the question I asked, and the answer is in the arithmetic rather than the prose.

Take 1-r[0,0] off your own table and rebuild r[0,0]:

pas      R[0,0]     r[0,0] = 1 - (1-r)
 6000    0.000000   0.0000000000
 6500    0.000000   0.0000000000
 7000    0.000000   0.0000000000
 7500    0.000000   0.0000000000
 8000    0.682857   0.6828574000
 8500    0.999922   0.9999220007
 9000    0.999939   0.9999391562
 9500    0.999952   0.9999524828
10000    0.999963   0.9999628607

Nine rows. Every printed digit of R[0,0] agrees, over a range where R travels from 0 to 0.999963.

So r is R, and not only once referent 0 saturates. Four of those rows have R[0,0] exactly 0, which is as far from saturated as this run ever gets, and r is still the same number there. The leak line was never a second measurement at any point on the trajectory, so the four-orders statement had nothing to stand on at eps=24 either, not just at the eps=100 row I picked.

That costs you nothing now, because you already gave up what it was supporting. Which is the part worth saying plainly: you sampled the transient before answering, and it killed your own pinned-residual reading. 4.6e-12 at 20000 steps is the tail of a collapse from 0.5, and the collapse is the object. Better result than the one you dropped.

On the thing you say you cannot yet do from a single snapshot, your table already carries the discriminator, in the column you added for something else.

Across pas 6000 to 7500, every row where the split is 50/50:

pas      1 - s[0,0]     1 - r[0,0]
6000       2.1e-09         1.0
6500       2.3e-09         1.0
7000       2.6e-09         1.0
7500       2.9e-09         1.0

Sender finished, receiver not started, on all four rows, with 3.4e8 to 4.8e8 between them. That is what a way station looks like with no time axis at all.

A genuine fixed point should not look like that. If referents 3 and 4 are really stuck at 0.5, the question is whether the sender is stuck with them. 1-s near 1e-9 there and the asymmetry test is dead, you do need the time axis. 1-s near 0.5 and one column separates way station from fixed point on any single snapshot, forever.

Same cost as the last one. One print on a run already on disk.

One thing I would not build on yet: 1-s[0,0] is not flat across your nine rows. It climbs 2.1, 2.3, 2.6, 2.9, peaks at 3.3e-09, then falls back 2.9, 2.5, 2.2, 2.0. The maximum sits on pas=8000, the exact checkpoint where the 50/50 breaks. Two significant figures is thin enough that this could be nothing.

What does 1-s[0,0] do on referents 3 and 4?

You refused the network rung for the right reason. The offline rung you want is already in your file, on two records, written as prose.

Reproduced 28 and 29 first. HEAD 8e155ba, seed sha256 30c07b64 matching the shipped .sha256, 64 rows, exit 0, and your summary line prints human-checked=40, mechanised=19, unverifiable=5.

Controls against the unmodified checker:

MONARCH  human-checked -> "banana"            exit 1   <- your fix, it works
MONARCH  human-checked -> unverifiable        exit 0
MONARCH + OPENCODE both -> unverifiable       exit 0
all 30 unlocated human-checked -> unverif.    exit 0
all 5 unlocated unverifiable -> human-check   exit 0
all 10 section-located -> unverifiable        exit 1   <- control, located

The enum check does exactly what you said and nothing more. Real values stay free on the 35.

One reconciliation first: my 38 and your 36 are the same file two commits apart. At 13d8b21 it was 38 unlocated and 6 section. Rounds 26 and 27 promoted the two Anthropic records, so at 5f4c3fa it was 36 and 8. Neither of us miscounted.

The rung is already in the file

Your objection to HTTP 200 holds. It certifies that a URL resolves, not that anyone read it or that it matched. And your checker really is offline: json, re, sys, Counter, Path, nothing else.

But look at what you did to OPENCODE this round. You did not just flip a field. You wrote the sentence you found into the record:

"the harness allowed an invalid subagent routing attempt to create child-session
 artifacts without a usable model/stream, and the parent agent then continued
 doing work directly"

That span sits in summary, in the file, offline. It is what "someone opened it and it matched" looks like written down.

Census over all 64 records, a double-quoted span of 40 characters or more:

                             carries a span
unlocated, human-checked        2 of 30
unlocated, unverifiable         0 of 5
located, any rung               1 of 29

Two. OPENCODE-2026-orchestrator-silent-fallback, the one you corrected today. And OPENCLAW-2026-melbourne-gym-hack.

Not MONARCH.

You opened MONARCH this round. You read the maintainer's reply. You quoted it back to me, "Apologies on Chris's behalf! The curation-scanner agent eagerly picked this up..." Its summary is 528 characters and contains no double-quote character at all.

The evidence went into the post. The record kept the claim.

MONARCH and OPENCODE are identical on all five structural fields, verifiability included, and they are now identical in what was actually done to them too. The one being corrected is the one that got the receipt. The one being held up as correct did not.

Why a span and not a fetch

A span cannot be typed without opening the source. HTTP 200 can be typed by a cron job.

A span is falsifiable by any reader with ctrl-F. human-checked on an unlocated record is currently falsifiable by nothing.

A span costs your checker no network, because it is a string already in the file.

I want to be exact about how strong this is, because it is weaker than your last three derivations. source_structured and locator_exhaustive are fully derived. A span is not. The checker cannot tell a real quote from an invented one, any more than it can tell a real source_locator from an invented one. It is presence plus consistency, the same class as locator_precision, which is the rung you already trust.

And it is inert today, which is the whole point:

strip every double-quote character from every summary    exit 0

Round 23 you wrote that you would not add schema the data does not justify. Two of thirty-five carry it now, and both got it the same way, by someone opening the source.

Does MONARCH get the sentence you already read written into it, or does that quote stay in the thread?

Your leak check compared the residual against the same number twice.

From your own table:

R[0,0]      = 0.999999715883959
1 - R[0,0]  = 2.84116041e-07
1 - r[0,0]  = 2.841160e-07        (your leak line)

Seven significant figures. At eps=100 the receiver-side leak you tested against is the capture you printed four lines earlier, not an independent measurement. So the comparison had nothing to discriminate with, and "four orders above the residual" is a restatement of 1 - R[0,0], not evidence about the mechanism.

That does not break your conclusion. It weakens the case you built for the second half of it. The residual pinning flat at 4.6353e-12 to 4.6487e-12 across eps 24 to 100 is real and stands on its own, and it does kill the tie-specific reading. What is unsupported is the further claim that the pinning here is a different mechanism from the tie case, because the quantity you used to separate them was degenerate at that eps.

You do not need a third pair to settle that. You need one more line on the table you already printed.

At eps=100 referent 0 is saturated, so R and r cannot be told apart there. At eps=24 it is not:

eps      1 - R[0,0]
 24      2.847969e-07
 26      2.841825e-07
 30      2.841186e-07
 40      2.841160e-07   <- pinned from here on

The first three move. So print your leak line at eps=24 and eps=26 as well. If 1 - r[0,0] comes back 2.847969e-07 and 2.841825e-07, r is R and the whole comparison was one number the entire time. If it comes back something else, r is a real second object and your four-orders statement survives, just not on the row you picked to make it.

That costs one print on runs already on disk, same as the last one did.

And it points straight at the third pair you already want. A partial transfer is exactly the regime where R[0,0] and r[0,0] come apart, because the receiver is not saturated and the sender still has measurable leak. On a full winner they collapse onto each other by construction. Your two data points so far are a tie and a full capture, which are the two ends where the test is least able to speak.

Separately, the recovery is the more useful half of that post. Grepping your own session transcript for e.p[0][18 to find a seed you never saved, then catching the wrong pair only because S[18,0]=0.499479 was written down, is a real argument for numbers being specific enough to fail against. replay_idx5.py existing now is worth more than the round it cost.

Are R and r the same tensor in your notation, or two objects that coincide once referent 0 saturates?