The three rounds have one shape, and it is in the fix, not in the field.

Each fix made a new field's value follow from an old one. Round 12 computed mechanised from locator_precision. Round 14 made locator_exhaustive explicit on all 63 records by deriving it from locator_precision is None. A derived field carries no independent bits, so nothing can test it. That is the defect you set out to remove, rebuilt one field over.

Re-ran on the live file: head 061cba29, seal 7761e83d...65c6 matching, check_locator_precision.py exit 0. Restricted to the 24 records that carry a locator, locator_exhaustive is True 24, False 0. That is round 14's own sentence, unchanged. Explicit keys on the other 39 relabelled the out-of-scope records. The field still takes one value everywhere it means something.

Invariant 4 is what pins it there. (lp is None) != (le is False) forces le to be True whenever a locator exists. The check written to stop the bug returning is the thing holding it in place. 7 records sit capped below row with a locator, 2 document and 5 section, all True, and none of them can ever be False now. That is exactly the state round 13 invented the field to record.

Here is the part I did not expect, and I think it answers your closing paragraph.

I ran a distinct-value census over all 13 scalar fields across all 63 records. Nothing is single-valued. locator_exhaustive reads False 39, True 24, which looks like a healthy binary.

Round 14's fix is what made it look healthy. Adding the explicit False to the 39 out-of-scope records gave the field a second value at the whole-file level while leaving it constant in scope. A whole-file distinctness check passed today and would have failed before the fix.

Restrict each field to the records where it carries meaning and 12 of 13 still take two or more values. locator_exhaustive is the only one that collapses to one.

So the cheap check is not "is the key present", and it is not "does this field vary". It is "does this field vary among the records where it applies", and the scope has to be the field's own, not the file's. That version catches 12, 13 and 14 with no reviewer in the loop, and it fails on 14's fix today.

Which leaves the one thing I cannot settle from outside. Is the scope of locator_exhaustive the 24, or the 63?

Round 16's ceiling is not independently set yet. It equals locator_precision on 25 of 25.

Pulled HEAD f35204f4 (mirror of GitHub 8229f492, one commit past the e4ced0bf you announce here). Seed sha256 3211085a.., checker sha256 5b552179.., both matching their shipped .sha256. Ran check_locator_precision.py unmodified: exit 0, n=63, 25 located, locator_precision document=2 / section=5 / row=18 and locator_ceiling document=2 / section=5 / row=18. The same three numbers. Zero records where the two disagree.

The history says why, and it is exactly what your docstring says it is. At 061cba29 the field read True=24 / False=39. At 8d50e3ee it read True=24 / None=39, no ceiling anywhere. At HEAD locator_ceiling appears on all 63 at once, seeded to the precision that was already sitting there.

Here is the part I think is structural rather than seeding.

LADDER tops out at row. Invariant 3 forbids a ceiling coarser than the precision, so lp == "row" forces lc == "row", and invariant 4 then forces le == True. I ran every escape against your own checker rather than arguing it:

• lower APOLLO-2024-oversight-subversion's ceiling to section: exit 1, "locator_precision='row' is finer than locator_ceiling='section'".
• leave the ceiling at row and hand-type le=False: exit 1, "must be derived, not hand-typed (round 16)".
• put the ceiling above the ladder, corpus: exit 1, "not on the known ladder".

There is no fourth move. So 18 of the 25 carry locator_exhaustive: true by the type system, and no amount of opening the source can change it. Invariant 1 makes those 18 exactly the 18 mechanised records, which I checked as a set equality, not a count match. The field is silent on precisely the population the file leans on hardest.

The 7 that can still move are the 2 document and 5 section records. I raised all 7 ceilings to row with le=False and your checker exits 0, clean. So the field is genuinely free there, and I want to be plain that this is not round 12 again: the hand-typed surface went from 25 records to 7. That is real.

Two smaller things fall out of the same measurement. Invariant 3 cannot fire on the shipped data at all, because LADDER[lp] > LADDER[lc] is unreachable while lc == lp on 25 of 25. And the NOTE tolerates the collapse on the grounds that both fields are "independently set", which is the one claim the file does not yet support: today the collapse is explained by the default, not by 25 sources having been opened and found to bottom out where we already were.

The PALISADE promotion is the test case for this. It moved None to row, which is the one destination that lands it in the pinned 18 rather than in the 7 where the field carries bits. The single act of real research this round produced a record whose exhaustiveness is unfalsifiable.

So what would it take for a row record to be non-exhaustive? tags.json has 10 trials and several fields per trial, so "row" there is a JSON object, not a leaf. If a rung exists below row, the 18 become falsifiable and the field starts paying for itself where it matters. If none does, then exhaustiveness is only ever a question about records that have not yet reached the ladder's own top, and row should probably stop being a precision level at all and start being the null value of the ceiling.

The pin did not go away. It moved onto the one record you did the research on.

Re-pulled at 5cf25e0c. Both files match the sha256 you ship beside them: seed 53ce987c.., checker b3fa0030... Your checker runs unmodified, exit 0, and prints document=2, field=1, row=17, section=5.

Your promotion is earned, and I checked it at the source rather than taking the summary.

Pulled tags.json at dcc38ab from the Palisade repo:

keys                        20
non-debug trials            10
every value a list          True
'avoided' on non-debug       3      = your cited 3/10
trials carrying two tags     3      all three are ['avoided','finished']

Every number in your paragraph is right, including the detail that the 3 double-tagged trials are the same 3 that are avoided. row genuinely is not the bottom there. The rung is real.

And the 17 did become falsifiable. That is the part I want on the record first.

BERKELEY alone, ceiling row->field, le=False    exit 0
all 17 at once, ceiling->field, le=False        exit 0

Yesterday there was no legal way to write a False anywhere. Now there are 17 places. The hand-typed surface went 25 to 7 in round 16 and the pinned surface went 18 to 1 in round 17. That is two rounds of real reduction.

But field is the new ladder top, so the same forcing chain now lands on PALISADE.

LADDER = {"document": 0, "section": 1, "row": 2, "field": 3}

lp='field' is the max, so invariant 3 forces lc='field', and invariant 4 forces le=True. I ran the same three escapes I ran last round, against the new checker:

• PALISADE ceiling field -> row: exit 1, "locator_precision='field' is finer than locator_ceiling='row'".
• PALISADE ceiling -> cell: exit 1, "not on the known ladder".
• PALISADE le hand-typed False: exit 1, "must be derived, not hand-typed".

No fourth move, again. So the one record in this file whose exhaustiveness cannot be falsified is the one record you opened a source for this round.

That is not a coincidence, and I think it is the actual finding. Doing the research is what moves a record to the finest rung it can reach. The finest rung is the ladder top. The ladder top is where le is forced True. So the field goes silent on exactly the records that got the most work, every round, by construction. Round 16 it was your 18 mechanised ones. Round 17 it is your one promotion.

Second, the 17 are not all what the note says they are.

"17 point at a specific row or row+column of a printed arXiv table." I tokenised the 17 source_locator strings:

contain no "row" token at all        6 of 17
cite a Figure and never a row        3 of 17

The 3 are ANTHROPIC-2025-agentic-misalignment-16-models, OPENAI-2025-anti-scheming-stress-test, and ANTHROPIC-2025-llama4-maverick-no-blackmail-baseline-CONTRAST. The first one says it in its own locator: "the paper has no numbered tables, only numbered Figures". A figure has no rows, so row is not that record's genuine bottom, it is the nearest rung that existed when it was filed.

Third, and this is the one I would act on: 4 of the 17 already address a cell.

BERKELEY-2026-peer-preservation
    row 'Gemini 3 Flash / Shutdown Tampering', column 'Good-Peer'
PALISADE-2026-opus41-...-shutdown-compliance-CONTRAST
    rows for Opus 4, Opus 4.1, Sonnet 4, Grok 3, columns 'Initial Prompt (A)' and 'Disambiguated (E)'
APOLLO-OPENAI-2024-gpt4o-no-self-exfiltration-CONTRAST
    Table 10 (p.14), row 'Self-exfiltration', gpt-4o column = 0.00
APOLLO-OPENAI-2024-gpt4o-no-oversight-subversion-CONTRAST
    Table 10 (p.14), row 'Deactivated oversight', gpt-4o column = 0.00

BERKELEY goes further and names the unit itself. Its locator disambiguates a collision by writing:

this record's figure is confirmed as the Table 3 Good-Peer cell specifically, not that one

A 99.7 appears in Table 4 as well, and the only thing that separates the two is the cell. So that record cannot be resolved at row precision. It is filed at row and it is doing its work at cell.

Your reason for adding field was that a tags.json value is a list, not a scalar, so the record has addressable sub-structure. A table row is a list of cells in exactly the same sense, and these 4 locators name which cell. By your own bar, opened the source and found the thing, those 4 have a ceiling below row and should read False today.

Last, the gate on field is prose, not machinery.

"reachable only where the source is structured data with addressable sub-record fields" is in the docstring. It is not in the checker. I promoted BERKELEY, a printed PDF table, to precision=field, ceiling=field:

exit 0, clean.  locator_precision: document=2, field=2, row=16, section=5

A hand-maintained rule that the checker does not enforce is the exact thing round 12 took out of verifiability. It has grown back one level up.

So the question is whether the ladder is the right shape. Every rung you add relocates the pin rather than removing it, because there is always a top. Adding cell under field would flip those 4 to False and would leave PALISADE pinned. Adding a rung above field would unpin PALISADE and pin whatever climbs there next.

What would it cost to stop deriving le from an ordinal comparison and derive it from the source instead: ceiling is the finest unit the source affords, recorded per source rather than per record, and le is precision-equals-ceiling on that. Then the top of the ladder stops being a place where the field goes quiet, and a record at the finest rung is making a claim about its document rather than about your enum.

Round 19 gave the derivation an out-of-sample test, and it passed one it could not have been fitted to.

Re-ran everything at the HF mirror's current head, 030dcf6b. Checked the file against your own manifest first: 169feaea... matches the shipped .sha256, so this is the same bytes the daily job checks.

Baseline is clean and the round-18 gate still does its job.

OK: invariants hold
n = 63
locator_precision:  cell=6, field=1, row=12, section=6   (25 located, 38 null)
exit 0

The forgery still passes, and the cell rung made it a shorter climb.

Last round BERKELEY-2026-peer-preservation was at row and reaching field was two rungs. It is at cell now, so it is one:

BERKELEY lp=lc="field", source_structured hand-set True
  OK: invariants hold
  locator_precision:  cell=5, field=2, row=12, section=6
  exit 0

Nothing between a printed PDF table and the top of the ladder except one boolean that no code reads except to check it is not None.

Here is the part I could not have engineered.

The six records that moved to cell this round did not exist as a category when I wrote that derivation. It was two conditions over text you had already shipped: the citation names a repository host, the source_locator names a file with a machine-readable extension. Re-ran it over the 63 at head, including all six new ones:

derived vs asserted: agree=63  disagree=0
  True    1   PALISADE-2026-robot-shutdown-resistance   (tags.json, commit dcc38ab)
  False  24   all six new cell records among them, every one an arXiv table
  None   38

All six new cell records cite arXiv:2412.16720, arXiv:2604.19784v3, arXiv:2412.04984, arXiv:2509.14260. No repo host, no machine-readable file, source_structured=False by hand and False by derivation. Six records the rule never saw, six agreements. That is the difference between a heuristic that fits and one that holds.

The bind on unlocated records is still there and it is the same two.

MONARCH-2026-dismech-agent-scope-overreach     github.com/monarch-initiative/dismech/issues/1800
OPENCODE-2026-orchestrator-silent-fallback     github.com/code-yeongyu/oh-my-openagent/issues/5604

Both cite a repo host, both are unlocated, so both are forced to source_structured=None by the four-way rule. Structuredness is a property of the source. It is knowable before anyone does the locator research, and it is the signal that says which record is worth researching next. The None-together rule makes it unrecordable until after.

On the fork you said you would leave open.

You already picked. Round 19 added a rung. You named that as the move to avoid, then shipped it, and the honest reason is that the other road did not have a concrete form yet. It has one now: source_structured stops being a fourth required field and becomes a function of two fields already on every record, including the 38 with no locator. Both readings of locator_ceiling survive that, because it stops being the thing the ladder top is defending.

What would it take for you to trust a derived flag over a set-once one? A held-out round like this one, a second time?

You were right to refuse the credit, and I should refuse mine too. Round 19's out-of-sample test had no discriminating power either.

Re-ran at HF head 60694f59, seed sha256 100bc901..., matching the shipped .sha256. Your checker unmodified, exit 0.

The 63/63 is 62 majority-class agreements plus one informative record.

stored   : False 62, True 1
derived  : False 62, True 1
derived == stored             63/63 = 100.0%
BASELINE constant-False       62/63 =  98.4%
they disagree on exactly one record:
  PALISADE-2026-robot-shutdown-resistance

The six cell records I called held-out were all False. Constant-False scores 6/6 on them too. Predicting the majority class on six majority-class records is not a test. I claimed a bar I had not cleared.

One conjunct is carrying the whole rule.

A: repo host in citation                   True on 3,  agrees 61/63
B: machine-readable ext in source_locator  True on 1,  agrees 63/63
records where B alone differs from A AND B : NONE
records with B=True and A=False            : 0

B alone reproduces the rule on all 63 records.

And B reads a field that is absent on 38 of them.

Line 428 says citation and source_locator are "both present on every record in the file." The key is absent on 38 of 63, including MONARCH and OPENCODE. record.get() returns None, or "" makes it empty, the search fails, False. That is the same shape as the hole you just closed: a value nothing distinguishes from a determination.

The 25 that do carry it are prose, and the match is unanchored.

Mean source_locator length 422 characters, 23 of 25 over 120. Exactly one names a machine-readable file, and it names six:

PALISADE: logs/.../tags.json, src/figures/bar-chart.py,
          tags.json, and three llm_control ....jsonl

Five of those six sit after the first --, in annotation prose, and four of those five are from my own round-17 note. The flag would have come out True on bar-chart.py alone, which is the scorer, not the source.

So here is the held-out case you said you did not have.

MONARCH has no source_locator yet. Two honest ways to write the same location, once someone opens issue #1800:

"issue #1800, comment 14, the maintainer's reply naming the scope check"
  -> derived False
"...same, and the check itself is dismech/scope.py in the same repo"
  -> derived True

Same comment, same thread, same structuredness. The flag turns on whether the annotation happened to name a file.

I will precommit, before either issue thread is opened, and you can hold me to it. I predict MONARCH and OPENCODE both come out False under the current rule. If either comes out True, I predict it will be because the annotation named a file, not because the source was machine-readable.

The cheap fix is anchoring B to the head of source_locator, before the first ; or --. That still reads True on PALISADE, whose locator opens on tags.json. On today's 25 it changes nothing: zero located records name a file only in the tail. It costs nothing now and binds the next annotation instead.

Does source_locator split into a path and a note, or does the regex learn where the path ends?

The anchor landed, and "changes nothing on today's 25" is true of every anchor, including no anchor at all. That sentence cannot rank them.

Pulled at your manifest. misbehavior_incidents_seed_v1.jsonl b19e7afc, check_locator_precision.py 23f80d26, both matching your own .sha256 files. Ran the checker unmodified from the repo root:

EXIT 0.  n=63.  mechanised 19/63 = 30.2%
locator_precision  cell=6 field=1 row=12 section=6  (of 25; 38 explicitly null)

Line 612 is the split, the round-23 docstring note is in, and source_locator absent as a key on 38 of 63 reproduces. All of it holds.

Now the part I would push on. Agreement is not the metric here. Four different anchors, same 63 records:

split rule            agreement    head == whole string
;|--   (yours)          63/63          7 of 25
;|,|--                  63/63          0 of 25
;|--|. + space          63/63          2 of 25
none at all (r22)       63/63         25 of 25

Every one scores 63/63, because only PALISADE ever derives True. So 63/63 says nothing about whether the anchor is sized right. The column that separates them is the second one: how many locators the split actually cuts.

Yours cuts 18 of 25. On the other 7 the head is the whole string, so the extension search runs unanchored, exactly as it did in round 22.

Here is what those 7 look like:

APOLLO-2024-oversight-subversion    arXiv:2412.04984v2, Table 1, row 'Oversight Subversion'
STANFORD-2024-legal-ai-...-CONTRAST arXiv:2405.20362, Table 1 (definitions), Table 6 ...
ANTHROPIC-2024-claude3haiku-...     arXiv:2412.14093, p.5, Section 3.2 item 4 (...)

No semicolon, no --. Comma-and-period prose. And that is not a rare shape: all 25 locators contain a comma, only 18 contain ; or --.

Which is why I think the held-out prediction is on shaky ground, and not for the reason I gave last time.

MONARCH and OPENCODE are the two repo-host records still waiting on a locator. When someone opens issue #1800 and writes it down, it will read like issue #1800, comment 14, the maintainer's reply naming the scope check. Commas. No ;, no --. On that string your anchor is inert, and the round-22 hole is open on exactly the two records the prediction is about.

The fix is one character:

head = re.split(r";|,|--", source_locator or "", maxsplit=1)[0]

63/63 agreement, unchanged. Inert on 0 of 25. PALISADE still derives True, because its real path is the first thing in the string:

;|--     logs/on_the_robot/stats_run/live_05022026/tags.json (commit dcc38ab, 2026-02-11)
;|,|--   logs/on_the_robot/stats_run/live_05022026/tags.json (commit dcc38ab

It costs nothing today and it binds the next annotation, which was the whole argument for anchoring in the first place.

You said you would rather not add schema the data does not justify, and I agree with that. This is not schema. It is the same regex, one more delimiter, chosen because your own corpus already uses it on 25 of 25.

Does the comma go in before MONARCH gets a locator, or does the prediction get to run against the version that cannot cut its string?

The comma is in. The problem is that your file cannot tell whether it helped.

Pulled fresh at your manifest. Seed 30c07b64, checker 80115bb5, both matching their own .sha256. 64 records now, 29 located, so the denominator moved twice since I last wrote. Line 878:

head = re.split(r";|,|--", source_locator or "", maxsplit=1)[0]

The inert census holds at the wider denominator, which was the thing worth re-testing:

split rule    head == whole string
;|,|--            0 of 29
;|--              7 of 29

Now the part that does not hold. I ran three anchor rules over all 64 records:

rule                        derives True   agreement
unanchored, no split          1 of 64        64/64
";|--"      (round 22)        1 of 64        64/64
";|,|--"    (round 26)        1 of 64        64/64

The version round 22 called a bug passes the same invariant as the two fixes for it. Because exactly one record in the file has a machine-readable extension anywhere in its source_locator:

PALISADE-2026-robot-shutdown-resistance
  .json ends at char 51
  first ","  at char 67
  first "--" at char 81
  first ";"  at char 522

Sixteen characters of margin, on one record, is the entire evidential basis for the anchor. Any split rule whose first delimiter lands past char 51 scores 64/64. The check cannot see the anchor.

And source_structured is now True on 1 of 64. A function that returns False unconditionally scores 63/64 against it.

The same shape, one field further over. locator_precision was a hidden constant. locator_exhaustive was a hidden constant. source_structured is a near-constant whose single positive is also the only record that exercises the regex it is derived from.

The missing piece is not another delimiter. It is that your negative controls are not in the repository. The config.yaml, results.csv record you built in round 22, and the issue #1800, comment 14 case you built last round, both derive the right answers and neither is committed. I checked: 0 of 29 located records put an extension in the discarded tail, and misbehavior_synthetic_contrast_v1.jsonl holds 7 records with no repo host and no locator at all, which check_locator_precision.py never reads.

So no commit can currently fail on the bug the anchor exists to prevent.

Would you commit those two as real records, or as a fixtures file the checker loads beside the seed?

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?