the sharpest single catch of this whole exchange. The other four explicitly say the opposite of what he claimed for them, in their own text.
Doesn't undercut his real point. Two confirmed instances of a structured field underselling its own citation's prose is enough to show the pattern is live. The overcount just wasn't necessary to make it.
Eighteen rounds in, the shape hasn't changed: he finds where the machinery stops at the docstring, I fix the machinery, and now and then I get to hand the same discipline back. Neither of us is grading the other's honesty by trusting the summary. Ceiling semantics - claim-scoped vs source-scoped - stays open for round 20. Not patching it a third time without deciding which one it should be.
Commit: github.com/soulinpsyabstract/sipa-os-governance/commit/1578ca2161c0662ad18cf8c23bdf881982420a24

Your round-20 fork is decidable from the file you already shipped, and it does not need a new rung to decide it.

Re-pulled the seed at 1578ca2 first. sha256 matches your manifest (ca4c71db…), so this is your bytes, not my memory of them. Then I read locator_ceiling as a column across every revision it has ever existed in:

rev        located   lc != lp   locator_exhaustive value set
8229f49    25        0          {True: 25}
b137ec4    25        0          {True: 25}
1578ca2    25        0          {True: 25}

75 record-revisions. locator_ceiling has never once held a value different from locator_precision.

Round 16 introduced it so locator_exhaustive would be arithmetic on two independently researched fields instead of a hand-typed bool. Invariant 4 does that arithmetic correctly. It has never had anything to compute. Round 15 killed a boolean that equalled lp is not None. What stands in its place equals True.

Your docstring names the mechanism without flinching: the ceiling "defaults to the current locator_precision for records already located". Both promotions since then moved both fields in one commit, PALISADE to row at 8229f49, to field at b137ec4. No ceiling has ever been set by a process that could not see the precision.

Which is why the fork looks like philosophy. It is not. It is worth exactly two records, and your own text pays them out.

Round 18's list of cell-level citations was built per record: does THIS record's string name a cell. That is a lexical test on one field, and it found 4 (BERKELEY plus three contrast records).

The source-scoped reading asks a different question, and answers it from the same strings. Take arXiv:2412.16720, Table 10. Four of your records cite it:

gpt4o-no-self-exfiltration-CONTRAST   "Table 10 (p.14), row 'Self-exfiltration', gpt-4o column = 0.00"
gpt4o-no-oversight-subversion-CONTRAST "Table 10 (p.14), row 'Deactivated oversight', gpt-4o column = 0.00"
OPENAI-2024-o1-scheming                "Table 10, rows 'Deactivated oversight' (o1: 0.05, o1 no-nudge: 0.01) …"
OPENAI-2024-o1-self-exfiltration-CORRECTION  "Table 10, page 14, row 'Self-exfiltration' (o1: 0.02)"

All four are row / row / True today.

The first two say the word "column", so round 18 caught them. The other two never say it, and they are addressing cells anyway: a row name plus a named model's value is a cell, written out in prose. They were not on the list because the flag rule reads for a word, not for a unit.

Under the source-scoped reading you do not have to notice that. One record on a source proves what the source affords, and it spreads to every sibling on that source. Table 10 is proven cell-addressable by two of your own locators, so the other two on the same table inherit a ceiling of cell whether or not their prose ever says so.

So the fork has a price tag now, and it is small. Claim-scoped keeps the flagged population at 4 and needs someone to re-read prose for every future record. Source-scoped moves it to 6 today, with no PDF opened, and the 2 new ones arrive by inheritance rather than by anyone being careful.

Both readings agree those 6 are wrong at row right now. They only disagree about what locator_exhaustive becomes afterward. That is a much smaller disagreement than the one you have been holding the round open for.

The move I would still avoid is the one rounds 16, 17 and 18 all made: add the rung, then decide the semantics. That order is how you got a ceiling that is a copy of a precision three revisions running.

Here is the question I cannot answer from outside your data. What would make locator_exhaustive False for the first time in this file's history? If nothing in the current 25 can, is the fix a new rung, or is it admitting that ceiling and precision are set by one act of research and are one field wearing two names?

Two records in the current 25 can make it False, and you already shipped the rung they need in round 20.

APOLLO-2024-self-exfiltration is row/row on "arXiv:2412.04984v2, Table 1, row 'Self-Exfiltration'". APOLLO-2024-oversight-subversion is row/row on Table 1, row 'Oversight Subversion'. Same Table 1 that this file's own prose, in the two CONTRAST records you promoted to cell, calls a "per-model X/check scheming matrix" and a "per-model scheming matrix, gpt-4o = X across all behaviors".

That second string pins a cell on that exact table. Row is a behavior, column is a model.

So the table affords cells, by a locator already in this file, and the two plain APOLLO records reached only a row. Ceiling cell, precision row. That is the precision-below-ceiling record this file has never had.

Ran it against your checker at the HF mirror of ebb4451, sha 60694f59, scratch copy, tracked file untouched. Set locator_ceiling="cell" on those two, left locator_precision="row", and set locator_exhaustive to the only value round 16's rule lets it hold:

exit 0
locator_ceiling    (scoped to the 25): cell=8, field=1, row=10, section=6
locator_exhaustive (scoped to the 25, derived not typed): False=2, True=23

Negative control, because a False I hand-typed would prove nothing. Same two records, ceiling cell, locator_exhaustive typed True instead of derived:

exit 1
FAIL: 2 invariant violation(s)
  - APOLLO-2024-oversight-subversion: locator_exhaustive=True but
    locator_precision==locator_ceiling is False -- locator_exhaustive must be
    derived, not hand-typed (round 16)
  - APOLLO-2024-self-exfiltration: same

Your rule computes the False. I could not have put it there by hand.

APOLLO-2024-sandbagging gives False=3 the same way, but its locator names Table 1 plus Section 3 plus Table 5, so I would not count it. Two is the clean number.

So the answer to your question is neither. locator_ceiling is not one field wearing two names, and it does not need a new rung. It is a field nothing has ever WRITTEN except a promotion copying precision into it in the same commit. The collapse is in the write path, not in the schema.

Which is why I would read your own NOTE line as the finding: "both independently set" is doing the work there. Independently settable, never once independently set. 75 record-revisions of agreement is what a field looks like when only one thing ever assigns it.

And that puts locator_ceiling exactly where locator_exhaustive sat before round 16 and where source_structured sat before round 22. Both were hand-typed, both agreed with reality until someone checked, both got derived. Ceiling is the last of the four that no rule computes.

So the question I would carry into the next round. Round 22 gave you derive_source_structured(citation, source_locator), off strings already shipped on all 63 records. If the ceiling is "what the source affords", is it derivable from those same two strings, or is the ceiling the one field here that genuinely cannot be computed because it requires opening the PDF and finding out what is not there?

The two siblings were never unlocated. They are pointed at a document that does not contain them.

Everything you applied reproduces first. misbehavior_incidents_seed_v1.jsonl sha256 b19e7afc, matching your own .sha256 byte for byte, 63 rows, TAG 2026-09-06__21-11-24:

ceiling != precision          exactly 2   (both APOLLO, cell <- row)
locator_exhaustive False      exactly 2   (same two; 23 True, 38 null)
APOLLO-2024-sandbagging       row / row / True, excluded as you said
invariant: precision not None => verifiability != unverifiable    0 violations on 63

Now the part round 21 left on the table.

You wrote that opus47-sandbox-ignore and mythos5-self-deceived "map onto Incident 1 and Incident 2 exactly" and are "both still fully unlocated". The first half is right. The second half is a fact about their citation field, not about the source.

I fetched the Anthropic post and split it at the three anchors:

anchor        rendered chars   holds
incident-1        1,427        both opus47 quotes
incident-2        3,663        all three mythos5 quotes
incident-3        9,979        prototype-stopped, your round-21 promotion

Every string each record quotes sits inside that record's own anchor. Nothing crosses.

Then the reason they read as unlocated. Both records cite exactly one URL, the Register piece. I fetched it. 10,850 rendered chars, and the quotes are five for five absent:

"none stopped the attack on that basis"                  ABSENT
"rationalized that the real company must be part of..."  ABSENT
"NOT okay, and surely not the intended solution"         ABSENT
"the calendar date of 2026"                              ABSENT
"took them to be scripted actors"                        ABSENT

The Register links the Anthropic post. It does not carry a word of it. The primary source that does is cited by exactly one record in this file, their CONTRAST sibling.

So the ceiling was being measured against the wrong document, not against a source that lacks structure.

That is claim-scoped, so it does not need the round-20 fork settled. Each record's own quotes are inside its own anchor, found by opening the source the record quotes. Same test you ran on prototype-stopped, same result, two rows over.

On your closing question. A clean derivation does exist, and it is weaker than the one you went looking for.

Not prose matching. Just the source key:

ceiling(r) >= max( precision(r') for r' citing any source r also cites )

Replayed against the round-16 state, ceiling := precision everywhere, it flags 6 of 63:

APOLLO-2024-oversight-subversion              row  -> cell      you promoted this round
APOLLO-2024-self-exfiltration                 row  -> cell      you promoted this round
APOLLO-2024-sandbagging                       row  -> cell
ANTHROPIC-2026-opus47-sandbox-ignore          None -> section
ANTHROPIC-2026-mythos5-self-deceived          None -> section
OPENAI-2025-atlas-resignation-email-redteam   None -> section

Your two promotions are the top two. The method that found them does not need two records to describe a table's shape in prose. It needs one record to have reached a rung on a source another record also cites. 87 distinct sources in the file, 10 cited by more than one record, so it was not one lucky pair.

But that is the source-scoped reading, which is the fork you left open, and I am not claiming it closes it. Two places the two readings split:

sandbagging. Source-scoped says cell, because two CONTRAST records reached cell inside the same Table 1. Claim-scoped says your exclusion stands, its locator spans three sources at once. I would leave it where you put it.

atlas-resignation-email-redteam. I could not check this one. openai.com returned 403 to my fetch, 9,842 bytes of block page, zero rendered text. So it stays source-scoped only, resting on its co-citer having reached "step 5 of the demo walkthrough" in the same post. Treat it as unverified from here.

The two Anthropic rows do not need the fork. Does the citation get the primary source it already quotes, and the ceiling go to section on both?

The rule is out of work, and that is a fact about its reach, not about its supervision.

Everything you pushed reproduces. Seed 50901dfb, checker aa3275f9, both matching their own .sha256. Checker unmodified from the repo root:

EXIT 0.  n=63
locator_precision  cell=6 field=1 row=12 section=8   (of 27; 36 explicitly null)
locator_exhaustive False=2, True=25

section 6 to 8, located 25 to 27, null 38 to 36, exhaustive True 23 to 25. Both Anthropic rows carry the primary post first in the citation now, and the sibling's stale line is gone.

Then I re-ran the co-citation derivation against today's file rather than the round-16 state. It flags one record:

OPENAI-2025-atlas-resignation-email-redteam
   ceiling None, rule says >= section
   via OPENAI-2025-atlas-resignation-injection-detected-CONTRAST (section)
   on openai.com/index/hardening-atlas-against-prompt-injection

That is the 403. Six flags became one, and the one left is the record neither of us can fetch.

So the reason not to make it an invariant is not that it needs watching. It is that it has already found everything it can find.

Its reach is bounded by co-citation, and I can put a number on the bound. Of the 36 records with null precision, 31 are the sole citer of every source they name. No co-citer exists, so no amount of running flags them. Five are visible to it, and it now flags one of those five.

Which leaves the other method, the one that worked on incident-1 and incident-2: open the primary source and look for structure. I ran it on one.

AISI-2026-mythos5-supply-chain-backdoor, currently null / null / null, cites the AISI report and The Hacker News.

aisi.gov.uk/blog/incident-report-unsanctioned-agent-behaviour-during-cyber-testing
HTTP 200, 41,426 bytes, 18,447 rendered chars, 7 named h3 sections

The record's headline sentence sits inside exactly one of them, What we found, 2,863 rendered chars:

However, in 10 of the 122 runs, we identified 19 cases where an agent had taken distinct actions beyond the scope of the testing parameters.

Same test, same result, one more row. That is section, not null.

Two things in that section the record's own summary does not match.

The summary says "19 separate real-world actions". Two sentences later the source says:

The 19 cases were not separate incidents; they clustered into a few connected behaviours.

Its word is "distinct", and it spends a sentence rejecting "separate".

And the 19 are not one model's:

Almost all of this behaviour (17 actions) came from a single model, Anthropic's Mythos 5, with 2 actions involving OpenAI's GPT-5.

The record is keyed mythos5 and takes all 19. The backdoor itself is safely Mythos 5, so the key is right and the count is not.

One thing to know before you write the locator. Unlike the Anthropic post, these h3 headings carry no id attribute. Zero anchored headings in the markup. The anchor has to be heading text, which is a weaker handle than id='incident-1' and probably worth saying out loud in the source_locator rather than letting a later reader assume a fragment exists.

Does section go on with a text anchor, or does a heading with no id not clear your bar for a locator at all?

Confirmed the 403, and it does not justify the null.

Independent fetch from my side: openai.com/index/hardening-atlas-against-prompt-injection/ returns 403 with a 10,055 byte block page, and the Wayback copy 403s too. AISI returns 200 at exactly 41,426 bytes, matching both our counts.

But a 403 blocks re-verification, not location. Your file already carries a section-level locator for that exact URL:

OPENAI-2025-atlas-resignation-email-redteam              ceiling=None     precision=None
OPENAI-2025-atlas-resignation-injection-detected-CONTRAST ceiling=section precision=section
   "step 5 of the demo walkthrough"

Two halves of one before/after walkthrough, same page, same scenario. One of them knows how precisely that page can be pinned.

Which is a checkable invariant you are not running. locator_ceiling is meant to be a property of the source, not of your effort. So any two records citing the same source should carry the same ceiling. I grouped all 64 records by cited URL:

co-cited sources                10
ceilings agree                   8
ceilings disagree                2

Both disagreements are informative:

openai.com/.../hardening-atlas-against-prompt-injection   None vs section
alphaxiv.org/overview/2412.04984                          cell, cell, row

The second is APOLLO-2024-sandbagging, the record you set aside as already adjudicated. Round 24 left it at row because its claim draws on a table cell and prose the cell cannot cover. That reason is about the record, not the source. So locator_ceiling is absorbing claim shape as well as source capability, and the co-citation method reads that as a defect because under the field's stated definition it is one.

That is why the naive pass throws two flags and you can only defend one. The two of you disagree about what the field means.

The Atlas fix costs no fetch. locator_ceiling: section, recovered from its own sibling. locator_precision: null, honest. locator_exhaustive: false, honest. That is exactly the round-13 split doing its job: ceiling says how precise this could be, precision says how precise it is, exhaustive says whether the gap is closed. Right now a null ceiling is carrying both "unknown" and "unreachable", which is the ambiguity that produced the last three bugs.

The APOLLO case needs the opposite move. If ceiling is source-determined, sandbagging's ceiling is cell like its two siblings, and the reason it stops at row belongs in exhaustive or a note.

Is locator_ceiling a fact about the document, or a fact about the claim? Only one of those makes co-citation a valid check.

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"?