Central New Jersey answers the density question; southern New Jersey has no retail surface to read

[gunbai-bot]

What this is

The colo census extended to central and southern New Jersey. Every facility is a ColoFacilityRow with a CabinetDensityClaim beside it, populated from extdeps.colo.types — no second carrier was minted for any of the five row shapes, which is the §3 fork this census exists to avoid.

THE TWO NUMBERS

facilities modelled (central NJ)	8
facilities whose density could actually be READ	4
of those, reachable by a medium-qualified request	1
southern NJ	SurveyedNoRetailOperator — a typed measurement, not an empty region

The second number is the answer. Derive it rather than trust this table: the arm on each of the eight rows named in gunbc.colo_census_coverage central_new_jersey is DensityPublished or DensityUnread, and nothing else decides it.

Read (4): databank_ewr2_density, njfx_wall_density, digital_fortress_piscataway_density, iron_mountain_nje1_density.
Unread (4): qts_piscataway_density, digital_realty_ewr11_density, digital_realty_ewr12_density, three_sixty_five_bridgewater_density — each carrying the obligation that says what was fetched and what the page did not publish. Facility megawatts, square footage, a peer site and the operator's other locations were all available for every one of these four, and none of them is a cabinet density.

The third number is the finding. Of the four read figures, exactly one — DataBank EWR2, on the operator's own printed word "Air" — carries a published cooling medium. NJFX, Digital Fortress and Iron Mountain publish a real per-cabinet figure and name no medium, so they sit at CoolingMediumUnspecified and no medium-qualified request can reach them: density_figure_for_medium returns RequestedMediumAbsent, not a figure. They are inventoried and unscreenable, which is the honest state and not a gap to be closed by inference. The same 1-of-4 ratio appeared independently in the New York lane — two lanes, same ratio, so it is a property of what operators publish rather than of either lane's reading.

One more grain: Iron Mountain's figure is WordingSummarized, not WordingVerbatim — the 2026-09-08 read went through a summarizing fetch tool and the 2026-09-09 raw re-fetch was blocked (HTTP 429 behind a security interstitial). The block is recorded as the reading; the silence is not mistaken for absence.

Evidence

Six witnesses in test.claim.colo_nj_central_south_census_test, all re-keyed onto the #10888 carrier and all executed after the re-keying — a re-keyed control that has not been run is a translation, not a check.

Two mutations, each against a baseline first proven to produce verdicts (an empty result is not a pass):

• EWR2 CapabilityAtLeast → MarketedAtMost reds only w_a_capability_floor_supports_from_below_and_never_bounds_above. databank_ewr1_density shares EWR2's exact wording and figure, so it was left untouched and the red attributes. This is the backwards reading — a 10kW+ floor read as a ceiling — that stood green for two days in this PR before Evidence belongs to the figure, and a lookup that picks is a lookup that widens #10888 gave it an arm.
• NJFX CoolingMediumUnspecified → CoolingMediumPublished { medium: AirCooling } reds only w_an_unlabelled_figure_is_inventoried_but_unscreenable. That mutation is precisely the fabrication this census forbids, so a control that stayed green under it would be decoration.

No transcribed count

central_new_jersey carries no facility_count and no density_read_count. It names its eight member facility rows and their eight density rows, so the numbers above are an identity join over the roster rather than a literal anyone has to remember to update. An earlier revision of this PR did transcribe the count; review 63095 confirmed the join is what stands now, and this section previously declared a debt the row no longer carries.

Failure modes filed

• a_positive_control_certifies_the_defect_it_exists_to_catch — new, five specimens.
• unread_arm_missing_on_a_secondary_axis — adjudicated against its own trigger after Evidence belongs to the figure, and a lookup that picks is a lookup that widens #10888: the forced half is now structurally impossible, the chosen-wrongly half survives as mechanically preventable and newly decidable. Not claimed as structural impossibility, because whether a page names a medium is a fact about external prose.

🤖 Generated with Claude Code

https://claude.ai/code/session_016jFtgPtXxTj1kE8wwZUNsG

[gunbai-bot]

Fixed in 573f2b4, review 62744 accepted in full.

All three prose-only NonEmptyStr rows are gone — databank_newark_obligation,
digital_realty_ewr19_obligation and njfx_tata_adjacency_obligation are now // annotations
above the declarations they qualify. You were right on both counts: §4c makes a String declaration
whose sole purpose is commentary misplaced data, and §3c makes it red that nothing read them.

I took the annotation arm rather than the UnmodelledFacilityObligation arm you offered, and the
reason is your own §3c point turned around: three to-dos do not justify a new type, and a carrier
consumed only by a witness written to consume it would be dangling with extra steps. Nothing is
lost — each note now sits directly above the row it qualifies, where a reader of that row finds it.

Two things this pass also changed, unprompted by the review but worth flagging since they touch the
same rows:

• databank_ewr2_density's claim_wording was "10kW+", and a raw-byte fetch shows the page's
  cell is 10kW+ Cab Density Air. My row carried a truncation of the operator's own text. The
  figure is unchanged and the correction is a gain: the operator's word AIR now selects the
  air-only arm rather than that arm being inferred from a missing liquid figure. All three read
  wordings in this PR are now verified literally against saved bytes, and each figure's nearest
  heading in byte order checked to confirm it scopes to the facility being modelled.

• gunbc.colo_census_coverage carried five §4c parse errors — annotations indented between the
  arms of RegionSurveyOutcome, where only module-item grain is modelled — which reddened
  compilation for anything importing it. Hoisted above the type, intact.

— sent from bright-swift-678

[gunbai-bot]

Review 62769 addressed in a1f83f3 — one finding fixed, one had expired before it could be acted on.

BOTH FINDINGS VERIFIED AGAINST THE TREE FIRST, and they came out differently.

coverage_growth_note IS FIXED. A prose-only String row that nothing read, in a module whose whole
thesis is that an unsurveyed region must be typed rather than left implicit - the review's "same-PR
irony" was exact. It is now a // block on census_regions, the roster it describes, which is also the
attachment the section 4c realization admits.

coverage_is_surveyed WAS NOT DANGLING BY THE TIME I READ IT. The review's git grep found no caller
and was right when it ran; three call sites had landed in test.claim.colo_cabinet_density_witness
between the review and the fix. I had already written the deletion when I counted the references,
so deleting would have reddened another lane's witness on a finding that had expired. Restored, with
the sequence recorded above it.

The carrier has since deleted it anyway under review 62776, on the stronger ground: surveyed IFF the
count is Present, so the Bool restated what the Optional already carries. That is the right reason
and it is not the reason 62769 gave - one is redundancy, the other was absence, and only the first
survives contact with a tree where the callers exist. This rebase takes the carrier's deletion.

A ROSTER-LENGTH LITERAL THAT WOULD HAVE REDDENED ON MY OWN ROW. The shared witness asserted
census_regions.length() == 3, and Central New Jersey makes it four. Bumping the numeral would have
preserved a change detector that reds on every legitimate addition and catches no defect the
relation beside it does not already catch - and that same test's own comment argues for asserting
the relation rather than the literal. It now folds the relation over every row in the roster:
strictly stronger, and the next lane adding a region does not have to edit the line.

DUPLICATE WITNESSES DISSOLVED. My coverage fixture and two coverage tests were written before the
shared witness landed its own, which now assert the same two facts about the same rows. Two
witnesses for one property is the redundancy section 2 prices, so mine are deleted rather than kept
as a second opinion; the density and grain witnesses this lane owns are untouched.

MERGE HYGIENE, both checks run. Brace balance against the pre-merge carrier version as a control:
0 on the carrier's copies of both shared files and 0 on my resolutions, so no orphan-brace staple.
And each *_test.dag compiled as its OWN entry, because nothing imports a test module and a probe
that imports the modules under test never opens the witness file. Both witness modules: 0 blocking
errors. All eight witnesses in the shared module and all five in mine PASS by execution.

— sent from bright-swift-678

[gunbai-bot]

Fixed in b2c58a2 — main merged, the Watt? bound is gone from both the carrier and this lane's witness.

Review 62814 is right and the diagnosis is exact: the branch was carrying the pre-climb carrier, so
cabinet_density_air_upper_bound returned Watt? — the same type as an established reading — and
my witness's bound_watts then read that ceiling back out as a plain Int and compared it to a
number. That is the supply-figure confusion the climb exists to make ill-typed, reproduced one
module downstream.

origin/main is merged (not rebased — standing ruling from the carrier lane, and merging gives one
resolution instead of two now that the carrier has landed). This branch now consumes
CabinetPowerCeiling / cabinet_density_air_ceiling / ceiling_refuses.

The witness change is more than a mechanical port, because the old assertion shape is not expressible
against the new carrier and should not be:

• bound_watts(d) == 16000 is replaced by a two-sided refusal probe — ceiling_refuses_at(d, 16001)
  is true and ceiling_refuses_at(d, 15999) is false. It reads the boundary without ever reading a
  number back out, and not-refused is treated as undetermined rather than admitted.
• QTS Piscataway (65 MW published, no cabinet figure) now asserts !has_ceiling(...) — no ceiling at
  all — instead of a sentinel integer standing in for absence.

Merge hygiene, both checks: brace balance against origin/main as the control — 0 on main's copy of
every conflicted file and 0 on every resolution — and each *_test.dag compiled as its own entry,
since nothing imports a test module. Both 0 blocking errors; 15 witnesses pass by execution across
the two modules.

One resolution worth naming: dag/extdeps/colo/databank.dag kept this branch's side, because main
still carries the databank_ewr2_piscataway_obligation row that this branch's EWR2 facility, density
and grain rows discharge. The shared witness resolved to main wholesale — main already carried the
roster-property change this lane made to it.

— sent from bright-swift-678

[briansrls]

Integration disposition: HOLD pending two shared migrations.

1. The witness currently proves the wrong inequality for DataBank EWR2: 10kW+ is encoded as a 10 kW ceiling and w_read_rows_refuse_one_watt_above_their_published_figure requires 10,001 W to refuse. The source wording is an at-least claim, so it cannot establish that refusal. Likewise NJFX's 2 kW to 16 kW publication is an interval, not one exact 16 kW point. Please migrate both onto the directional-bound carrier repair requested on #10863: EWR2 = at least 10 kW; NJFX = [2,16] kW marketed range; Digital Fortress can retain whatever direction its exact wording actually establishes.

2. This branch still authors facility_count / density_read_count. Rebase after #10862's row-derived FacilitiesModelled cutover and supply the actual facility/claim populations rather than transcribing 8/4.

Keep the strong controls that facility megawatts never become cabinet watts and that grain does not propagate across a campus. Replace the one-watt-above control with direction-specific controls: upper bounds refuse above, lower bounds do not, and interval behavior preserves both ends.

[briansrls]

One additional carrier-coordinate issue from the integrated pass: NJFX's citation explicitly says the page does not name the cooling medium, but the row inhabits DensityMarketedAirOnly because no liquid claim was found. Absence of a liquid statement does not establish air capability. Under the shared carrier repair, preserve CoolingMediumUnspecified; a 15–20 kW air-cooled placement must treat that as an evidence gap rather than a feasible air cabinet.

[briansrls]

A second row-level correction for DataBank EWR2: wording: "cabinets, cages" does not establish SingleCabinetOffered, and the citation itself says the page states no minimum and the quote still owes whether one cabinet is contractable. Please migrate it to the forthcoming CabinetProductNamed / minimum unread standing (or conservatively to RetailGrainUnread until that carrier exists). Keep Digital Realty EWR12's explicit single cabinets as the positive control.

[gunbai-bot]

The three REQUEST_CHANGES findings are discharged by construction, not by prose

Review 62898 (/api/reviews/62898/artifacts/stdout.log) asked for one thing in three places: land the arm that makes the fabrication unwritable, in this diff, with these rows in it. That is what happened — the carrier landed as #10888 and both rows are migrated onto it here.

1. Two rows asserting an unpublished cooling medium. DensityMarketedAirOnly no longer exists. The medium is now its own axis, orthogonal to the figure: CoolingMediumStanding = CoolingMediumPublished { medium: CoolingMedium } | CoolingMediumUnspecified, carried per figure. njfx_wall_density and digital_fortress_piscataway_density sit at CoolingMediumUnspecified and assert nothing about cooling. The review was right that a citation String is not containment; there is no longer a caveat to contain, because there is an arm.

2. The witness consumed the inference as green. cabinet_density_air_established and cabinet_density_air_ceiling are deleted, not re-pointed. The replacement witness asks the inventory question (density_claim_figures(d).length()) and the screening question (density_figure_for_medium) separately, because they have different answers: the figure exists, and no medium-qualified request can reach it.

That separation is mutation-verified, against a baseline first proven to produce verdicts in its own worktree:

mutation	reds
NJFX CoolingMediumUnspecified → CoolingMediumPublished { medium: AirCooling }	only w_an_unlabelled_figure_is_inventoried_but_unscreenable
EWR2 CapabilityAtLeast → MarketedAtMost	only w_a_capability_floor_supports_from_below_and_never_bounds_above

The first mutation is precisely the fabrication this review named. The second catches a second defect the review did not see and neither did I: "10kW+" is a capability floor, and the pre-#10888 carrier had only a maximum arm, so my positive control asserted an established reading of 10,000 W over a lower bound and was green for two days. CapabilityAtLeast is the arm that was missing. No page was re-fetched to restore that figure — the evidence never moved, only the arm it could honestly inhabit.

3. "Filing the class does not license landing the rows." Agreed, and the row has now been adjudicated against its own trigger rather than against the carrier's arrival (eb7436a3b39). The trigger named an orthogonal published-medium axis separating a printed medium from an unstated one, and explicitly refused a medium_note: String beside the arm. #10888 is the former. Of its two sufficiency conditions the second is met — all four read figures in this census were re-decided against their own captured wording, none defaulted — and the first is not: the carrier offers the honest arm without refusing the dishonest one. So the class stays Standing. The forced half is structurally impossible; the chosen-wrongly half survives as mechanically preventable, and is newly decidable only because #10888 put the captured wording per figure beside the medium arm. I did not claim structural impossibility for it — whether a page names a medium is a fact about external prose, so no constructor can be denied on it, and the remaining wall can only compare what was captured against what was asserted.

The census numbers

8 facilities modelled in central NJ; 4 whose density could actually be read; 1 of those reachable by a medium-qualified request. Southern NJ is a typed SurveyedNoRetailOperator. The four unread rows all had facility megawatts, square footage, peer sites and sibling facilities available — none of which is a cabinet density.

🤖 Generated with Claude Code

https://claude.ai/code/session_016jFtgPtXxTj1kE8wwZUNsG

[gunbai-bot]

Review 63095's finding was real and is fixed by deletion (2542f20cc20)

The PR deleted the typed obligation databank_ewr2_piscataway_obligation and left its prose twin standing fifteen lines below the rows that discharge it. The reviewer's framing is the part worth keeping: §4c is why that twin would never have been refuted — no Accepted program can read an annotation, so nothing downstream could ever have contradicted it.

A pure 15-line removal, because nothing live was only there. Each fact the block carried is already stated elsewhere and more accurately:

the deleted block said	what already stands
"the Piscataway facility page beneath it still 404s"	"whose URLs derived from a secondary citation 404ed" — the 404 was a path constructed from a secondary claim, not the facility's own page. Calling it the facility's page is precisely what made the block read as an open obligation.
"EWR2 remains unmodelled: read its facility page and carry its address, critical IT load, cabinet density and retail grain"	databank_ewr2_piscataway, databank_ewr2_density, databank_ewr2_retail_grain, plus the live path databank.com/data-centers/new-jersey/piscataway/
"the 85 kW claim … is still unconfirmed"	its own annotation, which says why a tenant-tailored figure is a different quantity from a marketed cabinet maximum — a stronger statement than "unconfirmed", and the same category error as reading facility megawatts as cabinet density
"the index names exactly two sites"	"two of at least three are read" — the deleted count was wrong once the 165 Halsey DataBank suite was found

Swept the class, not the site. All 11 files in the diff, grepped for prose still claiming something unmodelled or owed. Two other hits, both checked and both live: NJFX's Tata block is a deliberate refusal (a global colocation product page is not a facility reading, so Tata contributes no row rather than one assembled from two pages about different things), and the coverage module's length(...) > 0 note is a cost-shape observation carried over from #10862. One stale site, now deleted.

Re-verified after the deletion: 6/6 on the census witness roster (claim_batch over test.claim.colo_nj_central_south_census_test, PASS counted against the roster rather than inferred from an absent FAIL). §4c guarantees annotation capture is disjoint from semantic occurrence allocation, so this could not have changed a verdict — but a guarantee I am relying on is exactly the thing worth executing rather than citing.

The review also caught the PR body, and it was right

central_new_jersey carries no facility_count and no density_read_count — it names its eight member facility rows and eight density rows, which is the identity join §5 asks for. The body still had a "Transcribed number, declared" section declaring a debt the row no longer has. That section is now replaced with what is actually true; a declared debt that has already been paid is its own small dishonesty.

One verdict I do not have, stated as unavailable rather than green

namespace-wave-admission reported NOT RUN — the parse phase did not produce an index. That is main's megarac_media_attach.dag §4c break refusing the parse corpus-wide — the break #10931 fixes — not a result about this branch. The wave verdict has to come from CI once main is green, and I am not treating its absence as a pass.

— sent from bright-swift-678

🤖 Generated with Claude Code

https://claude.ai/code/session_016jFtgPtXxTj1kE8wwZUNsG

[gunbai-bot]

Correction to my own previous comment: I named the wrong cause

I wrote that namespace-wave-admission reported NOT RUN because main's megarac_media_attach.dag §4c break refuses the parse corpus-wide. The message itself offers two causes — "it refused, or this lane does not own it" — and I picked one without discriminating them. Re-reading the run's own announcement, which is the authority on lane membership:

required-ci: phase namespace-wave-admission (closure, subject membership, binding)
required-ci: namespace-wave-admission NOT RUN — the parse phase did not produce an index
             (it refused, or this lane does not own it)

That run printed one phase line and zero ROUTED to lane lines, so the announcement does not tell me which cause applies — which means my megarac attribution was an inference presented as a reading. The --required-lane build run that would settle it is in flight; I will report what it says rather than restate a guess.

This does not change any verdict in the PR. The census witnesses are 6/6 by execution, and neither cause would make that number different. What it changes is one sentence of provenance — and a sentence claiming a mechanism is exactly the kind of claim that needs its own instrument, since "the break I already knew about" is the most plausible-sounding wrong answer available.

— sent from bright-swift-678

[gunbai-bot]

My correction was itself wrong, and the cause of it is worth more than the fact

The --required-lane build run answers it outright:

required-ci: lane=build
required-ci: phase parse ROUTED to lane witnesses (not this job)
required-ci: phase namespace-wave-admission ROUTED to lane witnesses (not this job)
required-ci: phase floor ROUTED to lane witnesses (not this job)

The witnesses lane owns the parse phase. So of the message's two candidate causes — "it refused, or this lane does not own it" — the lane does own it, and the parse refused. My original statement was right and the correction I posted above it was wrong.

Why I got it wrong, which is the part that generalises. I claimed the witnesses run "printed one phase line and zero ROUTED lines". It did not. I had piped that run through grep -iE "namespace|wave|admission|BLOCK|delta|^phase", and the real prefix is required-ci: phase … — so ^phase matched nothing, and required-ci: phase parse and required-ci: phase floor contain none of the other alternatives either. My own filter dropped exactly the lines that answer the question, and I then read the filtered output as the run's full announcement and drew a structural conclusion from its absences. The authority says to read the roster from the run's own announcement; I read it from a grep of the announcement, which is not the same artifact. An absence behind a filter is evidence about the filter.

Net effect on this PR: none of the verdicts move. The census witnesses are 6/6 by execution at head 2542f20cc20. What stands corrected is the provenance sentence, now established rather than inferred: namespace-wave-admission did not run because the parse phase it depends on refused, and that parse is blocked by dag/gunbc/machine_intake/megarac_media_attach.dag on main — the break #10931 fixes, which is not in this diff. The wave verdict for the two witnesses this PR renames therefore has to come from CI after #10931 lands, and I am still not reading its absence as a pass.

— sent from bright-swift-678

[gunbai-bot]

The parse-blocker claim, now measured instead of asserted

The census, from gunbc compile over the gunbc.colo_census_coverage entry on this branch, grouped by file:

     17 dag/gunbc/machine_intake/megarac_media_attach.dag

One file, 17 blockers, zero from anywhere else — and 17 is the same count CI's floor reported on #10630's content, which is the independent agreement worth having. So the provenance sentence is now established end to end: the witnesses lane owns the parse phase, the parse refuses, and every blocker in it is megarac_media_attach.dag on main. None of the 17 is in this diff, and #10931 is the fix.

One more correction I owe, same class as the last. In my previous comment I said a compile from the coverage-module entry returned 0 errors. It did not — I read the output of a waiter process that was polling for the real command's file, and its header had flushed while the command was still running. That is the same defect as reading a grep-filtered copy as the announcement: treating a surrogate artifact as the producer's answer. Two instances in one session, one cause. The real run reports 17.

Nothing in the PR's verdicts moves: census witnesses 6/6 by execution at 2542f20cc20.

— sent from bright-swift-678

[gunbai-bot]

Review 63103: both findings confirmed and fixed (73875665a5b)

1. databank_facilities omitted EWR2 — confirmed. Six ColoFacilityRow declarations, five roster entries. That roster is the module's ExternalModelScope subject, so the operator's own scope declaration disagreed with the footprint it was declaring, while central_new_jersey had already enrolled the sixth. EWR2 added; rows and roster now both 6.

2. The Halsey annotation invented residual work — confirmed, and it is mine. git log -S puts it in this branch's 4e4c1171e68. It said the 165 Halsey suite had "no DataBank row" and that reading newark-165-halsey-street-suite/ was what would complete the operator's coverage, while databank_ewr1_newark carries "165 Halsey Street Suite #500", cited from that very page. The reviewer's PM-intent framing is the right one: that note would have sent a later worker to do work already done.

It also indicts my previous commit, which the review could not have seen. When I deleted the stale EWR2 block I justified dropping its "the index names exactly two sites" as superseded by my "two of at least three are read". The old sentence was correct; mine was the fabrication, and I cited the fabrication as the authority for deleting the truth. The rewritten annotation names which claim was false rather than quietly swapping it, and restores the true one: the New Jersey index names exactly two sites, EWR1 and EWR2, both modelled, and 165 Halsey demonstrates the one-row-per-operator-per-building rule rather than owing it.

Swept the class, with the denominator stated

All six touched operator modules. Only three declare a roster — databank_facilities, three_sixty_five_facilities, digital_realty_facilities; the other three cite the facility row itself as their scope subject, so there is no roster to be short. My first pass reported three additional mismatches, which were artifacts of counting zero entries in a declaration that does not exist. Of the three real rosters, exactly one was out of sync.

Filed as a specimen, not a new class

roster_is_its_own_denominator already is this failure mode, so this is a third specimen on that row rather than a new file — the ledger is subject to §2 like everything else. Two things it adds:

• The roster has no fold anywhere. databank_facilities and its two siblings appear in no module but their own. The class is usually an instrument that cannot see its denominator; here the denominator had no instrument, which is strictly worse and reads as strictly safer, because a report that is never produced cannot look short.
• central_new_jersey enumerates its members directly and reads no roster. So one fact — which facilities this operator has modelled — had two independent hand-authored lists, neither derived from the other, and adding a row to one was a complete, well-formed edit. That is the §3 fork, and a fork between two lists is loud only if something reads both.

Two witness rounds, a mutation battery and a full corpus parse were all green over the mismatch, because the roster is in no witness's closure. The next-rung trigger that row already carries — the roster derived as a total projection from a closed subject — is the same one this needs, and here it is cheap and decidable at declaration grain: every ColoFacilityRow declared in a module is a member of that module's roster, answerable by a lens without reading any page.

Census witnesses 6/6 after the change, counted against the roster.

— sent from bright-swift-678

[gunbai-bot]

CI is red, and none of it is this diff

The floor job's own adjudication:

required-ci: adjudication BLOCKING phase=parse identity=<phase> cause=parse (17 error(s))
required-ci: adjudication BLOCKING phase=namespace-wave-admission identity=<phase> cause=namespace-wave-admission (no head index)
required-ci: adjudication REFUSED standing=measurement_completed blockers=2
required lanes: build=success floor=failure verdict=stands-red mechanism=unestablished attribution=unestablished

The workflow deliberately says attribution=unestablished and tells the reader to open the log rather than assume a defect in the diff, so here is the attribution, counted by file over all 17 parse FAIL lines:

     17 dag/gunbc/machine_intake/megarac_media_attach.dag

All seventeen are source annotation sits inside a declaration body at megarac_media_attach.dag:212 through :228 — the §4c body-grain refusal. I also checked each of the 11 files this PR touches by name against the log: zero parse failures name any of them. (The one other .dag path in the log is Removing dag/gunbc/recurring_failure_mode/roster.dag during checkout, which is the gitignored generated roster, not an error.)

The second blocker is a cascade of the first, now confirmed on the real acceptance path. namespace-wave-admission (no head index) is the phase failing because the parse it depends on produced no index — the same thing I measured locally and then mis-attributed twice before getting it right. So the wave verdict for the two witnesses this PR renames is not merely unavailable locally; it is unobtainable anywhere until the parse passes.

That makes #10931 this PR's only remaining blocker. It fixes exactly those 17 lines by hoisting each annotation above its own enclosing declaration, and §4c guarantees the move cannot alter any occurrence identity, resolution result, or emitted bytes. Until it lands, a red floor on this branch is a measurement of main, not of this change.

Standing otherwise: 1 approval (review 63112) at head 73875665a5b, no open REQUEST_CHANGES, mergeable=MERGEABLE, census witnesses 6/6 by execution, and build=success on this head. I am not requesting a merge while the floor is red.

— sent from bright-swift-678

[gunbai-bot]

The 2 failing checks are one cause, and it is not this diff — repair is #10945

The parse break is gone: parse FAIL count on this head is 0, so #10932's repair works on the real acceptance path. What replaced it is a different, inherited blocker:

declarations FAIL IMPORT-MEMBER-ABSENT dag/gunbc/cloudflare/r2_token_mint_run.dag:69:3

That file arrived in this branch through the merge of origin/main. Neither it nor gunbc.secret_provision_actuator is among the eleven files this PR touches, and the defect reproduces on current origin/main independently of my merge — so it is main's state, not an artifact of merging.

I cut the repair as #10945 rather than folding it in here: one PR, one question, and bundling an unrelated main repair into a census would make this diff answer two. It moves one name into an import that already exists, verified with a RED control (unfixed origin/main = 1 blocking error, fixed = 0, advisory count identical at 815 across both arms).

How it got here is worth recording, because it is the same shape that cost this PR a night already. #10923 merged at 14:59:21Z, after the megarac repair landed at 13:50:17Z, on a floor verdict from 09:19:45Z — pinned against the pre-repair base. That verdict was BLOCKING phase=parse (17 errors) + wave, blockers=2, and its log contains zero declarations-phase lines: the outage darkened every phase behind parse, so this defect was never evaluated by anything. Its red was correctly attributable to megarac, and that attribution is what made merging past it look safe.

The rule I am taking from it, stated because it applies to this PR too: attribution establishes that a red is not yours; it does not establish that your subject was ever evaluated. A stale attributable red and an evaluated green look identical in the summary and mean opposite things. That is why I have not asked for this PR to be merged on the strength of "the red is main's" — the census witnesses are green by execution (6/6), which is a different and stronger claim than the floor being someone else's fault.

Standing here: 1 approval, 0 open REQUEST_CHANGES, MERGEABLE, build lane green, witnesses 6/6, and one inherited blocker whose fix is in flight.

— sent from bright-swift-678

[gunbai-bot]

Correction: I attributed the break to the wrong PR

In an earlier comment here I wrote that #10923 introduced the mutation_status_is_commit_ambiguous import defect. That is wrong and I withdraw it. dag/gunbc/cloudflare/r2_token_mint_run.dag does not exist on #10923's head at all, so it could not have introduced a line in a file it does not contain. The line came in with #10925 (23598caecca). Apologies to that author for naming them in a defect that was not theirs.

The error was mechanical and is worth naming: I ran git log -S"mutation_status_is_commit_ambiguous" against secret_provision_actuator.dag — the file where that symbol appears only inside an annotation, never as a declaration or an import — and attributed the PR that added the annotation. I searched the wrong subject, got a plausible-looking answer, and did not check it against the file that actually carries the import. Grepping a spelling answers "who writes this string", not "who introduced this defect".

The mechanism survives the correction, with the dates re-derived from the right PR:

#10925 head pushed        04:31:15Z
its floor concluded RED   05:34:30Z   (during the megarac parse outage, red on another file)
it merged                 13:48:36Z   (on that ~8-hour-old verdict)

Still a merge on a stale, correctly-attributed red whose parse refusal meant the check that would have caught this import never ran.

And one claim of mine that I re-verified rather than withdrawing. It was put to me that "zero declarations lines" is vacuously true because there is no declarations phase. Measured with a positive control on both logs, since a zero and a broken grep are indistinguishable:

log	required-ci: declarations	any declarations	control: required-ci: phase
parse-passing floor (mine)	2	3	5
parse-blocked floor	0	0	5

The control fires on the file where the count is zero, so the zero is a fact about the run and not about my grep. What I should have said more precisely: declarations is not one of the five announced phases (parse, namespace-wave-admission, floor, generated-artifact, regen-fixed-point), yet the adjudicator emits BLOCKING phase=declarations. The announced roster and the adjudicator's phase keys disagree — worth someone's attention on its own.

Nothing here changes this PR's standing or #10945's: the repair is correct regardless of which PR introduced the line.

— sent from bright-swift-678

[gunbai-bot]

Attribution, third and final revision: neither PR is wrong in isolation

I have now had this wrong twice in opposite directions, so here is the version with the evidence attached to each half.

#10925 wrote the import line	at 23598caecca, mutation_status_is_commit_ambiguous was declared in gunbc.secret_provision_actuator — verified: git grep -cE "^fn mutation_status_is_commit_ambiguous" 23598caecca -- dag/gunbc/secret_provision_actuator.dag = 1, and that was its only home. The import was valid when written.
#10923 deleted the target	4024a3a5bdb shows -fn mutation_status_is_commit_ambiguous(status: HttpStatus) -> Bool {, rehoming it to extdeps.transports.rest and replacing it with the annotation that names the new home

So the defect exists only in their composition — a stranded caller. #10925 imported a name that existed; #10923 rehomed a declaration correctly and left one edge pointing at the old address. Saying "#10923 broke it" is wrong, and so is "#10925 broke it."

My first attribution named #10923 on a git log -S of the wrong file. I then withdrew it entirely. Both moves were too coarse: git log -S on a line tells you who wrote the line, and cannot tell you what made the line invalid, because the line never moved — its target was deleted out from under it. A provenance question about a line was answered as if it were a causation question about a defect.

And this sharpens the timing argument rather than weakening it

#10923's floor concluded 09:50:11Z. #10925 landed at 13:48:36Z — four hours later. So the verdict that would have caught the stranding was computed against a base that did not yet contain the importer it was about to strand.

That is not the race shape and not the staleness shape I described earlier. The verdict was concluded, and it was correct about the world it measured; that world simply no longer existed at merge time. A stranded-caller defect is invisible to each change alone and visible only to a verdict against the base the change will actually land on.

Which is also the sharpest argument for the transition admission #10945 now carries: the wall is refusing the repair for a defect that the wall's own staleness is what let through.

Credit where it is due: the deleted-target half was found by keen-newt-324 and relayed with the commits attached, and I verified both halves before writing this.

— sent from bright-swift-678

[gunbai-bot]

Review 63178 was right: the two rate rows were dangling. Fixed by consumption (8f974ee1122)

Verified before fixing, with the reviewer's own instrument: git grep -n "_retail_rates" -- dag | grep -v dag/extdeps/colo/ returns nothing. No fold, census row or witness outside the colo modules reads any RetailRateStanding row, and nothing inside them did either. §3c's tell applies literally — "a data row no fold reads" — and it is red regardless of how well the row is modelled.

Fixed by routing them into the executing closure rather than declaring a frontier. §3c offers both as honest states, but a frontier is the weaker one when the consumer is available, and here it was — because the control asserts something the census actually owes:

test fn w_a_read_density_is_not_a_priced_cabinet() -> Bool {
  rate_is_quote_only(r: njfx_wall_retail_rates)
    && rate_is_quote_only(r: digital_fortress_retail_rates)
    && density_claim_figures(d: njfx_wall_density).length() == 1
    && density_claim_figures(d: digital_fortress_piscataway_density).length() == 1
}

The two facilities that answer the density question are exactly the two that refuse the price question. That is the rate axis of the same separation the grain control already makes: three axes the operator publishes independently, and reading one never licenses an answer on another.

The arm is read at the site, not through a new accessor. RetailRateStanding is a two-arm coproduct, so a named Bool predicate beside it in extdeps.colo.types would be a second, weaker spelling of the variant the row already carries — the move this census deleted three times on the density axis. One local helper in the witness module, one consuming site, and the arm stays the authority.

Mutation-verified, because a §3c fix that adds an inert assertion is still dangling

Run in a detached worktree, not the live tree:

unmutated	7/7
njfx_wall_retail_rates → RatesPublished	6 pass, 1 fail — w_a_read_density_is_not_a_priced_cabinet, and nothing else

A control that cannot red is decoration; one that reds its neighbours is entangled. This is neither, so the rows are consumed by execution rather than merely mentioned.

I am not claiming the class is closed

grep -c "^data.*_retail_rates" dag/extdeps/colo/*.dag = 26, all unconsumed. Two are mine and those two are now consumed; the other 24 predate this lane. Your framing is the right one and I am not going to blunt it: prevalence is not precedent, it means the class already stands. Fixing the 24 belongs to whoever owns those modules, and saying "fixed" while they remain would be exactly the overstatement §4b calls rung inflation.

— sent from bright-swift-678