Hypothesis feed

Protocol: fresh clone of main 49e429e built ON dev-ai (binary sha256 12eaff4d...5830c, rustc 1.96.1) vs the rev-7 L1v2 binary already resident (sha256 re-verified 534d3553...92c9f). Slices sha-verified (dickens.2m df925056..., nci.2m 6788fcc1..., ooffice.2m 5041e86f...). taskset 0-15, CUBR_THREADS=RAYON=OMP=4 (meta-35 semantics), admission loadavg 1.40 < 2.0 with process snapshot recorded; builds interleaved within every sample round; post-run 1-min load 2.05 attributed to self-decay (final 110 s threads-4 encode) - pre/post ps snapshots show the identical light resident daemons with < 0.05 cores total delta and nothing new; per-cell sample spread <= 0.7% across 48 minutes. Raw journal: repo documentation/ephemeral/research/CUBR-LEVERS-STAND-20260808/ (levers-timing.tsv + log). Unmeasured cells left empty; evaluation untouched (0). [CORRECTION 2026-08-08 · CUBR-PR43-COLSHIFT] Decode RSS is per-file: dickens +11.4%, nci +19.6%, ooffice +4.4% from the three-sample medians. The earlier ~11% shorthand described dickens only and is not a corpus figure. Encode RSS is too noisy at three samples for a trend claim. The nine-column TSV was revalidated: 18 rows, three samples per file/build, rt=PASS on all 18, and retained old/new warm archives cmp byte-identical. [EXTENSION 2026-08-08 · CUBR-PRESET-RSS] Preregistered runner completed under systemd with result=success/exit 0, admission loadavg 0.24, pin 0-15, threads 4, one warmup and median of three interleaved decode samples per build/file/preset. Public evidence: documentation/ephemeral/research/CUBR-LEVERS-PRESET-RSS-20260808/; preset-rss.tsv sha256 8c58098bd669855f3d50ef2dc5c89d2b05d3e90cec0696db2a5eeadca805659a; preset-rss.public.log sha256 3162fce4ca1a3ce883a0fe4a3da8b6e4e330b19a911d8bcb4b9a4768a1b30829; systemd-show.public.txt sha256 2208c94d97341d4d2c02308e96253fe507623b69d5d3b62901500523085ab441; archive-model-inspection.txt sha256 7d28886f5ec817bad0f61cd306414ee27919e15c76820fb79153e5a751d15f3a. Unredacted log sha256 e8b4f6aa1235b474fb99751e4256e20083d9b38218bd9767dab5c44e6d139469 is retained only in access-controlled stand evidence. Mechanism ceilings used: 768 MiB for max column-model dickens/nci, 736 MiB for uncapped base-model cells, 46 MiB for web. Evaluation remains untouched (0). [EXTENSION 2026-08-08 · CUBR-ZEROREP] Preregistered nci/max zero-representation run completed under systemd with result=success/exit 0, admission loadavg 0.16, pin 0-15, threads 4, one warmup and three interleaved decode samples per build. All three 104139-byte archives matched canonical sha256 1dcc11fa179e3aa0a0b745fba85b5c2187aa382b4b3022ec8ecd8839962b925b and all nine round trips passed. Medians: pre-PR41 18.71 s / 1430016 KiB; current packed 15.61 s / 1710592 KiB; zero-rep 15.25 s / 998912 KiB. Zero-rep reclaimed 711680 KiB (695 MiB), 253.65% of the same-run packed penalty and 90.49% of the 768 MiB ceiling; residual versus pre-PR41 was -431104 KiB. Zero/current time ratio 0.97694; pre-PR41/zero speedup 1.22689x. Compound prediction PASS. Public evidence: documentation/ephemeral/research/CUBR-ZEROREP-RESULTS-20260808/. Evaluation remains untouched (0). [EXTENSION 2026-08-09 · CUBR-ZEROREP-MATRIX-G3] Preregistered eight-cell zero-representation matrix completed under systemd with result=success/exit 0, pin 0-15, threads 4, one warmup and three interleaved decode samples per build. Cell verdicts: nci/balanced=PASS/ACCOUNTING_CONSISTENT; nci/web=PASS/ACCOUNTING_CONSISTENT; dickens/max=PASS/ACCOUNTING_CONSISTENT; dickens/balanced=PASS/ACCOUNTING_CONSISTENT; dickens/web=PASS/ACCOUNTING_CONSISTENT; ooffice/max=PASS/ACCOUNTING_CONSISTENT; ooffice/balanced=PASS/ACCOUNTING_CONSISTENT; ooffice/web=PASS/ACCOUNTING_CONSISTENT. All 24 canonical archives and all 96 round trips passed. Evidence: documentation/ephemeral/research/CUBR-ZEROREP-MATRIX-G3-RESULTS-20260809/. Evaluation remains untouched (0).

This is the identified cause of the largest encode/decode asymmetry in the corpus (mr 80.22x, x-ray 63.91x, sao 26.77x): the WINNING path is itself lopsided - med16 -> nested chunked base -> per-block eight-way competition at encode, against a decode that replays one scheme per block in 2.6 s. Same structural pattern as the CM2 column sweep (NEW-26), one level down. IMPORTANT DISTINCTION FOR WHOEVER IMPLEMENTS IT: unlike NEW-25 this canNOT be made byte-exact by bounding. NEW-25 was free because abandoning a candidate that already exceeded the incumbent cannot change the minimum; here the EXPENSIVE candidates are the ones that WIN, so a bound never fires on them and bounding only the losers saves ~190 s of ~1100 s rather than the ~700 s that matters. Stickiness is therefore a RATIO-COSTING preset lever: a later block where another scheme would have won gets the sticky choice instead. That cost MUST be measured, not assumed zero - the column sweep was also obviously free until it was priced at -0.71% to -4.83%. Instrumentation note: the existing per-candidate wins counter cannot answer this because it fires every time a candidate becomes the running minimum, so several candidates win per block; a FINAL: counter recording the winner OF THE BLOCK was added for this measurement. Per-class stability on exe/database/text was still running when this row was written - a scheme stable on image and unstable on text would make this a per-class preset rather than a global one, which is the shape of every other lever in this task. [PER-CLASS RESULTS 2026-07-30] x-ray (image) FINAL:geomix 384/384 blocks; ooffice (exe) FINAL:geomix 384/384 blocks. Two classes, one answer, every block - the competition is a constant wherever it runs to completion. dickens (text) and osdb (database) produced NO per-block winner rows AT ALL, and that absence is itself a result rather than a failed measurement: on those classes cm2 establishes the incumbent first, so the deferred base candidate is bounded by NEW-25 and abandoned before a single block completes. Direct evidence of NEW-25 firing, which had not previously been observed: dickens base 0.218 s completing with 1756742 output bytes on the unbounded build versus 0.097 s and ZERO output bytes abandoned on the NEW-25 build. That is worth 0.12 s of a ~119 s encode - nothing for speed, because base was never the cost on text (0.16% share) - and must NOT be quoted as a speed result; it is mechanism confirmation only. CONSEQUENCE FOR THIS LEVER SCOPE: on image and exe the per-block rows come from the NESTED, UNBOUNDED base calls inside the winning transform container, exactly the calls NEW-25 does not and should not bound (bounding the winner would be wrong). So the sticky-selection lever is aimed specifically at the NESTED competition, and its scope is currently established for IMAGE and EXE only - text and database cannot answer the question at all while NEW-25 abandons that path. [CORPUS CAMPAIGN EXTENSION 2026-08-01] Nine-file evidence available before the full N=24 campaign closed: file | class | MiB | s/MiB compress | s/MiB decompress | asymmetry samba | code | 20.6 | 11.97 | 11.887 | 1.0x reymont | text | 6.3 | 38.28 | 12.855 | 3.0x mr | image | 9.5 | 41.36 | 0.688 | 60.1x mozilla | exe | 48.8 | 44.75 | 11.886 | 3.8x dickens | text | 9.7 | 45.86 | 14.816 | 3.1x osdb | database | 9.6 | 53.96 | 16.296 | 3.3x nci | database | 32.0 | 56.85 | 9.171 | 6.2x ooffice | exe | 5.9 | 61.78 | 13.331 | 4.6x sao | binary | 6.9 | 88.41 | 3.337 | 26.5x Spearman(compress cost, asymmetry) = +0.58 across these nine files. This is weak-to-moderate supporting correlation, not proof of cause. The endpoints fit the proposed mechanism: samba is the cheapest encode and symmetric, while sao is the most expensive encode and strongly asymmetric. Size and type fits previously attempted on too few points were retracted; no scaling claim is made before N=24. Decode is bimodal in the measured corpus rows: file | class | decode MiB/s osdb | database | 0.061 webster | text | 0.077 samba | code | 0.084 mozilla | exe | 0.084 nci | database | 0.109 mr | image | 1.46 x-ray | image | 1.30 CM2-path files occupy a 0.06-0.11 MiB/s decode band across types, while the two measured image files are around 1.4 MiB/s, with a measured 17x gap and no observations between the bands. The sharpest single point is samba: encode = 0.084 MiB/s and decode = 0.084 MiB/s to three decimals. This is one measured file where the CM2 column sweep does not fire; it is structural support for the racing-candidates mechanism, not a causal proof. enwik8 adds the first 100 MB-scale observation: 95.4 MiB, measured 42.44 s/MiB compress (0.0236 MiB/s), 13.12 s/MiB decompress (0.0762 MiB/s), 3.23x asymmetry, archive size 19,552,678 bytes, byte-exact round-trip. Its per-byte costs remain inside the observed text band across a 19x file-size range (5.1-95.4 MiB); this is a bounded observation of no degradation for this file, not a general scaling claim. Three completed runs agree with 0.54% compress and 0.03% decompress spread. Cause remains UNPROVEN. The decisive test is the N=24 query joining per-file encode cost to the FINAL winning candidate already recorded by the attribution instrument. Run that join after all 24 max files are durable; it is a query, not a new experiment. The sticky-selection lever remains ratio-costing, unimplemented, and must never silently change max. [N=13 SUPERSEDING EXTENSION 2026-08-01] This N=13 snapshot supersedes the earlier nine-file table as the latest partial view; the N=9 block is intentionally preserved as measurement history. It covers all 12 Silesia files plus enwik8. Total measured compute reported at this checkpoint: 16.7 h. file | class | MiB | s/MiB compress | s/MiB decompress | asymmetry samba | code | 20.6 | 11.97 | 11.891 | 1.0x xml | text | 5.1 | 33.81 | 11.385 | 3.0x reymont | text | 6.3 | 38.28 | 12.859 | 3.0x x-ray | image | 8.1 | 38.72 | 0.766 | 50.6x webster | text | 39.5 | 40.02 | 12.991 | 3.1x mr | image | 9.5 | 41.32 | 0.690 | 59.9x enwik8 | text | 95.4 | 42.44 | 13.126 | 3.2x mozilla | exe | 48.8 | 44.76 | 11.890 | 3.8x dickens | text | 9.7 | 45.85 | 14.815 | 3.1x osdb | database | 9.6 | 53.97 | 16.310 | 3.3x nci | database | 32.0 | 56.86 | 9.180 | 6.2x ooffice | exe | 5.9 | 61.71 | 13.303 | 4.6x sao | binary | 6.9 | 88.39 | 3.342 | 26.4x The text class now has five files spanning 5.1-95.4 MiB (19x size range) with a 1.36x compress-cost spread. The ordering is not monotone in size: enwik8 is the largest and sits in the middle; xml is the smallest and cheapest. This is evidence against a simple size explanation, not a scaling claim. No corpus mean or scaling exponent is computed at N=13. Decode bimodality persists with two image observations. In table units, image decode cost is 0.690-0.766 s/MiB (about 1.45-1.30 MiB/s); the other eleven observations are 9.18-16.31 s/MiB (about 0.109-0.061 MiB/s). The speed gap is about 12-24x with nothing measured between the bands. Samba remains the only 1.0x encode/decode equality and the cheapest encode by a 2.8x margin over xml. Compress cost spans 7.39x from samba to sao, but only 2.61x with samba excluded: the partial distribution remains a tight band plus the one file known to skip the racing sweep. Cause remains UNPROVEN. The decisive per-file encode-cost to FINAL winning-candidate join runs as a query only after max reaches durable N=24. Tiny Canterbury files must be reported as measured and excluded from broad per-byte/corpus-shape statements where fixed overhead dominates. Correction: the FINAL: counter was produced by a temporary instrumented build for the x-ray measurement; its output was not persisted, so the decisive test requires re-instrumenting and re-running the encoder rather than a later database query. [N=24 COMPLETE CAMPAIGN 2026-08-02] Campaign closure: [2026-08-02T09:47:18Z] === END preset=web rc=0 === [2026-08-02T09:47:18Z] ALL PRESETS DONE The max, balanced, and lowmem-decode presets each produced 217 journal rows across 24 files, with 120 byte-exact round-trips and 0 failures. Across all three presets this is 360 byte-exact round-trips, with zero non-zero cmp_status values and zero non-zero exit_code values. Corpus ratios are retained from the DB/existing benchmark rather than timing journals: max 0.189007, balanced 0.189891 (+0.47%), and lowmem-decode 0.206627 (+9.32%). The journal archive_bytes/output_size_bytes fields cannot recover original input size, so a journal-derived ratio would be tautological. The +9.32% value is the corpus delta, not a per-file expectation. Per-file lowmem ratio cost ranged from +0.06% (xargs.1) to +15.70% (enwik8). Lowmem-decode inherits the Balanced sweep and adds the table cap; it is not an additive second sweep. The measured examples are xml 2.99x -> 3.90x and samba 0.99x -> 1.27x. No decode-speed claim is made. Measured Silesia per-file summary (Balanced ratio | Lowmem ratio | max decode RSS | lowmem decode RSS | RSS drop | lowmem ratio cost): xml 2.99x | 3.90x | 5.574 G | 0.107 G | 51.9x | +4.20% reymont 3.01x | 3.88x | 6.125 G | 0.111 G | 55.3x | +5.46% dickens 2.77x | 3.55x | 10.544 G | 0.114 G | 92.7x | +8.90% webster 2.81x | 3.13x | 10.835 G | 0.146 G | 74.0x | +14.11% osdb 2.50x | 3.11x | 12.267 G | 0.116 G | 106.0x | +9.57% enwik8 2.48x | 2.48x | 11.334 G | 0.216 G | 52.4x | +15.70% sao 1.56x | 1.65x | 0.092 G | 0.093 G | 1.0x | IDENTICAL nci 1.48x | 1.53x | 10.322 G | 0.069 G | 150.3x | +3.21% samba 0.99x | 1.27x | 12.026 G | 0.127 G | 94.4x | +5.94% ooffice 1.00x | 1.10x | 6.138 G | 0.111 G | 55.1x | +5.60% mr 1.00x | 1.07x | 0.086 G | 0.086 G | 1.0x | IDENTICAL mozilla 1.00x | 1.05x | 12.079 G | 0.164 G | 73.6x | +6.97% x-ray 1.00x | 1.00x | 0.086 G | 0.086 G | 1.0x | IDENTICAL Canterbury campaign observations are fixed-overhead dominated and excluded from corpus-level statements: cp.html 3.09x, lcet10.txt 3.12x, plrabn12.txt 3.09x, fields.c 2.74x, alice29.txt 2.68x, xargs.1 2.37x, asyoulik.txt 2.19x, kennedy.xls 1.23x, grammar.lsp 1.02x, ptt5 1.02x, sum 1.00x. Their RSS drops are 1.0-3.9x because tables never became large; these values do not assert an unprovided preset axis. The measured no-change exceptions are sao, mr, and x-ray (0.086-0.093 GiB on both presets, with byte-identical archives), plus Canterbury grammar.lsp, ptt5, and sum. These are inert-cap exceptions: their table exponent never reached the cap. Correction retained: the FINAL: counter was produced by a temporary instrumented build for the x-ray measurement; its output was not persisted, so the decisive test requires re-instrumenting and re-running the encoder rather than a later database query. The cause remains UNPROVEN. [CUBR-0092 GATE RESULT 2026-08-02 — MEASURED, GATED, NOT SHIPPED] The inner sticky value-stream candidate was implemented and measured, but it is not shipped. The pre-registered kill gate required at least 1.50x end-to-end encode speedup on both one representative image and one independent executable, byte-exact round-trip on every measured configuration, no target output growth above 1 percent, and at most plus 0.50 percent relative ratio cost on the 24-file corpus. Fixed stand: dev-ai, CPUs 0-15, CUBR_THREADS=16, one pinned baseline and candidate run per representative file. Baseline binary SHA256 d2ee91bf8b2eec3c144183ebde06fb4e72bae5c89a96d23be8bd1e08fd60dd19; candidate binary SHA256 a9fec5a2a1c74d2337581afc28eae52a0225ee5d590033bdf8100a9191e27374. - x-ray: baseline 131.10 s; candidate 98.67 s; 1.328671x, recorded as 1.33x. Compressed output was 3,637,036 bytes for both. Round-trip PASS. - ooffice: baseline 222.34 s; candidate 211.61 s; 1.050706x, recorded as 1.05x. Compressed output was 1,763,460 bytes for both. Round-trip PASS. Both speed cells miss the pre-registered 1.50x threshold. Output growth was zero on both measured representatives, but the corpus cap was not adjudicated because the newer gate stopped the 24-file sweep after 12 baseline rows and before any candidate corpus row. No verdict is claimed for the other corpus files. The speed-gate miss alone kills the ship decision. Encode RSS observations: x-ray baseline 1,746,428 KiB versus candidate 1,542,056 KiB, a 11.70 percent decrease; ooffice baseline 6,662,864 KiB versus candidate 7,340,856 KiB, a 10.18 percent increase. With one pinned run per file, these observations cannot distinguish measurement noise from retained candidate state. The cause remains unresolved, so no memory benefit is claimed; the asymmetric ooffice increase is an additional reason not to ship. Evidence is preserved at /root/cubr0092-inner-sticky-20260802T155722Z on dev-ai, including the raw representative timing files and the intentionally aborted partial corpus sweep. Source candidate remains uncommitted and unmerged; no PR, deploy, or production claim follows from this measurement. [CUBR-0092 EVIDENCE CORRECTION 2026-08-02] The original representative.tsv was defective: every enc_rss_kib cell contained the elapsed value followed by the literal maxrss_kib token. It has been renamed representative.raw.tsv so the defect remains inspectable, and representative.tsv was regenerated from the authoritative timing files. The candidate_ooffice encode cell has two runs, not one. The first run produced 217.44 seconds; its candidate_ooffice output and timing files were born at 18:07:10 +0200, and the pre-existing 77.74-second decode and original TSV row were written before the later overwrite. A second encode overwrote the output and .time files at 18:12:11 +0200; its stdout reports time_ms=211496 and its authoritative .time reports elapsed_s=211.61 maxrss_kib=7340856. Therefore 211.61 seconds is the selected final measurement, while the candidate_ooffice encode cell is n=2 and 217.44 is retained as prior-run evidence. The final 211.61-second blob was decoded separately in candidate_ooffice.final.dec.time at 78.21 seconds and byte-compared to /root/corpus-full/silesia/ooffice with decode_rc=0 and cmp_rc=0. The old baseline_ooffice decode value 79.07 was also stale; baseline_ooffice.dec.time is authoritative at 84.66 and the corrected TSV uses it. Corrected encode RSS values are numeric values from the .enc.time files: x-ray baseline 1746428 KiB, x-ray candidate 1542056 KiB, ooffice baseline 6662864 KiB, and ooffice candidate 7340856 KiB. These timings were measured on dev-ai (64 cores, pinned 0-15), not on the campaign stand 162.55.81.5 (16 cores). They are internally comparable baseline versus candidate on dev-ai and must not be compared against any N=24 campaign figure. The gate verdict remains unchanged: both selected speed cells miss 1.50x. [CUBR-0092 RESOLUTION CAVEAT 2026-08-02] The candidate ooffice encode runs were 211.61 s and 217.44 s: spread 5.83 s, versus 10.73 s from the 222.34 s baseline to the selected 211.61 s candidate. Therefore the 1.05x executable case is not distinguishable from noise at n=2 versus n=1. The x-ray comparison is n=1 on each side, so 1.33x is a single-run comparison. Verdict unchanged: the 1.50x gate was missed; do not rerun to tighten this dead lever. [PROF FOUND 2026-08-04] The committed CUBRIM_PROFILE=1 instrument was re-run on the NEW-29 Silesia corpus rather than the web corpus, using two 2 MiB representative slices. The profiler header's caveat is binding: nested candidates double-count and the table is attribution, not a partition; ordinary wins are running-minimum events. Only FINAL rows answer the final-per-block question. Evidence commit: 6f281f360b9670f992976b1e248b41343a7c5bd3. Measured binary SHA-256: 0a327d55e6d549d4c742a4ca0e098bbc5e02946311893ccddaacc898fd3fd372. Measured source commit: 3a59903910aa526a5d8e1633465f784fbfb4fc65. prof.rs blob SHA-256: 0e6c3eaf2a7b8102df3dcd1837216df4022d662c24e578acd2a4fb58fac727a7. codec.rs blob SHA-256: ff1c27faaae9739c29a40d13582edab43558774961d55e91f2e428edaaf3fa54. Full Silesia manifest SHA-256: d9203058b86b39f94f20b29603a89af5229619b06c78741c64d7098730c39647. Host nproc=16; processes pinned to CPUs 0-3; campaign host 162.55.81.5 untouched. file | class | full SHA-256 | slice SHA-256 | compressed | ratio | encode wall | decode wall | RT | FINAL x-ray.2m | image | 7de9fce1405dc44ae5e6813ed21cd5751e761bd4265655a005d39b9685d1c9ad | 9bfd1c5321dbd4dcec1cfb037189ef78ceb7052ce8647086b70b0e1cb401aab3 | 878363 | 0.418836 | 104.518 s | 1.661 s | PASS | geomix 384/384 ooffice.2m | executable | e7ee013880d34dd5208283d0d3d91b07f442e067454276095ded14f322a656eb | 5041e86f07bf17d7a8b3b0ab496a1b6413256399848709f8be543bbdca12de09 | 677605 | 0.323107 | 142.805 s | 23.912 s | PASS | geomix 384/384 Both raw profiler tables contain FINAL:geomix with 384 final blocks and no other FINAL row. Cause is proven for these measured representative image and executable slices: the inner value-scheme rail recomputes a constant final answer. This does not claim all Silesia files, an N=12/N=24 aggregate, or any speed/ratio benefit from a sticky lever. NEW-29 remains closed and its CUBR-0092 KILLED verdict is unchanged. Evidence report and raw tables: documentation/ephemeral/research/CUBR-PROFFOUND-20260804.md and its raw/ directory.

NO NUMBER EXISTS AND NONE IS ESTIMATED. The harness was built (l3.sh on dev-ai: ooffice 2 MB at CUBR_THREADS in {default,64,16,8,4}, deliberately UNPINNED because the question is whole-machine behaviour and pinning to 8 cores while varying thread count conflates the two). It waited for a quiet host, started at load 1.42, and was killed before producing a single complete row. REASON: the benchmark track had begun its competitor baseline on the same machine. Load was only 6.80 on 64 cores, so on a naive reading there was headroom - but the contention was UNEQUAL ACROSS ROWS, since a single-threaded brotli -q 11 steals ~1/64 of capacity from the 64-thread row and essentially nothing from the 4-thread row. That biases the comparison IN FAVOUR of capping threads, which is the hypothesis under test. The alternative host was at load 8.09 on 16 cores with another session's cubrim process running. Same standard applied here as was imposed on three sibling sessions during this programme. The script takes one command on a genuinely quiet host. What IS established is the mechanism, read from source, plus the observed load-82 incident - that is a defect description, not a measured lever, and must not be quoted as one. [FLAG CORRECTION 2026-07-31] This row briefly carried measured=true / status=measured while its verdict said UNMEASURED, with measure_date and measure_task both empty and ZERO rows in the measurements table. Reset to measured=false / status=open, which is what the evidence supports: L3 has no number. Recorded rather than quietly fixed because a measured=true flag with no measurement behind it is precisely the false-green this programme has been correcting elsewhere, and the next reader deserves to know the flag was once wrong here too. The three independent signals that exposed it - empty measure_date, empty measure_task, and no measurements rows - are the check worth reusing: measured=true should never coexist with them. [PROVENANCE 2026-08-05 · CUBR-0087] Raw record: dev-ai:/root/cubr0087/out/l3.tsv (mtime 2026-07-31 12:38 UTC), produced by the committed harness /root/cubr0087/l3.sh — cmp after every decode, RT PASS 5/5, output 677605 bytes on all five rows. Binary: cubrim-l1v2 sha256 534d355304eb16bf67e5b2d513b81af4d130a993c4b5e8ddd5c52317f8192c9f; source commit 06aed3a4d65ce18a46ed257abccd79c6d9055a65 (only code commit on CUBR-0087-speed-memory, merged via PR #13); codec.rs sha256 9c23b9dbcf55412136e0cfe0c9ae0884c380516c2764ee684bd8d85b55dc3ffe; prof.rs sha256 4b2672d097207d2aaafed103629b5b97db22213a6021d78e46ffd77bdd254c21 (CUBRIM_PROFILE not set — pure timing run). Corpus: silesia/ooffice[0:2097152], slice command `head -c 2097152 ooffice`, slice sha256 5041e86f07bf17d7a8b3b0ab496a1b6413256399848709f8be543bbdca12de09, full-file sha256 e7ee013880d34dd5208283d0d3d91b07f442e067454276095ded14f322a656eb. Pinning: unpinned by design (the question is whole-machine behaviour; pinning while varying thread count conflates the two); NOT comparable to the pinned (0-7) sweep rows. Independent re-verification 2026-08-05 on arcana-devs (16 cores): same binary + same slice gives 677605 bytes with archive sha256 4d563b48ae509f11b65b0c71929e0b0375b2322b26aefc489b36aefeeacd60be at both CUBR_THREADS=default and CUBR_THREADS=4, cmp round-trip PASS both, and that sha equals the F7 L1 identity-gate value for ooffice.2m; a fresh cargo release build of 06aed3a reproduces the archive byte-identically with RT PASS. Timing was deliberately NOT re-measured on arcana-devs: that host carries a steady ~1.2-core soak-test load (adsessor run-soak.sh, live since 2026-07-28), which fails the F15 quiet-host standard and would bias in favour of the capping hypothesis; the dev-ai numbers from load 0.19-0.69 stand as the observation.

Footprint sweep on dev-ai (aether), 64 cores, load 0.36, every row pinned to the same 8-core set, dickens 2 MB slice, byte-exact round-trip on every row. tbits=24 (native, control) 461437 B / enc 80.8 s / dec 27.0 s / enc RSS 1.59 GiB / dec RSS 1.47 GiB. tbits=22 466176 B (+1.03%) / 74.2 s / 25.0 s / 0.55 GiB / 0.40 GiB. tbits=20 476746 B (+3.32%) / 69.8 s / 23.5 s / 0.26 GiB / 0.109 GiB. tbits=18 499852 B (+8.32%) / 56.6 s / 19.2 s / 0.197 GiB / 0.0327 GiB. DECODE peak falls 13.5x (1.47 GiB -> 0.109 GiB) at tbits=20 for +3.32% output. This also answers M3 against the memory-bound hypothesis: a 2.9x smaller working set buys only 8% throughput, so the codec is compute-bound in the mixer, not memory-latency-bound. [IMPLEMENTED 2026-07-30, CUBR-0087] The exponent now travels in the CM2 length header, bits 56..60, with 0 meaning derive-as-before. Verified by running, not by argument: (1) a capped archive (tbits=18) decodes on a decoder given NO configuration at all - PASS; (2) uncapped output is byte-identical to the pre-change build, sha 2840d51a... on both; (3) a pre-change decoder reads new uncapped output - PASS; (4) --preset web on dickens 2 MB emits 487506 B at encode peak 0.26 GiB, round-trip PASS. COMPATIBILITY IS ONE-DIRECTIONAL and was initially documented wrong by me, then corrected: max/balanced archives leave the field zero and decode everywhere including older builds, but a decoder that predates the field CANNOT read a capped archive. It fails closed - DecodeError: MODE_CM2: coded stream exhausted before orig_len bytes decoded, exit 2, no output file - never silent corruption. That fail-closed behaviour comes from the QA-F guards that exist only on the release lineage, which is an additional argument for CUBR-0089 landing them on main. SAFETY: effective_tbits() clamps an explicit exponent to min(declared, derived) so it can only ever SHRINK; without that clamp a tiny crafted blob could request 2^27 tables and regain the QA-F-007 model-amplification vector. Shipped as EncodeConfig::cm2_max_tbits and CLI --preset web. The memory figure is class-independent (0.107-0.109 GiB decode peak on both dickens and ooffice) because decode is CM2 alone whatever won at encode time. [CUBR-0087 <-> CUBR-0075 RECONCILIATION, 2026-07-30] These are one programme, split by side of the codec, and CUBR-0087 was deliberately NOT opened as a competing track. CUBR-0075 owns the DECODE side: linear decode, bounded decoder memory, ARM, early-output, truncation robustness, static-vs-dynamic profiles. CUBR-0087 owns the ARCHIVER side: encode throughput, peak RSS, presets. The two met at one measured fact and it runs in CUBR-0075's favour: the decoder rebuilds the same CM2 model tables the encoder used, sized from orig_len, so decoding a >=16 MB file needs ~12.3 GiB (DB meta_id=35: overall 12561 MiB, silesia 12561, database 12561, exe 12368, code 12315, text 11608). wasm32 caps at 4 GiB. CUBR-0075's bounded decoder memory acceptance criterion was therefore unmeetable at ANY setting, and CUBR-0077's WASM decoder could not exist at a useful size - not through optimisation, because the tables are allocated before decoding starts. CUBR-0087 has now delivered the missing primitive: the table exponent travels in the CM2 length header (bits 56..60, 0 = derive as before) and --preset web caps it at 20, giving decode peak 0.109 GiB for +3.32% output, class-independent. So CUBR-0075 can now state a real decoder memory bound instead of an aspiration, and CUBR-0077 is unblocked. What CUBR-0087 does NOT cover and CUBR-0075 still owns: linear/streaming decode, early-output, truncation robustness, and ARM. No duplicate track was opened; this hypothesis and NEW-25/NEW-26 are the archiver-side half. [CORPUS RESULT 2026-07-31, supersedes the slice figure] Full 24-file world corpus, 314,749,364 bytes, round-trip OK on all 24 files. web 65,035,750 bytes = ratio 0.206627 against max 0.189007, i.e. +9.32% output — THREE TIMES MORE EXPENSIVE than the +3.32% measured on the 2 MB dickens slice. Cause is structural and the slice could not have shown it: a 2 MB slice derives tbits=24 so capping at 20 costs four steps, while a real corpus file >=16 MB derives tbits=27 and the same cap costs SEVEN. PRODUCT STATEMENT THIS LICENSES: the 13.5x decoder-memory cut does NOT cost the ratio lead, it narrows it from 17.3% to 9.6% — web 0.206627 still beats ppmd 0.228592 and xz 0.234411 on the same corpus. That is the honest headline for the web profile and it is a corpus number, not a slice. CAUTION: web at 0.206627 sits close to the consilium ~0.21 refusal threshold; that threshold was set for --max and web is a different operating point so it is NOT breached, but any further ratio-costing lever stacked onto web must be re-checked against it rather than assumed to have headroom. COMPATIBILITY REMAINS ONE-DIRECTIONAL AND MUST BE STATED WHEREVER web IS OFFERED: a decoder predating the table-exponent field CANNOT read a capped archive — it fails closed with DecodeError: MODE_CM2: coded stream exhausted before orig_len bytes decoded, exit 2, no output file, verified by running an older binary, never silent corruption. max and balanced archives leave the field zero and open on any decoder. [CORPUS MEMORY RESULT 2026-07-31, in world_benchmark_memory, 72 rows, rt_status OK on all 24 files of all three presets] The slice understated the memory win as badly as it understated the ratio cost. Full 24-file world corpus, dev-ai, code_sha on metas 36/37/38: max encode peak 18,599 MiB / DECODE PEAK 12,560 MiB; balanced 18,089 / 12,366; web 9,348 / 221. DECODE PEAK FALLS 12,560 -> 221 MiB = 56.8x, not the 13.5x measured on a 2 MB slice, because the corpus contains files large enough to derive the full tbits=27 model (13.5 GiB of tables) where the slice only ever derived 24. Cross-check: max decode peak 12,560 MiB against meta_id=35 max_decompress_peak_rss_kib 12,561 MiB - independent agreement on a different host. THE NUMBER THAT MATTERS FOR CUBR-0077: 221 MiB is comfortably under the wasm32 4 GiB address-space ceiling, so a browser decoder is no longer arithmetically impossible - it is ordinary. The correct public framing is NOT 13.5x better memory but decode peak 221 MiB on the world corpus, down from 12.3 GiB, which is what makes a wasm32 decoder possible at all. Encode peak also halves, 18,599 -> 9,348 MiB. Ratio cost of all this is +9.32% (0.206627 vs 0.189007) and web still leads the field: ppmd 0.228592, xz 0.234411.

dev-ai, 64 cores, load 0.36, fixed 8-core pin, byte-exact round-trip on every row. dickens 2 MB: native 461437 B in 80.76 s -> nocol 472253 B in 26.91 s = 3.00x faster for +2.35% output. ooffice 2 MB (exe): nocol emits the BYTE-IDENTICAL blob 677605 B with no speedup (94.01 s vs 93.86 s), because a type transform wins there and the CM2 column sweep never fires. Predicted before the run and confirmed by it. CONSEQUENCE FOR PUBLICATION: the 3.00x is a text/xml/database number, not a corpus number, and any public claim must name the classes it applies to. Composes with the NEW-27 table cap almost exactly: speedups multiply (3.00 x 1.16 = 3.48 predicted, 3.49 measured) and costs add (2.35 + 3.32 = 5.67 predicted, 5.65 measured). [M4 CLOSED BY DIRECT MEASUREMENT, CUBR-0087 2026-07-30] The code-scope outlier (samba 0.0851 MiB/s against a 0.0119-0.0250 band) is the column sweep NOT FIRING, confirmed rather than inferred. Attribution on a 2 MB samba slice, dev-ai: cm2 23.434 s (97.44%), cm2_variant_base 23.419 s (97.37%), and NO cm2_variant_col row at all - the instrument emits a row for every candidate that runs, so its absence is the measurement. detect_col_delims proposes nothing on a tar of C sources. cm2 total and cm2_variant_base agree to 15 ms, the same statement from the other side. Arithmetic: dickens 2 MB with the sweep firing = 80.8 s (0.0248 MiB/s); dickens with the sweep suppressed = 26.9 s (0.0744); samba = 24.1 s (0.0832), reproducing the DB code-scope 0.0851. So samba was never fast because source code is easy - it was simply not paying for a sweep everything else was paying for, and NEW-26 is the knob that brings the other classes to it. M4 and F2c are the same finding seen from opposite ends. [CORPUS RESULT 2026-07-31, supersedes every slice figure] Full 24-file world corpus, 314,749,364 bytes, round-trip OK on all 24 files. balanced 59,768,178 bytes = ratio 0.189891 against max 59,489,703 = 0.189007, i.e. +0.47% output — FIVE TIMES CHEAPER than the +2.35% measured on the dickens slice, because the column sweep is a no-op wherever CM2 does not win and most of the corpus is in that position; the slice figure came from one of the files where it bites hardest. Still #1 on the corpus: ppmd 0.228592, xz 0.234411, so balanced leads by 16.9% relative. The max run reproduces meta_id=35 (0.18900658684095069371 -> 0.189007) to six decimals on a DIFFERENT host, which is the strongest available evidence the harness is sound. PUBLICATION RULE UNCHANGED AND NOW BACKED BY CORPUS DATA: name the class. The 3.00x encode speedup is a text/xml/database figure; on exe it is a byte-identical no-op.