bundle/v0/COMPUTE_ESTIMATE.md

Compute estimate

The original planning ranges were:

• Configuration/data smoke: under one local CPU minute.
• One bounded conic canary: 5-30 CPU minutes.
• Main-text and coverage matrix (10,500 tasks): 12-72 aggregate CPU-hours if tasks terminate comparably to the author examples.
• Complete 14,000-task suite: 24-144 aggregate CPU-hours, embarrassingly parallel, plus artifact upload time.

The full-run estimate remains deliberately wide because the paper permits up to one million outer iterations and the released examples provide no paper-scale timing table. GPU requirement is zero.

Measured optimizer timing

All measurements below used a clean committed Windows CPU snapshot, one-thread BLAS, the independent solver, and claim-ineligible timing manifests. They spent $0.

Gate	Tasks	Updates	Internal wall	Trace bytes	Released stop observed	Outcome
paper plain GD, fixed 100	21	2,100	14.7849 s	12,708,904	5/21	escalation required
paper plain GD, fixed 1,000	16	16,000	69.6408 s	96,246,799	0/16	extrapolation denied
paired optimizer fidelity, cap 250	8	1,752	8.3401 s	2,944,376	1/8	four-task diagnostic only
paired stopping escalation, cap 5,000	8	33,964	138.0023 s	52,739,104	2/8	broader seeded timing required

The 100-step run had five released-code stop triggers, four caused by objective worsening. The 1,000-step escalation had no stop trigger, no solver-iteration deterioration, a maximum effective field-aware residual of 5.556315791781018e-8, and one timing-drift failure. These runs establish per-update cost and solver health. They do not establish a stopping-time distribution, and they do not authorize a 14,000-task launch.

The fixed-100 artifact is bound to run key sha256:ad7abe12a3dd71b7d98b3e39598e28a1636d6d49238472698cdf94a8d8958f79 at commit 830741cd1e9afe10185e2ca69174a85dd8cfab28. The fixed-1,000 artifact is bound to run key sha256:5b0a8c2119f44254bd272fc766936a6ca04ebe86597d24ef6dec102a2eb3befa at commit f1711b2179ba1de61410fd9e088345ea04c969a6.

The paired 5,000-step escalation used the corrected paper and released-code stopping contracts. One positive-objective paper-GD route stopped at 3,962 iterations. The negative-objective paper-GD route stopped at two iterations because the paper's literal denominator inverted the improvement sign. Six routes reached the cap without a primary trigger. The run is bound to sha256:c0d32dbaa3f5e3c19d6508f22d139068ea0d8ee1b080b3421f07b615903acb4f at commit f324f9ddffaf2e07684d9b3f7327261258bf2af8.

Across these four representative tasks and two optimizer routes, the mean was 17.25 seconds and 6.59 MB per trajectory. Applying those means mechanically to 14,000 tasks gives about 67.0 aggregate CPU-hours and 92.3 GB of uncompressed evidence. The CPU figure lies inside the original 24-144 hour range, but four tasks cannot freeze a portfolio estimate. The storage projection is already sufficient to reject a naive JSONL launch. The next execution gate must sample more seeds and adopt a lossless compact numeric trace format or compression while retaining independently validated scalar and checkpoint lineage.

Measured out-of-sample timing

Two grouped regression evaluations each processed exactly 10,000,000 OOS samples and five representative decisions. Together they took 5.56585 seconds internally: 0.22039 seconds sampling, 2.21513 seconds evaluation, and 0.21835 seconds aggregation. The bound run identity is sha256:310a18e9c42d6d1ab3a2ea155d539242cdee7cbaec71587225d915b1bec313dd.

This OOS result covers only absolute and squared regression groups. It does not project the entire portfolio and leaves cost_freeze_eligible: false.

Measured local evidence: the three-iteration Gaussian-portfolio v3 canary, including 42 finite-difference re-solves, twenty bootstrap distances, and trace persistence, took 0.883218 seconds externally. This validates low-dimensional solver plumbing but is not a representative convergence timing sample and must not be linearly extrapolated to the full matrix.

The canonical three-route Appendix v2 bundle took 1.2794429 seconds externally. It included exact empirical OT solves, nonzero OT-envelope checks, conic-value checks, active-penalty checks, two outer steps per route, terminal re-solves, and trace persistence. It is likewise a plumbing measurement, not a convergence-cost estimate.

The first clean stopping-rule canary used one Gaussian task, twenty bootstrap distributions, two outer steps, full gradient checks, and a terminal re-solve. It completed in 0.334499 seconds on local Windows CPU. Multiplying this cold-process canary time by all 14,000 tasks gives 78.05 serial minutes, but that is only a coarse projection for the implemented Gaussian route. It is not yet a defensible portfolio estimate because dimensions, route solvers, stopping lengths, process reuse, out-of-sample evaluation, and raw artifact writes vary by suite.

No paid or remote run is authorized from these data. A compact optimizer-fidelity probe must first separate the paper Algorithm 2 stopping rule from the released-source stopping rule, measure the primary stopping-time tail, and replace full per-iteration state serialization with scalar iteration records plus bound checkpoints.

As checked on 2026-07-19, Hugging Face Jobs lists cpu-upgrade as 8 vCPU / 32 GB at $0.03 per hardware-hour: https://huggingface.co/docs/hub/en/jobs-pricing. Under ideal eight-way utilization, the original 24-144 aggregate CPU-hour range corresponds to 3-18 hardware-hours, or $0.09-$0.54. With a 25% setup/persistence buffer, that would be $0.12-$0.68. This remains a planning range, not launch authority, because the measured 1,000-step gate did not identify the stopping-time distribution.

Frozen 400-task stopping and storage diagnostic

The first complete stratified diagnostic validated 400 of 400 tasks across 60 strata. Its sealed analysis identity is sha256:9aaff11076c7fc7f7b3209e657e69b6901a7533c2bab9a1ce928629bf6dd1c8e, bound to batch manifest sha256:766069d5ee7be3ad37fa1a4d399fa943de78f6f8dd1022e46c7bfbf7d771bd35 and receipt set sha256:1d35fff9002f0aae8228a3761e54ada917c7f54f4c5334bda99f228b176d2bf9. Reanalysis produced the same identity.

The point estimates at the 5,000-iteration diagnostic cap are 113,716.88 CPU-core-seconds, 2.7407 GB of artifacts, a 69.29% stopping-rule trigger probability, and a 30.71% censoring probability. These are diagnostic estimates only. The preregistered precision gate failed because the overall relative half-widths were 19.72% for runtime and 12.55% for storage, above the frozen 10% limit. Five non-regression suites also exceeded at least one frozen 20% per-suite limit. The result therefore has precision_pass: false, all scientific claims remain HOLD, and no full-matrix launch is authorized from it.

The independent follow-up is frozen in configs/stopping_storage_precision_followup_v1.json. It draws a fresh SHA-ranked sample from the full 14,000-task population, preserves all 60 strata and the Gaussian main versus ablation pairs, and analyzes the follow-up independently. Its 2,580 tasks include 90 expected pilot overlaps by design. Those overlaps were rerun under the follow-up commit, so runtime evidence was not reused. The original 10% overall and 20% per-suite gates were unchanged. The launch controller was local only, used eight one-thread workers, issued tasks in a separately bound SHA-ranked order so the first 200 were interleaved across suites, evaluated a conservative wall projection after those 200 completions, and would have blocked further issuance if the projected upper wall exceeded 5,400 seconds.

Frozen 2,580-task precision follow-up

The clean execution used manifest sha256:5e0f724f8faa52207cf8ce0df822db08c868541b369c54d9fa48b10df1a6543a at commit e5db1b7082b0056ad80695e0936100c15f9d5ee7. All 2,580 tasks succeeded, no failure ledger was created, and the 200-task wall gate passed with a conservative projection of 3,811.84 seconds against the frozen 5,400-second limit.

The validated aggregate identity is sha256:65c51df2681e33ba1363341cd44bcfd8d094b8427cc599eb40ac6c1f95ae862d. The sealed analysis identity is sha256:4b2009f94a968455b96ec3f7c0a618cb446d4f3c67ec610f86e0180097e2c3b6. A full independent reanalysis produced the same identity and file hash.

At the 5,000-iteration diagnostic cap, the projected full-matrix requirements are 124,251.44 CPU-core-seconds, or 34.51 CPU-core-hours, and 2.9407 GB of artifacts. The projected stopping-rule trigger probability is 66.72%, leaving 33.28% censored at the cap. Overall relative half-widths are 5.71% for runtime and 6.03% for storage. All fourteen suite-by-metric checks pass the frozen 20% limit; the widest is 14.54% for Gaussian-main runtime.

This gate authorizes only the diagnostic resource estimate. It does not freeze cost, authorize the full matrix, or support a paper claim. C1, C2, and C3 remain HOLD. Because roughly one-third of tasks are projected to reach the cap, a fresh-process checkpoint/resume canary is required before any full-matrix launch.

Checkpoint/resume canary result

The eight-task fresh-process canary passed from clean commit 654bce052ee076f65a1a38f06fdae769afb35403. Its sealed receipt is sha256:ae7f31368dc23426f43b9bd8e651596cd90b5020c861a89304337da9348a679d, bound to manifest sha256:559fe003a09b0b71457f125dc1fa42ff0c3e43aeb7907bbb5d987968c6853946. All eight resumed candidates exactly matched distinct-identity uninterrupted oracles, including the terminal post-update solve. The closed 56-event lifecycle completed in 37.203 seconds, below the frozen 300-second cutoff, with all external authority denied.

This result establishes that the saved Algorithm 2 state is sufficient for exact cold-process continuation on the frozen canary routes. It does not yet put checkpoint/resume into the production 14,000-task result schema, authorize the full matrix, freeze cost, or support C1-C3. The next gate must integrate the proven state and lifecycle contract into the production batch runner, then pass a bounded interrupted production-batch canary before a full launch.