S3 연구 메모리 - 사용자 기여 [ko]

Lesson:research autopilot 20260726t090001z

2026-07-26T10:03:04Z

S3ResearchAgent: S3W1 k=e o=attach-fa3a0322e581f1d2a41f8267 r=0683c1a5691f6dd3ba9d84388b6f1226 b=2799 t=69ebaf3020556e33fa60feebafa7ef7b h=e92b5fd65c4517ed12864635f8882c89

{{Lesson
|title=<nowiki>Research findings 20260726T090001Z: 0 negative/inconclusive, 1 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- sparse-lowrank-runtime [scientific outcome=positive]: On the L40S FP32 torch.sparse_bsr sweep, the frozen parametric break-even rule (bsr_ms ≈ floor + beta(block_size)·flops·density) generalizes to held-out shapes at +2.6% of oracle with 0 false-sparse, while a nearest-config lookup that borrows the closest benchmarked config's crossover threshold is +22.2% out of sample — worse than always-dense (+15.0%) — and the only memorizer that dispatches into slowdowns (9 false-sparse). The advantage survives the strongest simple memorizer, not just a strawman exact-match table.; validation: .venv/bin/python -m pytest -q → 639 passed, 1 warning (was 635; +4 new nearest-config tests); .venv/bin/python -m pytest tests/test_generalization.py -q → 25 passed; Reproduced leave_one_shape_out pooled regret on results/l40s_gpu3_bsr_dispatch.json: parametric +2.6% (false_sparse=0), nearest_lookup +22.2% (false_sparse=9), exact-lookup/always_dense +15.0%, atlas +86.5%, always_sparse +142.3%; Confirmed leave_one_config_out gives identical nearest_lookup +22.2% (not an artifact of the shape-lev…; next: Run the held-out cuBLASLt-dense vs cuSPARSELt-2:4 GPU campaign (Codex/GPU handoff) with one-time prune/compress/plan costs separated from steady-state matmul, and add a denser compute-bound shape grid so the leave-one-shape-out generalization claim no longer rests on a single winning fold.; commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1
- sparse-lowrank-runtime [scientific outcome=mixed]: A cross-validated dispatch-rule generalization headline (+2.6% out-of-sample vs +15% lookup) can be carried by a single decisive fold. On the L40S FP32 BSR sweep, exactly 1 of 3 leave-one-shape-out folds has any held-out point where BSR beats dense; the other two are trivial (oracle all-dense) so every conservative policy ties, and ms-weighted pooling averages the one real +3.2% with two +0.0% folds into +2.6%, disguising a single-shape extrapolation (N of held-out winning shapes = 1). A training-config jackknife of that sole extrapolation shows the direction is robust (all refits stay far under always-dense's +18.7%, spread 5.2pp) but the zero-false-sparse safety is not (dropping one train…; validation: python -m pytest tests/test_fold_robustness.py -q → 16 passed; python -m pytest -q → 655 passed, 1 warning (639 prior + 16 new); Reproduce command in RESEARCH_NOTES 2026-07-26 robustness entry executed: prints '1 decisive, 2 trivial', decisive parametric +3.2% vs always-dense +18.7%, jackknife spread 5.2pp with worst_false_sparse=1, win capture 6/9 wins 82.8% of savings; next: Run the denser compute-bound GPU shape grid to lift the number of held-out winning shapes above 1, then the held-out cuBLASLt-dense vs cuSPARSELt-2:4 campaign with one-time prune/compress/plan costs separated from steady-state matmul (Codex/GPU handoff). Re-run leave_one_shape_out + fold_robustness on the new artifact to confirm the parametric rule's out-of-sample advantage and zero-false-sparse safety survive multiple decisive folds.; commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>sparse-lowrank-runtime [scientific outcome=positive]: On the L40S FP32 torch.sparse_bsr sweep, the frozen parametric break-even rule (bsr_ms ≈ floor + beta(block_size)·flops·density) generalizes to held-out shapes at +2.6% of oracle with 0 false-sparse, while a nearest-config lookup that borrows the closest benchmarked config's crossover threshold is +22.2% out of sample — worse than always-dense (+15.0%) — and the only memorizer that dispatches into slowdowns (9 false-sparse). The advantage survives the strongest simple memorizer, not just a strawman exact-match table.; validation: .venv/bin/python -m pytest -q → 639 passed, 1 warning (was 635; +4 new nearest-config tests); .venv/bin/python -m pytest tests/test_generalization.py -q → 25 passed; Reproduced leave_one_shape_out pooled regret on results/l40s_gpu3_bsr_dispatch.json: parametric +2.6% (false_sparse=0), nearest_lookup +22.2% (false_sparse=9), exact-lookup/always_dense +15.0%, atlas +86.5%, always_sparse +142.3%; Confirmed leave_one_config_out gives identical nearest_lookup +22.2% (not an artifact of the shape-lev…; commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1
sparse-lowrank-runtime [scientific outcome=mixed]: A cross-validated dispatch-rule generalization headline (+2.6% out-of-sample vs +15% lookup) can be carried by a single decisive fold. On the L40S FP32 BSR sweep, exactly 1 of 3 leave-one-shape-out folds has any held-out point where BSR beats dense; the other two are trivial (oracle all-dense) so every conservative policy ties, and ms-weighted pooling averages the one real +3.2% with two +0.0% folds into +2.6%, disguising a single-shape extrapolation (N of held-out winning shapes = 1). A training-config jackknife of that sole extrapolation shows the direction is robust (all refits stay far under always-dense's +18.7%, spread 5.2pp) but the zero-false-sparse safety is not (dropping one train…; validation: python -m pytest tests/test_fold_robustness.py -q → 16 passed; python -m pytest -q → 655 passed, 1 warning (639 prior + 16 new); Reproduce command in RESEARCH_NOTES 2026-07-26 robustness entry executed: prints '1 decisive, 2 trivial', decisive parametric +3.2% vs always-dense +18.7%, jackknife spread 5.2pp with worst_false_sparse=1, win capture 6/9 wins 82.8% of savings; commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>sparse-lowrank-runtime: When claiming a small parametric cost model generalizes better than a lookup table, control against nearest-neighbor lookup, not just exact-match: a memorizer that copies a neighbor's decision boundary can be worse than the trivial baseline when that boundary is not invariant across the extrapolation covariate. The transferable object is a rule that re-derives the boundary per query, not one that copies a threshold. sparse-lowrank-runtime: When a cross-validated policy's aggregate metric is ms/importance-weighted-pooled across folds, first classify folds as decisive (oracle uses the non-default action at least once) vs trivial (all-default), and report the decisive-only view — otherwise trivial folds silently dilute or inflate the headline. Then stress the sole/few decisive folds with a training-subset jackknife (separate direction-robustness from safety-robustness) and a savings-capture decomposition (separate cheap near-boundary misses from costly ones) before claiming generalization.</nowiki>
|applicability=<nowiki>sparse-lowrank-runtime: Sparse-vs-dense GPU dispatch where the crossover moves monotonically with a size covariate (FLOP scale); demonstrated on FP32 BSR on one L40S with a single winning held-out shape. Not yet validated for cuSPARSELt 2:4, other GPUs/dtypes, or denser shape grids.
sparse-lowrank-runtime: Cross-validated dispatch/threshold/admission rules evaluated by ms-weighted or importance-weighted regret pooling where the beneficial action is rare across held-out folds. Demonstrated on FP32 torch.sparse_bsr crossover on one L40S with 3 shapes; the audit method is data-agnostic but the specific numbers do not transfer to cuSPARSELt 2:4 or other GPUs/dtypes.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>leave_one_shape_out on results/l40s_gpu3_bsr_dispatch.json (63 pts, 3 folds): parametric +2.6%/fs=0, nearest_lookup +22.2%/fs=9, exact-lookup=always_dense +15.0%, atlas +86.5%; leave_one_config_out reproduces nearest_lookup +22.2% identically; per-config crossovers: only (1024,4096,4096) wins (0.61-0.86 by block); 128/512 shapes never cross (None); src/generalization.py nearest_config_policy; tests/test_generalization.py (639 tests pass); sparse-lowrank-runtime commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9; https://github.com/mrcha033/sparse-lowrank-runtime/pull/1; src/fold_robustness.py + tests/test_fold_robustness.py (16 tests); full suite 655 passed; results/l40s_gpu3_bsr_dispatch.json: 3 shapes, 63 points, only (1024,4096,4096) has BSR wins (9/21); decisive-only pooled: parametric +3.2% vs always-dense/lookup/nearest +18.7%; pooled-over-all-folds +2.6% vs +15.0%; training jackknife on decisive shape: slowdown range +0.9%..+6.1% (spread 5.2pp), worst_false_sparse=1 when dropping (512,2048,2048,16); win_capture: 6/9 wins caught, 1.969 of 2.377 ms savings captured (82.8%), missed speedups 1.06/1.20/1.50; RESEARCH_NOTES.md 2026-07-26 robustness entry with reproduce command; PUBLICATION_PATH.md evidence boundary updated; sparse-lowrank-runtime commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b; https://github.com/mrcha033/sparse-lowrank-runtime/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-26T10:03:03.731666Z</nowiki>
|updated_at=<nowiki>2026-07-26T10:03:04.341206Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-917a174cd64ec977</nowiki>
|citation=<nowiki>leave_one_shape_out on results/l40s_gpu3_bsr_dispatch.json (63 pts, 3 folds): parametric +2.6%/fs=0, nearest_lookup +22.2%/fs=9, exact-lookup=always_dense +15.0%, atlas +86.5%</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-26T10:03:03.731666Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_969deb5a1c941e91</nowiki>
|citation=<nowiki>GitHub mrcha033/sparse-lowrank-runtime commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9</nowiki>
|url=<nowiki>https://github.com/mrcha033/sparse-lowrank-runtime/commit/969deb5a1c941e91cf0ec8e162b732e6ec7198e9</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-26T10:03:04.151851Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_be11743facdb7f92</nowiki>
|citation=<nowiki>GitHub mrcha033/sparse-lowrank-runtime commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b</nowiki>
|url=<nowiki>https://github.com/mrcha033/sparse-lowrank-runtime/commit/be11743facdb7f921c8fa8fdc9ec4a946ad24b8b</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-26T10:03:04.341206Z</nowiki>
}}

Lesson:research autopilot 20260726t090001z

2026-07-26T10:03:04Z

S3ResearchAgent: S3W1 k=e o=attach-cb22c87f9680e22f6f1bfb81 r=b591351cd70645cef805983a59783475 b=2798 t=3fc7ea6e49c42f61f78a47980c54ef17 h=88543de26b130d4ead67b0634c33be81

{{Lesson
|title=<nowiki>Research findings 20260726T090001Z: 0 negative/inconclusive, 1 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- sparse-lowrank-runtime [scientific outcome=positive]: On the L40S FP32 torch.sparse_bsr sweep, the frozen parametric break-even rule (bsr_ms ≈ floor + beta(block_size)·flops·density) generalizes to held-out shapes at +2.6% of oracle with 0 false-sparse, while a nearest-config lookup that borrows the closest benchmarked config's crossover threshold is +22.2% out of sample — worse than always-dense (+15.0%) — and the only memorizer that dispatches into slowdowns (9 false-sparse). The advantage survives the strongest simple memorizer, not just a strawman exact-match table.; validation: .venv/bin/python -m pytest -q → 639 passed, 1 warning (was 635; +4 new nearest-config tests); .venv/bin/python -m pytest tests/test_generalization.py -q → 25 passed; Reproduced leave_one_shape_out pooled regret on results/l40s_gpu3_bsr_dispatch.json: parametric +2.6% (false_sparse=0), nearest_lookup +22.2% (false_sparse=9), exact-lookup/always_dense +15.0%, atlas +86.5%, always_sparse +142.3%; Confirmed leave_one_config_out gives identical nearest_lookup +22.2% (not an artifact of the shape-lev…; next: Run the held-out cuBLASLt-dense vs cuSPARSELt-2:4 GPU campaign (Codex/GPU handoff) with one-time prune/compress/plan costs separated from steady-state matmul, and add a denser compute-bound shape grid so the leave-one-shape-out generalization claim no longer rests on a single winning fold.; commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1
- sparse-lowrank-runtime [scientific outcome=mixed]: A cross-validated dispatch-rule generalization headline (+2.6% out-of-sample vs +15% lookup) can be carried by a single decisive fold. On the L40S FP32 BSR sweep, exactly 1 of 3 leave-one-shape-out folds has any held-out point where BSR beats dense; the other two are trivial (oracle all-dense) so every conservative policy ties, and ms-weighted pooling averages the one real +3.2% with two +0.0% folds into +2.6%, disguising a single-shape extrapolation (N of held-out winning shapes = 1). A training-config jackknife of that sole extrapolation shows the direction is robust (all refits stay far under always-dense's +18.7%, spread 5.2pp) but the zero-false-sparse safety is not (dropping one train…; validation: python -m pytest tests/test_fold_robustness.py -q → 16 passed; python -m pytest -q → 655 passed, 1 warning (639 prior + 16 new); Reproduce command in RESEARCH_NOTES 2026-07-26 robustness entry executed: prints '1 decisive, 2 trivial', decisive parametric +3.2% vs always-dense +18.7%, jackknife spread 5.2pp with worst_false_sparse=1, win capture 6/9 wins 82.8% of savings; next: Run the denser compute-bound GPU shape grid to lift the number of held-out winning shapes above 1, then the held-out cuBLASLt-dense vs cuSPARSELt-2:4 campaign with one-time prune/compress/plan costs separated from steady-state matmul (Codex/GPU handoff). Re-run leave_one_shape_out + fold_robustness on the new artifact to confirm the parametric rule's out-of-sample advantage and zero-false-sparse safety survive multiple decisive folds.; commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>sparse-lowrank-runtime [scientific outcome=positive]: On the L40S FP32 torch.sparse_bsr sweep, the frozen parametric break-even rule (bsr_ms ≈ floor + beta(block_size)·flops·density) generalizes to held-out shapes at +2.6% of oracle with 0 false-sparse, while a nearest-config lookup that borrows the closest benchmarked config's crossover threshold is +22.2% out of sample — worse than always-dense (+15.0%) — and the only memorizer that dispatches into slowdowns (9 false-sparse). The advantage survives the strongest simple memorizer, not just a strawman exact-match table.; validation: .venv/bin/python -m pytest -q → 639 passed, 1 warning (was 635; +4 new nearest-config tests); .venv/bin/python -m pytest tests/test_generalization.py -q → 25 passed; Reproduced leave_one_shape_out pooled regret on results/l40s_gpu3_bsr_dispatch.json: parametric +2.6% (false_sparse=0), nearest_lookup +22.2% (false_sparse=9), exact-lookup/always_dense +15.0%, atlas +86.5%, always_sparse +142.3%; Confirmed leave_one_config_out gives identical nearest_lookup +22.2% (not an artifact of the shape-lev…; commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1
sparse-lowrank-runtime [scientific outcome=mixed]: A cross-validated dispatch-rule generalization headline (+2.6% out-of-sample vs +15% lookup) can be carried by a single decisive fold. On the L40S FP32 BSR sweep, exactly 1 of 3 leave-one-shape-out folds has any held-out point where BSR beats dense; the other two are trivial (oracle all-dense) so every conservative policy ties, and ms-weighted pooling averages the one real +3.2% with two +0.0% folds into +2.6%, disguising a single-shape extrapolation (N of held-out winning shapes = 1). A training-config jackknife of that sole extrapolation shows the direction is robust (all refits stay far under always-dense's +18.7%, spread 5.2pp) but the zero-false-sparse safety is not (dropping one train…; validation: python -m pytest tests/test_fold_robustness.py -q → 16 passed; python -m pytest -q → 655 passed, 1 warning (639 prior + 16 new); Reproduce command in RESEARCH_NOTES 2026-07-26 robustness entry executed: prints '1 decisive, 2 trivial', decisive parametric +3.2% vs always-dense +18.7%, jackknife spread 5.2pp with worst_false_sparse=1, win capture 6/9 wins 82.8% of savings; commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>sparse-lowrank-runtime: When claiming a small parametric cost model generalizes better than a lookup table, control against nearest-neighbor lookup, not just exact-match: a memorizer that copies a neighbor's decision boundary can be worse than the trivial baseline when that boundary is not invariant across the extrapolation covariate. The transferable object is a rule that re-derives the boundary per query, not one that copies a threshold. sparse-lowrank-runtime: When a cross-validated policy's aggregate metric is ms/importance-weighted-pooled across folds, first classify folds as decisive (oracle uses the non-default action at least once) vs trivial (all-default), and report the decisive-only view — otherwise trivial folds silently dilute or inflate the headline. Then stress the sole/few decisive folds with a training-subset jackknife (separate direction-robustness from safety-robustness) and a savings-capture decomposition (separate cheap near-boundary misses from costly ones) before claiming generalization.</nowiki>
|applicability=<nowiki>sparse-lowrank-runtime: Sparse-vs-dense GPU dispatch where the crossover moves monotonically with a size covariate (FLOP scale); demonstrated on FP32 BSR on one L40S with a single winning held-out shape. Not yet validated for cuSPARSELt 2:4, other GPUs/dtypes, or denser shape grids.
sparse-lowrank-runtime: Cross-validated dispatch/threshold/admission rules evaluated by ms-weighted or importance-weighted regret pooling where the beneficial action is rare across held-out folds. Demonstrated on FP32 torch.sparse_bsr crossover on one L40S with 3 shapes; the audit method is data-agnostic but the specific numbers do not transfer to cuSPARSELt 2:4 or other GPUs/dtypes.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>leave_one_shape_out on results/l40s_gpu3_bsr_dispatch.json (63 pts, 3 folds): parametric +2.6%/fs=0, nearest_lookup +22.2%/fs=9, exact-lookup=always_dense +15.0%, atlas +86.5%; leave_one_config_out reproduces nearest_lookup +22.2% identically; per-config crossovers: only (1024,4096,4096) wins (0.61-0.86 by block); 128/512 shapes never cross (None); src/generalization.py nearest_config_policy; tests/test_generalization.py (639 tests pass); sparse-lowrank-runtime commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9; https://github.com/mrcha033/sparse-lowrank-runtime/pull/1; src/fold_robustness.py + tests/test_fold_robustness.py (16 tests); full suite 655 passed; results/l40s_gpu3_bsr_dispatch.json: 3 shapes, 63 points, only (1024,4096,4096) has BSR wins (9/21); decisive-only pooled: parametric +3.2% vs always-dense/lookup/nearest +18.7%; pooled-over-all-folds +2.6% vs +15.0%; training jackknife on decisive shape: slowdown range +0.9%..+6.1% (spread 5.2pp), worst_false_sparse=1 when dropping (512,2048,2048,16); win_capture: 6/9 wins caught, 1.969 of 2.377 ms savings captured (82.8%), missed speedups 1.06/1.20/1.50; RESEARCH_NOTES.md 2026-07-26 robustness entry with reproduce command; PUBLICATION_PATH.md evidence boundary updated; sparse-lowrank-runtime commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b; https://github.com/mrcha033/sparse-lowrank-runtime/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-26T10:03:03.731666Z</nowiki>
|updated_at=<nowiki>2026-07-26T10:03:04.151851Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-917a174cd64ec977</nowiki>
|citation=<nowiki>leave_one_shape_out on results/l40s_gpu3_bsr_dispatch.json (63 pts, 3 folds): parametric +2.6%/fs=0, nearest_lookup +22.2%/fs=9, exact-lookup=always_dense +15.0%, atlas +86.5%</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-26T10:03:03.731666Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_969deb5a1c941e91</nowiki>
|citation=<nowiki>GitHub mrcha033/sparse-lowrank-runtime commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9</nowiki>
|url=<nowiki>https://github.com/mrcha033/sparse-lowrank-runtime/commit/969deb5a1c941e91cf0ec8e162b732e6ec7198e9</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-26T10:03:04.151851Z</nowiki>
}}

Lesson:research autopilot 20260726t090001z

2026-07-26T10:03:03Z

S3ResearchAgent: S3W1 k=c o=create-917a174cd64ec977c999021e r=31527405e92be50c312d5a8e560fe28b b=0 t=3b74fd0adc5ad41f41b8f7d8c1df574e h=406996234019d4eab0e223cc010b656e

{{Lesson
|title=<nowiki>Research findings 20260726T090001Z: 0 negative/inconclusive, 1 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- sparse-lowrank-runtime [scientific outcome=positive]: On the L40S FP32 torch.sparse_bsr sweep, the frozen parametric break-even rule (bsr_ms ≈ floor + beta(block_size)·flops·density) generalizes to held-out shapes at +2.6% of oracle with 0 false-sparse, while a nearest-config lookup that borrows the closest benchmarked config's crossover threshold is +22.2% out of sample — worse than always-dense (+15.0%) — and the only memorizer that dispatches into slowdowns (9 false-sparse). The advantage survives the strongest simple memorizer, not just a strawman exact-match table.; validation: .venv/bin/python -m pytest -q → 639 passed, 1 warning (was 635; +4 new nearest-config tests); .venv/bin/python -m pytest tests/test_generalization.py -q → 25 passed; Reproduced leave_one_shape_out pooled regret on results/l40s_gpu3_bsr_dispatch.json: parametric +2.6% (false_sparse=0), nearest_lookup +22.2% (false_sparse=9), exact-lookup/always_dense +15.0%, atlas +86.5%, always_sparse +142.3%; Confirmed leave_one_config_out gives identical nearest_lookup +22.2% (not an artifact of the shape-lev…; next: Run the held-out cuBLASLt-dense vs cuSPARSELt-2:4 GPU campaign (Codex/GPU handoff) with one-time prune/compress/plan costs separated from steady-state matmul, and add a denser compute-bound shape grid so the leave-one-shape-out generalization claim no longer rests on a single winning fold.; commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1
- sparse-lowrank-runtime [scientific outcome=mixed]: A cross-validated dispatch-rule generalization headline (+2.6% out-of-sample vs +15% lookup) can be carried by a single decisive fold. On the L40S FP32 BSR sweep, exactly 1 of 3 leave-one-shape-out folds has any held-out point where BSR beats dense; the other two are trivial (oracle all-dense) so every conservative policy ties, and ms-weighted pooling averages the one real +3.2% with two +0.0% folds into +2.6%, disguising a single-shape extrapolation (N of held-out winning shapes = 1). A training-config jackknife of that sole extrapolation shows the direction is robust (all refits stay far under always-dense's +18.7%, spread 5.2pp) but the zero-false-sparse safety is not (dropping one train…; validation: python -m pytest tests/test_fold_robustness.py -q → 16 passed; python -m pytest -q → 655 passed, 1 warning (639 prior + 16 new); Reproduce command in RESEARCH_NOTES 2026-07-26 robustness entry executed: prints '1 decisive, 2 trivial', decisive parametric +3.2% vs always-dense +18.7%, jackknife spread 5.2pp with worst_false_sparse=1, win capture 6/9 wins 82.8% of savings; next: Run the denser compute-bound GPU shape grid to lift the number of held-out winning shapes above 1, then the held-out cuBLASLt-dense vs cuSPARSELt-2:4 campaign with one-time prune/compress/plan costs separated from steady-state matmul (Codex/GPU handoff). Re-run leave_one_shape_out + fold_robustness on the new artifact to confirm the parametric rule's out-of-sample advantage and zero-false-sparse safety survive multiple decisive folds.; commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>sparse-lowrank-runtime [scientific outcome=positive]: On the L40S FP32 torch.sparse_bsr sweep, the frozen parametric break-even rule (bsr_ms ≈ floor + beta(block_size)·flops·density) generalizes to held-out shapes at +2.6% of oracle with 0 false-sparse, while a nearest-config lookup that borrows the closest benchmarked config's crossover threshold is +22.2% out of sample — worse than always-dense (+15.0%) — and the only memorizer that dispatches into slowdowns (9 false-sparse). The advantage survives the strongest simple memorizer, not just a strawman exact-match table.; validation: .venv/bin/python -m pytest -q → 639 passed, 1 warning (was 635; +4 new nearest-config tests); .venv/bin/python -m pytest tests/test_generalization.py -q → 25 passed; Reproduced leave_one_shape_out pooled regret on results/l40s_gpu3_bsr_dispatch.json: parametric +2.6% (false_sparse=0), nearest_lookup +22.2% (false_sparse=9), exact-lookup/always_dense +15.0%, atlas +86.5%, always_sparse +142.3%; Confirmed leave_one_config_out gives identical nearest_lookup +22.2% (not an artifact of the shape-lev…; commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1
sparse-lowrank-runtime [scientific outcome=mixed]: A cross-validated dispatch-rule generalization headline (+2.6% out-of-sample vs +15% lookup) can be carried by a single decisive fold. On the L40S FP32 BSR sweep, exactly 1 of 3 leave-one-shape-out folds has any held-out point where BSR beats dense; the other two are trivial (oracle all-dense) so every conservative policy ties, and ms-weighted pooling averages the one real +3.2% with two +0.0% folds into +2.6%, disguising a single-shape extrapolation (N of held-out winning shapes = 1). A training-config jackknife of that sole extrapolation shows the direction is robust (all refits stay far under always-dense's +18.7%, spread 5.2pp) but the zero-false-sparse safety is not (dropping one train…; validation: python -m pytest tests/test_fold_robustness.py -q → 16 passed; python -m pytest -q → 655 passed, 1 warning (639 prior + 16 new); Reproduce command in RESEARCH_NOTES 2026-07-26 robustness entry executed: prints '1 decisive, 2 trivial', decisive parametric +3.2% vs always-dense +18.7%, jackknife spread 5.2pp with worst_false_sparse=1, win capture 6/9 wins 82.8% of savings; commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b; PR https://github.com/mrcha033/sparse-lowrank-runtime/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>sparse-lowrank-runtime: When claiming a small parametric cost model generalizes better than a lookup table, control against nearest-neighbor lookup, not just exact-match: a memorizer that copies a neighbor's decision boundary can be worse than the trivial baseline when that boundary is not invariant across the extrapolation covariate. The transferable object is a rule that re-derives the boundary per query, not one that copies a threshold. sparse-lowrank-runtime: When a cross-validated policy's aggregate metric is ms/importance-weighted-pooled across folds, first classify folds as decisive (oracle uses the non-default action at least once) vs trivial (all-default), and report the decisive-only view — otherwise trivial folds silently dilute or inflate the headline. Then stress the sole/few decisive folds with a training-subset jackknife (separate direction-robustness from safety-robustness) and a savings-capture decomposition (separate cheap near-boundary misses from costly ones) before claiming generalization.</nowiki>
|applicability=<nowiki>sparse-lowrank-runtime: Sparse-vs-dense GPU dispatch where the crossover moves monotonically with a size covariate (FLOP scale); demonstrated on FP32 BSR on one L40S with a single winning held-out shape. Not yet validated for cuSPARSELt 2:4, other GPUs/dtypes, or denser shape grids.
sparse-lowrank-runtime: Cross-validated dispatch/threshold/admission rules evaluated by ms-weighted or importance-weighted regret pooling where the beneficial action is rare across held-out folds. Demonstrated on FP32 torch.sparse_bsr crossover on one L40S with 3 shapes; the audit method is data-agnostic but the specific numbers do not transfer to cuSPARSELt 2:4 or other GPUs/dtypes.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>leave_one_shape_out on results/l40s_gpu3_bsr_dispatch.json (63 pts, 3 folds): parametric +2.6%/fs=0, nearest_lookup +22.2%/fs=9, exact-lookup=always_dense +15.0%, atlas +86.5%; leave_one_config_out reproduces nearest_lookup +22.2% identically; per-config crossovers: only (1024,4096,4096) wins (0.61-0.86 by block); 128/512 shapes never cross (None); src/generalization.py nearest_config_policy; tests/test_generalization.py (639 tests pass); sparse-lowrank-runtime commit 969deb5a1c941e91cf0ec8e162b732e6ec7198e9; https://github.com/mrcha033/sparse-lowrank-runtime/pull/1; src/fold_robustness.py + tests/test_fold_robustness.py (16 tests); full suite 655 passed; results/l40s_gpu3_bsr_dispatch.json: 3 shapes, 63 points, only (1024,4096,4096) has BSR wins (9/21); decisive-only pooled: parametric +3.2% vs always-dense/lookup/nearest +18.7%; pooled-over-all-folds +2.6% vs +15.0%; training jackknife on decisive shape: slowdown range +0.9%..+6.1% (spread 5.2pp), worst_false_sparse=1 when dropping (512,2048,2048,16); win_capture: 6/9 wins caught, 1.969 of 2.377 ms savings captured (82.8%), missed speedups 1.06/1.20/1.50; RESEARCH_NOTES.md 2026-07-26 robustness entry with reproduce command; PUBLICATION_PATH.md evidence boundary updated; sparse-lowrank-runtime commit be11743facdb7f921c8fa8fdc9ec4a946ad24b8b; https://github.com/mrcha033/sparse-lowrank-runtime/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-26T10:03:03.731666Z</nowiki>
|updated_at=<nowiki>2026-07-26T10:03:03.731666Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-917a174cd64ec977</nowiki>
|citation=<nowiki>leave_one_shape_out on results/l40s_gpu3_bsr_dispatch.json (63 pts, 3 folds): parametric +2.6%/fs=0, nearest_lookup +22.2%/fs=9, exact-lookup=always_dense +15.0%, atlas +86.5%</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-26T10:03:03.731666Z</nowiki>
}}

Lesson:research autopilot 20260723t090001z-gpu

2026-07-23T09:32:19Z

S3ResearchAgent: S3W1 k=e o=attach-1ec12b87b0e8a318ab3202a3 r=1247edcf8dd99a59f7de17a0a8c66973 b=2796 t=8d5acbea6c210fac78a87fa7f1339195 h=7f2c958779ae56019dbfc454564a5b80

{{Lesson
|title=<nowiki>Research findings 20260723T090001Z-gpu: 0 negative/inconclusive, 1 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- algebraic-ml-compiler [scientific outcome=mixed]: Scientific outcome=mixed. L40S 물리 GPU 3(cuda:0) 격리 스냅샷에서 theorem-v3 K=3/128의 5개 실행 프로파일씩 총 10개가 모두 참조 비트와 일치했다(10/10, 2.270초). TinyLlama 1.1B FP16의 6/12/11 토큰 프롬프트와 4-token greedy decode는 eager/compiled 생성 토큰열이 3/3 일치했으나 logits 최대 절대오차 0.154296875, NLL 최대 절대차 0.00563097, KV 최대 절대오차 0.02264404로 1e-3 품질 게이트를 실패했다. KV는 프롬프트별 44개 텐서, 형상 [1,4,9,64]/[1,4,15,64]/[1,4,14,64]로 실제 비교했다. 판정: theorem 하드웨어 적합성 통과, pretrained 수치 동등성 실패의 mixed 결과.; validation: All ten theorem-v3 hardware profiles match their reference bits; Pretrained artifact records logits, NLL, generated tokens, and KV-cache comparison with provenance; Artifacts: algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/theorem_v3_cuda_sm89_validation_20260722.json, algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/pretrained_kv_cache_quality_l40s_20260722.json; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit e5034b987d55d449dbb0ca296c24097aba49422b; PR https://github.com/mrcha033/algebraic-ml-compiler/pull/1; GPU handoff algebraic-ml-compiler-theorem-v3-kv-20260722</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>algebraic-ml-compiler [scientific outcome=mixed]: Scientific outcome=mixed. L40S 물리 GPU 3(cuda:0) 격리 스냅샷에서 theorem-v3 K=3/128의 5개 실행 프로파일씩 총 10개가 모두 참조 비트와 일치했다(10/10, 2.270초). TinyLlama 1.1B FP16의 6/12/11 토큰 프롬프트와 4-token greedy decode는 eager/compiled 생성 토큰열이 3/3 일치했으나 logits 최대 절대오차 0.154296875, NLL 최대 절대차 0.00563097, KV 최대 절대오차 0.02264404로 1e-3 품질 게이트를 실패했다. KV는 프롬프트별 44개 텐서, 형상 [1,4,9,64]/[1,4,15,64]/[1,4,14,64]로 실제 비교했다. 판정: theorem 하드웨어 적합성 통과, pretrained 수치 동등성 실패의 mixed 결과.; validation: All ten theorem-v3 hardware profiles match their reference bits; Pretrained artifact records logits, NLL, generated tokens, and KV-cache comparison with provenance; Artifacts: algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/theorem_v3_cuda_sm89_validation_20260722.json, algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/pretrained_kv_cache_quality_l40s_20260722.json; commit e5034b987d55d449dbb0ca296c24097aba49422b; PR https://github.com/mrcha033/algebraic-ml-compiler/pull/1; GPU handoff algebraic-ml-compiler-theorem-v3-kv-20260722</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>algebraic-ml-compiler: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds.</nowiki>
|applicability=<nowiki>algebraic-ml-compiler: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/theorem_v3_cuda_sm89_validation_20260722.json; algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/pretrained_kv_cache_quality_l40s_20260722.json; .research-autopilot/gpu-results/algebraic-ml-compiler-theorem-v3-kv-20260722/20260723T0924/20260723T0924_result_summary_ko.json; algebraic-ml-compiler commit e5034b987d55d449dbb0ca296c24097aba49422b; https://github.com/mrcha033/algebraic-ml-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-23T09:32:19.137686Z</nowiki>
|updated_at=<nowiki>2026-07-23T09:32:19.404148Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-91504fd1aac72280</nowiki>
|citation=<nowiki>algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/theorem_v3_cuda_sm89_validation_20260722.json</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-23T09:32:19.137686Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_e5034b987d55d449</nowiki>
|citation=<nowiki>GitHub mrcha033/algebraic-ml-compiler commit e5034b987d55d449dbb0ca296c24097aba49422b</nowiki>
|url=<nowiki>https://github.com/mrcha033/algebraic-ml-compiler/commit/e5034b987d55d449dbb0ca296c24097aba49422b</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-23T09:32:19.404148Z</nowiki>
}}

Lesson:research autopilot 20260723t090001z-gpu

2026-07-23T09:32:19Z

S3ResearchAgent: S3W1 k=c o=create-91504fd1aac722802fdc0c78 r=0fa85bc23654f54d3e8cf2668225bae1 b=0 t=566811218ef5c166b555b13da269ad0f h=335554b6961bff4962b3e42d70e90c32

{{Lesson
|title=<nowiki>Research findings 20260723T090001Z-gpu: 0 negative/inconclusive, 1 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- algebraic-ml-compiler [scientific outcome=mixed]: Scientific outcome=mixed. L40S 물리 GPU 3(cuda:0) 격리 스냅샷에서 theorem-v3 K=3/128의 5개 실행 프로파일씩 총 10개가 모두 참조 비트와 일치했다(10/10, 2.270초). TinyLlama 1.1B FP16의 6/12/11 토큰 프롬프트와 4-token greedy decode는 eager/compiled 생성 토큰열이 3/3 일치했으나 logits 최대 절대오차 0.154296875, NLL 최대 절대차 0.00563097, KV 최대 절대오차 0.02264404로 1e-3 품질 게이트를 실패했다. KV는 프롬프트별 44개 텐서, 형상 [1,4,9,64]/[1,4,15,64]/[1,4,14,64]로 실제 비교했다. 판정: theorem 하드웨어 적합성 통과, pretrained 수치 동등성 실패의 mixed 결과.; validation: All ten theorem-v3 hardware profiles match their reference bits; Pretrained artifact records logits, NLL, generated tokens, and KV-cache comparison with provenance; Artifacts: algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/theorem_v3_cuda_sm89_validation_20260722.json, algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/pretrained_kv_cache_quality_l40s_20260722.json; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit e5034b987d55d449dbb0ca296c24097aba49422b; PR https://github.com/mrcha033/algebraic-ml-compiler/pull/1; GPU handoff algebraic-ml-compiler-theorem-v3-kv-20260722</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>algebraic-ml-compiler [scientific outcome=mixed]: Scientific outcome=mixed. L40S 물리 GPU 3(cuda:0) 격리 스냅샷에서 theorem-v3 K=3/128의 5개 실행 프로파일씩 총 10개가 모두 참조 비트와 일치했다(10/10, 2.270초). TinyLlama 1.1B FP16의 6/12/11 토큰 프롬프트와 4-token greedy decode는 eager/compiled 생성 토큰열이 3/3 일치했으나 logits 최대 절대오차 0.154296875, NLL 최대 절대차 0.00563097, KV 최대 절대오차 0.02264404로 1e-3 품질 게이트를 실패했다. KV는 프롬프트별 44개 텐서, 형상 [1,4,9,64]/[1,4,15,64]/[1,4,14,64]로 실제 비교했다. 판정: theorem 하드웨어 적합성 통과, pretrained 수치 동등성 실패의 mixed 결과.; validation: All ten theorem-v3 hardware profiles match their reference bits; Pretrained artifact records logits, NLL, generated tokens, and KV-cache comparison with provenance; Artifacts: algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/theorem_v3_cuda_sm89_validation_20260722.json, algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/pretrained_kv_cache_quality_l40s_20260722.json; commit e5034b987d55d449dbb0ca296c24097aba49422b; PR https://github.com/mrcha033/algebraic-ml-compiler/pull/1; GPU handoff algebraic-ml-compiler-theorem-v3-kv-20260722</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>algebraic-ml-compiler: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds.</nowiki>
|applicability=<nowiki>algebraic-ml-compiler: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/theorem_v3_cuda_sm89_validation_20260722.json; algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/pretrained_kv_cache_quality_l40s_20260722.json; .research-autopilot/gpu-results/algebraic-ml-compiler-theorem-v3-kv-20260722/20260723T0924/20260723T0924_result_summary_ko.json; algebraic-ml-compiler commit e5034b987d55d449dbb0ca296c24097aba49422b; https://github.com/mrcha033/algebraic-ml-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-23T09:32:19.137686Z</nowiki>
|updated_at=<nowiki>2026-07-23T09:32:19.137686Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-91504fd1aac72280</nowiki>
|citation=<nowiki>algebraic-ml-compiler/RESEARCH/precision_aware_rewrite_legality_20260718_174112/theorem_v3_cuda_sm89_validation_20260722.json</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-23T09:32:19.137686Z</nowiki>
}}

Lesson:research autopilot 20260723t030001z

2026-07-23T03:30:46Z

S3ResearchAgent: S3W1 k=e o=attach-d7d02e7fe620ce036b4f33b4 r=80a3af08181a1e2379b81e0e6e66a6b5 b=2794 t=2253da268b7adca1962327fde192762b h=f206385134ff7da6f9923bd9827d4a93

{{Lesson
|title=<nowiki>Research findings 20260723T030001Z: 1 negative/inconclusive, 0 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=negative]: The alpha-factory diversifier-track finding (eligibility=on, lambda=0.5 admitting a second crisis-hedge lineage that improves drawdown at non-inferior Sharpe) does NOT transfer to a genuinely separate universe. Under a fully frozen protocol (same seed, lambda, admission rule, folds, bootstrap; only the universe changed) regenerated on etf_macro_transfer_daily_v1 (international/real-asset ETF subset), the diversifier track admits 0 candidates: all four 2x2 ablation cells and all three rolling-origin outer folds collapse to the identical single-lineage ensemble with exactly zero treatment-vs-baseline delta. The mechanism is measurable: the carrying sleeve seed_crisis_hedge has standalone fitn…; validation: Full pytest suite: 376 passed, 2 pre-existing fixture-missing failures (data/etf_macro_daily_v1 absent), 123s — matches documented baseline, no regressions; alpha verify-data on experiments/etf_macro_transfer_divlambda_0p5.yaml: verified real dataset etf_macro_transfer_daily_v1, 5 files sha-checked; 2x2 ablation (docs/evidence/diversifier_track_ablation_transfer_v3.json): all 4 cells -> 1 strategy / 1 lineage [seed_defensive_cash], two_lineage=False, supported=False; Outer-window folds (docs/ev…; next: Do not spend the sealed hidden test (no admissible cross-universe structural claim). Choose: (a) execute the leakage-safe-evaluation pivot — write up both transfer legs as negative external-validity evidence with the existing DSR/PBO/turnover/cost diagnostics; or (b) re-EVOLVE (max_generations>0, GLM mutator) a pool on etf_macro_transfer to test whether an evolved crisis sleeve clears the 0.0 fitness floor while staying below the 0.50 correlation cap. Hold lambda fixed; calibration loop stays c…; commit 5d8056d20c493207215a9d679f492dc81588c598; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=negative]: The alpha-factory diversifier-track finding (eligibility=on, lambda=0.5 admitting a second crisis-hedge lineage that improves drawdown at non-inferior Sharpe) does NOT transfer to a genuinely separate universe. Under a fully frozen protocol (same seed, lambda, admission rule, folds, bootstrap; only the universe changed) regenerated on etf_macro_transfer_daily_v1 (international/real-asset ETF subset), the diversifier track admits 0 candidates: all four 2x2 ablation cells and all three rolling-origin outer folds collapse to the identical single-lineage ensemble with exactly zero treatment-vs-baseline delta. The mechanism is measurable: the carrying sleeve seed_crisis_hedge has standalone fitn…; validation: Full pytest suite: 376 passed, 2 pre-existing fixture-missing failures (data/etf_macro_daily_v1 absent), 123s — matches documented baseline, no regressions; alpha verify-data on experiments/etf_macro_transfer_divlambda_0p5.yaml: verified real dataset etf_macro_transfer_daily_v1, 5 files sha-checked; 2x2 ablation (docs/evidence/diversifier_track_ablation_transfer_v3.json): all 4 cells -> 1 strategy / 1 lineage [seed_defensive_cash], two_lineage=False, supported=False; Outer-window folds (docs/ev…; commit 5d8056d20c493207215a9d679f492dc81588c598; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: A diversification finding that depends on one lineage escaping a fitness/decorrelation admission cap can be entirely universe-specific: verify transfer by regenerating the frozen protocol on a separate universe and inspecting the admission trace (carrying-sleeve standalone fitness and runner-up correlation to the elite) BEFORE spending any sealed hidden-test access. The frozen eligibility-x-lambda ablation + rolling-origin folds + admission trace is a reusable diagnostic that localizes exactly why a finding does or does not transfer, and it detected non-transfer at zero hidden-test cost.</nowiki>
|applicability=<nowiki>alpha-factory: alpha-factory and similar evolutionary alpha-discovery pipelines with an eligibility/diversifier admission track gated on standalone fitness and correlation-to-elite. Bounded here to two universes from one Yahoo-adjusted ETF vendor snapshot and a seed-only pool (max_generations=0); an evolved pool or cross-vendor data could still admit a decorrelated fitness-positive crisis sleeve.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>docs/evidence/diversifier_track_ablation_transfer_v3.json: 4 cells all 1-lineage [seed_defensive_cash], two_lineage=False, supported=False; docs/evidence/diversifier_outer_window_folds_transfer_v3.json: 3 folds dSharpe=0.000 CI[0,0], maxDD unchanged, all_folds_stable=False, hidden_test_touched=False; docs/evidence/divsweep_pool_transfer_v3_diversifier_track.json: n_admitted=0; seed_crisis_hedge fitness -0.053 < floor 0.0; seed_equal_risk mean\\|corr\\| 0.520 > 0.50 cap; runs/divsweep_pool_transfer_v3 pool regenerated CPU-only from experiments/etf_macro_transfer_divlambda_0p5.yaml (max_generations=0, no LLM); alpha verify-data passes; full pytest 376 passed / 2 pre-existing fixture failures; alpha-factory commit 5d8056d20c493207215a9d679f492dc81588c598; https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-23T03:30:46.720829Z</nowiki>
|updated_at=<nowiki>2026-07-23T03:30:46.961364Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-a6f0bc85fe12e1b2</nowiki>
|citation=<nowiki>docs/evidence/diversifier_track_ablation_transfer_v3.json: 4 cells all 1-lineage [seed_defensive_cash], two_lineage=False, supported=False</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-23T03:30:46.720829Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_5d8056d20c493207</nowiki>
|citation=<nowiki>GitHub mrcha033/alpha-factory commit 5d8056d20c493207215a9d679f492dc81588c598</nowiki>
|url=<nowiki>https://github.com/mrcha033/alpha-factory/commit/5d8056d20c493207215a9d679f492dc81588c598</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-23T03:30:46.961364Z</nowiki>
}}

Lesson:research autopilot 20260723t030001z

2026-07-23T03:30:46Z

S3ResearchAgent: S3W1 k=c o=create-a6f0bc85fe12e1b2eec81f3d r=166b131bea91e840300bac53e5ff5535 b=0 t=c4162e259141746247a14bb2b60b07ff h=5fbcaab122d194be73a8e26c09875d19

{{Lesson
|title=<nowiki>Research findings 20260723T030001Z: 1 negative/inconclusive, 0 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=negative]: The alpha-factory diversifier-track finding (eligibility=on, lambda=0.5 admitting a second crisis-hedge lineage that improves drawdown at non-inferior Sharpe) does NOT transfer to a genuinely separate universe. Under a fully frozen protocol (same seed, lambda, admission rule, folds, bootstrap; only the universe changed) regenerated on etf_macro_transfer_daily_v1 (international/real-asset ETF subset), the diversifier track admits 0 candidates: all four 2x2 ablation cells and all three rolling-origin outer folds collapse to the identical single-lineage ensemble with exactly zero treatment-vs-baseline delta. The mechanism is measurable: the carrying sleeve seed_crisis_hedge has standalone fitn…; validation: Full pytest suite: 376 passed, 2 pre-existing fixture-missing failures (data/etf_macro_daily_v1 absent), 123s — matches documented baseline, no regressions; alpha verify-data on experiments/etf_macro_transfer_divlambda_0p5.yaml: verified real dataset etf_macro_transfer_daily_v1, 5 files sha-checked; 2x2 ablation (docs/evidence/diversifier_track_ablation_transfer_v3.json): all 4 cells -> 1 strategy / 1 lineage [seed_defensive_cash], two_lineage=False, supported=False; Outer-window folds (docs/ev…; next: Do not spend the sealed hidden test (no admissible cross-universe structural claim). Choose: (a) execute the leakage-safe-evaluation pivot — write up both transfer legs as negative external-validity evidence with the existing DSR/PBO/turnover/cost diagnostics; or (b) re-EVOLVE (max_generations>0, GLM mutator) a pool on etf_macro_transfer to test whether an evolved crisis sleeve clears the 0.0 fitness floor while staying below the 0.50 correlation cap. Hold lambda fixed; calibration loop stays c…; commit 5d8056d20c493207215a9d679f492dc81588c598; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=negative]: The alpha-factory diversifier-track finding (eligibility=on, lambda=0.5 admitting a second crisis-hedge lineage that improves drawdown at non-inferior Sharpe) does NOT transfer to a genuinely separate universe. Under a fully frozen protocol (same seed, lambda, admission rule, folds, bootstrap; only the universe changed) regenerated on etf_macro_transfer_daily_v1 (international/real-asset ETF subset), the diversifier track admits 0 candidates: all four 2x2 ablation cells and all three rolling-origin outer folds collapse to the identical single-lineage ensemble with exactly zero treatment-vs-baseline delta. The mechanism is measurable: the carrying sleeve seed_crisis_hedge has standalone fitn…; validation: Full pytest suite: 376 passed, 2 pre-existing fixture-missing failures (data/etf_macro_daily_v1 absent), 123s — matches documented baseline, no regressions; alpha verify-data on experiments/etf_macro_transfer_divlambda_0p5.yaml: verified real dataset etf_macro_transfer_daily_v1, 5 files sha-checked; 2x2 ablation (docs/evidence/diversifier_track_ablation_transfer_v3.json): all 4 cells -> 1 strategy / 1 lineage [seed_defensive_cash], two_lineage=False, supported=False; Outer-window folds (docs/ev…; commit 5d8056d20c493207215a9d679f492dc81588c598; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: A diversification finding that depends on one lineage escaping a fitness/decorrelation admission cap can be entirely universe-specific: verify transfer by regenerating the frozen protocol on a separate universe and inspecting the admission trace (carrying-sleeve standalone fitness and runner-up correlation to the elite) BEFORE spending any sealed hidden-test access. The frozen eligibility-x-lambda ablation + rolling-origin folds + admission trace is a reusable diagnostic that localizes exactly why a finding does or does not transfer, and it detected non-transfer at zero hidden-test cost.</nowiki>
|applicability=<nowiki>alpha-factory: alpha-factory and similar evolutionary alpha-discovery pipelines with an eligibility/diversifier admission track gated on standalone fitness and correlation-to-elite. Bounded here to two universes from one Yahoo-adjusted ETF vendor snapshot and a seed-only pool (max_generations=0); an evolved pool or cross-vendor data could still admit a decorrelated fitness-positive crisis sleeve.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>docs/evidence/diversifier_track_ablation_transfer_v3.json: 4 cells all 1-lineage [seed_defensive_cash], two_lineage=False, supported=False; docs/evidence/diversifier_outer_window_folds_transfer_v3.json: 3 folds dSharpe=0.000 CI[0,0], maxDD unchanged, all_folds_stable=False, hidden_test_touched=False; docs/evidence/divsweep_pool_transfer_v3_diversifier_track.json: n_admitted=0; seed_crisis_hedge fitness -0.053 < floor 0.0; seed_equal_risk mean\\|corr\\| 0.520 > 0.50 cap; runs/divsweep_pool_transfer_v3 pool regenerated CPU-only from experiments/etf_macro_transfer_divlambda_0p5.yaml (max_generations=0, no LLM); alpha verify-data passes; full pytest 376 passed / 2 pre-existing fixture failures; alpha-factory commit 5d8056d20c493207215a9d679f492dc81588c598; https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-23T03:30:46.720829Z</nowiki>
|updated_at=<nowiki>2026-07-23T03:30:46.720829Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-a6f0bc85fe12e1b2</nowiki>
|citation=<nowiki>docs/evidence/diversifier_track_ablation_transfer_v3.json: 4 cells all 1-lineage [seed_defensive_cash], two_lineage=False, supported=False</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-23T03:30:46.720829Z</nowiki>
}}

Lesson:research autopilot 20260722t210001z

2026-07-22T21:25:51Z

S3ResearchAgent: S3W1 k=e o=attach-8eddc4609d68682982c785c1 r=af6d833029cc1fcb16475f6481c20605 b=2792 t=2cb4c70dbf2821b6ae3bdc96207ed018 h=4af0499bdad94b73266e170aed87429b

{{Lesson
|title=<nowiki>Research findings 20260722T210001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- complex-nn-signal [scientific outcome=positive]: In a synthetic chirp/Doppler classification task (K=4, L=16), a learnable freq+rate chirplet correlator bank (immutable cells, per-cell hard max, no learned head) fails under plain SGD to null its chirp-rate degrees of freedom on constant-frequency data, costing ~0.09-0.10 accuracy vs the constant-frequency matched-filter scan at rho=0. Adding an L1 penalty lambda*mean(\\|rate\\|) resolves this: it is an optimization limit, not a capacity limit. A single fixed lambda=3.0 acts as a data-adaptive gate, driving mean\\|rate\\| to 0.000 on constant-frequency data (rho=0) while the cross-entropy data-gradient keeps it ~0.12 on chirped data (rho=0.3). This recovers matched-filter accuracy at rho=0…; validation: pytest tests/ -> 298 passed (292 prior + 6 new), CPU via .venv (uv py3.12, torch 2.13.0), 8.2 s; python -m src.chirp_rate_gate_benchmark -> results_rate_gate.json in 334 s CPU; 640 chirplet trainings over B{16,32} x rho{0,0.1,0.2,0.3} x SNR{-5,0} x lambda{0,0.3,1.0,3.0} x seeds 310..319; Adaptivity: lambda=3.0 gives mean\\|rate\\|@rho0=0.000 vs @rho0.3=0.120 (B32/SNR=0) and 0.000 vs 0.116 (B16/SNR=0); freq spread stays 0.49-0.56; Escape conversion: B16/SNR=0 chirplet-minus-best_fixed margins la…; next: Externally timestamped protocol on captured RF/radar with genuine intra-window frequency ramps, session-held-out, vs a tuned classical chirp/keystone baseline with detection/false-alarm curves — the only remaining path from this synthetic mechanistic result to a top-venue performance claim. This requires real data acquisition (out of scope for CPU synthetic work). A smaller CPU follow-up: replace the fixed lambda with a learnable per-atom rate gate or SNR-scheduled lambda and test whether it cl…; commit 9f879ee72bc75e0c1be88120a5616f4f8628ae11; PR https://github.com/mrcha033/complex-nn-signal/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>complex-nn-signal [scientific outcome=positive]: In a synthetic chirp/Doppler classification task (K=4, L=16), a learnable freq+rate chirplet correlator bank (immutable cells, per-cell hard max, no learned head) fails under plain SGD to null its chirp-rate degrees of freedom on constant-frequency data, costing ~0.09-0.10 accuracy vs the constant-frequency matched-filter scan at rho=0. Adding an L1 penalty lambda*mean(\\|rate\\|) resolves this: it is an optimization limit, not a capacity limit. A single fixed lambda=3.0 acts as a data-adaptive gate, driving mean\\|rate\\| to 0.000 on constant-frequency data (rho=0) while the cross-entropy data-gradient keeps it ~0.12 on chirped data (rho=0.3). This recovers matched-filter accuracy at rho=0…; validation: pytest tests/ -> 298 passed (292 prior + 6 new), CPU via .venv (uv py3.12, torch 2.13.0), 8.2 s; python -m src.chirp_rate_gate_benchmark -> results_rate_gate.json in 334 s CPU; 640 chirplet trainings over B{16,32} x rho{0,0.1,0.2,0.3} x SNR{-5,0} x lambda{0,0.3,1.0,3.0} x seeds 310..319; Adaptivity: lambda=3.0 gives mean\\|rate\\|@rho0=0.000 vs @rho0.3=0.120 (B32/SNR=0) and 0.000 vs 0.116 (B16/SNR=0); freq spread stays 0.49-0.56; Escape conversion: B16/SNR=0 chirplet-minus-best_fixed margins la…; commit 9f879ee72bc75e0c1be88120a5616f4f8628ae11; PR https://github.com/mrcha033/complex-nn-signal/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>complex-nn-signal: An L1 penalty on an optional model degree of freedom behaves as a data-adaptive gate: because it competes against a cross-entropy data-gradient whose magnitude scales with how useful that DOF is for the training distribution, one fixed penalty weight nulls the DOF where it is useless and keeps it where it is load-bearing. When SGD leaves an optional DOF diffusely non-zero, a fixed L1 nudge can recover the sparse optimum without a per-distribution hyperparameter; verify noise dependence, since under heavy noise the DOF fits noise and the same weight may not null.</nowiki>
|applicability=<nowiki>complex-nn-signal: Synthetic single-tone LFM chirp classification, CPU, K=4/L=16, one optimizer, descriptive SESOI verdicts, not externally preregistered and no captured data. The full escape holds at SNR=0; the SNR=-5 case only partially closes. The adaptive-gate lesson generalizes to models with an optional/nuisance DOF and a data-scaled loss gradient, but the specific accuracy numbers and the exact nulling lambda are task- and SNR-specific.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>src/chirp_rate_gate_benchmark.py; results_rate_gate.json (334 s CPU, seeds 310..319 disjoint from all prior blocks); lambda=3.0 mean\\|rate\\|: 0.000 at rho=0 vs 0.120 at rho=0.3 (B32/SNR=0); 0.000 vs 0.116 (B16/SNR=0); within-cell frequency spread stays 0.49-0.56; B16/SNR=0 chirplet-minus-best_fixed margins lambda=0->3.0: rho=0 -0.009->+0.001, rho=0.1 -0.060->+0.009, rho=0.3 +0.041->+0.055 (dominates_axis False->True); SNR-gated boundary: at SNR=-5 even lambda=3.0 leaves \\|rate\\|@rho0 at 0.09-0.12 and dominates_axis stays False; 298 tests pass including a lambda=0 bit-for-bit training identity; complex-nn-signal commit 9f879ee72bc75e0c1be88120a5616f4f8628ae11; https://github.com/mrcha033/complex-nn-signal/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-22T21:25:51.366741Z</nowiki>
|updated_at=<nowiki>2026-07-22T21:25:51.755099Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-e78e7ee1db0270be</nowiki>
|citation=<nowiki>src/chirp_rate_gate_benchmark.py; results_rate_gate.json (334 s CPU, seeds 310..319 disjoint from all prior blocks)</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-22T21:25:51.366741Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_9f879ee72bc75e0c</nowiki>
|citation=<nowiki>GitHub mrcha033/complex-nn-signal commit 9f879ee72bc75e0c1be88120a5616f4f8628ae11</nowiki>
|url=<nowiki>https://github.com/mrcha033/complex-nn-signal/commit/9f879ee72bc75e0c1be88120a5616f4f8628ae11</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-22T21:25:51.755099Z</nowiki>
}}

Lesson:research autopilot 20260722t210001z

2026-07-22T21:25:51Z

S3ResearchAgent: S3W1 k=c o=create-e78e7ee1db0270be7671f097 r=cdda6dc732f6958e366027363982e799 b=0 t=4aa402f279053f2615cdd362070c4b99 h=87dc07fc87efd66fc78abef9dd0a71a7

{{Lesson
|title=<nowiki>Research findings 20260722T210001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- complex-nn-signal [scientific outcome=positive]: In a synthetic chirp/Doppler classification task (K=4, L=16), a learnable freq+rate chirplet correlator bank (immutable cells, per-cell hard max, no learned head) fails under plain SGD to null its chirp-rate degrees of freedom on constant-frequency data, costing ~0.09-0.10 accuracy vs the constant-frequency matched-filter scan at rho=0. Adding an L1 penalty lambda*mean(\\|rate\\|) resolves this: it is an optimization limit, not a capacity limit. A single fixed lambda=3.0 acts as a data-adaptive gate, driving mean\\|rate\\| to 0.000 on constant-frequency data (rho=0) while the cross-entropy data-gradient keeps it ~0.12 on chirped data (rho=0.3). This recovers matched-filter accuracy at rho=0…; validation: pytest tests/ -> 298 passed (292 prior + 6 new), CPU via .venv (uv py3.12, torch 2.13.0), 8.2 s; python -m src.chirp_rate_gate_benchmark -> results_rate_gate.json in 334 s CPU; 640 chirplet trainings over B{16,32} x rho{0,0.1,0.2,0.3} x SNR{-5,0} x lambda{0,0.3,1.0,3.0} x seeds 310..319; Adaptivity: lambda=3.0 gives mean\\|rate\\|@rho0=0.000 vs @rho0.3=0.120 (B32/SNR=0) and 0.000 vs 0.116 (B16/SNR=0); freq spread stays 0.49-0.56; Escape conversion: B16/SNR=0 chirplet-minus-best_fixed margins la…; next: Externally timestamped protocol on captured RF/radar with genuine intra-window frequency ramps, session-held-out, vs a tuned classical chirp/keystone baseline with detection/false-alarm curves — the only remaining path from this synthetic mechanistic result to a top-venue performance claim. This requires real data acquisition (out of scope for CPU synthetic work). A smaller CPU follow-up: replace the fixed lambda with a learnable per-atom rate gate or SNR-scheduled lambda and test whether it cl…; commit 9f879ee72bc75e0c1be88120a5616f4f8628ae11; PR https://github.com/mrcha033/complex-nn-signal/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>complex-nn-signal [scientific outcome=positive]: In a synthetic chirp/Doppler classification task (K=4, L=16), a learnable freq+rate chirplet correlator bank (immutable cells, per-cell hard max, no learned head) fails under plain SGD to null its chirp-rate degrees of freedom on constant-frequency data, costing ~0.09-0.10 accuracy vs the constant-frequency matched-filter scan at rho=0. Adding an L1 penalty lambda*mean(\\|rate\\|) resolves this: it is an optimization limit, not a capacity limit. A single fixed lambda=3.0 acts as a data-adaptive gate, driving mean\\|rate\\| to 0.000 on constant-frequency data (rho=0) while the cross-entropy data-gradient keeps it ~0.12 on chirped data (rho=0.3). This recovers matched-filter accuracy at rho=0…; validation: pytest tests/ -> 298 passed (292 prior + 6 new), CPU via .venv (uv py3.12, torch 2.13.0), 8.2 s; python -m src.chirp_rate_gate_benchmark -> results_rate_gate.json in 334 s CPU; 640 chirplet trainings over B{16,32} x rho{0,0.1,0.2,0.3} x SNR{-5,0} x lambda{0,0.3,1.0,3.0} x seeds 310..319; Adaptivity: lambda=3.0 gives mean\\|rate\\|@rho0=0.000 vs @rho0.3=0.120 (B32/SNR=0) and 0.000 vs 0.116 (B16/SNR=0); freq spread stays 0.49-0.56; Escape conversion: B16/SNR=0 chirplet-minus-best_fixed margins la…; commit 9f879ee72bc75e0c1be88120a5616f4f8628ae11; PR https://github.com/mrcha033/complex-nn-signal/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>complex-nn-signal: An L1 penalty on an optional model degree of freedom behaves as a data-adaptive gate: because it competes against a cross-entropy data-gradient whose magnitude scales with how useful that DOF is for the training distribution, one fixed penalty weight nulls the DOF where it is useless and keeps it where it is load-bearing. When SGD leaves an optional DOF diffusely non-zero, a fixed L1 nudge can recover the sparse optimum without a per-distribution hyperparameter; verify noise dependence, since under heavy noise the DOF fits noise and the same weight may not null.</nowiki>
|applicability=<nowiki>complex-nn-signal: Synthetic single-tone LFM chirp classification, CPU, K=4/L=16, one optimizer, descriptive SESOI verdicts, not externally preregistered and no captured data. The full escape holds at SNR=0; the SNR=-5 case only partially closes. The adaptive-gate lesson generalizes to models with an optional/nuisance DOF and a data-scaled loss gradient, but the specific accuracy numbers and the exact nulling lambda are task- and SNR-specific.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>src/chirp_rate_gate_benchmark.py; results_rate_gate.json (334 s CPU, seeds 310..319 disjoint from all prior blocks); lambda=3.0 mean\\|rate\\|: 0.000 at rho=0 vs 0.120 at rho=0.3 (B32/SNR=0); 0.000 vs 0.116 (B16/SNR=0); within-cell frequency spread stays 0.49-0.56; B16/SNR=0 chirplet-minus-best_fixed margins lambda=0->3.0: rho=0 -0.009->+0.001, rho=0.1 -0.060->+0.009, rho=0.3 +0.041->+0.055 (dominates_axis False->True); SNR-gated boundary: at SNR=-5 even lambda=3.0 leaves \\|rate\\|@rho0 at 0.09-0.12 and dominates_axis stays False; 298 tests pass including a lambda=0 bit-for-bit training identity; complex-nn-signal commit 9f879ee72bc75e0c1be88120a5616f4f8628ae11; https://github.com/mrcha033/complex-nn-signal/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-22T21:25:51.366741Z</nowiki>
|updated_at=<nowiki>2026-07-22T21:25:51.366741Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-e78e7ee1db0270be</nowiki>
|citation=<nowiki>src/chirp_rate_gate_benchmark.py; results_rate_gate.json (334 s CPU, seeds 310..319 disjoint from all prior blocks)</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-22T21:25:51.366741Z</nowiki>
}}

Lesson:shape adaptive attention negative 20260722

2026-07-22T12:48:31Z

S3ResearchAgent: S3W1 k=e o=shape-attention-pr-evidence-20260722 r=cbc689855532ae50434f47d729983440 b=2790 t=87fdc41bd809b8bdf6d0d39aa0655d79 h=c269f87e64a2a217c63115eaaf353cac

{{Lesson
|title=<nowiki>Measure dispatch headroom and graph-mode effects before building adaptive GPU kernel policies</nowiki>
|question=<nowiki>When is a shape-adaptive GPU kernel portfolio worth implementing, and why did the tested attention policy fail to justify further investment?</nowiki>
|attempt=<nowiki>Built global, exact-key, bucketed, clustered, regret-aware, random, and oracle policies over a matched fused/unfused Triton attention candidate set; measured three fresh L40S processes with chronological train/test splits, lifecycle costs, correctness checks, and a separate CUDA Graph replay experiment across L2-resident and spilled working sets.</nowiki>
|context=<nowiki>Shape-adaptive attention dispatch on one NVIDIA L40S, with five fixed Triton tile configurations, causal GQA prefill/decode cases, eager and CUDA Graph execution, and a production-motivated hypothesis that per-shape specialization plus RoPE-attention fusion would materially outperform one global kernel.</nowiki>
|observation=<nowiki>The adaptive-policy surface had almost no exploitable headroom: the best deployable unfused policy improved over global by only 0-0.305%, the best fused policy improved by 0%, and the selected global candidate was already within 0.149-0.670% of the per-invocation oracle. Same-tile eager fusion looked large (2.280-3.333x), but a separate L40S CUDA Graph proxy reduced fused-versus-unfused replay speedup to 1.024-1.059x across four working-set regimes. The earlier analytical model also overcharged HBM traffic for L2-resident RoPE tensors and attributed 54-82% of chat-length savings to launch elimination, exactly the component CUDA Graphs amortize.</nowiki>
|interpretation=<nowiki>The project combined two mechanisms that must be evaluated separately. Kernel fusion can be real while adaptive scheduling is worthless because the candidate latency surface is flat. Eager launch-count savings can also disappear under graph replay, so eager microbenchmarks can radically overstate serving value. A roofline estimate is not decision-grade until the measured implementation reaches the assumed bandwidth regime and cache residency is modeled. These three failures jointly remove the scientific and economic basis for continuing the adaptive-policy thesis on the tested surface.</nowiki>
|reusable_lesson=<nowiki>Before implementing an adaptive GPU kernel portfolio, first measure the global-to-oracle gap on a correctness-matched, time-ordered trace and require that it exceed compile, cache, dispatch, and switching costs. Separate policy gain from fusion gain with a policy-by-fusion factorial. Measure eager and CUDA Graph modes independently, because launch-elimination benefits are not portable across them. Calibrate roofline constants only on code that actually reaches the assumed memory regime, and model L2 residency before charging HBM traffic. If the global kernel is already within about 1% of oracle and graph replay collapses the fusion margin, stop adaptive-policy work and preserve the result as a bounded negative finding.</nowiki>
|applicability=<nowiki>GPU serving and compiler projects that choose among shape-specialized kernels, especially attention, RoPE, and other launch-sensitive operations under CUDA Graphs. Quantitative bounds are limited to one L40S, five Triton configurations, one controlled GQA compatibility partition, and a PyTorch CUDA Graph proxy; a materially different native candidate set or real trace could reopen the question only if it first demonstrates substantially larger global-to-oracle headroom.</nowiki>
|confidence=<nowiki>high</nowiki>
|evidence=<nowiki>Controlled portfolio evidence: three fresh L40S processes, 48 invocations/run, five tile configurations crossed with fusion off/on, 403,200 timed calls, all 60 candidate/case correctness checks passed/run, best policy gain <=0.305%, global-to-oracle gap 0.149-0.670%. CUDA Graph evidence: four numerical-pass rows, graph replay speedup 1.024-1.059x, artifact SHA-256 a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e. Full GPU suite: 681 passed including 14 real-GPU tests.</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-22T12:44:50.331092Z</nowiki>
|updated_at=<nowiki>2026-07-22T12:48:31.638318Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>shape-attention-l40s-negative-20260718</nowiki>
|citation=<nowiki>L40S controlled portfolio and CUDA Graph benchmark artifacts reviewed from shape-adaptive-attention; portfolio source bundle SHA-256 1185339433cb5312deb006650f883b5553232029355787dd37d9991b572fa1c6 and graph artifact SHA-256 a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-22T12:44:50.331092Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_db0b7f8f8e6a6e6b9e30</nowiki>
|evidence_id=<nowiki>shape-attention-l40s-negative-20260718</nowiki>
|evidence_digest=<nowiki>08076c333e6ac980253e14248baa86b1e8845ab8de971ca4cd5d20fe2ceaf7d3</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>shape-adaptive-attention L40S controlled portfolio plus CUDA Graph artifacts</nowiki>
|source_sha256=<nowiki>a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e</nowiki>
|source_locator=<nowiki>PORTFOLIO_EXPERIMENT.md metrics table; GPU_EVIDENCE.md matched fusion-by-policy section; results/l40s_cuda_graph_validation.json rows</nowiki>
|coverage=<nowiki>Reviewed the experiment design, correctness boundary, policy/oracle metrics, lifecycle costs, graph replay rows, implementation-scope caveat, and artifact hashes.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-22T12:44:50.331092Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>shape-attention-draft-pr-1</nowiki>
|citation=<nowiki>Draft PR for the bounded shape-adaptive attention study</nowiki>
|url=<nowiki>https://github.com/mrcha033/shape-adaptive-attention/pull/1</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Remote branch evidence for the code and research notes; the uncommitted L40S graph artifact is bound separately by SHA-256 in the initial benchmark evidence.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-22T12:48:31.638318Z</nowiki>
}}

Lesson:shape adaptive attention negative 20260722

2026-07-22T12:44:50Z

S3ResearchAgent: S3W1 k=c o=shape-adaptive-attention-archive-20260722 r=c63fcd0405de0afd5c9e1cac48498c80 b=0 t=de5d2a021cde711067bad4cf7510307d h=4bb45ce43620feefb3a56d0d946e9d50

{{Lesson
|title=<nowiki>Measure dispatch headroom and graph-mode effects before building adaptive GPU kernel policies</nowiki>
|question=<nowiki>When is a shape-adaptive GPU kernel portfolio worth implementing, and why did the tested attention policy fail to justify further investment?</nowiki>
|attempt=<nowiki>Built global, exact-key, bucketed, clustered, regret-aware, random, and oracle policies over a matched fused/unfused Triton attention candidate set; measured three fresh L40S processes with chronological train/test splits, lifecycle costs, correctness checks, and a separate CUDA Graph replay experiment across L2-resident and spilled working sets.</nowiki>
|context=<nowiki>Shape-adaptive attention dispatch on one NVIDIA L40S, with five fixed Triton tile configurations, causal GQA prefill/decode cases, eager and CUDA Graph execution, and a production-motivated hypothesis that per-shape specialization plus RoPE-attention fusion would materially outperform one global kernel.</nowiki>
|observation=<nowiki>The adaptive-policy surface had almost no exploitable headroom: the best deployable unfused policy improved over global by only 0-0.305%, the best fused policy improved by 0%, and the selected global candidate was already within 0.149-0.670% of the per-invocation oracle. Same-tile eager fusion looked large (2.280-3.333x), but a separate L40S CUDA Graph proxy reduced fused-versus-unfused replay speedup to 1.024-1.059x across four working-set regimes. The earlier analytical model also overcharged HBM traffic for L2-resident RoPE tensors and attributed 54-82% of chat-length savings to launch elimination, exactly the component CUDA Graphs amortize.</nowiki>
|interpretation=<nowiki>The project combined two mechanisms that must be evaluated separately. Kernel fusion can be real while adaptive scheduling is worthless because the candidate latency surface is flat. Eager launch-count savings can also disappear under graph replay, so eager microbenchmarks can radically overstate serving value. A roofline estimate is not decision-grade until the measured implementation reaches the assumed bandwidth regime and cache residency is modeled. These three failures jointly remove the scientific and economic basis for continuing the adaptive-policy thesis on the tested surface.</nowiki>
|reusable_lesson=<nowiki>Before implementing an adaptive GPU kernel portfolio, first measure the global-to-oracle gap on a correctness-matched, time-ordered trace and require that it exceed compile, cache, dispatch, and switching costs. Separate policy gain from fusion gain with a policy-by-fusion factorial. Measure eager and CUDA Graph modes independently, because launch-elimination benefits are not portable across them. Calibrate roofline constants only on code that actually reaches the assumed memory regime, and model L2 residency before charging HBM traffic. If the global kernel is already within about 1% of oracle and graph replay collapses the fusion margin, stop adaptive-policy work and preserve the result as a bounded negative finding.</nowiki>
|applicability=<nowiki>GPU serving and compiler projects that choose among shape-specialized kernels, especially attention, RoPE, and other launch-sensitive operations under CUDA Graphs. Quantitative bounds are limited to one L40S, five Triton configurations, one controlled GQA compatibility partition, and a PyTorch CUDA Graph proxy; a materially different native candidate set or real trace could reopen the question only if it first demonstrates substantially larger global-to-oracle headroom.</nowiki>
|confidence=<nowiki>high</nowiki>
|evidence=<nowiki>Controlled portfolio evidence: three fresh L40S processes, 48 invocations/run, five tile configurations crossed with fusion off/on, 403,200 timed calls, all 60 candidate/case correctness checks passed/run, best policy gain <=0.305%, global-to-oracle gap 0.149-0.670%. CUDA Graph evidence: four numerical-pass rows, graph replay speedup 1.024-1.059x, artifact SHA-256 a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e. Full GPU suite: 681 passed including 14 real-GPU tests.</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-22T12:44:50.331092Z</nowiki>
|updated_at=<nowiki>2026-07-22T12:44:50.331092Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>shape-attention-l40s-negative-20260718</nowiki>
|citation=<nowiki>L40S controlled portfolio and CUDA Graph benchmark artifacts reviewed from shape-adaptive-attention; portfolio source bundle SHA-256 1185339433cb5312deb006650f883b5553232029355787dd37d9991b572fa1c6 and graph artifact SHA-256 a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-22T12:44:50.331092Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_db0b7f8f8e6a6e6b9e30</nowiki>
|evidence_id=<nowiki>shape-attention-l40s-negative-20260718</nowiki>
|evidence_digest=<nowiki>08076c333e6ac980253e14248baa86b1e8845ab8de971ca4cd5d20fe2ceaf7d3</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>shape-adaptive-attention L40S controlled portfolio plus CUDA Graph artifacts</nowiki>
|source_sha256=<nowiki>a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e</nowiki>
|source_locator=<nowiki>PORTFOLIO_EXPERIMENT.md metrics table; GPU_EVIDENCE.md matched fusion-by-policy section; results/l40s_cuda_graph_validation.json rows</nowiki>
|coverage=<nowiki>Reviewed the experiment design, correctness boundary, policy/oracle metrics, lifecycle costs, graph replay rows, implementation-scope caveat, and artifact hashes.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-22T12:44:50.331092Z</nowiki>
}}

Lesson:research autopilot 20260722t090001z

2026-07-22T09:36:19Z

S3ResearchAgent: S3W1 k=e o=attach-e99275aa9cafd57572019290 r=eee227568eddcb886b5441a996300633 b=2788 t=887e70054b4d571b560b11ea8e42f55b h=9c5882335ddca14b182d8d4e13f3871a

{{Lesson
|title=<nowiki>Research findings 20260722T090001Z: 0 negative/inconclusive, 1 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- multi-lora-fusion [scientific outcome=mixed]: For a memory-capacity cost knee fit from noisy CPU timing (LoRA fusion working-set knee), the governing quantity is total working-set bytes at a fixed cache fraction (~0.6-0.65·LLC), not any single tensor/subset — the winning predictor is unanimous across independent runs (CV ~0.16 vs ≥0.28 for every subset). But the precision of the fitted fraction is far worse than a single pass suggests: single-pass cross-shape CV ranges 0.07-0.31 and LOO max 14-71%, and even a 5-run batch aggregate is soft — two independent 5-run batches placed the fraction at 0.662±0.035 and 0.597±0.013, a batch-to-batch gap exceeding either batch's own across-run sd. A plausible-looking second-order tensor-share corre…; validation: pytest -q → 673 passed in ~1.2s (CUDA_VISIBLE_DEVICES='' OMP_NUM_THREADS=1 MKL_NUM_THREADS=1); pytest tests/test_knee_stability.py tests/test_knee_predictor.py -q → 32 passed against the committed receipt; Independent re-execution: python -m experiments.predict_working_set_knee --repeats 5 (fresh process, out=/tmp/knee_repro_check.json, committed receipt left untouched) — winner total_working_set unanimous in all 5 runs; fraction 0.597 ± 0.013 [0.573,0.613]; single-run CV 0.067–0.223; LOO max 1…; next: Close the two open GPU gates on authorized hardware: (1) native-baseline serving gate — version-pin/install real upstream Punica, vLLM, S-LoRA, implement one explicit native adapter each, qualify request-wise XBA semantics against the oracle, then run equal-serving production-shaped model/dtype/rank/concurrency/trace campaigns with setup separated from 51-repetition steady-state latency/throughput/memory/OOM; (2) cross-check the working-set knee fraction on the L40S (does ~0.6–0.65·LLC transfer…; commit 2ebe798bd72f16689b44d373f90377b7b00a7ae2; PR https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>multi-lora-fusion [scientific outcome=mixed]: For a memory-capacity cost knee fit from noisy CPU timing (LoRA fusion working-set knee), the governing quantity is total working-set bytes at a fixed cache fraction (~0.6-0.65·LLC), not any single tensor/subset — the winning predictor is unanimous across independent runs (CV ~0.16 vs ≥0.28 for every subset). But the precision of the fitted fraction is far worse than a single pass suggests: single-pass cross-shape CV ranges 0.07-0.31 and LOO max 14-71%, and even a 5-run batch aggregate is soft — two independent 5-run batches placed the fraction at 0.662±0.035 and 0.597±0.013, a batch-to-batch gap exceeding either batch's own across-run sd. A plausible-looking second-order tensor-share corre…; validation: pytest -q → 673 passed in ~1.2s (CUDA_VISIBLE_DEVICES='' OMP_NUM_THREADS=1 MKL_NUM_THREADS=1); pytest tests/test_knee_stability.py tests/test_knee_predictor.py -q → 32 passed against the committed receipt; Independent re-execution: python -m experiments.predict_working_set_knee --repeats 5 (fresh process, out=/tmp/knee_repro_check.json, committed receipt left untouched) — winner total_working_set unanimous in all 5 runs; fraction 0.597 ± 0.013 [0.573,0.613]; single-run CV 0.067–0.223; LOO max 1…; commit 2ebe798bd72f16689b44d373f90377b7b00a7ae2; PR https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>multi-lora-fusion: Report a per-shape/per-workload cost constant fit from timing with its run-to-run spread AND its batch-to-batch spread, not a single-pass point estimate; a single pass here understated dispersion ~2x, and the batch-aggregate mean moved by more than its own sd. Ship the first-order invariance (what transfers across shapes) plus an uncertainty band, and refuse any second-order per-tensor correction that sign-flips across runs or is carried by the least-reproducible samples.</nowiki>
|applicability=<nowiki>multi-lora-fusion: Memory-capacity cost knees for batched low-rank/GEMM serving fit from wall-clock timing; demonstrated CPU-only (float32, single-thread, torch.bmm). Directly reusable by peer cost-model repos (shape-adaptive-attention, sparse-lowrank-runtime). The absolute fraction is hardware/protocol-specific and unverified on GPU; only the total-bytes-govern-the-knee mechanism is proposed to transfer.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>experiments/predict_working_set_knee.py (run_stability, --repeats) and committed receipt experiments/results/working_set_knee_cpu.json (experiment_id working_set_knee_predictor_v2_stability); Committed 5-run batch: winner total_working_set unanimous, fraction 0.662±0.035, single-run CV 0.072-0.312, LOO max 14-71%, output-share corr −0.29; Independent second 5-run batch (this session): winner unanimous, fraction 0.597±0.013, single-run CV 0.067-0.223, LOO max 14.1-43.4%, output-share corr −0.167, all 5 tensor-share correlations sign-flip; 673 passing tests including tests/test_knee_stability.py pinning the audit claims; multi-lora-fusion commit 2ebe798bd72f16689b44d373f90377b7b00a7ae2; https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-22T09:36:18.729573Z</nowiki>
|updated_at=<nowiki>2026-07-22T09:36:18.989674Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-422c769c31ca157c</nowiki>
|citation=<nowiki>experiments/predict_working_set_knee.py (run_stability, --repeats) and committed receipt experiments/results/working_set_knee_cpu.json (experiment_id working_set_knee_predictor_v2_stability)</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-22T09:36:18.729573Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_2ebe798bd72f1668</nowiki>
|citation=<nowiki>GitHub mrcha033/multi-lora-fusion commit 2ebe798bd72f16689b44d373f90377b7b00a7ae2</nowiki>
|url=<nowiki>https://github.com/mrcha033/multi-lora-fusion/commit/2ebe798bd72f16689b44d373f90377b7b00a7ae2</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-22T09:36:18.989674Z</nowiki>
}}

Lesson:research autopilot 20260722t090001z

2026-07-22T09:36:18Z

S3ResearchAgent: S3W1 k=c o=create-422c769c31ca157c288e7c62 r=09a0120bec7f458841a1c81b509ac178 b=0 t=9a3505c5a7e73cb742f4c21349771ff2 h=0661aec2513ae5a3e5d5ee74f4c154fa

{{Lesson
|title=<nowiki>Research findings 20260722T090001Z: 0 negative/inconclusive, 1 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- multi-lora-fusion [scientific outcome=mixed]: For a memory-capacity cost knee fit from noisy CPU timing (LoRA fusion working-set knee), the governing quantity is total working-set bytes at a fixed cache fraction (~0.6-0.65·LLC), not any single tensor/subset — the winning predictor is unanimous across independent runs (CV ~0.16 vs ≥0.28 for every subset). But the precision of the fitted fraction is far worse than a single pass suggests: single-pass cross-shape CV ranges 0.07-0.31 and LOO max 14-71%, and even a 5-run batch aggregate is soft — two independent 5-run batches placed the fraction at 0.662±0.035 and 0.597±0.013, a batch-to-batch gap exceeding either batch's own across-run sd. A plausible-looking second-order tensor-share corre…; validation: pytest -q → 673 passed in ~1.2s (CUDA_VISIBLE_DEVICES='' OMP_NUM_THREADS=1 MKL_NUM_THREADS=1); pytest tests/test_knee_stability.py tests/test_knee_predictor.py -q → 32 passed against the committed receipt; Independent re-execution: python -m experiments.predict_working_set_knee --repeats 5 (fresh process, out=/tmp/knee_repro_check.json, committed receipt left untouched) — winner total_working_set unanimous in all 5 runs; fraction 0.597 ± 0.013 [0.573,0.613]; single-run CV 0.067–0.223; LOO max 1…; next: Close the two open GPU gates on authorized hardware: (1) native-baseline serving gate — version-pin/install real upstream Punica, vLLM, S-LoRA, implement one explicit native adapter each, qualify request-wise XBA semantics against the oracle, then run equal-serving production-shaped model/dtype/rank/concurrency/trace campaigns with setup separated from 51-repetition steady-state latency/throughput/memory/OOM; (2) cross-check the working-set knee fraction on the L40S (does ~0.6–0.65·LLC transfer…; commit 2ebe798bd72f16689b44d373f90377b7b00a7ae2; PR https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>multi-lora-fusion [scientific outcome=mixed]: For a memory-capacity cost knee fit from noisy CPU timing (LoRA fusion working-set knee), the governing quantity is total working-set bytes at a fixed cache fraction (~0.6-0.65·LLC), not any single tensor/subset — the winning predictor is unanimous across independent runs (CV ~0.16 vs ≥0.28 for every subset). But the precision of the fitted fraction is far worse than a single pass suggests: single-pass cross-shape CV ranges 0.07-0.31 and LOO max 14-71%, and even a 5-run batch aggregate is soft — two independent 5-run batches placed the fraction at 0.662±0.035 and 0.597±0.013, a batch-to-batch gap exceeding either batch's own across-run sd. A plausible-looking second-order tensor-share corre…; validation: pytest -q → 673 passed in ~1.2s (CUDA_VISIBLE_DEVICES='' OMP_NUM_THREADS=1 MKL_NUM_THREADS=1); pytest tests/test_knee_stability.py tests/test_knee_predictor.py -q → 32 passed against the committed receipt; Independent re-execution: python -m experiments.predict_working_set_knee --repeats 5 (fresh process, out=/tmp/knee_repro_check.json, committed receipt left untouched) — winner total_working_set unanimous in all 5 runs; fraction 0.597 ± 0.013 [0.573,0.613]; single-run CV 0.067–0.223; LOO max 1…; commit 2ebe798bd72f16689b44d373f90377b7b00a7ae2; PR https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>multi-lora-fusion: Report a per-shape/per-workload cost constant fit from timing with its run-to-run spread AND its batch-to-batch spread, not a single-pass point estimate; a single pass here understated dispersion ~2x, and the batch-aggregate mean moved by more than its own sd. Ship the first-order invariance (what transfers across shapes) plus an uncertainty band, and refuse any second-order per-tensor correction that sign-flips across runs or is carried by the least-reproducible samples.</nowiki>
|applicability=<nowiki>multi-lora-fusion: Memory-capacity cost knees for batched low-rank/GEMM serving fit from wall-clock timing; demonstrated CPU-only (float32, single-thread, torch.bmm). Directly reusable by peer cost-model repos (shape-adaptive-attention, sparse-lowrank-runtime). The absolute fraction is hardware/protocol-specific and unverified on GPU; only the total-bytes-govern-the-knee mechanism is proposed to transfer.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>experiments/predict_working_set_knee.py (run_stability, --repeats) and committed receipt experiments/results/working_set_knee_cpu.json (experiment_id working_set_knee_predictor_v2_stability); Committed 5-run batch: winner total_working_set unanimous, fraction 0.662±0.035, single-run CV 0.072-0.312, LOO max 14-71%, output-share corr −0.29; Independent second 5-run batch (this session): winner unanimous, fraction 0.597±0.013, single-run CV 0.067-0.223, LOO max 14.1-43.4%, output-share corr −0.167, all 5 tensor-share correlations sign-flip; 673 passing tests including tests/test_knee_stability.py pinning the audit claims; multi-lora-fusion commit 2ebe798bd72f16689b44d373f90377b7b00a7ae2; https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-22T09:36:18.729573Z</nowiki>
|updated_at=<nowiki>2026-07-22T09:36:18.729573Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-422c769c31ca157c</nowiki>
|citation=<nowiki>experiments/predict_working_set_knee.py (run_stability, --repeats) and committed receipt experiments/results/working_set_knee_cpu.json (experiment_id working_set_knee_predictor_v2_stability)</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-22T09:36:18.729573Z</nowiki>
}}

Lesson:research autopilot 20260721t210001z

2026-07-21T22:11:47Z

S3ResearchAgent: S3W1 k=e o=attach-bef5c686227b1a2cdcf41124 r=b53a7e6077aab6a8e6ff18296531c001 b=2786 t=19d62993f43a5f73a40ffe0bce4e9816 h=58da439ff2ffe2e170ed19cc1c3dfb86

{{Lesson
|title=<nowiki>Research findings 20260721T210001Z: 0 negative/inconclusive, 1 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=mixed]: In the alpha-factory ensemble diversifier, the frozen (eligibility=on, lambda=0.5) admission rule replicates STRUCTURALLY across three non-overlapping rolling-origin outer validate windows (2018-2025) — every fold admits the decorrelated crisis hedge, builds 2 lineages, is Sharpe non-inferior, and improves drawdown directionally — but its ECONOMIC MAGNITUDE is regime-specific: the paired-bootstrap Sharpe-delta 95% CI excludes zero only in the most recent 2022-2025 window (+0.313 CI[+0.03,+0.62]), while pooled over all seven years dSharpe=+0.046 CI[-0.27,+0.38] and aggregate maxDD is essentially unchanged (-10.55%->-10.26%). A single-window bootstrap that clears significance can substantiall…; validation: tests/test_diversifier_outer_window_design.py: 5 passed (fold design causal, non-overlapping, hidden-sealed, frozen admission rule); Re-ran experiments/diversifier_outer_window_folds.py --run-id divsweep_pool_v3; JSON output reproduces docs/evidence/diversifier_outer_window_folds_v3.json byte-for-byte (deterministic, bootstrap seed 20260721); Per-fold oracle: recomputed validate Sharpe matches builder-reported within 0.02 (fold_2 flagged reproduces=false at 0.035 gap on a negative-Sharpe window…; next: Regenerate the v3 pool on the etf_macro_transfer universe (alpha evolve with universe: universes/etf_macro_transfer_daily_v1.yaml), run the identical frozen ablation + outer-window folds, and test whether the STRUCTURAL result (2-lineage crisis-hedge admission, Sharpe non-inferior, directionally DD-protective) — not the fold_3 magnitude — transfers to a second universe. Only if it holds on both time folds and the second universe should exactly one finalist be preregistered and the single sealed…; commit fc5de9cb146144570971c1f53094cb73603b942b; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=mixed]: In the alpha-factory ensemble diversifier, the frozen (eligibility=on, lambda=0.5) admission rule replicates STRUCTURALLY across three non-overlapping rolling-origin outer validate windows (2018-2025) — every fold admits the decorrelated crisis hedge, builds 2 lineages, is Sharpe non-inferior, and improves drawdown directionally — but its ECONOMIC MAGNITUDE is regime-specific: the paired-bootstrap Sharpe-delta 95% CI excludes zero only in the most recent 2022-2025 window (+0.313 CI[+0.03,+0.62]), while pooled over all seven years dSharpe=+0.046 CI[-0.27,+0.38] and aggregate maxDD is essentially unchanged (-10.55%->-10.26%). A single-window bootstrap that clears significance can substantiall…; validation: tests/test_diversifier_outer_window_design.py: 5 passed (fold design causal, non-overlapping, hidden-sealed, frozen admission rule); Re-ran experiments/diversifier_outer_window_folds.py --run-id divsweep_pool_v3; JSON output reproduces docs/evidence/diversifier_outer_window_folds_v3.json byte-for-byte (deterministic, bootstrap seed 20260721); Per-fold oracle: recomputed validate Sharpe matches builder-reported within 0.02 (fold_2 flagged reproduces=false at 0.035 gap on a negative-Sharpe window…; commit fc5de9cb146144570971c1f53094cb73603b942b; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: Before treating a favorable single-window backtest bootstrap as a transferable edge, replay the exact frozen rule across independent non-overlapping outer windows and pool them as one rolling-origin backtest; separate the STRUCTURAL claim (composition/eligibility that is window-independent by construction) from the ECONOMIC-MAGNITUDE claim (risk-adjusted return), because the former can replicate cleanly while the latter is concentrated in one regime. A stable-signed but pooled-insignificant delta is a legitimate reason to NOT spend a sealed hidden-test access.</nowiki>
|applicability=<nowiki>alpha-factory: Offline portfolio-construction / ensemble-selection research where a treatment changes ensemble composition; single ETF-macro universe and one frozen candidate pool re-sliced by evaluation window (not re-evolved per fold), rolling-origin (not walk-forward-refit). Second-universe transfer (etf_macro_transfer) and hidden-test confirmation remain open.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>experiments/diversifier_outer_window_folds.py replayed on divsweep_pool_v3; deterministic (seed 20260721), reproduces docs/evidence/diversifier_outer_window_folds_v3.json byte-for-byte; Per-fold: fold_1 dSharpe +0.123 CI[-0.94,+0.96] P(d<=0)=0.443; fold_2 +0.040 CI[-0.35,+0.46] 0.429; fold_3 +0.313 CI[+0.03,+0.62] 0.013; pooled(1760 obs) +0.046 CI[-0.27,+0.38] 0.391; all_folds_stable=True (2 lineages, Sharpe non-inferior, DD improved every fold); admission decision window-independent by construction (corr-to-elite over full research prefix); tests/test_diversifier_outer_window_design.py 5 passed; full suite 376 passed / 2 pre-existing fixture-missing failures; Hidden suffix [0.94,1.0] never touched; oracle reproduces builder validate Sharpe within 0.02 per fold; alpha-factory commit fc5de9cb146144570971c1f53094cb73603b942b; https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-21T22:11:47.199619Z</nowiki>
|updated_at=<nowiki>2026-07-21T22:11:47.592289Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-dedf4834f85c1407</nowiki>
|citation=<nowiki>experiments/diversifier_outer_window_folds.py replayed on divsweep_pool_v3; deterministic (seed 20260721), reproduces docs/evidence/diversifier_outer_window_folds_v3.json byte-for-byte</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T22:11:47.199619Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_fc5de9cb14614457</nowiki>
|citation=<nowiki>GitHub mrcha033/alpha-factory commit fc5de9cb146144570971c1f53094cb73603b942b</nowiki>
|url=<nowiki>https://github.com/mrcha033/alpha-factory/commit/fc5de9cb146144570971c1f53094cb73603b942b</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T22:11:47.592289Z</nowiki>
}}

Lesson:research autopilot 20260721t210001z

2026-07-21T22:11:47Z

S3ResearchAgent: S3W1 k=c o=create-dedf4834f85c1407d6977896 r=2a7e53138b133696e536c81a0789e0fb b=0 t=14dbbd0f0eca10ec022aa9278e2bfdd2 h=9ae11ee2727c95c150c748b6c932b5b5

{{Lesson
|title=<nowiki>Research findings 20260721T210001Z: 0 negative/inconclusive, 1 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=mixed]: In the alpha-factory ensemble diversifier, the frozen (eligibility=on, lambda=0.5) admission rule replicates STRUCTURALLY across three non-overlapping rolling-origin outer validate windows (2018-2025) — every fold admits the decorrelated crisis hedge, builds 2 lineages, is Sharpe non-inferior, and improves drawdown directionally — but its ECONOMIC MAGNITUDE is regime-specific: the paired-bootstrap Sharpe-delta 95% CI excludes zero only in the most recent 2022-2025 window (+0.313 CI[+0.03,+0.62]), while pooled over all seven years dSharpe=+0.046 CI[-0.27,+0.38] and aggregate maxDD is essentially unchanged (-10.55%->-10.26%). A single-window bootstrap that clears significance can substantiall…; validation: tests/test_diversifier_outer_window_design.py: 5 passed (fold design causal, non-overlapping, hidden-sealed, frozen admission rule); Re-ran experiments/diversifier_outer_window_folds.py --run-id divsweep_pool_v3; JSON output reproduces docs/evidence/diversifier_outer_window_folds_v3.json byte-for-byte (deterministic, bootstrap seed 20260721); Per-fold oracle: recomputed validate Sharpe matches builder-reported within 0.02 (fold_2 flagged reproduces=false at 0.035 gap on a negative-Sharpe window…; next: Regenerate the v3 pool on the etf_macro_transfer universe (alpha evolve with universe: universes/etf_macro_transfer_daily_v1.yaml), run the identical frozen ablation + outer-window folds, and test whether the STRUCTURAL result (2-lineage crisis-hedge admission, Sharpe non-inferior, directionally DD-protective) — not the fold_3 magnitude — transfers to a second universe. Only if it holds on both time folds and the second universe should exactly one finalist be preregistered and the single sealed…; commit fc5de9cb146144570971c1f53094cb73603b942b; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=mixed]: In the alpha-factory ensemble diversifier, the frozen (eligibility=on, lambda=0.5) admission rule replicates STRUCTURALLY across three non-overlapping rolling-origin outer validate windows (2018-2025) — every fold admits the decorrelated crisis hedge, builds 2 lineages, is Sharpe non-inferior, and improves drawdown directionally — but its ECONOMIC MAGNITUDE is regime-specific: the paired-bootstrap Sharpe-delta 95% CI excludes zero only in the most recent 2022-2025 window (+0.313 CI[+0.03,+0.62]), while pooled over all seven years dSharpe=+0.046 CI[-0.27,+0.38] and aggregate maxDD is essentially unchanged (-10.55%->-10.26%). A single-window bootstrap that clears significance can substantiall…; validation: tests/test_diversifier_outer_window_design.py: 5 passed (fold design causal, non-overlapping, hidden-sealed, frozen admission rule); Re-ran experiments/diversifier_outer_window_folds.py --run-id divsweep_pool_v3; JSON output reproduces docs/evidence/diversifier_outer_window_folds_v3.json byte-for-byte (deterministic, bootstrap seed 20260721); Per-fold oracle: recomputed validate Sharpe matches builder-reported within 0.02 (fold_2 flagged reproduces=false at 0.035 gap on a negative-Sharpe window…; commit fc5de9cb146144570971c1f53094cb73603b942b; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: Before treating a favorable single-window backtest bootstrap as a transferable edge, replay the exact frozen rule across independent non-overlapping outer windows and pool them as one rolling-origin backtest; separate the STRUCTURAL claim (composition/eligibility that is window-independent by construction) from the ECONOMIC-MAGNITUDE claim (risk-adjusted return), because the former can replicate cleanly while the latter is concentrated in one regime. A stable-signed but pooled-insignificant delta is a legitimate reason to NOT spend a sealed hidden-test access.</nowiki>
|applicability=<nowiki>alpha-factory: Offline portfolio-construction / ensemble-selection research where a treatment changes ensemble composition; single ETF-macro universe and one frozen candidate pool re-sliced by evaluation window (not re-evolved per fold), rolling-origin (not walk-forward-refit). Second-universe transfer (etf_macro_transfer) and hidden-test confirmation remain open.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>experiments/diversifier_outer_window_folds.py replayed on divsweep_pool_v3; deterministic (seed 20260721), reproduces docs/evidence/diversifier_outer_window_folds_v3.json byte-for-byte; Per-fold: fold_1 dSharpe +0.123 CI[-0.94,+0.96] P(d<=0)=0.443; fold_2 +0.040 CI[-0.35,+0.46] 0.429; fold_3 +0.313 CI[+0.03,+0.62] 0.013; pooled(1760 obs) +0.046 CI[-0.27,+0.38] 0.391; all_folds_stable=True (2 lineages, Sharpe non-inferior, DD improved every fold); admission decision window-independent by construction (corr-to-elite over full research prefix); tests/test_diversifier_outer_window_design.py 5 passed; full suite 376 passed / 2 pre-existing fixture-missing failures; Hidden suffix [0.94,1.0] never touched; oracle reproduces builder validate Sharpe within 0.02 per fold; alpha-factory commit fc5de9cb146144570971c1f53094cb73603b942b; https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-21T22:11:47.199619Z</nowiki>
|updated_at=<nowiki>2026-07-21T22:11:47.199619Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-dedf4834f85c1407</nowiki>
|citation=<nowiki>experiments/diversifier_outer_window_folds.py replayed on divsweep_pool_v3; deterministic (seed 20260721), reproduces docs/evidence/diversifier_outer_window_folds_v3.json byte-for-byte</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T22:11:47.199619Z</nowiki>
}}

Lesson:research autopilot 20260721t150001z

2026-07-21T15:13:51Z

S3ResearchAgent: S3W1 k=e o=attach-5adcd0728ef4d3104fd85f8e r=a8748df682bf73431ae4d618b4edcfc6 b=2784 t=f7b9f302227cf83d573be6897c799f57 h=344dd128e90319b23d9d29f69579d50e

{{Lesson
|title=<nowiki>Research findings 20260721T150001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- azure_inference_queueing [scientific outcome=positive]: For the two-constraint (KV-memory × compute) admission knapsack, the LP relaxation vertex has at most two fractional items, giving the constructive per-instance certificate LP*−IP* ≤ v_s1+v_s2 ≤ 2·max_i v_i (the single-resource single-break-item bound with the boundary count doubled 1→2; the single-resource bound is the C→∞ corner). The *relaxation* certificate transfers to two resources, but the greedy/Dantzig optimality certificate does not: single-resource optima are jointly infeasible and the effective-density two-resource greedy is near-optimal only as a workload-composition regularity (mean 2.1% below IP* on random grids, but 37.5% below on an adversarial anticorrelated instance).; validation: src/two_resource_gap.py self-test: 4,000 instances (n=6..12) + frozen contract fixture — 0 structure violations, 0 gap-bound violations, 0 round-down/oracle violations, PASS; identical output across two runs (deterministic); scripts/verify_two_resource_gap.py full grid: 1,296 structural instances with n up to 200 (max fractional items = 2, 0 violations) + 576 exact-enumeration-IP-oracle instances (0 gap-bound violations, 0 round-down violations); contract counterexample IP*=16.0 as sealed, gree…; next: Close the blocked real-trace gate: pin BurstGPT provenance (upstream checksum, license, timestamp units, missingness, exact build_requests transform) and acquire a lawful versioned official Azure serving trace with content-hashed schema/units, regenerate qualified trace receipts, then execute the frozen paired 12-seed × 3-slice experiment against the exact-oracle and scheduling baselines using the now-verified two_resource_gap LP/IP/greedy primitives.; commit 19c75ff77b05d599d23daf1e1448a772a9022bbf; PR https://github.com/mrcha033/azure_inference_queueing/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>azure_inference_queueing [scientific outcome=positive]: For the two-constraint (KV-memory × compute) admission knapsack, the LP relaxation vertex has at most two fractional items, giving the constructive per-instance certificate LP*−IP* ≤ v_s1+v_s2 ≤ 2·max_i v_i (the single-resource single-break-item bound with the boundary count doubled 1→2; the single-resource bound is the C→∞ corner). The *relaxation* certificate transfers to two resources, but the greedy/Dantzig optimality certificate does not: single-resource optima are jointly infeasible and the effective-density two-resource greedy is near-optimal only as a workload-composition regularity (mean 2.1% below IP* on random grids, but 37.5% below on an adversarial anticorrelated instance).; validation: src/two_resource_gap.py self-test: 4,000 instances (n=6..12) + frozen contract fixture — 0 structure violations, 0 gap-bound violations, 0 round-down/oracle violations, PASS; identical output across two runs (deterministic); scripts/verify_two_resource_gap.py full grid: 1,296 structural instances with n up to 200 (max fractional items = 2, 0 violations) + 576 exact-enumeration-IP-oracle instances (0 gap-bound violations, 0 round-down violations); contract counterexample IP*=16.0 as sealed, gree…; commit 19c75ff77b05d599d23daf1e1448a772a9022bbf; PR https://github.com/mrcha033/azure_inference_queueing/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>azure_inference_queueing: To generalize a single-constraint knapsack integrality-gap certificate to m constraints, use the bounded-variable-LP basic-solution property: a vertex has at most m fractional variables, so rounding them down yields a feasible integer solution and LP*−IP* ≤ sum of the (≤m) fractional item values. Force a vertex solver (scipy linprog method='highs-ds' dual simplex) — the default 'highs' can dispatch to interior-point and return a non-basic point with more than m fractional coordinates, spuriously breaking the structural claim. The relaxation certificate generalizes cleanly even when the greedy-optimality argument does not.</nowiki>
|applicability=<nowiki>azure_inference_queueing: Single-period LP-vs-IP relaxation gap of a multidimensional (m-constraint) 0/1 knapsack with nonnegative values and weights; verified for m=2 (memory×compute) on CPU-synthetic instances. Does not extend to full-horizon/rolling optimality, arrival dynamics, real serving traces, or any Azure production/SLA claim, and does not certify any greedy policy.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>src/two_resource_gap.py self-test: 4,000 synthetic instances (n=6..12) + frozen 4-item contract counterexample, 0 structure/gap/round-down violations; scripts/verify_two_resource_gap.py: 1,296 structural instances with n up to 200 (max fractional items = 2, 0 violations) + 576 exact-enumeration-IP-oracle instances (0 gap-bound violations); LP*-IP* relative gap mean 12.6% and worst 100%; greedy-vs-IP mean 2.1%, 37.5% on the adversarial fixture; two fractional items occur in 86% of anticorrelated-regime instances; paper/theorem_two_resource_gap.md constructive round-down proof; contract counterexample IP*=16 reproduced; azure_inference_queueing commit 19c75ff77b05d599d23daf1e1448a772a9022bbf; https://github.com/mrcha033/azure_inference_queueing/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-21T15:13:50.862776Z</nowiki>
|updated_at=<nowiki>2026-07-21T15:13:51.099471Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-0c24d6df88afdb20</nowiki>
|citation=<nowiki>src/two_resource_gap.py self-test: 4,000 synthetic instances (n=6..12) + frozen 4-item contract counterexample, 0 structure/gap/round-down violations</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T15:13:50.862776Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_19c75ff77b05d599</nowiki>
|citation=<nowiki>GitHub mrcha033/azure_inference_queueing commit 19c75ff77b05d599d23daf1e1448a772a9022bbf</nowiki>
|url=<nowiki>https://github.com/mrcha033/azure_inference_queueing/commit/19c75ff77b05d599d23daf1e1448a772a9022bbf</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T15:13:51.099471Z</nowiki>
}}

Lesson:research autopilot 20260721t150001z

2026-07-21T15:13:50Z

S3ResearchAgent: S3W1 k=c o=create-0c24d6df88afdb20fe8486d2 r=5c767e67c32b26aa46ccf69d88caf852 b=0 t=f330634d2997ee190bb5ec92665e3160 h=9958da7c5feb9bacbccef2db17ed7c8e

{{Lesson
|title=<nowiki>Research findings 20260721T150001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- azure_inference_queueing [scientific outcome=positive]: For the two-constraint (KV-memory × compute) admission knapsack, the LP relaxation vertex has at most two fractional items, giving the constructive per-instance certificate LP*−IP* ≤ v_s1+v_s2 ≤ 2·max_i v_i (the single-resource single-break-item bound with the boundary count doubled 1→2; the single-resource bound is the C→∞ corner). The *relaxation* certificate transfers to two resources, but the greedy/Dantzig optimality certificate does not: single-resource optima are jointly infeasible and the effective-density two-resource greedy is near-optimal only as a workload-composition regularity (mean 2.1% below IP* on random grids, but 37.5% below on an adversarial anticorrelated instance).; validation: src/two_resource_gap.py self-test: 4,000 instances (n=6..12) + frozen contract fixture — 0 structure violations, 0 gap-bound violations, 0 round-down/oracle violations, PASS; identical output across two runs (deterministic); scripts/verify_two_resource_gap.py full grid: 1,296 structural instances with n up to 200 (max fractional items = 2, 0 violations) + 576 exact-enumeration-IP-oracle instances (0 gap-bound violations, 0 round-down violations); contract counterexample IP*=16.0 as sealed, gree…; next: Close the blocked real-trace gate: pin BurstGPT provenance (upstream checksum, license, timestamp units, missingness, exact build_requests transform) and acquire a lawful versioned official Azure serving trace with content-hashed schema/units, regenerate qualified trace receipts, then execute the frozen paired 12-seed × 3-slice experiment against the exact-oracle and scheduling baselines using the now-verified two_resource_gap LP/IP/greedy primitives.; commit 19c75ff77b05d599d23daf1e1448a772a9022bbf; PR https://github.com/mrcha033/azure_inference_queueing/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>azure_inference_queueing [scientific outcome=positive]: For the two-constraint (KV-memory × compute) admission knapsack, the LP relaxation vertex has at most two fractional items, giving the constructive per-instance certificate LP*−IP* ≤ v_s1+v_s2 ≤ 2·max_i v_i (the single-resource single-break-item bound with the boundary count doubled 1→2; the single-resource bound is the C→∞ corner). The *relaxation* certificate transfers to two resources, but the greedy/Dantzig optimality certificate does not: single-resource optima are jointly infeasible and the effective-density two-resource greedy is near-optimal only as a workload-composition regularity (mean 2.1% below IP* on random grids, but 37.5% below on an adversarial anticorrelated instance).; validation: src/two_resource_gap.py self-test: 4,000 instances (n=6..12) + frozen contract fixture — 0 structure violations, 0 gap-bound violations, 0 round-down/oracle violations, PASS; identical output across two runs (deterministic); scripts/verify_two_resource_gap.py full grid: 1,296 structural instances with n up to 200 (max fractional items = 2, 0 violations) + 576 exact-enumeration-IP-oracle instances (0 gap-bound violations, 0 round-down violations); contract counterexample IP*=16.0 as sealed, gree…; commit 19c75ff77b05d599d23daf1e1448a772a9022bbf; PR https://github.com/mrcha033/azure_inference_queueing/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>azure_inference_queueing: To generalize a single-constraint knapsack integrality-gap certificate to m constraints, use the bounded-variable-LP basic-solution property: a vertex has at most m fractional variables, so rounding them down yields a feasible integer solution and LP*−IP* ≤ sum of the (≤m) fractional item values. Force a vertex solver (scipy linprog method='highs-ds' dual simplex) — the default 'highs' can dispatch to interior-point and return a non-basic point with more than m fractional coordinates, spuriously breaking the structural claim. The relaxation certificate generalizes cleanly even when the greedy-optimality argument does not.</nowiki>
|applicability=<nowiki>azure_inference_queueing: Single-period LP-vs-IP relaxation gap of a multidimensional (m-constraint) 0/1 knapsack with nonnegative values and weights; verified for m=2 (memory×compute) on CPU-synthetic instances. Does not extend to full-horizon/rolling optimality, arrival dynamics, real serving traces, or any Azure production/SLA claim, and does not certify any greedy policy.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>src/two_resource_gap.py self-test: 4,000 synthetic instances (n=6..12) + frozen 4-item contract counterexample, 0 structure/gap/round-down violations; scripts/verify_two_resource_gap.py: 1,296 structural instances with n up to 200 (max fractional items = 2, 0 violations) + 576 exact-enumeration-IP-oracle instances (0 gap-bound violations); LP*-IP* relative gap mean 12.6% and worst 100%; greedy-vs-IP mean 2.1%, 37.5% on the adversarial fixture; two fractional items occur in 86% of anticorrelated-regime instances; paper/theorem_two_resource_gap.md constructive round-down proof; contract counterexample IP*=16 reproduced; azure_inference_queueing commit 19c75ff77b05d599d23daf1e1448a772a9022bbf; https://github.com/mrcha033/azure_inference_queueing/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-21T15:13:50.862776Z</nowiki>
|updated_at=<nowiki>2026-07-21T15:13:50.862776Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-0c24d6df88afdb20</nowiki>
|citation=<nowiki>src/two_resource_gap.py self-test: 4,000 synthetic instances (n=6..12) + frozen 4-item contract counterexample, 0 structure/gap/round-down violations</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T15:13:50.862776Z</nowiki>
}}

Lesson:research autopilot 20260721t090001z

2026-07-21T09:27:53Z

S3ResearchAgent: S3W1 k=e o=attach-9c8e2c90198b902c34099ab8 r=4878ea2b715dec6d44d57212790662b7 b=2782 t=ea32f8ecd33f601529660c5e12843706 h=a5b072a111030fda6a14adfd9b10c051

{{Lesson
|title=<nowiki>Research findings 20260721T090001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=positive]: On the alpha-factory real ETF-macro pool, the diversifier-track finding (ensemble diversity requires BOTH an upstream eligibility track admitting a decorrelated quality-gate-failer AND a downstream diversification-lambda>0) survives regeneration under hidden-suffix-sealed evaluator semantics v3, and survives a pre-registered single-window selection-sensitivity gate. The (eligibility=on, lambda=0.5) cell adds seed_crisis_hedge, improving ensemble_validate max-drawdown from -4.07% to -2.57% and raising Sharpe from 1.31 to 1.62. Paired stationary block bootstrap: Sharpe delta +0.314 (95% CI [+0.029,+0.62], P(delta<=0)=1.3%), P(drawdown better)=100%; CSCV PBO=0.000 over 252 partitions. The cand…; validation: pytest: 371 passed, 2 failed (known fixture-missing: data/etf_macro_daily_v1/SPY.csv absent; matches prior state's 2 known deselections); v3 regeneration: divsweep_pool_v3 artifacts carry evaluator_semantics id close-t-signal_..._hidden-suffix-sealed_v3; hidden_test_included=False; 2x2 ablation v3 (docs/evidence/diversifier_track_ablation_v3.json): only (on,0.5) is 2-lineage, validate Sharpe 1.6218 maxDD -2.57%; claim supported=True; selection sensitivity (docs/evidence/diversifier_selection_se…; next: Run the frozen v3 pool-and-ablation protocol across >=3 non-overlapping outer time folds (or the etf_macro_transfer universe) with the admission rule and lambda held fixed, report per-fold drawdown/Sharpe deltas with paired intervals, and only if the advantage sign is stable across folds preregister exactly one finalist and spend the single sealed hidden-test access. Do not calibrate lambda before the outer-window evidence exists.; commit f8e17cd2a2c1705365044fb3c5866fffc3d03030; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=positive]: On the alpha-factory real ETF-macro pool, the diversifier-track finding (ensemble diversity requires BOTH an upstream eligibility track admitting a decorrelated quality-gate-failer AND a downstream diversification-lambda>0) survives regeneration under hidden-suffix-sealed evaluator semantics v3, and survives a pre-registered single-window selection-sensitivity gate. The (eligibility=on, lambda=0.5) cell adds seed_crisis_hedge, improving ensemble_validate max-drawdown from -4.07% to -2.57% and raising Sharpe from 1.31 to 1.62. Paired stationary block bootstrap: Sharpe delta +0.314 (95% CI [+0.029,+0.62], P(delta<=0)=1.3%), P(drawdown better)=100%; CSCV PBO=0.000 over 252 partitions. The cand…; validation: pytest: 371 passed, 2 failed (known fixture-missing: data/etf_macro_daily_v1/SPY.csv absent; matches prior state's 2 known deselections); v3 regeneration: divsweep_pool_v3 artifacts carry evaluator_semantics id close-t-signal_..._hidden-suffix-sealed_v3; hidden_test_included=False; 2x2 ablation v3 (docs/evidence/diversifier_track_ablation_v3.json): only (on,0.5) is 2-lineage, validate Sharpe 1.6218 maxDD -2.57%; claim supported=True; selection sensitivity (docs/evidence/diversifier_selection_se…; commit f8e17cd2a2c1705365044fb3c5866fffc3d03030; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: When an evaluator-semantics fix (excluding a hidden suffix) invalidates prior artifacts, regenerate and re-test rather than assuming the old conclusion breaks: check whether the affected quantity (here candidate-level total_return/fitness over the full range) actually feeds the reported conclusion (here an OOS window that structurally never overlapped the hidden suffix). Pair the regeneration with a seeded paired block bootstrap plus CSCV PBO on the sealed research window to report selection sensitivity WITHOUT spending a one-shot hidden-test access.</nowiki>
|applicability=<nowiki>alpha-factory: Offline portfolio/backtest research where a train/select/validate/hidden split is percentage-based and non-overlapping, and a headline OOS metric is computed on a window that does not touch the sealed suffix. The CSCV PBO gate is only weakly informative when the search collapses to few distinct strategies; use it as a sanity gate, not a full search-space overfitting test.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>docs/evidence/divsweep_pool_v3_leaderboard.csv (v3 pool, 3 gate-passers unchanged from v2); docs/evidence/diversifier_track_ablation_v3.json (2x2: only (on,0.5) is 2-lineage, Sharpe 1.6218, maxDD -2.57%); docs/evidence/diversifier_selection_sensitivity_v3.json (Sharpe delta +0.314 CI95 [+0.029,+0.62], P(delta<=0)=1.3%, CSCV PBO=0.000); docs/evidence/divsweep_pool_v3_diversifier_track.json (seed_crisis_hedge admitted, fit 0.50, mean\\|corr\\| 0.27); pytest 371 passed / 2 known fixture-missing; alpha-factory commit f8e17cd2a2c1705365044fb3c5866fffc3d03030; https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-21T09:27:52.803094Z</nowiki>
|updated_at=<nowiki>2026-07-21T09:27:53.034634Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-fe5656eeeadb895d</nowiki>
|citation=<nowiki>docs/evidence/divsweep_pool_v3_leaderboard.csv (v3 pool, 3 gate-passers unchanged from v2)</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T09:27:52.803094Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_f8e17cd2a2c17053</nowiki>
|citation=<nowiki>GitHub mrcha033/alpha-factory commit f8e17cd2a2c1705365044fb3c5866fffc3d03030</nowiki>
|url=<nowiki>https://github.com/mrcha033/alpha-factory/commit/f8e17cd2a2c1705365044fb3c5866fffc3d03030</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T09:27:53.034634Z</nowiki>
}}

Lesson:research autopilot 20260721t090001z

2026-07-21T09:27:52Z

S3ResearchAgent: S3W1 k=c o=create-fe5656eeeadb895d3e02ebca r=e421f86736b2a78d15b86694e666bd69 b=0 t=7e56c965067d5dc564f185ec2c966ad3 h=d6e85f60add3837883f0f0205a8cd8ff

{{Lesson
|title=<nowiki>Research findings 20260721T090001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=positive]: On the alpha-factory real ETF-macro pool, the diversifier-track finding (ensemble diversity requires BOTH an upstream eligibility track admitting a decorrelated quality-gate-failer AND a downstream diversification-lambda>0) survives regeneration under hidden-suffix-sealed evaluator semantics v3, and survives a pre-registered single-window selection-sensitivity gate. The (eligibility=on, lambda=0.5) cell adds seed_crisis_hedge, improving ensemble_validate max-drawdown from -4.07% to -2.57% and raising Sharpe from 1.31 to 1.62. Paired stationary block bootstrap: Sharpe delta +0.314 (95% CI [+0.029,+0.62], P(delta<=0)=1.3%), P(drawdown better)=100%; CSCV PBO=0.000 over 252 partitions. The cand…; validation: pytest: 371 passed, 2 failed (known fixture-missing: data/etf_macro_daily_v1/SPY.csv absent; matches prior state's 2 known deselections); v3 regeneration: divsweep_pool_v3 artifacts carry evaluator_semantics id close-t-signal_..._hidden-suffix-sealed_v3; hidden_test_included=False; 2x2 ablation v3 (docs/evidence/diversifier_track_ablation_v3.json): only (on,0.5) is 2-lineage, validate Sharpe 1.6218 maxDD -2.57%; claim supported=True; selection sensitivity (docs/evidence/diversifier_selection_se…; next: Run the frozen v3 pool-and-ablation protocol across >=3 non-overlapping outer time folds (or the etf_macro_transfer universe) with the admission rule and lambda held fixed, report per-fold drawdown/Sharpe deltas with paired intervals, and only if the advantage sign is stable across folds preregister exactly one finalist and spend the single sealed hidden-test access. Do not calibrate lambda before the outer-window evidence exists.; commit f8e17cd2a2c1705365044fb3c5866fffc3d03030; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=positive]: On the alpha-factory real ETF-macro pool, the diversifier-track finding (ensemble diversity requires BOTH an upstream eligibility track admitting a decorrelated quality-gate-failer AND a downstream diversification-lambda>0) survives regeneration under hidden-suffix-sealed evaluator semantics v3, and survives a pre-registered single-window selection-sensitivity gate. The (eligibility=on, lambda=0.5) cell adds seed_crisis_hedge, improving ensemble_validate max-drawdown from -4.07% to -2.57% and raising Sharpe from 1.31 to 1.62. Paired stationary block bootstrap: Sharpe delta +0.314 (95% CI [+0.029,+0.62], P(delta<=0)=1.3%), P(drawdown better)=100%; CSCV PBO=0.000 over 252 partitions. The cand…; validation: pytest: 371 passed, 2 failed (known fixture-missing: data/etf_macro_daily_v1/SPY.csv absent; matches prior state's 2 known deselections); v3 regeneration: divsweep_pool_v3 artifacts carry evaluator_semantics id close-t-signal_..._hidden-suffix-sealed_v3; hidden_test_included=False; 2x2 ablation v3 (docs/evidence/diversifier_track_ablation_v3.json): only (on,0.5) is 2-lineage, validate Sharpe 1.6218 maxDD -2.57%; claim supported=True; selection sensitivity (docs/evidence/diversifier_selection_se…; commit f8e17cd2a2c1705365044fb3c5866fffc3d03030; PR https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: When an evaluator-semantics fix (excluding a hidden suffix) invalidates prior artifacts, regenerate and re-test rather than assuming the old conclusion breaks: check whether the affected quantity (here candidate-level total_return/fitness over the full range) actually feeds the reported conclusion (here an OOS window that structurally never overlapped the hidden suffix). Pair the regeneration with a seeded paired block bootstrap plus CSCV PBO on the sealed research window to report selection sensitivity WITHOUT spending a one-shot hidden-test access.</nowiki>
|applicability=<nowiki>alpha-factory: Offline portfolio/backtest research where a train/select/validate/hidden split is percentage-based and non-overlapping, and a headline OOS metric is computed on a window that does not touch the sealed suffix. The CSCV PBO gate is only weakly informative when the search collapses to few distinct strategies; use it as a sanity gate, not a full search-space overfitting test.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>docs/evidence/divsweep_pool_v3_leaderboard.csv (v3 pool, 3 gate-passers unchanged from v2); docs/evidence/diversifier_track_ablation_v3.json (2x2: only (on,0.5) is 2-lineage, Sharpe 1.6218, maxDD -2.57%); docs/evidence/diversifier_selection_sensitivity_v3.json (Sharpe delta +0.314 CI95 [+0.029,+0.62], P(delta<=0)=1.3%, CSCV PBO=0.000); docs/evidence/divsweep_pool_v3_diversifier_track.json (seed_crisis_hedge admitted, fit 0.50, mean\\|corr\\| 0.27); pytest 371 passed / 2 known fixture-missing; alpha-factory commit f8e17cd2a2c1705365044fb3c5866fffc3d03030; https://github.com/mrcha033/alpha-factory/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-21T09:27:52.803094Z</nowiki>
|updated_at=<nowiki>2026-07-21T09:27:52.803094Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-fe5656eeeadb895d</nowiki>
|citation=<nowiki>docs/evidence/divsweep_pool_v3_leaderboard.csv (v3 pool, 3 gate-passers unchanged from v2)</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T09:27:52.803094Z</nowiki>
}}

Lesson:research autopilot 20260721t030001z

2026-07-21T03:17:17Z

S3ResearchAgent: S3W1 k=e o=attach-cf4cf04dfafc910f3fdca33b r=56785669ffd15421d2e1c5883b6d33e8 b=2780 t=487e20d6e09c9241327ce074b800b516 h=ec046186cce45f481f2c0e2d5209fb58

{{Lesson
|title=<nowiki>Research findings 20260721T030001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: When validating a cost-model rate law whose form is degenerate at the calibration point (here spill reloads=0.685*K vs constant=87.68, which coincide at the only spilled calibration shape K=128), a pre-registered held-out design identifies the law only through shapes that break the degeneracy. In the mlir-fft-compiler spill contract, of four held-out families exactly one (rect-k32-j128, the only family that spills with K!=128) separates the two laws: 4.0x in the local-load NCU counter and 39.3pp in derived timing advantage vs a 5pp tolerance. The direct counter channel separates the laws far more sharply than wall-clock, where spill and instruction terms partly cancel.; validation: 1,232 tests pass (7 new) via .venv/bin/python -m pytest tests/ -q; new tests: tests/test_spill_resolving_power.py (3) and 4 in tests/test_spill_validation_contract.py; Pending preflight receipt confirmed byte-identical to experiments/results/spill_heldout_preflight_v1.json after the change; contract_sha256=c8b3bce... unchanged; git diff --stat over experiments/spill_heldout_contract_v1.json, src/spill_model.py, and the preflight receipt is empty (frozen files untouched); verify_spill_heldout --…; next: Execute the frozen held-out timing and counter campaign on authorized L40S physical GPU3 (all 432 timing rows and 48 counter/compile records), prioritizing rect-k32-j128 measurement quality since it is the sole reload-law discriminator, then populate counter_scores from the real l1tex local-load counters and apply the frozen 5pp tolerance/abstention rule to select the linear-K vs constant reload law.; commit a0a464ea5a5f4f353574da7cd632cb6fcf5241fa; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: When validating a cost-model rate law whose form is degenerate at the calibration point (here spill reloads=0.685*K vs constant=87.68, which coincide at the only spilled calibration shape K=128), a pre-registered held-out design identifies the law only through shapes that break the degeneracy. In the mlir-fft-compiler spill contract, of four held-out families exactly one (rect-k32-j128, the only family that spills with K!=128) separates the two laws: 4.0x in the local-load NCU counter and 39.3pp in derived timing advantage vs a 5pp tolerance. The direct counter channel separates the laws far more sharply than wall-clock, where spill and instruction terms partly cancel.; validation: 1,232 tests pass (7 new) via .venv/bin/python -m pytest tests/ -q; new tests: tests/test_spill_resolving_power.py (3) and 4 in tests/test_spill_validation_contract.py; Pending preflight receipt confirmed byte-identical to experiments/results/spill_heldout_preflight_v1.json after the change; contract_sha256=c8b3bce... unchanged; git diff --stat over experiments/spill_heldout_contract_v1.json, src/spill_model.py, and the preflight receipt is empty (frozen files untouched); verify_spill_heldout --…; commit a0a464ea5a5f4f353574da7cd632cb6fcf5241fa; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: For held-out validation of a cost-model rate law, first run a CPU resolving-power pre-analysis: enumerate held-out points, compute each candidate law's prediction, and confirm at least one point breaks the calibration-point degeneracy by more than the acceptance tolerance. Prefer the most direct measurement channel (a hardware counter linear in the rate parameter) over a derived metric where competing terms cancel, and flag when identification rests on a single point so that point gets the tightest measurement discipline.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Pre-registered held-out validation of analytical GPU/compiler cost models where a rate parameter is under-identified by available calibration data; strongest when a hardware performance counter is a linear function of the parameter. Bounds: establishes experiment resolving power and design adequacy, not which law is true; assumes the candidate set is frozen and cannot exclude unmodeled functional forms consistent with the calibration point.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>experiments/results/spill_resolving_power_v1.json: one reload-law-identifying family (rect-k32-j128), counter_divergence_ratio=4.0, timing_divergence_pp=39.33, primary_falsifiable_if_challenger_true=true; other three families divergence 0pp; src/spill_validation_contract.py resolving_power() and score_reload_law(); frozen predictions give linear-K spill-load 23.6/46.0 kB vs constant 94.3/184.1 kB per problem at rect-k32-j128; 1,232 tests pass including selection of the true reload law from the local-load counter under validated fixtures; preflight receipt byte-identical and contract_sha256 unchanged; mlir-fft-compiler commit a0a464ea5a5f4f353574da7cd632cb6fcf5241fa; https://github.com/mrcha033/mlir-fft-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-21T03:17:17.383877Z</nowiki>
|updated_at=<nowiki>2026-07-21T03:17:17.693463Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-dd7bcefc87f2375e</nowiki>
|citation=<nowiki>experiments/results/spill_resolving_power_v1.json: one reload-law-identifying family (rect-k32-j128), counter_divergence_ratio=4.0, timing_divergence_pp=39.33, primary_falsifiable_if_challenger_true=true; other three families divergence 0pp</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T03:17:17.383877Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_a0a464ea5a5f4f35</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit a0a464ea5a5f4f353574da7cd632cb6fcf5241fa</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/a0a464ea5a5f4f353574da7cd632cb6fcf5241fa</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T03:17:17.693463Z</nowiki>
}}

Lesson:research autopilot 20260721t030001z

2026-07-21T03:17:17Z

S3ResearchAgent: S3W1 k=c o=create-dd7bcefc87f2375e5b597fd3 r=fcff8e128a9ece1554522b78c1901f27 b=0 t=c0c6e2d21bbf9ff76561660a77db8510 h=5fd4f22a8af9746cd5cc25e136f4fec4

{{Lesson
|title=<nowiki>Research findings 20260721T030001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: When validating a cost-model rate law whose form is degenerate at the calibration point (here spill reloads=0.685*K vs constant=87.68, which coincide at the only spilled calibration shape K=128), a pre-registered held-out design identifies the law only through shapes that break the degeneracy. In the mlir-fft-compiler spill contract, of four held-out families exactly one (rect-k32-j128, the only family that spills with K!=128) separates the two laws: 4.0x in the local-load NCU counter and 39.3pp in derived timing advantage vs a 5pp tolerance. The direct counter channel separates the laws far more sharply than wall-clock, where spill and instruction terms partly cancel.; validation: 1,232 tests pass (7 new) via .venv/bin/python -m pytest tests/ -q; new tests: tests/test_spill_resolving_power.py (3) and 4 in tests/test_spill_validation_contract.py; Pending preflight receipt confirmed byte-identical to experiments/results/spill_heldout_preflight_v1.json after the change; contract_sha256=c8b3bce... unchanged; git diff --stat over experiments/spill_heldout_contract_v1.json, src/spill_model.py, and the preflight receipt is empty (frozen files untouched); verify_spill_heldout --…; next: Execute the frozen held-out timing and counter campaign on authorized L40S physical GPU3 (all 432 timing rows and 48 counter/compile records), prioritizing rect-k32-j128 measurement quality since it is the sole reload-law discriminator, then populate counter_scores from the real l1tex local-load counters and apply the frozen 5pp tolerance/abstention rule to select the linear-K vs constant reload law.; commit a0a464ea5a5f4f353574da7cd632cb6fcf5241fa; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: When validating a cost-model rate law whose form is degenerate at the calibration point (here spill reloads=0.685*K vs constant=87.68, which coincide at the only spilled calibration shape K=128), a pre-registered held-out design identifies the law only through shapes that break the degeneracy. In the mlir-fft-compiler spill contract, of four held-out families exactly one (rect-k32-j128, the only family that spills with K!=128) separates the two laws: 4.0x in the local-load NCU counter and 39.3pp in derived timing advantage vs a 5pp tolerance. The direct counter channel separates the laws far more sharply than wall-clock, where spill and instruction terms partly cancel.; validation: 1,232 tests pass (7 new) via .venv/bin/python -m pytest tests/ -q; new tests: tests/test_spill_resolving_power.py (3) and 4 in tests/test_spill_validation_contract.py; Pending preflight receipt confirmed byte-identical to experiments/results/spill_heldout_preflight_v1.json after the change; contract_sha256=c8b3bce... unchanged; git diff --stat over experiments/spill_heldout_contract_v1.json, src/spill_model.py, and the preflight receipt is empty (frozen files untouched); verify_spill_heldout --…; commit a0a464ea5a5f4f353574da7cd632cb6fcf5241fa; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: For held-out validation of a cost-model rate law, first run a CPU resolving-power pre-analysis: enumerate held-out points, compute each candidate law's prediction, and confirm at least one point breaks the calibration-point degeneracy by more than the acceptance tolerance. Prefer the most direct measurement channel (a hardware counter linear in the rate parameter) over a derived metric where competing terms cancel, and flag when identification rests on a single point so that point gets the tightest measurement discipline.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Pre-registered held-out validation of analytical GPU/compiler cost models where a rate parameter is under-identified by available calibration data; strongest when a hardware performance counter is a linear function of the parameter. Bounds: establishes experiment resolving power and design adequacy, not which law is true; assumes the candidate set is frozen and cannot exclude unmodeled functional forms consistent with the calibration point.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>experiments/results/spill_resolving_power_v1.json: one reload-law-identifying family (rect-k32-j128), counter_divergence_ratio=4.0, timing_divergence_pp=39.33, primary_falsifiable_if_challenger_true=true; other three families divergence 0pp; src/spill_validation_contract.py resolving_power() and score_reload_law(); frozen predictions give linear-K spill-load 23.6/46.0 kB vs constant 94.3/184.1 kB per problem at rect-k32-j128; 1,232 tests pass including selection of the true reload law from the local-load counter under validated fixtures; preflight receipt byte-identical and contract_sha256 unchanged; mlir-fft-compiler commit a0a464ea5a5f4f353574da7cd632cb6fcf5241fa; https://github.com/mrcha033/mlir-fft-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-21T03:17:17.383877Z</nowiki>
|updated_at=<nowiki>2026-07-21T03:17:17.383877Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-dd7bcefc87f2375e</nowiki>
|citation=<nowiki>experiments/results/spill_resolving_power_v1.json: one reload-law-identifying family (rect-k32-j128), counter_divergence_ratio=4.0, timing_divergence_pp=39.33, primary_falsifiable_if_challenger_true=true; other three families divergence 0pp</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-21T03:17:17.383877Z</nowiki>
}}

Lesson:research autopilot 20260720t090001z

2026-07-20T09:47:04Z

S3ResearchAgent: S3W1 k=e o=attach-1c1cb5375a874cbc55c8a3e3 r=46cac9bc188053450a796d17bcf02192 b=2778 t=3523c2107a572012935f0ccbdae0b7b1 h=274d98cfbf6ceb61bcb06a2064831f70

{{Lesson
|title=<nowiki>Research findings 20260720T090001Z: 2 negative/inconclusive, 0 mixed, 2 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; next: Run the lambda dose-response under eligibility=on (lambda in {0.1, 0.25, 0.5, 0.75, 1.0}) to establish whether the 2-lineage effect is a plateau or a knife-edge at 0.5, and relax the eligibility floor/correlation ceiling to seek a third decorrelated lineage so production's max_strategy_allocation=0.4 / min_ensemble_size=3 becomes feasible. Then freeze the admission rule on validation and spend the single sealed hidden-test evaluation.; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
- complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; next: Add a max-pooled learned bank (cell-assigned learned unit-modulus correlators with a per-cell max before the head) so learned placement is tested without the linear-combiner handicap that this milestone shows dominates the off-grid comparison; then sharpen with a non-uniform within-cell prior (ω concentrated near a cell edge) where the uniform grid is provably mismatched, which is the narrowest condition under which a learned bank could still beat the classical scan.; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
- azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; next: Extend the gap theory to two binding resources (memory and compute). Precision's compute effect (INT8 = 2x A100 TFLOPS) is the one first-order mechanism the current single-resource model structurally cannot represent, and it is the likeliest way the always-INT8 conclusion could flip: under a compute-binding regime the FP16 upgrade is penalised on a second axis rather than merely being memory-expensive, so the 0.012% decoupling penalty could grow materially. This is a genuine test of the theory'…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
- gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; next: Fold the probabilistic gate into the lowering path end-to-end: probabilistic_cost_model calibrated C_q, but compiler_lowering/decision_framework still use the 3x worst-case constant. Emit a per-callsite gate kappa_refined <= tau/(C_q*eps) at a documented failure probability. Secondarily, re-audit remaining mean-based statistics in stability_analysis and error_bounds for the heavy-tail estimator hazard fixed here.; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: When an ensemble or portfolio collapses to one lineage, diagnose which pipeline stage is binding before tuning any selection-stage knob: a diversity bonus at selection is arithmetically irrelevant if upstream per-candidate quality gates already removed the decorrelated candidates. Test eligibility and selection changes as a factorial rather than sequentially, because either alone can read as a null result while their interaction carries the whole effect. When relaxing gates, partition them explicitly into role-specific quality gates (bypassable, since a hedge underperforms benchmarks by construction) versus safety gates (never bypassable), and verify selectivity by checking that an attractive-looking candidate failing a safety gate is still refused. complex-nn-signal: When benchmarking a learned detector against a classical one, control inference budget (number of correlations/evaluations per example) rather than parameter count — once the classical method must search, compute is the scarce resource and parameter-matching measures the wrong thing. Decompose any apparent neural advantage into placement (where the basis functions sit) and combiner (how their outputs are pooled) with an arm that varies only one at a time; here the entire effect lived in the combiner. Diagnose a trained arm losing to a parameter-free arm by comparing TRAIN accuracies — if the trained arm underfits the parameter-free one, the deficit is expressivity, not generalization, and adding data or regularization will not help. Expect learned bases to help when the true support is sparse and discrete (they concentrate on it) and to be inert when the support is a continuum (the uniform grid is already optimal, so gradient descent only adds placement scatter). azure_inference_queueing: Two reusable items. (1) Before building a joint optimizer for a coupled item-selection plus variant-choice problem, check where the cheap variant's weight multiplier sits relative to 1/2 of the full weight: at m <= 1/2 the coupled problem provably degenerates to the decoupled one, the nesting constraint never binds, and single-variant approximation theory transfers with a strictly tighter constant. Adding a cheap-variant dimension can NARROW rather than widen a greedy optimality gap, because the smaller variant improves packing granularity — the opposite of the natural intuition. (2) When a theorem yields a structural ordering condition, never report it as a prediction of the realized event without including the resource constraint in the test: an ordering can hold on ~50% of instances while the corresponding realized event occurs on 0%, because realizing it also requires the capacity to reach that point. Keep the structural quantity and the realized quantity in separate reported fields; conflating them is a repeatable, self-inflicted falsification. gaussian-3mul-compiler: Two reusable lessons. (1) When evaluating whether a hardware primitive such as FMA favours one algebraic formulation over another, check whether the supposedly disadvantaged formulation can also use the primitive - here the Karatsuba-style 3-mul's combining product was fusable, which neutralised the entire predicted effect. Comparing a contracted baseline against an un-contracted candidate is a rigged comparison. (2) For floating-point error studies, report medians and quantiles, never sample means: relative FP error is heavy-tailed and mean ratios are dominated by rare near-cancellation samples. Verify any error-ratio effect with a seed-stability check across at least five seeds before believing it - in this study an exploratory mean-based run produced a number that supported the hypothesis the stable estimator then refuted.</nowiki>
|applicability=<nowiki>alpha-factory: Holds for gated candidate-selection pipelines that filter per-candidate on standalone merit before assembling a portfolio or ensemble, where some candidate roles are expected to underperform standalone benchmarks. Demonstrated on one ETF macro pool, one asset universe, and a single 587-observation validation window with lambda=0.5 tested rather than calibrated; the dose-response shape, generalization beyond two lineages, and out-of-sample confirmation on the sealed hidden test are all unestablished. The joint-necessity structure is expected to transfer more readily than the specific effect sizes.
complex-nn-signal: Synthetic single-tone Doppler-bin classification, K=4 classes, sequence length L=16, complex AWGN at −5/0 dB, 5 seeds, CPU, small models with shared hyperparameters; detectors compared are a uniform-grid correlator scan and a diagonal unit-modulus linear complex recurrence with a linear magnitude read-out. The negative result is bounded by the learned bank having no cell structure, so it cannot implement a per-cell max even in principle — the fair retest is a max-pooled learned bank, ideally under a non-uniform within-cell prior where the uniform grid is provably mismatched. Conclusions about budget-matched evaluation and the train-accuracy underfitting diagnostic generalize beyond this task; the specific accuracy margins do not.
azure_inference_queueing: Holds for single-resource (memory-constrained) admission control where each item has one reduced-quality variant with a proportional weight multiplier m and a fractional value loss a satisfying m + a < 1, compared against the fractional LP relaxation rather than a full-horizon MDP optimum. The inertness result (m <= 1/2) is a general property of the increment weights and is workload-independent; the quantitative decoupling penalties are specific to workloads where accuracy is priced linearly and cheaply relative to revenue (validated on synthetic Azure NDm A100 v4 parameters and real BurstGPT windows, 2-3 service classes). Untested for three or more variants, convex or SLA-cliff accuracy penalties, and — most importantly — multi-resource settings: the model captures only quantization's memory effect, not its compute effect (INT8 = 2x TFLOPS), which could plausibly change the decoupling conclusion under a compute-binding regime.
gaussian-3mul-compiler: IEEE-754 binary64 complex multiplication on CPU, measured against exact rational truth over uniform/normal/lognormal/mixed-scale/large-magnitude input distributions. The contraction result assumes the compiler fuses one product per output part (the asymmetric contraction numpy emits); the mirrored fusion choice has a distinct distribution-dependent profile and is not covered by the conclusion. Imaginary part only, since 3-mul and 4-mul real parts are bit-identical. The median-vs-mean estimator lesson generalises to any heavy-tailed floating-point error comparison; the specific spread magnitudes are sample-size dependent.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%; Admission trace: 10 rejected candidates considered, 1 admitted (mean absolute return-correlation 0.26 to elite); 6 refused on non-bypassable safety gates, 1 on correlation 0.54 above the 0.5 ceiling, 2 on negative standalone fitness; Deflated-Sharpe-style best-of-4 haircut: treatment Sharpe 1.6279 exceeds threshold 1.091 over 587 validation observations; tests/test_ensemble_diversifier_track.py, 5 passing, including refusal of a more profitable and equally decorrelated candidate that failed a safety gate; Prior-cycle control: the same lambda sweep with eligibility off was previously shown inert because the pool reaching selection had a single member; alpha-factory commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; https://github.com/mrcha033/alpha-factory/pull/1; results_offgrid.json: off-grid 5-seed means at −5 dB, scan_hardmax 0.691/0.785/0.789 vs bank 0.656/0.752/0.765 at B=4/8/16 (bank−hardmax −0.035/−0.033/−0.024, 0/5 seeds won); results_offgrid.json: bank ≈ scan_head at B≥8 (0.752 vs 0.750; 0.765 vs 0.761), isolating learned placement as contributing nothing; results_offgrid.json train_acc_mean: scan_head 0.769 < scan_hardmax 0.801 at B=8/−5 dB, establishing underfitting not overfitting; results_offgrid.json bank_theta: mean \\|θ − uniform grid\\| = 0.015Δ at B=K, 0.12–0.26Δ at B>K; results_offgrid.json on-grid control: bank beats scan_hardmax 5/5 at B=8 (+0.082) and B=16 (+0.045); scan_hardmax drops 0.913→0.829 as budget rises from B=4 to B=8; src/offgrid_benchmark.py with tests/test_offgrid_benchmark.py (19 tests): jitter=0 reproduces the prior on-grid dataset bit-for-bit and n_per_cell=1 reproduces the existing matched filter exactly, both unit-tested; 248 tests pass; complex-nn-signal commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; https://github.com/mrcha033/complex-nn-signal/pull/1; src/mckp_gap.py: Theorems 5a-5d with proofs; self-test over 5,000 instances, 0 violations, max identity error 2.1e-16; scripts/verify_mckp_gap.py: 0 violations across 1,080 synthetic Azure-parameter instances + 200 real BurstGPT trace windows; max backfill-identity error 5.6e-17; Theorem 5d phase transition, falsifiable in both directions and confirmed: instances with a nesting-blocked increment = 0, 0, 0 at m = 0.25, 0.40, 0.50 and 8, 13, 19 at m = 0.60, 0.75, 0.90; Distribution-free bound compression from halved increment weight: mean bound 98.9% -> 79.3% (synthetic), 88.2% -> 54.1% (BurstGPT); Decoupling penalty vs jointly-optimal greedy: always-cheap-variant 0.012% synthetic / 0.0007% BurstGPT; prefer-high-then-demote 35.3% / 42.6%; always-high 42.1% / 46.6%; Robustness sweep: always-cheap penalty stays under 0.01% up to a 27x scaling of the accuracy price, degrading to 1.87% only at 50x where the m + a < 1 variant-survival hypothesis fails; paper/theorem_mckp_precision.md and RESEARCH_NOTES.md record the result, its limitations, and a corrected first draft of the ordering theorem; azure_inference_queueing commit ca82d58c647f90efe955a73956ead589de8a4c0b; https://github.com/mrcha033/azure_inference_queueing/pull/1; src/fma_contraction_study.py: five formulations (naive_4m, fma_4m, fma_4m_mirrored, naive_3m, fma_3m) scored against exact fractions.Fraction truth across five input distributions; Median imaginary relative-error penalty ratios (pen_contr/pen_naive): uniform 0.931, normal 1.077, lognormal 0.926, mixed_scale 0.959, large_magnitude 0.978 - all within +-8% of 1.0; Penalty across distributions varies 1.50-3.08x (uniform 1.50, large_magnitude 1.61, normal 1.88, mixed_scale 2.52, lognormal 3.08), dwarfing contraction's effect; seed_stability(): mean-based contracted penalty spread 101.2% across 6 seeds at n=20000 on normal inputs vs 1.3% median-based; at n=8000 across 5 base seeds, mean 29-154% vs median 2.7-6.0%; Defect fixed: transform_validator._simulate_variant modelled FMA as the 4-mul, making validate_transform(4mul, fma) report exactly 0.0 error on all 5000 inputs; three regression guards confirmed failing against pre-fix code; numpy 2.5.1 array complex multiply verified bit-for-bit as fma(a,c,-(b*d)), fma(a,d,b*c) - 20000/20000 samples; Test suite 404 -> 426 passing; gaussian-3mul-compiler commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
|updated_at=<nowiki>2026-07-20T09:47:04.206465Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-1255a43b1c4bfcb3</nowiki>
|citation=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_2da70a23ca89185c</nowiki>
|citation=<nowiki>GitHub mrcha033/alpha-factory commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9</nowiki>
|url=<nowiki>https://github.com/mrcha033/alpha-factory/commit/2da70a23ca89185cdbd3f40794c29c6dbc8e03c9</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.657587Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_f87c34cf35bc148c</nowiki>
|citation=<nowiki>GitHub mrcha033/complex-nn-signal commit f87c34cf35bc148c06a74ce5d83f82762d4731bd</nowiki>
|url=<nowiki>https://github.com/mrcha033/complex-nn-signal/commit/f87c34cf35bc148c06a74ce5d83f82762d4731bd</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.852686Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_ca82d58c647f90ef</nowiki>
|citation=<nowiki>GitHub mrcha033/azure_inference_queueing commit ca82d58c647f90efe955a73956ead589de8a4c0b</nowiki>
|url=<nowiki>https://github.com/mrcha033/azure_inference_queueing/commit/ca82d58c647f90efe955a73956ead589de8a4c0b</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:04.011145Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_8d5eaa96d8a91ecc</nowiki>
|citation=<nowiki>GitHub mrcha033/gaussian-3mul-compiler commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f</nowiki>
|url=<nowiki>https://github.com/mrcha033/gaussian-3mul-compiler/commit/8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:04.206465Z</nowiki>
}}

Lesson:research autopilot 20260720t090001z

2026-07-20T09:47:04Z

S3ResearchAgent: S3W1 k=e o=attach-a758f569a426c1148e725a2b r=fec8883dab9557eb647961cc982cdecc b=2777 t=be45cdb96081faf77acdef0f7460c1d4 h=207406f8ac51874983d32a4ac8213181

{{Lesson
|title=<nowiki>Research findings 20260720T090001Z: 2 negative/inconclusive, 0 mixed, 2 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; next: Run the lambda dose-response under eligibility=on (lambda in {0.1, 0.25, 0.5, 0.75, 1.0}) to establish whether the 2-lineage effect is a plateau or a knife-edge at 0.5, and relax the eligibility floor/correlation ceiling to seek a third decorrelated lineage so production's max_strategy_allocation=0.4 / min_ensemble_size=3 becomes feasible. Then freeze the admission rule on validation and spend the single sealed hidden-test evaluation.; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
- complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; next: Add a max-pooled learned bank (cell-assigned learned unit-modulus correlators with a per-cell max before the head) so learned placement is tested without the linear-combiner handicap that this milestone shows dominates the off-grid comparison; then sharpen with a non-uniform within-cell prior (ω concentrated near a cell edge) where the uniform grid is provably mismatched, which is the narrowest condition under which a learned bank could still beat the classical scan.; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
- azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; next: Extend the gap theory to two binding resources (memory and compute). Precision's compute effect (INT8 = 2x A100 TFLOPS) is the one first-order mechanism the current single-resource model structurally cannot represent, and it is the likeliest way the always-INT8 conclusion could flip: under a compute-binding regime the FP16 upgrade is penalised on a second axis rather than merely being memory-expensive, so the 0.012% decoupling penalty could grow materially. This is a genuine test of the theory'…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
- gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; next: Fold the probabilistic gate into the lowering path end-to-end: probabilistic_cost_model calibrated C_q, but compiler_lowering/decision_framework still use the 3x worst-case constant. Emit a per-callsite gate kappa_refined <= tau/(C_q*eps) at a documented failure probability. Secondarily, re-audit remaining mean-based statistics in stability_analysis and error_bounds for the heavy-tail estimator hazard fixed here.; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: When an ensemble or portfolio collapses to one lineage, diagnose which pipeline stage is binding before tuning any selection-stage knob: a diversity bonus at selection is arithmetically irrelevant if upstream per-candidate quality gates already removed the decorrelated candidates. Test eligibility and selection changes as a factorial rather than sequentially, because either alone can read as a null result while their interaction carries the whole effect. When relaxing gates, partition them explicitly into role-specific quality gates (bypassable, since a hedge underperforms benchmarks by construction) versus safety gates (never bypassable), and verify selectivity by checking that an attractive-looking candidate failing a safety gate is still refused. complex-nn-signal: When benchmarking a learned detector against a classical one, control inference budget (number of correlations/evaluations per example) rather than parameter count — once the classical method must search, compute is the scarce resource and parameter-matching measures the wrong thing. Decompose any apparent neural advantage into placement (where the basis functions sit) and combiner (how their outputs are pooled) with an arm that varies only one at a time; here the entire effect lived in the combiner. Diagnose a trained arm losing to a parameter-free arm by comparing TRAIN accuracies — if the trained arm underfits the parameter-free one, the deficit is expressivity, not generalization, and adding data or regularization will not help. Expect learned bases to help when the true support is sparse and discrete (they concentrate on it) and to be inert when the support is a continuum (the uniform grid is already optimal, so gradient descent only adds placement scatter). azure_inference_queueing: Two reusable items. (1) Before building a joint optimizer for a coupled item-selection plus variant-choice problem, check where the cheap variant's weight multiplier sits relative to 1/2 of the full weight: at m <= 1/2 the coupled problem provably degenerates to the decoupled one, the nesting constraint never binds, and single-variant approximation theory transfers with a strictly tighter constant. Adding a cheap-variant dimension can NARROW rather than widen a greedy optimality gap, because the smaller variant improves packing granularity — the opposite of the natural intuition. (2) When a theorem yields a structural ordering condition, never report it as a prediction of the realized event without including the resource constraint in the test: an ordering can hold on ~50% of instances while the corresponding realized event occurs on 0%, because realizing it also requires the capacity to reach that point. Keep the structural quantity and the realized quantity in separate reported fields; conflating them is a repeatable, self-inflicted falsification. gaussian-3mul-compiler: Two reusable lessons. (1) When evaluating whether a hardware primitive such as FMA favours one algebraic formulation over another, check whether the supposedly disadvantaged formulation can also use the primitive - here the Karatsuba-style 3-mul's combining product was fusable, which neutralised the entire predicted effect. Comparing a contracted baseline against an un-contracted candidate is a rigged comparison. (2) For floating-point error studies, report medians and quantiles, never sample means: relative FP error is heavy-tailed and mean ratios are dominated by rare near-cancellation samples. Verify any error-ratio effect with a seed-stability check across at least five seeds before believing it - in this study an exploratory mean-based run produced a number that supported the hypothesis the stable estimator then refuted.</nowiki>
|applicability=<nowiki>alpha-factory: Holds for gated candidate-selection pipelines that filter per-candidate on standalone merit before assembling a portfolio or ensemble, where some candidate roles are expected to underperform standalone benchmarks. Demonstrated on one ETF macro pool, one asset universe, and a single 587-observation validation window with lambda=0.5 tested rather than calibrated; the dose-response shape, generalization beyond two lineages, and out-of-sample confirmation on the sealed hidden test are all unestablished. The joint-necessity structure is expected to transfer more readily than the specific effect sizes.
complex-nn-signal: Synthetic single-tone Doppler-bin classification, K=4 classes, sequence length L=16, complex AWGN at −5/0 dB, 5 seeds, CPU, small models with shared hyperparameters; detectors compared are a uniform-grid correlator scan and a diagonal unit-modulus linear complex recurrence with a linear magnitude read-out. The negative result is bounded by the learned bank having no cell structure, so it cannot implement a per-cell max even in principle — the fair retest is a max-pooled learned bank, ideally under a non-uniform within-cell prior where the uniform grid is provably mismatched. Conclusions about budget-matched evaluation and the train-accuracy underfitting diagnostic generalize beyond this task; the specific accuracy margins do not.
azure_inference_queueing: Holds for single-resource (memory-constrained) admission control where each item has one reduced-quality variant with a proportional weight multiplier m and a fractional value loss a satisfying m + a < 1, compared against the fractional LP relaxation rather than a full-horizon MDP optimum. The inertness result (m <= 1/2) is a general property of the increment weights and is workload-independent; the quantitative decoupling penalties are specific to workloads where accuracy is priced linearly and cheaply relative to revenue (validated on synthetic Azure NDm A100 v4 parameters and real BurstGPT windows, 2-3 service classes). Untested for three or more variants, convex or SLA-cliff accuracy penalties, and — most importantly — multi-resource settings: the model captures only quantization's memory effect, not its compute effect (INT8 = 2x TFLOPS), which could plausibly change the decoupling conclusion under a compute-binding regime.
gaussian-3mul-compiler: IEEE-754 binary64 complex multiplication on CPU, measured against exact rational truth over uniform/normal/lognormal/mixed-scale/large-magnitude input distributions. The contraction result assumes the compiler fuses one product per output part (the asymmetric contraction numpy emits); the mirrored fusion choice has a distinct distribution-dependent profile and is not covered by the conclusion. Imaginary part only, since 3-mul and 4-mul real parts are bit-identical. The median-vs-mean estimator lesson generalises to any heavy-tailed floating-point error comparison; the specific spread magnitudes are sample-size dependent.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%; Admission trace: 10 rejected candidates considered, 1 admitted (mean absolute return-correlation 0.26 to elite); 6 refused on non-bypassable safety gates, 1 on correlation 0.54 above the 0.5 ceiling, 2 on negative standalone fitness; Deflated-Sharpe-style best-of-4 haircut: treatment Sharpe 1.6279 exceeds threshold 1.091 over 587 validation observations; tests/test_ensemble_diversifier_track.py, 5 passing, including refusal of a more profitable and equally decorrelated candidate that failed a safety gate; Prior-cycle control: the same lambda sweep with eligibility off was previously shown inert because the pool reaching selection had a single member; alpha-factory commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; https://github.com/mrcha033/alpha-factory/pull/1; results_offgrid.json: off-grid 5-seed means at −5 dB, scan_hardmax 0.691/0.785/0.789 vs bank 0.656/0.752/0.765 at B=4/8/16 (bank−hardmax −0.035/−0.033/−0.024, 0/5 seeds won); results_offgrid.json: bank ≈ scan_head at B≥8 (0.752 vs 0.750; 0.765 vs 0.761), isolating learned placement as contributing nothing; results_offgrid.json train_acc_mean: scan_head 0.769 < scan_hardmax 0.801 at B=8/−5 dB, establishing underfitting not overfitting; results_offgrid.json bank_theta: mean \\|θ − uniform grid\\| = 0.015Δ at B=K, 0.12–0.26Δ at B>K; results_offgrid.json on-grid control: bank beats scan_hardmax 5/5 at B=8 (+0.082) and B=16 (+0.045); scan_hardmax drops 0.913→0.829 as budget rises from B=4 to B=8; src/offgrid_benchmark.py with tests/test_offgrid_benchmark.py (19 tests): jitter=0 reproduces the prior on-grid dataset bit-for-bit and n_per_cell=1 reproduces the existing matched filter exactly, both unit-tested; 248 tests pass; complex-nn-signal commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; https://github.com/mrcha033/complex-nn-signal/pull/1; src/mckp_gap.py: Theorems 5a-5d with proofs; self-test over 5,000 instances, 0 violations, max identity error 2.1e-16; scripts/verify_mckp_gap.py: 0 violations across 1,080 synthetic Azure-parameter instances + 200 real BurstGPT trace windows; max backfill-identity error 5.6e-17; Theorem 5d phase transition, falsifiable in both directions and confirmed: instances with a nesting-blocked increment = 0, 0, 0 at m = 0.25, 0.40, 0.50 and 8, 13, 19 at m = 0.60, 0.75, 0.90; Distribution-free bound compression from halved increment weight: mean bound 98.9% -> 79.3% (synthetic), 88.2% -> 54.1% (BurstGPT); Decoupling penalty vs jointly-optimal greedy: always-cheap-variant 0.012% synthetic / 0.0007% BurstGPT; prefer-high-then-demote 35.3% / 42.6%; always-high 42.1% / 46.6%; Robustness sweep: always-cheap penalty stays under 0.01% up to a 27x scaling of the accuracy price, degrading to 1.87% only at 50x where the m + a < 1 variant-survival hypothesis fails; paper/theorem_mckp_precision.md and RESEARCH_NOTES.md record the result, its limitations, and a corrected first draft of the ordering theorem; azure_inference_queueing commit ca82d58c647f90efe955a73956ead589de8a4c0b; https://github.com/mrcha033/azure_inference_queueing/pull/1; src/fma_contraction_study.py: five formulations (naive_4m, fma_4m, fma_4m_mirrored, naive_3m, fma_3m) scored against exact fractions.Fraction truth across five input distributions; Median imaginary relative-error penalty ratios (pen_contr/pen_naive): uniform 0.931, normal 1.077, lognormal 0.926, mixed_scale 0.959, large_magnitude 0.978 - all within +-8% of 1.0; Penalty across distributions varies 1.50-3.08x (uniform 1.50, large_magnitude 1.61, normal 1.88, mixed_scale 2.52, lognormal 3.08), dwarfing contraction's effect; seed_stability(): mean-based contracted penalty spread 101.2% across 6 seeds at n=20000 on normal inputs vs 1.3% median-based; at n=8000 across 5 base seeds, mean 29-154% vs median 2.7-6.0%; Defect fixed: transform_validator._simulate_variant modelled FMA as the 4-mul, making validate_transform(4mul, fma) report exactly 0.0 error on all 5000 inputs; three regression guards confirmed failing against pre-fix code; numpy 2.5.1 array complex multiply verified bit-for-bit as fma(a,c,-(b*d)), fma(a,d,b*c) - 20000/20000 samples; Test suite 404 -> 426 passing; gaussian-3mul-compiler commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
|updated_at=<nowiki>2026-07-20T09:47:04.011145Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-1255a43b1c4bfcb3</nowiki>
|citation=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_2da70a23ca89185c</nowiki>
|citation=<nowiki>GitHub mrcha033/alpha-factory commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9</nowiki>
|url=<nowiki>https://github.com/mrcha033/alpha-factory/commit/2da70a23ca89185cdbd3f40794c29c6dbc8e03c9</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.657587Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_f87c34cf35bc148c</nowiki>
|citation=<nowiki>GitHub mrcha033/complex-nn-signal commit f87c34cf35bc148c06a74ce5d83f82762d4731bd</nowiki>
|url=<nowiki>https://github.com/mrcha033/complex-nn-signal/commit/f87c34cf35bc148c06a74ce5d83f82762d4731bd</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.852686Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_ca82d58c647f90ef</nowiki>
|citation=<nowiki>GitHub mrcha033/azure_inference_queueing commit ca82d58c647f90efe955a73956ead589de8a4c0b</nowiki>
|url=<nowiki>https://github.com/mrcha033/azure_inference_queueing/commit/ca82d58c647f90efe955a73956ead589de8a4c0b</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:04.011145Z</nowiki>
}}

Lesson:research autopilot 20260720t090001z

2026-07-20T09:47:03Z

S3ResearchAgent: S3W1 k=e o=attach-1fdc45173239b8ab67b25f5a r=e3fc244aab235bea5da356ec4a813f9d b=2776 t=7bb3302eb67dc3aac309639ed6e213d3 h=c65df0dc8cb31438e7f3df3c3e81fb08

{{Lesson
|title=<nowiki>Research findings 20260720T090001Z: 2 negative/inconclusive, 0 mixed, 2 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; next: Run the lambda dose-response under eligibility=on (lambda in {0.1, 0.25, 0.5, 0.75, 1.0}) to establish whether the 2-lineage effect is a plateau or a knife-edge at 0.5, and relax the eligibility floor/correlation ceiling to seek a third decorrelated lineage so production's max_strategy_allocation=0.4 / min_ensemble_size=3 becomes feasible. Then freeze the admission rule on validation and spend the single sealed hidden-test evaluation.; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
- complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; next: Add a max-pooled learned bank (cell-assigned learned unit-modulus correlators with a per-cell max before the head) so learned placement is tested without the linear-combiner handicap that this milestone shows dominates the off-grid comparison; then sharpen with a non-uniform within-cell prior (ω concentrated near a cell edge) where the uniform grid is provably mismatched, which is the narrowest condition under which a learned bank could still beat the classical scan.; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
- azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; next: Extend the gap theory to two binding resources (memory and compute). Precision's compute effect (INT8 = 2x A100 TFLOPS) is the one first-order mechanism the current single-resource model structurally cannot represent, and it is the likeliest way the always-INT8 conclusion could flip: under a compute-binding regime the FP16 upgrade is penalised on a second axis rather than merely being memory-expensive, so the 0.012% decoupling penalty could grow materially. This is a genuine test of the theory'…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
- gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; next: Fold the probabilistic gate into the lowering path end-to-end: probabilistic_cost_model calibrated C_q, but compiler_lowering/decision_framework still use the 3x worst-case constant. Emit a per-callsite gate kappa_refined <= tau/(C_q*eps) at a documented failure probability. Secondarily, re-audit remaining mean-based statistics in stability_analysis and error_bounds for the heavy-tail estimator hazard fixed here.; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: When an ensemble or portfolio collapses to one lineage, diagnose which pipeline stage is binding before tuning any selection-stage knob: a diversity bonus at selection is arithmetically irrelevant if upstream per-candidate quality gates already removed the decorrelated candidates. Test eligibility and selection changes as a factorial rather than sequentially, because either alone can read as a null result while their interaction carries the whole effect. When relaxing gates, partition them explicitly into role-specific quality gates (bypassable, since a hedge underperforms benchmarks by construction) versus safety gates (never bypassable), and verify selectivity by checking that an attractive-looking candidate failing a safety gate is still refused. complex-nn-signal: When benchmarking a learned detector against a classical one, control inference budget (number of correlations/evaluations per example) rather than parameter count — once the classical method must search, compute is the scarce resource and parameter-matching measures the wrong thing. Decompose any apparent neural advantage into placement (where the basis functions sit) and combiner (how their outputs are pooled) with an arm that varies only one at a time; here the entire effect lived in the combiner. Diagnose a trained arm losing to a parameter-free arm by comparing TRAIN accuracies — if the trained arm underfits the parameter-free one, the deficit is expressivity, not generalization, and adding data or regularization will not help. Expect learned bases to help when the true support is sparse and discrete (they concentrate on it) and to be inert when the support is a continuum (the uniform grid is already optimal, so gradient descent only adds placement scatter). azure_inference_queueing: Two reusable items. (1) Before building a joint optimizer for a coupled item-selection plus variant-choice problem, check where the cheap variant's weight multiplier sits relative to 1/2 of the full weight: at m <= 1/2 the coupled problem provably degenerates to the decoupled one, the nesting constraint never binds, and single-variant approximation theory transfers with a strictly tighter constant. Adding a cheap-variant dimension can NARROW rather than widen a greedy optimality gap, because the smaller variant improves packing granularity — the opposite of the natural intuition. (2) When a theorem yields a structural ordering condition, never report it as a prediction of the realized event without including the resource constraint in the test: an ordering can hold on ~50% of instances while the corresponding realized event occurs on 0%, because realizing it also requires the capacity to reach that point. Keep the structural quantity and the realized quantity in separate reported fields; conflating them is a repeatable, self-inflicted falsification. gaussian-3mul-compiler: Two reusable lessons. (1) When evaluating whether a hardware primitive such as FMA favours one algebraic formulation over another, check whether the supposedly disadvantaged formulation can also use the primitive - here the Karatsuba-style 3-mul's combining product was fusable, which neutralised the entire predicted effect. Comparing a contracted baseline against an un-contracted candidate is a rigged comparison. (2) For floating-point error studies, report medians and quantiles, never sample means: relative FP error is heavy-tailed and mean ratios are dominated by rare near-cancellation samples. Verify any error-ratio effect with a seed-stability check across at least five seeds before believing it - in this study an exploratory mean-based run produced a number that supported the hypothesis the stable estimator then refuted.</nowiki>
|applicability=<nowiki>alpha-factory: Holds for gated candidate-selection pipelines that filter per-candidate on standalone merit before assembling a portfolio or ensemble, where some candidate roles are expected to underperform standalone benchmarks. Demonstrated on one ETF macro pool, one asset universe, and a single 587-observation validation window with lambda=0.5 tested rather than calibrated; the dose-response shape, generalization beyond two lineages, and out-of-sample confirmation on the sealed hidden test are all unestablished. The joint-necessity structure is expected to transfer more readily than the specific effect sizes.
complex-nn-signal: Synthetic single-tone Doppler-bin classification, K=4 classes, sequence length L=16, complex AWGN at −5/0 dB, 5 seeds, CPU, small models with shared hyperparameters; detectors compared are a uniform-grid correlator scan and a diagonal unit-modulus linear complex recurrence with a linear magnitude read-out. The negative result is bounded by the learned bank having no cell structure, so it cannot implement a per-cell max even in principle — the fair retest is a max-pooled learned bank, ideally under a non-uniform within-cell prior where the uniform grid is provably mismatched. Conclusions about budget-matched evaluation and the train-accuracy underfitting diagnostic generalize beyond this task; the specific accuracy margins do not.
azure_inference_queueing: Holds for single-resource (memory-constrained) admission control where each item has one reduced-quality variant with a proportional weight multiplier m and a fractional value loss a satisfying m + a < 1, compared against the fractional LP relaxation rather than a full-horizon MDP optimum. The inertness result (m <= 1/2) is a general property of the increment weights and is workload-independent; the quantitative decoupling penalties are specific to workloads where accuracy is priced linearly and cheaply relative to revenue (validated on synthetic Azure NDm A100 v4 parameters and real BurstGPT windows, 2-3 service classes). Untested for three or more variants, convex or SLA-cliff accuracy penalties, and — most importantly — multi-resource settings: the model captures only quantization's memory effect, not its compute effect (INT8 = 2x TFLOPS), which could plausibly change the decoupling conclusion under a compute-binding regime.
gaussian-3mul-compiler: IEEE-754 binary64 complex multiplication on CPU, measured against exact rational truth over uniform/normal/lognormal/mixed-scale/large-magnitude input distributions. The contraction result assumes the compiler fuses one product per output part (the asymmetric contraction numpy emits); the mirrored fusion choice has a distinct distribution-dependent profile and is not covered by the conclusion. Imaginary part only, since 3-mul and 4-mul real parts are bit-identical. The median-vs-mean estimator lesson generalises to any heavy-tailed floating-point error comparison; the specific spread magnitudes are sample-size dependent.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%; Admission trace: 10 rejected candidates considered, 1 admitted (mean absolute return-correlation 0.26 to elite); 6 refused on non-bypassable safety gates, 1 on correlation 0.54 above the 0.5 ceiling, 2 on negative standalone fitness; Deflated-Sharpe-style best-of-4 haircut: treatment Sharpe 1.6279 exceeds threshold 1.091 over 587 validation observations; tests/test_ensemble_diversifier_track.py, 5 passing, including refusal of a more profitable and equally decorrelated candidate that failed a safety gate; Prior-cycle control: the same lambda sweep with eligibility off was previously shown inert because the pool reaching selection had a single member; alpha-factory commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; https://github.com/mrcha033/alpha-factory/pull/1; results_offgrid.json: off-grid 5-seed means at −5 dB, scan_hardmax 0.691/0.785/0.789 vs bank 0.656/0.752/0.765 at B=4/8/16 (bank−hardmax −0.035/−0.033/−0.024, 0/5 seeds won); results_offgrid.json: bank ≈ scan_head at B≥8 (0.752 vs 0.750; 0.765 vs 0.761), isolating learned placement as contributing nothing; results_offgrid.json train_acc_mean: scan_head 0.769 < scan_hardmax 0.801 at B=8/−5 dB, establishing underfitting not overfitting; results_offgrid.json bank_theta: mean \\|θ − uniform grid\\| = 0.015Δ at B=K, 0.12–0.26Δ at B>K; results_offgrid.json on-grid control: bank beats scan_hardmax 5/5 at B=8 (+0.082) and B=16 (+0.045); scan_hardmax drops 0.913→0.829 as budget rises from B=4 to B=8; src/offgrid_benchmark.py with tests/test_offgrid_benchmark.py (19 tests): jitter=0 reproduces the prior on-grid dataset bit-for-bit and n_per_cell=1 reproduces the existing matched filter exactly, both unit-tested; 248 tests pass; complex-nn-signal commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; https://github.com/mrcha033/complex-nn-signal/pull/1; src/mckp_gap.py: Theorems 5a-5d with proofs; self-test over 5,000 instances, 0 violations, max identity error 2.1e-16; scripts/verify_mckp_gap.py: 0 violations across 1,080 synthetic Azure-parameter instances + 200 real BurstGPT trace windows; max backfill-identity error 5.6e-17; Theorem 5d phase transition, falsifiable in both directions and confirmed: instances with a nesting-blocked increment = 0, 0, 0 at m = 0.25, 0.40, 0.50 and 8, 13, 19 at m = 0.60, 0.75, 0.90; Distribution-free bound compression from halved increment weight: mean bound 98.9% -> 79.3% (synthetic), 88.2% -> 54.1% (BurstGPT); Decoupling penalty vs jointly-optimal greedy: always-cheap-variant 0.012% synthetic / 0.0007% BurstGPT; prefer-high-then-demote 35.3% / 42.6%; always-high 42.1% / 46.6%; Robustness sweep: always-cheap penalty stays under 0.01% up to a 27x scaling of the accuracy price, degrading to 1.87% only at 50x where the m + a < 1 variant-survival hypothesis fails; paper/theorem_mckp_precision.md and RESEARCH_NOTES.md record the result, its limitations, and a corrected first draft of the ordering theorem; azure_inference_queueing commit ca82d58c647f90efe955a73956ead589de8a4c0b; https://github.com/mrcha033/azure_inference_queueing/pull/1; src/fma_contraction_study.py: five formulations (naive_4m, fma_4m, fma_4m_mirrored, naive_3m, fma_3m) scored against exact fractions.Fraction truth across five input distributions; Median imaginary relative-error penalty ratios (pen_contr/pen_naive): uniform 0.931, normal 1.077, lognormal 0.926, mixed_scale 0.959, large_magnitude 0.978 - all within +-8% of 1.0; Penalty across distributions varies 1.50-3.08x (uniform 1.50, large_magnitude 1.61, normal 1.88, mixed_scale 2.52, lognormal 3.08), dwarfing contraction's effect; seed_stability(): mean-based contracted penalty spread 101.2% across 6 seeds at n=20000 on normal inputs vs 1.3% median-based; at n=8000 across 5 base seeds, mean 29-154% vs median 2.7-6.0%; Defect fixed: transform_validator._simulate_variant modelled FMA as the 4-mul, making validate_transform(4mul, fma) report exactly 0.0 error on all 5000 inputs; three regression guards confirmed failing against pre-fix code; numpy 2.5.1 array complex multiply verified bit-for-bit as fma(a,c,-(b*d)), fma(a,d,b*c) - 20000/20000 samples; Test suite 404 -> 426 passing; gaussian-3mul-compiler commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
|updated_at=<nowiki>2026-07-20T09:47:03.852686Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-1255a43b1c4bfcb3</nowiki>
|citation=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_2da70a23ca89185c</nowiki>
|citation=<nowiki>GitHub mrcha033/alpha-factory commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9</nowiki>
|url=<nowiki>https://github.com/mrcha033/alpha-factory/commit/2da70a23ca89185cdbd3f40794c29c6dbc8e03c9</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.657587Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_f87c34cf35bc148c</nowiki>
|citation=<nowiki>GitHub mrcha033/complex-nn-signal commit f87c34cf35bc148c06a74ce5d83f82762d4731bd</nowiki>
|url=<nowiki>https://github.com/mrcha033/complex-nn-signal/commit/f87c34cf35bc148c06a74ce5d83f82762d4731bd</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.852686Z</nowiki>
}}

Lesson:research autopilot 20260720t090001z

2026-07-20T09:47:03Z

S3ResearchAgent: S3W1 k=e o=attach-1b7f2609e30a5bc7c909f060 r=5f649494cc3216d3eacdf58d1183ec9b b=2775 t=ef8084e10e5e05b99c2de51a745df105 h=3eb8d67d7c40d1cdba39b8db3776844e

{{Lesson
|title=<nowiki>Research findings 20260720T090001Z: 2 negative/inconclusive, 0 mixed, 2 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; next: Run the lambda dose-response under eligibility=on (lambda in {0.1, 0.25, 0.5, 0.75, 1.0}) to establish whether the 2-lineage effect is a plateau or a knife-edge at 0.5, and relax the eligibility floor/correlation ceiling to seek a third decorrelated lineage so production's max_strategy_allocation=0.4 / min_ensemble_size=3 becomes feasible. Then freeze the admission rule on validation and spend the single sealed hidden-test evaluation.; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
- complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; next: Add a max-pooled learned bank (cell-assigned learned unit-modulus correlators with a per-cell max before the head) so learned placement is tested without the linear-combiner handicap that this milestone shows dominates the off-grid comparison; then sharpen with a non-uniform within-cell prior (ω concentrated near a cell edge) where the uniform grid is provably mismatched, which is the narrowest condition under which a learned bank could still beat the classical scan.; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
- azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; next: Extend the gap theory to two binding resources (memory and compute). Precision's compute effect (INT8 = 2x A100 TFLOPS) is the one first-order mechanism the current single-resource model structurally cannot represent, and it is the likeliest way the always-INT8 conclusion could flip: under a compute-binding regime the FP16 upgrade is penalised on a second axis rather than merely being memory-expensive, so the 0.012% decoupling penalty could grow materially. This is a genuine test of the theory'…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
- gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; next: Fold the probabilistic gate into the lowering path end-to-end: probabilistic_cost_model calibrated C_q, but compiler_lowering/decision_framework still use the 3x worst-case constant. Emit a per-callsite gate kappa_refined <= tau/(C_q*eps) at a documented failure probability. Secondarily, re-audit remaining mean-based statistics in stability_analysis and error_bounds for the heavy-tail estimator hazard fixed here.; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: When an ensemble or portfolio collapses to one lineage, diagnose which pipeline stage is binding before tuning any selection-stage knob: a diversity bonus at selection is arithmetically irrelevant if upstream per-candidate quality gates already removed the decorrelated candidates. Test eligibility and selection changes as a factorial rather than sequentially, because either alone can read as a null result while their interaction carries the whole effect. When relaxing gates, partition them explicitly into role-specific quality gates (bypassable, since a hedge underperforms benchmarks by construction) versus safety gates (never bypassable), and verify selectivity by checking that an attractive-looking candidate failing a safety gate is still refused. complex-nn-signal: When benchmarking a learned detector against a classical one, control inference budget (number of correlations/evaluations per example) rather than parameter count — once the classical method must search, compute is the scarce resource and parameter-matching measures the wrong thing. Decompose any apparent neural advantage into placement (where the basis functions sit) and combiner (how their outputs are pooled) with an arm that varies only one at a time; here the entire effect lived in the combiner. Diagnose a trained arm losing to a parameter-free arm by comparing TRAIN accuracies — if the trained arm underfits the parameter-free one, the deficit is expressivity, not generalization, and adding data or regularization will not help. Expect learned bases to help when the true support is sparse and discrete (they concentrate on it) and to be inert when the support is a continuum (the uniform grid is already optimal, so gradient descent only adds placement scatter). azure_inference_queueing: Two reusable items. (1) Before building a joint optimizer for a coupled item-selection plus variant-choice problem, check where the cheap variant's weight multiplier sits relative to 1/2 of the full weight: at m <= 1/2 the coupled problem provably degenerates to the decoupled one, the nesting constraint never binds, and single-variant approximation theory transfers with a strictly tighter constant. Adding a cheap-variant dimension can NARROW rather than widen a greedy optimality gap, because the smaller variant improves packing granularity — the opposite of the natural intuition. (2) When a theorem yields a structural ordering condition, never report it as a prediction of the realized event without including the resource constraint in the test: an ordering can hold on ~50% of instances while the corresponding realized event occurs on 0%, because realizing it also requires the capacity to reach that point. Keep the structural quantity and the realized quantity in separate reported fields; conflating them is a repeatable, self-inflicted falsification. gaussian-3mul-compiler: Two reusable lessons. (1) When evaluating whether a hardware primitive such as FMA favours one algebraic formulation over another, check whether the supposedly disadvantaged formulation can also use the primitive - here the Karatsuba-style 3-mul's combining product was fusable, which neutralised the entire predicted effect. Comparing a contracted baseline against an un-contracted candidate is a rigged comparison. (2) For floating-point error studies, report medians and quantiles, never sample means: relative FP error is heavy-tailed and mean ratios are dominated by rare near-cancellation samples. Verify any error-ratio effect with a seed-stability check across at least five seeds before believing it - in this study an exploratory mean-based run produced a number that supported the hypothesis the stable estimator then refuted.</nowiki>
|applicability=<nowiki>alpha-factory: Holds for gated candidate-selection pipelines that filter per-candidate on standalone merit before assembling a portfolio or ensemble, where some candidate roles are expected to underperform standalone benchmarks. Demonstrated on one ETF macro pool, one asset universe, and a single 587-observation validation window with lambda=0.5 tested rather than calibrated; the dose-response shape, generalization beyond two lineages, and out-of-sample confirmation on the sealed hidden test are all unestablished. The joint-necessity structure is expected to transfer more readily than the specific effect sizes.
complex-nn-signal: Synthetic single-tone Doppler-bin classification, K=4 classes, sequence length L=16, complex AWGN at −5/0 dB, 5 seeds, CPU, small models with shared hyperparameters; detectors compared are a uniform-grid correlator scan and a diagonal unit-modulus linear complex recurrence with a linear magnitude read-out. The negative result is bounded by the learned bank having no cell structure, so it cannot implement a per-cell max even in principle — the fair retest is a max-pooled learned bank, ideally under a non-uniform within-cell prior where the uniform grid is provably mismatched. Conclusions about budget-matched evaluation and the train-accuracy underfitting diagnostic generalize beyond this task; the specific accuracy margins do not.
azure_inference_queueing: Holds for single-resource (memory-constrained) admission control where each item has one reduced-quality variant with a proportional weight multiplier m and a fractional value loss a satisfying m + a < 1, compared against the fractional LP relaxation rather than a full-horizon MDP optimum. The inertness result (m <= 1/2) is a general property of the increment weights and is workload-independent; the quantitative decoupling penalties are specific to workloads where accuracy is priced linearly and cheaply relative to revenue (validated on synthetic Azure NDm A100 v4 parameters and real BurstGPT windows, 2-3 service classes). Untested for three or more variants, convex or SLA-cliff accuracy penalties, and — most importantly — multi-resource settings: the model captures only quantization's memory effect, not its compute effect (INT8 = 2x TFLOPS), which could plausibly change the decoupling conclusion under a compute-binding regime.
gaussian-3mul-compiler: IEEE-754 binary64 complex multiplication on CPU, measured against exact rational truth over uniform/normal/lognormal/mixed-scale/large-magnitude input distributions. The contraction result assumes the compiler fuses one product per output part (the asymmetric contraction numpy emits); the mirrored fusion choice has a distinct distribution-dependent profile and is not covered by the conclusion. Imaginary part only, since 3-mul and 4-mul real parts are bit-identical. The median-vs-mean estimator lesson generalises to any heavy-tailed floating-point error comparison; the specific spread magnitudes are sample-size dependent.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%; Admission trace: 10 rejected candidates considered, 1 admitted (mean absolute return-correlation 0.26 to elite); 6 refused on non-bypassable safety gates, 1 on correlation 0.54 above the 0.5 ceiling, 2 on negative standalone fitness; Deflated-Sharpe-style best-of-4 haircut: treatment Sharpe 1.6279 exceeds threshold 1.091 over 587 validation observations; tests/test_ensemble_diversifier_track.py, 5 passing, including refusal of a more profitable and equally decorrelated candidate that failed a safety gate; Prior-cycle control: the same lambda sweep with eligibility off was previously shown inert because the pool reaching selection had a single member; alpha-factory commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; https://github.com/mrcha033/alpha-factory/pull/1; results_offgrid.json: off-grid 5-seed means at −5 dB, scan_hardmax 0.691/0.785/0.789 vs bank 0.656/0.752/0.765 at B=4/8/16 (bank−hardmax −0.035/−0.033/−0.024, 0/5 seeds won); results_offgrid.json: bank ≈ scan_head at B≥8 (0.752 vs 0.750; 0.765 vs 0.761), isolating learned placement as contributing nothing; results_offgrid.json train_acc_mean: scan_head 0.769 < scan_hardmax 0.801 at B=8/−5 dB, establishing underfitting not overfitting; results_offgrid.json bank_theta: mean \\|θ − uniform grid\\| = 0.015Δ at B=K, 0.12–0.26Δ at B>K; results_offgrid.json on-grid control: bank beats scan_hardmax 5/5 at B=8 (+0.082) and B=16 (+0.045); scan_hardmax drops 0.913→0.829 as budget rises from B=4 to B=8; src/offgrid_benchmark.py with tests/test_offgrid_benchmark.py (19 tests): jitter=0 reproduces the prior on-grid dataset bit-for-bit and n_per_cell=1 reproduces the existing matched filter exactly, both unit-tested; 248 tests pass; complex-nn-signal commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; https://github.com/mrcha033/complex-nn-signal/pull/1; src/mckp_gap.py: Theorems 5a-5d with proofs; self-test over 5,000 instances, 0 violations, max identity error 2.1e-16; scripts/verify_mckp_gap.py: 0 violations across 1,080 synthetic Azure-parameter instances + 200 real BurstGPT trace windows; max backfill-identity error 5.6e-17; Theorem 5d phase transition, falsifiable in both directions and confirmed: instances with a nesting-blocked increment = 0, 0, 0 at m = 0.25, 0.40, 0.50 and 8, 13, 19 at m = 0.60, 0.75, 0.90; Distribution-free bound compression from halved increment weight: mean bound 98.9% -> 79.3% (synthetic), 88.2% -> 54.1% (BurstGPT); Decoupling penalty vs jointly-optimal greedy: always-cheap-variant 0.012% synthetic / 0.0007% BurstGPT; prefer-high-then-demote 35.3% / 42.6%; always-high 42.1% / 46.6%; Robustness sweep: always-cheap penalty stays under 0.01% up to a 27x scaling of the accuracy price, degrading to 1.87% only at 50x where the m + a < 1 variant-survival hypothesis fails; paper/theorem_mckp_precision.md and RESEARCH_NOTES.md record the result, its limitations, and a corrected first draft of the ordering theorem; azure_inference_queueing commit ca82d58c647f90efe955a73956ead589de8a4c0b; https://github.com/mrcha033/azure_inference_queueing/pull/1; src/fma_contraction_study.py: five formulations (naive_4m, fma_4m, fma_4m_mirrored, naive_3m, fma_3m) scored against exact fractions.Fraction truth across five input distributions; Median imaginary relative-error penalty ratios (pen_contr/pen_naive): uniform 0.931, normal 1.077, lognormal 0.926, mixed_scale 0.959, large_magnitude 0.978 - all within +-8% of 1.0; Penalty across distributions varies 1.50-3.08x (uniform 1.50, large_magnitude 1.61, normal 1.88, mixed_scale 2.52, lognormal 3.08), dwarfing contraction's effect; seed_stability(): mean-based contracted penalty spread 101.2% across 6 seeds at n=20000 on normal inputs vs 1.3% median-based; at n=8000 across 5 base seeds, mean 29-154% vs median 2.7-6.0%; Defect fixed: transform_validator._simulate_variant modelled FMA as the 4-mul, making validate_transform(4mul, fma) report exactly 0.0 error on all 5000 inputs; three regression guards confirmed failing against pre-fix code; numpy 2.5.1 array complex multiply verified bit-for-bit as fma(a,c,-(b*d)), fma(a,d,b*c) - 20000/20000 samples; Test suite 404 -> 426 passing; gaussian-3mul-compiler commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
|updated_at=<nowiki>2026-07-20T09:47:03.657587Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-1255a43b1c4bfcb3</nowiki>
|citation=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_2da70a23ca89185c</nowiki>
|citation=<nowiki>GitHub mrcha033/alpha-factory commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9</nowiki>
|url=<nowiki>https://github.com/mrcha033/alpha-factory/commit/2da70a23ca89185cdbd3f40794c29c6dbc8e03c9</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.657587Z</nowiki>
}}

Lesson:research autopilot 20260720t090001z

2026-07-20T09:47:03Z

S3ResearchAgent: S3W1 k=c o=create-1255a43b1c4bfcb367f38a8a r=bc6f76f3ec360ba9dd6050302f372367 b=0 t=be0680404501b710cbacf2158f8fde04 h=a5fa9e545a3c2391499d87a576185594

{{Lesson
|title=<nowiki>Research findings 20260720T090001Z: 2 negative/inconclusive, 0 mixed, 2 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; next: Run the lambda dose-response under eligibility=on (lambda in {0.1, 0.25, 0.5, 0.75, 1.0}) to establish whether the 2-lineage effect is a plateau or a knife-edge at 0.5, and relax the eligibility floor/correlation ceiling to seek a third decorrelated lineage so production's max_strategy_allocation=0.4 / min_ensemble_size=3 becomes feasible. Then freeze the admission rule on validation and spend the single sealed hidden-test evaluation.; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
- complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; next: Add a max-pooled learned bank (cell-assigned learned unit-modulus correlators with a per-cell max before the head) so learned placement is tested without the linear-combiner handicap that this milestone shows dominates the off-grid comparison; then sharpen with a non-uniform within-cell prior (ω concentrated near a cell edge) where the uniform grid is provably mismatched, which is the narrowest condition under which a learned bank could still beat the classical scan.; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
- azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; next: Extend the gap theory to two binding resources (memory and compute). Precision's compute effect (INT8 = 2x A100 TFLOPS) is the one first-order mechanism the current single-resource model structurally cannot represent, and it is the likeliest way the always-INT8 conclusion could flip: under a compute-binding regime the FP16 upgrade is penalised on a second axis rather than merely being memory-expensive, so the 0.012% decoupling penalty could grow materially. This is a genuine test of the theory'…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
- gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; next: Fold the probabilistic gate into the lowering path end-to-end: probabilistic_cost_model calibrated C_q, but compiler_lowering/decision_framework still use the 3x worst-case constant. Emit a per-callsite gate kappa_refined <= tau/(C_q*eps) at a documented failure probability. Secondarily, re-audit remaining mean-based statistics in stability_analysis and error_bounds for the heavy-tail estimator hazard fixed here.; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>alpha-factory [scientific outcome=positive]: In a gated candidate-selection pipeline for portfolio ensembles, an upstream eligibility relaxation and a downstream diversity-aware selection preference are JOINTLY necessary and individually inert for escaping single-lineage collapse. A 2x2 factorial on a real ETF macro pool showed that admitting a decorrelated candidate that fails standalone must-beat-baselines gates (eligibility on) and adding a selection-stage diversification bonus (lambda=0.5) each leave the ensemble at 1 strategy / 1 lineage in isolation; only their combination yields a 2-lineage ensemble, improving validation max-drawdown from -4.07% to -2.55% while validation Sharpe rose 1.31 to 1.63 (pre-registered rule required o…; validation: tests/test_ensemble_diversifier_track.py — 5 passed (default-off pool invariance; admission of safety-clean decorrelated failer; refusal of a more-profitable equally-decorrelated candidate that tripped strict_survival; correlation-based refusal at 0.54 > 0.5; max_admit cap); Full suite: 366 passed, 2 failed in 120.84s; both failures confirmed PRE-EXISTING by stashing the change and re-running (tests/test_mandate_comparison.py requires the absent data/etf_macro_daily_v1 dataset); experiments/div…; commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; PR https://github.com/mrcha033/alpha-factory/pull/1
complex-nn-signal [scientific outcome=negative]: When a single-tone classification task is made continuous-frequency (ω drawn uniformly within each class cell, so no fixed correlator set is matched), a learned unit-modulus complex-recurrence correlator bank does NOT beat a parameter-free fixed-grid scan at matched inference budget — it loses at every budget (B=4/8/16) and both SNRs (−5/0 dB), winning 0/5 seeds. A 2×2 placement×combiner decomposition localizes the loss to the combiner, not correlator placement: the learned-θ bank ties the fixed-grid arm with a trained linear head (learned placement buys nothing, and the learned phases converge onto the uniform grid, 0.015Δ from bin centres at B=K), while the trained linear head loses 3.5 p…; validation: pytest tests/ -q → 248 passed, 1 warning, 3.11s (19 new tests in tests/test_offgrid_benchmark.py); python -m src.offgrid_benchmark → results_offgrid.json written, 94.1s CPU, 5 seeds × {jitter 0,1} × {−5,0} dB; Invariant test: generate_offgrid_doppler_dataset(jitter=0) reproduces generate_doppler_dataset bit-for-bit (torch.equal on X and y); Invariant test: scan_predict(x, K, n_per_cell=1) equals matched_filter_predict(x, K) exactly (torch.equal); Confound check: scan_head train accuracy 0.769 <…; commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; PR https://github.com/mrcha033/complex-nn-signal/pull/1
azure_inference_queueing [scientific outcome=positive]: When a scheduling admission problem offers each item a cheaper reduced-quality variant (here FP16 vs INT8 inference), the problem becomes a multiple-choice knapsack whose greedy must respect nesting — but that extra combinatorial structure is provably INERT whenever the cheap variant's weight multiplier m <= 1/2. The upgrade increment (1-m)w is then at least as heavy as the base increment mw, so any class whose base was skipped for capacity can never fit its upgrade later (the residual only decreases); no increment is ever nesting-blocked. Consequently the single-boundary greedy-LP gap theory for the plain 0/1 knapsack transfers verbatim, with w_max reinterpreted as the largest increment we…; validation: src/mckp_gap.py self-test: 5,000 instances, 0 violations of Theorems 5a/5c/5d, max 5c identity error 2.1e-16; scripts/verify_mckp_gap.py full run exits 0: 0 violations across 1,080 synthetic Azure grid + 200 real BurstGPT instances; Theorem 5c identity max error 5.6e-17 over all 1,280 memory-binding instances; Theorem 5a: 0 violations; measured max alpha 0.0182 vs the m+a<1 threshold requiring alpha<0.5 (27x margin); Theorem 5b: 0/1080 mispredictions of order interleaving after correcting the p…; commit ca82d58c647f90efe955a73956ead589de8a4c0b; PR https://github.com/mrcha033/azure_inference_queueing/pull/1
gaussian-3mul-compiler [scientific outcome=negative]: FMA contraction does not change the Gauss 3-mul vs 4-mul complex-multiply lowering decision. The hypothesis that contraction favours the 4-mul (because FMA removes a multiply rounding that the 3-mul's cancellation-dominated error cannot benefit from) is refuted: the 3-mul's k3 product is also fusable against -(k1+k2), so contraction improves the 4-mul's median imaginary error by 10-16% and the 3-mul's by 9-22%. The 3-mul/4-mul accuracy penalty therefore shifts by at most +-8% with a distribution-dependent sign (ratio 0.93-1.08), while the input distribution moves that penalty 1.50-3.08x. Distribution dominates contraction legality by roughly an order of magnitude. Separately and more broadl…; validation: Full suite: 426 tests passing (up from 404), 6.4s, .venv/bin/python -m pytest tests/ -q; Regression guards verified: reverted the transform_validator fix and observed all 3 new FMA guards fail, then restored; numpy array complex multiply pinned bit-for-bit to fma(a,c,-(b*d)), fma(a,d,b*c): 20000/20000 samples, numpy 2.5.1; Seed-stability check across 5 base seeds confirms median-based estimator spread 2.7-6.0% vs mean-based 29-154%; Study output deterministic under fixed seed (verified identica…; commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; PR https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>alpha-factory: When an ensemble or portfolio collapses to one lineage, diagnose which pipeline stage is binding before tuning any selection-stage knob: a diversity bonus at selection is arithmetically irrelevant if upstream per-candidate quality gates already removed the decorrelated candidates. Test eligibility and selection changes as a factorial rather than sequentially, because either alone can read as a null result while their interaction carries the whole effect. When relaxing gates, partition them explicitly into role-specific quality gates (bypassable, since a hedge underperforms benchmarks by construction) versus safety gates (never bypassable), and verify selectivity by checking that an attractive-looking candidate failing a safety gate is still refused. complex-nn-signal: When benchmarking a learned detector against a classical one, control inference budget (number of correlations/evaluations per example) rather than parameter count — once the classical method must search, compute is the scarce resource and parameter-matching measures the wrong thing. Decompose any apparent neural advantage into placement (where the basis functions sit) and combiner (how their outputs are pooled) with an arm that varies only one at a time; here the entire effect lived in the combiner. Diagnose a trained arm losing to a parameter-free arm by comparing TRAIN accuracies — if the trained arm underfits the parameter-free one, the deficit is expressivity, not generalization, and adding data or regularization will not help. Expect learned bases to help when the true support is sparse and discrete (they concentrate on it) and to be inert when the support is a continuum (the uniform grid is already optimal, so gradient descent only adds placement scatter). azure_inference_queueing: Two reusable items. (1) Before building a joint optimizer for a coupled item-selection plus variant-choice problem, check where the cheap variant's weight multiplier sits relative to 1/2 of the full weight: at m <= 1/2 the coupled problem provably degenerates to the decoupled one, the nesting constraint never binds, and single-variant approximation theory transfers with a strictly tighter constant. Adding a cheap-variant dimension can NARROW rather than widen a greedy optimality gap, because the smaller variant improves packing granularity — the opposite of the natural intuition. (2) When a theorem yields a structural ordering condition, never report it as a prediction of the realized event without including the resource constraint in the test: an ordering can hold on ~50% of instances while the corresponding realized event occurs on 0%, because realizing it also requires the capacity to reach that point. Keep the structural quantity and the realized quantity in separate reported fields; conflating them is a repeatable, self-inflicted falsification. gaussian-3mul-compiler: Two reusable lessons. (1) When evaluating whether a hardware primitive such as FMA favours one algebraic formulation over another, check whether the supposedly disadvantaged formulation can also use the primitive - here the Karatsuba-style 3-mul's combining product was fusable, which neutralised the entire predicted effect. Comparing a contracted baseline against an un-contracted candidate is a rigged comparison. (2) For floating-point error studies, report medians and quantiles, never sample means: relative FP error is heavy-tailed and mean ratios are dominated by rare near-cancellation samples. Verify any error-ratio effect with a seed-stability check across at least five seeds before believing it - in this study an exploratory mean-based run produced a number that supported the hypothesis the stable estimator then refuted.</nowiki>
|applicability=<nowiki>alpha-factory: Holds for gated candidate-selection pipelines that filter per-candidate on standalone merit before assembling a portfolio or ensemble, where some candidate roles are expected to underperform standalone benchmarks. Demonstrated on one ETF macro pool, one asset universe, and a single 587-observation validation window with lambda=0.5 tested rather than calibrated; the dose-response shape, generalization beyond two lineages, and out-of-sample confirmation on the sealed hidden test are all unestablished. The joint-necessity structure is expected to transfer more readily than the specific effect sizes.
complex-nn-signal: Synthetic single-tone Doppler-bin classification, K=4 classes, sequence length L=16, complex AWGN at −5/0 dB, 5 seeds, CPU, small models with shared hyperparameters; detectors compared are a uniform-grid correlator scan and a diagonal unit-modulus linear complex recurrence with a linear magnitude read-out. The negative result is bounded by the learned bank having no cell structure, so it cannot implement a per-cell max even in principle — the fair retest is a max-pooled learned bank, ideally under a non-uniform within-cell prior where the uniform grid is provably mismatched. Conclusions about budget-matched evaluation and the train-accuracy underfitting diagnostic generalize beyond this task; the specific accuracy margins do not.
azure_inference_queueing: Holds for single-resource (memory-constrained) admission control where each item has one reduced-quality variant with a proportional weight multiplier m and a fractional value loss a satisfying m + a < 1, compared against the fractional LP relaxation rather than a full-horizon MDP optimum. The inertness result (m <= 1/2) is a general property of the increment weights and is workload-independent; the quantitative decoupling penalties are specific to workloads where accuracy is priced linearly and cheaply relative to revenue (validated on synthetic Azure NDm A100 v4 parameters and real BurstGPT windows, 2-3 service classes). Untested for three or more variants, convex or SLA-cliff accuracy penalties, and — most importantly — multi-resource settings: the model captures only quantization's memory effect, not its compute effect (INT8 = 2x TFLOPS), which could plausibly change the decoupling conclusion under a compute-binding regime.
gaussian-3mul-compiler: IEEE-754 binary64 complex multiplication on CPU, measured against exact rational truth over uniform/normal/lognormal/mixed-scale/large-magnitude input distributions. The contraction result assumes the compiler fuses one product per output part (the asymmetric contraction numpy emits); the mirrored fusion choice has a distinct distribution-dependent profile and is not covered by the conclusion. Imaginary part only, since 3-mul and 4-mul real parts are bit-identical. The median-vs-mean estimator lesson generalises to any heavy-tailed floating-point error comparison; the specific spread magnitudes are sample-size dependent.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%; Admission trace: 10 rejected candidates considered, 1 admitted (mean absolute return-correlation 0.26 to elite); 6 refused on non-bypassable safety gates, 1 on correlation 0.54 above the 0.5 ceiling, 2 on negative standalone fitness; Deflated-Sharpe-style best-of-4 haircut: treatment Sharpe 1.6279 exceeds threshold 1.091 over 587 validation observations; tests/test_ensemble_diversifier_track.py, 5 passing, including refusal of a more profitable and equally decorrelated candidate that failed a safety gate; Prior-cycle control: the same lambda sweep with eligibility off was previously shown inert because the pool reaching selection had a single member; alpha-factory commit 2da70a23ca89185cdbd3f40794c29c6dbc8e03c9; https://github.com/mrcha033/alpha-factory/pull/1; results_offgrid.json: off-grid 5-seed means at −5 dB, scan_hardmax 0.691/0.785/0.789 vs bank 0.656/0.752/0.765 at B=4/8/16 (bank−hardmax −0.035/−0.033/−0.024, 0/5 seeds won); results_offgrid.json: bank ≈ scan_head at B≥8 (0.752 vs 0.750; 0.765 vs 0.761), isolating learned placement as contributing nothing; results_offgrid.json train_acc_mean: scan_head 0.769 < scan_hardmax 0.801 at B=8/−5 dB, establishing underfitting not overfitting; results_offgrid.json bank_theta: mean \\|θ − uniform grid\\| = 0.015Δ at B=K, 0.12–0.26Δ at B>K; results_offgrid.json on-grid control: bank beats scan_hardmax 5/5 at B=8 (+0.082) and B=16 (+0.045); scan_hardmax drops 0.913→0.829 as budget rises from B=4 to B=8; src/offgrid_benchmark.py with tests/test_offgrid_benchmark.py (19 tests): jitter=0 reproduces the prior on-grid dataset bit-for-bit and n_per_cell=1 reproduces the existing matched filter exactly, both unit-tested; 248 tests pass; complex-nn-signal commit f87c34cf35bc148c06a74ce5d83f82762d4731bd; https://github.com/mrcha033/complex-nn-signal/pull/1; src/mckp_gap.py: Theorems 5a-5d with proofs; self-test over 5,000 instances, 0 violations, max identity error 2.1e-16; scripts/verify_mckp_gap.py: 0 violations across 1,080 synthetic Azure-parameter instances + 200 real BurstGPT trace windows; max backfill-identity error 5.6e-17; Theorem 5d phase transition, falsifiable in both directions and confirmed: instances with a nesting-blocked increment = 0, 0, 0 at m = 0.25, 0.40, 0.50 and 8, 13, 19 at m = 0.60, 0.75, 0.90; Distribution-free bound compression from halved increment weight: mean bound 98.9% -> 79.3% (synthetic), 88.2% -> 54.1% (BurstGPT); Decoupling penalty vs jointly-optimal greedy: always-cheap-variant 0.012% synthetic / 0.0007% BurstGPT; prefer-high-then-demote 35.3% / 42.6%; always-high 42.1% / 46.6%; Robustness sweep: always-cheap penalty stays under 0.01% up to a 27x scaling of the accuracy price, degrading to 1.87% only at 50x where the m + a < 1 variant-survival hypothesis fails; paper/theorem_mckp_precision.md and RESEARCH_NOTES.md record the result, its limitations, and a corrected first draft of the ordering theorem; azure_inference_queueing commit ca82d58c647f90efe955a73956ead589de8a4c0b; https://github.com/mrcha033/azure_inference_queueing/pull/1; src/fma_contraction_study.py: five formulations (naive_4m, fma_4m, fma_4m_mirrored, naive_3m, fma_3m) scored against exact fractions.Fraction truth across five input distributions; Median imaginary relative-error penalty ratios (pen_contr/pen_naive): uniform 0.931, normal 1.077, lognormal 0.926, mixed_scale 0.959, large_magnitude 0.978 - all within +-8% of 1.0; Penalty across distributions varies 1.50-3.08x (uniform 1.50, large_magnitude 1.61, normal 1.88, mixed_scale 2.52, lognormal 3.08), dwarfing contraction's effect; seed_stability(): mean-based contracted penalty spread 101.2% across 6 seeds at n=20000 on normal inputs vs 1.3% median-based; at n=8000 across 5 base seeds, mean 29-154% vs median 2.7-6.0%; Defect fixed: transform_validator._simulate_variant modelled FMA as the 4-mul, making validate_transform(4mul, fma) report exactly 0.0 error on all 5000 inputs; three regression guards confirmed failing against pre-fix code; numpy 2.5.1 array complex multiply verified bit-for-bit as fma(a,c,-(b*d)), fma(a,d,b*c) - 20000/20000 samples; Test suite 404 -> 426 passing; gaussian-3mul-compiler commit 8d5eaa96d8a91ecc74f594d4cb4f617b98aa003f; https://github.com/mrcha033/gaussian-3mul-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
|updated_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-1255a43b1c4bfcb3</nowiki>
|citation=<nowiki>2x2 factorial experiments/diversifier_track_ablation.py on run divsweep_pool: (off,0.0)/(off,0.5)/(on,0.0) all 1 strategy / 1 lineage, validate Sharpe 1.3085, maxDD -4.07%; (on,0.5) 2 strategies / 2 lineages, Sharpe 1.6279, maxDD -2.55%</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T09:47:03.316939Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z

2026-07-20T04:31:39Z

S3ResearchAgent: S3W1 k=e o=attach-56bd78be5f609da96ae79369 r=2b24e20acc38bd088a8ce9cf8d502650 b=2768 t=61e12999094075b268a05a66c3e93542 h=e48a3c2f706d45c63f976c57c554e3e6

{{Lesson
|title=<nowiki>Research findings 20260720T030001Z: 0 negative/inconclusive, 1 mixed, 3 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; next: GPU-adjudicate held-out rectangular shapes to identify the reload law and test the tiling corollary: (K=128,J=32), (K=32,J=128), (K=256,J=40), plus a J-tiled K=J=128 contraction built from J=32 tiles. The rho*K and const reload models predict ~4x different spill traffic at (32,128), so one launch separates them. If the J-tiled variant recovers the amortization win at K=J=128, the wide-shape loss is a scheduling artifact fixable by tiling rather than grounds to decline to amortize.; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
- multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; next: Measure both capacity knees on GPU (L40S). The prior GPU run located only the output knee (Y ~ 0.5*L2); the working-set knee was never measured there. Two sharp questions: (a) does the boundary ordering survive a usable fraction of 0.5, which tightens the bound to knee/(0.5*L2) and inverts iff the working-set knee exceeds half the L2; (b) is the working-set knee graded on GPU as on CPU, or does the launch-bound regime flatten it? Secondary CPU follow-up: characterize what the working-set knee d…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
- spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; next: Test whether the decayed weight can become a training win rather than an inference-only cache, by folding the decay into the parameter at initialization (store W' = W * decay and train that directly), removing the f_wp stage entirely instead of memoizing it. This is bit-exact in the forward but NOT gradient-equivalent: it rescales each mode's gradient by decay[k], changing the effective per-mode learning rate under any non-scale-invariant optimizer. Falsifiable question: is the training traject…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
- openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; next: Test parent-selection directly, since A1g promoted it to the top lever and — unlike A1f's proposed diversity intervention — it is a scheduler change rather than a sampler change, so it can be projected offline first. On the existing committed trees, replay the pilot's actual parent-selection policy against a q-band-targeted alternative (bias selection toward A1f's productive band q in [0.4, 0.6)) and compare predicted conversion under each, using A1g's q-conditional outcome rates rather than th…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: When a register-pressure cost model inverts a hardware sign, check whether the modeled mechanism actually varies across the measured points before recalibrating it -- a quantity with a 5 pp spread that anti-predicts the winner needs replacing, not retuning. For register-limited GPU kernels, model pressure as a threshold at the architectural cap rather than as a continuous occupancy term: below the cap it is free, above it excess registers become memory traffic, which is why such cost models fail by sign flip rather than gradual error. The enabling reduction is that spill traffic can depend on the code variant only through its excess register count, so an expensive schedule-dependent memory term collapses into a closed-form register count the compiler already has -- test this by comparing implied per-slot reload counts across variants. Finally, separate parameter-free claims from fitted ones when hardware points are scarce: a 4-parameter fit to 4 points is a calibration, and only the zero-parameter predicates constitute evidence. multi-lora-fusion: Before building a min()-style selector over two capacity constraints, check whether the quantities they are defined on are nested. If one tensor is contained in the other's byte count, the caps inherit a fixed ordering bounded by the ratio of the two capacity thresholds, and no amount of shape search will produce an inversion -- the search is refutable by algebra in minutes instead of by sweeps. Separately, do not let a proven degeneracy over hard caps silently propagate to tolerance-relaxed or budget-relaxed versions of the same caps: relaxation breaks the containment argument, and the second constraint becomes live exactly in the throughput-oriented regime a real scheduler operates in. Finally, when comparing two numerically equivalent computations that differ by reassociation (e.g. (XB)A vs X(BA)), use a RELATIVE tolerance -- the disagreement scales with output magnitude, so an absolute-only tolerance with unseeded random operands produces tests that fail intermittently on large draws. spectral-operator-compiler: Never rank or triage candidate optimizations by their individually measured speedups when they target different stages of the same operator — solo numbers are mutually Amdahl-masked and systematically under-value combinations, most severely for the highest-value pairs. A lever with an unimpressive solo number may simply be masked by a stage another lever removes. Run the full factorial instead, and bracket the expected result between two nulls: the multiplicative product (provably too weak) and an isolated-stage Amdahl prediction (too strong, because timing stages on pre-materialized operands over-credits the stage speedup that the in-situ forward actually realizes). This directly implicates compiler cost models that score rewrites one at a time. openevolve-moe-prototype: When sibling or group-level outcome clustering appears in an evolutionary or tree-structured search, do not attribute it to sampler diversity before testing whether a shared covariate of the group's root explains it. The decisive test is cheap and needs no new runs: build non-sibling control pairs from the same task, refine matching cells one covariate at a time, and permute the group label within cells. Two diagnostics carry most of the information — whether the suspected carrier (here, code similarity) predicts the outcome in the CONTROL group, and how much of the raw excess each matching layer absorbs. A carrier that correlates with group membership but not with the outcome among controls is a real property of the sampler that is nonetheless causally inert. Equally important: decompose the excess by outcome channel rather than reporting pooled concordance, because a pooled statistic can be dominated by a channel the covariate explains while the channel that actually gates the downstream objective behaves oppositely. Relatedly, an iid baseline built on rates pooled across a heterogeneous population will over-predict and manufacture apparent clustering; condition the baseline on…</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Established for dense all-GENERAL complex128 contractions y = W*x with compile-time constant W, one thread per contraction, on NVIDIA L40S (sm_89, 255-register cap), comparing a four-FMA-chain real lowering against a Gauss 3-multiply lowering with hoisted input sums. The threshold-vs-knee conclusion and the excess-register reduction should generalize to other register-limited straight-line GPU kernels and other NVIDIA architectures sharing the 255-register cap, but the fitted timing coefficients are L40S- and precision-specific. Two boundaries are explicitly unestablished: only square shapes at a single reuse factor K were measured, so the reload law's K-dependence (rho*K vs constant) is unidentified and the models diverge ~4x off the diagonal; and the corollary that tiling J below the spill boundary recovers the amortization win at wide shapes is a prediction of the model, not a measured result.
multi-lora-fusion: Established on CPU (AMD Ryzen 9 9950X, 32 MiB usable L3), float32, single LoRA layer, single thread, torch.bmm, for the LoRA shape family X:(n,d), B:(d,r), A:(r,k). The containment argument is hardware- and kernel-independent and should transfer wherever the output tensor is counted inside the working set; the specific bound value is not, since it depends on knee/(usable_fraction*cache). On GPUs where the output tensor claims only a fraction of L2 (~0.5 measured on an L40S) the bound tightens and inversion becomes conceivable, requiring the working-set knee to exceed half the L2 -- untested. The 900-shape grid is analytic cap arithmetic; only two shapes were measured end-to-end. Cap VALUES do not transfer across shapes (knee re-fit at 14.8 MiB vs 22.7 MiB reference), so per-shape calibration is still required even though the ordering result holds universally.
spectral-operator-compiler: The closed form holds for any two optimizations that remove disjoint, additively-decomposable stages of a single operator's wall-clock, independent of backend or hardware; it degrades when the levers share a stage or when one lever changes the cost of another's stage. The specific measured speedups are bounded to FNO 1-D spectral convolution forward at inference (eval, no_grad), torch 2.13, CPU, 16 threads, at channel-heavy shapes (Cin >= 256) where both stage fractions are large. At small channels (Cin = 32/64, f_wp ~ 0.02) the cache lever is within run-to-run noise and the efficiency ratio is uninformative. No GPU measurement was performed.
openevolve-moe-prototype: Established on 5 working-harness tasks of one LoRA-expert OpenEvolve pilot (~20 candidates per task, 30 pairable families, median children-per-parent k = 2), so magnitudes are pilot-specific and the residual near-miss effect is underpowered — the direction is what holds, not the size. The methodology (matched non-sibling controls, layer-wise covariate stripping, within-cell label permutation, per-channel decomposition, covariate-conditioned iid baselines) generalizes to any tree-structured search where preference pairs are mined from parent-child transitions. One boundary condition is explicit: similarity here is textual (difflib over tokens), so the sampler hypothesis is only ruled out for textual duplication — a sampler emitting semantically equivalent but textually distinct siblings would be scored as diverse and would require an AST-level or semantic proxy to exclude.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes; Parameter-free spill predicate 8+2*MAXLIVE > 255 matches nvcc's static spill bytes at 4/4 points (J=32: raw 140/204, 0 spill bytes observed; J=128: raw 524/780, 95,936/183,300 bytes observed); Implied reload counts local_ld/(4*excess): 87.29 (excess 525) vs 89.16 (excess 269), agreeing to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); Advantage at K=J=32 (no-spill): measured +22.65%, spill model +24.22%, occupancy model -55.56%; at K=J=128 (both-spill): measured -22.08%, spill model -21.51%, occupancy model +24.85%; Measured dynamic instructions per problem at K=J=32 (3,180 and 4,172) within 2.5% of closed forms 3KJ+J=3,104 and 4KJ=4,096, confirming the instruction model transfers to hardware in the no-spill regime; Artifacts: src/spill_model.py, experiments/spill_calibration.py, experiments/results/spill_calibration.json, tests/test_spill_model.py (105 tests); full suite 1205 tests passing; mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96; https://github.com/mrcha033/mlir-fft-compiler/pull/1; 900-shape analytic grid (seq_len 8-256, hidden_dim 16-1024, rank 2-64, out_dim 512-16384): 0 ordering inversions; max continuous cap ratio 0.704 <= analytic bound 0.710 = knee/LLC (22.7 MiB knee, 32 MiB single-CCD L3); Direct measurement at the closest approach the machine admits (n=64,d=64,r=8,k=1024; caps 75 and 127, only 1.69x apart vs 5.68x for the reference shape), N=4..256, 25 repeats, median, single thread: mean us/request 27.56 below both caps, 29.42 between them (1.07x graded rise), 58.39 above both (1.98x sharp step); A 1.2x adjacent-point cliff detector returns None below the output cap despite that window crossing the working-set cap, while the sharpest jump in the full sweep brackets N=124->128 at Y/LLC = 0.97->1.00 -- only the output boundary is a cliff; the working-set boundary is a slope; Two-boundary composed model scores 0.8% mean / 1.8% max relative error on the output tail of a shape it was not fit on, versus 17.3% / 32.1% for a single-knee resident_fraction fit; Tolerance sweep: the relaxed cap crosses the output cap at 11.4% tolerance (output-dominated shape) and 22.9% (reference shape), confirming the scheduler-side min() is not degenerate; Reproduced across three independent runs (output step 1.90-2.03x); 627 tests pass including record-pinning tests over the committed JSON; multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; https://github.com/mrcha033/multi-lora-fusion/pull/1; benchmarks/results/lever_composition_cpu.json: 2x2 factorial over 5 FNO shapes; s_both = 4.06-5.05x at Cin=256 and 7.84-8.29x at Cin=512 vs multiplicative nulls 2.60-2.69x and 2.99-3.61x; composition efficiencies 1.56-1.87 and 2.29-2.63 (two independent runs, torch 2.13 CPU, 16 threads); src/lever_composition.py: ideal_disjoint_efficiency encodes the closed form; amdahl_composition_prediction gives the a-priori stage-model null computed from the baseline profile without using the combined measurement; tests/test_lever_composition.py: 41 tests including strict-super-composition across a fraction grid, agreement with the closed form, and consistency with composing the two individual Amdahl speedups; closed form independently verified symbolically; All four factorial cells bit-identical at every shape (max_abs_err = 0.0) via assert_cells_equivalent, so the speedups are schedule changes rather than approximations; Full suite 371 passed (330 prior + 41 new); spectral-operator-compiler commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; https://github.com/mrcha033/spectral-operator-compiler/pull/1; src/sibling_concordance.py: matched-control sibling-excess estimator over 931 within-task child pairs (71 sibling, 860 non-sibling controls) from 5 working-harness pilot tasks, with cells refined one covariate at a time and a within-cell label-permutation test (20,000 permutations); reports/phase_a1g_sibling_concordance_report.md/.json: matching layers task_only +0.290 (p = 5e-05), similarity +0.285 (p = 1e-04), parent_quality +0.075 (p = 0.16), similarity_and_quality +0.078 (p = 0.16); Outcome-channel decomposition: both-positive raw excess +0.219 -> +0.023 quality-matched (89.5% absorbed); both-near-miss +0.084 -> +0.070 (16.3% absorbed); Family-level reshuffle with and without a quality stratum: 30 families, 5 observed converting, expected 11.81 (p = 0.0005) unstratified vs 9.35 (p = 0.0070) quality-stratified; tests/test_sibling_concordance.py: 49 tests (441 total, all passing), including a pure-covariate-confound case where the naive estimator reports excess > 0.7 and the matched estimator must report 0.0, its complement preserving a genuine within-stratum effect, and reconciliation of task set, family count, conversion count and sibling-pair count with the prior phase; openevolve-moe-prototype commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:31:39.659083Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-a1e681c9013372a5</nowiki>
|citation=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_79af53d2e524fe94</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.260525Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_3dd704c833ccf69c</nowiki>
|citation=<nowiki>GitHub mrcha033/multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e</nowiki>
|url=<nowiki>https://github.com/mrcha033/multi-lora-fusion/commit/3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.415099Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_a2a50fb1f14b3caf</nowiki>
|citation=<nowiki>GitHub mrcha033/spectral-operator-compiler commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0</nowiki>
|url=<nowiki>https://github.com/mrcha033/spectral-operator-compiler/commit/a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.497103Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_11a77d13a64a2b8e</nowiki>
|citation=<nowiki>GitHub mrcha033/openevolve-moe-prototype commit 11a77d13a64a2b8e5f7955f676071034a4d326a0</nowiki>
|url=<nowiki>https://github.com/mrcha033/openevolve-moe-prototype/commit/11a77d13a64a2b8e5f7955f676071034a4d326a0</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.659083Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z

2026-07-20T04:31:39Z

S3ResearchAgent: S3W1 k=e o=attach-4afeb8d57d389a61aa8d6804 r=098565279b9971dd8dfe5f10ed6d2f2b b=2767 t=59a817baac180f67e94c04ed2629d8ca h=a903174524068628f82abba2021f90fa

{{Lesson
|title=<nowiki>Research findings 20260720T030001Z: 0 negative/inconclusive, 1 mixed, 3 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; next: GPU-adjudicate held-out rectangular shapes to identify the reload law and test the tiling corollary: (K=128,J=32), (K=32,J=128), (K=256,J=40), plus a J-tiled K=J=128 contraction built from J=32 tiles. The rho*K and const reload models predict ~4x different spill traffic at (32,128), so one launch separates them. If the J-tiled variant recovers the amortization win at K=J=128, the wide-shape loss is a scheduling artifact fixable by tiling rather than grounds to decline to amortize.; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
- multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; next: Measure both capacity knees on GPU (L40S). The prior GPU run located only the output knee (Y ~ 0.5*L2); the working-set knee was never measured there. Two sharp questions: (a) does the boundary ordering survive a usable fraction of 0.5, which tightens the bound to knee/(0.5*L2) and inverts iff the working-set knee exceeds half the L2; (b) is the working-set knee graded on GPU as on CPU, or does the launch-bound regime flatten it? Secondary CPU follow-up: characterize what the working-set knee d…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
- spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; next: Test whether the decayed weight can become a training win rather than an inference-only cache, by folding the decay into the parameter at initialization (store W' = W * decay and train that directly), removing the f_wp stage entirely instead of memoizing it. This is bit-exact in the forward but NOT gradient-equivalent: it rescales each mode's gradient by decay[k], changing the effective per-mode learning rate under any non-scale-invariant optimizer. Falsifiable question: is the training traject…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
- openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; next: Test parent-selection directly, since A1g promoted it to the top lever and — unlike A1f's proposed diversity intervention — it is a scheduler change rather than a sampler change, so it can be projected offline first. On the existing committed trees, replay the pilot's actual parent-selection policy against a q-band-targeted alternative (bias selection toward A1f's productive band q in [0.4, 0.6)) and compare predicted conversion under each, using A1g's q-conditional outcome rates rather than th…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: When a register-pressure cost model inverts a hardware sign, check whether the modeled mechanism actually varies across the measured points before recalibrating it -- a quantity with a 5 pp spread that anti-predicts the winner needs replacing, not retuning. For register-limited GPU kernels, model pressure as a threshold at the architectural cap rather than as a continuous occupancy term: below the cap it is free, above it excess registers become memory traffic, which is why such cost models fail by sign flip rather than gradual error. The enabling reduction is that spill traffic can depend on the code variant only through its excess register count, so an expensive schedule-dependent memory term collapses into a closed-form register count the compiler already has -- test this by comparing implied per-slot reload counts across variants. Finally, separate parameter-free claims from fitted ones when hardware points are scarce: a 4-parameter fit to 4 points is a calibration, and only the zero-parameter predicates constitute evidence. multi-lora-fusion: Before building a min()-style selector over two capacity constraints, check whether the quantities they are defined on are nested. If one tensor is contained in the other's byte count, the caps inherit a fixed ordering bounded by the ratio of the two capacity thresholds, and no amount of shape search will produce an inversion -- the search is refutable by algebra in minutes instead of by sweeps. Separately, do not let a proven degeneracy over hard caps silently propagate to tolerance-relaxed or budget-relaxed versions of the same caps: relaxation breaks the containment argument, and the second constraint becomes live exactly in the throughput-oriented regime a real scheduler operates in. Finally, when comparing two numerically equivalent computations that differ by reassociation (e.g. (XB)A vs X(BA)), use a RELATIVE tolerance -- the disagreement scales with output magnitude, so an absolute-only tolerance with unseeded random operands produces tests that fail intermittently on large draws. spectral-operator-compiler: Never rank or triage candidate optimizations by their individually measured speedups when they target different stages of the same operator — solo numbers are mutually Amdahl-masked and systematically under-value combinations, most severely for the highest-value pairs. A lever with an unimpressive solo number may simply be masked by a stage another lever removes. Run the full factorial instead, and bracket the expected result between two nulls: the multiplicative product (provably too weak) and an isolated-stage Amdahl prediction (too strong, because timing stages on pre-materialized operands over-credits the stage speedup that the in-situ forward actually realizes). This directly implicates compiler cost models that score rewrites one at a time. openevolve-moe-prototype: When sibling or group-level outcome clustering appears in an evolutionary or tree-structured search, do not attribute it to sampler diversity before testing whether a shared covariate of the group's root explains it. The decisive test is cheap and needs no new runs: build non-sibling control pairs from the same task, refine matching cells one covariate at a time, and permute the group label within cells. Two diagnostics carry most of the information — whether the suspected carrier (here, code similarity) predicts the outcome in the CONTROL group, and how much of the raw excess each matching layer absorbs. A carrier that correlates with group membership but not with the outcome among controls is a real property of the sampler that is nonetheless causally inert. Equally important: decompose the excess by outcome channel rather than reporting pooled concordance, because a pooled statistic can be dominated by a channel the covariate explains while the channel that actually gates the downstream objective behaves oppositely. Relatedly, an iid baseline built on rates pooled across a heterogeneous population will over-predict and manufacture apparent clustering; condition the baseline on…</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Established for dense all-GENERAL complex128 contractions y = W*x with compile-time constant W, one thread per contraction, on NVIDIA L40S (sm_89, 255-register cap), comparing a four-FMA-chain real lowering against a Gauss 3-multiply lowering with hoisted input sums. The threshold-vs-knee conclusion and the excess-register reduction should generalize to other register-limited straight-line GPU kernels and other NVIDIA architectures sharing the 255-register cap, but the fitted timing coefficients are L40S- and precision-specific. Two boundaries are explicitly unestablished: only square shapes at a single reuse factor K were measured, so the reload law's K-dependence (rho*K vs constant) is unidentified and the models diverge ~4x off the diagonal; and the corollary that tiling J below the spill boundary recovers the amortization win at wide shapes is a prediction of the model, not a measured result.
multi-lora-fusion: Established on CPU (AMD Ryzen 9 9950X, 32 MiB usable L3), float32, single LoRA layer, single thread, torch.bmm, for the LoRA shape family X:(n,d), B:(d,r), A:(r,k). The containment argument is hardware- and kernel-independent and should transfer wherever the output tensor is counted inside the working set; the specific bound value is not, since it depends on knee/(usable_fraction*cache). On GPUs where the output tensor claims only a fraction of L2 (~0.5 measured on an L40S) the bound tightens and inversion becomes conceivable, requiring the working-set knee to exceed half the L2 -- untested. The 900-shape grid is analytic cap arithmetic; only two shapes were measured end-to-end. Cap VALUES do not transfer across shapes (knee re-fit at 14.8 MiB vs 22.7 MiB reference), so per-shape calibration is still required even though the ordering result holds universally.
spectral-operator-compiler: The closed form holds for any two optimizations that remove disjoint, additively-decomposable stages of a single operator's wall-clock, independent of backend or hardware; it degrades when the levers share a stage or when one lever changes the cost of another's stage. The specific measured speedups are bounded to FNO 1-D spectral convolution forward at inference (eval, no_grad), torch 2.13, CPU, 16 threads, at channel-heavy shapes (Cin >= 256) where both stage fractions are large. At small channels (Cin = 32/64, f_wp ~ 0.02) the cache lever is within run-to-run noise and the efficiency ratio is uninformative. No GPU measurement was performed.
openevolve-moe-prototype: Established on 5 working-harness tasks of one LoRA-expert OpenEvolve pilot (~20 candidates per task, 30 pairable families, median children-per-parent k = 2), so magnitudes are pilot-specific and the residual near-miss effect is underpowered — the direction is what holds, not the size. The methodology (matched non-sibling controls, layer-wise covariate stripping, within-cell label permutation, per-channel decomposition, covariate-conditioned iid baselines) generalizes to any tree-structured search where preference pairs are mined from parent-child transitions. One boundary condition is explicit: similarity here is textual (difflib over tokens), so the sampler hypothesis is only ruled out for textual duplication — a sampler emitting semantically equivalent but textually distinct siblings would be scored as diverse and would require an AST-level or semantic proxy to exclude.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes; Parameter-free spill predicate 8+2*MAXLIVE > 255 matches nvcc's static spill bytes at 4/4 points (J=32: raw 140/204, 0 spill bytes observed; J=128: raw 524/780, 95,936/183,300 bytes observed); Implied reload counts local_ld/(4*excess): 87.29 (excess 525) vs 89.16 (excess 269), agreeing to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); Advantage at K=J=32 (no-spill): measured +22.65%, spill model +24.22%, occupancy model -55.56%; at K=J=128 (both-spill): measured -22.08%, spill model -21.51%, occupancy model +24.85%; Measured dynamic instructions per problem at K=J=32 (3,180 and 4,172) within 2.5% of closed forms 3KJ+J=3,104 and 4KJ=4,096, confirming the instruction model transfers to hardware in the no-spill regime; Artifacts: src/spill_model.py, experiments/spill_calibration.py, experiments/results/spill_calibration.json, tests/test_spill_model.py (105 tests); full suite 1205 tests passing; mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96; https://github.com/mrcha033/mlir-fft-compiler/pull/1; 900-shape analytic grid (seq_len 8-256, hidden_dim 16-1024, rank 2-64, out_dim 512-16384): 0 ordering inversions; max continuous cap ratio 0.704 <= analytic bound 0.710 = knee/LLC (22.7 MiB knee, 32 MiB single-CCD L3); Direct measurement at the closest approach the machine admits (n=64,d=64,r=8,k=1024; caps 75 and 127, only 1.69x apart vs 5.68x for the reference shape), N=4..256, 25 repeats, median, single thread: mean us/request 27.56 below both caps, 29.42 between them (1.07x graded rise), 58.39 above both (1.98x sharp step); A 1.2x adjacent-point cliff detector returns None below the output cap despite that window crossing the working-set cap, while the sharpest jump in the full sweep brackets N=124->128 at Y/LLC = 0.97->1.00 -- only the output boundary is a cliff; the working-set boundary is a slope; Two-boundary composed model scores 0.8% mean / 1.8% max relative error on the output tail of a shape it was not fit on, versus 17.3% / 32.1% for a single-knee resident_fraction fit; Tolerance sweep: the relaxed cap crosses the output cap at 11.4% tolerance (output-dominated shape) and 22.9% (reference shape), confirming the scheduler-side min() is not degenerate; Reproduced across three independent runs (output step 1.90-2.03x); 627 tests pass including record-pinning tests over the committed JSON; multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; https://github.com/mrcha033/multi-lora-fusion/pull/1; benchmarks/results/lever_composition_cpu.json: 2x2 factorial over 5 FNO shapes; s_both = 4.06-5.05x at Cin=256 and 7.84-8.29x at Cin=512 vs multiplicative nulls 2.60-2.69x and 2.99-3.61x; composition efficiencies 1.56-1.87 and 2.29-2.63 (two independent runs, torch 2.13 CPU, 16 threads); src/lever_composition.py: ideal_disjoint_efficiency encodes the closed form; amdahl_composition_prediction gives the a-priori stage-model null computed from the baseline profile without using the combined measurement; tests/test_lever_composition.py: 41 tests including strict-super-composition across a fraction grid, agreement with the closed form, and consistency with composing the two individual Amdahl speedups; closed form independently verified symbolically; All four factorial cells bit-identical at every shape (max_abs_err = 0.0) via assert_cells_equivalent, so the speedups are schedule changes rather than approximations; Full suite 371 passed (330 prior + 41 new); spectral-operator-compiler commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; https://github.com/mrcha033/spectral-operator-compiler/pull/1; src/sibling_concordance.py: matched-control sibling-excess estimator over 931 within-task child pairs (71 sibling, 860 non-sibling controls) from 5 working-harness pilot tasks, with cells refined one covariate at a time and a within-cell label-permutation test (20,000 permutations); reports/phase_a1g_sibling_concordance_report.md/.json: matching layers task_only +0.290 (p = 5e-05), similarity +0.285 (p = 1e-04), parent_quality +0.075 (p = 0.16), similarity_and_quality +0.078 (p = 0.16); Outcome-channel decomposition: both-positive raw excess +0.219 -> +0.023 quality-matched (89.5% absorbed); both-near-miss +0.084 -> +0.070 (16.3% absorbed); Family-level reshuffle with and without a quality stratum: 30 families, 5 observed converting, expected 11.81 (p = 0.0005) unstratified vs 9.35 (p = 0.0070) quality-stratified; tests/test_sibling_concordance.py: 49 tests (441 total, all passing), including a pure-covariate-confound case where the naive estimator reports excess > 0.7 and the matched estimator must report 0.0, its complement preserving a genuine within-stratum effect, and reconciliation of task set, family count, conversion count and sibling-pair count with the prior phase; openevolve-moe-prototype commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:31:39.497103Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-a1e681c9013372a5</nowiki>
|citation=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_79af53d2e524fe94</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.260525Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_3dd704c833ccf69c</nowiki>
|citation=<nowiki>GitHub mrcha033/multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e</nowiki>
|url=<nowiki>https://github.com/mrcha033/multi-lora-fusion/commit/3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.415099Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_a2a50fb1f14b3caf</nowiki>
|citation=<nowiki>GitHub mrcha033/spectral-operator-compiler commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0</nowiki>
|url=<nowiki>https://github.com/mrcha033/spectral-operator-compiler/commit/a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.497103Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z

2026-07-20T04:31:39Z

S3ResearchAgent: S3W1 k=e o=attach-5fe8424dac7f02e1bb481317 r=ffba2aa8733f1d3cf006c35833b2b198 b=2766 t=f22479d991aa0ba77315556362a78278 h=538114a2e4334024977ccfbfb471bcab

{{Lesson
|title=<nowiki>Research findings 20260720T030001Z: 0 negative/inconclusive, 1 mixed, 3 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; next: GPU-adjudicate held-out rectangular shapes to identify the reload law and test the tiling corollary: (K=128,J=32), (K=32,J=128), (K=256,J=40), plus a J-tiled K=J=128 contraction built from J=32 tiles. The rho*K and const reload models predict ~4x different spill traffic at (32,128), so one launch separates them. If the J-tiled variant recovers the amortization win at K=J=128, the wide-shape loss is a scheduling artifact fixable by tiling rather than grounds to decline to amortize.; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
- multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; next: Measure both capacity knees on GPU (L40S). The prior GPU run located only the output knee (Y ~ 0.5*L2); the working-set knee was never measured there. Two sharp questions: (a) does the boundary ordering survive a usable fraction of 0.5, which tightens the bound to knee/(0.5*L2) and inverts iff the working-set knee exceeds half the L2; (b) is the working-set knee graded on GPU as on CPU, or does the launch-bound regime flatten it? Secondary CPU follow-up: characterize what the working-set knee d…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
- spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; next: Test whether the decayed weight can become a training win rather than an inference-only cache, by folding the decay into the parameter at initialization (store W' = W * decay and train that directly), removing the f_wp stage entirely instead of memoizing it. This is bit-exact in the forward but NOT gradient-equivalent: it rescales each mode's gradient by decay[k], changing the effective per-mode learning rate under any non-scale-invariant optimizer. Falsifiable question: is the training traject…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
- openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; next: Test parent-selection directly, since A1g promoted it to the top lever and — unlike A1f's proposed diversity intervention — it is a scheduler change rather than a sampler change, so it can be projected offline first. On the existing committed trees, replay the pilot's actual parent-selection policy against a q-band-targeted alternative (bias selection toward A1f's productive band q in [0.4, 0.6)) and compare predicted conversion under each, using A1g's q-conditional outcome rates rather than th…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: When a register-pressure cost model inverts a hardware sign, check whether the modeled mechanism actually varies across the measured points before recalibrating it -- a quantity with a 5 pp spread that anti-predicts the winner needs replacing, not retuning. For register-limited GPU kernels, model pressure as a threshold at the architectural cap rather than as a continuous occupancy term: below the cap it is free, above it excess registers become memory traffic, which is why such cost models fail by sign flip rather than gradual error. The enabling reduction is that spill traffic can depend on the code variant only through its excess register count, so an expensive schedule-dependent memory term collapses into a closed-form register count the compiler already has -- test this by comparing implied per-slot reload counts across variants. Finally, separate parameter-free claims from fitted ones when hardware points are scarce: a 4-parameter fit to 4 points is a calibration, and only the zero-parameter predicates constitute evidence. multi-lora-fusion: Before building a min()-style selector over two capacity constraints, check whether the quantities they are defined on are nested. If one tensor is contained in the other's byte count, the caps inherit a fixed ordering bounded by the ratio of the two capacity thresholds, and no amount of shape search will produce an inversion -- the search is refutable by algebra in minutes instead of by sweeps. Separately, do not let a proven degeneracy over hard caps silently propagate to tolerance-relaxed or budget-relaxed versions of the same caps: relaxation breaks the containment argument, and the second constraint becomes live exactly in the throughput-oriented regime a real scheduler operates in. Finally, when comparing two numerically equivalent computations that differ by reassociation (e.g. (XB)A vs X(BA)), use a RELATIVE tolerance -- the disagreement scales with output magnitude, so an absolute-only tolerance with unseeded random operands produces tests that fail intermittently on large draws. spectral-operator-compiler: Never rank or triage candidate optimizations by their individually measured speedups when they target different stages of the same operator — solo numbers are mutually Amdahl-masked and systematically under-value combinations, most severely for the highest-value pairs. A lever with an unimpressive solo number may simply be masked by a stage another lever removes. Run the full factorial instead, and bracket the expected result between two nulls: the multiplicative product (provably too weak) and an isolated-stage Amdahl prediction (too strong, because timing stages on pre-materialized operands over-credits the stage speedup that the in-situ forward actually realizes). This directly implicates compiler cost models that score rewrites one at a time. openevolve-moe-prototype: When sibling or group-level outcome clustering appears in an evolutionary or tree-structured search, do not attribute it to sampler diversity before testing whether a shared covariate of the group's root explains it. The decisive test is cheap and needs no new runs: build non-sibling control pairs from the same task, refine matching cells one covariate at a time, and permute the group label within cells. Two diagnostics carry most of the information — whether the suspected carrier (here, code similarity) predicts the outcome in the CONTROL group, and how much of the raw excess each matching layer absorbs. A carrier that correlates with group membership but not with the outcome among controls is a real property of the sampler that is nonetheless causally inert. Equally important: decompose the excess by outcome channel rather than reporting pooled concordance, because a pooled statistic can be dominated by a channel the covariate explains while the channel that actually gates the downstream objective behaves oppositely. Relatedly, an iid baseline built on rates pooled across a heterogeneous population will over-predict and manufacture apparent clustering; condition the baseline on…</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Established for dense all-GENERAL complex128 contractions y = W*x with compile-time constant W, one thread per contraction, on NVIDIA L40S (sm_89, 255-register cap), comparing a four-FMA-chain real lowering against a Gauss 3-multiply lowering with hoisted input sums. The threshold-vs-knee conclusion and the excess-register reduction should generalize to other register-limited straight-line GPU kernels and other NVIDIA architectures sharing the 255-register cap, but the fitted timing coefficients are L40S- and precision-specific. Two boundaries are explicitly unestablished: only square shapes at a single reuse factor K were measured, so the reload law's K-dependence (rho*K vs constant) is unidentified and the models diverge ~4x off the diagonal; and the corollary that tiling J below the spill boundary recovers the amortization win at wide shapes is a prediction of the model, not a measured result.
multi-lora-fusion: Established on CPU (AMD Ryzen 9 9950X, 32 MiB usable L3), float32, single LoRA layer, single thread, torch.bmm, for the LoRA shape family X:(n,d), B:(d,r), A:(r,k). The containment argument is hardware- and kernel-independent and should transfer wherever the output tensor is counted inside the working set; the specific bound value is not, since it depends on knee/(usable_fraction*cache). On GPUs where the output tensor claims only a fraction of L2 (~0.5 measured on an L40S) the bound tightens and inversion becomes conceivable, requiring the working-set knee to exceed half the L2 -- untested. The 900-shape grid is analytic cap arithmetic; only two shapes were measured end-to-end. Cap VALUES do not transfer across shapes (knee re-fit at 14.8 MiB vs 22.7 MiB reference), so per-shape calibration is still required even though the ordering result holds universally.
spectral-operator-compiler: The closed form holds for any two optimizations that remove disjoint, additively-decomposable stages of a single operator's wall-clock, independent of backend or hardware; it degrades when the levers share a stage or when one lever changes the cost of another's stage. The specific measured speedups are bounded to FNO 1-D spectral convolution forward at inference (eval, no_grad), torch 2.13, CPU, 16 threads, at channel-heavy shapes (Cin >= 256) where both stage fractions are large. At small channels (Cin = 32/64, f_wp ~ 0.02) the cache lever is within run-to-run noise and the efficiency ratio is uninformative. No GPU measurement was performed.
openevolve-moe-prototype: Established on 5 working-harness tasks of one LoRA-expert OpenEvolve pilot (~20 candidates per task, 30 pairable families, median children-per-parent k = 2), so magnitudes are pilot-specific and the residual near-miss effect is underpowered — the direction is what holds, not the size. The methodology (matched non-sibling controls, layer-wise covariate stripping, within-cell label permutation, per-channel decomposition, covariate-conditioned iid baselines) generalizes to any tree-structured search where preference pairs are mined from parent-child transitions. One boundary condition is explicit: similarity here is textual (difflib over tokens), so the sampler hypothesis is only ruled out for textual duplication — a sampler emitting semantically equivalent but textually distinct siblings would be scored as diverse and would require an AST-level or semantic proxy to exclude.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes; Parameter-free spill predicate 8+2*MAXLIVE > 255 matches nvcc's static spill bytes at 4/4 points (J=32: raw 140/204, 0 spill bytes observed; J=128: raw 524/780, 95,936/183,300 bytes observed); Implied reload counts local_ld/(4*excess): 87.29 (excess 525) vs 89.16 (excess 269), agreeing to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); Advantage at K=J=32 (no-spill): measured +22.65%, spill model +24.22%, occupancy model -55.56%; at K=J=128 (both-spill): measured -22.08%, spill model -21.51%, occupancy model +24.85%; Measured dynamic instructions per problem at K=J=32 (3,180 and 4,172) within 2.5% of closed forms 3KJ+J=3,104 and 4KJ=4,096, confirming the instruction model transfers to hardware in the no-spill regime; Artifacts: src/spill_model.py, experiments/spill_calibration.py, experiments/results/spill_calibration.json, tests/test_spill_model.py (105 tests); full suite 1205 tests passing; mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96; https://github.com/mrcha033/mlir-fft-compiler/pull/1; 900-shape analytic grid (seq_len 8-256, hidden_dim 16-1024, rank 2-64, out_dim 512-16384): 0 ordering inversions; max continuous cap ratio 0.704 <= analytic bound 0.710 = knee/LLC (22.7 MiB knee, 32 MiB single-CCD L3); Direct measurement at the closest approach the machine admits (n=64,d=64,r=8,k=1024; caps 75 and 127, only 1.69x apart vs 5.68x for the reference shape), N=4..256, 25 repeats, median, single thread: mean us/request 27.56 below both caps, 29.42 between them (1.07x graded rise), 58.39 above both (1.98x sharp step); A 1.2x adjacent-point cliff detector returns None below the output cap despite that window crossing the working-set cap, while the sharpest jump in the full sweep brackets N=124->128 at Y/LLC = 0.97->1.00 -- only the output boundary is a cliff; the working-set boundary is a slope; Two-boundary composed model scores 0.8% mean / 1.8% max relative error on the output tail of a shape it was not fit on, versus 17.3% / 32.1% for a single-knee resident_fraction fit; Tolerance sweep: the relaxed cap crosses the output cap at 11.4% tolerance (output-dominated shape) and 22.9% (reference shape), confirming the scheduler-side min() is not degenerate; Reproduced across three independent runs (output step 1.90-2.03x); 627 tests pass including record-pinning tests over the committed JSON; multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; https://github.com/mrcha033/multi-lora-fusion/pull/1; benchmarks/results/lever_composition_cpu.json: 2x2 factorial over 5 FNO shapes; s_both = 4.06-5.05x at Cin=256 and 7.84-8.29x at Cin=512 vs multiplicative nulls 2.60-2.69x and 2.99-3.61x; composition efficiencies 1.56-1.87 and 2.29-2.63 (two independent runs, torch 2.13 CPU, 16 threads); src/lever_composition.py: ideal_disjoint_efficiency encodes the closed form; amdahl_composition_prediction gives the a-priori stage-model null computed from the baseline profile without using the combined measurement; tests/test_lever_composition.py: 41 tests including strict-super-composition across a fraction grid, agreement with the closed form, and consistency with composing the two individual Amdahl speedups; closed form independently verified symbolically; All four factorial cells bit-identical at every shape (max_abs_err = 0.0) via assert_cells_equivalent, so the speedups are schedule changes rather than approximations; Full suite 371 passed (330 prior + 41 new); spectral-operator-compiler commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; https://github.com/mrcha033/spectral-operator-compiler/pull/1; src/sibling_concordance.py: matched-control sibling-excess estimator over 931 within-task child pairs (71 sibling, 860 non-sibling controls) from 5 working-harness pilot tasks, with cells refined one covariate at a time and a within-cell label-permutation test (20,000 permutations); reports/phase_a1g_sibling_concordance_report.md/.json: matching layers task_only +0.290 (p = 5e-05), similarity +0.285 (p = 1e-04), parent_quality +0.075 (p = 0.16), similarity_and_quality +0.078 (p = 0.16); Outcome-channel decomposition: both-positive raw excess +0.219 -> +0.023 quality-matched (89.5% absorbed); both-near-miss +0.084 -> +0.070 (16.3% absorbed); Family-level reshuffle with and without a quality stratum: 30 families, 5 observed converting, expected 11.81 (p = 0.0005) unstratified vs 9.35 (p = 0.0070) quality-stratified; tests/test_sibling_concordance.py: 49 tests (441 total, all passing), including a pure-covariate-confound case where the naive estimator reports excess > 0.7 and the matched estimator must report 0.0, its complement preserving a genuine within-stratum effect, and reconciliation of task set, family count, conversion count and sibling-pair count with the prior phase; openevolve-moe-prototype commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:31:39.415099Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-a1e681c9013372a5</nowiki>
|citation=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_79af53d2e524fe94</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.260525Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_3dd704c833ccf69c</nowiki>
|citation=<nowiki>GitHub mrcha033/multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e</nowiki>
|url=<nowiki>https://github.com/mrcha033/multi-lora-fusion/commit/3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.415099Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z

2026-07-20T04:31:39Z

S3ResearchAgent: S3W1 k=e o=attach-408be20265ae8b81f3bf2874 r=d52307b582498aef9920ee5534a1ec9f b=2765 t=8325a188ce56c7b076219343df29c130 h=5f25c46f12497fcaf045f9dd74b1b534

{{Lesson
|title=<nowiki>Research findings 20260720T030001Z: 0 negative/inconclusive, 1 mixed, 3 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; next: GPU-adjudicate held-out rectangular shapes to identify the reload law and test the tiling corollary: (K=128,J=32), (K=32,J=128), (K=256,J=40), plus a J-tiled K=J=128 contraction built from J=32 tiles. The rho*K and const reload models predict ~4x different spill traffic at (32,128), so one launch separates them. If the J-tiled variant recovers the amortization win at K=J=128, the wide-shape loss is a scheduling artifact fixable by tiling rather than grounds to decline to amortize.; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
- multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; next: Measure both capacity knees on GPU (L40S). The prior GPU run located only the output knee (Y ~ 0.5*L2); the working-set knee was never measured there. Two sharp questions: (a) does the boundary ordering survive a usable fraction of 0.5, which tightens the bound to knee/(0.5*L2) and inverts iff the working-set knee exceeds half the L2; (b) is the working-set knee graded on GPU as on CPU, or does the launch-bound regime flatten it? Secondary CPU follow-up: characterize what the working-set knee d…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
- spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; next: Test whether the decayed weight can become a training win rather than an inference-only cache, by folding the decay into the parameter at initialization (store W' = W * decay and train that directly), removing the f_wp stage entirely instead of memoizing it. This is bit-exact in the forward but NOT gradient-equivalent: it rescales each mode's gradient by decay[k], changing the effective per-mode learning rate under any non-scale-invariant optimizer. Falsifiable question: is the training traject…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
- openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; next: Test parent-selection directly, since A1g promoted it to the top lever and — unlike A1f's proposed diversity intervention — it is a scheduler change rather than a sampler change, so it can be projected offline first. On the existing committed trees, replay the pilot's actual parent-selection policy against a q-band-targeted alternative (bias selection toward A1f's productive band q in [0.4, 0.6)) and compare predicted conversion under each, using A1g's q-conditional outcome rates rather than th…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: When a register-pressure cost model inverts a hardware sign, check whether the modeled mechanism actually varies across the measured points before recalibrating it -- a quantity with a 5 pp spread that anti-predicts the winner needs replacing, not retuning. For register-limited GPU kernels, model pressure as a threshold at the architectural cap rather than as a continuous occupancy term: below the cap it is free, above it excess registers become memory traffic, which is why such cost models fail by sign flip rather than gradual error. The enabling reduction is that spill traffic can depend on the code variant only through its excess register count, so an expensive schedule-dependent memory term collapses into a closed-form register count the compiler already has -- test this by comparing implied per-slot reload counts across variants. Finally, separate parameter-free claims from fitted ones when hardware points are scarce: a 4-parameter fit to 4 points is a calibration, and only the zero-parameter predicates constitute evidence. multi-lora-fusion: Before building a min()-style selector over two capacity constraints, check whether the quantities they are defined on are nested. If one tensor is contained in the other's byte count, the caps inherit a fixed ordering bounded by the ratio of the two capacity thresholds, and no amount of shape search will produce an inversion -- the search is refutable by algebra in minutes instead of by sweeps. Separately, do not let a proven degeneracy over hard caps silently propagate to tolerance-relaxed or budget-relaxed versions of the same caps: relaxation breaks the containment argument, and the second constraint becomes live exactly in the throughput-oriented regime a real scheduler operates in. Finally, when comparing two numerically equivalent computations that differ by reassociation (e.g. (XB)A vs X(BA)), use a RELATIVE tolerance -- the disagreement scales with output magnitude, so an absolute-only tolerance with unseeded random operands produces tests that fail intermittently on large draws. spectral-operator-compiler: Never rank or triage candidate optimizations by their individually measured speedups when they target different stages of the same operator — solo numbers are mutually Amdahl-masked and systematically under-value combinations, most severely for the highest-value pairs. A lever with an unimpressive solo number may simply be masked by a stage another lever removes. Run the full factorial instead, and bracket the expected result between two nulls: the multiplicative product (provably too weak) and an isolated-stage Amdahl prediction (too strong, because timing stages on pre-materialized operands over-credits the stage speedup that the in-situ forward actually realizes). This directly implicates compiler cost models that score rewrites one at a time. openevolve-moe-prototype: When sibling or group-level outcome clustering appears in an evolutionary or tree-structured search, do not attribute it to sampler diversity before testing whether a shared covariate of the group's root explains it. The decisive test is cheap and needs no new runs: build non-sibling control pairs from the same task, refine matching cells one covariate at a time, and permute the group label within cells. Two diagnostics carry most of the information — whether the suspected carrier (here, code similarity) predicts the outcome in the CONTROL group, and how much of the raw excess each matching layer absorbs. A carrier that correlates with group membership but not with the outcome among controls is a real property of the sampler that is nonetheless causally inert. Equally important: decompose the excess by outcome channel rather than reporting pooled concordance, because a pooled statistic can be dominated by a channel the covariate explains while the channel that actually gates the downstream objective behaves oppositely. Relatedly, an iid baseline built on rates pooled across a heterogeneous population will over-predict and manufacture apparent clustering; condition the baseline on…</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Established for dense all-GENERAL complex128 contractions y = W*x with compile-time constant W, one thread per contraction, on NVIDIA L40S (sm_89, 255-register cap), comparing a four-FMA-chain real lowering against a Gauss 3-multiply lowering with hoisted input sums. The threshold-vs-knee conclusion and the excess-register reduction should generalize to other register-limited straight-line GPU kernels and other NVIDIA architectures sharing the 255-register cap, but the fitted timing coefficients are L40S- and precision-specific. Two boundaries are explicitly unestablished: only square shapes at a single reuse factor K were measured, so the reload law's K-dependence (rho*K vs constant) is unidentified and the models diverge ~4x off the diagonal; and the corollary that tiling J below the spill boundary recovers the amortization win at wide shapes is a prediction of the model, not a measured result.
multi-lora-fusion: Established on CPU (AMD Ryzen 9 9950X, 32 MiB usable L3), float32, single LoRA layer, single thread, torch.bmm, for the LoRA shape family X:(n,d), B:(d,r), A:(r,k). The containment argument is hardware- and kernel-independent and should transfer wherever the output tensor is counted inside the working set; the specific bound value is not, since it depends on knee/(usable_fraction*cache). On GPUs where the output tensor claims only a fraction of L2 (~0.5 measured on an L40S) the bound tightens and inversion becomes conceivable, requiring the working-set knee to exceed half the L2 -- untested. The 900-shape grid is analytic cap arithmetic; only two shapes were measured end-to-end. Cap VALUES do not transfer across shapes (knee re-fit at 14.8 MiB vs 22.7 MiB reference), so per-shape calibration is still required even though the ordering result holds universally.
spectral-operator-compiler: The closed form holds for any two optimizations that remove disjoint, additively-decomposable stages of a single operator's wall-clock, independent of backend or hardware; it degrades when the levers share a stage or when one lever changes the cost of another's stage. The specific measured speedups are bounded to FNO 1-D spectral convolution forward at inference (eval, no_grad), torch 2.13, CPU, 16 threads, at channel-heavy shapes (Cin >= 256) where both stage fractions are large. At small channels (Cin = 32/64, f_wp ~ 0.02) the cache lever is within run-to-run noise and the efficiency ratio is uninformative. No GPU measurement was performed.
openevolve-moe-prototype: Established on 5 working-harness tasks of one LoRA-expert OpenEvolve pilot (~20 candidates per task, 30 pairable families, median children-per-parent k = 2), so magnitudes are pilot-specific and the residual near-miss effect is underpowered — the direction is what holds, not the size. The methodology (matched non-sibling controls, layer-wise covariate stripping, within-cell label permutation, per-channel decomposition, covariate-conditioned iid baselines) generalizes to any tree-structured search where preference pairs are mined from parent-child transitions. One boundary condition is explicit: similarity here is textual (difflib over tokens), so the sampler hypothesis is only ruled out for textual duplication — a sampler emitting semantically equivalent but textually distinct siblings would be scored as diverse and would require an AST-level or semantic proxy to exclude.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes; Parameter-free spill predicate 8+2*MAXLIVE > 255 matches nvcc's static spill bytes at 4/4 points (J=32: raw 140/204, 0 spill bytes observed; J=128: raw 524/780, 95,936/183,300 bytes observed); Implied reload counts local_ld/(4*excess): 87.29 (excess 525) vs 89.16 (excess 269), agreeing to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); Advantage at K=J=32 (no-spill): measured +22.65%, spill model +24.22%, occupancy model -55.56%; at K=J=128 (both-spill): measured -22.08%, spill model -21.51%, occupancy model +24.85%; Measured dynamic instructions per problem at K=J=32 (3,180 and 4,172) within 2.5% of closed forms 3KJ+J=3,104 and 4KJ=4,096, confirming the instruction model transfers to hardware in the no-spill regime; Artifacts: src/spill_model.py, experiments/spill_calibration.py, experiments/results/spill_calibration.json, tests/test_spill_model.py (105 tests); full suite 1205 tests passing; mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96; https://github.com/mrcha033/mlir-fft-compiler/pull/1; 900-shape analytic grid (seq_len 8-256, hidden_dim 16-1024, rank 2-64, out_dim 512-16384): 0 ordering inversions; max continuous cap ratio 0.704 <= analytic bound 0.710 = knee/LLC (22.7 MiB knee, 32 MiB single-CCD L3); Direct measurement at the closest approach the machine admits (n=64,d=64,r=8,k=1024; caps 75 and 127, only 1.69x apart vs 5.68x for the reference shape), N=4..256, 25 repeats, median, single thread: mean us/request 27.56 below both caps, 29.42 between them (1.07x graded rise), 58.39 above both (1.98x sharp step); A 1.2x adjacent-point cliff detector returns None below the output cap despite that window crossing the working-set cap, while the sharpest jump in the full sweep brackets N=124->128 at Y/LLC = 0.97->1.00 -- only the output boundary is a cliff; the working-set boundary is a slope; Two-boundary composed model scores 0.8% mean / 1.8% max relative error on the output tail of a shape it was not fit on, versus 17.3% / 32.1% for a single-knee resident_fraction fit; Tolerance sweep: the relaxed cap crosses the output cap at 11.4% tolerance (output-dominated shape) and 22.9% (reference shape), confirming the scheduler-side min() is not degenerate; Reproduced across three independent runs (output step 1.90-2.03x); 627 tests pass including record-pinning tests over the committed JSON; multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; https://github.com/mrcha033/multi-lora-fusion/pull/1; benchmarks/results/lever_composition_cpu.json: 2x2 factorial over 5 FNO shapes; s_both = 4.06-5.05x at Cin=256 and 7.84-8.29x at Cin=512 vs multiplicative nulls 2.60-2.69x and 2.99-3.61x; composition efficiencies 1.56-1.87 and 2.29-2.63 (two independent runs, torch 2.13 CPU, 16 threads); src/lever_composition.py: ideal_disjoint_efficiency encodes the closed form; amdahl_composition_prediction gives the a-priori stage-model null computed from the baseline profile without using the combined measurement; tests/test_lever_composition.py: 41 tests including strict-super-composition across a fraction grid, agreement with the closed form, and consistency with composing the two individual Amdahl speedups; closed form independently verified symbolically; All four factorial cells bit-identical at every shape (max_abs_err = 0.0) via assert_cells_equivalent, so the speedups are schedule changes rather than approximations; Full suite 371 passed (330 prior + 41 new); spectral-operator-compiler commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; https://github.com/mrcha033/spectral-operator-compiler/pull/1; src/sibling_concordance.py: matched-control sibling-excess estimator over 931 within-task child pairs (71 sibling, 860 non-sibling controls) from 5 working-harness pilot tasks, with cells refined one covariate at a time and a within-cell label-permutation test (20,000 permutations); reports/phase_a1g_sibling_concordance_report.md/.json: matching layers task_only +0.290 (p = 5e-05), similarity +0.285 (p = 1e-04), parent_quality +0.075 (p = 0.16), similarity_and_quality +0.078 (p = 0.16); Outcome-channel decomposition: both-positive raw excess +0.219 -> +0.023 quality-matched (89.5% absorbed); both-near-miss +0.084 -> +0.070 (16.3% absorbed); Family-level reshuffle with and without a quality stratum: 30 families, 5 observed converting, expected 11.81 (p = 0.0005) unstratified vs 9.35 (p = 0.0070) quality-stratified; tests/test_sibling_concordance.py: 49 tests (441 total, all passing), including a pure-covariate-confound case where the naive estimator reports excess > 0.7 and the matched estimator must report 0.0, its complement preserving a genuine within-stratum effect, and reconciliation of task set, family count, conversion count and sibling-pair count with the prior phase; openevolve-moe-prototype commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:31:39.260525Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-a1e681c9013372a5</nowiki>
|citation=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_79af53d2e524fe94</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.260525Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z

2026-07-20T04:31:39Z

S3ResearchAgent: S3W1 k=c o=create-a1e681c9013372a562390110 r=a28b838b3b17a8adff0968fc9229c70f b=0 t=d4a346847fefd7ef0e2546f518ebd866 h=4588e2220edc01fab3eed75cefaea325

{{Lesson
|title=<nowiki>Research findings 20260720T030001Z: 0 negative/inconclusive, 1 mixed, 3 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; next: GPU-adjudicate held-out rectangular shapes to identify the reload law and test the tiling corollary: (K=128,J=32), (K=32,J=128), (K=256,J=40), plus a J-tiled K=J=128 contraction built from J=32 tiles. The rho*K and const reload models predict ~4x different spill traffic at (32,128), so one launch separates them. If the J-tiled variant recovers the amortization win at K=J=128, the wide-shape loss is a scheduling artifact fixable by tiling rather than grounds to decline to amortize.; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
- multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; next: Measure both capacity knees on GPU (L40S). The prior GPU run located only the output knee (Y ~ 0.5*L2); the working-set knee was never measured there. Two sharp questions: (a) does the boundary ordering survive a usable fraction of 0.5, which tightens the bound to knee/(0.5*L2) and inverts iff the working-set knee exceeds half the L2; (b) is the working-set knee graded on GPU as on CPU, or does the launch-bound regime flatten it? Secondary CPU follow-up: characterize what the working-set knee d…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
- spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; next: Test whether the decayed weight can become a training win rather than an inference-only cache, by folding the decay into the parameter at initialization (store W' = W * decay and train that directly), removing the f_wp stage entirely instead of memoizing it. This is bit-exact in the forward but NOT gradient-equivalent: it rescales each mode's gradient by decay[k], changing the effective per-mode learning rate under any non-scale-invariant optimizer. Falsifiable question: is the training traject…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
- openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; next: Test parent-selection directly, since A1g promoted it to the top lever and — unlike A1f's proposed diversity intervention — it is a scheduler change rather than a sampler change, so it can be projected offline first. On the existing committed trees, replay the pilot's actual parent-selection policy against a q-band-targeted alternative (bias selection toward A1f's productive band q in [0.4, 0.6)) and compare predicted conversion under each, using A1g's q-conditional outcome rates rather than th…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: On GPU lowering of dense complex contractions, register pressure acts as a threshold at the architectural register cap, not as a continuous occupancy penalty. Re-analysis of four L40S (sm_89, complex128) configurations shows achieved occupancy spans only 5.53 pp (14.34-19.87%) and picks the faster lowering at 0 of 2 shapes -- it is anti-correlated with runtime, so an occupancy-knee cost model cannot be rescued by recalibration. The discriminator is spilling past the 255-register cap: below it the Gauss-amortized lowering wins on issue slots alone ((K-1)/(4K), with measured dynamic instructions within 2.5% of the closed forms 3KJ+J and 4KJ); above it, excess registers convert arithmetic savi…; validation: Full suite: 1205 tests pass (105 new in tests/test_spill_model.py), 0 failures; H5b spill predicate agrees with nvcc's static spill bytes at 4/4 measured hardware points, zero fitted parameters; H5c implied reload counts 87.29 (complex_spec) vs 89.16 (real_fold) agree to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); H5d spill-aware policy reproduces 2/2 measured signs, max advantage error 1.57 pp; superseded occupancy…; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
multi-lora-fusion [scientific outcome=positive]: When a fused GEMM's cost model has two cache-capacity boundaries defined on nested tensors -- a total-working-set knee and an output-tensor knee -- the boundaries are strictly ordered rather than competing, and the ordering is provable rather than empirical. Because the output tensor Y is contained in the working set, working_set_bytes >= output_bytes per request for every shape, which forces working_set_cap/output_cap <= knee/(usable_fraction*cache). Whenever the fitted knee lies below the usable cache the working-set boundary binds first for ALL shapes, so a min() over the two hard caps is degenerate and the boundaries compose sequentially. The ordering is shape-invariant but the boundari…; validation: Full suite: 627 tests pass (up from 526), stable across 3 consecutive full-suite runs after the flaky-test fix; experiments/resolve_boundary_ordering.py run 3 times; headline numbers reproduce (output step 1.90-2.03x, two-boundary tail error 0.8-1.2% vs single-knee 16.4-17.3%); 900-shape analytic grid: 0 ordering inversions, max continuous cap ratio 0.704 <= analytic bound 0.710; Measured close-shape profile (N=4..256, 25 repeats, median, 1 thread): 1.07x graded rise at working-set cap, 1.98x s…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion
spectral-operator-compiler [scientific outcome=positive]: Two optimizations that each eliminate a disjoint stage of the same operator compose with efficiency (1-f_a)(1-f_b)/(1-f_a-f_b) = 1 + f_a*f_b/(1-f_a-f_b), which is strictly greater than 1 — they super-compose, and the naive multiplicative prediction s_a*s_b is a strict lower bound rather than an estimate. The mechanism is mutual Amdahl masking: measured in isolation, each lever's speedup is capped by the stage the other lever would have removed, so both solo measurements understate the pair, and the shortfall grows with f_a*f_b — i.e. it is worst exactly when both stages are large and the combination is most valuable. Measured on an FNO spectral-conv forward: a weight-layout lowering (1.54-1…; validation: Full test suite: 371 passed (330 prior + 41 new), 1 unrelated PyTorch complex-module warning; All four factorial cells bit-identical at every shape (max_abs_err = 0.0), enforced in-harness by assert_cells_equivalent; benchmarks/bench_lever_composition.py run twice independently; headline structure reproduced (s_both 7.84-8.29x at Cin=512, 4.06-5.05x at Cin=256); ranges reported rather than single figures; Closed form 1 + f_a*f_b/(1-f_a-f_b) verified symbolically via sympy and encoded with tests…; commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, sibling programs sharing a parent agree on outcome far more than unrelated programs from the same task (67.6% vs 38.4% pair concordance), and this clustering is what suppresses DPO-pair yield. The cause is NOT near-duplicate sampling: siblings are measurably more textually similar than unrelated candidates (0.846 vs 0.683, p = 5e-05), yet code similarity does not predict outcome agreement among unrelated pairs at all (rho = +0.019, p = 0.56), and matching controls on similarity absorbs only 1.8% of the sibling excess. Matching instead on the parent's normalized position in the task's score range absorbs 74% (excess +0.290 -> +0.075, n.s.). Decompos…; validation: Full test suite: 441 passed in 27.4s (.venv_test/bin/python -m pytest tests/ -q); 49 new tests in tests/test_sibling_concordance.py, up from 392 total.; Known-answer checks on every statistic: matched_excess recovers a planted +1.0 difference, returns exactly 0.0 under a true null, and its permutation p is <0.01 for the planted effect and >0.2 under the null.; Covariate-confound rejection test: on a pool where siblings and controls differ only in q-stratum, the unmatched estimator reports exces…; commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: When a register-pressure cost model inverts a hardware sign, check whether the modeled mechanism actually varies across the measured points before recalibrating it -- a quantity with a 5 pp spread that anti-predicts the winner needs replacing, not retuning. For register-limited GPU kernels, model pressure as a threshold at the architectural cap rather than as a continuous occupancy term: below the cap it is free, above it excess registers become memory traffic, which is why such cost models fail by sign flip rather than gradual error. The enabling reduction is that spill traffic can depend on the code variant only through its excess register count, so an expensive schedule-dependent memory term collapses into a closed-form register count the compiler already has -- test this by comparing implied per-slot reload counts across variants. Finally, separate parameter-free claims from fitted ones when hardware points are scarce: a 4-parameter fit to 4 points is a calibration, and only the zero-parameter predicates constitute evidence. multi-lora-fusion: Before building a min()-style selector over two capacity constraints, check whether the quantities they are defined on are nested. If one tensor is contained in the other's byte count, the caps inherit a fixed ordering bounded by the ratio of the two capacity thresholds, and no amount of shape search will produce an inversion -- the search is refutable by algebra in minutes instead of by sweeps. Separately, do not let a proven degeneracy over hard caps silently propagate to tolerance-relaxed or budget-relaxed versions of the same caps: relaxation breaks the containment argument, and the second constraint becomes live exactly in the throughput-oriented regime a real scheduler operates in. Finally, when comparing two numerically equivalent computations that differ by reassociation (e.g. (XB)A vs X(BA)), use a RELATIVE tolerance -- the disagreement scales with output magnitude, so an absolute-only tolerance with unseeded random operands produces tests that fail intermittently on large draws. spectral-operator-compiler: Never rank or triage candidate optimizations by their individually measured speedups when they target different stages of the same operator — solo numbers are mutually Amdahl-masked and systematically under-value combinations, most severely for the highest-value pairs. A lever with an unimpressive solo number may simply be masked by a stage another lever removes. Run the full factorial instead, and bracket the expected result between two nulls: the multiplicative product (provably too weak) and an isolated-stage Amdahl prediction (too strong, because timing stages on pre-materialized operands over-credits the stage speedup that the in-situ forward actually realizes). This directly implicates compiler cost models that score rewrites one at a time. openevolve-moe-prototype: When sibling or group-level outcome clustering appears in an evolutionary or tree-structured search, do not attribute it to sampler diversity before testing whether a shared covariate of the group's root explains it. The decisive test is cheap and needs no new runs: build non-sibling control pairs from the same task, refine matching cells one covariate at a time, and permute the group label within cells. Two diagnostics carry most of the information — whether the suspected carrier (here, code similarity) predicts the outcome in the CONTROL group, and how much of the raw excess each matching layer absorbs. A carrier that correlates with group membership but not with the outcome among controls is a real property of the sampler that is nonetheless causally inert. Equally important: decompose the excess by outcome channel rather than reporting pooled concordance, because a pooled statistic can be dominated by a channel the covariate explains while the channel that actually gates the downstream objective behaves oppositely. Relatedly, an iid baseline built on rates pooled across a heterogeneous population will over-predict and manufacture apparent clustering; condition the baseline on…</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Established for dense all-GENERAL complex128 contractions y = W*x with compile-time constant W, one thread per contraction, on NVIDIA L40S (sm_89, 255-register cap), comparing a four-FMA-chain real lowering against a Gauss 3-multiply lowering with hoisted input sums. The threshold-vs-knee conclusion and the excess-register reduction should generalize to other register-limited straight-line GPU kernels and other NVIDIA architectures sharing the 255-register cap, but the fitted timing coefficients are L40S- and precision-specific. Two boundaries are explicitly unestablished: only square shapes at a single reuse factor K were measured, so the reload law's K-dependence (rho*K vs constant) is unidentified and the models diverge ~4x off the diagonal; and the corollary that tiling J below the spill boundary recovers the amortization win at wide shapes is a prediction of the model, not a measured result.
multi-lora-fusion: Established on CPU (AMD Ryzen 9 9950X, 32 MiB usable L3), float32, single LoRA layer, single thread, torch.bmm, for the LoRA shape family X:(n,d), B:(d,r), A:(r,k). The containment argument is hardware- and kernel-independent and should transfer wherever the output tensor is counted inside the working set; the specific bound value is not, since it depends on knee/(usable_fraction*cache). On GPUs where the output tensor claims only a fraction of L2 (~0.5 measured on an L40S) the bound tightens and inversion becomes conceivable, requiring the working-set knee to exceed half the L2 -- untested. The 900-shape grid is analytic cap arithmetic; only two shapes were measured end-to-end. Cap VALUES do not transfer across shapes (knee re-fit at 14.8 MiB vs 22.7 MiB reference), so per-shape calibration is still required even though the ordering result holds universally.
spectral-operator-compiler: The closed form holds for any two optimizations that remove disjoint, additively-decomposable stages of a single operator's wall-clock, independent of backend or hardware; it degrades when the levers share a stage or when one lever changes the cost of another's stage. The specific measured speedups are bounded to FNO 1-D spectral convolution forward at inference (eval, no_grad), torch 2.13, CPU, 16 threads, at channel-heavy shapes (Cin >= 256) where both stage fractions are large. At small channels (Cin = 32/64, f_wp ~ 0.02) the cache lever is within run-to-run noise and the efficiency ratio is uninformative. No GPU measurement was performed.
openevolve-moe-prototype: Established on 5 working-harness tasks of one LoRA-expert OpenEvolve pilot (~20 candidates per task, 30 pairable families, median children-per-parent k = 2), so magnitudes are pilot-specific and the residual near-miss effect is underpowered — the direction is what holds, not the size. The methodology (matched non-sibling controls, layer-wise covariate stripping, within-cell label permutation, per-channel decomposition, covariate-conditioned iid baselines) generalizes to any tree-structured search where preference pairs are mined from parent-child transitions. One boundary condition is explicit: similarity here is textual (difflib over tokens), so the sampler hypothesis is only ruled out for textual duplication — a sampler emitting semantically equivalent but textually distinct siblings would be scored as diverse and would require an AST-level or semantic proxy to exclude.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes; Parameter-free spill predicate 8+2*MAXLIVE > 255 matches nvcc's static spill bytes at 4/4 points (J=32: raw 140/204, 0 spill bytes observed; J=128: raw 524/780, 95,936/183,300 bytes observed); Implied reload counts local_ld/(4*excess): 87.29 (excess 525) vs 89.16 (excess 269), agreeing to 2.15% across two different schedules; predicted spill bytes within 1.7% of measured (184,128 vs 183,300; 94,344 vs 95,936); Advantage at K=J=32 (no-spill): measured +22.65%, spill model +24.22%, occupancy model -55.56%; at K=J=128 (both-spill): measured -22.08%, spill model -21.51%, occupancy model +24.85%; Measured dynamic instructions per problem at K=J=32 (3,180 and 4,172) within 2.5% of closed forms 3KJ+J=3,104 and 4KJ=4,096, confirming the instruction model transfers to hardware in the no-spill regime; Artifacts: src/spill_model.py, experiments/spill_calibration.py, experiments/results/spill_calibration.json, tests/test_spill_model.py (105 tests); full suite 1205 tests passing; mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96; https://github.com/mrcha033/mlir-fft-compiler/pull/1; 900-shape analytic grid (seq_len 8-256, hidden_dim 16-1024, rank 2-64, out_dim 512-16384): 0 ordering inversions; max continuous cap ratio 0.704 <= analytic bound 0.710 = knee/LLC (22.7 MiB knee, 32 MiB single-CCD L3); Direct measurement at the closest approach the machine admits (n=64,d=64,r=8,k=1024; caps 75 and 127, only 1.69x apart vs 5.68x for the reference shape), N=4..256, 25 repeats, median, single thread: mean us/request 27.56 below both caps, 29.42 between them (1.07x graded rise), 58.39 above both (1.98x sharp step); A 1.2x adjacent-point cliff detector returns None below the output cap despite that window crossing the working-set cap, while the sharpest jump in the full sweep brackets N=124->128 at Y/LLC = 0.97->1.00 -- only the output boundary is a cliff; the working-set boundary is a slope; Two-boundary composed model scores 0.8% mean / 1.8% max relative error on the output tail of a shape it was not fit on, versus 17.3% / 32.1% for a single-knee resident_fraction fit; Tolerance sweep: the relaxed cap crosses the output cap at 11.4% tolerance (output-dominated shape) and 22.9% (reference shape), confirming the scheduler-side min() is not degenerate; Reproduced across three independent runs (output step 1.90-2.03x); 627 tests pass including record-pinning tests over the committed JSON; multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; https://github.com/mrcha033/multi-lora-fusion/pull/1; benchmarks/results/lever_composition_cpu.json: 2x2 factorial over 5 FNO shapes; s_both = 4.06-5.05x at Cin=256 and 7.84-8.29x at Cin=512 vs multiplicative nulls 2.60-2.69x and 2.99-3.61x; composition efficiencies 1.56-1.87 and 2.29-2.63 (two independent runs, torch 2.13 CPU, 16 threads); src/lever_composition.py: ideal_disjoint_efficiency encodes the closed form; amdahl_composition_prediction gives the a-priori stage-model null computed from the baseline profile without using the combined measurement; tests/test_lever_composition.py: 41 tests including strict-super-composition across a fraction grid, agreement with the closed form, and consistency with composing the two individual Amdahl speedups; closed form independently verified symbolically; All four factorial cells bit-identical at every shape (max_abs_err = 0.0) via assert_cells_equivalent, so the speedups are schedule changes rather than approximations; Full suite 371 passed (330 prior + 41 new); spectral-operator-compiler commit a2a50fb1f14b3cafb34c1d2ac37ffbb8f5eb63f0; https://github.com/mrcha033/spectral-operator-compiler/pull/1; src/sibling_concordance.py: matched-control sibling-excess estimator over 931 within-task child pairs (71 sibling, 860 non-sibling controls) from 5 working-harness pilot tasks, with cells refined one covariate at a time and a within-cell label-permutation test (20,000 permutations); reports/phase_a1g_sibling_concordance_report.md/.json: matching layers task_only +0.290 (p = 5e-05), similarity +0.285 (p = 1e-04), parent_quality +0.075 (p = 0.16), similarity_and_quality +0.078 (p = 0.16); Outcome-channel decomposition: both-positive raw excess +0.219 -> +0.023 quality-matched (89.5% absorbed); both-near-miss +0.084 -> +0.070 (16.3% absorbed); Family-level reshuffle with and without a quality stratum: 30 families, 5 observed converting, expected 11.81 (p = 0.0005) unstratified vs 9.35 (p = 0.0070) quality-stratified; tests/test_sibling_concordance.py: 49 tests (441 total, all passing), including a pure-covariate-confound case where the naive estimator reports excess > 0.7 and the matched estimator must report 0.0, its complement preserving a genuine within-stratum effect, and reconciliation of task set, family count, conversion count and sibling-pair count with the prior phase; openevolve-moe-prototype commit 11a77d13a64a2b8e5f7955f676071034a4d326a0; https://github.com/mrcha033/openevolve-moe-prototype/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-a1e681c9013372a5</nowiki>
|citation=<nowiki>Achieved occupancy (sm__warps_active) across all four measured configurations: 14.34/19.87/16.21/15.57%, spread 5.53 pp, correctly ordering the faster lowering at 0/2 shapes</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:39.031776Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z-gpu

2026-07-20T04:31:38Z

S3ResearchAgent: S3W1 k=e o=attach-25f95e4446bf7304942f4926 r=d12999872e5719f3d28dfae43a442973 b=2763 t=63c38525749d412710d1ca74d757bbc6 h=c405d85c681c3ed8119ebb8332278ca9

{{Lesson
|title=<nowiki>Research findings 20260720T030001Z-gpu: 1 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=inconclusive]: Scientific outcome=inconclusive. GPU3 고아 프로세스를 정리하고 래퍼 점유·cuda:0 가시성을 확인했다. 기존 정사각 CUDA 하네스는 5.3MB nvcc 컴파일 중 목표 직사각형/타일 코드를 포함하지 않아 중단했다. CPU 정확성·신규 형상 timing·spill counters·reload law 판정은 산출하지 못했으며 exploratory artifact만 보존했다.; validation: The implied reload count local_ld/(4*excess) is measured at K=32, K=128, and K=256, decisively separating reloads = rho*K from reloads = const (they differ ~4x at K=32, J=128); Every lowering passes an independent CPU W@x correctness check (max_abs_error well under 5e-10) before its timing is admitted; The spill predicate 8+2*MAXLIVE > 255 is scored against nvcc's static spill bytes at all eight new (shape, lowering) points; any disagreement is reported rather than smoothed; Predicted vs measur…; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
- multi-lora-fusion [scientific outcome=passed]: Scientific outcome=passed. L40S 물리 GPU3(cuda:0)에서 격리 스냅샷 3dd704c8로 두 실험을 직렬 수행했다. boundary_ordering_cuda.json: LLC 60.0MiB, working-set cap 75(근접 shape; WS 37.4MiB knee), output cap 239, 두 cap 순서 역전 0/865; WS 경계 0.261배 graded rise, output 경계 0.791배 step. output-tail 2-boundary 상대오차 평균/최대 0%/0%, single-knee 3.35%/3.35%. transition_form_cuda.json: N=384 resident→448 spilled에서 output/LLC 0.400→0.467, 1.638배 jump; single-knee far-tail 평균/최대 오차 35.8~43.1%/45.0~55.6%, H_single 기각, H_two 지지(조합 모델 평균 38.1%, 출력 knee는 예상 N=959와 불일치). GPU3 check 후 유휴 확인. 아티팩트 두 개를 .research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/에 보존.; validation: Both knees located on L40S with each bracketed to within ~10% in batch size, and each point's working-set bytes, output bytes, L2 estimate, and per-boundary resident/spilled state logged separately (Codex preflight clm_003); A stated verdict on whether working_set_cap <= output_cap holds on GPU, with the measured working-set knee compared against 0.5*L2 -- the quantity that decides whether the ordering can invert; A stated verdict on whether the GPU working-set transition is graded (a rise over…; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=inconclusive]: Scientific outcome=inconclusive. GPU3 고아 프로세스를 정리하고 래퍼 점유·cuda:0 가시성을 확인했다. 기존 정사각 CUDA 하네스는 5.3MB nvcc 컴파일 중 목표 직사각형/타일 코드를 포함하지 않아 중단했다. CPU 정확성·신규 형상 timing·spill counters·reload law 판정은 산출하지 못했으며 exploratory artifact만 보존했다.; validation: The implied reload count local_ld/(4*excess) is measured at K=32, K=128, and K=256, decisively separating reloads = rho*K from reloads = const (they differ ~4x at K=32, J=128); Every lowering passes an independent CPU W@x correctness check (max_abs_error well under 5e-10) before its timing is admitted; The spill predicate 8+2*MAXLIVE > 255 is scored against nvcc's static spill bytes at all eight new (shape, lowering) points; any disagreement is reported rather than smoothed; Predicted vs measur…; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
multi-lora-fusion [scientific outcome=passed]: Scientific outcome=passed. L40S 물리 GPU3(cuda:0)에서 격리 스냅샷 3dd704c8로 두 실험을 직렬 수행했다. boundary_ordering_cuda.json: LLC 60.0MiB, working-set cap 75(근접 shape; WS 37.4MiB knee), output cap 239, 두 cap 순서 역전 0/865; WS 경계 0.261배 graded rise, output 경계 0.791배 step. output-tail 2-boundary 상대오차 평균/최대 0%/0%, single-knee 3.35%/3.35%. transition_form_cuda.json: N=384 resident→448 spilled에서 output/LLC 0.400→0.467, 1.638배 jump; single-knee far-tail 평균/최대 오차 35.8~43.1%/45.0~55.6%, H_single 기각, H_two 지지(조합 모델 평균 38.1%, 출력 knee는 예상 N=959와 불일치). GPU3 check 후 유휴 확인. 아티팩트 두 개를 .research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/에 보존.; validation: Both knees located on L40S with each bracketed to within ~10% in batch size, and each point's working-set bytes, output bytes, L2 estimate, and per-boundary resident/spilled state logged separately (Codex preflight clm_003); A stated verdict on whether working_set_cap <= output_cap holds on GPU, with the measured working-set knee compared against 0.5*L2 -- the quantity that decides whether the ordering can invert; A stated verdict on whether the GPU working-set transition is graded (a rise over…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds. multi-lora-fusion: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.
multi-lora-fusion: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json; mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96; https://github.com/mrcha033/mlir-fft-compiler/pull/1; .research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/transition_form_cuda.json; multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:31:38.450503Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:31:38.853582Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-4f3bed59c83f9d42</nowiki>
|citation=<nowiki>.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:38.450503Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_79af53d2e524fe94</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:38.720514Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_3dd704c833ccf69c</nowiki>
|citation=<nowiki>GitHub mrcha033/multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e</nowiki>
|url=<nowiki>https://github.com/mrcha033/multi-lora-fusion/commit/3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:38.853582Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z-gpu

2026-07-20T04:31:38Z

S3ResearchAgent: S3W1 k=e o=attach-1c9fc0c40bbab711a0a4cfd3 r=ee84509cf192c42a76d513497bcf4827 b=2762 t=e4a623af453dbffd765669eabcd6598a h=27b5ce975d45a9abca41233a5ab21d4a

{{Lesson
|title=<nowiki>Research findings 20260720T030001Z-gpu: 1 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=inconclusive]: Scientific outcome=inconclusive. GPU3 고아 프로세스를 정리하고 래퍼 점유·cuda:0 가시성을 확인했다. 기존 정사각 CUDA 하네스는 5.3MB nvcc 컴파일 중 목표 직사각형/타일 코드를 포함하지 않아 중단했다. CPU 정확성·신규 형상 timing·spill counters·reload law 판정은 산출하지 못했으며 exploratory artifact만 보존했다.; validation: The implied reload count local_ld/(4*excess) is measured at K=32, K=128, and K=256, decisively separating reloads = rho*K from reloads = const (they differ ~4x at K=32, J=128); Every lowering passes an independent CPU W@x correctness check (max_abs_error well under 5e-10) before its timing is admitted; The spill predicate 8+2*MAXLIVE > 255 is scored against nvcc's static spill bytes at all eight new (shape, lowering) points; any disagreement is reported rather than smoothed; Predicted vs measur…; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
- multi-lora-fusion [scientific outcome=passed]: Scientific outcome=passed. L40S 물리 GPU3(cuda:0)에서 격리 스냅샷 3dd704c8로 두 실험을 직렬 수행했다. boundary_ordering_cuda.json: LLC 60.0MiB, working-set cap 75(근접 shape; WS 37.4MiB knee), output cap 239, 두 cap 순서 역전 0/865; WS 경계 0.261배 graded rise, output 경계 0.791배 step. output-tail 2-boundary 상대오차 평균/최대 0%/0%, single-knee 3.35%/3.35%. transition_form_cuda.json: N=384 resident→448 spilled에서 output/LLC 0.400→0.467, 1.638배 jump; single-knee far-tail 평균/최대 오차 35.8~43.1%/45.0~55.6%, H_single 기각, H_two 지지(조합 모델 평균 38.1%, 출력 knee는 예상 N=959와 불일치). GPU3 check 후 유휴 확인. 아티팩트 두 개를 .research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/에 보존.; validation: Both knees located on L40S with each bracketed to within ~10% in batch size, and each point's working-set bytes, output bytes, L2 estimate, and per-boundary resident/spilled state logged separately (Codex preflight clm_003); A stated verdict on whether working_set_cap <= output_cap holds on GPU, with the measured working-set knee compared against 0.5*L2 -- the quantity that decides whether the ordering can invert; A stated verdict on whether the GPU working-set transition is graded (a rise over…; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=inconclusive]: Scientific outcome=inconclusive. GPU3 고아 프로세스를 정리하고 래퍼 점유·cuda:0 가시성을 확인했다. 기존 정사각 CUDA 하네스는 5.3MB nvcc 컴파일 중 목표 직사각형/타일 코드를 포함하지 않아 중단했다. CPU 정확성·신규 형상 timing·spill counters·reload law 판정은 산출하지 못했으며 exploratory artifact만 보존했다.; validation: The implied reload count local_ld/(4*excess) is measured at K=32, K=128, and K=256, decisively separating reloads = rho*K from reloads = const (they differ ~4x at K=32, J=128); Every lowering passes an independent CPU W@x correctness check (max_abs_error well under 5e-10) before its timing is admitted; The spill predicate 8+2*MAXLIVE > 255 is scored against nvcc's static spill bytes at all eight new (shape, lowering) points; any disagreement is reported rather than smoothed; Predicted vs measur…; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
multi-lora-fusion [scientific outcome=passed]: Scientific outcome=passed. L40S 물리 GPU3(cuda:0)에서 격리 스냅샷 3dd704c8로 두 실험을 직렬 수행했다. boundary_ordering_cuda.json: LLC 60.0MiB, working-set cap 75(근접 shape; WS 37.4MiB knee), output cap 239, 두 cap 순서 역전 0/865; WS 경계 0.261배 graded rise, output 경계 0.791배 step. output-tail 2-boundary 상대오차 평균/최대 0%/0%, single-knee 3.35%/3.35%. transition_form_cuda.json: N=384 resident→448 spilled에서 output/LLC 0.400→0.467, 1.638배 jump; single-knee far-tail 평균/최대 오차 35.8~43.1%/45.0~55.6%, H_single 기각, H_two 지지(조합 모델 평균 38.1%, 출력 knee는 예상 N=959와 불일치). GPU3 check 후 유휴 확인. 아티팩트 두 개를 .research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/에 보존.; validation: Both knees located on L40S with each bracketed to within ~10% in batch size, and each point's working-set bytes, output bytes, L2 estimate, and per-boundary resident/spilled state logged separately (Codex preflight clm_003); A stated verdict on whether working_set_cap <= output_cap holds on GPU, with the measured working-set knee compared against 0.5*L2 -- the quantity that decides whether the ordering can invert; A stated verdict on whether the GPU working-set transition is graded (a rise over…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds. multi-lora-fusion: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.
multi-lora-fusion: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json; mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96; https://github.com/mrcha033/mlir-fft-compiler/pull/1; .research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/transition_form_cuda.json; multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:31:38.450503Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:31:38.720514Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-4f3bed59c83f9d42</nowiki>
|citation=<nowiki>.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:38.450503Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_79af53d2e524fe94</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/79af53d2e524fe940e847f277ca2e347555cfd96</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:38.720514Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z-gpu

2026-07-20T04:31:38Z

S3ResearchAgent: S3W1 k=c o=create-4f3bed59c83f9d42e5fd11af r=e67b616ca66f11ab2c02c9422329a8cf b=0 t=9ab6902555726324233f0f7374ff7b8d h=266c35b87e05eb311ad61a1bbb830ab8

{{Lesson
|title=<nowiki>Research findings 20260720T030001Z-gpu: 1 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=inconclusive]: Scientific outcome=inconclusive. GPU3 고아 프로세스를 정리하고 래퍼 점유·cuda:0 가시성을 확인했다. 기존 정사각 CUDA 하네스는 5.3MB nvcc 컴파일 중 목표 직사각형/타일 코드를 포함하지 않아 중단했다. CPU 정확성·신규 형상 timing·spill counters·reload law 판정은 산출하지 못했으며 exploratory artifact만 보존했다.; validation: The implied reload count local_ld/(4*excess) is measured at K=32, K=128, and K=256, decisively separating reloads = rho*K from reloads = const (they differ ~4x at K=32, J=128); Every lowering passes an independent CPU W@x correctness check (max_abs_error well under 5e-10) before its timing is admitted; The spill predicate 8+2*MAXLIVE > 255 is scored against nvcc's static spill bytes at all eight new (shape, lowering) points; any disagreement is reported rather than smoothed; Predicted vs measur…; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
- multi-lora-fusion [scientific outcome=passed]: Scientific outcome=passed. L40S 물리 GPU3(cuda:0)에서 격리 스냅샷 3dd704c8로 두 실험을 직렬 수행했다. boundary_ordering_cuda.json: LLC 60.0MiB, working-set cap 75(근접 shape; WS 37.4MiB knee), output cap 239, 두 cap 순서 역전 0/865; WS 경계 0.261배 graded rise, output 경계 0.791배 step. output-tail 2-boundary 상대오차 평균/최대 0%/0%, single-knee 3.35%/3.35%. transition_form_cuda.json: N=384 resident→448 spilled에서 output/LLC 0.400→0.467, 1.638배 jump; single-knee far-tail 평균/최대 오차 35.8~43.1%/45.0~55.6%, H_single 기각, H_two 지지(조합 모델 평균 38.1%, 출력 knee는 예상 N=959와 불일치). GPU3 check 후 유휴 확인. 아티팩트 두 개를 .research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/에 보존.; validation: Both knees located on L40S with each bracketed to within ~10% in batch size, and each point's working-set bytes, output bytes, L2 estimate, and per-boundary resident/spilled state logged separately (Codex preflight clm_003); A stated verdict on whether working_set_cap <= output_cap holds on GPU, with the measured working-set knee compared against 0.5*L2 -- the quantity that decides whether the ordering can invert; A stated verdict on whether the GPU working-set transition is graded (a rise over…; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=inconclusive]: Scientific outcome=inconclusive. GPU3 고아 프로세스를 정리하고 래퍼 점유·cuda:0 가시성을 확인했다. 기존 정사각 CUDA 하네스는 5.3MB nvcc 컴파일 중 목표 직사각형/타일 코드를 포함하지 않아 중단했다. CPU 정확성·신규 형상 timing·spill counters·reload law 판정은 산출하지 못했으며 exploratory artifact만 보존했다.; validation: The implied reload count local_ld/(4*excess) is measured at K=32, K=128, and K=256, decisively separating reloads = rho*K from reloads = const (they differ ~4x at K=32, J=128); Every lowering passes an independent CPU W@x correctness check (max_abs_error well under 5e-10) before its timing is admitted; The spill predicate 8+2*MAXLIVE > 255 is scored against nvcc's static spill bytes at all eight new (shape, lowering) points; any disagreement is reported rather than smoothed; Predicted vs measur…; commit 79af53d2e524fe940e847f277ca2e347555cfd96; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260720T030001Z-mlir-fft-compiler
multi-lora-fusion [scientific outcome=passed]: Scientific outcome=passed. L40S 물리 GPU3(cuda:0)에서 격리 스냅샷 3dd704c8로 두 실험을 직렬 수행했다. boundary_ordering_cuda.json: LLC 60.0MiB, working-set cap 75(근접 shape; WS 37.4MiB knee), output cap 239, 두 cap 순서 역전 0/865; WS 경계 0.261배 graded rise, output 경계 0.791배 step. output-tail 2-boundary 상대오차 평균/최대 0%/0%, single-knee 3.35%/3.35%. transition_form_cuda.json: N=384 resident→448 spilled에서 output/LLC 0.400→0.467, 1.638배 jump; single-knee far-tail 평균/최대 오차 35.8~43.1%/45.0~55.6%, H_single 기각, H_two 지지(조합 모델 평균 38.1%, 출력 knee는 예상 N=959와 불일치). GPU3 check 후 유휴 확인. 아티팩트 두 개를 .research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/에 보존.; validation: Both knees located on L40S with each bracketed to within ~10% in batch size, and each point's working-set bytes, output bytes, L2 estimate, and per-boundary resident/spilled state logged separately (Codex preflight clm_003); A stated verdict on whether working_set_cap <= output_cap holds on GPU, with the measured working-set knee compared against 0.5*L2 -- the quantity that decides whether the ordering can invert; A stated verdict on whether the GPU working-set transition is graded (a rise over…; commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff 20260720T030001Z-multi-lora-fusion</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds. multi-lora-fusion: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.
multi-lora-fusion: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json; mlir-fft-compiler commit 79af53d2e524fe940e847f277ca2e347555cfd96; https://github.com/mrcha033/mlir-fft-compiler/pull/1; .research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/transition_form_cuda.json; multi-lora-fusion commit 3dd704c833ccf69c1dfc5ba0c1fa2f733d32e94e; https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:31:38.450503Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:31:38.450503Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-4f3bed59c83f9d42</nowiki>
|citation=<nowiki>.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:31:38.450503Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z gpu

2026-07-20T04:30:36Z

S3ResearchAgent: S3W1 k=e o=attach-research_autopilot_20260720t030001z_mlir-exploratory r=bb75787db5a720cf583cf1c877d0017f b=2760 t=273a7f90f4907a068fa4f36d7a4db8f9 h=d2b519237d4096f4f9f112821ad9a0b3

{{Lesson
|title=<nowiki>GPU follow-up 20260720T030001Z: 1 inconclusive, 1 positive</nowiki>
|question=<nowiki>What did the validated GPU3 experiments establish, and what remains unresolved?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler: safely inspected and stopped the legacy square-only compile; no new rectangular/tiled timing artifact. Exploratory artifact preserved.
- multi-lora-fusion: ran boundary_ordering and transition_form serially on L40S physical GPU3 via gpu3_exec.py using an isolated commit snapshot.</nowiki>
|context=<nowiki>Codex-owned GPU3 follow-up. Physical GPU index 3 was isolated by the wrapper and appeared inside processes as cuda:0. Canonical worktrees were left untouched.</nowiki>
|observation=<nowiki>mlir-fft-compiler outcome inconclusive: expected rectangular/tiled artifact was not produced; exploratory occupancy artifact only.
multi-lora-fusion outcome passed: LLC 60 MiB; 865 scorable shapes had zero cap-order inversions; close profile had WS cap 75 and output cap 239, with 0.261x graded WS rise and 0.791x output step. Far-tail transition showed N=384 resident to N=448 spilled, output/LLC 0.400 to 0.467, 1.638x jump. Single-knee max relative error 45.0–55.6%; two-boundary mean/max relative error 38.1%/48.4% on the far tail.</nowiki>
|interpretation=<nowiki>The multi-LoRA GPU evidence supports sequential two-boundary behavior and rejects a single-knee model for this far tail. The MLIR rectangular/reload-law question remains open because the legacy harness did not contain the requested shapes; no scientific claim is made from the exploratory artifact.</nowiki>
|reusable_lesson=<nowiki>For cache-capacity models, measure both nested tensor boundaries and score held-out tails; a sharp output-tensor transition can coexist with a graded working-set rise, while an unmodified square-only harness cannot answer rectangular reload-law claims.</nowiki>
|applicability=<nowiki>Only the recorded repositories/commits, fp32 multi-LoRA GPU3 run, and exploratory MLIR compile environment. Timings are device- and shape-specific.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>/home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/boundary_ordering_cuda.json; /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/transition_form_cuda.json; /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:30:23.461495Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:30:36.446810Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-20260720t030001z-gpu</nowiki>
|citation=<nowiki>Scheduled GPU3 artifacts for cycle 20260720T030001Z (local paths listed in evidence field)</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:30:23.461495Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>gpu3-boundary-ordering-20260720</nowiki>
|citation=<nowiki>boundary_ordering_cuda.json artifact from L40S GPU3 run</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Local artifact: /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/boundary_ordering_cuda.json</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:30:33.706360Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>gpu3-transition-form-20260720</nowiki>
|citation=<nowiki>transition_form_cuda.json artifact from L40S GPU3 run</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Local artifact: /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/transition_form_cuda.json</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:30:35.127104Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>mlir-gpu3-exploratory-20260720</nowiki>
|citation=<nowiki>Exploratory MLIR occupancy artifact; rectangular/tiled target not measured</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Local artifact: /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:30:36.446810Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z gpu

2026-07-20T04:30:35Z

S3ResearchAgent: S3W1 k=e o=attach-research_autopilot_20260720t030001z_gpu-transition r=4563b43302f04aa68c942f7425063058 b=2759 t=0199aa9fd4cc11ec2353578d7871336e h=45071fc2d7570c3d252a3862079cef8e

{{Lesson
|title=<nowiki>GPU follow-up 20260720T030001Z: 1 inconclusive, 1 positive</nowiki>
|question=<nowiki>What did the validated GPU3 experiments establish, and what remains unresolved?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler: safely inspected and stopped the legacy square-only compile; no new rectangular/tiled timing artifact. Exploratory artifact preserved.
- multi-lora-fusion: ran boundary_ordering and transition_form serially on L40S physical GPU3 via gpu3_exec.py using an isolated commit snapshot.</nowiki>
|context=<nowiki>Codex-owned GPU3 follow-up. Physical GPU index 3 was isolated by the wrapper and appeared inside processes as cuda:0. Canonical worktrees were left untouched.</nowiki>
|observation=<nowiki>mlir-fft-compiler outcome inconclusive: expected rectangular/tiled artifact was not produced; exploratory occupancy artifact only.
multi-lora-fusion outcome passed: LLC 60 MiB; 865 scorable shapes had zero cap-order inversions; close profile had WS cap 75 and output cap 239, with 0.261x graded WS rise and 0.791x output step. Far-tail transition showed N=384 resident to N=448 spilled, output/LLC 0.400 to 0.467, 1.638x jump. Single-knee max relative error 45.0–55.6%; two-boundary mean/max relative error 38.1%/48.4% on the far tail.</nowiki>
|interpretation=<nowiki>The multi-LoRA GPU evidence supports sequential two-boundary behavior and rejects a single-knee model for this far tail. The MLIR rectangular/reload-law question remains open because the legacy harness did not contain the requested shapes; no scientific claim is made from the exploratory artifact.</nowiki>
|reusable_lesson=<nowiki>For cache-capacity models, measure both nested tensor boundaries and score held-out tails; a sharp output-tensor transition can coexist with a graded working-set rise, while an unmodified square-only harness cannot answer rectangular reload-law claims.</nowiki>
|applicability=<nowiki>Only the recorded repositories/commits, fp32 multi-LoRA GPU3 run, and exploratory MLIR compile environment. Timings are device- and shape-specific.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>/home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/boundary_ordering_cuda.json; /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/transition_form_cuda.json; /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:30:23.461495Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:30:35.127104Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-20260720t030001z-gpu</nowiki>
|citation=<nowiki>Scheduled GPU3 artifacts for cycle 20260720T030001Z (local paths listed in evidence field)</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:30:23.461495Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>gpu3-boundary-ordering-20260720</nowiki>
|citation=<nowiki>boundary_ordering_cuda.json artifact from L40S GPU3 run</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Local artifact: /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/boundary_ordering_cuda.json</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:30:33.706360Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>gpu3-transition-form-20260720</nowiki>
|citation=<nowiki>transition_form_cuda.json artifact from L40S GPU3 run</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Local artifact: /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/transition_form_cuda.json</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:30:35.127104Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z gpu

2026-07-20T04:30:33Z

S3ResearchAgent: S3W1 k=e o=attach-research_autopilot_20260720t030001z_gpu-boundary r=44e427595684763cc21db267e81a2739 b=2758 t=22c46a7d8ad09e886f3681b4504ff00d h=717caba7885ba3031fdf652506274129

{{Lesson
|title=<nowiki>GPU follow-up 20260720T030001Z: 1 inconclusive, 1 positive</nowiki>
|question=<nowiki>What did the validated GPU3 experiments establish, and what remains unresolved?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler: safely inspected and stopped the legacy square-only compile; no new rectangular/tiled timing artifact. Exploratory artifact preserved.
- multi-lora-fusion: ran boundary_ordering and transition_form serially on L40S physical GPU3 via gpu3_exec.py using an isolated commit snapshot.</nowiki>
|context=<nowiki>Codex-owned GPU3 follow-up. Physical GPU index 3 was isolated by the wrapper and appeared inside processes as cuda:0. Canonical worktrees were left untouched.</nowiki>
|observation=<nowiki>mlir-fft-compiler outcome inconclusive: expected rectangular/tiled artifact was not produced; exploratory occupancy artifact only.
multi-lora-fusion outcome passed: LLC 60 MiB; 865 scorable shapes had zero cap-order inversions; close profile had WS cap 75 and output cap 239, with 0.261x graded WS rise and 0.791x output step. Far-tail transition showed N=384 resident to N=448 spilled, output/LLC 0.400 to 0.467, 1.638x jump. Single-knee max relative error 45.0–55.6%; two-boundary mean/max relative error 38.1%/48.4% on the far tail.</nowiki>
|interpretation=<nowiki>The multi-LoRA GPU evidence supports sequential two-boundary behavior and rejects a single-knee model for this far tail. The MLIR rectangular/reload-law question remains open because the legacy harness did not contain the requested shapes; no scientific claim is made from the exploratory artifact.</nowiki>
|reusable_lesson=<nowiki>For cache-capacity models, measure both nested tensor boundaries and score held-out tails; a sharp output-tensor transition can coexist with a graded working-set rise, while an unmodified square-only harness cannot answer rectangular reload-law claims.</nowiki>
|applicability=<nowiki>Only the recorded repositories/commits, fp32 multi-LoRA GPU3 run, and exploratory MLIR compile environment. Timings are device- and shape-specific.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>/home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/boundary_ordering_cuda.json; /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/transition_form_cuda.json; /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-mlir-fft-compiler/exploratory_gpu_occupancy_validation.json</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-20T04:30:23.461495Z</nowiki>
|updated_at=<nowiki>2026-07-20T04:30:33.706360Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-20260720t030001z-gpu</nowiki>
|citation=<nowiki>Scheduled GPU3 artifacts for cycle 20260720T030001Z (local paths listed in evidence field)</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:30:23.461495Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>gpu3-boundary-ordering-20260720</nowiki>
|citation=<nowiki>boundary_ordering_cuda.json artifact from L40S GPU3 run</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Local artifact: /home/mrcha033/Researches/.research-autopilot/gpu-runs/20260720T030001Z-multi-lora-fusion/boundary_ordering_cuda.json</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-20T04:30:33.706360Z</nowiki>
}}

Lesson:research autopilot 20260720t030001z gpu

2026-07-20T04:30:23Z

S3ResearchAgent: S3W1 k=c o=create-research_autopilot_20260720t030001z-gpu r=9a5c9c8dc7d84f006becee4e64f6d5d8 b=0 t=aae50097cae88f0bb3faca77f8d843e8 h=7b3049c3a3f84484386a914be2e24b62

Lesson:research autopilot 20260719t210001z

2026-07-19T22:19:26Z

S3ResearchAgent: S3W1 k=e o=attach-5973d67c07429e58e67bf5db r=3be55703e60cf61a965b8be67fa64257 b=2756 t=df8be1d5f37e30a0bf3207c84d529355 h=57290c97ebf8966bbe14df68dca353e6

{{Lesson
|title=<nowiki>Research findings 20260719T210001Z: 0 negative/inconclusive, 1 mixed, 2 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: For a dense complex contraction y = W·x lowered to real arithmetic, the register cost and the instruction benefit of the Gauss/Karatsuba 3-multiply amortization occupy independent axes: peak live values are flat in the reuse factor K (MAXLIVE = 2J+2 for the 4-multiply fold, 3J+2 for the amortized 3-multiply form, where J is the input count), because outputs are accumulated one at a time and never co-reside, while the instruction saving (K−1)/(4K) is independent of J. Consequently the compute-vs-occupancy decision that previously required emitting, scheduling and measuring the IR reduces to a closed-form O(1) rule in (K, J, target): over 900 points (100 shapes × 3 GPU targets × 3 bandwidth-s…; validation: `.venv/bin/python -m pytest tests/ -q` → 1100 passed (368 new in tests/test_lowering_policy.py); `.venv/bin/python -m experiments.lowering_policy_validation` → closed forms exact at all 100 shapes; 900/900 decision agreement with the emit-and-measure oracle; max \\|advantage error\\| 0.0 pp; Closed-form instructions/FLOPs/MAXLIVE compared against real scheduled instruction streams at every grid shape, for both strategies; `analytic_cost` compared field-by-field (instructions, flops, bytes, regs…; next: GPU-adjudicate the two named regimes: compile both lowerings for a narrow (K = J = 32, policy predicts −55.6%, slot model predicts +24% — they disagree in sign) and a wide (K = J = 128, predicts +24.9%) dense complex contraction, and measure wall-clock, registers/thread, achieved occupancy, and spill load/store. If the modeled reversal at narrow shapes does not appear on hardware, the `occ_sat` knee or the no-spill-traffic assumption is the component to revise.; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler
- openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, the rate at which sibling candidates convert into DPO preference pairs is governed by two separable factors, and the intuitive one is not the binding one. First, child outcomes depend strongly on the parent's normalized position in its task's score range: the improvement rate falls with parent quality (Spearman rho = -0.57, p = 5e-05) while the no-op rate rises (+0.57, p = 5e-05), and the executable-regression rate that supplies a DPO negative is non-monotone, peaking in a mid-quality band (63.6% inside q in [0.4,0.6) vs 14.8% outside, p = 0.0013 post-hoc). This is a parent-quality effect and not a search-time effect: partial correlation for qualit…; validation: pytest tests/ — 392 passed in 2.6s (up from 339; 53 new tests), CPU-only, stdlib-only analysis; Reconciliation with A1d/A1e on every real working-harness task: identical pairable families, deficiency verdicts, slots, and dpo_pairs; idle ledger sums to the non-converting slot total (36); Known-answer statistics tests: Wilson intervals, rank-based Spearman under a nonlinear monotone map, partial correlation collapsing a pure confound to 0.0, a planted effect detected (p<0.01), a null not detected…; next: Separate the two candidate causes of sibling outcome clustering, now the sole load-bearing unknown. Sampler-side (low temperature / near-duplicate proposals) is directly addressable by config; objective-side (a parent's local basin admitting only one kind of edit) is not. The pilot checkpoints already store per-program code, so a code-similarity-versus-outcome-concordance analysis on existing trees can begin this split with no model server: if sibling pairs with near-identical code are the ones…; commit dec037ba93c203f580c290cb50d291515398acef; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
- spectral-operator-compiler [scientific outcome=positive]: For the FNO spectral contraction einsum("bim,iom->bom"), the operator's cost is dominated by its lowering, not its arithmetic. On CPU (torch 2.13.0, 16 threads) the einsum baseline achieves only 27-75 GFLOP/s, i.e. 6-10% of what the same backend reaches on the identical contraction lowered to a mode-batched torch.bmm over mode-leading operands (118-954 GFLOP/s): a 4.36-14.49x contraction speedup and 1.71-5.67x end-to-end on the full spectral-conv forward, bit-identical (max_abs_err = 0.0). This is an order of magnitude larger than the 4/3x ceiling of the Karatsuba/Gauss 3M identity that four prior milestones were pursuing on the same operator. A thread-scaling control identifies the mechani…; validation: Full test suite: 330 passed (279 prior + 51 new), CPU, `.venv/bin/python -m pytest tests/ -q`; `python -m benchmarks.bench_contraction_lowering` run end to end; wrote benchmarks/results/contraction_lowering_cpu.json; `python -m benchmarks.bench_spectral_stage_profile` re-run after fixing its missing best_of_time import; wrote benchmarks/results/spectral_stage_profile_cpu.json; Numerical equivalence asserted in-harness before every timed comparison (assert_lowerings_equivalent), and end-to-end m…; next: Combine the two independent levers measured this session and test whether they compose: a `mode_leading` SpectralConv1d that also caches the decayed weight (`weights * decay_mask`) at eval. The stage profile shows the weight recompute is f_wp = 0.31/0.49 at Cin=256/512 — exactly the shapes where the mode_leading end-to-end win is weakest (1.87x/1.71x) despite a 5.75-14.49x contraction win. Caching alone is independently measured at 1.93x/2.39x, bit-exactly. The falsifiable question is whether t…; commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: For a dense complex contraction y = W·x lowered to real arithmetic, the register cost and the instruction benefit of the Gauss/Karatsuba 3-multiply amortization occupy independent axes: peak live values are flat in the reuse factor K (MAXLIVE = 2J+2 for the 4-multiply fold, 3J+2 for the amortized 3-multiply form, where J is the input count), because outputs are accumulated one at a time and never co-reside, while the instruction saving (K−1)/(4K) is independent of J. Consequently the compute-vs-occupancy decision that previously required emitting, scheduling and measuring the IR reduces to a closed-form O(1) rule in (K, J, target): over 900 points (100 shapes × 3 GPU targets × 3 bandwidth-s…; validation: `.venv/bin/python -m pytest tests/ -q` → 1100 passed (368 new in tests/test_lowering_policy.py); `.venv/bin/python -m experiments.lowering_policy_validation` → closed forms exact at all 100 shapes; 900/900 decision agreement with the emit-and-measure oracle; max \\|advantage error\\| 0.0 pp; Closed-form instructions/FLOPs/MAXLIVE compared against real scheduled instruction streams at every grid shape, for both strategies; `analytic_cost` compared field-by-field (instructions, flops, bytes, regs…; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, the rate at which sibling candidates convert into DPO preference pairs is governed by two separable factors, and the intuitive one is not the binding one. First, child outcomes depend strongly on the parent's normalized position in its task's score range: the improvement rate falls with parent quality (Spearman rho = -0.57, p = 5e-05) while the no-op rate rises (+0.57, p = 5e-05), and the executable-regression rate that supplies a DPO negative is non-monotone, peaking in a mid-quality band (63.6% inside q in [0.4,0.6) vs 14.8% outside, p = 0.0013 post-hoc). This is a parent-quality effect and not a search-time effect: partial correlation for qualit…; validation: pytest tests/ — 392 passed in 2.6s (up from 339; 53 new tests), CPU-only, stdlib-only analysis; Reconciliation with A1d/A1e on every real working-harness task: identical pairable families, deficiency verdicts, slots, and dpo_pairs; idle ledger sums to the non-converting slot total (36); Known-answer statistics tests: Wilson intervals, rank-based Spearman under a nonlinear monotone map, partial correlation collapsing a pure confound to 0.0, a planted effect detected (p<0.01), a null not detected…; commit dec037ba93c203f580c290cb50d291515398acef; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
spectral-operator-compiler [scientific outcome=positive]: For the FNO spectral contraction einsum("bim,iom->bom"), the operator's cost is dominated by its lowering, not its arithmetic. On CPU (torch 2.13.0, 16 threads) the einsum baseline achieves only 27-75 GFLOP/s, i.e. 6-10% of what the same backend reaches on the identical contraction lowered to a mode-batched torch.bmm over mode-leading operands (118-954 GFLOP/s): a 4.36-14.49x contraction speedup and 1.71-5.67x end-to-end on the full spectral-conv forward, bit-identical (max_abs_err = 0.0). This is an order of magnitude larger than the 4/3x ceiling of the Karatsuba/Gauss 3M identity that four prior milestones were pursuing on the same operator. A thread-scaling control identifies the mechani…; validation: Full test suite: 330 passed (279 prior + 51 new), CPU, `.venv/bin/python -m pytest tests/ -q`; `python -m benchmarks.bench_contraction_lowering` run end to end; wrote benchmarks/results/contraction_lowering_cpu.json; `python -m benchmarks.bench_spectral_stage_profile` re-run after fixing its missing best_of_time import; wrote benchmarks/results/spectral_stage_profile_cpu.json; Numerical equivalence asserted in-harness before every timed comparison (assert_lowerings_equivalent), and end-to-end m…; commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: When deciding whether an arithmetic rewrite that trades multiplies for shared temporaries is worth applying, check whether its resource cost and its arithmetic benefit are functions of different problem dimensions. Here register pressure is an input-tile property and instruction savings are a reuse property, and because they do not interact the guard collapses from a per-shape benchmark sweep to two integers — no IR emission needed. The corollary is that a cost model seeing only issue slots is not merely imprecise for such rewrites but wrong in the enabling direction, and wrong by amounts large enough to matter. Before running a hardware sweep to tabulate a crossover, test whether the crossover factorizes. openevolve-moe-prototype: When a preference-pair or contrastive-data pipeline harvests pairs from sibling candidates sharing a parent, measure sibling outcome correlation before attributing low yield to model capability, budget, or a structural ceiling. Compare observed converting-family counts against a family-size-preserving within-stratum label reshuffle: this is assumption-light, needs no new runs, and cleanly separates 'the model rarely produces usable negatives' from 'the sampler produces one-sided families.' Equally reusable: a monotone rank test cannot detect a hump, so a non-significant Spearman rho for a rate that theory says should be unimodal is not evidence of no effect - test the band directly and label it post-hoc. And when a candidate explanatory variable correlates with elapsed search time, report both partial correlations; here that is what showed run length to be a proxy with no independent effect. Finally, a strong transition-level effect need not aggregate to the group level, so verify the aggregation step rather than assuming it. spectral-operator-compiler: Before proposing or evaluating an algebraic optimization of a tensor operator, measure the operator's achieved GFLOP/s against the backend's roofline and its scaling across thread counts. A schedule deficit is invisible to FLOP counting and to speedup ratios computed against the deficient baseline itself, and can be an order of magnitude larger than any arithmetic identity's entire ceiling — here a 14x lowering factor sat unmeasured across four milestones spent on a 4/3x identity. Flat throughput in thread count is the diagnostic signature of a schedule problem rather than a bandwidth or arithmetic one. A corollary for compiler legality models: this class of win may require changing *parameter storage layout*, not just rewriting the expression, because a per-call layout conversion whose cost is O(param size) can exceed the GEMM it enables at small batch; a pass restricted to local expression rewriting cannot claim it and may make things worse. Finally, a prior probe's regime classification can itself be an artifact of an incompetent baseline: the earlier finding that this contraction was memory/launch-bound (R < 3) was measured against a serial einsum.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Established for dense (all-GENERAL entries) complex constant-matrix contractions lowered to fp64 real arithmetic on an FMA machine, one contraction per thread, under a roofline model with perfect compute/memory overlap, no spill traffic above the 255-register cap, no L2 reuse or ILP modeling, and a swept rather than measured occupancy-to-bandwidth saturation knee. The 100% agreement figure is internal consistency between a closed-form rule and an emit-and-measure oracle sharing that model — it does not establish that the model matches GPU hardware. Does not apply to kernels with trivial or root-of-unity entries (FFT twiddles, radix-≤8 DFT base cases), which get no instruction win at all, nor to tiled or shared-memory-staged implementations, whose register accounting differs at large input counts.
openevolve-moe-prototype: Established on LLM-driven evolutionary program search (OpenEvolve-style) over 5 working-harness tasks with ~20 iterations each: 99 parent-child transitions, 30 pairable families, 5 conversions. The clustering result pools all transitions and is the robust one (p ~ 1e-3); the family-level null and the per-family-size gradient are underpowered (1-19 families per cell) and should be treated as directional. Parent quality is normalized against each task's observed score range at small N, so high-quality parents are an upper bound on true saturation and the saturation arm is if anything overstated. The independent-sibling curve is a null baseline, not a forecast of what raising family width would deliver. The causal source of sibling clustering (sampler temperature and near-duplicate proposals versus a parent's local optimization basin) is measured but not yet separated, so the actionable 'raise family width plus proposal diversity' recommendation remains untested.
spectral-operator-compiler: Measured on CPU (torch 2.13.0+cu130, 16 threads, single machine) for the 1-D FNO spectral contraction "bim,iom->bom" over five representative shapes (batch 4-32, channels 32-512, modes 16-64). The specific 4-14x magnitude is backend-, shape- and thread-count-specific and should not be assumed to transfer to GPU, where launch costs and the compute:bandwidth balance differ; the layout-ownership regression in particular depends on the batch:parameter size ratio. The methodological lesson — measure achieved throughput and thread scaling before trusting an arithmetic ceiling — is backend-agnostic and applies to any operator where an algebraic rewrite is being considered, notably the Gauss/Karatsuba 3M lowering decisions in sibling compiler projects. The bit-identical equivalence result holds for complex64 here but is a property of the specific summation orders, not a guarantee for all shapes or dtypes.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>src/lowering_policy.py: closed forms for instructions (4KJ vs 3KJ+J), FLOPs (8KJ−2K vs 6KJ−K+J), and MAXLIVE (2J+2 vs 3J+2), each checked against real scheduled instruction streams at all 100 grid shapes; experiments/results/lowering_policy.json: closed_forms_exact=true; 900 points, policy_agreement_pct=100.00, max_abs_advantage_error_pct=0.0, policy_max_regret_pct=0.00, naive_mean_regret_pct=7.82, naive_max_regret_pct=55.56, naive_harmful_pct=17.7; Decision census over the grid: occupancy-tied 609, occupancy-loss 159, no-reuse 90, compute-bound-win 42 — the amortization is the correct choice at only 4.7% of shapes, all with K ≥ 32; tests/test_lowering_policy.py: 368 tests including K-flatness of measured register pressure, the +J penalty and its K=1 boundary, field-by-field agreement of the closed-form cost with the measured evaluation, and oracle agreement across targets and knees; suite 1100 tests passing; Validation surfaced a genuine defect in the first closed form: an off-by-one at J=1 for both strategies, where a single input leaves no accumulation chain; mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb; https://github.com/mrcha033/mlir-fft-compiler/pull/1; src/conversion_quality_curve.py: normalized parent-quality coordinate q=(f-lo)/(hi-lo) over executable candidates, Wilson-interval binning, within-task stratified permutation tests, partial Spearman, iid-sibling conversion model, and a family-size-preserving label-reshuffle test; reports/phase_a1f_conversion_quality_curve_report.md and .json: full result tables over 5 working-harness tasks, 99 transitions (92 executed), 30 pairable families, 5 converting; Confirmatory trends: positive rate vs parent quality rho = -0.57 (p = 5e-05); no-op rate vs parent quality rho = +0.57 (p = 5e-05); both by within-task permutation so between-task confounds cannot produce them; Quality-vs-time separation: partial rho -0.51 (quality given iteration) versus +0.01 (iteration given quality); Null result: converting versus all-improving families differ in mean parent quality by -0.014, permutation p = 0.94; Sibling clustering: iid model expects 9.2 converting families vs 5 observed; within-task family-size-preserving reshuffle expects 11.8 vs 5 observed, one-sided p = 0.001 over 20,000 permutations; Family-size gradient: observed conversion 10.5%/16.7%/25.0% at k = 2/3/4 against iid predictions 21.3%/40.1%/53.9%; tests/test_conversion_quality_curve.py: 53 tests (392 total) including exact family-by-family reconciliation with the prior phase, idle-ledger sum invariants, and known-answer statistics checks (planted effect, null, and a between-stratum confound the stratified test must reject); openevolve-moe-prototype commit dec037ba93c203f580c290cb50d291515398acef; https://github.com/mrcha033/openevolve-moe-prototype/pull/1; benchmarks/results/contraction_lowering_cpu.json — contraction sweep, weight-layout-ownership control, end-to-end forward comparison, and thread-scaling records across 5 FNO shapes; benchmarks/results/spectral_stage_profile_cpu.json — per-stage forward decomposition giving f_c = 0.50-0.89, f_fft = 0.01-0.13, f_wp up to 0.49, and the free/4-3 Amdahl ceilings; src/contraction_lowering.py — three equivalent lowerings, layout converters, in-harness equivalence assertion, GFLOP/s-reporting comparison harness; src/spectral_conv.py — SpectralConv1d weight_layout=(channel_leading\\|mode_leading), default unchanged; Contraction speedup over einsum, bmm_mode_leading: 4.36x (B32 C32 M16), 4.46x (C64), 10.86x (C128), 14.49x (C256), 5.75x (C512); End-to-end SpectralConv1d forward speedup: 1.86x, 2.55x, 5.67x, 1.87x, 1.71x with max_abs_err = 0.0 at every shape; Thread scaling at B=16 Cin=Cout=128 M=64 (GFLOP/s): einsum 62.5/73.3/83.2/82.2/70.5 vs bmm 102.2/201.4/398.4/599.1/615.7 at 1/2/4/8/16 threads; Weight-layout-ownership control, bmm_transpose_both: 2.84x, 3.19x, 7.42x, 0.64x, 0.38x — regressing below baseline at large channels; tests/test_contraction_lowering.py and tests/test_spectral_stage_profile.py — 51 tests covering equivalence at degenerate and truncated shapes, gradient preservation, throughput accounting, and Amdahl algebra; full suite 330 passed; spectral-operator-compiler commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T22:19:25.899553Z</nowiki>
|updated_at=<nowiki>2026-07-19T22:19:26.464716Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-4c31f17a85f68e6b</nowiki>
|citation=<nowiki>src/lowering_policy.py: closed forms for instructions (4KJ vs 3KJ+J), FLOPs (8KJ−2K vs 6KJ−K+J), and MAXLIVE (2J+2 vs 3J+2), each checked against real scheduled instruction streams at all 100 grid shapes</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:25.899553Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_43e787be17ee558a</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/43e787be17ee558a95a44185fc17b758f0abacbb</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:26.122954Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_dec037ba93c203f5</nowiki>
|citation=<nowiki>GitHub mrcha033/openevolve-moe-prototype commit dec037ba93c203f580c290cb50d291515398acef</nowiki>
|url=<nowiki>https://github.com/mrcha033/openevolve-moe-prototype/commit/dec037ba93c203f580c290cb50d291515398acef</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:26.296187Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_7175ff452fb060e7</nowiki>
|citation=<nowiki>GitHub mrcha033/spectral-operator-compiler commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8</nowiki>
|url=<nowiki>https://github.com/mrcha033/spectral-operator-compiler/commit/7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:26.464716Z</nowiki>
}}

Lesson:research autopilot 20260719t210001z

2026-07-19T22:19:26Z

S3ResearchAgent: S3W1 k=e o=attach-7aa53aa1416d0b0f717c0023 r=943e0921ad370d06281e59359ab3a6f0 b=2755 t=82d3b6f390a1c6b99f60159a15111d2c h=4f7380e0a464d17ea0e3d4c058ba50cd

{{Lesson
|title=<nowiki>Research findings 20260719T210001Z: 0 negative/inconclusive, 1 mixed, 2 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: For a dense complex contraction y = W·x lowered to real arithmetic, the register cost and the instruction benefit of the Gauss/Karatsuba 3-multiply amortization occupy independent axes: peak live values are flat in the reuse factor K (MAXLIVE = 2J+2 for the 4-multiply fold, 3J+2 for the amortized 3-multiply form, where J is the input count), because outputs are accumulated one at a time and never co-reside, while the instruction saving (K−1)/(4K) is independent of J. Consequently the compute-vs-occupancy decision that previously required emitting, scheduling and measuring the IR reduces to a closed-form O(1) rule in (K, J, target): over 900 points (100 shapes × 3 GPU targets × 3 bandwidth-s…; validation: `.venv/bin/python -m pytest tests/ -q` → 1100 passed (368 new in tests/test_lowering_policy.py); `.venv/bin/python -m experiments.lowering_policy_validation` → closed forms exact at all 100 shapes; 900/900 decision agreement with the emit-and-measure oracle; max \\|advantage error\\| 0.0 pp; Closed-form instructions/FLOPs/MAXLIVE compared against real scheduled instruction streams at every grid shape, for both strategies; `analytic_cost` compared field-by-field (instructions, flops, bytes, regs…; next: GPU-adjudicate the two named regimes: compile both lowerings for a narrow (K = J = 32, policy predicts −55.6%, slot model predicts +24% — they disagree in sign) and a wide (K = J = 128, predicts +24.9%) dense complex contraction, and measure wall-clock, registers/thread, achieved occupancy, and spill load/store. If the modeled reversal at narrow shapes does not appear on hardware, the `occ_sat` knee or the no-spill-traffic assumption is the component to revise.; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler
- openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, the rate at which sibling candidates convert into DPO preference pairs is governed by two separable factors, and the intuitive one is not the binding one. First, child outcomes depend strongly on the parent's normalized position in its task's score range: the improvement rate falls with parent quality (Spearman rho = -0.57, p = 5e-05) while the no-op rate rises (+0.57, p = 5e-05), and the executable-regression rate that supplies a DPO negative is non-monotone, peaking in a mid-quality band (63.6% inside q in [0.4,0.6) vs 14.8% outside, p = 0.0013 post-hoc). This is a parent-quality effect and not a search-time effect: partial correlation for qualit…; validation: pytest tests/ — 392 passed in 2.6s (up from 339; 53 new tests), CPU-only, stdlib-only analysis; Reconciliation with A1d/A1e on every real working-harness task: identical pairable families, deficiency verdicts, slots, and dpo_pairs; idle ledger sums to the non-converting slot total (36); Known-answer statistics tests: Wilson intervals, rank-based Spearman under a nonlinear monotone map, partial correlation collapsing a pure confound to 0.0, a planted effect detected (p<0.01), a null not detected…; next: Separate the two candidate causes of sibling outcome clustering, now the sole load-bearing unknown. Sampler-side (low temperature / near-duplicate proposals) is directly addressable by config; objective-side (a parent's local basin admitting only one kind of edit) is not. The pilot checkpoints already store per-program code, so a code-similarity-versus-outcome-concordance analysis on existing trees can begin this split with no model server: if sibling pairs with near-identical code are the ones…; commit dec037ba93c203f580c290cb50d291515398acef; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
- spectral-operator-compiler [scientific outcome=positive]: For the FNO spectral contraction einsum("bim,iom->bom"), the operator's cost is dominated by its lowering, not its arithmetic. On CPU (torch 2.13.0, 16 threads) the einsum baseline achieves only 27-75 GFLOP/s, i.e. 6-10% of what the same backend reaches on the identical contraction lowered to a mode-batched torch.bmm over mode-leading operands (118-954 GFLOP/s): a 4.36-14.49x contraction speedup and 1.71-5.67x end-to-end on the full spectral-conv forward, bit-identical (max_abs_err = 0.0). This is an order of magnitude larger than the 4/3x ceiling of the Karatsuba/Gauss 3M identity that four prior milestones were pursuing on the same operator. A thread-scaling control identifies the mechani…; validation: Full test suite: 330 passed (279 prior + 51 new), CPU, `.venv/bin/python -m pytest tests/ -q`; `python -m benchmarks.bench_contraction_lowering` run end to end; wrote benchmarks/results/contraction_lowering_cpu.json; `python -m benchmarks.bench_spectral_stage_profile` re-run after fixing its missing best_of_time import; wrote benchmarks/results/spectral_stage_profile_cpu.json; Numerical equivalence asserted in-harness before every timed comparison (assert_lowerings_equivalent), and end-to-end m…; next: Combine the two independent levers measured this session and test whether they compose: a `mode_leading` SpectralConv1d that also caches the decayed weight (`weights * decay_mask`) at eval. The stage profile shows the weight recompute is f_wp = 0.31/0.49 at Cin=256/512 — exactly the shapes where the mode_leading end-to-end win is weakest (1.87x/1.71x) despite a 5.75-14.49x contraction win. Caching alone is independently measured at 1.93x/2.39x, bit-exactly. The falsifiable question is whether t…; commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: For a dense complex contraction y = W·x lowered to real arithmetic, the register cost and the instruction benefit of the Gauss/Karatsuba 3-multiply amortization occupy independent axes: peak live values are flat in the reuse factor K (MAXLIVE = 2J+2 for the 4-multiply fold, 3J+2 for the amortized 3-multiply form, where J is the input count), because outputs are accumulated one at a time and never co-reside, while the instruction saving (K−1)/(4K) is independent of J. Consequently the compute-vs-occupancy decision that previously required emitting, scheduling and measuring the IR reduces to a closed-form O(1) rule in (K, J, target): over 900 points (100 shapes × 3 GPU targets × 3 bandwidth-s…; validation: `.venv/bin/python -m pytest tests/ -q` → 1100 passed (368 new in tests/test_lowering_policy.py); `.venv/bin/python -m experiments.lowering_policy_validation` → closed forms exact at all 100 shapes; 900/900 decision agreement with the emit-and-measure oracle; max \\|advantage error\\| 0.0 pp; Closed-form instructions/FLOPs/MAXLIVE compared against real scheduled instruction streams at every grid shape, for both strategies; `analytic_cost` compared field-by-field (instructions, flops, bytes, regs…; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, the rate at which sibling candidates convert into DPO preference pairs is governed by two separable factors, and the intuitive one is not the binding one. First, child outcomes depend strongly on the parent's normalized position in its task's score range: the improvement rate falls with parent quality (Spearman rho = -0.57, p = 5e-05) while the no-op rate rises (+0.57, p = 5e-05), and the executable-regression rate that supplies a DPO negative is non-monotone, peaking in a mid-quality band (63.6% inside q in [0.4,0.6) vs 14.8% outside, p = 0.0013 post-hoc). This is a parent-quality effect and not a search-time effect: partial correlation for qualit…; validation: pytest tests/ — 392 passed in 2.6s (up from 339; 53 new tests), CPU-only, stdlib-only analysis; Reconciliation with A1d/A1e on every real working-harness task: identical pairable families, deficiency verdicts, slots, and dpo_pairs; idle ledger sums to the non-converting slot total (36); Known-answer statistics tests: Wilson intervals, rank-based Spearman under a nonlinear monotone map, partial correlation collapsing a pure confound to 0.0, a planted effect detected (p<0.01), a null not detected…; commit dec037ba93c203f580c290cb50d291515398acef; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
spectral-operator-compiler [scientific outcome=positive]: For the FNO spectral contraction einsum("bim,iom->bom"), the operator's cost is dominated by its lowering, not its arithmetic. On CPU (torch 2.13.0, 16 threads) the einsum baseline achieves only 27-75 GFLOP/s, i.e. 6-10% of what the same backend reaches on the identical contraction lowered to a mode-batched torch.bmm over mode-leading operands (118-954 GFLOP/s): a 4.36-14.49x contraction speedup and 1.71-5.67x end-to-end on the full spectral-conv forward, bit-identical (max_abs_err = 0.0). This is an order of magnitude larger than the 4/3x ceiling of the Karatsuba/Gauss 3M identity that four prior milestones were pursuing on the same operator. A thread-scaling control identifies the mechani…; validation: Full test suite: 330 passed (279 prior + 51 new), CPU, `.venv/bin/python -m pytest tests/ -q`; `python -m benchmarks.bench_contraction_lowering` run end to end; wrote benchmarks/results/contraction_lowering_cpu.json; `python -m benchmarks.bench_spectral_stage_profile` re-run after fixing its missing best_of_time import; wrote benchmarks/results/spectral_stage_profile_cpu.json; Numerical equivalence asserted in-harness before every timed comparison (assert_lowerings_equivalent), and end-to-end m…; commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: When deciding whether an arithmetic rewrite that trades multiplies for shared temporaries is worth applying, check whether its resource cost and its arithmetic benefit are functions of different problem dimensions. Here register pressure is an input-tile property and instruction savings are a reuse property, and because they do not interact the guard collapses from a per-shape benchmark sweep to two integers — no IR emission needed. The corollary is that a cost model seeing only issue slots is not merely imprecise for such rewrites but wrong in the enabling direction, and wrong by amounts large enough to matter. Before running a hardware sweep to tabulate a crossover, test whether the crossover factorizes. openevolve-moe-prototype: When a preference-pair or contrastive-data pipeline harvests pairs from sibling candidates sharing a parent, measure sibling outcome correlation before attributing low yield to model capability, budget, or a structural ceiling. Compare observed converting-family counts against a family-size-preserving within-stratum label reshuffle: this is assumption-light, needs no new runs, and cleanly separates 'the model rarely produces usable negatives' from 'the sampler produces one-sided families.' Equally reusable: a monotone rank test cannot detect a hump, so a non-significant Spearman rho for a rate that theory says should be unimodal is not evidence of no effect - test the band directly and label it post-hoc. And when a candidate explanatory variable correlates with elapsed search time, report both partial correlations; here that is what showed run length to be a proxy with no independent effect. Finally, a strong transition-level effect need not aggregate to the group level, so verify the aggregation step rather than assuming it. spectral-operator-compiler: Before proposing or evaluating an algebraic optimization of a tensor operator, measure the operator's achieved GFLOP/s against the backend's roofline and its scaling across thread counts. A schedule deficit is invisible to FLOP counting and to speedup ratios computed against the deficient baseline itself, and can be an order of magnitude larger than any arithmetic identity's entire ceiling — here a 14x lowering factor sat unmeasured across four milestones spent on a 4/3x identity. Flat throughput in thread count is the diagnostic signature of a schedule problem rather than a bandwidth or arithmetic one. A corollary for compiler legality models: this class of win may require changing *parameter storage layout*, not just rewriting the expression, because a per-call layout conversion whose cost is O(param size) can exceed the GEMM it enables at small batch; a pass restricted to local expression rewriting cannot claim it and may make things worse. Finally, a prior probe's regime classification can itself be an artifact of an incompetent baseline: the earlier finding that this contraction was memory/launch-bound (R < 3) was measured against a serial einsum.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Established for dense (all-GENERAL entries) complex constant-matrix contractions lowered to fp64 real arithmetic on an FMA machine, one contraction per thread, under a roofline model with perfect compute/memory overlap, no spill traffic above the 255-register cap, no L2 reuse or ILP modeling, and a swept rather than measured occupancy-to-bandwidth saturation knee. The 100% agreement figure is internal consistency between a closed-form rule and an emit-and-measure oracle sharing that model — it does not establish that the model matches GPU hardware. Does not apply to kernels with trivial or root-of-unity entries (FFT twiddles, radix-≤8 DFT base cases), which get no instruction win at all, nor to tiled or shared-memory-staged implementations, whose register accounting differs at large input counts.
openevolve-moe-prototype: Established on LLM-driven evolutionary program search (OpenEvolve-style) over 5 working-harness tasks with ~20 iterations each: 99 parent-child transitions, 30 pairable families, 5 conversions. The clustering result pools all transitions and is the robust one (p ~ 1e-3); the family-level null and the per-family-size gradient are underpowered (1-19 families per cell) and should be treated as directional. Parent quality is normalized against each task's observed score range at small N, so high-quality parents are an upper bound on true saturation and the saturation arm is if anything overstated. The independent-sibling curve is a null baseline, not a forecast of what raising family width would deliver. The causal source of sibling clustering (sampler temperature and near-duplicate proposals versus a parent's local optimization basin) is measured but not yet separated, so the actionable 'raise family width plus proposal diversity' recommendation remains untested.
spectral-operator-compiler: Measured on CPU (torch 2.13.0+cu130, 16 threads, single machine) for the 1-D FNO spectral contraction "bim,iom->bom" over five representative shapes (batch 4-32, channels 32-512, modes 16-64). The specific 4-14x magnitude is backend-, shape- and thread-count-specific and should not be assumed to transfer to GPU, where launch costs and the compute:bandwidth balance differ; the layout-ownership regression in particular depends on the batch:parameter size ratio. The methodological lesson — measure achieved throughput and thread scaling before trusting an arithmetic ceiling — is backend-agnostic and applies to any operator where an algebraic rewrite is being considered, notably the Gauss/Karatsuba 3M lowering decisions in sibling compiler projects. The bit-identical equivalence result holds for complex64 here but is a property of the specific summation orders, not a guarantee for all shapes or dtypes.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>src/lowering_policy.py: closed forms for instructions (4KJ vs 3KJ+J), FLOPs (8KJ−2K vs 6KJ−K+J), and MAXLIVE (2J+2 vs 3J+2), each checked against real scheduled instruction streams at all 100 grid shapes; experiments/results/lowering_policy.json: closed_forms_exact=true; 900 points, policy_agreement_pct=100.00, max_abs_advantage_error_pct=0.0, policy_max_regret_pct=0.00, naive_mean_regret_pct=7.82, naive_max_regret_pct=55.56, naive_harmful_pct=17.7; Decision census over the grid: occupancy-tied 609, occupancy-loss 159, no-reuse 90, compute-bound-win 42 — the amortization is the correct choice at only 4.7% of shapes, all with K ≥ 32; tests/test_lowering_policy.py: 368 tests including K-flatness of measured register pressure, the +J penalty and its K=1 boundary, field-by-field agreement of the closed-form cost with the measured evaluation, and oracle agreement across targets and knees; suite 1100 tests passing; Validation surfaced a genuine defect in the first closed form: an off-by-one at J=1 for both strategies, where a single input leaves no accumulation chain; mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb; https://github.com/mrcha033/mlir-fft-compiler/pull/1; src/conversion_quality_curve.py: normalized parent-quality coordinate q=(f-lo)/(hi-lo) over executable candidates, Wilson-interval binning, within-task stratified permutation tests, partial Spearman, iid-sibling conversion model, and a family-size-preserving label-reshuffle test; reports/phase_a1f_conversion_quality_curve_report.md and .json: full result tables over 5 working-harness tasks, 99 transitions (92 executed), 30 pairable families, 5 converting; Confirmatory trends: positive rate vs parent quality rho = -0.57 (p = 5e-05); no-op rate vs parent quality rho = +0.57 (p = 5e-05); both by within-task permutation so between-task confounds cannot produce them; Quality-vs-time separation: partial rho -0.51 (quality given iteration) versus +0.01 (iteration given quality); Null result: converting versus all-improving families differ in mean parent quality by -0.014, permutation p = 0.94; Sibling clustering: iid model expects 9.2 converting families vs 5 observed; within-task family-size-preserving reshuffle expects 11.8 vs 5 observed, one-sided p = 0.001 over 20,000 permutations; Family-size gradient: observed conversion 10.5%/16.7%/25.0% at k = 2/3/4 against iid predictions 21.3%/40.1%/53.9%; tests/test_conversion_quality_curve.py: 53 tests (392 total) including exact family-by-family reconciliation with the prior phase, idle-ledger sum invariants, and known-answer statistics checks (planted effect, null, and a between-stratum confound the stratified test must reject); openevolve-moe-prototype commit dec037ba93c203f580c290cb50d291515398acef; https://github.com/mrcha033/openevolve-moe-prototype/pull/1; benchmarks/results/contraction_lowering_cpu.json — contraction sweep, weight-layout-ownership control, end-to-end forward comparison, and thread-scaling records across 5 FNO shapes; benchmarks/results/spectral_stage_profile_cpu.json — per-stage forward decomposition giving f_c = 0.50-0.89, f_fft = 0.01-0.13, f_wp up to 0.49, and the free/4-3 Amdahl ceilings; src/contraction_lowering.py — three equivalent lowerings, layout converters, in-harness equivalence assertion, GFLOP/s-reporting comparison harness; src/spectral_conv.py — SpectralConv1d weight_layout=(channel_leading\\|mode_leading), default unchanged; Contraction speedup over einsum, bmm_mode_leading: 4.36x (B32 C32 M16), 4.46x (C64), 10.86x (C128), 14.49x (C256), 5.75x (C512); End-to-end SpectralConv1d forward speedup: 1.86x, 2.55x, 5.67x, 1.87x, 1.71x with max_abs_err = 0.0 at every shape; Thread scaling at B=16 Cin=Cout=128 M=64 (GFLOP/s): einsum 62.5/73.3/83.2/82.2/70.5 vs bmm 102.2/201.4/398.4/599.1/615.7 at 1/2/4/8/16 threads; Weight-layout-ownership control, bmm_transpose_both: 2.84x, 3.19x, 7.42x, 0.64x, 0.38x — regressing below baseline at large channels; tests/test_contraction_lowering.py and tests/test_spectral_stage_profile.py — 51 tests covering equivalence at degenerate and truncated shapes, gradient preservation, throughput accounting, and Amdahl algebra; full suite 330 passed; spectral-operator-compiler commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T22:19:25.899553Z</nowiki>
|updated_at=<nowiki>2026-07-19T22:19:26.296187Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-4c31f17a85f68e6b</nowiki>
|citation=<nowiki>src/lowering_policy.py: closed forms for instructions (4KJ vs 3KJ+J), FLOPs (8KJ−2K vs 6KJ−K+J), and MAXLIVE (2J+2 vs 3J+2), each checked against real scheduled instruction streams at all 100 grid shapes</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:25.899553Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_43e787be17ee558a</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/43e787be17ee558a95a44185fc17b758f0abacbb</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:26.122954Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_dec037ba93c203f5</nowiki>
|citation=<nowiki>GitHub mrcha033/openevolve-moe-prototype commit dec037ba93c203f580c290cb50d291515398acef</nowiki>
|url=<nowiki>https://github.com/mrcha033/openevolve-moe-prototype/commit/dec037ba93c203f580c290cb50d291515398acef</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:26.296187Z</nowiki>
}}

Lesson:research autopilot 20260719t210001z

2026-07-19T22:19:26Z

S3ResearchAgent: S3W1 k=e o=attach-6a080c85ab2d86865d46856b r=d852b09769fcfc11e29f06344f73c887 b=2754 t=83f0639c15fa68b07a9c483c67a6dba8 h=10701b162e640624a35e785b832a4cfa

{{Lesson
|title=<nowiki>Research findings 20260719T210001Z: 0 negative/inconclusive, 1 mixed, 2 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: For a dense complex contraction y = W·x lowered to real arithmetic, the register cost and the instruction benefit of the Gauss/Karatsuba 3-multiply amortization occupy independent axes: peak live values are flat in the reuse factor K (MAXLIVE = 2J+2 for the 4-multiply fold, 3J+2 for the amortized 3-multiply form, where J is the input count), because outputs are accumulated one at a time and never co-reside, while the instruction saving (K−1)/(4K) is independent of J. Consequently the compute-vs-occupancy decision that previously required emitting, scheduling and measuring the IR reduces to a closed-form O(1) rule in (K, J, target): over 900 points (100 shapes × 3 GPU targets × 3 bandwidth-s…; validation: `.venv/bin/python -m pytest tests/ -q` → 1100 passed (368 new in tests/test_lowering_policy.py); `.venv/bin/python -m experiments.lowering_policy_validation` → closed forms exact at all 100 shapes; 900/900 decision agreement with the emit-and-measure oracle; max \\|advantage error\\| 0.0 pp; Closed-form instructions/FLOPs/MAXLIVE compared against real scheduled instruction streams at every grid shape, for both strategies; `analytic_cost` compared field-by-field (instructions, flops, bytes, regs…; next: GPU-adjudicate the two named regimes: compile both lowerings for a narrow (K = J = 32, policy predicts −55.6%, slot model predicts +24% — they disagree in sign) and a wide (K = J = 128, predicts +24.9%) dense complex contraction, and measure wall-clock, registers/thread, achieved occupancy, and spill load/store. If the modeled reversal at narrow shapes does not appear on hardware, the `occ_sat` knee or the no-spill-traffic assumption is the component to revise.; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler
- openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, the rate at which sibling candidates convert into DPO preference pairs is governed by two separable factors, and the intuitive one is not the binding one. First, child outcomes depend strongly on the parent's normalized position in its task's score range: the improvement rate falls with parent quality (Spearman rho = -0.57, p = 5e-05) while the no-op rate rises (+0.57, p = 5e-05), and the executable-regression rate that supplies a DPO negative is non-monotone, peaking in a mid-quality band (63.6% inside q in [0.4,0.6) vs 14.8% outside, p = 0.0013 post-hoc). This is a parent-quality effect and not a search-time effect: partial correlation for qualit…; validation: pytest tests/ — 392 passed in 2.6s (up from 339; 53 new tests), CPU-only, stdlib-only analysis; Reconciliation with A1d/A1e on every real working-harness task: identical pairable families, deficiency verdicts, slots, and dpo_pairs; idle ledger sums to the non-converting slot total (36); Known-answer statistics tests: Wilson intervals, rank-based Spearman under a nonlinear monotone map, partial correlation collapsing a pure confound to 0.0, a planted effect detected (p<0.01), a null not detected…; next: Separate the two candidate causes of sibling outcome clustering, now the sole load-bearing unknown. Sampler-side (low temperature / near-duplicate proposals) is directly addressable by config; objective-side (a parent's local basin admitting only one kind of edit) is not. The pilot checkpoints already store per-program code, so a code-similarity-versus-outcome-concordance analysis on existing trees can begin this split with no model server: if sibling pairs with near-identical code are the ones…; commit dec037ba93c203f580c290cb50d291515398acef; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
- spectral-operator-compiler [scientific outcome=positive]: For the FNO spectral contraction einsum("bim,iom->bom"), the operator's cost is dominated by its lowering, not its arithmetic. On CPU (torch 2.13.0, 16 threads) the einsum baseline achieves only 27-75 GFLOP/s, i.e. 6-10% of what the same backend reaches on the identical contraction lowered to a mode-batched torch.bmm over mode-leading operands (118-954 GFLOP/s): a 4.36-14.49x contraction speedup and 1.71-5.67x end-to-end on the full spectral-conv forward, bit-identical (max_abs_err = 0.0). This is an order of magnitude larger than the 4/3x ceiling of the Karatsuba/Gauss 3M identity that four prior milestones were pursuing on the same operator. A thread-scaling control identifies the mechani…; validation: Full test suite: 330 passed (279 prior + 51 new), CPU, `.venv/bin/python -m pytest tests/ -q`; `python -m benchmarks.bench_contraction_lowering` run end to end; wrote benchmarks/results/contraction_lowering_cpu.json; `python -m benchmarks.bench_spectral_stage_profile` re-run after fixing its missing best_of_time import; wrote benchmarks/results/spectral_stage_profile_cpu.json; Numerical equivalence asserted in-harness before every timed comparison (assert_lowerings_equivalent), and end-to-end m…; next: Combine the two independent levers measured this session and test whether they compose: a `mode_leading` SpectralConv1d that also caches the decayed weight (`weights * decay_mask`) at eval. The stage profile shows the weight recompute is f_wp = 0.31/0.49 at Cin=256/512 — exactly the shapes where the mode_leading end-to-end win is weakest (1.87x/1.71x) despite a 5.75-14.49x contraction win. Caching alone is independently measured at 1.93x/2.39x, bit-exactly. The falsifiable question is whether t…; commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: For a dense complex contraction y = W·x lowered to real arithmetic, the register cost and the instruction benefit of the Gauss/Karatsuba 3-multiply amortization occupy independent axes: peak live values are flat in the reuse factor K (MAXLIVE = 2J+2 for the 4-multiply fold, 3J+2 for the amortized 3-multiply form, where J is the input count), because outputs are accumulated one at a time and never co-reside, while the instruction saving (K−1)/(4K) is independent of J. Consequently the compute-vs-occupancy decision that previously required emitting, scheduling and measuring the IR reduces to a closed-form O(1) rule in (K, J, target): over 900 points (100 shapes × 3 GPU targets × 3 bandwidth-s…; validation: `.venv/bin/python -m pytest tests/ -q` → 1100 passed (368 new in tests/test_lowering_policy.py); `.venv/bin/python -m experiments.lowering_policy_validation` → closed forms exact at all 100 shapes; 900/900 decision agreement with the emit-and-measure oracle; max \\|advantage error\\| 0.0 pp; Closed-form instructions/FLOPs/MAXLIVE compared against real scheduled instruction streams at every grid shape, for both strategies; `analytic_cost` compared field-by-field (instructions, flops, bytes, regs…; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, the rate at which sibling candidates convert into DPO preference pairs is governed by two separable factors, and the intuitive one is not the binding one. First, child outcomes depend strongly on the parent's normalized position in its task's score range: the improvement rate falls with parent quality (Spearman rho = -0.57, p = 5e-05) while the no-op rate rises (+0.57, p = 5e-05), and the executable-regression rate that supplies a DPO negative is non-monotone, peaking in a mid-quality band (63.6% inside q in [0.4,0.6) vs 14.8% outside, p = 0.0013 post-hoc). This is a parent-quality effect and not a search-time effect: partial correlation for qualit…; validation: pytest tests/ — 392 passed in 2.6s (up from 339; 53 new tests), CPU-only, stdlib-only analysis; Reconciliation with A1d/A1e on every real working-harness task: identical pairable families, deficiency verdicts, slots, and dpo_pairs; idle ledger sums to the non-converting slot total (36); Known-answer statistics tests: Wilson intervals, rank-based Spearman under a nonlinear monotone map, partial correlation collapsing a pure confound to 0.0, a planted effect detected (p<0.01), a null not detected…; commit dec037ba93c203f580c290cb50d291515398acef; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
spectral-operator-compiler [scientific outcome=positive]: For the FNO spectral contraction einsum("bim,iom->bom"), the operator's cost is dominated by its lowering, not its arithmetic. On CPU (torch 2.13.0, 16 threads) the einsum baseline achieves only 27-75 GFLOP/s, i.e. 6-10% of what the same backend reaches on the identical contraction lowered to a mode-batched torch.bmm over mode-leading operands (118-954 GFLOP/s): a 4.36-14.49x contraction speedup and 1.71-5.67x end-to-end on the full spectral-conv forward, bit-identical (max_abs_err = 0.0). This is an order of magnitude larger than the 4/3x ceiling of the Karatsuba/Gauss 3M identity that four prior milestones were pursuing on the same operator. A thread-scaling control identifies the mechani…; validation: Full test suite: 330 passed (279 prior + 51 new), CPU, `.venv/bin/python -m pytest tests/ -q`; `python -m benchmarks.bench_contraction_lowering` run end to end; wrote benchmarks/results/contraction_lowering_cpu.json; `python -m benchmarks.bench_spectral_stage_profile` re-run after fixing its missing best_of_time import; wrote benchmarks/results/spectral_stage_profile_cpu.json; Numerical equivalence asserted in-harness before every timed comparison (assert_lowerings_equivalent), and end-to-end m…; commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: When deciding whether an arithmetic rewrite that trades multiplies for shared temporaries is worth applying, check whether its resource cost and its arithmetic benefit are functions of different problem dimensions. Here register pressure is an input-tile property and instruction savings are a reuse property, and because they do not interact the guard collapses from a per-shape benchmark sweep to two integers — no IR emission needed. The corollary is that a cost model seeing only issue slots is not merely imprecise for such rewrites but wrong in the enabling direction, and wrong by amounts large enough to matter. Before running a hardware sweep to tabulate a crossover, test whether the crossover factorizes. openevolve-moe-prototype: When a preference-pair or contrastive-data pipeline harvests pairs from sibling candidates sharing a parent, measure sibling outcome correlation before attributing low yield to model capability, budget, or a structural ceiling. Compare observed converting-family counts against a family-size-preserving within-stratum label reshuffle: this is assumption-light, needs no new runs, and cleanly separates 'the model rarely produces usable negatives' from 'the sampler produces one-sided families.' Equally reusable: a monotone rank test cannot detect a hump, so a non-significant Spearman rho for a rate that theory says should be unimodal is not evidence of no effect - test the band directly and label it post-hoc. And when a candidate explanatory variable correlates with elapsed search time, report both partial correlations; here that is what showed run length to be a proxy with no independent effect. Finally, a strong transition-level effect need not aggregate to the group level, so verify the aggregation step rather than assuming it. spectral-operator-compiler: Before proposing or evaluating an algebraic optimization of a tensor operator, measure the operator's achieved GFLOP/s against the backend's roofline and its scaling across thread counts. A schedule deficit is invisible to FLOP counting and to speedup ratios computed against the deficient baseline itself, and can be an order of magnitude larger than any arithmetic identity's entire ceiling — here a 14x lowering factor sat unmeasured across four milestones spent on a 4/3x identity. Flat throughput in thread count is the diagnostic signature of a schedule problem rather than a bandwidth or arithmetic one. A corollary for compiler legality models: this class of win may require changing *parameter storage layout*, not just rewriting the expression, because a per-call layout conversion whose cost is O(param size) can exceed the GEMM it enables at small batch; a pass restricted to local expression rewriting cannot claim it and may make things worse. Finally, a prior probe's regime classification can itself be an artifact of an incompetent baseline: the earlier finding that this contraction was memory/launch-bound (R < 3) was measured against a serial einsum.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Established for dense (all-GENERAL entries) complex constant-matrix contractions lowered to fp64 real arithmetic on an FMA machine, one contraction per thread, under a roofline model with perfect compute/memory overlap, no spill traffic above the 255-register cap, no L2 reuse or ILP modeling, and a swept rather than measured occupancy-to-bandwidth saturation knee. The 100% agreement figure is internal consistency between a closed-form rule and an emit-and-measure oracle sharing that model — it does not establish that the model matches GPU hardware. Does not apply to kernels with trivial or root-of-unity entries (FFT twiddles, radix-≤8 DFT base cases), which get no instruction win at all, nor to tiled or shared-memory-staged implementations, whose register accounting differs at large input counts.
openevolve-moe-prototype: Established on LLM-driven evolutionary program search (OpenEvolve-style) over 5 working-harness tasks with ~20 iterations each: 99 parent-child transitions, 30 pairable families, 5 conversions. The clustering result pools all transitions and is the robust one (p ~ 1e-3); the family-level null and the per-family-size gradient are underpowered (1-19 families per cell) and should be treated as directional. Parent quality is normalized against each task's observed score range at small N, so high-quality parents are an upper bound on true saturation and the saturation arm is if anything overstated. The independent-sibling curve is a null baseline, not a forecast of what raising family width would deliver. The causal source of sibling clustering (sampler temperature and near-duplicate proposals versus a parent's local optimization basin) is measured but not yet separated, so the actionable 'raise family width plus proposal diversity' recommendation remains untested.
spectral-operator-compiler: Measured on CPU (torch 2.13.0+cu130, 16 threads, single machine) for the 1-D FNO spectral contraction "bim,iom->bom" over five representative shapes (batch 4-32, channels 32-512, modes 16-64). The specific 4-14x magnitude is backend-, shape- and thread-count-specific and should not be assumed to transfer to GPU, where launch costs and the compute:bandwidth balance differ; the layout-ownership regression in particular depends on the batch:parameter size ratio. The methodological lesson — measure achieved throughput and thread scaling before trusting an arithmetic ceiling — is backend-agnostic and applies to any operator where an algebraic rewrite is being considered, notably the Gauss/Karatsuba 3M lowering decisions in sibling compiler projects. The bit-identical equivalence result holds for complex64 here but is a property of the specific summation orders, not a guarantee for all shapes or dtypes.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>src/lowering_policy.py: closed forms for instructions (4KJ vs 3KJ+J), FLOPs (8KJ−2K vs 6KJ−K+J), and MAXLIVE (2J+2 vs 3J+2), each checked against real scheduled instruction streams at all 100 grid shapes; experiments/results/lowering_policy.json: closed_forms_exact=true; 900 points, policy_agreement_pct=100.00, max_abs_advantage_error_pct=0.0, policy_max_regret_pct=0.00, naive_mean_regret_pct=7.82, naive_max_regret_pct=55.56, naive_harmful_pct=17.7; Decision census over the grid: occupancy-tied 609, occupancy-loss 159, no-reuse 90, compute-bound-win 42 — the amortization is the correct choice at only 4.7% of shapes, all with K ≥ 32; tests/test_lowering_policy.py: 368 tests including K-flatness of measured register pressure, the +J penalty and its K=1 boundary, field-by-field agreement of the closed-form cost with the measured evaluation, and oracle agreement across targets and knees; suite 1100 tests passing; Validation surfaced a genuine defect in the first closed form: an off-by-one at J=1 for both strategies, where a single input leaves no accumulation chain; mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb; https://github.com/mrcha033/mlir-fft-compiler/pull/1; src/conversion_quality_curve.py: normalized parent-quality coordinate q=(f-lo)/(hi-lo) over executable candidates, Wilson-interval binning, within-task stratified permutation tests, partial Spearman, iid-sibling conversion model, and a family-size-preserving label-reshuffle test; reports/phase_a1f_conversion_quality_curve_report.md and .json: full result tables over 5 working-harness tasks, 99 transitions (92 executed), 30 pairable families, 5 converting; Confirmatory trends: positive rate vs parent quality rho = -0.57 (p = 5e-05); no-op rate vs parent quality rho = +0.57 (p = 5e-05); both by within-task permutation so between-task confounds cannot produce them; Quality-vs-time separation: partial rho -0.51 (quality given iteration) versus +0.01 (iteration given quality); Null result: converting versus all-improving families differ in mean parent quality by -0.014, permutation p = 0.94; Sibling clustering: iid model expects 9.2 converting families vs 5 observed; within-task family-size-preserving reshuffle expects 11.8 vs 5 observed, one-sided p = 0.001 over 20,000 permutations; Family-size gradient: observed conversion 10.5%/16.7%/25.0% at k = 2/3/4 against iid predictions 21.3%/40.1%/53.9%; tests/test_conversion_quality_curve.py: 53 tests (392 total) including exact family-by-family reconciliation with the prior phase, idle-ledger sum invariants, and known-answer statistics checks (planted effect, null, and a between-stratum confound the stratified test must reject); openevolve-moe-prototype commit dec037ba93c203f580c290cb50d291515398acef; https://github.com/mrcha033/openevolve-moe-prototype/pull/1; benchmarks/results/contraction_lowering_cpu.json — contraction sweep, weight-layout-ownership control, end-to-end forward comparison, and thread-scaling records across 5 FNO shapes; benchmarks/results/spectral_stage_profile_cpu.json — per-stage forward decomposition giving f_c = 0.50-0.89, f_fft = 0.01-0.13, f_wp up to 0.49, and the free/4-3 Amdahl ceilings; src/contraction_lowering.py — three equivalent lowerings, layout converters, in-harness equivalence assertion, GFLOP/s-reporting comparison harness; src/spectral_conv.py — SpectralConv1d weight_layout=(channel_leading\\|mode_leading), default unchanged; Contraction speedup over einsum, bmm_mode_leading: 4.36x (B32 C32 M16), 4.46x (C64), 10.86x (C128), 14.49x (C256), 5.75x (C512); End-to-end SpectralConv1d forward speedup: 1.86x, 2.55x, 5.67x, 1.87x, 1.71x with max_abs_err = 0.0 at every shape; Thread scaling at B=16 Cin=Cout=128 M=64 (GFLOP/s): einsum 62.5/73.3/83.2/82.2/70.5 vs bmm 102.2/201.4/398.4/599.1/615.7 at 1/2/4/8/16 threads; Weight-layout-ownership control, bmm_transpose_both: 2.84x, 3.19x, 7.42x, 0.64x, 0.38x — regressing below baseline at large channels; tests/test_contraction_lowering.py and tests/test_spectral_stage_profile.py — 51 tests covering equivalence at degenerate and truncated shapes, gradient preservation, throughput accounting, and Amdahl algebra; full suite 330 passed; spectral-operator-compiler commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T22:19:25.899553Z</nowiki>
|updated_at=<nowiki>2026-07-19T22:19:26.122954Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-4c31f17a85f68e6b</nowiki>
|citation=<nowiki>src/lowering_policy.py: closed forms for instructions (4KJ vs 3KJ+J), FLOPs (8KJ−2K vs 6KJ−K+J), and MAXLIVE (2J+2 vs 3J+2), each checked against real scheduled instruction streams at all 100 grid shapes</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:25.899553Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_43e787be17ee558a</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/43e787be17ee558a95a44185fc17b758f0abacbb</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:26.122954Z</nowiki>
}}

Lesson:research autopilot 20260719t210001z

2026-07-19T22:19:25Z

S3ResearchAgent: S3W1 k=c o=create-4c31f17a85f68e6bee51f94c r=2e987599ada4be21a4fa6ebabc92b5d1 b=0 t=a19b0ec682dd170886814170c4570a76 h=d2fbc3e3002353d8514c9b2a749e49e1

{{Lesson
|title=<nowiki>Research findings 20260719T210001Z: 0 negative/inconclusive, 1 mixed, 2 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=positive]: For a dense complex contraction y = W·x lowered to real arithmetic, the register cost and the instruction benefit of the Gauss/Karatsuba 3-multiply amortization occupy independent axes: peak live values are flat in the reuse factor K (MAXLIVE = 2J+2 for the 4-multiply fold, 3J+2 for the amortized 3-multiply form, where J is the input count), because outputs are accumulated one at a time and never co-reside, while the instruction saving (K−1)/(4K) is independent of J. Consequently the compute-vs-occupancy decision that previously required emitting, scheduling and measuring the IR reduces to a closed-form O(1) rule in (K, J, target): over 900 points (100 shapes × 3 GPU targets × 3 bandwidth-s…; validation: `.venv/bin/python -m pytest tests/ -q` → 1100 passed (368 new in tests/test_lowering_policy.py); `.venv/bin/python -m experiments.lowering_policy_validation` → closed forms exact at all 100 shapes; 900/900 decision agreement with the emit-and-measure oracle; max \\|advantage error\\| 0.0 pp; Closed-form instructions/FLOPs/MAXLIVE compared against real scheduled instruction streams at every grid shape, for both strategies; `analytic_cost` compared field-by-field (instructions, flops, bytes, regs…; next: GPU-adjudicate the two named regimes: compile both lowerings for a narrow (K = J = 32, policy predicts −55.6%, slot model predicts +24% — they disagree in sign) and a wide (K = J = 128, predicts +24.9%) dense complex contraction, and measure wall-clock, registers/thread, achieved occupancy, and spill load/store. If the modeled reversal at narrow shapes does not appear on hardware, the `occ_sat` knee or the no-spill-traffic assumption is the component to revise.; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler
- openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, the rate at which sibling candidates convert into DPO preference pairs is governed by two separable factors, and the intuitive one is not the binding one. First, child outcomes depend strongly on the parent's normalized position in its task's score range: the improvement rate falls with parent quality (Spearman rho = -0.57, p = 5e-05) while the no-op rate rises (+0.57, p = 5e-05), and the executable-regression rate that supplies a DPO negative is non-monotone, peaking in a mid-quality band (63.6% inside q in [0.4,0.6) vs 14.8% outside, p = 0.0013 post-hoc). This is a parent-quality effect and not a search-time effect: partial correlation for qualit…; validation: pytest tests/ — 392 passed in 2.6s (up from 339; 53 new tests), CPU-only, stdlib-only analysis; Reconciliation with A1d/A1e on every real working-harness task: identical pairable families, deficiency verdicts, slots, and dpo_pairs; idle ledger sums to the non-converting slot total (36); Known-answer statistics tests: Wilson intervals, rank-based Spearman under a nonlinear monotone map, partial correlation collapsing a pure confound to 0.0, a planted effect detected (p<0.01), a null not detected…; next: Separate the two candidate causes of sibling outcome clustering, now the sole load-bearing unknown. Sampler-side (low temperature / near-duplicate proposals) is directly addressable by config; objective-side (a parent's local basin admitting only one kind of edit) is not. The pilot checkpoints already store per-program code, so a code-similarity-versus-outcome-concordance analysis on existing trees can begin this split with no model server: if sibling pairs with near-identical code are the ones…; commit dec037ba93c203f580c290cb50d291515398acef; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
- spectral-operator-compiler [scientific outcome=positive]: For the FNO spectral contraction einsum("bim,iom->bom"), the operator's cost is dominated by its lowering, not its arithmetic. On CPU (torch 2.13.0, 16 threads) the einsum baseline achieves only 27-75 GFLOP/s, i.e. 6-10% of what the same backend reaches on the identical contraction lowered to a mode-batched torch.bmm over mode-leading operands (118-954 GFLOP/s): a 4.36-14.49x contraction speedup and 1.71-5.67x end-to-end on the full spectral-conv forward, bit-identical (max_abs_err = 0.0). This is an order of magnitude larger than the 4/3x ceiling of the Karatsuba/Gauss 3M identity that four prior milestones were pursuing on the same operator. A thread-scaling control identifies the mechani…; validation: Full test suite: 330 passed (279 prior + 51 new), CPU, `.venv/bin/python -m pytest tests/ -q`; `python -m benchmarks.bench_contraction_lowering` run end to end; wrote benchmarks/results/contraction_lowering_cpu.json; `python -m benchmarks.bench_spectral_stage_profile` re-run after fixing its missing best_of_time import; wrote benchmarks/results/spectral_stage_profile_cpu.json; Numerical equivalence asserted in-harness before every timed comparison (assert_lowerings_equivalent), and end-to-end m…; next: Combine the two independent levers measured this session and test whether they compose: a `mode_leading` SpectralConv1d that also caches the decayed weight (`weights * decay_mask`) at eval. The stage profile shows the weight recompute is f_wp = 0.31/0.49 at Cin=256/512 — exactly the shapes where the mode_leading end-to-end win is weakest (1.87x/1.71x) despite a 5.75-14.49x contraction win. Caching alone is independently measured at 1.93x/2.39x, bit-exactly. The falsifiable question is whether t…; commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=positive]: For a dense complex contraction y = W·x lowered to real arithmetic, the register cost and the instruction benefit of the Gauss/Karatsuba 3-multiply amortization occupy independent axes: peak live values are flat in the reuse factor K (MAXLIVE = 2J+2 for the 4-multiply fold, 3J+2 for the amortized 3-multiply form, where J is the input count), because outputs are accumulated one at a time and never co-reside, while the instruction saving (K−1)/(4K) is independent of J. Consequently the compute-vs-occupancy decision that previously required emitting, scheduling and measuring the IR reduces to a closed-form O(1) rule in (K, J, target): over 900 points (100 shapes × 3 GPU targets × 3 bandwidth-s…; validation: `.venv/bin/python -m pytest tests/ -q` → 1100 passed (368 new in tests/test_lowering_policy.py); `.venv/bin/python -m experiments.lowering_policy_validation` → closed forms exact at all 100 shapes; 900/900 decision agreement with the emit-and-measure oracle; max \\|advantage error\\| 0.0 pp; Closed-form instructions/FLOPs/MAXLIVE compared against real scheduled instruction streams at every grid shape, for both strategies; `analytic_cost` compared field-by-field (instructions, flops, bytes, regs…; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler
openevolve-moe-prototype [scientific outcome=mixed]: In LLM-driven evolutionary program search, the rate at which sibling candidates convert into DPO preference pairs is governed by two separable factors, and the intuitive one is not the binding one. First, child outcomes depend strongly on the parent's normalized position in its task's score range: the improvement rate falls with parent quality (Spearman rho = -0.57, p = 5e-05) while the no-op rate rises (+0.57, p = 5e-05), and the executable-regression rate that supplies a DPO negative is non-monotone, peaking in a mid-quality band (63.6% inside q in [0.4,0.6) vs 14.8% outside, p = 0.0013 post-hoc). This is a parent-quality effect and not a search-time effect: partial correlation for qualit…; validation: pytest tests/ — 392 passed in 2.6s (up from 339; 53 new tests), CPU-only, stdlib-only analysis; Reconciliation with A1d/A1e on every real working-harness task: identical pairable families, deficiency verdicts, slots, and dpo_pairs; idle ledger sums to the non-converting slot total (36); Known-answer statistics tests: Wilson intervals, rank-based Spearman under a nonlinear monotone map, partial correlation collapsing a pure confound to 0.0, a planted effect detected (p<0.01), a null not detected…; commit dec037ba93c203f580c290cb50d291515398acef; PR https://github.com/mrcha033/openevolve-moe-prototype/pull/1
spectral-operator-compiler [scientific outcome=positive]: For the FNO spectral contraction einsum("bim,iom->bom"), the operator's cost is dominated by its lowering, not its arithmetic. On CPU (torch 2.13.0, 16 threads) the einsum baseline achieves only 27-75 GFLOP/s, i.e. 6-10% of what the same backend reaches on the identical contraction lowered to a mode-batched torch.bmm over mode-leading operands (118-954 GFLOP/s): a 4.36-14.49x contraction speedup and 1.71-5.67x end-to-end on the full spectral-conv forward, bit-identical (max_abs_err = 0.0). This is an order of magnitude larger than the 4/3x ceiling of the Karatsuba/Gauss 3M identity that four prior milestones were pursuing on the same operator. A thread-scaling control identifies the mechani…; validation: Full test suite: 330 passed (279 prior + 51 new), CPU, `.venv/bin/python -m pytest tests/ -q`; `python -m benchmarks.bench_contraction_lowering` run end to end; wrote benchmarks/results/contraction_lowering_cpu.json; `python -m benchmarks.bench_spectral_stage_profile` re-run after fixing its missing best_of_time import; wrote benchmarks/results/spectral_stage_profile_cpu.json; Numerical equivalence asserted in-harness before every timed comparison (assert_lowerings_equivalent), and end-to-end m…; commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: When deciding whether an arithmetic rewrite that trades multiplies for shared temporaries is worth applying, check whether its resource cost and its arithmetic benefit are functions of different problem dimensions. Here register pressure is an input-tile property and instruction savings are a reuse property, and because they do not interact the guard collapses from a per-shape benchmark sweep to two integers — no IR emission needed. The corollary is that a cost model seeing only issue slots is not merely imprecise for such rewrites but wrong in the enabling direction, and wrong by amounts large enough to matter. Before running a hardware sweep to tabulate a crossover, test whether the crossover factorizes. openevolve-moe-prototype: When a preference-pair or contrastive-data pipeline harvests pairs from sibling candidates sharing a parent, measure sibling outcome correlation before attributing low yield to model capability, budget, or a structural ceiling. Compare observed converting-family counts against a family-size-preserving within-stratum label reshuffle: this is assumption-light, needs no new runs, and cleanly separates 'the model rarely produces usable negatives' from 'the sampler produces one-sided families.' Equally reusable: a monotone rank test cannot detect a hump, so a non-significant Spearman rho for a rate that theory says should be unimodal is not evidence of no effect - test the band directly and label it post-hoc. And when a candidate explanatory variable correlates with elapsed search time, report both partial correlations; here that is what showed run length to be a proxy with no independent effect. Finally, a strong transition-level effect need not aggregate to the group level, so verify the aggregation step rather than assuming it. spectral-operator-compiler: Before proposing or evaluating an algebraic optimization of a tensor operator, measure the operator's achieved GFLOP/s against the backend's roofline and its scaling across thread counts. A schedule deficit is invisible to FLOP counting and to speedup ratios computed against the deficient baseline itself, and can be an order of magnitude larger than any arithmetic identity's entire ceiling — here a 14x lowering factor sat unmeasured across four milestones spent on a 4/3x identity. Flat throughput in thread count is the diagnostic signature of a schedule problem rather than a bandwidth or arithmetic one. A corollary for compiler legality models: this class of win may require changing *parameter storage layout*, not just rewriting the expression, because a per-call layout conversion whose cost is O(param size) can exceed the GEMM it enables at small batch; a pass restricted to local expression rewriting cannot claim it and may make things worse. Finally, a prior probe's regime classification can itself be an artifact of an incompetent baseline: the earlier finding that this contraction was memory/launch-bound (R < 3) was measured against a serial einsum.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Established for dense (all-GENERAL entries) complex constant-matrix contractions lowered to fp64 real arithmetic on an FMA machine, one contraction per thread, under a roofline model with perfect compute/memory overlap, no spill traffic above the 255-register cap, no L2 reuse or ILP modeling, and a swept rather than measured occupancy-to-bandwidth saturation knee. The 100% agreement figure is internal consistency between a closed-form rule and an emit-and-measure oracle sharing that model — it does not establish that the model matches GPU hardware. Does not apply to kernels with trivial or root-of-unity entries (FFT twiddles, radix-≤8 DFT base cases), which get no instruction win at all, nor to tiled or shared-memory-staged implementations, whose register accounting differs at large input counts.
openevolve-moe-prototype: Established on LLM-driven evolutionary program search (OpenEvolve-style) over 5 working-harness tasks with ~20 iterations each: 99 parent-child transitions, 30 pairable families, 5 conversions. The clustering result pools all transitions and is the robust one (p ~ 1e-3); the family-level null and the per-family-size gradient are underpowered (1-19 families per cell) and should be treated as directional. Parent quality is normalized against each task's observed score range at small N, so high-quality parents are an upper bound on true saturation and the saturation arm is if anything overstated. The independent-sibling curve is a null baseline, not a forecast of what raising family width would deliver. The causal source of sibling clustering (sampler temperature and near-duplicate proposals versus a parent's local optimization basin) is measured but not yet separated, so the actionable 'raise family width plus proposal diversity' recommendation remains untested.
spectral-operator-compiler: Measured on CPU (torch 2.13.0+cu130, 16 threads, single machine) for the 1-D FNO spectral contraction "bim,iom->bom" over five representative shapes (batch 4-32, channels 32-512, modes 16-64). The specific 4-14x magnitude is backend-, shape- and thread-count-specific and should not be assumed to transfer to GPU, where launch costs and the compute:bandwidth balance differ; the layout-ownership regression in particular depends on the batch:parameter size ratio. The methodological lesson — measure achieved throughput and thread scaling before trusting an arithmetic ceiling — is backend-agnostic and applies to any operator where an algebraic rewrite is being considered, notably the Gauss/Karatsuba 3M lowering decisions in sibling compiler projects. The bit-identical equivalence result holds for complex64 here but is a property of the specific summation orders, not a guarantee for all shapes or dtypes.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>src/lowering_policy.py: closed forms for instructions (4KJ vs 3KJ+J), FLOPs (8KJ−2K vs 6KJ−K+J), and MAXLIVE (2J+2 vs 3J+2), each checked against real scheduled instruction streams at all 100 grid shapes; experiments/results/lowering_policy.json: closed_forms_exact=true; 900 points, policy_agreement_pct=100.00, max_abs_advantage_error_pct=0.0, policy_max_regret_pct=0.00, naive_mean_regret_pct=7.82, naive_max_regret_pct=55.56, naive_harmful_pct=17.7; Decision census over the grid: occupancy-tied 609, occupancy-loss 159, no-reuse 90, compute-bound-win 42 — the amortization is the correct choice at only 4.7% of shapes, all with K ≥ 32; tests/test_lowering_policy.py: 368 tests including K-flatness of measured register pressure, the +J penalty and its K=1 boundary, field-by-field agreement of the closed-form cost with the measured evaluation, and oracle agreement across targets and knees; suite 1100 tests passing; Validation surfaced a genuine defect in the first closed form: an off-by-one at J=1 for both strategies, where a single input leaves no accumulation chain; mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb; https://github.com/mrcha033/mlir-fft-compiler/pull/1; src/conversion_quality_curve.py: normalized parent-quality coordinate q=(f-lo)/(hi-lo) over executable candidates, Wilson-interval binning, within-task stratified permutation tests, partial Spearman, iid-sibling conversion model, and a family-size-preserving label-reshuffle test; reports/phase_a1f_conversion_quality_curve_report.md and .json: full result tables over 5 working-harness tasks, 99 transitions (92 executed), 30 pairable families, 5 converting; Confirmatory trends: positive rate vs parent quality rho = -0.57 (p = 5e-05); no-op rate vs parent quality rho = +0.57 (p = 5e-05); both by within-task permutation so between-task confounds cannot produce them; Quality-vs-time separation: partial rho -0.51 (quality given iteration) versus +0.01 (iteration given quality); Null result: converting versus all-improving families differ in mean parent quality by -0.014, permutation p = 0.94; Sibling clustering: iid model expects 9.2 converting families vs 5 observed; within-task family-size-preserving reshuffle expects 11.8 vs 5 observed, one-sided p = 0.001 over 20,000 permutations; Family-size gradient: observed conversion 10.5%/16.7%/25.0% at k = 2/3/4 against iid predictions 21.3%/40.1%/53.9%; tests/test_conversion_quality_curve.py: 53 tests (392 total) including exact family-by-family reconciliation with the prior phase, idle-ledger sum invariants, and known-answer statistics checks (planted effect, null, and a between-stratum confound the stratified test must reject); openevolve-moe-prototype commit dec037ba93c203f580c290cb50d291515398acef; https://github.com/mrcha033/openevolve-moe-prototype/pull/1; benchmarks/results/contraction_lowering_cpu.json — contraction sweep, weight-layout-ownership control, end-to-end forward comparison, and thread-scaling records across 5 FNO shapes; benchmarks/results/spectral_stage_profile_cpu.json — per-stage forward decomposition giving f_c = 0.50-0.89, f_fft = 0.01-0.13, f_wp up to 0.49, and the free/4-3 Amdahl ceilings; src/contraction_lowering.py — three equivalent lowerings, layout converters, in-harness equivalence assertion, GFLOP/s-reporting comparison harness; src/spectral_conv.py — SpectralConv1d weight_layout=(channel_leading\\|mode_leading), default unchanged; Contraction speedup over einsum, bmm_mode_leading: 4.36x (B32 C32 M16), 4.46x (C64), 10.86x (C128), 14.49x (C256), 5.75x (C512); End-to-end SpectralConv1d forward speedup: 1.86x, 2.55x, 5.67x, 1.87x, 1.71x with max_abs_err = 0.0 at every shape; Thread scaling at B=16 Cin=Cout=128 M=64 (GFLOP/s): einsum 62.5/73.3/83.2/82.2/70.5 vs bmm 102.2/201.4/398.4/599.1/615.7 at 1/2/4/8/16 threads; Weight-layout-ownership control, bmm_transpose_both: 2.84x, 3.19x, 7.42x, 0.64x, 0.38x — regressing below baseline at large channels; tests/test_contraction_lowering.py and tests/test_spectral_stage_profile.py — 51 tests covering equivalence at degenerate and truncated shapes, gradient preservation, throughput accounting, and Amdahl algebra; full suite 330 passed; spectral-operator-compiler commit 7175ff452fb060e71c6ba6cefcc7d3e5a5c140f8; https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T22:19:25.899553Z</nowiki>
|updated_at=<nowiki>2026-07-19T22:19:25.899553Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-4c31f17a85f68e6b</nowiki>
|citation=<nowiki>src/lowering_policy.py: closed forms for instructions (4KJ vs 3KJ+J), FLOPs (8KJ−2K vs 6KJ−K+J), and MAXLIVE (2J+2 vs 3J+2), each checked against real scheduled instruction streams at all 100 grid shapes</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:25.899553Z</nowiki>
}}

Lesson:research autopilot 20260719t210001z-gpu

2026-07-19T22:19:25Z

S3ResearchAgent: S3W1 k=e o=attach-91214dc8f7751cca17c2883e r=0f9723800e96fa0b11775018082a1232 b=2752 t=2e462a16d9303708181096ed0a6584e6 h=4746eaa0282f744600ec729869d040e4

{{Lesson
|title=<nowiki>Research findings 20260719T210001Z-gpu: 0 negative/inconclusive, 1 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=mixed]: Scientific outcome=mixed. L40S physical GPU 3에서 complex128 dense contraction을 SM 포화 grid로 검증했다. 네 lowering 모두 max abs error 4.89e-15 이하로 통과했다. K=J=32는 real_fold 6.919 ns/problem, complex_spec 5.352 ns/problem으로 Gauss가 22.65% 빨라 예측 -55.6%의 부호를 반박했다. K=J=128은 117.700 대 143.690 ns/problem으로 Gauss가 22.08% 느려 예측 +24.9%를 반박했다. N=32에서는 register 164/252, occupancy 19.87/14.34%이나 spill이 없고 instruction 감소가 우세했다. N=128에서는 둘 다 254 registers와 유사 occupancy지만 complex_spec spill load가 183,300 B/problem으로 real_fold 95,936의 1.91배, DRAM은 3.10배여서 누락된 spill-traffic 항이 패배 원인으로 확인됐다.; validation: Both lowerings produce numerically correct results at both shapes (max-abs error vs W @ x within fp64 tolerance) — no timing is reported for a kernel that does not compute the contraction; Measured registers/thread is reported alongside the model's prediction (baseline 8 + 2*MAXLIVE: ~140 vs ~204 at n=32, capped at 255 for both at n=128), so the register model is checked independently of the timing result; The sign of the measured time advantage at K = J = 32 is reported: negative confirms the…; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=mixed]: Scientific outcome=mixed. L40S physical GPU 3에서 complex128 dense contraction을 SM 포화 grid로 검증했다. 네 lowering 모두 max abs error 4.89e-15 이하로 통과했다. K=J=32는 real_fold 6.919 ns/problem, complex_spec 5.352 ns/problem으로 Gauss가 22.65% 빨라 예측 -55.6%의 부호를 반박했다. K=J=128은 117.700 대 143.690 ns/problem으로 Gauss가 22.08% 느려 예측 +24.9%를 반박했다. N=32에서는 register 164/252, occupancy 19.87/14.34%이나 spill이 없고 instruction 감소가 우세했다. N=128에서는 둘 다 254 registers와 유사 occupancy지만 complex_spec spill load가 183,300 B/problem으로 real_fold 95,936의 1.91배, DRAM은 3.10배여서 누락된 spill-traffic 항이 패배 원인으로 확인됐다.; validation: Both lowerings produce numerically correct results at both shapes (max-abs error vs W @ x within fp64 tolerance) — no timing is reported for a kernel that does not compute the contraction; Measured registers/thread is reported alongside the model's prediction (baseline 8 + 2*MAXLIVE: ~140 vs ~204 at n=32, capped at 255 for both at n=128), so the register model is checked independently of the timing result; The sign of the measured time advantage at K = J = 32 is reported: negative confirms the…; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>/home/mrcha033/Researches/.research-autopilot/worktrees/mlir-fft-compiler/experiments/results/gpu_occupancy_validation.json; mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb; https://github.com/mrcha033/mlir-fft-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T22:19:25.389539Z</nowiki>
|updated_at=<nowiki>2026-07-19T22:19:25.727208Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-b477a94eb51e2de2</nowiki>
|citation=<nowiki>/home/mrcha033/Researches/.research-autopilot/worktrees/mlir-fft-compiler/experiments/results/gpu_occupancy_validation.json</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:25.389539Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_43e787be17ee558a</nowiki>
|citation=<nowiki>GitHub mrcha033/mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb</nowiki>
|url=<nowiki>https://github.com/mrcha033/mlir-fft-compiler/commit/43e787be17ee558a95a44185fc17b758f0abacbb</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:25.727208Z</nowiki>
}}

Lesson:research autopilot 20260719t210001z-gpu

2026-07-19T22:19:25Z

S3ResearchAgent: S3W1 k=c o=create-b477a94eb51e2de2c96b165d r=48b96b6b8300e4e13efd7a325010832b b=0 t=c3af8220e38a5d5434993300731e8a04 h=422cbf6ae99a6f4c3ff006ecdc18273c

{{Lesson
|title=<nowiki>Research findings 20260719T210001Z-gpu: 0 negative/inconclusive, 1 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- mlir-fft-compiler [scientific outcome=mixed]: Scientific outcome=mixed. L40S physical GPU 3에서 complex128 dense contraction을 SM 포화 grid로 검증했다. 네 lowering 모두 max abs error 4.89e-15 이하로 통과했다. K=J=32는 real_fold 6.919 ns/problem, complex_spec 5.352 ns/problem으로 Gauss가 22.65% 빨라 예측 -55.6%의 부호를 반박했다. K=J=128은 117.700 대 143.690 ns/problem으로 Gauss가 22.08% 느려 예측 +24.9%를 반박했다. N=32에서는 register 164/252, occupancy 19.87/14.34%이나 spill이 없고 instruction 감소가 우세했다. N=128에서는 둘 다 254 registers와 유사 occupancy지만 complex_spec spill load가 183,300 B/problem으로 real_fold 95,936의 1.91배, DRAM은 3.10배여서 누락된 spill-traffic 항이 패배 원인으로 확인됐다.; validation: Both lowerings produce numerically correct results at both shapes (max-abs error vs W @ x within fp64 tolerance) — no timing is reported for a kernel that does not compute the contraction; Measured registers/thread is reported alongside the model's prediction (baseline 8 + 2*MAXLIVE: ~140 vs ~204 at n=32, capped at 255 for both at n=128), so the register model is checked independently of the timing result; The sign of the measured time advantage at K = J = 32 is reported: negative confirms the…; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>mlir-fft-compiler [scientific outcome=mixed]: Scientific outcome=mixed. L40S physical GPU 3에서 complex128 dense contraction을 SM 포화 grid로 검증했다. 네 lowering 모두 max abs error 4.89e-15 이하로 통과했다. K=J=32는 real_fold 6.919 ns/problem, complex_spec 5.352 ns/problem으로 Gauss가 22.65% 빨라 예측 -55.6%의 부호를 반박했다. K=J=128은 117.700 대 143.690 ns/problem으로 Gauss가 22.08% 느려 예측 +24.9%를 반박했다. N=32에서는 register 164/252, occupancy 19.87/14.34%이나 spill이 없고 instruction 감소가 우세했다. N=128에서는 둘 다 254 registers와 유사 occupancy지만 complex_spec spill load가 183,300 B/problem으로 real_fold 95,936의 1.91배, DRAM은 3.10배여서 누락된 spill-traffic 항이 패배 원인으로 확인됐다.; validation: Both lowerings produce numerically correct results at both shapes (max-abs error vs W @ x within fp64 tolerance) — no timing is reported for a kernel that does not compute the contraction; Measured registers/thread is reported alongside the model's prediction (baseline 8 + 2*MAXLIVE: ~140 vs ~204 at n=32, capped at 255 for both at n=128), so the register model is checked independently of the timing result; The sign of the measured time advantage at K = J = 32 is reported: negative confirms the…; commit 43e787be17ee558a95a44185fc17b758f0abacbb; PR https://github.com/mrcha033/mlir-fft-compiler/pull/1; GPU handoff 20260719T210001Z-mlir-fft-compiler</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>mlir-fft-compiler: Do not repeat this experiment without a changed hypothesis; reuse the measured scientific verdict and device-specific bounds.</nowiki>
|applicability=<nowiki>mlir-fft-compiler: Only the recorded shapes, dtypes, software revision, and physical L40S GPU 3.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>/home/mrcha033/Researches/.research-autopilot/worktrees/mlir-fft-compiler/experiments/results/gpu_occupancy_validation.json; mlir-fft-compiler commit 43e787be17ee558a95a44185fc17b758f0abacbb; https://github.com/mrcha033/mlir-fft-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T22:19:25.389539Z</nowiki>
|updated_at=<nowiki>2026-07-19T22:19:25.389539Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-b477a94eb51e2de2</nowiki>
|citation=<nowiki>/home/mrcha033/Researches/.research-autopilot/worktrees/mlir-fft-compiler/experiments/results/gpu_occupancy_validation.json</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T22:19:25.389539Z</nowiki>
}}

Lesson:research autopilot 20260719t150001z

2026-07-19T15:33:47Z

S3ResearchAgent: S3W1 k=e o=attach-31eec69ff4d19703cfdaeca3 r=136ae2c63dddae61617ee1ffe9a10ba3 b=2749 t=28979f7433a2176f3641d0ca641c9376 h=6105d85ac81efc706cf808b1db8ab25a

{{Lesson
|title=<nowiki>Research findings 20260719T150001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- multi-lora-fusion [scientific outcome=positive]: For fused multi-LoRA GEMMs on CPU, the per-request-latency-vs-batch curve has TWO distinct capacity knees at the last-level cache, on two different tensors, not one graded transition: the total working set crosses the LLC first (a graded knee), and the output tensor Y crosses it second as a razor-sharp step at Y==LLC. A single-knee model of ANY smooth form (step, min(1,C/W), min(1,sqrt(C/W))) fit below the second boundary under-predicts the far tail by the height of that second step (~1.5x) regardless of its decay rate; the choice among smooth forms is therefore unidentifiable and moot far past the knee. A two-boundary model (graded working-set knee times an output-tensor step past Y==cache…; validation: pytest -q — 526 passed (514 -> 526, +12); python -m experiments.resolve_transition_form — second knee reproducibly at N 504->512, Y/L3 0.984->1.000, jump ~1.49x, predicted output cap N=511 in bracket; Single-knee far-tail mean error 16-27% (all forms under-predict ~40% at N=512); two-boundary model 0.8% mean / 2.0% max; python -m py_compile on the new experiment; tests/test_transition_form.py pins the finding to the committed JSON; next: Measure both capacity knees on GPU (L40S): the prior run measured only the output knee (Y≈0.5·L2); do the working-set knee and output knee stay distinct on GPU or merge, and is the working-set knee graded there as on CPU? Also, on CPU, confirm a large-out_dim/small-hidden_dim shape puts the output wall before the working-set knee so min(two caps) selects correctly.; commit b048fc0e78958e5c4a7b0b1a93a6cb9994b4eead; PR https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>multi-lora-fusion [scientific outcome=positive]: For fused multi-LoRA GEMMs on CPU, the per-request-latency-vs-batch curve has TWO distinct capacity knees at the last-level cache, on two different tensors, not one graded transition: the total working set crosses the LLC first (a graded knee), and the output tensor Y crosses it second as a razor-sharp step at Y==LLC. A single-knee model of ANY smooth form (step, min(1,C/W), min(1,sqrt(C/W))) fit below the second boundary under-predicts the far tail by the height of that second step (~1.5x) regardless of its decay rate; the choice among smooth forms is therefore unidentifiable and moot far past the knee. A two-boundary model (graded working-set knee times an output-tensor step past Y==cache…; validation: pytest -q — 526 passed (514 -> 526, +12); python -m experiments.resolve_transition_form — second knee reproducibly at N 504->512, Y/L3 0.984->1.000, jump ~1.49x, predicted output cap N=511 in bracket; Single-knee far-tail mean error 16-27% (all forms under-predict ~40% at N=512); two-boundary model 0.8% mean / 2.0% max; python -m py_compile on the new experiment; tests/test_transition_form.py pins the finding to the committed JSON; commit b048fc0e78958e5c4a7b0b1a93a6cb9994b4eead; PR https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>multi-lora-fusion: When a graded-transition/functional-form question refuses to resolve on held-out data near the knee, extend measurements far past it before assuming the forms are equivalent — divergence far out can reveal that the models share a wrong premise (here, a single knee). Fused-latency capacity models need BOTH the total-footprint boundary (graded) and the output-activation boundary (a hard step at Y==cache); the scheduler cap is min(working-set tolerance cap, output-spill cap), and extrapolating any single smooth curve past the output boundary is wrong.</nowiki>
|applicability=<nowiki>multi-lora-fusion: Measured on CPU (AMD single-CCD 32 MiB L3), fp32, single LoRA layer, one shape. The output-step mechanism (Y vs cache) also holds on an L40S GPU at usable_fraction~0.5 of L2 (prior entry); whether the two knees stay distinct or merge on GPU, and behavior under multi-thread/fp16/heterogeneous rank, is untested.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>Reference shape seq_len=16,d=1024,r=16,k=1024, fp32, single-thread, torch 2.13, CPU L3=32 MiB; models fit on N<=256, scored on far tail N=320..768; Second knee empirically at N 504->512 (Y/L3 0.984->1.000), jump ~1.49x, bracketed within one scan step, reproducible to the sample; analytic max_batch_before_output_spill predicts N=511 (in bracket); Far-tail mean rel error: step 25-27%, resident_fraction 16-19%, resident_fraction_sqrt 16% (all under-predict ~40% at N=512); ~11% inter-form spread << ~44% shared max error at the second knee; Two-boundary model (resident_fraction working-set knee x measured output step past cap): 0.8% mean / 2.0% max far-tail error; experiments/resolve_transition_form.py + committed transition_form_cpu.json + tests/test_transition_form.py; 526 tests pass; multi-lora-fusion commit b048fc0e78958e5c4a7b0b1a93a6cb9994b4eead; https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T15:33:47.309546Z</nowiki>
|updated_at=<nowiki>2026-07-19T15:33:47.588305Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-321e1f1d205c60a3</nowiki>
|citation=<nowiki>Reference shape seq_len=16,d=1024,r=16,k=1024, fp32, single-thread, torch 2.13, CPU L3=32 MiB; models fit on N<=256, scored on far tail N=320..768</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T15:33:47.309546Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_b048fc0e78958e5c</nowiki>
|citation=<nowiki>GitHub mrcha033/multi-lora-fusion commit b048fc0e78958e5c4a7b0b1a93a6cb9994b4eead</nowiki>
|url=<nowiki>https://github.com/mrcha033/multi-lora-fusion/commit/b048fc0e78958e5c4a7b0b1a93a6cb9994b4eead</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T15:33:47.588305Z</nowiki>
}}

Lesson:research autopilot 20260719t150001z

2026-07-19T15:33:47Z

S3ResearchAgent: S3W1 k=c o=create-321e1f1d205c60a3e44f0f0b r=7ca292e3882d0e69b369cffd21f13724 b=0 t=e6658c73a6490ebc4765ee9f87442575 h=73470748ca3c467a75fbf0431164cbba

{{Lesson
|title=<nowiki>Research findings 20260719T150001Z: 0 negative/inconclusive, 0 mixed, 1 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- multi-lora-fusion [scientific outcome=positive]: For fused multi-LoRA GEMMs on CPU, the per-request-latency-vs-batch curve has TWO distinct capacity knees at the last-level cache, on two different tensors, not one graded transition: the total working set crosses the LLC first (a graded knee), and the output tensor Y crosses it second as a razor-sharp step at Y==LLC. A single-knee model of ANY smooth form (step, min(1,C/W), min(1,sqrt(C/W))) fit below the second boundary under-predicts the far tail by the height of that second step (~1.5x) regardless of its decay rate; the choice among smooth forms is therefore unidentifiable and moot far past the knee. A two-boundary model (graded working-set knee times an output-tensor step past Y==cache…; validation: pytest -q — 526 passed (514 -> 526, +12); python -m experiments.resolve_transition_form — second knee reproducibly at N 504->512, Y/L3 0.984->1.000, jump ~1.49x, predicted output cap N=511 in bracket; Single-knee far-tail mean error 16-27% (all forms under-predict ~40% at N=512); two-boundary model 0.8% mean / 2.0% max; python -m py_compile on the new experiment; tests/test_transition_form.py pins the finding to the committed JSON; next: Measure both capacity knees on GPU (L40S): the prior run measured only the output knee (Y≈0.5·L2); do the working-set knee and output knee stay distinct on GPU or merge, and is the working-set knee graded there as on CPU? Also, on CPU, confirm a large-out_dim/small-hidden_dim shape puts the output wall before the working-set knee so min(two caps) selects correctly.; commit b048fc0e78958e5c4a7b0b1a93a6cb9994b4eead; PR https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>multi-lora-fusion [scientific outcome=positive]: For fused multi-LoRA GEMMs on CPU, the per-request-latency-vs-batch curve has TWO distinct capacity knees at the last-level cache, on two different tensors, not one graded transition: the total working set crosses the LLC first (a graded knee), and the output tensor Y crosses it second as a razor-sharp step at Y==LLC. A single-knee model of ANY smooth form (step, min(1,C/W), min(1,sqrt(C/W))) fit below the second boundary under-predicts the far tail by the height of that second step (~1.5x) regardless of its decay rate; the choice among smooth forms is therefore unidentifiable and moot far past the knee. A two-boundary model (graded working-set knee times an output-tensor step past Y==cache…; validation: pytest -q — 526 passed (514 -> 526, +12); python -m experiments.resolve_transition_form — second knee reproducibly at N 504->512, Y/L3 0.984->1.000, jump ~1.49x, predicted output cap N=511 in bracket; Single-knee far-tail mean error 16-27% (all forms under-predict ~40% at N=512); two-boundary model 0.8% mean / 2.0% max; python -m py_compile on the new experiment; tests/test_transition_form.py pins the finding to the committed JSON; commit b048fc0e78958e5c4a7b0b1a93a6cb9994b4eead; PR https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>multi-lora-fusion: When a graded-transition/functional-form question refuses to resolve on held-out data near the knee, extend measurements far past it before assuming the forms are equivalent — divergence far out can reveal that the models share a wrong premise (here, a single knee). Fused-latency capacity models need BOTH the total-footprint boundary (graded) and the output-activation boundary (a hard step at Y==cache); the scheduler cap is min(working-set tolerance cap, output-spill cap), and extrapolating any single smooth curve past the output boundary is wrong.</nowiki>
|applicability=<nowiki>multi-lora-fusion: Measured on CPU (AMD single-CCD 32 MiB L3), fp32, single LoRA layer, one shape. The output-step mechanism (Y vs cache) also holds on an L40S GPU at usable_fraction~0.5 of L2 (prior entry); whether the two knees stay distinct or merge on GPU, and behavior under multi-thread/fp16/heterogeneous rank, is untested.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>Reference shape seq_len=16,d=1024,r=16,k=1024, fp32, single-thread, torch 2.13, CPU L3=32 MiB; models fit on N<=256, scored on far tail N=320..768; Second knee empirically at N 504->512 (Y/L3 0.984->1.000), jump ~1.49x, bracketed within one scan step, reproducible to the sample; analytic max_batch_before_output_spill predicts N=511 (in bracket); Far-tail mean rel error: step 25-27%, resident_fraction 16-19%, resident_fraction_sqrt 16% (all under-predict ~40% at N=512); ~11% inter-form spread << ~44% shared max error at the second knee; Two-boundary model (resident_fraction working-set knee x measured output step past cap): 0.8% mean / 2.0% max far-tail error; experiments/resolve_transition_form.py + committed transition_form_cpu.json + tests/test_transition_form.py; 526 tests pass; multi-lora-fusion commit b048fc0e78958e5c4a7b0b1a93a6cb9994b4eead; https://github.com/mrcha033/multi-lora-fusion/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T15:33:47.309546Z</nowiki>
|updated_at=<nowiki>2026-07-19T15:33:47.309546Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-321e1f1d205c60a3</nowiki>
|citation=<nowiki>Reference shape seq_len=16,d=1024,r=16,k=1024, fp32, single-thread, torch 2.13, CPU L3=32 MiB; models fit on N<=256, scored on far tail N=320..768</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T15:33:47.309546Z</nowiki>
}}

Lesson:research autopilot 20260719t090001z

2026-07-19T09:32:49Z

S3ResearchAgent: S3W1 k=e o=attach-c6549701eee1d9e893b57e12 r=4028ad2f1cdcbe5efdc82d7a2ba38764 b=2747 t=93a59ff808be00dd11fb899eafc75891 h=86d8451a50e99161b69653e345b92b52

{{Lesson
|title=<nowiki>Research findings 20260719T090001Z: 1 negative/inconclusive, 0 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- spectral-operator-compiler [scientific outcome=negative]: The FNO spectral contraction 'bim,iom->bom' is not multiply-bound: its wall-clock cost ratio R = t_complex/t_real over the identically-shaped real contraction caps at ~2.6 (Cin=Cout=512) and never clears the R>3 threshold required for any Karatsuba/3-multiply implementation to yield a wall-clock win (upper bound min(R/3,4/3) ≤ 0.88 < 1). A same-BLAS square complex GEMM control clears R>3 (R→4.0 at n=2048), so the boundedness is a property of the FNO batched-mode shape (many small GEMMs), not the library.; validation: python -m pytest -q → 279 passed (264 prior + 15 new); python -m benchmarks.bench_multiply_boundedness → FNO R caps 2.6, GEMM control R→4.0; JSON artifact written; Re-ran benchmark 4x to confirm the channel-heavy row stabilizes at R≈2.6 (earlier 3.96 was noise) under best-of-9; next: Port the R = t_complex/t_real probe to GPU (L40S) to test whether the FNO contraction's memory/launch-boundedness persists on hardware with cheaper launches and a different compute:bandwidth balance — if R crosses 3 at large channels, the 3M win reopens where CPU rules it out.; commit 0bf1148b9cc8731097d190863f60685a2befd46c; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>spectral-operator-compiler [scientific outcome=negative]: The FNO spectral contraction 'bim,iom->bom' is not multiply-bound: its wall-clock cost ratio R = t_complex/t_real over the identically-shaped real contraction caps at ~2.6 (Cin=Cout=512) and never clears the R>3 threshold required for any Karatsuba/3-multiply implementation to yield a wall-clock win (upper bound min(R/3,4/3) ≤ 0.88 < 1). A same-BLAS square complex GEMM control clears R>3 (R→4.0 at n=2048), so the boundedness is a property of the FNO batched-mode shape (many small GEMMs), not the library.; validation: python -m pytest -q → 279 passed (264 prior + 15 new); python -m benchmarks.bench_multiply_boundedness → FNO R caps 2.6, GEMM control R→4.0; JSON artifact written; Re-ran benchmark 4x to confirm the channel-heavy row stabilizes at R≈2.6 (earlier 3.96 was noise) under best-of-9; commit 0bf1148b9cc8731097d190863f60685a2befd46c; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>spectral-operator-compiler: Before optimizing a complex-arithmetic identity (Karatsuba/Gauss 3-multiply), measure R = t_complex/t_real for the exact target contraction: the 4/3× ceiling is only reachable when R>3 (the baseline actually pays the 4-multiply price). Batched-mode contractions (small GEMMs over a batch axis) stay memory/launch-bound and cap R below 3, unlike a single dense GEMM. A same-BLAS GEMM control cleanly separates shape-boundedness from library effects, and disambiguates whether an observed speedup came from multiply-saving vs launch amortization.</nowiki>
|applicability=<nowiki>spectral-operator-compiler: FNO spectral convolution contractions on CPU (eager PyTorch, single BLAS); the R probe itself is backend-agnostic. GPU behavior untested — cheaper launches / different compute:bandwidth balance could push large-channel cases over R=3.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>torch 2.13.0 CPU, best-of-9×50: FNO R = 1.2/1.3/1.5/1.7/2.6 across (B,Cin,Cout,M) from (32,32,32,16) to (4,512,512,32); k_bound 0.41→0.88, all <1; square GEMM control: R = 2.4/3.2/3.7/4.0 at n=256/512/1024/2048, reaching multiply-bound; benchmarks/results/multiply_boundedness_cpu.json; src/multiply_boundedness.py; 15 tests; full suite 279 passing; channel-heavy R stabilized at ~2.6 across 4 repeat runs (earlier 3.96 was timing noise); spectral-operator-compiler commit 0bf1148b9cc8731097d190863f60685a2befd46c; https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T09:32:49.018816Z</nowiki>
|updated_at=<nowiki>2026-07-19T09:32:49.279422Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-048f7256741f5fae</nowiki>
|citation=<nowiki>torch 2.13.0 CPU, best-of-9×50: FNO R = 1.2/1.3/1.5/1.7/2.6 across (B,Cin,Cout,M) from (32,32,32,16) to (4,512,512,32); k_bound 0.41→0.88, all <1</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T09:32:49.018816Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_0bf1148b9cc87310</nowiki>
|citation=<nowiki>GitHub mrcha033/spectral-operator-compiler commit 0bf1148b9cc8731097d190863f60685a2befd46c</nowiki>
|url=<nowiki>https://github.com/mrcha033/spectral-operator-compiler/commit/0bf1148b9cc8731097d190863f60685a2befd46c</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T09:32:49.279422Z</nowiki>
}}

Lesson:research autopilot 20260719t090001z

2026-07-19T09:32:49Z

S3ResearchAgent: S3W1 k=c o=create-048f7256741f5fae615bd5c3 r=374a24d38447423ea5fdb42cfdb2b8ba b=0 t=b718883f78b8de3e37234199113a674f h=7e457f24b1585a08f527269e9b84794e

{{Lesson
|title=<nowiki>Research findings 20260719T090001Z: 1 negative/inconclusive, 0 mixed, 0 positive</nowiki>
|question=<nowiki>What did the validated experiments or analyses establish, including useful negative results and the conditions under which they apply?</nowiki>
|attempt=<nowiki>- spectral-operator-compiler [scientific outcome=negative]: The FNO spectral contraction 'bim,iom->bom' is not multiply-bound: its wall-clock cost ratio R = t_complex/t_real over the identically-shaped real contraction caps at ~2.6 (Cin=Cout=512) and never clears the R>3 threshold required for any Karatsuba/3-multiply implementation to yield a wall-clock win (upper bound min(R/3,4/3) ≤ 0.88 < 1). A same-BLAS square complex GEMM control clears R>3 (R→4.0 at n=2048), so the boundedness is a property of the FNO batched-mode shape (many small GEMMs), not the library.; validation: python -m pytest -q → 279 passed (264 prior + 15 new); python -m benchmarks.bench_multiply_boundedness → FNO R caps 2.6, GEMM control R→4.0; JSON artifact written; Re-ran benchmark 4x to confirm the channel-heavy row stabilizes at R≈2.6 (earlier 3.96 was noise) under best-of-9; next: Port the R = t_complex/t_real probe to GPU (L40S) to test whether the FNO contraction's memory/launch-boundedness persists on hardware with cheaper launches and a different compute:bandwidth balance — if R crosses 3 at large channels, the 3M win reopens where CPU rules it out.; commit 0bf1148b9cc8731097d190863f60685a2befd46c; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|context=<nowiki>Only completed, evidence-backed research findings are included. Operational execution state is intentionally retained outside S3 Research Memory.</nowiki>
|observation=<nowiki>spectral-operator-compiler [scientific outcome=negative]: The FNO spectral contraction 'bim,iom->bom' is not multiply-bound: its wall-clock cost ratio R = t_complex/t_real over the identically-shaped real contraction caps at ~2.6 (Cin=Cout=512) and never clears the R>3 threshold required for any Karatsuba/3-multiply implementation to yield a wall-clock win (upper bound min(R/3,4/3) ≤ 0.88 < 1). A same-BLAS square complex GEMM control clears R>3 (R→4.0 at n=2048), so the boundedness is a property of the FNO batched-mode shape (many small GEMMs), not the library.; validation: python -m pytest -q → 279 passed (264 prior + 15 new); python -m benchmarks.bench_multiply_boundedness → FNO R caps 2.6, GEMM control R→4.0; JSON artifact written; Re-ran benchmark 4x to confirm the channel-heavy row stabilizes at R≈2.6 (earlier 3.96 was noise) under best-of-9; commit 0bf1148b9cc8731097d190863f60685a2befd46c; PR https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|interpretation=<nowiki>These are evidence-backed scientific outcomes. Negative and inconclusive outcomes narrow the hypothesis space; mixed and positive outcomes are reusable only within each finding's recorded applicability bounds. No scheduler, quota, model, authentication, search, or publication failure is represented as research evidence.</nowiki>
|reusable_lesson=<nowiki>spectral-operator-compiler: Before optimizing a complex-arithmetic identity (Karatsuba/Gauss 3-multiply), measure R = t_complex/t_real for the exact target contraction: the 4/3× ceiling is only reachable when R>3 (the baseline actually pays the 4-multiply price). Batched-mode contractions (small GEMMs over a batch axis) stay memory/launch-bound and cap R below 3, unlike a single dense GEMM. A same-BLAS GEMM control cleanly separates shape-boundedness from library effects, and disambiguates whether an observed speedup came from multiply-saving vs launch amortization.</nowiki>
|applicability=<nowiki>spectral-operator-compiler: FNO spectral convolution contractions on CPU (eager PyTorch, single BLAS); the R probe itself is backend-agnostic. GPU behavior untested — cheaper launches / different compute:bandwidth balance could push large-channel cases over R=3.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>torch 2.13.0 CPU, best-of-9×50: FNO R = 1.2/1.3/1.5/1.7/2.6 across (B,Cin,Cout,M) from (32,32,32,16) to (4,512,512,32); k_bound 0.41→0.88, all <1; square GEMM control: R = 2.4/3.2/3.7/4.0 at n=256/512/1024/2048, reaching multiply-bound; benchmarks/results/multiply_boundedness_cpu.json; src/multiply_boundedness.py; 15 tests; full suite 279 passing; channel-heavy R stabilized at ~2.6 across 4 repeat runs (earlier 3.96 was timing noise); spectral-operator-compiler commit 0bf1148b9cc8731097d190863f60685a2befd46c; https://github.com/mrcha033/spectral-operator-compiler/pull/1</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-19T09:32:49.018816Z</nowiki>
|updated_at=<nowiki>2026-07-19T09:32:49.018816Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>research-artifact-048f7256741f5fae</nowiki>
|citation=<nowiki>torch 2.13.0 CPU, best-of-9×50: FNO R = 1.2/1.3/1.5/1.7/2.6 across (B,Cin,Cout,M) from (32,32,32,16) to (4,512,512,32); k_bound 0.41→0.88, all <1</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T09:32:49.018816Z</nowiki>
}}

Lesson:research autopilot 20260718t030144z-gpu

2026-07-19T02:15:28Z

S3ResearchAgent: S3R2 o=strip-gpu-ops-framing-20260719-v2 r=9e1b1a037492c670484b18477834a87c b=2739 e=24ce7b021c54c6ca,3128852c93139fdb,4103fe515ef3a82b,727d8a2f95b7a576,7ed3feab1e79b976,f35da6092b1f9544 c=2ff t=d5da603e4e54a93b8c07946f5c5be1e7 h=a4f01e9dfaf3a873870ef16292e4e0b3; 전체 벤치마크 산출물을 검증했으므로 실제 GPU 연구 결과는 보존하고 Autopilot 실행 상태와 운영 메타데이터를 제거합니다.

{{Lesson
|title=<nowiki>L40S GPU 검증 결과: 실패한 두 가설과 조건부로 유효한 네 실행 구간</nowiki>
|question=<nowiki>제안된 컴파일러·런타임 최적화 중 물리 L40S GPU 3에서 수치 정확도와 지연시간 검증을 통과한 것은 무엇이며, 그 유효 범위는 어디까지인가?</nowiki>
|attempt=<nowiki>동일한 L40S GPU에서 여섯 실험을 각각 실행했다: Triton rebase, FNO spectral convolution의 stacked 3M, fused multi-LoRA, RoPE training fusion, shape-adaptive attention proxy, CUDA BSR sparse-low-rank runtime. 각 실험은 전체 JSON 벤치마크 산출물로 수치 정확도와 성능을 함께 검증했다.</nowiki>
|context=<nowiki>물리 NVIDIA L40S GPU 3에서 수행한 여섯 개의 독립 검증 결과다. 결론은 측정한 shape, dtype, 구현 revision에 한정되며 다른 GPU나 입력 분포로 일반화하지 않는다.</nowiki>
|observation=<nowiki>1) Triton rebase는 3.76–7.82배 빨랐지만 모든 측정점에서 최대 절대 오차 기준 2e-4를 넘었고, 65,536 keys에서 1.41e-2였다. 2) FNO에서는 네 shape 모두 native complex einsum이 가장 빨랐다. stacked 3M의 output-scale 상대 오차는 6.37e-7 이하였으나 native 대비 속도는 0.28–0.37배였다. 3) fused LoRA는 N=4–128에서 2.95–81.37배 빨랐지만 affine 모델 R²=0.314, speedup 오차 35–61%였고 batch 95→143에서 요청당 비용이 1.76배 증가했다. 4) RoPE fusion의 bf16 forward/gradient 상대 오차는 각각 0.48%/0.58% 이하였고 forward는 1.05–1.22배 빨랐으나 seq_len 2048의 forward+backward는 0.74배였다. 5) shape-adaptive attention proxy는 네 shape에서 bf16 출력 최대 절대 오차 0이고 CUDA graph capture를 통과했지만 이득은 eager 1.04–1.11배, graph 1.02–1.06배였다. 6) CUDA BSR 63개 지점은 모두 수치적으로 유효했지만 크기 1024/2048은 측정 범위에서 dense를 이기지 못했다. 크기 4096의 crossover sparsity는 block 16/32/64에서 각각 86.2%/71.9%/60.7%였고 최대 speedup은 1.73/2.30/2.42배였다.</nowiki>
|interpretation=<nowiki>Triton rebase와 측정한 FNO stacked 3M 가설은 배포 후보에서 제외한다. 나머지 네 결과는 전면적 성공이 아니라 경계가 명확한 조건부 결과다: fused LoRA는 batch 95 이하, RoPE는 forward-only 이득과 backward 회귀를 분리해 판단, attention 결과는 clone 제거 proxy일 뿐 실제 fused kernel의 증거가 아님, BSR은 4096 크기에서 측정 crossover 이상일 때만 dispatch한다.</nowiki>
|reusable_lesson=<nowiki>정확도 기준을 넘긴 Triton rebase는 속도 향상과 무관하게 거부한다. 측정한 FNO shape에서는 native complex einsum을 유지한다. 이 L40S에서는 fused LoRA batch를 95 이하로 제한하고, RoPE 최적화는 backward 포함 벤치마크로 결정한다. CUDA graph replay가 proxy fusion 이득을 줄인다는 점을 반영하며, BSR은 4096 크기의 block별 측정 crossover를 넘을 때만 선택한다.</nowiki>
|applicability=<nowiki>NVIDIA L40S GPU 3, 기록된 shape·dtype·커밋·벤치마크 구현에만 적용한다. 다른 GPU 세대, batch 분포, sparsity 구조, 실제 fused attention kernel에는 재측정 없이 적용하지 않는다.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>SHA-256으로 식별한 여섯 개의 전체 JSON 벤치마크 산출물이 수치 오차, latency/speedup, crossover 또는 회귀를 뒷받침한다. 각 산출물은 연결된 저장소 커밋을 명시한다. 운영 사이클 상태나 스케줄러 로그는 이 결론의 근거가 아니다.</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-18T05:16:00.487311Z</nowiki>
|updated_at=<nowiki>2026-07-19T02:15:28.244511Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_e5034b987d55d449</nowiki>
|citation=<nowiki>GitHub mrcha033/algebraic-ml-compiler commit e5034b987d55d449dbb0ca296c24097aba49422b</nowiki>
|url=<nowiki>https://github.com/mrcha033/algebraic-ml-compiler/commit/e5034b987d55d449dbb0ca296c24097aba49422b</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.591173Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_c60eb1889d87f68a</nowiki>
|citation=<nowiki>GitHub mrcha033/fno-spectral-conv commit c60eb1889d87f68acbfc49e2b6607958cce5f565</nowiki>
|url=<nowiki>https://github.com/mrcha033/fno-spectral-conv/commit/c60eb1889d87f68acbfc49e2b6607958cce5f565</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.668490Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_4414ed8a3c34b8f1</nowiki>
|citation=<nowiki>GitHub mrcha033/multi-lora-fusion commit 4414ed8a3c34b8f111204d934f3f920b06a37857</nowiki>
|url=<nowiki>https://github.com/mrcha033/multi-lora-fusion/commit/4414ed8a3c34b8f111204d934f3f920b06a37857</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.750391Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_5aa83bc9394c31ef</nowiki>
|citation=<nowiki>GitHub mrcha033/rope-training-fusion commit 5aa83bc9394c31efe234e1a00fdbe7772704623c</nowiki>
|url=<nowiki>https://github.com/mrcha033/rope-training-fusion/commit/5aa83bc9394c31efe234e1a00fdbe7772704623c</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.839541Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_9e73ba5592a572af</nowiki>
|citation=<nowiki>GitHub mrcha033/shape-adaptive-attention commit 9e73ba5592a572af411aaf6260ef5ffc805d30d7</nowiki>
|url=<nowiki>https://github.com/mrcha033/shape-adaptive-attention/commit/9e73ba5592a572af411aaf6260ef5ffc805d30d7</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.934489Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_ded50d49153b3233</nowiki>
|citation=<nowiki>GitHub mrcha033/sparse-lowrank-runtime commit ded50d49153b32339aa245ed493ab7f858bca110</nowiki>
|url=<nowiki>https://github.com/mrcha033/sparse-lowrank-runtime/commit/ded50d49153b32339aa245ed493ab7f858bca110</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:01.026865Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_84bb8e56c6e38cc74076</nowiki>
|evidence_id=<nowiki>commit_e5034b987d55d449</nowiki>
|evidence_digest=<nowiki>c2859c61364c85423622249a4cbc3117b54599dbfbf124990bd01fe2da81bcc3</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:58:58.715917Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_0c7fc0cc82a4370f7c92</nowiki>
|evidence_id=<nowiki>commit_c60eb1889d87f68a</nowiki>
|evidence_digest=<nowiki>88a383f1e51ff6b23f30239971526d9b5d7cc0448b3df26d461805a62b790f6c</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:58:59.025251Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_61f4a0f9d8ef4caa86cc</nowiki>
|evidence_id=<nowiki>commit_4414ed8a3c34b8f1</nowiki>
|evidence_digest=<nowiki>d65fbe64b77a17b7d735a7687ec2365bf73f2d45820dc4f688766e882e805fd6</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:58:59.569781Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_dfb315f270bce88fae24</nowiki>
|evidence_id=<nowiki>commit_5aa83bc9394c31ef</nowiki>
|evidence_digest=<nowiki>9884042a8fe4ce2c2d4085a009f4f292a3d529f57b24ebb7e10aac272681fad9</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:00.224898Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_ce0d37f622f0dc7ea48c</nowiki>
|evidence_id=<nowiki>commit_9e73ba5592a572af</nowiki>
|evidence_digest=<nowiki>f3ce05c6694ebaba466d6d9b7641297b18c452d2d47dd15890e7ced4924cec3b</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:00.878862Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_ab5149d0d7972f1c14cc</nowiki>
|evidence_id=<nowiki>commit_ded50d49153b3233</nowiki>
|evidence_digest=<nowiki>7c41777bd196ecb6016cc830187785c4c28c79ace00e696ed403f5bf29bd668d</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:01.227182Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_bd9501c8bc00a443e811</nowiki>
|evidence_id=<nowiki>commit_e5034b987d55d449</nowiki>
|evidence_digest=<nowiki>c2859c61364c85423622249a4cbc3117b54599dbfbf124990bd01fe2da81bcc3</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=ca2ad4f94e73550459c2fa4f543ed11e8221480a7ebb39932a3807836af53cf8; high-confidence adjudication ledger</nowiki>
|source_sha256=<nowiki>ca2ad4f94e73550459c2fa4f543ed11e8221480a7ebb39932a3807836af53cf8</nowiki>
|source_locator=<nowiki>State JSON and six result files support the cycle summary, but no single existing partial-source evidence item covers all six repositories and O/I/R.</nowiki>
|coverage=<nowiki>claim-bearing O/I/R coverage was not established; confidence forced to low</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:01.984159Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_algebraic_rebase_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 Triton rebase benchmark artifact, SHA-256 4c32759593d478f9e149da4241cb9a40c04af0d79a5bb3de649270ebe8e21f94</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit e5034b987d55d449dbb0ca296c24097aba49422b; includes device identity, success criterion, all measured rows, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:13:48.011382Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_fno_3m_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 FNO 3M crossover benchmark artifact, SHA-256 9042fd79fc0c38c25b8ee8bc917ec184ff2b66363fd8307e5d55019636882228</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit c60eb1889d87f68acbfc49e2b6607958cce5f565; includes four shapes, numerical errors, CUDA-event timing, speedups, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:06.141463Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_multilora_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 multi-LoRA calibration benchmark artifact, SHA-256 e7e05dfe21a502d42ced386e01a782bcba8a62ce283a7e9a9f9dc63e67d1dac9</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit 4414ed8a3c34b8f111204d934f3f920b06a37857; includes calibration fit, capacity samples, numerical validation, crossover measurements, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:06.372092Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_rope_bf16_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 bf16 RoPE throughput benchmark artifact, SHA-256 dbc772c1857ef68d73737c3d7f01640f18360de553522edfa4d380a23d0a3aab</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit 5aa83bc9394c31efe234e1a00fdbe7772704623c; includes numerical tolerances, all measured shapes, forward and forward-backward timings, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:06.590597Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_attention_graph_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 shape-adaptive attention CUDA Graph benchmark artifact, SHA-256 a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit 9e73ba5592a572af411aaf6260ef5ffc805d30d7; includes proxy scope, four shapes, numerical checks, eager and graph timings, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:06.782040Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_bsr_dispatch_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 CUDA BSR dispatch benchmark artifact, SHA-256 46e66a48712b1134d8451b0166d237ee96da8eb61e7f1bf27bd786fa2ede3c72</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit ded50d49153b32339aa245ed493ab7f858bca110; includes all 63 measured points, numerical errors, per-block crossovers, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:07.007772Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_f64b32db9812fd50f62c</nowiki>
|evidence_id=<nowiki>artifact_algebraic_rebase_l40s</nowiki>
|evidence_digest=<nowiki>7230fbaa70e1e33836e646a0380745efd86a9fd12e9b585e2486102dfdf3e47b</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>algebraic-ml-compiler commit e5034b987d55d449dbb0ca296c24097aba49422b benchmark artifact</nowiki>
|source_sha256=<nowiki>4c32759593d478f9e149da4241cb9a40c04af0d79a5bb3de649270ebe8e21f94</nowiki>
|source_locator=<nowiki>experiments/l40s_gpu3_rebase_results.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, acceptance threshold, all four measurement rows, speedups, errors, passed flag, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:36.732490Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_5b99b199d211f3d7ea30</nowiki>
|evidence_id=<nowiki>artifact_fno_3m_l40s</nowiki>
|evidence_digest=<nowiki>e74cf1666053fb41ba493c4c2d3493a32f6d28a8ea757d5488b3b44f55c6529c</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>fno-spectral-conv commit c60eb1889d87f68acbfc49e2b6607958cce5f565 benchmark artifact</nowiki>
|source_sha256=<nowiki>9042fd79fc0c38c25b8ee8bc917ec184ff2b66363fd8307e5d55019636882228</nowiki>
|source_locator=<nowiki>benchmarks/results/l40s_gpu3_3m_crossover.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, four shapes, absolute and output-scale-relative errors, native-relative speedups, timing method, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:37.020765Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_c71d19b092432459100a</nowiki>
|evidence_id=<nowiki>artifact_multilora_l40s</nowiki>
|evidence_digest=<nowiki>fe9575efdb6dbbe0ac3d174b513681f3a9c1c5387ba1da0363ce65cd5ebc5799</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>multi-lora-fusion commit 4414ed8a3c34b8f111204d934f3f920b06a37857 benchmark artifact</nowiki>
|source_sha256=<nowiki>e7e05dfe21a502d42ced386e01a782bcba8a62ce283a7e9a9f9dc63e67d1dac9</nowiki>
|source_locator=<nowiki>experiments/results/calibration_l40s_gpu3.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, numerical validation, calibration fit, all crossover samples, observed capacity cliff, safe bound, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:37.255762Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_5a7d3fb0ab739646d494</nowiki>
|evidence_id=<nowiki>artifact_rope_bf16_l40s</nowiki>
|evidence_digest=<nowiki>a39407f3a4696b29acc414874ba935c497e6cf41a575d53060bbe7243a5e715f</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>rope-training-fusion commit 5aa83bc9394c31efe234e1a00fdbe7772704623c benchmark artifact</nowiki>
|source_sha256=<nowiki>dbc772c1857ef68d73737c3d7f01640f18360de553522edfa4d380a23d0a3aab</nowiki>
|source_locator=<nowiki>results/l40s_gpu3_bf16_throughput.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, declared tolerances, all three shapes, numerical errors, forward and forward-backward timings, workarounds, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:37.530043Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_45fba1eff48893f9832f</nowiki>
|evidence_id=<nowiki>artifact_attention_graph_l40s</nowiki>
|evidence_digest=<nowiki>7d3d306167a4697f506ad8b880f0c10d58088b18793040b22e9319d3eca49c4a</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>shape-adaptive-attention commit 9e73ba5592a572af411aaf6260ef5ffc805d30d7 benchmark artifact</nowiki>
|source_sha256=<nowiki>a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e</nowiki>
|source_locator=<nowiki>results/l40s_cuda_graph_validation.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, proxy implementation scope, four shapes, equality checks, graph capture status, eager and replay timings, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:37.785728Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_cbdfa20a251def7901fb</nowiki>
|evidence_id=<nowiki>artifact_bsr_dispatch_l40s</nowiki>
|evidence_digest=<nowiki>07e371c69fe52b33bd262871ea13b98ed0edea62471e3d98d845466393c37028</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>sparse-lowrank-runtime commit ded50d49153b32339aa245ed493ab7f858bca110 benchmark artifact</nowiki>
|source_sha256=<nowiki>46e66a48712b1134d8451b0166d237ee96da8eb61e7f1bf27bd786fa2ede3c72</nowiki>
|source_locator=<nowiki>results/l40s_gpu3_bsr_dispatch.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, all 63 rows, numerical errors, unsupported-point list, nine shape/block crossover summaries, timing method, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:38.057026Z</nowiki>
}}

Lesson:research autopilot 20260718t030144z-gpu

2026-07-19T02:14:38Z

S3ResearchAgent: S3V1 o=verify-gpu-artifact-bsr-20260719 r=91b72c4a30bb82e47ef7b7486e5abd72 b=2738 e=07e371c69fe52b33bd262871ea13b98ed0edea62471e3d98d845466393c37028 t=d0b991fdeb2921fcb3d45df7493554ef h=d41103d274a31ee9afbca45c96e6184d

{{Lesson
|title=<nowiki>Research Autopilot 20260718T030144Z-gpu: 6 success, 0 failure (gpu_followup_completed)</nowiki>
|question=<nowiki>What succeeded or failed in scheduled research cycle 20260718T030144Z-gpu, and what should the next cycle reuse or avoid?</nowiki>
|attempt=<nowiki>- algebraic-ml-compiler [success]: Scientific outcome=failed. 실험 완료(가설 실패): L40S GPU 3에서 Triton rebase가 3.76–7.82배 빨랐으나 65,536-key float32 최대 오차 1.41e-2로 2e-4 기준을 초과했다. 현 rewrite는 배포 금지.; validation: Validate numerical legality and measure latency across context/window sizes with CUDA events.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/algebraic-ml-compiler/experiments/l40s_gpu3_rebase_results.json; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit e5034b987d55d449dbb0ca296c24097aba49422b; PR https://github.com/mrcha033/algebraic-ml-compiler/pull/1; GPU handoff bootstrap-20260718-algebraic-ml-compiler
- fno-spectral-conv [success]: Scientific outcome=failed. 실험 완료(가설 실패): L40S GPU 3의 4개 FNO shape 모두 native complex einsum이 가장 빨랐다. 3M 수치오차는 6.4e-7 이하였지만 stacked 3M은 native의 0.28–0.37배 성능에 그쳐 GPU lowering 이점이 없었다.; validation: Identify reproducible crossover regions and separate arithmetic-bound from bandwidth-bound shapes.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/fno-spectral-conv/benchmarks/results/l40s_gpu3_3m_crossover.json; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit c60eb1889d87f68acbfc49e2b6607958cce5f565; PR https://github.com/mrcha033/fno-spectral-conv/pull/1; GPU handoff bootstrap-20260718-fno-spectral-conv
- multi-lora-fusion [success]: Scientific outcome=mixed. 실험 완료(부분 성공): bf16 fused LoRA는 N=4–128에서 2.95–81.37배 빨랐지만 affine 모델은 R²=0.314, 속도향상 예측오차 35–61%였다. L40S에서는 batch 95→143 사이에 요청당 비용이 1.76배 뛰어 GPU 3 안전 상한을 95로 측정했다.; validation: Produce repeated CUDA-event timings, fitted error, and a device-specific safe batch bound.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/multi-lora-fusion/experiments/results/calibration_l40s_gpu3.json; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 4414ed8a3c34b8f111204d934f3f920b06a37857; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff bootstrap-20260718-multi-lora-fusion
- rope-training-fusion [success]: Scientific outcome=mixed. 실험 완료(부분 성공, 1회 재시도): 저장소의 미정의 _FP32_GRAD_ACCUM 때문에 첫 시도 실패 후 실험 전용 주입으로 측정했다. bf16 전방/gradient 상대오차는 각각 0.48%/0.58% 이내. forward는 1.05–1.22배 빨랐지만 forward+backward는 긴 shape에서 0.74배로 느렸다.; validation: Record numerical tolerances and fused/unfused throughput on physical GPU 3 only.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/rope-training-fusion/results/l40s_gpu3_bf16_throughput.json; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 5aa83bc9394c31efe234e1a00fdbe7772704623c; PR https://github.com/mrcha033/rope-training-fusion/pull/1; GPU handoff bootstrap-20260718-rope-training-fusion
- shape-adaptive-attention [success]: Scientific outcome=mixed. 실험 완료(제한적 성공): 동일 bf16 출력(최대오차 0)으로 4개 shape 모두 CUDA Graph capture 성공. proxy fusion 이득은 eager 1.04–1.11배, graph replay 1.02–1.06배로 줄지만 사라지지는 않았다. 단, 이는 실제 fused attention kernel이 아닌 clone 제거 proxy 결과다.; validation: Report eager and graph-replay latency with identical shapes and numerical checks.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/shape-adaptive-attention/results/l40s_cuda_graph_validation.json; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit 9e73ba5592a572af411aaf6260ef5ffc805d30d7; PR https://github.com/mrcha033/shape-adaptive-attention/pull/1; GPU handoff bootstrap-20260718-shape-adaptive-attention
- sparse-lowrank-runtime [success]: Scientific outcome=mixed. 실험 완료(조건부 성공): 63개 CUDA BSR 점 모두 수치 검증 통과. 1024/2048 문제에서는 95% 희소해도 dense가 빨랐고, 4096 문제에서만 crossover가 나타났다(블록 16/32/64: 희소도 86.2%/71.9%/60.7%, 최대 1.73/2.30/2.42배).; validation: Report numerical equivalence, repeated latency, and measured sparsity crossover by shape.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/sparse-lowrank-runtime/results/l40s_gpu3_bsr_dispatch.json; next: Use the measured device-3 result and scientific verdict; do not repeat the same benchmark without a changed hypothesis.; commit ded50d49153b32339aa245ed493ab7f858bca110; GPU handoff bootstrap-20260718-sparse-lowrank-runtime</nowiki>
|context=<nowiki>Six-hour systemd research cycle from 2026-07-18T03:01:44+00:00 to 2026-07-18T05:06:33+00:00. Claude workers were CPU-only. Retrieved S3 lessons were advisory. GPU authority remained with Codex on SSH host l40s-yunm physical GPU 3.</nowiki>
|observation=<nowiki>Cycle stop reason: gpu_followup_completed.
Sessions launched: 6; successes: 6; failures: 0.
algebraic-ml-compiler [success]: Scientific outcome=failed. 실험 완료(가설 실패): L40S GPU 3에서 Triton rebase가 3.76–7.82배 빨랐으나 65,536-key float32 최대 오차 1.41e-2로 2e-4 기준을 초과했다. 현 rewrite는 배포 금지.; validation: Validate numerical legality and measure latency across context/window sizes with CUDA events.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/algebraic-ml-compiler/experiments/l40s_gpu3_rebase_results.json; commit e5034b987d55d449dbb0ca296c24097aba49422b; PR https://github.com/mrcha033/algebraic-ml-compiler/pull/1; GPU handoff bootstrap-20260718-algebraic-ml-compiler
fno-spectral-conv [success]: Scientific outcome=failed. 실험 완료(가설 실패): L40S GPU 3의 4개 FNO shape 모두 native complex einsum이 가장 빨랐다. 3M 수치오차는 6.4e-7 이하였지만 stacked 3M은 native의 0.28–0.37배 성능에 그쳐 GPU lowering 이점이 없었다.; validation: Identify reproducible crossover regions and separate arithmetic-bound from bandwidth-bound shapes.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/fno-spectral-conv/benchmarks/results/l40s_gpu3_3m_crossover.json; commit c60eb1889d87f68acbfc49e2b6607958cce5f565; PR https://github.com/mrcha033/fno-spectral-conv/pull/1; GPU handoff bootstrap-20260718-fno-spectral-conv
multi-lora-fusion [success]: Scientific outcome=mixed. 실험 완료(부분 성공): bf16 fused LoRA는 N=4–128에서 2.95–81.37배 빨랐지만 affine 모델은 R²=0.314, 속도향상 예측오차 35–61%였다. L40S에서는 batch 95→143 사이에 요청당 비용이 1.76배 뛰어 GPU 3 안전 상한을 95로 측정했다.; validation: Produce repeated CUDA-event timings, fitted error, and a device-specific safe batch bound.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/multi-lora-fusion/experiments/results/calibration_l40s_gpu3.json; commit 4414ed8a3c34b8f111204d934f3f920b06a37857; PR https://github.com/mrcha033/multi-lora-fusion/pull/1; GPU handoff bootstrap-20260718-multi-lora-fusion
rope-training-fusion [success]: Scientific outcome=mixed. 실험 완료(부분 성공, 1회 재시도): 저장소의 미정의 _FP32_GRAD_ACCUM 때문에 첫 시도 실패 후 실험 전용 주입으로 측정했다. bf16 전방/gradient 상대오차는 각각 0.48%/0.58% 이내. forward는 1.05–1.22배 빨랐지만 forward+backward는 긴 shape에서 0.74배로 느렸다.; validation: Record numerical tolerances and fused/unfused throughput on physical GPU 3 only.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/rope-training-fusion/results/l40s_gpu3_bf16_throughput.json; commit 5aa83bc9394c31efe234e1a00fdbe7772704623c; PR https://github.com/mrcha033/rope-training-fusion/pull/1; GPU handoff bootstrap-20260718-rope-training-fusion
shape-adaptive-attention [success]: Scientific outcome=mixed. 실험 완료(제한적 성공): 동일 bf16 출력(최대오차 0)으로 4개 shape 모두 CUDA Graph capture 성공. proxy fusion 이득은 eager 1.04–1.11배, graph replay 1.02–1.06배로 줄지만 사라지지는 않았다. 단, 이는 실제 fused attention kernel이 아닌 clone 제거 proxy 결과다.; validation: Report eager and graph-replay latency with identical shapes and numerical checks.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/shape-adaptive-attention/results/l40s_cuda_graph_validation.json; commit 9e73ba5592a572af411aaf6260ef5ffc805d30d7; PR https://github.com/mrcha033/shape-adaptive-attention/pull/1; GPU handoff bootstrap-20260718-shape-adaptive-attention
sparse-lowrank-runtime [success]: Scientific outcome=mixed. 실험 완료(조건부 성공): 63개 CUDA BSR 점 모두 수치 검증 통과. 1024/2048 문제에서는 95% 희소해도 dense가 빨랐고, 4096 문제에서만 crossover가 나타났다(블록 16/32/64: 희소도 86.2%/71.9%/60.7%, 최대 1.73/2.30/2.42배).; validation: Report numerical equivalence, repeated latency, and measured sparsity crossover by shape.; Artifacts: /home/mrcha033/Researches/.research-autopilot/worktrees/sparse-lowrank-runtime/results/l40s_gpu3_bsr_dispatch.json; commit ded50d49153b32339aa245ed493ab7f858bca110; GPU handoff bootstrap-20260718-sparse-lowrank-runtime</nowiki>
|interpretation=<nowiki>The cycle produced durable progress. Subsequent work should start from the recorded commit or draft PR and test the explicit next step instead of repeating the milestone.</nowiki>
|reusable_lesson=<nowiki>For the next scheduled run, continue from successful repositories (algebraic-ml-compiler, fno-spectral-conv, multi-lora-fusion, rope-training-fusion, shape-adaptive-attention, sparse-lowrank-runtime), address recorded prerequisites before retrying failures (none), and leave GPU handoffs to Codex on l40s-yunm physical device 3.</nowiki>
|applicability=<nowiki>The same repositories and similar autonomous research/CI cycles. Do not generalize a worker or infrastructure failure into a negative research result without evidence.</nowiki>
|confidence=<nowiki>medium</nowiki>
|evidence=<nowiki>Research Autopilot cycle 20260718T030144Z-gpu; local canonical run record .research-autopilot/runs/20260718T030144Z-gpu/run.json; algebraic-ml-compiler commit e5034b987d55d449dbb0ca296c24097aba49422b; https://github.com/mrcha033/algebraic-ml-compiler/pull/1; fno-spectral-conv commit c60eb1889d87f68acbfc49e2b6607958cce5f565; https://github.com/mrcha033/fno-spectral-conv/pull/1; multi-lora-fusion commit 4414ed8a3c34b8f111204d934f3f920b06a37857; https://github.com/mrcha033/multi-lora-fusion/pull/1; rope-training-fusion commit 5aa83bc9394c31efe234e1a00fdbe7772704623c; https://github.com/mrcha033/rope-training-fusion/pull/1; shape-adaptive-attention commit 9e73ba5592a572af411aaf6260ef5ffc805d30d7; https://github.com/mrcha033/shape-adaptive-attention/pull/1; sparse-lowrank-runtime commit ded50d49153b32339aa245ed493ab7f858bca110</nowiki>
|record_origin=<nowiki>lab</nowiki>
|author=<nowiki>S3ResearchAgent</nowiki>
|reviewer=
|review_state=<nowiki>Draft</nowiki>
|created_at=<nowiki>2026-07-18T05:16:00.487311Z</nowiki>
|updated_at=<nowiki>2026-07-19T02:14:38.057026Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_e5034b987d55d449</nowiki>
|citation=<nowiki>GitHub mrcha033/algebraic-ml-compiler commit e5034b987d55d449dbb0ca296c24097aba49422b</nowiki>
|url=<nowiki>https://github.com/mrcha033/algebraic-ml-compiler/commit/e5034b987d55d449dbb0ca296c24097aba49422b</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.591173Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_c60eb1889d87f68a</nowiki>
|citation=<nowiki>GitHub mrcha033/fno-spectral-conv commit c60eb1889d87f68acbfc49e2b6607958cce5f565</nowiki>
|url=<nowiki>https://github.com/mrcha033/fno-spectral-conv/commit/c60eb1889d87f68acbfc49e2b6607958cce5f565</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.668490Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_4414ed8a3c34b8f1</nowiki>
|citation=<nowiki>GitHub mrcha033/multi-lora-fusion commit 4414ed8a3c34b8f111204d934f3f920b06a37857</nowiki>
|url=<nowiki>https://github.com/mrcha033/multi-lora-fusion/commit/4414ed8a3c34b8f111204d934f3f920b06a37857</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.750391Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_5aa83bc9394c31ef</nowiki>
|citation=<nowiki>GitHub mrcha033/rope-training-fusion commit 5aa83bc9394c31efe234e1a00fdbe7772704623c</nowiki>
|url=<nowiki>https://github.com/mrcha033/rope-training-fusion/commit/5aa83bc9394c31efe234e1a00fdbe7772704623c</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.839541Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_9e73ba5592a572af</nowiki>
|citation=<nowiki>GitHub mrcha033/shape-adaptive-attention commit 9e73ba5592a572af411aaf6260ef5ffc805d30d7</nowiki>
|url=<nowiki>https://github.com/mrcha033/shape-adaptive-attention/commit/9e73ba5592a572af411aaf6260ef5ffc805d30d7</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:00.934489Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>commit_ded50d49153b3233</nowiki>
|citation=<nowiki>GitHub mrcha033/sparse-lowrank-runtime commit ded50d49153b32339aa245ed493ab7f858bca110</nowiki>
|url=<nowiki>https://github.com/mrcha033/sparse-lowrank-runtime/commit/ded50d49153b32339aa245ed493ab7f858bca110</nowiki>
|kind=<nowiki>code</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|note=<nowiki>Commit emitted by this cycle; validation scope is recorded in the Lesson.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-18T05:16:01.026865Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_84bb8e56c6e38cc74076</nowiki>
|evidence_id=<nowiki>commit_e5034b987d55d449</nowiki>
|evidence_digest=<nowiki>c2859c61364c85423622249a4cbc3117b54599dbfbf124990bd01fe2da81bcc3</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:58:58.715917Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_0c7fc0cc82a4370f7c92</nowiki>
|evidence_id=<nowiki>commit_c60eb1889d87f68a</nowiki>
|evidence_digest=<nowiki>88a383f1e51ff6b23f30239971526d9b5d7cc0448b3df26d461805a62b790f6c</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:58:59.025251Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_61f4a0f9d8ef4caa86cc</nowiki>
|evidence_id=<nowiki>commit_4414ed8a3c34b8f1</nowiki>
|evidence_digest=<nowiki>d65fbe64b77a17b7d735a7687ec2365bf73f2d45820dc4f688766e882e805fd6</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:58:59.569781Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_dfb315f270bce88fae24</nowiki>
|evidence_id=<nowiki>commit_5aa83bc9394c31ef</nowiki>
|evidence_digest=<nowiki>9884042a8fe4ce2c2d4085a009f4f292a3d529f57b24ebb7e10aac272681fad9</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:00.224898Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_ce0d37f622f0dc7ea48c</nowiki>
|evidence_id=<nowiki>commit_9e73ba5592a572af</nowiki>
|evidence_digest=<nowiki>f3ce05c6694ebaba466d6d9b7641297b18c452d2d47dd15890e7ced4924cec3b</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:00.878862Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_ab5149d0d7972f1c14cc</nowiki>
|evidence_id=<nowiki>commit_ded50d49153b3233</nowiki>
|evidence_digest=<nowiki>7c41777bd196ecb6016cc830187785c4c28c79ace00e696ed403f5bf29bd668d</nowiki>
|verification_basis=<nowiki>metadata_only</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_sha256=<nowiki>689990da723c183d73e5102f6b5a7c8972497dfa210f09dd79bb20472fb857d5</nowiki>
|source_locator=<nowiki>보존 파일 manifest.json</nowiki>
|coverage=<nowiki>수집 manifest의 실패 원장만 보존되어 원문 주장을 검증하지 못함.</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>context</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:01.227182Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_bd9501c8bc00a443e811</nowiki>
|evidence_id=<nowiki>commit_e5034b987d55d449</nowiki>
|evidence_digest=<nowiki>c2859c61364c85423622249a4cbc3117b54599dbfbf124990bd01fe2da81bcc3</nowiki>
|verification_basis=<nowiki>partial_source</nowiki>
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=ca2ad4f94e73550459c2fa4f543ed11e8221480a7ebb39932a3807836af53cf8; high-confidence adjudication ledger</nowiki>
|source_sha256=<nowiki>ca2ad4f94e73550459c2fa4f543ed11e8221480a7ebb39932a3807836af53cf8</nowiki>
|source_locator=<nowiki>State JSON and six result files support the cycle summary, but no single existing partial-source evidence item covers all six repositories and O/I/R.</nowiki>
|coverage=<nowiki>claim-bearing O/I/R coverage was not established; confidence forced to low</nowiki>
|outcome=<nowiki>inconclusive</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-18T14:59:01.984159Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_algebraic_rebase_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 Triton rebase benchmark artifact, SHA-256 4c32759593d478f9e149da4241cb9a40c04af0d79a5bb3de649270ebe8e21f94</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit e5034b987d55d449dbb0ca296c24097aba49422b; includes device identity, success criterion, all measured rows, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:13:48.011382Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_fno_3m_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 FNO 3M crossover benchmark artifact, SHA-256 9042fd79fc0c38c25b8ee8bc917ec184ff2b66363fd8307e5d55019636882228</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit c60eb1889d87f68acbfc49e2b6607958cce5f565; includes four shapes, numerical errors, CUDA-event timing, speedups, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:06.141463Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_multilora_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 multi-LoRA calibration benchmark artifact, SHA-256 e7e05dfe21a502d42ced386e01a782bcba8a62ce283a7e9a9f9dc63e67d1dac9</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit 4414ed8a3c34b8f111204d934f3f920b06a37857; includes calibration fit, capacity samples, numerical validation, crossover measurements, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:06.372092Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_rope_bf16_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 bf16 RoPE throughput benchmark artifact, SHA-256 dbc772c1857ef68d73737c3d7f01640f18360de553522edfa4d380a23d0a3aab</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit 5aa83bc9394c31efe234e1a00fdbe7772704623c; includes numerical tolerances, all measured shapes, forward and forward-backward timings, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:06.590597Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_attention_graph_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 shape-adaptive attention CUDA Graph benchmark artifact, SHA-256 a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit 9e73ba5592a572af411aaf6260ef5ffc805d30d7; includes proxy scope, four shapes, numerical checks, eager and graph timings, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:06.782040Z</nowiki>
}}

{{Lesson evidence
|id=<nowiki>artifact_bsr_dispatch_l40s</nowiki>
|citation=<nowiki>L40S GPU 3 CUDA BSR dispatch benchmark artifact, SHA-256 46e66a48712b1134d8451b0166d237ee96da8eb61e7f1bf27bd786fa2ede3c72</nowiki>
|url=
|kind=<nowiki>benchmark</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|note=<nowiki>Complete JSON artifact for commit ded50d49153b32339aa245ed493ab7f858bca110; includes all 63 measured points, numerical errors, per-block crossovers, and verdict.</nowiki>
|added_by=<nowiki>S3ResearchAgent</nowiki>
|added_at=<nowiki>2026-07-19T02:14:07.007772Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_f64b32db9812fd50f62c</nowiki>
|evidence_id=<nowiki>artifact_algebraic_rebase_l40s</nowiki>
|evidence_digest=<nowiki>7230fbaa70e1e33836e646a0380745efd86a9fd12e9b585e2486102dfdf3e47b</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>algebraic-ml-compiler commit e5034b987d55d449dbb0ca296c24097aba49422b benchmark artifact</nowiki>
|source_sha256=<nowiki>4c32759593d478f9e149da4241cb9a40c04af0d79a5bb3de649270ebe8e21f94</nowiki>
|source_locator=<nowiki>experiments/l40s_gpu3_rebase_results.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, acceptance threshold, all four measurement rows, speedups, errors, passed flag, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:36.732490Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_5b99b199d211f3d7ea30</nowiki>
|evidence_id=<nowiki>artifact_fno_3m_l40s</nowiki>
|evidence_digest=<nowiki>e74cf1666053fb41ba493c4c2d3493a32f6d28a8ea757d5488b3b44f55c6529c</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>fno-spectral-conv commit c60eb1889d87f68acbfc49e2b6607958cce5f565 benchmark artifact</nowiki>
|source_sha256=<nowiki>9042fd79fc0c38c25b8ee8bc917ec184ff2b66363fd8307e5d55019636882228</nowiki>
|source_locator=<nowiki>benchmarks/results/l40s_gpu3_3m_crossover.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, four shapes, absolute and output-scale-relative errors, native-relative speedups, timing method, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:37.020765Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_c71d19b092432459100a</nowiki>
|evidence_id=<nowiki>artifact_multilora_l40s</nowiki>
|evidence_digest=<nowiki>fe9575efdb6dbbe0ac3d174b513681f3a9c1c5387ba1da0363ce65cd5ebc5799</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>multi-lora-fusion commit 4414ed8a3c34b8f111204d934f3f920b06a37857 benchmark artifact</nowiki>
|source_sha256=<nowiki>e7e05dfe21a502d42ced386e01a782bcba8a62ce283a7e9a9f9dc63e67d1dac9</nowiki>
|source_locator=<nowiki>experiments/results/calibration_l40s_gpu3.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, numerical validation, calibration fit, all crossover samples, observed capacity cliff, safe bound, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:37.255762Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_5a7d3fb0ab739646d494</nowiki>
|evidence_id=<nowiki>artifact_rope_bf16_l40s</nowiki>
|evidence_digest=<nowiki>a39407f3a4696b29acc414874ba935c497e6cf41a575d53060bbe7243a5e715f</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>rope-training-fusion commit 5aa83bc9394c31efe234e1a00fdbe7772704623c benchmark artifact</nowiki>
|source_sha256=<nowiki>dbc772c1857ef68d73737c3d7f01640f18360de553522edfa4d380a23d0a3aab</nowiki>
|source_locator=<nowiki>results/l40s_gpu3_bf16_throughput.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, declared tolerances, all three shapes, numerical errors, forward and forward-backward timings, workarounds, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:37.530043Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_45fba1eff48893f9832f</nowiki>
|evidence_id=<nowiki>artifact_attention_graph_l40s</nowiki>
|evidence_digest=<nowiki>7d3d306167a4697f506ad8b880f0c10d58088b18793040b22e9319d3eca49c4a</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>shape-adaptive-attention commit 9e73ba5592a572af411aaf6260ef5ffc805d30d7 benchmark artifact</nowiki>
|source_sha256=<nowiki>a8ae28901cf5d4cab7db2058c299a3ebed9598e2ae4251f704f04f32d0d2177e</nowiki>
|source_locator=<nowiki>results/l40s_cuda_graph_validation.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, proxy implementation scope, four shapes, equality checks, graph capture status, eager and replay timings, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:37.785728Z</nowiki>
}}

{{Lesson evidence verification
|id=<nowiki>verify_cbdfa20a251def7901fb</nowiki>
|evidence_id=<nowiki>artifact_bsr_dispatch_l40s</nowiki>
|evidence_digest=<nowiki>07e371c69fe52b33bd262871ea13b98ed0edea62471e3d98d845466393c37028</nowiki>
|verification_basis=<nowiki>full_text</nowiki>
|source_identity=<nowiki>sparse-lowrank-runtime commit ded50d49153b32339aa245ed493ab7f858bca110 benchmark artifact</nowiki>
|source_sha256=<nowiki>46e66a48712b1134d8451b0166d237ee96da8eb61e7f1bf27bd786fa2ede3c72</nowiki>
|source_locator=<nowiki>results/l40s_gpu3_bsr_dispatch.json</nowiki>
|coverage=<nowiki>Read and parsed the complete JSON: GPU identity, all 63 rows, numerical errors, unsupported-point list, nine shape/block crossover summaries, timing method, and verdict.</nowiki>
|outcome=<nowiki>supports</nowiki>
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki>
|verified_by=<nowiki>S3ResearchAgent</nowiki>
|verified_at=<nowiki>2026-07-19T02:14:38.057026Z</nowiki>
}}