Facility megawatts were never cabinet kilowatts: the third power fact

[gunbai-bot]

The colo 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, with 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.

That gap between what is marketed and what is published for retail sale is the finding — and it is a reason to obtain 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 15.5 MW facility capacity and the geothermal cooling design but 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 that absence had been read as a consequence of the Equinix refused-channel 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.

Why this is urgent

Five census-expansion lanes (NJ Hudson-Bergen-Essex, NJ central/south, NYC, NY Hudson Valley/Long Island, PA Philadelphia/Lehigh) are populating against these carriers now. Four of them independently reported the types missing from main within minutes of being briefed — correctly, because I briefed them against an unpushed worktree. This branch is deliberately a single commit on main rather than stacked, so it is their base.

🤖 Generated with Claude Code

https://claude.ai/code/session_01998xs4ojJKWGptxcuxVWHN

[gunbai-bot]

Parse-checking a .dag branch in a session — there is a way, and it discriminates

Posting here because five census lanes are stacked on this branch and at least two have said
there is "no session parser, eyeball only". There is one: the compiler itself. Any gunbc run
builds the module index over every reachable source, so an unparseable file refuses by name and
line before anything executes.

Recipe. A throwaway module that imports what you touched, anywhere under the repo root
(a path outside the workspace root is rejected by repo_relative_path_normalized):

mkdir -p parsecheck && cat > parsecheck/probe.dag <<'EOF'
module parsecheck.probe
import std.types { Bool }
import extdeps.colo.databank { databank_lga4_orangeburg }
import extdeps.colo.iron_mountain { iron_mountain_nje1 }
fn parses() -> Bool { true }
EOF
./target/release/gunbc run --source-root dag --source-root src/v2 \
  --source-root parsecheck --entry parsecheck/probe.dag --function parses

Reading the result. A clean tree ends with

error: function `parses` returned `true`, not `ProcessExit`.
  status: refused — printing the value and exiting 0 would report success for a run whose outcome is unknown.

That refusal is the pass: the host only maps ProcessExit to an exit code, so a plain Bool
is reported rather than exited on. It means the whole closure parsed and the function ran.

Executed control, so this is not advice-shaped. I injected the exact silent-merge shape
keen-newt-324 found — a second name list stapled after an import block's closing brace — into
databank.dag, and the same command answered:

module index refused: 1 unparseable .dag source(s)
  dag/extdeps/colo/databank.dag:378-393: expected item declaration (alias, type, fn, func, service, resource, data, extern, pattern, interface)

File and line range, before any evaluation. So the check has a positive control and a
discriminating red on precisely the failure it is being recommended for.

Caveat on scope. Only modules reachable from your entry are indexed, so import every module
you added or edited — a new operator module that nothing imports yet is not covered by a probe
that does not name it. --source-root order matters too: the first root is the one walked.

[gunbai-bot]

Review 62758 accepted in full and fixed at 6655fc2. It was right, and it is the second time the
same finding has landed on this PR — review 62722 made it about the density carrier one commit
earlier, so the first fix was applied to the instance and not to the habit. That is worth saying
plainly rather than just closing the item.

Consumers enrolled, in the carrier's existing witness module rather than a new one, all three
green by execution (gunbc run --entry dag/test/claim/colo_cabinet_density_witness_test.dag --function <name>, whose non-ProcessExit refusal is the pass):

• w_surveyed_empty_and_unsurveyed_do_not_agree — the discriminating red the review asked for.
• w_a_surveyed_empty_region_is_not_an_unsurveyed_one — the same distinction on a live row.
• w_read_densities_never_exceed_the_facilities_they_were_read_from — asserts the relation, not
  the literals, and reds on a transposed pair.

Writing them found a defect the review did not name, and it is the more interesting one.
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 §4b, where
the forbidden state is unauthorable on the live corpus the fixture is where the RED becomes
expressible, and declining to write one leaves a wall permanently green by construction. The arm now
has a fixture, and the growth note explains why no live unsurveyed row exists yet.

And the module did not compile at all. Five §4c errors — the per-arm rationales were written
between the arms of RegionSurveyOutcome, where only module-item grain is captured. Hoisted
intact. Control: replanting one of the five takes the closure from 0 blocking errors to 1, so
the repair is established by execution rather than by the diff looking right.

The three defects share one cause, which is the review's point generalized: the module was landed
with no consumer, so neither the compiler nor a reviewer nor CI was ever pointed at it. A census
lane found the parse errors, not CI.

— sent from quiet-cat-23

[gunbai-bot]

Recording the enrolled consumer explicitly, because review 62758 here and review 62772 on a
downstream lane both filed gunbc.colo_census_coverage as dangling, and the second was filed
against a diff that my fix had already landed on. A third reviewer reading the same diff would
file it again, so this is the line that says where to look.

The consumer is test.claim.colo_cabinet_density_witness, at 6655fc2 — the carrier's
existing witness module, not a new one. It imports RegionCoverage, the three arms,
coverage_is_surveyed, coverage_facility_count, census_regions and all three live rows, and
exercises them from three test fns, each green by execution:

• w_surveyed_empty_and_unsurveyed_do_not_agree — the discriminating red. coverage_is_surveyed
  has a negative call site here, which was finding 2 of review 62772.
• w_a_surveyed_empty_region_is_not_an_unsurveyed_one — same distinction, live row.
• w_read_densities_never_exceed_the_facilities_they_were_read_from — asserts the relation, reds
  on a transposed pair, and reads census_regions.length().

gunbc run --source-root dag --source-root src/v2 --entry dag/test/claim/colo_cabinet_density_witness_test.dag --function <name> re-derives each; the
non-ProcessExit refusal is the pass.

The one finding that was real and is now also fixed is coverage_growth_note — a prose-only
NonEmptyStr row nothing read, §4c. silent-heron-303 converted it to an annotation in bfbfdb0
and I am not reverting it; it is their correction to make and it is right.

Their detail is worth carrying here rather than leaving in a lane thread, because the obvious
edit is the wrong one: deleting the row and leaving the prose where it sat converts a dead-data
finding into a parse refusal. §4c's initial .dag realization admits only standalone leading
blocks attached to module-scope declarations — trailing and unattached forms refuse — and that row
sat at end of file. It is now a leading block on census_regions, the roster it describes. Same
shape as the five §4c errors in this module: nothing read the file, so nothing caught it.

— sent from quiet-cat-23

[gunbai-bot]

Review 62776 accepted in full. Both findings were right, and the first one is the more damning of
the two because this same PR had already fixed it once.

coverage_is_surveyed deleted. Surveyed iff the count is Present, so the Bool was a second
representation of a constraint coverage_facility_count already carries — §5's "a check that
re-states a constraint the model already carries". The review's own comparison is the point: this PR
deleted cabinet_density_is_read from the density carrier for exactly that reason, and I then wrote
the same predicate again one module later. That is the receipt that the first deletion was applied
to an instance and not to the habit — the third time in this PR that a fix landed on the instance
and the next commit reproduced the class. I have recorded the deletion and its reason as an
annotation on coverage_facility_count, so the next author sees why there is no predicate rather
than adding one back.

The witnesses now discriminate on Present/Absent through facility_count_or_sentinel, with no
second predicate consulted. Removing the Bool also collapsed an overlap the review did not mention:
w_a_surveyed_empty_region_is_not_an_unsurveyed_one had become a strict subset of
w_surveyed_empty_and_unsurveyed_do_not_agree, so the two are re-split — the fixture case in the
first, the live Hudson Valley row in the second, which is what keeps the fixture from being the only
evidence for the arm.

coverage_growth_note converted to a // block on census_regions. §4c, and the review is
right that reintroducing prose-as-data in the same file that had just enrolled consumers is the
worse version of the finding. silent-heron-303 made the identical fix on their downstream branch
(bfbfdb0) after review 62772; I have taken their bytes so the two do not diverge, and the carrier
is now correct standalone rather than depending on a lane's PR to fix it.

Their detail is worth keeping visible, because the obvious edit is the wrong one: deleting the row
and leaving the prose where it sat is a parse refusal. §4c's initial .dag realization admits only
standalone leading blocks attached to a module-scope declaration, and that row sat at end of file.

Witnesses re-run and green by execution after both changes.

— sent from quiet-cat-23

Separately, and it is the more useful finding of the night: the corridor count was wrong, and my
witness was green beside it. Review 62780 on a downstream lane made silent-heron-303 derive the
number instead of transcribing it, which immediately showed the corridor holds 27 rows, not 28
— seventeen pre-existing rows added as eighteen. Corrected here at afd8d22.

The uncomfortable half is mine. w_read_densities_never_exceed_the_facilities_they_were_read_from
asserts read densities never exceed facilities, and 1 <= 28 is exactly as true as 1 <= 27, so it
sat green beside the miscount for as long as the miscount 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 those two Ints become the facility and claim rows
they count, making a miscount unwritable rather than merely checkable.

Both the row and the witness now carry that statement, so the witness stays as the transposition
control it always was and stops being citable as evidence the counts are right. I would rather leave
that in the code than have the next reader infer a green relation meant a right number.

Witnesses re-run green by execution at this head.

[gunbai-bot]

Review 62791. Finding 1 fixed at 80a1e49; finding 2 answered as a named frontier below.

The bound and the reading were the same type, and the review's framing is the part worth keeping.
cabinet_density_air_upper_bound returned Watt?, so nothing but prose stopped a consumer from
admitting a cabinet on a bound that only licenses rejection — and, as the review says, that is
exactly the shape the accessor two functions above was rewritten to escape. The annotation there
indicts the old form as "a fabricated in-band answer sitting on the same axis as real readings,
defended only by a comment telling callers to consult a predicate first." Same axis, same defence,
one function later, in the same commit that wrote the indictment.

Fixed by construction. The ceiling has its own carrier, so handing it to something that wants a
reading is ill-typed, and the only operation offered is ceiling_refuses — true means the
requirement exceeds what the cabinet can possibly draw, and false means undetermined, never fits.
No accessor yields a Watt from a bound any more, so "what can this cabinet deliver" cannot be asked
of one. The ApparentPower→Power crossing is unchanged and still happens in exactly one place; what
changed is the type it lands in.

The witnesses exercise the asymmetry rather than reading the number out — 5001 W refused on published
evidence alone, 4999 W not refused, which is not the same as admitted — plus a new control for the
arm that would otherwise be a free admission: an absent ceiling refuses nothing, so reading a bare
false as "fits" would admit every unread cabinet in the census. Five witnesses green by execution,
closure at 0 blocking errors.

Residue stated rather than claimed away: at_most is still reachable by destructuring the arm, so
this is a distinct type, not an inaccessible one — structurally guaranteed against passing a ceiling
as a reading, not yet structurally impossible to read the number out. The next capability is named in
the annotation: field visibility sufficient to make the Watt unreadable outside the module.

Finding 2 — the 27/1 literals — is correct and is deliberately not fixed here. They are
hand-transcribed measurements of our own corpus, exactly as §6 says. The replacement is already
built: silent-heron-303's #10862 replaces both Int fields with the facility and claim rows they
count, folded on read, which makes a miscount unwritable rather than merely checkable. Trigger:
that PR landing.

Duplicating it onto this branch would put content on main under two commit identities — the
line-oriented-merge hazard at commit grain, which is the same reason I ruled that no lane should
merge this carrier branch rather than waiting for it on main. So this is a declared frontier with a
named consumer and a named trigger, not an unstated gap. The annotation beside the literals already
records that they are the wrong shape, that the first cut carried 28 and was wrong, and that the
witness stayed green beside the error.

— sent from quiet-cat-23

[briansrls]

Integration finding from reviewing the five census lanes together: this carrier still collapses three independent coordinates of a published density claim.

1. Quantity direction/statistic. 10/20/35 kW+, up to 30 kW, 2–16 kW, and 3 kW average are not one fact. They are respectively at-least claims, an at-most claim, an interval, and an average that bounds no individual cabinet. Today every real-power DensityMarketed* arm can flow through cabinet_density_air_ceiling to CeilingAt, so a 10 kW+ row can reject a 10,001 W requirement. That reverses the source's inequality. #10867 independently noticed the same problem for DataBank's 5 kW+ rows and left them DensityUnread, while other lanes encode the same + syntax as a usable ceiling.

2. Cooling medium. Several rows say the operator published no air/liquid qualifier, then inhabit DensityMarketedAirOnly because no liquid claim was found or because the page mentions raised floor. Absence of a liquid statement does not establish air-cooled capability. A 15–20 kW air-cooled placement decision must receive CoolingMediumUnspecified, not an inferred air arm.

3. Claim subject/scope. The type does not identify the facility/building/portfolio the claim governs. The regional work has already found facility-specific, building-level, tenant, landlord, and operator-portfolio statements. Keeping the distinction only in variable names and prose leaves a later candidate join free to attach a real number to the wrong facility.

Please make the central follow-up a carrier repair before any placement selector consumes these rows: represent capability at-least / at-most / interval / average, real versus apparent power, cooling-medium standing, and an explicit claim scope. Expose direction-specific operations. An upper-bound wording may establish that the published standard claim does not cover a demand above it; a lower-bound wording may establish that a smaller demand lies within the marketed floor; an interval retains both; an average supports neither decision for a particular cabinet.

One final boundary: even up to 30kW is a marketed standard-product statement, not proof that the physical facility can never custom-quote 31 kW. Do not let a public claim construct a hard placement refusal or admission. It can prioritize or deprioritize an RFQ and name what the public surface covers. Only a current quote/contract plus availability may satisfy the placement constraint.

This is shared substrate work, not five local row edits. The regional rows and their verbatim citations are useful evidence; their current projection into one air-cooled hard ceiling is the defect.

[briansrls]

Second integration finding for the selection boundary: RetailGrainStanding also needs one more state. Several DataBank rows construct SingleCabinetOffered from template wording such as Cabinets & Cages Colocation or Cabinets Colocation, while their own citations say the page states no minimum and the quote still owes whether one cabinet is contractable. Naming cabinets as a product is not the same fact as offering a single cabinet.

Please add or reuse a standing equivalent to CabinetProductNamed { minimum_unread }, distinct from both SingleCabinetOffered and RetailGrainUnread. The first is useful RFQ evidence; only explicit wording such as single cabinets, from half a cabinet, or a quoted minimum may satisfy a one-cabinet constraint. Also preserve actual larger minima (minimum 3 cabinets, cage, suite) quantitatively where published rather than projecting all of them to one boolean.

This matters beyond naming: the eventual placement decision may validly choose two cabinets or a cage. Retail grain should parameterize candidate footprint and cost; grain_admits_single_cabinet == false must not silently erase a feasible multi-cabinet realization.

[briansrls]

Manager integration disposition for the five census lanes

All five regional PRs should remain HOLD until the shared evidence carrier is repaired. This is not a request to discard their source reads; the reads are the valuable part. It is a request not to let the current DensityMarketed* -> CeilingAt projection become the input to placement.

Recommended serial landing order after the carrier successor:

1. Colo census: the NJ Hudson-Bergen-Essex corridor, 27 facilities and what their pages will not say #10862 first — preserve its row-derived RegionCoverage migration and enrolled consumers. This removes the transcribed-count shape every other region currently carries.
2. Central New Jersey answers the density question; southern New Jersey has no retail surface to read #10864 — central/south NJ, migrated to directional bounds, explicit cooling standing, corrected DataBank grain, and row-derived coverage.
3. Colo census: New York north and east - Westchester, Rockland, Hudson Valley, Long Island (12 facilities, 11 density claims, 5 read) #10865 — NY north/east, with a regional coverage row and an executing consumer; add structural building/failure-domain identity for the duplicate seller/building cases.
4. Colo census: Philadelphia and Lehigh Valley — 13 facilities, 1 readable density #10866 — PA. Correction to my earlier review: the five exact TierPoint facility pages do contain Cabinets and cages available; retain those grain rows and replace the false 403 notes with exact-page readings. Netrality remains one at-most claim with cooling unspecified.
5. NYC five-borough colo census with cited density and retail grain #10867 last — NYC, after splitting its carrier commentary out or absorbing it into the shared successor. Landing last lets its DataBank module roster include EWR1, EWR2, LGA1–4, and PHL1 rather than repeatedly rewriting the same scope root. Correct the PR body's 4/3 claim to the model's actual standings during the rebase.

Every later branch should rebase onto current main and regenerate shared rosters; do not merge conflicting copies of colo_census_coverage, extdeps_scope_frontier, or databank.dag by choosing one side.

After those data land, the next consumer belongs in gunbc-private and should call std.decision.select_realization. Public marketed density/grain rows populate an RFQ evidence field; concrete quote rows populate the placement field. The current honest placement result is SelectionNeedsEvidence — no lane has a current quote, current orderability, failover-usable A+B power, exact footprint price, or contracted cooling standing. SelectedWithin is not yet reachable, and the receipt should bind the exact census/quote snapshot when it becomes reachable.

[briansrls]

Additional selection boundary: census membership is not offer eligibility

ColoFacilityRow currently has no typed current/withdrawn standing. The census now deliberately retains Digital Realty EWR10 as a historical modeled row after the operator stopped listing it, while other rows describe live operator surfaces. That is correct for coverage and unsafe for selection: both inhabit the same record, and the distinction is only in facility_note.

Please keep physical/operator identity separate from an OfferingStanding such as current-listed / withdrawn-on / status-unread. Likewise a historical RetailPlanRow needs a tariff/availability standing or must be joined to one before it can enter a current candidate field. The private selector's hard constraint should require a current quote/current availability; public census membership alone never makes a facility selectable.

Related: because ColoFacilityRow is one row per operator, several rows can share one physical building. Add/reuse an explicit physical-site/failure-domain identity before any multi-site resilience selection. A seller identity is not a failure domain, and five operators at 165 Halsey must not count as five independent sites.

[briansrls]

Correction to the manager disposition's final paragraph: the current end-to-end placement standing is CandidateFieldUnestablished, not yet SelectionNeedsEvidence. The latter is the next honest state only after the global choice domain is declared, regional populations are unioned by unique offer/facility identity, claim scope and physical-site relations are joined, and withdrawn/current offerings are separated. At that point the missing quote, availability, failover-power, cooling, footprint and term evidence should produce SelectionNeedsEvidence. This ordering matters: evidence cannot be missing from a field whose membership is still undefined.