Historical report imported 2026-10-10 from docs/experiments/benchmarks/cross-system-storage-sweep-findings.md. Original SHA-256: ded900068a5eae4a4e12e663e38173f7ff98980e46ff8df8b9941e02382c26c4. Measurements and outcomes retain their stated revisions. Links and local environment labels are normalized; $FABRIC_DATA is the mounted experiment drive. See evidence policy.

Finite storage run-size findings

The registered 36 matched pairs (72 native cells) completed their semantic gates. The machine-readable matched report (local evidence omitted from stage) retains both seeds, every cap, cost domain, physical filter result and reference control. This is an instrumented, single-process offline experiment under the sweep proposal (local checkout reference docs/experiments/benchmarks/cross-system-storage-sweep-proposal.md; not present at origin/main), not deployment qualification or a default-change decision.

Observed cap effects

Against bounded 16 MiB, bounded 8 MiB passed all six shape × input-size screens in both registered seeds. The benefit came from heap; build write bytes were slightly higher, by approximately 0.007–0.025%, rather than showing a write reduction.

Input target	Shape	Build peak heap reduction at 8 MiB	32 MiB heap change versus 16 MiB
16 MiB	steady	26.75%	+53.18%
16 MiB	adversarial	26.73%	+53.16%
16 MiB	bigrows	21.29%	identical within each seed
64 MiB	steady	25.73%	+33.38%
64 MiB	adversarial	25.71%	+33.36%
64 MiB	bigrows	20.46%	+44.44%

Across the twelve 8-versus-16 comparisons, encoded build throughput ranged from 0.9366 to 1.1112 of baseline, whole-native CPU from 0.9024 to 1.0221, and whole-native peak RSS from 0.8158 to 0.9501. These distinct measurement scopes must not be substituted for each other: allocation counters cover requested live heap during build; process RSS includes generation and verification and allocator/runtime residency. The decoder ran in a reaped subprocess; parent residency was recorded separately and below worker HWM.

All six 32 MiB screens failed in both seeds. The 16 MiB bigrows heap plateau is a useful null counterexample: increasing this cap did not reduce that build peak, while RSS rose 11.3–13.0%. Other 32 MiB cases increased heap 33–53% and RSS about 15–37%. Throughput changes were small or inconsistent, and no case showed the required 10% heap/write benefit. A larger run cap cannot be nominated from these results.

Sampled initial log-spill counts generally changed with caps: steady/adversarial 16 MiB input showed 4/2/1 at caps 8/16/32, and 64 MiB showed 13/7/4. The corresponding 64 MiB bigrows observations were 9/5/3. These are 100 ms filesystem lower bounds, not exact spill totals; the second 16 MiB bigrows seed missed short-lived files. No intermediate merge was sampled. Absence in the samples does not establish absence of a merge. Each signal table has its own byte and 32,768-row limits, so a single aggregate cap is not a model of total live memory.

The matched references had nearly identical heap across compile caps, supporting the deduction that the bounded run mechanism caused the heap trend. Timing controls are weaker: for 64 MiB adversarial seed 2703204353, reference cap 8/32 throughput was 1.761/1.785 times reference cap 16, and CPU 0.692/0.687 times. This unresolved timing outlier prevents a claim of uniformly tight timing reproducibility and motivates fresh direct bounded 8-versus-16 confirmation.

Prospective model counterexample

Predictions were frozen before either 64 MiB job at SHA-256 e635a912d3170d1677f0863d252ce20e72405f545f7d374adaa235a9cab772c7. The registered scaling proposal (local checkout reference docs/experiments/benchmarks/cross-system-storage-scaling-prediction-proposal.md; not present at origin/main) required maximum relative error ≤5%, without refitting, for twelve steady/adversarial holdouts per model. The formal evaluation (local evidence omitted from stage) falsified both finite predictions: constant-per-cap model A reached 23.027% error; linear-in-cap model B reached 22.981%. Every holdout exceeded 5%, and every prediction underestimated observed peak.

For example, steady cap 8 predicted 26,374,792.5 bytes under model A but observed 34,264,845 bytes at 64 MiB input. This falsifies input-independent peak over this range; it does not establish unbounded memory or a product defect. Source inspection already identified an adversary: metrics rows grow from about 14,304 to 57,120, crossing the independent 32,768-row limit. Simultaneous occupancy of per-table buffers, writer batches and manifests remains unidentified by the three cap knobs. A separately registered phase-attribution experiment can discriminate peak intervals; these observations must not be used to refit and retroactively accept the failed predictions.

Fresh confirmation of the 8 MiB candidate

The separately registered confirmation (local checkout reference docs/experiments/benchmarks/cross-system-storage-confirmation-proposal.md; not present at origin/main) completed twelve direct bounded8-versus-bounded16 pairs (24 native cells), using new seeds 2703204355/2703204356 and the exact original frozen binaries. The compact result (local evidence omitted from stage) records all twelve paired semantic gates and all six shape × target screens confirmed in both seeds. Benefit remained heap reduction, not write reduction. The coordinator receipt (local evidence omitted from stage) records the exact command, child/outer exit 0, 500.790 seconds, 610,406,400-byte cgroup peak (582.13 MiB), zero OOM events, zero final swap usage and removed owned scratch. The run remained under enforced no-swap containment.

Input target	Shape	Fresh heap ratio 8/16, both seeds	Fresh throughput ratio 8/16, seed 4355 / 4356
16 MiB	steady	0.732553 / 0.732556	0.940751 / 1.078070
16 MiB	adversarial	0.732706 / 0.732703	1.059197 / 1.064125
16 MiB	bigrows	0.787068 / 0.787071	1.045752 / 1.015793
64 MiB	steady	0.742733 / 0.742732	1.034955 / 0.997699
64 MiB	adversarial	0.742854 / 0.742853	0.981300 / 1.004647
64 MiB	bigrows	0.795469 / 0.794513	0.974547 / 0.965032

Across all fresh pairs, build heap fell 20.45–26.74% and whole-native RSS fell 3.42–21.01%. Throughput ratios were 0.940751–1.078070, whole-native CPU ratios 0.957948–1.042144, and build-write ratios 1.000066–1.000252. Thus every pair retained the prospective ≥10% benefit, ≥90% throughput and ≤110% CPU/RSS guards, with parent HWM below worker HWM and observable heap change. Slightly increased writes again preclude an IO-gain claim. The opposite steady16 throughput changes in the two fresh seeds also caution against nominating a universal speed gain.

This confirmation establishes a repeatable finite heap-benefit candidate across four tested seeds, both input targets and all three shapes. It does not retest full-sort references, extend input distributions, establish an optimal cap, or repair the falsified flat-input predictions. The same differential Rust logical ledgers and independent physical FTF1 reconstruction apply. Exact member maps were captured before passing-state removal; decoder cleanup is recorded separately. No product default or frozen experiment source changed.

Phase diagnostic: peak during ingestion and batch writing

The separate attribution proposal (local checkout reference docs/experiments/benchmarks/cross-system-storage-attribution-proposal.md; not present at origin/main) completed four observer/plain pairs (eight native cells), with unchanged semantic gates and exact physical-filter checks. Its summary (local evidence omitted from stage) and retained compressed event traces provide one steady-input seed at caps 8/16 and targets 16/64 MiB. This diagnostic uses separately built feature-enabled binaries; it does not replace the original grid.

The observer installed 29,360,128 requested live bytes, exactly 28 MiB, for 262,144 preallocated records. This is a fixed observer baseline, not a production reservation. Observed raw peaks include it; baseline-relative incremental peaks can be compared to plain increments, while RSS must remain unadjusted.

Input / cap MiB	Plain incremental peak bytes	Observed incremental peak bytes	Observed raw peak bytes	Plain / observed build seconds
16 / 8	26,373,251	26,373,275	55,735,284	0.436086 / 0.424331
16 / 16	36,003,085	36,003,109	65,365,126	0.424722 / 0.439644
64 / 8	34,263,356	34,263,380	63,625,389	1.613746 / 1.634406
64 / 16	46,132,171	46,132,195	75,494,212	1.617152 / 1.640141

Incremental peaks differ by only 24 bytes in each pair, while observed timing changes range from −2.70% to +3.51%. With only one pair per condition, these timing differences do not establish a stable observer overhead. Raw heap includes the preallocation even though untouched reserved pages need not all become resident. Whole-native RSS ranged from 47,492/48,224 KiB (plain/observed 16/8) to 96,740/103,568 KiB (64/16); no observer-baseline subtraction applies to RSS.

In all four observed cells, the final new global heap record is enclosed by bounded_parquet_encode_write, nested inside bounded_table_flush; an arrow_batches conversion interval immediately precedes it. At 64/8, the enclosing write interval is approximately 239–283 ms after observer installation; at 64/16, approximately 231–276 ms. These intervals occur during ingestion, while signal sort buffers coexist with the batches writer. No later merge interval sets a higher record. Thus an extra merge is not the explanation for the observed peak increase in these two steady conditions.

The live background at the start of the peak-setting write interval rose from 14,416,595 to 22,263,371 baseline-relative bytes between targets 16 and 64 at cap 8, an increase of 7,846,776 bytes; the incremental peak rose 7,890,105 bytes. At cap 16, background rose from 24,010,556 to 34,132,186 bytes, an increase of 10,121,630 bytes; peak rose 10,129,086 bytes. The added background accounts numerically for nearly all the peak shift. Source inspection establishes that logs, metrics and spans have separate live Runs buffers while batches/gaps writers are active, and final resident runs are spilled before merge output. This supports co-resident ingestion state as the mechanism family behind the failed flat-input models.

The observer does not tag individual allocation owners or record per-table occupancy. Consequently, it cannot assign the added bytes specifically to metrics, distinguish all simultaneous buffers, or establish exclusive phase ownership. The metrics-row-limit crossing remains a source-grounded candidate within that family. Timings are inclusive, nested and nonadditive; global high-water samples inside later phases can reflect earlier work. The 64 MiB cells emitted 16,243/16,231 records, below the declared 16,384 trace envelope with little margin; this diagnostic does not authorize larger inputs without new admission/protocol scope.

Meaning and limits

The ordered row ledgers and input checks are differential through existing Rust scanners. They are not an independent logical row oracle. The Python FTF1 checker independently reconstructs physical filter coverage from each file's own Parquet row groups, authenticates metadata and rejects omitted or misaligned filters. Complete regular-member content maps were recorded before passing fixture cleanup; failures remain subject to full-state preservation. Reservation accounting, concurrent ingestion, crash recovery, varied machines and general input distributions were not measured. Cap 8 is now a confirmed finite research candidate with unchanged gates and timing guards; production promotion requires separately scoped evidence and no default has changed.