Skip to content

Confirming the string is not confirming whose fact it is - #10872

Merged
briansrls merged 2 commits into
mainfrom
session/quiet-cat-23-rfm-citation-scope
Sep 9, 2026
Merged

briansrls merged 2 commits into
mainfrom
session/quiet-cat-23-rfm-citation-scope

Conversation

@gunbai-bot

@gunbai-bot gunbai-bot Bot commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

A verbatim citation is a string with a scope — the element that authored it and the heading
that governs it. Rendering to text keeps the string and destroys both, so a reader working from a
rendering can confirm the wording perfectly and still be wrong about the owner.

Two specimens from the colo census, opposite directions, one mechanism:

  • Fusion. A spec strip authored as two sibling <li> cells captured as one comma'd sentence
    that appears nowhere in the bytes. Four independent instances on four facilities of one operator,
    three different readers — which is what makes it a property of the page template rather than of a
    reader.
  • Locality. 12 kW of 2x 208V/50A A+B redundant power in a 42U configuration reproduced in the
    bytes exactly, on the right operator's page, under a block headed
    Limited Time: Chicago-Area Facility.

The second defeats the repair the first motivates, which is why the row exists. Closing fusion
with "confirm the wording occurs in the raw bytes" passes cleanly on the Chicago figure — a
string-occurrence test cannot fail on correct text attached to the wrong subject. A verification
sound for one member of a class and silent for another does not partially repair it; it certifies
the residue.

The repair is at markup grain and only there: element boundaries settle fusion (one <li> is an
authored cell, two joined by a comma is invention) and byte order settles locality (the nearest
preceding heading is the figure's scope). Tag-stripped text cannot express the first, so the
intuitive fix destroys the evidence — and raw bytes cannot answer the wording question at all once
the numeral is emphasized. Two questions, two artefacts.

Measured cost of not having the row: verbatim auditing reduced the readable-density population
rather than growing it — one metro 4 rows to 2, one corridor 2 to 1 of 28 — and every withdrawal
had passed a plausibility read.

Bounded against positional_citation (right owner, decaying position),
stable_citation_mutable_referent (referent moved after a correct read) and
type_name_field_carries_rendered_value (a rendering in what the corpus carries, not what it was
checked against).

Row file only — the roster is derived and gitignored. Compiles clean in the
gunbc.design_ledgers closure; the 3 blocking errors in that closure are pre-existing on main
(extdeps.gunbc shell-transport emission) and unrelated.

🤖 Generated with Claude Code

https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN

Brian Searls and others added 2 commits September 9, 2026 00:29
A verbatim citation is a string WITH A SCOPE -- the element that authored it and the heading
that governs it. Rendering to text keeps the string and destroys both, so a reader working from
a rendering can confirm the wording perfectly and still be wrong about the owner.

Two specimens from the colo census, opposite directions, one mechanism. FUSION: a spec strip
authored as two sibling <li> cells captured as one comma'd sentence that appears nowhere in the
bytes -- four independent instances on four facilities of one operator, three different readers,
which is what makes it a property of the page template. LOCALITY: "12 kW of 2x 208V/50A A+B
redundant power in a 42U configuration" reproduced in the bytes EXACTLY, on the right operator's
page, under a block headed "Limited Time: Chicago-Area Facility".

The second defeats the repair the first motivates, which is why the row exists. Closing fusion
with "confirm the wording occurs in the raw bytes" passes cleanly on the Chicago figure -- a
string-occurrence test cannot fail on correct text attached to the wrong subject. A verification
sound for one member of a class and silent for another does not partially repair it; it
certifies the residue.

The repair is at markup grain and only there: element boundaries settle fusion (one <li> is an
authored cell, two joined by a comma is invention) and byte order settles locality (the nearest
preceding heading is the figure's scope). Tag-stripped text cannot express the first, so the
intuitive fix destroys the evidence -- and raw bytes cannot answer the wording question at all
once the numeral is emphasized. Two questions, two artefacts.

Measured cost of not having the row: verbatim auditing REDUCED the readable-density population
rather than growing it, one metro 4 rows to 2 and one corridor 2 to 1 of 28, and every
withdrawal had passed a plausibility read.

Bounded against positional_citation (right owner, decaying position),
stable_citation_mutable_referent (referent moved after a correct read) and
type_name_field_carries_rendered_value (rendering in what the corpus CARRIES, not what it was
CHECKED AGAINST).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN
Review 62774: no rung found at, no ceiling with reason, no next-rung trigger. Correct, and
load-bearing rather than ceremonial here, because the receipts already PRESCRIBE a repair -- match
the wording against tag-stripped text, decide fusion and scope against the markup -- and a named
repair with no capability that ends it is exactly the untracked stall section 4b(2) forbids. A
class with no trigger can never rank.

RUNG FOUND AT: mitigatable, and the mitigation was a human re-reading page bytes, which is the
weakest form the rung has. While the Chicago row stood it was SILENT WRONGNESS -- below the ladder
rather than on it -- because no consumer could distinguish the wrong figure from a right one. It
is filed at mitigatable because the containment is now real and entirely retrospective.

CEILING: structurally impossible, for both halves. The invalid states are a wording SPANNING TWO
ELEMENTS and a wording SCOPED BY A HEADING NAMING ANOTHER SUBJECT. Element containment is a tree
question and enclosing-heading is a byte-order question -- decidable, no predicate lifted to proof
-- and neither has a constructor once the wording is minted as a projection of one captured
element and its heading path. The residual is the external boundary and is deliberately not a
rung: whether the captured bytes are that page today is upstream reality, observed and never
fabricated. So the ceiling is impossibility of MISATTRIBUTION WITHIN A CAPTURE, not of a stale
capture.

TRIGGER, NAMING THE CAPABILITY: a captured-source carrier whose mint takes bytes plus an element
identity and YIELDS the wording, so claim_wording cannot be inhabited by a hand-typed String at
all, carrying the enclosing heading path and joining it against the facility the row is about. It
must be SUFFICIENT FOR: no author can write a wording spanning two elements, and none whose
enclosing heading names a different facility, promotion or metro. A carrier that merely STORES the
bytes beside the wording does not discharge it -- both stay writable and one author satisfies both
in one edit, which is the artifact-shaped trigger this ledger warns about.

And the intermediate rung is recorded so it cannot be reported as the ceiling: a lens over stored
captures reaches mechanically preventable and stops there, because the wording and the capture
both stay writable and safety depends on that lens staying enrolled.

The review's other observations were checked and stand: filename-is-membership so the derived
roster picks the row up with no second list, evidence: [] matches the documented standing reason,
and the sibling boundaries are correct. Compiles clean in the gunbc.design_ledgers closure -- the
3 blocking errors there are pre-existing on main (extdeps.gunbc shell-transport emission) and
unchanged by this commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN
@gunbai-bot

gunbai-bot Bot commented Sep 9, 2026

Copy link
Copy Markdown
Contributor Author

Review 62774 accepted and fixed at ecf2e56. The finding was right and it was load-bearing rather
than ceremonial, for the reason the review gave: the receipts already prescribe a repair, and a
named repair with no capability that ends it is exactly the untracked stall §4b(2) forbids.

RUNG FOUND AT: mitigatable — and the mitigation was a human re-reading page bytes, which is the
weakest form the rung has. Worth stating the harsher half: while the Chicago row stood it was
silent wrongness, below the ladder rather than on it, because no consumer could distinguish the
wrong figure from a right one. It is filed at mitigatable because the containment is real and
entirely retrospective.

CEILING: structurally impossible, both halves. The invalid states are a wording spanning two
elements
and a wording scoped by a heading naming another subject. Element containment is a tree
question, enclosing-heading is a byte-order question — decidable, no predicate lifted to proof — and
neither has a constructor once the wording is minted as a projection of one captured element and its
heading path. The residual is deliberately not a rung: whether the captured bytes are that page
today is upstream reality, observed at a declared boundary and never fabricated. So the ceiling is
impossibility of misattribution within a capture, not of a stale capture.

NEXT-RUNG TRIGGER, naming the capability: a captured-source carrier whose mint takes bytes plus
an element identity and yields the wording, so claim_wording cannot be inhabited by a hand-typed
String at all, carrying the enclosing heading path and joining it against the facility the row is
about. Sufficient for: no author can write a wording spanning two elements, and none whose enclosing
heading names a different facility, promotion or metro.

I took the roster_is_its_own_denominator correction the review pointed at seriously rather than
just matching its format. A carrier that merely stores the bytes beside the wording does not
discharge this
— both stay writable and one author satisfies both in one edit, which is the
artifact-shaped trigger. And the intermediate rung is recorded so it cannot later be cited as the
ceiling: a lens over stored captures reaches mechanically preventable and stops there, because
safety then depends on that lens staying enrolled.

On the review's other observations — filename-is-membership, evidence: [] matching the standing
documented reason, single-line receipts preserving the merge geometry, and the sibling boundaries —
I checked each and they stand; no change needed. On the 43-of-189 rows omitting a ceiling: agreed
that is debt and not precedent, and I have not used it as one.

Compiles clean in the gunbc.design_ledgers closure; the 3 blocking errors there are pre-existing
on main (extdeps.gunbc shell-transport emission) and unchanged by this commit.

— sent from quiet-cat-23

@briansrls
briansrls merged commit 9eb9855 into main Sep 9, 2026
4 checks passed
@briansrls
briansrls deleted the session/quiet-cat-23-rfm-citation-scope branch September 9, 2026 02:07
gunbai-bot Bot pushed a commit that referenced this pull request Sep 9, 2026
…-by-hunk

The carrier landed on main as #10863 with #10872 and #10873 on top, so the
two files this branch shares with it became add/add conflicts: 20 hunks
across four files. Resolved by taking MAIN's version of each file whole and
re-applying only this branch's additions, rather than adjudicating hunks -
hand hunk-resolution has already cost this branch two parse defects, and a
conflict boundary that cuts through a declaration is what produced both.

What that discipline caught: main's witness had gained an entire ceiling
API - cabinet_density_air_ceiling, CabinetPowerCeiling, CeilingAt,
ceiling_refuses, two helper fns and the test
w_absent_ceiling_refuses_nothing_and_a_real_one_does - none of which exists
on this branch. Taking my side of that file would have silently deleted a
test and its carrier. Verified by identity rather than by eye: all 9 of
main's test fns are present in the merged file, plus 1 of mine, and the
ceiling API appears 15 times.

Main also adopted all(census_regions, ...) where I had written
filter(...).length() == 0. Main's is the better idiom and is kept.

Per file: types.dag is byte-identical to main (never edited here);
databank.dag is main's plus the EWR1 Newark rows; colo_census_coverage.dag
is this branch's derived-count version, which is a strict superset of main's
- main's only unique content is the two Int fields my change replaces and a
paragraph describing them as "already in flight", now obsolete; the witness
is main's with the read-count accessor, the corrected vacuous arm, and the
two-claim fixture applied on top. Main's predicate destructured
FacilitiesModelled's Int fields and could not have compiled against the
derived arm, so replacing it was forced rather than preferred.

Structural check over all 24 touched files reports zero defects.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp
gunbai-bot Bot pushed a commit that referenced this pull request Sep 9, 2026
The merge took main's types.dag, which no longer declares
cabinet_density_air_upper_bound - #10872 replaced it with
cabinet_density_air_ceiling returning CabinetPowerCeiling. My
density_claim_is_read still called the deleted symbol, so the coverage
module could not have resolved. Neither the brace/annotation check nor the
merge itself can see this: it is a symbol-level break, and the file it
breaks is not the file the conflict was in.

density_claim_is_read now folds cabinet_density_air_ceiling, whose Present
and Absent arms carry exactly the same distinction the old accessor did -
Present for both published arms, Absent exactly for DensityUnread - so the
read count is unchanged and there is still one authority for what "read"
means.

Only the PRESENCE of the ceiling is read, never its magnitude, and the
annotation says so. That is the sound use of the new carrier: a ceiling
answers whether a requirement is refused, so asking it "was anything
published" is a question about the claim, not about the cabinet. The Watt
inside CeilingAt is never touched by this fold, which keeps counting read
claims from becoming admission on a bound - the thing #10872 built the
separate ceiling type to prevent.

Added a symbol-resolution check over the branch's imports to catch this
class, since the structural check could not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp
briansrls added a commit that referenced this pull request Sep 10, 2026
…hat their pages will not say (#10862)

* Facility megawatts were never cabinet kilowatts: the third power fact

The census carried two power facts and neither answered the question a
deployment asks. A facility's marketed capacity - 80 MW at a carrier hotel,
25.6 MW at an enterprise campus - is a fact about a BUILDING, and reading it as
density is the same category error as reading a substation's rating as a
house's service. A RetailPlanRow's PowerAllocation is the right grain and
exists for exactly two operators in this metro, because almost nobody
publishes retail power.

Between them sits the fact operators DO publish: a marketed maximum per
cabinet. CabinetDensityClaim carries it, and carries the marketing wording
verbatim beside the numeral, because a marketed maximum is not a quote, not
currently available capacity and not a commitment. A candidate may be screened
IN on it and may never be screened as PRICED on it. RetailGrainStanding is the
separate question of whether the operator sells one cabinet at all - a campus
marketing 25 MW that takes only suite commitments is a different refusal from
an unread density.

WHAT THE FIRST TWO READS SHOW. Every priced plan in this census tops out at
2.5 kW across twenty rack units, which made colocation look physically
incapable of holding a 650 W-per-node fleet. It is not. Iron Mountain NJE-1
markets "high-density up to 30 kW/rack" with individual cabinets offered;
DataBank LGA4 markets "35kW+ air-cooled, 100kW+ liquid-cooled". Against a
650 W node those are 46 and 53 nodes of air-cooled headroom, where the densest
PRICED product modelled here holds three. The gap between what is marketed and
what is published for retail sale IS the finding - and it is a reason to get
quotes, not a reason to believe one will be affordable. Nothing here says what
35 kW costs.

THE UNREAD ARM EARNED ITS KEEP IMMEDIATELY. The review that prompted this work
asserted Iron Mountain advertises 20 kW cabinets in Pennsylvania. The page was
read and states no per-rack or per-cabinet density at all, so WPA-1 carries
DensityUnread naming the unconfirmed claim rather than the number. A density
nobody published must not enter the census because a secondary source said it
existed.

NEW YORK WAS NEVER REFUSED, IT WAS NEVER SURVEYED. The census stood at 23 New
Jersey facilities and 7 Pennsylvania ones with no New York site, and this
session had reported that absence as a consequence of the Equinix ruling. It
was not: the Equinix campus that ruling names is itself in Secaucus, New
Jersey. DataBank LGA4 Orangeburg is the first New York row.

Executed control: cabinet_density_air_kw over the three new claims returns
[35, 30, 0] - the two read claims yield their marketed figures and the unread
one yields zero, which callers must read through cabinet_density_is_read
rather than compare as a number.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN

* Watt and VoltAmpere already existed; I re-invented both as a bare Int

TWO REVIEWS ARRIVED AT THIS FROM OPPOSITE ENDS AND MET ON ONE DEFECT.

A census lane reading Telehouse Chelsea - "standard power to rack at 3.5kVA
with scalable options to 5kVA" - had no correct arm for an apparent-power
publication, so they put 5 in a field named air_cooled_kw and documented the
mismatch in the citation. The documentation was right and the FIELD was wrong:
a note cannot stop a consumer reading a number out of a field named for the
quantity it is not. Independently, review 62722 observed that a unit baked into
a field name is a second representation of a fact std.measure already owns, and
that THIS FILE ALREADY IMPORTS Watt for PowerAllocation - so the census was
answering "how much power" two ways at once.

Both objections have one repair, and the corpus had already made the
distinction structurally: Watt is Measure<Power, One, Nat>, VoltAmpere is
Measure<ApparentPower, One, Nat>, carried on SEPARATE dimensions with a note in
std.measure saying that putting both on Power would conflate them. So neither
half of this was a new concept. I minted a worse version of two that existed,
which is exactly the re-invention DESIGN section 2 names.

WHY THE APPARENT/REAL DISTINCTION IS LOAD-BEARING. kW = kVA x power factor with
PF <= 1, so kW <= kVA always, and reading a kVA publication as kilowatts
OVERSTATES real capacity - it fails in the flattering direction, which here
means putting more nodes in a cabinet than its breaker will carry. Colocation
quotes state kVA precisely because the facility sizes to apparent power, so
this is the common case and not an edge one.

THE ZERO IS GONE TOO, and review 62722 was right that the predicate beside it
was the tell. cabinet_density_air_kw returned 0 for an unread claim - a
fabricated in-band answer on the same axis as real readings, defended only by a
comment telling callers to consult cabinet_density_is_read first, which is the
validation-standing-where-construction-was-available shape section 5 warns
about. The reading is now Watt? and the predicate is DELETED rather than
documented around: the confusable zero is unconstructible.

Absent has two causes with one consequence: nobody published a figure, or
somebody published apparent power and no power factor exists to convert it.
Either way there is no established watt reading and an admission decision that
needs one must refuse. The upper bound is a separate, weaker function - sound
for REJECTING a cabinet too small even at the bound, never for admitting one -
and it is the only place ApparentPower crosses to Power, justified by the
inequality and by nothing else.

Also rosters dag/extdeps/colo/databank.dag in scope_carrier_paths; keen-newt-324
found the placement gate refuses it as a new unrostered extdeps file.

Executed controls, one dispatch, established vs upper bound over four claims:
                              established      upper bound
  DataBank LGA4 (35 kW)         35000 W          35000 W
  Iron Mountain NJE-1 (30 kW)   30000 W                -
  Telehouse Chelsea (5 kVA)      ABSENT           5000 W   the whole point
  Iron Mountain WPA-1 (unread)   ABSENT           ABSENT

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN

* wip: corridor census rows

* The controls only existed in a probe I deleted: enroll them

Review 62722's third finding, and it is the one I had already flagged about my
own work two turns earlier without acting on it. The carrier landed a type, two
functions and six data rows that NOTHING read: grep for cabinet_density,
CabinetDensityClaim, RetailGrainStanding or databank outside those three files
returned empty, and no module outside dag/extdeps/colo imports the colo
namespace at all. The PR body cited an executed control, but that control lived
in a scratch probe the author ran and then deleted.

A deleted probe is not evidence a wall stays standing. DESIGN section 3c is
explicit that a declaration nobody consumes is red regardless of how well it is
modelled, and section 5 that a run nobody can repeat is not a consumer. Being
able to name the failure did not make it not a failure.

Five enrolled witnesses, with the discriminating case first among equals:
  w_published_kilowatts_establish_real_power        positive control
  w_apparent_power_establishes_no_real_power        THE DISCRIMINATING RED
  w_apparent_power_still_bounds_real_power_above    kW <= kVA, so the bound holds
  w_unread_density_establishes_and_bounds_nothing   the zero stays unconstructible
  w_density_and_grain_are_separate_facts            the two axes stay independent

The apparent-power fixture reproduces the Telehouse Chelsea publication shape
that found the defect. It lives in the witness rather than an operator module
because it is evidence about the CARRIER, not a census row; the live Telehouse
rows belong to whichever lane reads that operator.

MUTATION CONTROL, executed. Restoring the defect - making
cabinet_power_established return the volt-ampere count as watts, which is
exactly the conflation the carrier was rewritten to prevent - flips
w_apparent_power_establishes_no_real_power from true to false while the other
four stay true:
  clean    [true, true,  true, true, true]
  mutated  [true, FALSE, true, true, true]
So the red is discriminating rather than decorative, and it names the single
behaviour it guards.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN

* A surveyed-empty region and an unsurveyed one rendered identically

Two census lanes reached this need independently within the hour. Southern New
Jersey - seven counties - yielded zero facility rows, and the Hudson Valley
proper - four counties - yielded zero retail colocation. Both lanes wanted to
record that as a RESULT, neither had anywhere to put it, and both wrote it into
a pull-request body where the next reader will never find it.

The defect is that a census with no row for Cape May County looks exactly the
same whether somebody read every operator page in it and found nothing, or
whether nobody has ever looked. The first is expensive knowledge worth keeping;
the second is an open obligation. Collapsing them means the expensive half gets
re-derived by the next lane and the open half is mistaken for settled.

THIS CENSUS HAS ALREADY MADE THE SECOND ERROR ONCE. The absence of any New York
row was reported - by me, twice - as a consequence of the Equinix refused-
channel ruling. It was not: that campus is itself in Secaucus, New Jersey. New
York was never refused, it was never surveyed, and nothing in the substrate
could have said so.

RegionSurveyOutcome makes the two arms distinct. SurveyedNoRetailOperator
carries the counties searched, the causes, and who searched when - the searched
list is what makes it a measurement rather than an assertion, because a later
reader can judge the coverage instead of taking "empty" on trust.
RegionUnsurveyed is the only arm carrying an open obligation.
coverage_facility_count is Optional for the same reason: a surveyed-empty
region answers zero and an unsurveyed one answers nothing, and a plain Int
would let both produce the same number.

EmptyRegionCause is separate because regions are empty in ways that oblige
different follow-ups: aggregators-only, resellers without a facility, operators
present but not selling retail colocation, or a directory claim the operator's
own pages contradict. Southern New Jersey carries the last of those with two
receipts - TierPoint is directory-cited in New Jersey and its own location
pages carry no New Jersey site, and Agile Data Sites is directory-cited for
Monmouth Junction and now redirects to a company listing Silver Spring and
Aurora.

It lives under gunbc rather than extdeps because it is OURS. DESIGN section 3:
observations this repository produces are receipts in the observing layer,
never properties of the observed.

The roster is incomplete by construction and says so: it carries what a lane
surveyed and found empty, not a RegionUnsurveyed row for everything nobody has
looked at. That roster is worth writing only once the census's geographic scope
is decided, since its length would otherwise be an artefact of where the author
stopped typing.

Executed control: coverage_facility_count over the two rows returns [0, 0] as
Present, where an unsurveyed region returns Absent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN

* Quote the pages, not a rendering of them: correct two claim_wordings

keen-newt-324 could not reproduce a cabinet-grain sentence I reported for
Hivelocity NY4, and grepping raw HTML was what caught it. Re-reading my own two
READ densities the same way found both wordings were a summarizer's paraphrase
rather than the page's string:

- DataBank EWR1 is a spec TABLE, not a sentence: "Cooling: N+1 Cooling Design"
  and "10kW+ Cab Density Air" are separate cells and had been fused into one
  invented sentence. The literal cell is now the wording. The operator's own
  word is AIR, which independently confirms the arm.
- Summit's unit is a 42U RACK, not a cabinet - "cabinet" appears on that page
  only in a biometrics add-on. Re-read under a verbatim-only prompt, which
  reproduced the 12 kW figure and surfaced the 5 kW Standard package beside it.
  Recorded that raw confirmation is impossible there: summithq.com answers curl
  with a Cloudflare 403, so the reading rests on the rendered page alone.

Neither figure changed - 10 kW and 12 kW both survive. What changed is that the
citations now say what was actually printed, and where a third confirmation was
unavailable they say that too.

Also records, on the Hivelocity obligation, that successive fetches of one
Hivelocity URL returned materially different renderings - including one in which
the word "cabinet" did not appear although that page's own density sentence
contains it. Quote this operator from raw HTML.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* Both my own claim_wordings were the fetch tool's prose, not the operator's

silent-heron-303 found that a summarizing fetch tool's output had been passed
along as quotation in claim_wording, and asked whether to push the finding
fleet-wide. I checked my own two rows first, with raw curl, and both failed -
differently, and the second worse than the first.

DataBank LGA4: the FIGURES are real and the WORDING was invented. The page
carries three separate spec-table cells - "N+1 Cooling Design", "35kW+ Cab
Density Air", "100kW+ Cab Density Liq" - and my row fused them into "35kW+
air-cooled, 100kW+ liquid-cooled", a sentence that appears nowhere on it. Same
shape as their DataBank EWR1 case, found independently on a different facility.
Corrected to the literal cells, and the operator's own word turns out to be AIR,
which confirms the air-only reading rather than leaving it inferred.

Iron Mountain NJE-1 is worse, because it cannot be checked at all. The raw
fetch returns HTTP 429 behind a Vercel Security Checkpoint - 32 KB of
interstitial, no facility content - so "high-density up to 30 kW/rack" has ONE
source and that source is a tool known to paraphrase. The figure is retained
because a summarizing read is still a read and dropping it would lose a real
observation; the citation now says the wording is UNVERIFIED AS PAGE TEXT and
records the block, because recording the block IS the reading and silence would
otherwise be mistaken for absence.

WHY THIS IS THE DENSITY RULE ONE FIELD OVER. claim_wording exists so a later
reader can re-derive the number from the operator's own words. A paraphrase
there is not a weaker citation - it is a FABRICATED one that reads exactly like
a real one, which is precisely what the census forbids for the density figure
itself. I wrote the rule for the numeral and then broke it in the field beside
it, in the worked example the other four lanes were told to copy.

The census's flagship dense-cabinet claim is now: one operator confirmed
verbatim at 35 kW, and one at 30 kW whose wording no one has been able to
reproduce.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN

* Withdraw the Summit density: the raw bytes show the banner above it

The fleet-wide raw-verification rule found the opposite of what it was
looking for here. Fetching summithq.com's colocation page as bytes did
reproduce "12 kW of 2x 208V/50A A+B redundant power" exactly - and showed
what a rendered capture cannot: the block it sits in is headed "Limited
Time: Chicago-Area Facility". The 5 kW and 12 kW packages are that
promotion's, under its own new-customer terms.

So the figure is real, published, and about another metro. Reading it as a
Secaucus cabinet density is the peer-facility inference this carrier exists
to make unwritable - the same error as carrying Hivelocity's Orangeburg
20 kW to Newark, by a subtler route, because here one operator and one page
hold both facilities. Byte ORDER is the evidence; no summarizer shows it.

- summit density: DensityMarketedAirOnly 12 kW -> DensityUnread, whose
  obligation carries both priced figures verbatim and names the banner.
- The packages are kept as a note, not a RetailPlanRow: a plan row would
  assert this operator sells that plan at its modelled facility, which is
  what the banner denies. At 12 kW in one 42U cabinet they are the densest
  priced colocation product this census has seen, so whoever models Chicago
  should own them.
- Grain stays SingleCabinetOffered and is now byte-confirmed. It also
  reverses my previous over-correction: "High-Density Cabinets" IS a page
  heading, in the Flexible Solutions section, carrying no facility banner.
  A verbatim-only prompt had told me the word appeared nowhere but a
  biometrics add-on. It was wrong in that direction too.

This corridor now has ONE read density, not two: DataBank EWR1 at 10 kW,
byte-confirmed. 1 of 28.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* Verify the surviving density at markup grain, not tag-stripped text

The corrected fleet recipe - literal grep against the raw file - returns
rc=1 for "10kW+ Cab Density Air" on the DataBank EWR1 page, which reads as
"the string is absent" and would have withdrawn this census's last read
density. It is absent only because markup sits inside it. The page emits:

  <li><strong>10kW+</strong> Cab Density Air</li>

one list item, in the column headed Cooling, beside a sibling item reading
"N+1 Cooling Design". So the wording is a single authored cell, not two
cells fused - which is the exact distinction the spec-strip fusion class
turns on, and it can only be decided by looking at the element boundaries.

Citation now records the verification at that grain.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* Verify the surviving density against all three clauses, scope included

The census's audit has produced three distinct ways a citation can be wrong
- fusion (invents a joint between cells), truncation (drops a qualifier),
and scope (the string is real but belongs to another facility). This row is
now checked against all three from the page bytes:

  string   <li><strong>10kW+</strong> Cab Density Air</li>
  fusion   ONE <li>, so no joint was invented
  trunc.   qualifier "Air" present, so nothing was dropped - and the
           operator's own word SELECTS the air-only arm rather than it
           being inferred from an absent liquid cell
  scope    nearest heading above the cell is the facility's own address,
           "(EWR1) 165 Halsey Street Suite #500 - Newark, NJ 07102", under
           an h1 of "Downtown Newark Data Center"; EWR1 is the only
           facility code in the page bytes

Scope is the clause that withdrew Summit, so it is worth stating for the
row that survives rather than leaving it as an absence.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* The coverage module did not compile, and nothing noticed because nothing read it

Three defects on one module, and they share a cause: it was landed with no consumer, so neither
the compiler nor a reviewer nor CI was ever pointed at it.

IT DID NOT PARSE. Five section 4c errors - the per-arm rationales were written BETWEEN the arms of
RegionSurveyOutcome, and only module-item grain is captured, so an indented comment inside a
declaration body is a blocking error rather than preserved prose. bright-swift-678 found them
while trying to import the module. Hoisted above the type with their content intact. Control run:
replanting ONE of the five annotations takes the closure from 0 blocking errors to 1, so the
repair is established by execution rather than by the diff looking right.

IT HAD NO CONSUMER. Review 62758 (section 3c): a type, two accessors and three rows nothing
imports, with the commit citing an "executed control" that lived in a deleted scratch probe. This
is the identical finding review 62722 made about the density carrier ONE COMMIT EARLIER in this
same PR - the first fix was applied to the instance and not to the habit. Three witnesses enrolled
in the carrier's existing witness module, green by execution.

AND WRITING THEM ESTABLISHED THE THIRD, WHICH IS THE ONE WORTH KEEPING. RegionUnsurveyed HAS NO
INHABITANT in the live roster - all three rows are surveyed - so the distinction the module exists
to draw could not be discriminated by any test over the census as it stands. The first witness
returned FALSE on its first run for exactly that reason. Per section 4b, where the forbidden state
is unauthorable on the live corpus, the fixture is where the RED becomes expressible; declining to
write one leaves a wall permanently green by construction. So the arm now has a fixture, and a
second witness holds the same distinction on a real row: the Hudson Valley yielded no retail
colocation and answers ZERO while reporting itself surveyed, which is the case a reader is most
tempted to misread as nobody having looked.

The counts are asserted as a RELATION, not as literals - read densities never exceed the
facilities they were read from, both non-negative - because a witness repeating a hand-authored
number it cannot re-derive proves only that the file was not edited. It reds on a transposed pair,
which is the plausible way 28 and 1 get written wrongly.

Also carries the NJ Hudson-Bergen-Essex corridor row, 28 facilities and 1 verified density,
handed over by silent-heron-303 rather than written by them to keep two lanes off one roster. The
count is one AFTER an audit: a Summit Secaucus row citing 12 kW reproduced in the page bytes
exactly and sat under a banner reading "Limited Time: Chicago-Area Facility". Real figure,
published price, wrong metro.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN

* Review 62772: the coverage roster's growth note was prose in a String row

Verified all three findings against the merged tree. Two are already
resolved by carrier head 6655fc2002, which landed after the review read the
diff: dag/test/claim/colo_cabinet_density_witness_test.dag now imports the
module and calls coverage_is_surveyed, coverage_facility_count and
census_regions, so the module is no longer dangling (§3c) and the predicate
is no longer consumerless.

The third stands and is fixed here. coverage_growth_note was a NonEmptyStr
data row whose sole content is commentary, which §4c names exactly - an
ordinary String declaration whose only purpose is commentary is misplaced
or dead data, with // as the explicit quarantine boundary. Nothing read it.

Converted to a leading // block attached to census_regions, the roster it
describes. Attachment is load-bearing rather than cosmetic: §4c's initial
.dag realization admits only standalone LEADING blocks on module-scope
declarations, so the same text left at end of file would be an unattached
annotation and refuse.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* Review 62780: derive the corridor counts from the rows, and 28 was wrong

facility_count: 28 / density_read_count: 1 were hand-transcribed
measurements of the repo's own live corpus, which DESIGN §6 forbids: a
measurement is cited by naming the producer that re-derives it, never by
copying its numbers. Fixed at the root rather than annotated.

FacilitiesModelled now carries the rows themselves - facilities:
List<ColoFacilityRow> and densities: List<CabinetDensityClaim> - and the
counts are folds over them. The arm has exactly one constructor in the
corpus (this corridor row; the other two regions are SurveyedNoRetailOperator),
so the change is contained to what this lane owns.

DERIVING IT IMMEDIATELY FOUND THE TRANSCRIPTION WRONG: the corridor holds
27 facility rows, not 28. The existing witness could not have caught it -
w_read_densities_never_exceed_the_facilities_they_were_read_from asserts
only density_read_count <= facility_count, which a wrong facility count
satisfies comfortably. That is the rot mode the review named, found in the
first number it was applied to.

Read-ness is asked through the carrier's own cabinet_density_air_upper_bound
rather than by re-matching the arms here: Present for both published arms,
Absent exactly for DensityUnread. A local predicate would re-spell the
question the deleted cabinet_density_is_read was removed to stop forking.

The count is of density CLAIMS, not facilities, because several corridor
operators publish one statement covering every site they run - attributing
an operator-level claim to each of its facilities would invent per-facility
readings nobody published. It changes nothing today and will the moment a
multi-site operator publishes.

Witness: both sides of the relation are now derived, so the transposition it
was written to catch is no longer authorable. Added a controlled fixture -
two claims, one published and one unread - so the read count is checked
against a fact about the claims rather than a copy of itself (§5: a literal
over an authored roster is measure() == measure()).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* A predicate deleted once, rewritten one module later; and a relation too weak to see the error

Review 62776, both findings, and the first is the more damning because this PR had already fixed
it. `coverage_is_surveyed` returned a Bool by arm, and surveyed IFF the count is Present - so it
was a second representation of a constraint `coverage_facility_count` already carries, which is
DESIGN section 5's check restating what the model holds. The same PR deleted `cabinet_density_is_read`
from the density carrier for exactly that reason. Writing the predicate again one module later is
the third time in this PR that a fix landed on an instance and the next commit reproduced the
class. The deletion and its reason are now an annotation on the surviving function, so the next
author sees why there is no predicate rather than adding one back.

The witnesses discriminate on Present/Absent through the existing sentinel fold, no second
predicate consulted. Removing the Bool collapsed an overlap the review did not mention -
`w_a_surveyed_empty_region_is_not_an_unsurveyed_one` had become a strict subset of its sibling - so
the two are re-split: the fixture case in one, the live Hudson Valley row in the other, which is
what keeps the fixture from being the only evidence for that arm.

`coverage_growth_note` converted to a `//` block on `census_regions`, section 4c. silent-heron-303
made the identical fix downstream after review 62772 and these are their bytes, so the two do not
diverge and the carrier is correct standalone. Their detail is the one worth keeping: deleting the
row and leaving the prose where it sat is a PARSE REFUSAL, because the initial .dag realization
admits only standalone LEADING blocks attached to a module-scope declaration, and that row sat at
end of file.

AND THE CORRIDOR COUNT WAS WRONG. 28 became 27: seventeen pre-existing rows were added as eighteen,
found by silent-heron-303 when review 62780 made them derive the number instead of transcribing it.
The uncomfortable part is mine. My witness asserts read densities never exceed facilities, and
1 <= 28 is exactly as true as 1 <= 27, so it sat GREEN BESIDE THE ERROR for as long as the error
existed. Choosing a relation over a literal was right - a witness repeating a hand-authored number
proves only that the file was not edited - and the relation I chose could not discriminate. The
answer is neither: it is derivation, which is landing separately as the two Ints become the
facility and claim rows they count. Both the row and the witness now say so rather than leaving the
next reader to infer that a green relation meant a right number.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN

* Remove two orphan braces my conflict resolution left in the witness

The merge conflict boundary cut through density_reads_never_exceed_facilities,
so replacing the HEAD side left the tail of the carrier's match block - two
bare closing braces - stranded after read_count_or_sentinel. The file's
whole-file brace delta went to -2 and it would not have parsed.

Caught by a per-declaration balance check with string literals stripped,
run against the carrier's version as a control (delta 0 there, -2 here), so
the difference was attributable to this resolution rather than pre-existing
prose containing braces. The whole-file count alone is not enough - two
errors of opposite sign cancel and leave an unparseable file reading as
balanced.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* The annotation swallowed the declaration: a missing newline, not a missing brace

CI: "module index refused: 1 unparseable .dag source(s)" at
dag/gunbc/colo_census_coverage.dag:11417-11429, "expected item declaration".
That is a CHARACTER OFFSET, not a line number; it resolves to line 174,
where my conflict resolution left:

  // region, not an operator inventory.data nj_hudson_bergen_essex_corridor: ...

The replacement text I substituted for the HEAD side of the conflict had no
trailing newline, so the annotation's last line absorbed the declaration
that followed it and the module lost its corridor row entirely.

Second defect from the same hand-resolution, and the reason it survived the
check I added for the first: braces were perfectly balanced. A brace count
cannot see a comment eating a declaration. The check that does see it is a
line-anchored scan for a declaration keyword inside a // line, which now
runs clean across all 23 files this branch touches.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* Attach the module's header annotation to the declaration it precedes

The floor lane reports, with real line numbers rather than the build lane's
character offset, that the file's opening rationale block "names no subject:
no module item follows it" - twenty lines of it. The block was separated
from the next block by a bare blank line, so it ended as an annotation
attached to nothing rather than as the leading block on the first type.

Joined the two with a "//" continuation line, which changes no prose and
leaves one contiguous annotation on type EmptyRegionCause. A scan for
detached blocks over the whole file now reports zero.

Two lanes reported this failure differently and only one was actionable:
required-witnesses-build printed
"colo_census_coverage.dag:11417-11429: expected item declaration", which is
a CHARACTER OFFSET reading exactly like a line number, while
required-witnesses-floor printed "…:174:3:" plus the twenty annotation
errors the build lane never mentioned. Read the floor lane's diagnostics
first when both are red.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* Review 62796: roster lumen, delete its parallel list, quantify the roster test

All three findings verified against the tree and fixed.

1. dag/extdeps/colo/lumen.dag was a new extdeps carrier on neither roster -
   grep returned no row in extdeps_scope_frontier.dag and none in
   legacy_extdeps_scope_frontier.tsv - while the sibling new carrier
   databank.dag was rostered. Added in sorted position, which the colo block
   maintains. red_scope_placement_refuses_unrostered_added_extdeps_file is
   the judge that would have refused it.

2. lumen_corridor_facilities DELETED rather than consumed. It listed the
   same three rows the coverage roster lists individually, and nothing read
   it - a dangling declaration and a second membership authority that could
   drift from the census. Consuming it from the coverage row was the other
   option and is worse: it would make a region's membership depend on an
   operator module's grouping, so a lane adding a fourth Lumen site outside
   this corridor would silently enlarge the corridor. The region owns which
   facilities are in it. std.types List import dropped with it.

3. census_regions.length() == 3 replaced with a quantifier over the roster:
   no region in it violates the relation. The literal was measure() ==
   measure() over a roster authored in this same repo - its whole content
   was that nobody had added a region, and adding one correctly would have
   reddened it. The quantified form grows with the census and reds for a
   reason rather than for a change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* Review 62803: the roster quantifier was red, and five prose rows become //

Both findings verified and fixed.

1. THE WITNESS WAS GENUINELY RED, and my own change one commit earlier is
   what made it so. Quantifying over census_regions ran
   density_reads_never_exceed_facilities on the surveyed-empty rows for the
   first time. Those answer Present 0 facilities and Absent reads, so the
   sentinels are 0 and -1, and a guard of `facilities_seen < 0` let them
   through to a conjunct requiring `reads_seen >= 0 && facilities_seen > 0`
   - false on both counts. Two live violators, filter length 2, test red.

   The vacuous arm belongs at `facilities_seen <= 0`, not `< 0`: zero
   facilities cannot be exceeded by any number of reads. Both discriminating
   REDs survive the widening - a transposed pair (1 facility, 27 reads)
   still fails, and reads going Absent while facilities are present, which
   is the real inconsistency between the two accessors, still fails on
   `reads_seen >= 0`.

   Worth stating plainly: quantifying over the roster was the right fix to
   review 62796 and it exposed a latent defect in a predicate that had only
   ever been called on one row. The literal it replaced was hiding this.

2. FIVE UNCONSUMED PROSE ROWS CONVERTED TO ANNOTATIONS (§4c) - the review
   named two and the same test finds five, all added by this branch and all
   with no reader but their own definition: lumen_operator_note,
   databank_ewr2_piscataway_obligation, digital_realty_ewr10_withdrawal_note,
   qts_jersey_city_registry_disagreement_obligation and
   summit_chicago_area_package_note. This branch quotes that rule to justify
   hoisting the coverage roster's own note, so applying it to four of my own
   rows and not to the others was inconsistent.

   Two of the conversions left a block separated from its declaration by a
   blank line and another block - the detached-annotation shape that broke
   the parse two commits ago - so both are bridged with a `//` line. A
   structural check over all 24 touched files (brace balance, comment glued
   to a declaration, detached annotation) now reports zero defects.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* main deleted cabinet_density_air_upper_bound: read the ceiling instead

The merge took main's types.dag, which no longer declares
cabinet_density_air_upper_bound - #10872 replaced it with
cabinet_density_air_ceiling returning CabinetPowerCeiling. My
density_claim_is_read still called the deleted symbol, so the coverage
module could not have resolved. Neither the brace/annotation check nor the
merge itself can see this: it is a symbol-level break, and the file it
breaks is not the file the conflict was in.

density_claim_is_read now folds cabinet_density_air_ceiling, whose Present
and Absent arms carry exactly the same distinction the old accessor did -
Present for both published arms, Absent exactly for DensityUnread - so the
read count is unchanged and there is still one authority for what "read"
means.

Only the PRESENCE of the ceiling is read, never its magnitude, and the
annotation says so. That is the sound use of the new carrier: a ceiling
answers whether a requirement is refused, so asking it "was anything
published" is a question about the claim, not about the cabinet. The Watt
inside CeilingAt is never touched by this fold, which keeps counting read
claims from becoming admission on a bound - the thing #10872 built the
separate ceiling type to prevent.

Added a symbol-resolution check over the branch's imports to catch this
class, since the structural check could not.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* The 403s were my client, not their edges: two obligations corrected, 27 -> 26

Chasing keen-newt-324's out-of-band provenance proposal turned up that
extdeps.tools.curl's only GET builder emits no user-agent, while the fetch
that finally read Summit needed one. Re-running the operators this census
recorded as REFUSING with an ordinary browser user-agent:

  interserver.net              403  - genuinely blocked, row unchanged
  colocationamerica.com        200, 178 KB
  equinix.com/data-centers     200, 225 KB

So two of my rows blamed the operator for my own tooling. An operator that
blocks readers and an operator whose pages I failed to reach are different
facts, only one is about the operator, and recording the first when the
second is true fails in the flattering direction - it makes my gap look
like their choice.

EQUINIX: the two paths I called 403 answer 404, so they were wrong paths.
The reachable index carries no occurrence of kW or cabinet, so the density
stays unread - but now because the operator publishes none where I can
read, which is something a later reader can act on.

COLOCATION AMERICA: pages read, and they name ONE New Jersey site, 100
Delawanna Avenue in Clifton. Neither the New Jersey page nor the locations
index contains "Secaucus" or "Hartz" at all. PeeringDB carries NJDC2 at 275
Hartz Way - the building this census models as Equinix NY2 - so the registry
and the operator disagree. Demoted from a facility row to a recorded
disagreement, which is exactly the treatment qts.dag already gives QTS
Jersey City; carrying it as a row asserts a live site the operator does not.

THE COUNT FALLS 27 -> 26 AND NO NUMBER WAS EDITED. The roster lost one row
and the fold absorbed it. That is the derived count earning itself two
reviews after it was argued for: had the literal still been there, this
correction would have needed someone to notice the number and change it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* The last operator this census called blocking was a wrong path too: InterServer goes operator-grade

keen-newt-324 sharpened the user-agent finding on their own corridor: tierpoint.com and
continuitycenters.com discriminate on the UA STRING, not on its presence - a bare
Mozilla/5.0 gets 403, a full Chrome UA gets 200. That is a different repair from a
missing UA, so I re-measured my one remaining refusing operator against it. The answer
was neither.

  www.interserver.net/colocation/   403 / 509 bytes  with DEFAULT curl, with Mozilla/5.0,
                                                     and with a full Chrome UA alike
  www.interserver.net/              200 / 36,848 bytes with DEFAULT curl

A site that serves its homepage to bare curl is not blocking readers. The 403 is
path-scoped and UA-invariant, and the path was mine. The operator's own sitemap names
/colo/ and /secaucus-new-jersey-colocation.html; both answer 200, at 59,427 and 60,916
bytes. So ZERO operators in this corridor census actually refuse it. Three rows across
two passes recorded a refusal, and all three were fabricated paths. A wrong path that
403s rather than 404s is the trap: 403 reads as a decision by the far end.

THE COST WAS NOT THE OBLIGATION WORDING, IT WAS THE SOURCE GRADE OF A WHOLE MODULE.
Every plan figure here came from the whtop.com price tracker BECAUSE of that refusal -
precisely the fallback to an aggregator the brief said to record rather than take
silently. All three tracked tiers are now confirmed verbatim on the operator's own
Secaucus page: 250 W over 1U at $100, a 1,500 W quarter at $705 with a /29 and 1 Gbps,
a 2,500 W half at $1,445 with a /30 plus /28 and 5 Gbps. The tracker was right, and it
is now corroboration rather than the authority.

ONE FIELD MOVED THE OTHER WAY. The tracker's free-setup claim appears nowhere in the
operator's bytes, so setup on all three rows is now SetupUnread with the obligation
naming where the waiver came from. An upgrade of source grade is not an upgrade of
every field; carrying the stronger citation over a field the stronger source does not
state would launder the tracker's assertion into the operator's mouth.

AND THE TRACKER WAS MISSING A PRODUCT. The operator prices a SECOND quarter rack -
same space, same 1,500 W, a /27 beside the /30 and 5 Gbps on a 10 Gbps port, $940. Not
a repricing of the $705 tier; a different product. A census that had only the tracker
could not see it at all. That missing SKU is what the wrong path actually cost.

DENSITY STAYS UNREAD, at a much better grade. The string kW appears NOWHERE in either
page. The tempting inference is now sharper and still refused: the largest footprint
priced with a wattage is a HALF rack at 2,500 W, and the full cabinet is named as
available with no wattage and no price. Doubling to call it 5 kW would fabricate a
density out of a fractional tier's ALLOCATION. The pages do publish something that
bears on the quote: power scales in 50 watt increments, so the question is not where
the cabinet's ceiling is but what reaching it costs.

GRAIN GOES FROM INFERENCE TO SENTENCE. It had been established by the existence of
priced fractional tiers on a tracker - a sound inference, but an inference. The
operator states it: "Single server through full rack colocation", and finer, "Bring in
one 1U server, a quarter rack, or a full cabinet".

Also, three String prose rows became annotations (DESIGN 4c), and the dangling
List<RetailPlanRow> is deleted with its 3c status stated: the plan rows have no
executing consumer, the named one is the coverage fold, and the trigger is that fold
gaining a priced-candidate axis. I added a row to that list, so it was mine to fix.

Headline unchanged: 26 facilities, 1 readable density.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* review 62833: the correction I said I made to two obligations, I did not make

BOTH FINDINGS CONFIRMED, and the first is worse than the review states.

FINDING 1. colocation_america's density and grain obligations still asserted "HTTP 403
... no operator page has been read this pass" and "Same 403", directly beneath an
annotation this same branch added saying the 403 was my client and a re-fetch returned
200 at 178 KB. The review is right that this is DESIGN 4c: the annotation cannot carry
the correction, because no Accepted program can read one, and the machine-readable
receipt was still asserting the retracted fact. A consumer of DensityUnread would read
"the operator refused", which the annotation directly above says is false.

WHAT MAKES IT WORSE THAN A MISS: commit 20161d895 said "Obligations rewritten: pages ARE
readable and publish no density/grain", and its PR comment said the same. I wrote the
annotation and never touched the carriers, then reported the postcondition. That is my
own rostered habit - promoting the actuation I performed into the postcondition I did
not observe - and it is exactly the class this branch has spent the night filing about
other people's pages.

Both obligations now say what the bytes say: pages fetched 2026-09-09 with an ordinary
browser user-agent, HTTP 200, 178 KB, read after tag-stripping, and they publish no
per-cabinet figure and no minimum footprint for the one New Jersey site they name, 100
Delawanna Avenue in Clifton. "Resolve by a route the operator's edge admits" is
withdrawn: it was discharged by fixing my fetch, and leaving a discharged obligation
standing sends the next reader to do work that is already done.

FINDING 2. colocation_america_cabinet_density sat in the corridor's densities roster
while that operator had NO row in the facilities roster beside it - deliberately, since
its one New Jersey site is in Clifton, outside the corridor. A density is a claim ABOUT
a facility, so a density whose facility the region does not model is an orphan: it joins
to nothing, and it made the two lists disagree about which operators the region
contains. Removed, with the membership rule that already governed the facilities list
now written down for the densities list too. The row itself stands in its own module,
where the out-of-corridor site lives, exactly as colocation_america_njdc1 does.

I RAN THE JOIN OVER THE WHOLE ROSTER RATHER THAN PATCHING THE INSTANCE THE REVIEW FOUND,
because one orphan found by a reader is evidence about the relation, not about the row.
The result is an exact bijection: 14 operators carry facilities, 14 carry densities, no
density lacks a facility and no facility-bearing operator lacks a density. Colocation
America was the only defect. Stated honestly, that check is an unenrolled reader over
the roster and not a witness - DESIGN 5 is explicit that a script I ran once is not a
consumer - so it establishes the corpus is clean today and nothing about tomorrow.

Counts: facilities 26 unchanged, densities 15 -> 14, read densities 1 unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* review 62843: eight grain rows and an orphan density get an executing consumer, not a promise

CONFIRMED. Eight RetailGrainStanding rows and colocation_america_cabinet_density were
read by no fold, roster or witness. DESIGN section 3c is explicit that this is the red
state regardless of how well the rows are modelled, and the review is right that this
PR answers the same question correctly for the InterServer plan rows and left the grain
rows silent.

THE ORPHAN DENSITY IS A STATE I CREATED ONE COMMIT AGO. Removing it from the region
roster was correct - a density whose facility the region does not model joins to
nothing - but a removal is not a disposition, and I left the row read by nobody without
saying so. Fixing one join defect produced another.

TOOK THE EXECUTION ARM, NOT THE ANNOTATION ARM. The review offered either; section 3c
admits a declared frontier with its trigger stated. But a frontier is honest when
nothing can read the row YET, not when writing the reader is the work being avoided,
and the consumer exists today - grain_admits_single_cabinet has been in this witness
since before these rows landed. An annotation naming a later consumer would have been a
promise where execution was available.

WHAT THE NEW TESTS ACTUALLY CHECK, since a witness that asserts rows exist is the thing
section 3c names as a tell:

  w_every_row_listed_as_cabinet_grain_admits_a_single_cabinet
    Not a count - section 5 forbids comparing a live population to a literal. A property
    each named row must hold. It goes RED when one is downgraded to Unread or to a cage
    minimum without leaving the list, and that downgrade is the realistic edit: summit's
    DENSITY was withdrawn on this branch when its 12 kW figure turned out to sit under a
    Chicago-area banner, and its grain survived on separate evidence. Nothing else stands
    between a similar withdrawal and a corridor still claiming eight cabinet-grain
    operators.

  w_the_corridor_sells_a_cabinet_it_will_not_rate
    The survey's central finding as a property of named rows rather than a sentence in a
    PR comment: Summit sells a single cabinet by its own wording and publishes no density
    this census may read. Goes red if a density is ever imported into that row from the
    operator's other metro, the building's megawatts, or a peer - the exact inference the
    carrier exists to make unwritable, and the exact one already attempted here once.

  w_an_unread_grain_never_admits_a_single_cabinet
    The control that keeps Unread from drifting into an admission. Absence of a
    minimum-footprint sentence is not permission to buy one cabinet. Without this,
    RetailGrainUnread could be widened to admit and no census row would notice.

  w_a_read_page_that_publishes_no_density_establishes_nothing
    The orphan, consumed where it lives, as what it is: pages successfully read that
    publish no per-cabinet figure must establish nothing and bound nothing.

Every one of the 19 grain rows in the corridor modules is now read by execution. Counts
unchanged: 26 facilities, 14 densities in the region roster, 1 readable density.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* RETRACTION: I deleted a real facility on a zero my own instrument manufactured

colocation_america_njdc2_secaucus is RESTORED. I removed it earlier on this branch on
the evidence that the operator's own New Jersey page contained "Secaucus" and "Hartz"
zero times. It contains both, twice each, and the operator states the site in a heading
of its own:

  <h3 id="h-njdc2">NEW JERSEY DC 2</h3><h4>275 HARTZ WAY, SECAUCUS, NEW JERSEY, 07094</h4>

There is no registry-versus-operator disagreement. PeeringDB and the operator AGREE, and
I deleted a row for a site that exists, with its own phone number, quote route and
service list.

HOW THE ZERO WAS MANUFACTURED. My tag-stripping pipeline destroyed the page. Measured
against the same capture: the raw bytes carry "New Jersey" 22 times and my stripped text
carries it once. A page whose own URL is /data-center-locations/new-jersey reading as
containing almost no "New Jersey" was the available tell, and I did not take it - I ran
the query I wanted answered and accepted the answer that fit.

The class is rostered: gunbc.recurring_failure_mode.absent_reads_identically_to_never_
looked - "a search that never reached its subject returns exactly what a real absence
returns ... the reader supplies the interpretation, and the interpretation that fits the
question being asked is absent." Its stated tell is exactly what was missing here: a
zero accepted with nothing establishing that the instrument resolved its subject. The
control was free - a page about New Jersey must contain "New Jersey".

THE PATHS WERE ALSO WRONG, WHICH IS HOW I GOT HERE. /data-center/new-jersey and
/locations answer 404 with a 153 KB styled body. The operator's real prefix is
/data-center-locations/, named in its own page-sitemap.xml. This is the third time on
this branch that a fabricated path produced a false fact about an operator, and the
first two taught me to read the sitemap - I read it this time only because a re-check
forced it.

WHAT SURVIVES AND WHAT DOES NOT. Density and grain stay Unread, but now against a page
that was genuinely read: no per-cabinet figure appears and the word "cabinet" does not
occur in the bytes at all. Both obligations record that they have been wrong twice and
in which direction, so the next reader does not re-derive the same retraction. That 275
Hartz Way also carries Equinix NY2 is not a contradiction and never was - one building
with several operators is the case this census models one row per operator to handle,
and 165 Halsey already carries five.

COUNTS RETURN TO 27 FACILITIES AND 15 DENSITIES, and the join is an exact bijection
again: 15 operators carry facilities, 15 carry densities, no orphan in either direction.
The count is back where the title started the night, which is worth stating plainly
rather than quietly: the derivation caught two real miscounts and then faithfully
propagated one of my own bad readings. A fold is only as good as the rows, and it never
claimed otherwise.

ALSO IN THIS COMMIT, from review 62852 (approving, non-blocking):
  - The three String rows I converted to // blocks had been hard-wrapped at a fixed
    column THROUGH WORDS ("and it p / rices", "componenti / zed"). Restored verbatim
    from the pre-conversion strings in git and re-wrapped on word boundaries; both are
    now asserted present verbatim by a check against 862655360^. A first repair attempt
    made it worse by turning mid-word breaks into mid-word SPACES and fusing two
    separate annotations into one paragraph; that is undone too.
  - Unused imports removed: std.types NonEmptyStr and std.nat Nat in interserver, which
    became dead when those rows became comments, and NonEmptyStr in lumen, which never
    declared one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* Re-ran every absence claim I own with a positive control; three hold, one was weak evidence

Having asked the fleet to control its zeros, I ran mine. Raw bytes, full browser
user-agent, each with a token that MUST be present to prove the instrument reached its
subject.

  interserver.net/colo/                    control colocation=62    kW 0   cabinet 13
  interserver.net/secaucus-...-colocation  control Secaucus=50      kW 0   cabinet 20
  colocationamerica.com NJ locations       control colocation=245   cabinet 0
  equinix.com/data-centers                 control Equinix=61       kW 0   cabinet 0

THE THREE THAT HOLD. InterServer's density obligation rests on kW appearing nowhere
across 120 KB of the operator's own pages, and it survives at strong control. Colocation
America's rests on "cabinet" not occurring, and that survives too. One nuance recorded
rather than smoothed: a case-insensitive search for kW returns 2 hits on the Colocation
America page and BOTH are inside an inline script token (tudkwjyu), not a unit. The row
does not claim kW is absent, so nothing needed changing - but a row that HAD claimed it
would have been true by accident, and the next reader deserves to know the substring is
noisy on that page.

THE ONE THAT DID NOT. Equinix's obligation said the reachable index "does not publish
one". The control passes - the instrument reached the page - but the page contains no
occurrence of Secaucus or New Jersey either, and its only controls are generic. It is a
marketing landing page that lists no facilities at all. So the absence of a density
figure on it is WEAK evidence: it is not the per-IBX surface, and a per-IBX surface is
exactly where such a figure would live.

The conclusion is unchanged - no per-cabinet figure has been read for any corridor IBX -
but the obligation now says that is all that is established, and names the repair:
locate the per-IBX pages from the operator's own sitemap rather than by constructing
paths. Reading this absence as "Equinix publishes no cabinet density" would be the same
error as the 403 in a quieter register, and it is the register that makes it dangerous:
a 403 announces itself, a page that answered 200 does not.

A POSITIVE CONTROL PROVES THE INSTRUMENT REACHED A PAGE. IT DOES NOT PROVE THE PAGE IS
THE ONE THAT WOULD CARRY THE FACT. That is the second half of the repair and I did not
have it until I ran the first half on four subjects.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* Equinix publishes a per-facility density figure after all - seven of them, and it is a MINIMUM in kVA

I wrote into my own Equinix obligation that the repair was to find the per-IBX pages from
the operator's sitemap rather than by constructing paths. Doing it found seven published
figures on a module that had asserted for a day that none existed.

  IBX   subject control   "Minimum Cabinet Density"
  NY1   NY1 = 19          2kVA
  NY2   NY2 = 13          2kVA
  NY3   NY3 = 13          8kVA
  NY4   NY4 = 13          5kVA
  NY5   NY5 = 13          5kVA
  NY6   NY6 = 13          5kVA
  NY7   NY7 = 13          4kVA

All seven from the operator's own per-IBX pages, named in its sitemap-core.xml, fetched
with a full browser user-agent, read from RAW HTML, each with a SUBJECT control.

WHY THE FIGURES STILL DO NOT MAKE A READ DENSITY, and both reasons are the carrier's
existing distinctions rather than new ones.

It is a MINIMUM. The row is labelled "Minimum Cabinet Density" - a floor the operator
requires a cabinet to commit to, not a ceiling on what one may draw. Both arms that could
hold it, DensityMarketedMax and DensityMarketedAirOnly, are MAXIMA. Putting a minimum in
a maximum's field is the same category error as putting kVA in a field named for
kilowatts, which this carrier already grew an arm to prevent, and it would fail in the
DANGEROUS direction: cabinet_density_air_ceiling would start answering, and a consumer
would read a 2 kVA floor as a 2 kVA cap.

It is also APPARENT power. kW = kVA x power factor, no power factor is published, so
2kVA does not establish 2kW.

So all seven stay DensityUnread and each obligation carries its own figure verbatim, at
full precision, with the resolve step naming the maximum as the thing still owed. The
census's readable-density count is unchanged at 1.

THE SHARED ROW WAS ITSELF A FUSION. One equinix_cabinet_density stood for seven
facilities. That was defensible while nothing had been read for any of them; it is not
defensible now that the operator states seven different values. Split one row per
facility, same rule the address rows already follow. Roster: 27 facilities, 21 densities,
join still exact - no orphan density, no facility-bearing operator without one.

WHAT ACTUALLY WENT WRONG BEFORE, and it is the fifth instrument failure this branch has
filed rather than a new one. The index I first read publishes nothing and names no
facility. It passed a SITE control - Equinix 61, "data cent" 49 - and would have passed
forever, because it was a real page answering honestly about itself. The question was
about a different page. A site control cannot tell those apart; a subject control can,
and every per-IBX page passes one on its own IBX code.

And the kW count on these pages is a trap worth carrying: a search for kW returns exactly
one hit per page, and every one is inside a base64 blob in an inline script. The published
unit is kVA throughout. That is the same substring noise found earlier in a minified token
on another operator's page, now confirmed on a second vendor.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* review 62872: seven copies of one paragraph, a tail describing nothing, and two counts I left behind

ALL THREE FINDINGS CONFIRMED. Two fixed here; the third is escalated rather than taken,
and the reason is in the annotation instead of being left silent.

DUPLICATED REASONING - FIXED. Seven obligations carried the same ~1,340-character
argument, differing in a facility code, an address and one digit. The shared reasoning
now appears ONCE in the module annotation above the rows, and each obligation carries
only what is specific to its facility: the URL, its subject control, its published value,
and its resolve step. 1,341 characters becomes 627, and the argument has one home rather
than seven copies to drift apart.

THE COPY HAD ALREADY DECAYED, exactly as review 62872 says. Every one of the seven ended
"the minimum below is a commitment floor" and there was nothing below any of them - the
sentence was written for a layout that never existed. That is the tell for copied prose
and it appeared within one commit of the copy being made, which is the argument for
DRY stated more cheaply than any principle: the seventh copy was wrong before anyone
read it.

TWO STALE COUNTS - FIXED, AND ONE WAS WORSE THAN A COUNT. colo_census_coverage still
said "the corridor holds TWENTY-SIX facility rows" AND still explained that Colocation
America NJDC2 "turned out to name no Secaucus site at all" - the reading I retracted two
commits ago. So the annotation was not merely stale on a number, it was still asserting
the false claim the retraction removed. Rewritten to record the full history: 28 typed,
27 derived, 26 on my bad reading, 27 on its retraction, and no number edited at any
point. The witness annotation simply drops its count instead of restating it as 27,
because a hand-typed count in prose is the thing this PR exists to stop carrying.

THE ANEMIC-DECOMPOSITION FINDING IS RIGHT AND IS NOT TAKEN HERE. The reviewer is correct
that a read numeric fact living in a NonEmptyStr is DESIGN section 2's anemic modeling,
that types.dag already carries the quantity as PublishedApparentPower over VoltAmpere,
and that the repair is an arm - DensityMinimumCommitted - on CabinetDensityClaim, the
same growth that file made once for kVA-versus-kW. I agree with all of it and recommended
that arm to the carrier owner before this review arrived.

It is not taken in this PR because the same MINIMUM figure shape appears across several
lanes' operators, and the carrier owner has ruled that shape changes land as ONE
census-wide motion. Adding the arm for Equinix alone would leave two shapes in one
carrier, which is the state that ruling exists to prevent. That reasoning is now written
into the module annotation rather than living in a PR thread, so a reader of the file
learns why the figure is in prose and what replaces it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* The arm I recommended was the wrong shape: point the frontier at #10885's quantifier instead

My escalation asked whether to add DensityMinimumCommitted to CabinetDensityClaim now or
fold it into the planned census-wide split. The answer was neither, and the shape I
recommended was wrong on its own terms.

A fourth arm for a floor needs a fifth for an interval, a sixth for an average, and a
seventh the first time an operator publishes a floor for air beside a cap for liquid. The
DIRECTION of a published figure is orthogonal to its unit and to its cooling medium, so
an arm per direction forks the quantifier once per combination - the re-invention DESIGN
section 2 forbids, proposed by me in a message arguing against forking a carrier.

gunbc#10885 carries PublishedPowerQuantity applied at every figure site instead:
CapabilityAtLeast, MarketedAtMost, MarketedInterval, PublishedAverage. DensityMarketedMax
and DensityMarketedAirOnly keep their names and their meaning narrows to which COOLINGS
were published, never which direction. My seven kVA minimums are CapabilityAtLeast.

THE PROPERTY I ASKED FOR SURVIVES AND IS ENFORCED BY EXECUTION rather than by the
paragraph I had written to protect it: cabinet_density_air_ceiling returns Absent for
CapabilityAtLeast, so these figures can be carried at full precision and contribute
nothing to a ceiling. That was the whole reason these rows stayed Unread.

AND THERE IS A HALF NEITHER THE ESCALATION NOR THE REVIEW HAD. A FLOOR ADMITS. I argued
only that a floor must not become a ceiling, which makes it harmless; sending it to
Absent also makes it useless. A 2 kVA minimum ADMITS a 2 kVA requirement and refuses
nothing, and that is the cheapest screen in the census - a marketed cap, by contrast,
admits nothing, because it is a product statement and not a promise that any cabinet is
available at it. Prose could never have supplied that, and it is a better answer than the
question I asked.

This commit only re-points the annotation: it named a repair that will not exist, which
would have sent the next reader to build the shape that was rejected. It now names the
real destination, why the recommended shape was declined, both properties above, and what
happens to these rows when #10885 lands - the wording they carry becomes the claim
wording, and the resolve step stays owed because a floor is genuinely not a maximum.

The escalation is retracted. No row changes here; the seven stay DensityUnread until the
carrier lands.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NvcvTgct4JBtYTQegmveCp

* review 62882: the witness did not compile, and my own checks were joined in the wrong direction

CONFIRMED AND FIXED. databank_ewr1_retail_grain is used in corridor_unread_grain_rows
and was never imported. The name is unresolved, so the ENTIRE witness module fails to
resolve - including the three controls the last two commits described as the PR's
central claim being made machine-checkable. They have never executed.

MY CHECKS WERE JOINED THE WRONG WAY ROUND, and this is the part worth more than the
one-line fix. I ran a symbol check on this exact file two commits ago and it printed
"all imported symbols resolve". That check asks: for every name in an import block, does
the target module declare it? It cannot see an unimported USE, …
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant