Lift the seven row-count ceilings a full-source native build meets, under one rule

[MaxGhenis]

Draft, and it stays draft. Base is native-scale-transport (PR #945's branch).

The transport lane's census (docs/us-native-scale-transport.md §5) recorded a
second family of ceilings it did not touch: row counts that a full-source native
US build meets. Max decided (2026-09-17) they are lifted as one change with one
argument, not one build at a time. This is that change.

The rule

A bound moves only if a full-source native build meets it. A bound that moves
becomes four times the measured full-source count of exactly what it counts,
rounded up to the next whole million.

The multiple is the transport lane's own: MAX_ROSTER_BYTES is 3.9× a
full-source preparation receipt, so both families share one law. The rounding
makes the rule checkable at a glance — divide any moved constant by the count its
comment names and the answer is between 4 and 4.6 — and
test_us_native_row_ceilings.py asserts it, so a later edit that drifts fails a
test rather than a build.

docs/us-native-row-ceilings.md is the argument: why each clause is
load-bearing, why a bound stays a bound rather than being deleted, and why three
classes must not move at all.

The counts are measured, not extrapolated

The recovered 1/1000 pilot artifact carries the whole ACS and ASEC catalogues,
which do not scale with the selection fraction. Its selectable households
reconcile to its own selection.supplied_households exactly —
1,348,408 + 84,422 + 98,784 + 55,762 = 1,587,376 — so "the whole catalogue" and
"what a full-source selection supplies" are the same set, and the catalogue's
counts are the full-source counts.

	households	persons
ACS	1,531,614	3,422,888
ASEC	55,762	142,125
stacked	1,587,376	3,565,013
combined clone	3,174,752	7,130,026

The transport lane's ~3,471,000 stacked / ~6,943,000 cloned were the 1/1000
per-household ratio extrapolated. These supersede them, about 2.7% higher.

What moved

constant	was	now	counts	full source	×
acs_pums.MAX_EXACT_HOUSEHOLDS	1,000,000	7,000,000	exact ACS household keys	1,531,614	4.57
acs_pums.MAX_EXACT_PERSON_ROWS	1,000,000	14,000,000	NP over selected ACS households	3,422,888	4.09
acs_person_coverage_columns.MAX_SELECTED_ROWS	1,000,000	14,000,000	requested ACS person keys	3,422,888	4.09
survey_observed_age.MAX_ROWS	2,000,000	14,000,000	one channel's person rows	3,422,888	4.09
survey_origin_budget.MAX_GROUPS	1,000,000	7,000,000	allocation instructions = selected households	1,587,376	4.41
current_survey_geography.MAX_HOUSEHOLDS	524,288	7,000,000	selected households	1,587,376	4.41
asec_demographic_source._MAX_PERSONS	600,000	14,000,000	retained ACS persons (the larger of its two rosters)	3,422,888	4.09
current_survey_geography.MAX_HOUSEHOLDS	524,288	7,000,000	selected households	1,587,376	4.41

Every refusal keeps its code, its exception type and its expression. Only the
number moves.

One consequence worth naming so a reviewer does not have to find it:
MAX_SELECTED_ROWS at 14,000,000 now sits above MAX_ROWS at 6,000,000 in the
same module. That is not a mistake — MAX_SELECTED_ROWS bounds caller-supplied
person keys, which can exceed what the source holds, while MAX_ROWS bounds the
archive's own rows — but it does mean the effective ceiling on that path is
6,000,000, by containment. Tying the two together (MAX_SELECTED_ROWS = MAX_ROWS)
would be tighter and provable, at the cost of making the rule two rules; it is
listed as an open question below.

The last two are ones the transport lane's census did not reach, and both were
moved only after reading what stood behind them. The rule's test for a bound that
looks like a row ceiling is one question: does the binding site stream, or
materialise a per-row payload? A bound in front of a materialised payload
cannot usefully be raised alone, because the payload's own byte cap refuses first
and at a smaller number.

• current_survey_geography.MAX_HOUSEHOLDS bound hardest of the seven — 524,288
  against 1,587,376, refusing at 33% of source. It reads as a byte budget
  (64 * 1024**2 // 128) but streams: _projection_digest feeds one bounded row
  encoding at a time into a hashlib.sha256 and materialises nothing per
  household. Moved.
• asec_demographic_source._MAX_PERSONS is one constant over two rosters, so it
  takes the larger. It is not a fixed-width encoding (rows is a JSON header
  integer; the only struct.pack is "<I" over the header length), and it could
  not have been an assertion about the ACS file's size — at 600,000 it sat 5.7×
  below the genuine 3,422,888-row file, and a bound that would refuse the real
  file is not a claim about it. Moved.
• current_survey_household_roles.MAX_PERSONS and
  current_child_property_income_source.MAX_ROWS fail the test —
  table.reset_index().to_json(...) and one json.dumps respectively, each under
  a 64 MiB cap. Left to the transport argument.

survey_origin_budget.MAX_GROUPS is the one the transport lane left as "not
established". It is established: allocation_instructions requires one
instruction per selected household, so the group count is the selected
household count.

What did not move, and why

• An upstream file's real size. acs_person_coverage_columns.MAX_ROWS and
  acs_native_coverage_binding.MAX_SOURCE_ROWS, both 6,000,000, assert that the
  ACS archive is near its real 3,422,888 records. Raising either trades a real
  check for nothing, since a selection cannot exceed its source.
• A fixed-width encoding. The PAYLOAD_MAX_BYTES = len(MAGIC) + 4 + HEADER_MAX_BYTES + ROW_BYTES * MAX_HOUSEHOLDS + 32 family computes a byte
  budget from a row ceiling, so moving the row ceiling moves the wire format.
  MAX_EXACT_FLOAT64_INTEGER = 2**53 bounds a value, not a row count.
• A quantity no fraction grows. asec_current_money.MAX_PERSONS (1,000,000)
  counts the ASEC source's own rows, measured at 142,125. The transport lane's
  §5 listed it among the bounds a full-source build meets; it does not, and this
  PR corrects that.

Findings the owner should see

The census read 146 bounds across five module families, each with its
enforcement site, refusal code and exception type, what it protects and its
counts at 1/10 and full source; 41 verdicts then went through an adversarial
pass that read the code again and tried to refute them, and no headline binding
call was overturned. Fourteen bind at full source — and six bind at 1/10,
which contradicts the transport lane's §5 conclusion that "a 1/10 build meets no
ceiling this lane did not lift". All six are byte transports. Three matter enough
to be measured rather than listed.

1. The ACS coverage authentication body budget is the tightest ceiling on the
path, and it is not close. acs_person_coverage_authentication charges every
selected row 6 * len(raw) + 1024 bytes against MAX_BODY_BYTES (64 MiB) before
the reader allocates, refusing SELECTED_BODY_BUDGET. Measured over 200,000 real
records of the pilot's captured public ACS PUMS archive — a person record
averages 695.57 bytes — the charge is 5,197 bytes and the budget admits
12,911 selected persons, 0.38% of source, 265× under at full source.

That is below 1/100. It is why lifting MAX_SELECTED_ROWS here is necessary and
not sufficient: this refuses 265× earlier on the same path.

2. The preparation-receipt ceiling #945 lifted is still enforced one module
downstream. survey_population_preparation._roster_payload returns one joined
payload under MAX_ROSTER_BYTES = 4 GiB — it must, because
KernelResult.artifacts is a mapping of bytes — and
graph_survey_population._checked_preparation checks those same bytes against
PREPARATION_MAX_BYTES, still 64 MiB, refusing PREPARATION_BYTES at :305
and :309 and again in the allocation kernel at :577/:582, reached from six
call sites including graph_atomic_survey_population:172.

From #945's own committed ceiling-receipt.json: a 1/10 roster measured
109,804,304 bytes and was recorded accepted by the producer — 1.64× this cap —
and a full-source roster measured 1,099,892,722 bytes, of which this cap admits
96,839 households. That is, to within rounding, exactly the 96,860 #945
reported as the ceiling it had lifted.

Both are pinned in test_us_native_row_ceilings.py so the next reader meets them
in a test rather than in a build. Neither is this lane's to move.

3. The origin budget's byte transport binds below one tenth.
survey_origin_budget.MAX_PAYLOAD_BYTES (64 MiB) admits 87,838 households,
5.53% of source — below 1/10 and below the 96,860-household preparation-receipt
ceiling the transport lane lifted. A full-source payload is 1.13 GiB, 18.07× the
cap. Measured, not estimated: one faithful origin record through the module's own
_reference and _json at full-source id widths is 764 bytes per group.

It cannot be raised here at all. graph._bounded_json opens with
_require(type(limit) is int and 0 < limit <= 64 * 1024**2, "TRANSPORT_LIMIT"),
so the shared encoder refuses any cap above 64 MiB before encoding a byte. This is
the transport argument's work, and lifting MAX_GROUPS is necessary but not
sufficient: at full source the refusal moves from GROUP_COUNT_BOUND to
TRANSPORT_LIMIT.

4. An inherited pin on this base is not regenerated. On
native-scale-transport, b6081efcb added path.read_bytes() inside
_spill_roster. read_bytes is in graph_implementation._RESOURCE_CALLS, so it
moves survey_population_preparation.py's resource_accesses_sha256 — and the
pin was not regenerated. implementation_manifest() therefore raised
"Unclassified US dependency/resource contract" for every stage containing that
module, including authenticated_survey_population_v1, the stage the nineteen-node
path runs. Proven by recomputing the contract from origin/native-scale-transport,
a64f7b733 and b6081efcb's own blobs; this branch does not touch that file.
Re-pinned here through the generator so the base is functional — say if you would
rather it moved to #945 and this branch rebased.

Pins

pin	generator	result
graph_implementation_inventory.json → all 124 contracts	graph_implementation._dependency_contract(payload, name, _covered_imports(name, inventory))	unchanged by these edits; one re-pinned for the inherited break above
acs_native_coverage_binding._ACCEPTED["acs_pums.py"]	sha256(<module>.read_bytes())	moved 6ecf79f0… → e79a2a4e…
the other three _ACCEPTED entries	same	unchanged
all ten implementation_manifest(stage)	graph_implementation.implementation_manifest	built

No pin was hand-edited. Both generators are committed under
experiments/native-row-ceilings/ and are idempotent — rerun, they report
nothing moved.

Tests

A boundary test per moved bound drives the refusal at exactly its own constant,
and the shared file asserts the shipped constant clears 4× its measured count —
so acceptance at a full-source-sized count follows from the two without any test
allocating a full-source roster. Two do drive real full-source counts for free:
survey_observed_age normalizes a genuine 3,422,888-row channel in 0.02 s, and
NP is a declared count, so a two-row ACS household table declaring the whole
3,422,888-person file exercises that ceiling with no person rows at all.

Scope

• No packages/microcosm-graph hunks.
• graph_atomic_survey_financial.py, survey_population_replay.py untouched.
• Not a build, a certification or a release artifact. No gated data was read; the
  only input is one recovered development artifact, and every receipt carries
  "release_eligible": false.

🤖 Generated with Claude Code