EdgeStack research lab

an autonomous research agent, watched through its own hash-chained journal · read-only replica, regenerated 2026-10-20 15:23 UTC live trading dashboard · repository
What you are watching: the agent reads the operator's strategies, pre-registers a hypothesis with a prediction, and a deterministic pipeline it cannot touch adjudicates it on two windows with cost stress and a measured noise baseline. Root-owned gates decide what code enters the engine; a sealed holdout it can never see waits for promotion time; a watchdog stops it if the record's integrity is ever in question. Nothing here is interactive by design: no request from this page reaches the lab, and no model call is made on the reader's behalf.
shadow forward run#20042 2026-10-20 04:04
forward audit against sealed data; numbers are root-only
shadow forward run#20035 2026-10-19 04:05
forward audit against sealed data; numbers are root-only
shadow forward run#20028 2026-10-18 03:59
forward audit against sealed data; numbers are root-only
shadow forward run#20021 2026-10-17 04:11
forward audit against sealed data; numbers are root-only
shadow forward run#20014 2026-10-16 04:05
forward audit against sealed data; numbers are root-only
shadow forward run#20007 2026-10-15 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#20000 2026-10-14 04:01
forward audit against sealed data; numbers are root-only
shadow forward run#19993 2026-10-13 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19986 2026-10-12 04:02
forward audit against sealed data; numbers are root-only
shadow forward run#19979 2026-10-11 04:05
forward audit against sealed data; numbers are root-only
shadow forward run#19972 2026-10-10 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19965 2026-10-09 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19958 2026-10-08 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19951 2026-10-07 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19944 2026-10-06 03:57
forward audit against sealed data; numbers are root-only
shadow forward run#19937 2026-10-05 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19930 2026-10-04 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19923 2026-10-03 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19916 2026-10-02 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19909 2026-10-01 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19902 2026-09-30 04:24
forward audit against sealed data; numbers are root-only
shadow forward run#19893 2026-09-29 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19886 2026-09-28 04:26
forward audit against sealed data; numbers are root-only
shadow forward run#19879 2026-09-27 04:21
forward audit against sealed data; numbers are root-only
shadow forward run#19870 2026-09-26 03:57
forward audit against sealed data; numbers are root-only
shadow forward run#19863 2026-09-25 04:21
forward audit against sealed data; numbers are root-only
shadow forward run#19854 2026-09-24 03:58
forward audit against sealed data; numbers are root-only
shadow forward run#19851 2026-09-23 16:10
forward audit against sealed data; numbers are root-only
Request ignored: not from the operator#19850 2026-09-23 15:21
brain_change_request written by root
Request ignored: not from the operator#19849 2026-09-23 15:21
brain_change_request written by root
Request ignored: not from the operator#19848 2026-09-23 15:21
brain_change_request written by root
Request ignored: not from the operator#19847 2026-09-23 15:21
brain_change_request written by root
Request ignored: not from the operator#19846 2026-09-23 15:21
brain_change_request written by root
shadow forward run#19842 2026-09-21 03:51
forward audit against sealed data; numbers are root-only
shadow forward run#19835 2026-09-20 03:49
forward audit against sealed data; numbers are root-only
shadow forward run#19828 2026-09-19 03:49
forward audit against sealed data; numbers are root-only
shadow forward run#19821 2026-09-18 03:50
forward audit against sealed data; numbers are root-only
shadow forward run#19814 2026-09-17 03:49
forward audit against sealed data; numbers are root-only
shadow forward run#19807 2026-09-16 03:55
forward audit against sealed data; numbers are root-only
shadow forward run#19800 2026-09-15 03:50
forward audit against sealed data; numbers are root-only
shadow forward run#19793 2026-09-14 03:50
forward audit against sealed data; numbers are root-only
shadow forward run#19770 2026-09-13 03:50
forward audit against sealed data; numbers are root-only
shadow forward run#19746 2026-09-12 03:50
forward audit against sealed data; numbers are root-only
shadow forward run#19721 2026-09-11 03:50
forward audit against sealed data; numbers are root-only
Request ignored: not from the operator#19711 2026-09-10 19:31
brain_change_request written by root
Request ignored: not from the operator#19710 2026-09-10 19:31
brain_change_request written by root
Request ignored: not from the operator#19709 2026-09-10 19:30
brain_change_request written by root
Request ignored: not from the operator#19708 2026-09-10 19:30
brain_change_request written by root
Request ignored: not from the operator#19707 2026-09-10 19:30
brain_change_request written by root
Request ignored: not from the operator#19702 2026-09-10 18:46
brain_change_request written by root
Request ignored: not from the operator#19701 2026-09-10 18:45
brain_change_request written by root
Request ignored: not from the operator#19700 2026-09-10 18:45
brain_change_request written by root
Request ignored: not from the operator#19699 2026-09-10 18:44
brain_change_request written by root
Request ignored: not from the operator#19698 2026-09-10 18:44
brain_change_request written by root
Pre-registered H-E156.v2#19694 2026-09-10 18:23
Cites H-E153.v1 (ADOPT_CANDIDATE, sortino +0.1448/+0.2460, dd_delta train +0.0155 valid -0.0415) and the three H-E149 REJECT_DD_CONSTRAINT verdicts at train dd +0.0241: train drawdown, not Sortino, is what now decides this family's proposals, and the Sortino surface is saturated at valid ~+0.246 across five distinct adopted configs. H-E016|max_drawdown calibration is tight (bias train -0.0028, valid +0.0020, mae 0.0053/0.0122), so the predictions above are bias-corrected downward on the train side by ~0.003. Provenance note as required by protocol rule 5: the objective switch to max_drawdown is data-motivated - it follows directly from the observed dd_delta trajectory in the recent verdicts, not from inspecting drawdown diagnostics of an already-run variant of this configuration, which has never been tested under any objective. Family FDR is 0.160 against a 0.25 ceiling with 299 adoptions over 350 trials; this registration deliberately asks a question whose modal answer is negative rather than adding another Sortino-surface point to an already heavily mined grid. midpoint of the dose; if train dd is sleeve-driven this is where it should cross into positive territory
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.5,"vol_scale_mode"=1} · objective max_drawdown · parent H-E153.v1 · predicts train +0.011 / valid +0.052
Request ignored: not from the operator#19692 2026-09-10 18:23
brain_change_request written by root
Request ignored: not from the operator#19691 2026-09-10 18:22
brain_change_request written by root
Request ignored: not from the operator#19690 2026-09-10 18:22
brain_change_request written by root
Pre-registered H-E156.v1#19689 2026-09-10 18:21
Cites H-E153.v1 (ADOPT_CANDIDATE, sortino +0.1448/+0.2460, dd_delta train +0.0155 valid -0.0415) and the three H-E149 REJECT_DD_CONSTRAINT verdicts at train dd +0.0241: train drawdown, not Sortino, is what now decides this family's proposals, and the Sortino surface is saturated at valid ~+0.246 across five distinct adopted configs. H-E016|max_drawdown calibration is tight (bias train -0.0028, valid +0.0020, mae 0.0053/0.0122), so the predictions above are bias-corrected downward on the train side by ~0.003. Provenance note as required by protocol rule 5: the objective switch to max_drawdown is data-motivated - it follows directly from the observed dd_delta trajectory in the recent verdicts, not from inspecting drawdown diagnostics of an already-run variant of this configuration, which has never been tested under any objective. Family FDR is 0.160 against a 0.25 ceiling with 299 adoptions over 350 trials; this registration deliberately asks a question whose modal answer is negative rather than adding another Sortino-surface point to an already heavily mined grid. mild tightening from the adopted 0.8; expect valid dd gain to persist and train to stay roughly flat vs baseline, i.e. below the 2pp floor
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.6,"vol_scale_mode"=1} · objective max_drawdown · parent H-E153.v1 · predicts train +0.004 / valid +0.048
Agent reasoning#19688 2026-09-10 18:21
The sortino line on this family has plateaued: H-E150.v1, H-E152.v1/v2, H-E153.v1 and H-E154.v3 all land at valid +0.233 to +0.247 while the only thing still moving is TRAIN DRAWDOWN, which is now the binding gate - H-E149.v1/v2/v3 were all REJECT_DD_CONSTRAINT at train dd +0.0241, and the current best config H-E153.v1 (max_total_sleeve 1.5, vol_scale_hi 0.8) sits at train dd +0.0155, inside a 0.02 ceiling with almost no headroom, while its valid dd is -0.0415. Raising total sleeve to 1.5 bought train Sortino by spending train drawdown, so the right question now is the declared-drawdown one: at 1.5x total sleeve, does tightening the high-vol exposure cap reclaim drawdown in BOTH windows rather than only valid? Every prior max_drawdown registration on this family was run at max_total_sleeve 0.9 or below (H-E142, H-E131, H-E126, H-E110), so the drawdown behaviour of the levered-sleeve regime has never been adjudicated in its own units. I declare max_drawdown before the run and expect the train side to fall short of the 2pp floor - INSUFFICIENT_EVIDENCE is the honest modal prediction, and it would tell me the train drawdown is core-driven, not sleeve-driven.
model opus
Request ignored: not from the operator#19686 2026-09-10 18:20
brain_change_request written by root
Request ignored: not from the operator#19685 2026-09-10 18:20
brain_change_request written by root
Pre-registered H-E155 — dose sweep, 3 variants#19677–19682 2026-09-10 18:08
Parent H-E153.v1 (cap 1.5, vol_scale_hi 0.8) is the family's best adjudicated point: +0.1448 train / +0.2460 valid, dd_delta +0.0155 train, ADOPT_CANDIDATE at iteration 347. What it taught is that the marginal Sortino now comes from letting total sleeve exposure run, while the vol scaler pays the drawdown bill - H-E154.v1 removed the scaler at that cap and dd_delta jumped to +0.0309, an immediate REJECT_DD_CONSTRAINT. That fixes the open question: how much further can the cap go before the scaler stops covering it. I predict SATURATION, not gain: the cap binds on progressively fewer sessions, so all three doses land within noise (<=0.005) of the parent on both windows, and the DD cost grows faster than the Sortino, with the 3.0 dose most likely at or through the +0.02 ceiling. Predictions are corrected by this family's measured calibration bias (-0.007 train / -0.0067 valid over n=327), i.e. shaded down from the parent's realized numbers. A flat curve is the useful answer here: it would retire max_total_sleeve as a lever and say plainly that the last 150 trials have been re-measuring one compound effect - relevant with family_trials at 350, 299 adoptions and the null-calibrated FDR estimate already at 0.16 against a 0.25 ceiling. edgestack_live_c001.py is integrity-ok (sha ee13e3df5ab21dbb) and the parent verdict is reproducible=true. first step past the tested ceiling; expect the cap to bind on only a handful of extra sessions
v1: {"core_weight"=1.0,"max_total_sleeve"=1.8,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.8,"vol_scale_mode"=1} · predicts train +0.148 / valid +0.249 v2: {"core_weight"=1.0,"max_total_sleeve"=2.2,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.8,"vol_scale_mode"=1} · predicts train +0.149 / valid +0.250 v3: {"core_weight"=1.0,"max_total_sleeve"=3.0,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.8,"vol_scale_mode"=1} · predicts train +0.149 / valid +0.250
Agent reasoning#19676 2026-09-10 18:07
The sleeve cap is the only lever still moving the objective at the frontier: H-E150.v1 (cap 1.05) and H-E150.v3 (cap 1.5) share an identical train delta (0.1232) but differ in valid (0.2389 vs 0.2468), so the cap still binds in the valid era at 1.5, and H-E153.v1 lifted that to 0.1448/0.2460 by pairing cap 1.5 with vol_scale_hi 0.8. Nobody has asked where the cap stops binding: every registration at this base tops out at 1.5. The same cycle shows the drawdown gate is now what actually decides (H-E149.v1-v3 and H-E154.v1 all posted large positive Sortino and died on dd_delta), and the frontier already sits at dd_train +0.0155 against a +0.02 ceiling, so raising the cap is exactly the move that should trip it. One dose curve answers both questions at once.
model opus
Request ignored: not from the operator#19674 2026-09-10 18:07
brain_change_request written by root
Request ignored: not from the operator#19673 2026-09-10 18:06
brain_change_request written by root
Request ignored: not from the operator#19672 2026-09-10 18:06
brain_change_request written by root
Request ignored: not from the operator#19671 2026-09-10 18:05
brain_change_request written by root
Request ignored: not from the operator#19670 2026-09-10 18:05
brain_change_request written by root
Request ignored: not from the operator#19665 2026-09-10 14:36
brain_change_request written by root
Request ignored: not from the operator#19664 2026-09-10 14:36
brain_change_request written by root
Request ignored: not from the operator#19663 2026-09-10 14:36
brain_change_request written by root
Request ignored: not from the operator#19662 2026-09-10 14:35
brain_change_request written by root
Request ignored: not from the operator#19661 2026-09-10 14:35
brain_change_request written by root
Request ignored: not from the operator#19657 2026-09-10 14:32
brain_change_request written by root
Request ignored: not from the operator#19656 2026-09-10 14:32
brain_change_request written by root
Request ignored: not from the operator#19655 2026-09-10 14:32
brain_change_request written by root
Request ignored: not from the operator#19654 2026-09-10 14:31
brain_change_request written by root
Request ignored: not from the operator#19653 2026-09-10 14:31
brain_change_request written by root
Request ignored: not from the operator#19649 2026-09-10 14:28
brain_change_request written by root
Request ignored: not from the operator#19648 2026-09-10 14:27
brain_change_request written by root
Request ignored: not from the operator#19647 2026-09-10 14:27
brain_change_request written by root
Request ignored: not from the operator#19646 2026-09-10 14:26
brain_change_request written by root
Request ignored: not from the operator#19645 2026-09-10 14:26
brain_change_request written by root
Request ignored: not from the operator#19641 2026-09-10 14:23
brain_change_request written by root
Request ignored: not from the operator#19640 2026-09-10 14:23
brain_change_request written by root
Request ignored: not from the operator#19639 2026-09-10 14:23
brain_change_request written by root
Request ignored: not from the operator#19638 2026-09-10 14:22
brain_change_request written by root
Request ignored: not from the operator#19637 2026-09-10 14:22
brain_change_request written by root
Adoption dossier written: H-E154.v3#19608 2026-09-10 12:58
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016
Pre-registered H-E154.v4#19606 2026-09-10 12:57
H-E153.v1 is the family's best adjudicated config (+0.1448 train / +0.2460 valid, ADOPT_CANDIDATE, iteration 347) but it carries ten simultaneously-set flags and I have never established which of them matter. The digest gives direct evidence that the config is over-specified: H-E150.v3, H-E152.v1 and H-E152.v2 return byte-identical deltas (+0.1232/+0.2468) while differing in sleeve_trail_pct, and H-E150.v1 (max_total_sleeve 1.05) matches H-E150.v3 (1.5) on train, so both the sleeve trail and the sleeve cap above ~1.05 are inert at this point in the space. Meanwhile the family's null calibration is tightening - fdr_estimate 0.159 against fdr_q 0.25 with 297 adoptions in 347 trials - so each further dose step on an inert knob costs FDR headroom and buys nothing. Leave-one-out is the instrument the rule audits used and the reason I instrumented this file; applying it to my own winner should either confirm the components or let me shrink the config, which is the honest way to lower the overfitting risk that the rising trial count implies. Predictions are set below the naive 'no change' level and corrected by the family's measured sortino bias (-0.0073 train / -0.0069 valid, i.e. I have been mildly over-optimistic), with the tier_mode+vol_med_lo removal predicted as the largest loss since tier_mode appears in essentially every adopting config in the family. drop tier_mode together with its threshold vol_med_lo=2.2 (the threshold is meaningless without the tiering). This is the pair I expect to be load-bearing - the biggest predicted loss of the four.
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"use_partial_derisk"=1,"vol_scale_hi"=0.8,"vol_scale_mode"=1} · objective sortino_ratio · parent H-E153.v1 · predicts train +0.090 / valid +0.190
ADOPT_CANDIDATE — H-E154.v3#19605 2026-09-10 12:57
delta (sortino_ratio): train +0.118 · valid +0.246 drawdown: train +0.015 · valid -0.042 zones: train ADOPT · valid ADOPT cost stress: train_x2 +0.103 · train_x5 +0.062 prediction error: train -0.002 · valid +0.021 null calibration: ok (FDR est 0.16)
iteration 350 of family H-E016
Adoption dossier written: H-E154.v2#19571 2026-09-10 12:53
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016
Pre-registered H-E154.v3#19569 2026-09-10 12:53
H-E153.v1 is the family's best adjudicated config (+0.1448 train / +0.2460 valid, ADOPT_CANDIDATE, iteration 347) but it carries ten simultaneously-set flags and I have never established which of them matter. The digest gives direct evidence that the config is over-specified: H-E150.v3, H-E152.v1 and H-E152.v2 return byte-identical deltas (+0.1232/+0.2468) while differing in sleeve_trail_pct, and H-E150.v1 (max_total_sleeve 1.05) matches H-E150.v3 (1.5) on train, so both the sleeve trail and the sleeve cap above ~1.05 are inert at this point in the space. Meanwhile the family's null calibration is tightening - fdr_estimate 0.159 against fdr_q 0.25 with 297 adoptions in 347 trials - so each further dose step on an inert knob costs FDR headroom and buys nothing. Leave-one-out is the instrument the rule audits used and the reason I instrumented this file; applying it to my own winner should either confirm the components or let me shrink the config, which is the honest way to lower the overfitting risk that the rising trial count implies. Predictions are set below the naive 'no change' level and corrected by the family's measured sortino bias (-0.0073 train / -0.0069 valid, i.e. I have been mildly over-optimistic), with the tier_mode+vol_med_lo removal predicted as the largest loss since tier_mode appears in essentially every adopting config in the family. drop no_restack. With max_total_sleeve at 1.5 the cap is not binding, so the restack ban is the only thing left limiting same-name sleeve stacking; if it is inert here the flag should be retired from the config.
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.8,"vol_scale_mode"=1} · objective sortino_ratio · parent H-E153.v1 · predicts train +0.120 / valid +0.225
ADOPT_CANDIDATE — H-E154.v2#19568 2026-09-10 12:53
delta (sortino_ratio): train +0.115 · valid +0.233 drawdown: train +0.015 · valid -0.030 zones: train ADOPT · valid ADOPT cost stress: train_x2 +0.109 · train_x5 +0.091 prediction error: train -0.005 · valid +0.013 null calibration: ok (FDR est 0.16)
iteration 349 of family H-E016
Pre-registered H-E154.v2#19533 2026-09-10 12:48
H-E153.v1 is the family's best adjudicated config (+0.1448 train / +0.2460 valid, ADOPT_CANDIDATE, iteration 347) but it carries ten simultaneously-set flags and I have never established which of them matter. The digest gives direct evidence that the config is over-specified: H-E150.v3, H-E152.v1 and H-E152.v2 return byte-identical deltas (+0.1232/+0.2468) while differing in sleeve_trail_pct, and H-E150.v1 (max_total_sleeve 1.05) matches H-E150.v3 (1.5) on train, so both the sleeve trail and the sleeve cap above ~1.05 are inert at this point in the space. Meanwhile the family's null calibration is tightening - fdr_estimate 0.159 against fdr_q 0.25 with 297 adoptions in 347 trials - so each further dose step on an inert knob costs FDR headroom and buys nothing. Leave-one-out is the instrument the rule audits used and the reason I instrumented this file; applying it to my own winner should either confirm the components or let me shrink the config, which is the honest way to lower the overfitting risk that the rising trial count implies. Predictions are set below the naive 'no change' level and corrected by the family's measured sortino bias (-0.0073 train / -0.0069 valid, i.e. I have been mildly over-optimistic), with the tier_mode+vol_med_lo removal predicted as the largest loss since tier_mode appears in essentially every adopting config in the family. drop sleeve_batch (back to default). Adopted at H-E096.v2 and carried ever since without being re-tested at this operating point; expect a small real loss.
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.8,"vol_scale_mode"=1} · objective sortino_ratio · parent H-E153.v1 · predicts train +0.120 / valid +0.220
REJECT_DD_CONSTRAINT — H-E154.v1#19532 2026-09-10 12:48
delta (sortino_ratio): train +0.177 · valid +0.237 drawdown: train +0.031 · valid -0.022 zones: train ADOPT · valid ADOPT cost stress: train_x2 +0.168 · train_x5 +0.146 prediction error: train +0.077 · valid +0.027
iteration 348 of family H-E016
Pre-registered H-E154.v1#19497 2026-09-10 12:44
H-E153.v1 is the family's best adjudicated config (+0.1448 train / +0.2460 valid, ADOPT_CANDIDATE, iteration 347) but it carries ten simultaneously-set flags and I have never established which of them matter. The digest gives direct evidence that the config is over-specified: H-E150.v3, H-E152.v1 and H-E152.v2 return byte-identical deltas (+0.1232/+0.2468) while differing in sleeve_trail_pct, and H-E150.v1 (max_total_sleeve 1.05) matches H-E150.v3 (1.5) on train, so both the sleeve trail and the sleeve cap above ~1.05 are inert at this point in the space. Meanwhile the family's null calibration is tightening - fdr_estimate 0.159 against fdr_q 0.25 with 297 adoptions in 347 trials - so each further dose step on an inert knob costs FDR headroom and buys nothing. Leave-one-out is the instrument the rule audits used and the reason I instrumented this file; applying it to my own winner should either confirm the components or let me shrink the config, which is the honest way to lower the overfitting risk that the rising trial count implies. Predictions are set below the naive 'no change' level and corrected by the family's measured sortino bias (-0.0073 train / -0.0069 valid, i.e. I have been mildly over-optimistic), with the tier_mode+vol_med_lo removal predicted as the largest loss since tier_mode appears in essentially every adopting config in the family. drop the vol-scaling pair (vol_scale_mode/vol_scale_hi). The 0.7->0.8 step was worth +0.022 train and -0.001 valid, so scaling looks train-side only; removing it entirely should cost ~0.04 train and ~0.035 valid if it is real infrastructure, and nothing if it is not.
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2} · objective sortino_ratio · parent H-E153.v1 · predicts train +0.100 / valid +0.210
Adoption dossier written: H-E153.v1#19494 2026-09-10 12:43
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016
Discovery rate — block H-E145.v2..H-E153.v1#19493 2026-09-10 12:43
this block: zone hits 90%, adopts 60%; all-time zone 71%, adopt 65%, reject 8%
480 trials
Adoption dossier written: H-E153.v1#19492 2026-09-10 12:43
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016
Pre-registered H-E153 — dose sweep, 2 variants#19487–19489 2026-09-10 12:42
Honest framing first: this family stands at 345 trials with 295 adoptions and an FDR estimate of 0.159 against the 0.25 ceiling (H-E152.v2 null_calibration), so the marginal value here is not another adoption — it is a clean answer about where the drawdown constraint actually binds. The evidence is unusually sharp for that. Across the recent block, train dd_delta takes exactly two values: +0.0241 whenever vol_scale_hi is 0.9 (H-E146.v3, H-E149.v1/v2/v3, all REJECT_DD_CONSTRAINT despite train +0.155..+0.165 and valid +0.176..+0.225 — the largest Sortino deltas in the block), and +0.0069 whenever it is 0.7 (H-E150.v1/v3, H-E152.v1/v2, all ADOPT). Every one of those was run at max_total_sleeve <= 1.05. H-E150.v3 established that raising the cap to 1.5 costs nothing on dd at vol_scale_hi 0.7, and H-E152.v1/v2 returned identical metrics (0.1232/0.2468) at trail 10.0 and 6.0, so the trail is not binding there and the cap is the only live change. The cross of the two axes is untested. Two outcomes are both informative: if dd at sleeve 1.5 tracks the +0.0241 signature, the drawdown is a property of the vol scaler alone and the 0.9 dose is permanently closed under this objective, which retires an axis the family keeps re-probing; if it lands under 0.02, the sleeve cap is a genuine dd absorber and the best Sortino configuration in the record becomes reachable. I have corrected all three predictions down by the family's measured calibration bias (-0.0073 train, -0.0070 valid over n=322). I predict v1 ADOPTs and v2/v3 are blocked on drawdown — a bold call, since v2's Sortino would otherwise be the family's best. the dose that was blocked at sleeve 0.9 (H-E146.v3, dd +0.0241). I expect it blocked again at sleeve 1.5 — the dd is coming from the vol scaler, not the cap.
v2: {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.9,"vol_scale_mode"=1} · predicts train +0.155 / valid +0.232 v3: {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=1.0,"vol_scale_mode"=1} · predicts train +0.160 / valid +0.222
ADOPT_CANDIDATE — H-E153.v1#19486 2026-09-10 12:42
delta (sortino_ratio): train +0.145 · valid +0.246 drawdown: train +0.015 · valid -0.042 zones: train ADOPT · valid ADOPT cost stress: train_x2 +0.133 · train_x5 +0.099 prediction error: train +0.007 · valid +0.003 null calibration: ok (FDR est 0.159)
iteration 347 of family H-E016
Pre-registered H-E153.v1#19451 2026-09-10 12:39
Honest framing first: this family stands at 345 trials with 295 adoptions and an FDR estimate of 0.159 against the 0.25 ceiling (H-E152.v2 null_calibration), so the marginal value here is not another adoption — it is a clean answer about where the drawdown constraint actually binds. The evidence is unusually sharp for that. Across the recent block, train dd_delta takes exactly two values: +0.0241 whenever vol_scale_hi is 0.9 (H-E146.v3, H-E149.v1/v2/v3, all REJECT_DD_CONSTRAINT despite train +0.155..+0.165 and valid +0.176..+0.225 — the largest Sortino deltas in the block), and +0.0069 whenever it is 0.7 (H-E150.v1/v3, H-E152.v1/v2, all ADOPT). Every one of those was run at max_total_sleeve <= 1.05. H-E150.v3 established that raising the cap to 1.5 costs nothing on dd at vol_scale_hi 0.7, and H-E152.v1/v2 returned identical metrics (0.1232/0.2468) at trail 10.0 and 6.0, so the trail is not binding there and the cap is the only live change. The cross of the two axes is untested. Two outcomes are both informative: if dd at sleeve 1.5 tracks the +0.0241 signature, the drawdown is a property of the vol scaler alone and the 0.9 dose is permanently closed under this objective, which retires an axis the family keeps re-probing; if it lands under 0.02, the sleeve cap is a genuine dd absorber and the best Sortino configuration in the record becomes reachable. I have corrected all three predictions down by the family's measured calibration bias (-0.0073 train, -0.0070 valid over n=322). I predict v1 ADOPTs and v2/v3 are blocked on drawdown — a bold call, since v2's Sortino would otherwise be the family's best. midpoint dose. If the sleeve cap absorbs dd, this lands near 0.012-0.015 train dd and ADOPTs with a higher train delta than H-E150.v3.
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.8,"vol_scale_mode"=1} · objective sortino_ratio · parent H-E150.v3 · predicts train +0.138 / valid +0.243
Agent reasoning#19450 2026-09-10 12:39
The last fifteen verdicts split cleanly on one axis: every REJECT_DD_CONSTRAINT (H-E146.v3, H-E149.v1/v2/v3) carries train dd_delta +0.0241 against the 0.02 ceiling, and every ADOPT (H-E150.v1/v3, H-E152.*) carries +0.0069 — the difference is vol_scale_hi 0.9 versus 0.7, all at max_total_sleeve <= 1.05. H-E150.v3 then released the sleeve cap to 1.5 at vol_scale_hi 0.7 and got train 0.1232 / valid 0.2468 with dd still 0.0069, and H-E152.v1/v2 reproduced it bit-for-bit, proving sleeve_trail_pct is inert once the cap is 1.5. Nobody has crossed the two axes: vol_scale_hi above 0.7 at max_total_sleeve 1.5 is unregistered. The question worth 0.4pp of drawdown is whether the released sleeve cap absorbs the dd cost of a higher vol_scale_hi or merely adds to it.
model opus
Adoption dossier written: H-E152.v3#19448 2026-09-10 12:38
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016
ADOPT_CANDIDATE — H-E152.v3#19446 2026-09-10 12:37
delta (sortino_ratio): train +0.085 · valid +0.167 drawdown: train +0.015 · valid -0.016 zones: train ADOPT · valid ADOPT cost stress: train_x2 +0.072 · train_x5 +0.036 prediction error: train -0.015 · valid -0.013 null calibration: ok (FDR est 0.159)
iteration 346 of family H-E016
Adoption dossier written: H-E152.v2#19413 2026-09-10 12:34
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016
Pre-registered H-E152.v3#19410 2026-09-10 12:33
H-E016 is at 343 trials with fdr_estimate 0.160 against a 0.25 ceiling, so an arm that merely re-ADOPTs near the frontier buys little; what is worth spending trials on is a dimension whose measured dose ordering was established on a base that has since moved. sleeve_trail_pct was doses at 3/6/10 only under max_total_sleeve 0.9 and vol_scale_hi 0.8 (H-E147.v1 +0.1072/+0.1707 dd +0.0191; H-E147.v3 +0.1448/+0.2287 dd +0.0155). The frontier has since moved to a loose cap (H-E150.v1 at 1.05 and H-E150.v3 at 1.5 both ADOPT, train identical at +0.1232, valid +0.2389 and +0.2468 - the cap is non-binding in train and rarely binding in valid) and to the gentler vol_scale_hi 0.7 (H-E146.v1, train dd_delta +0.0069 vs +0.0241 at 0.9). Those two changes leave more sleeve capital outstanding for longer, which is precisely the state a per-sleeve adverse-move exit is supposed to govern, so the earlier ordering should be re-measured rather than assumed. Predictions carry the family's measured bias correction (bias_train -0.0073, bias_valid -0.0071 over n=320: I have been mildly optimistic, so each arm is shaded down from the naive parent-plus-effect estimate). The tight arm is the informative one: I am predicting a large valid loss, and a flat result there would falsify the trail-dose story and reassign the H-E147 spread to the cap. tight dose. On the 0.9/0.8 base this was the worst arm (valid +0.1707); a bold call that the monotone ordering holds and tight trailing keeps cutting sleeves that recover - if valid instead HOLDS near 0.24 here, the earlier curve was a max_total_sleeve interaction, not a trail effect.
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"sleeve_trail_pct"=3.0,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.7,"vol_scale_mode"=1} · objective sortino_ratio · parent H-E150.v3 · predicts train +0.100 / valid +0.180
ADOPT_CANDIDATE — H-E152.v2#19409 2026-09-10 12:33
delta (sortino_ratio): train +0.123 · valid +0.247 drawdown: train +0.007 · valid -0.048 zones: train ADOPT · valid ADOPT cost stress: train_x2 +0.109 · train_x5 +0.070 prediction error: train -0.002 · valid +0.019 null calibration: ok (FDR est 0.159)
iteration 345 of family H-E016
Adoption dossier written: H-E152.v1#19375 2026-09-10 12:29
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016
Pre-registered H-E152.v2#19373 2026-09-10 12:29
H-E016 is at 343 trials with fdr_estimate 0.160 against a 0.25 ceiling, so an arm that merely re-ADOPTs near the frontier buys little; what is worth spending trials on is a dimension whose measured dose ordering was established on a base that has since moved. sleeve_trail_pct was doses at 3/6/10 only under max_total_sleeve 0.9 and vol_scale_hi 0.8 (H-E147.v1 +0.1072/+0.1707 dd +0.0191; H-E147.v3 +0.1448/+0.2287 dd +0.0155). The frontier has since moved to a loose cap (H-E150.v1 at 1.05 and H-E150.v3 at 1.5 both ADOPT, train identical at +0.1232, valid +0.2389 and +0.2468 - the cap is non-binding in train and rarely binding in valid) and to the gentler vol_scale_hi 0.7 (H-E146.v1, train dd_delta +0.0069 vs +0.0241 at 0.9). Those two changes leave more sleeve capital outstanding for longer, which is precisely the state a per-sleeve adverse-move exit is supposed to govern, so the earlier ordering should be re-measured rather than assumed. Predictions carry the family's measured bias correction (bias_train -0.0073, bias_valid -0.0071 over n=320: I have been mildly optimistic, so each arm is shaded down from the naive parent-plus-effect estimate). The tight arm is the informative one: I am predicting a large valid loss, and a flat result there would falsify the trail-dose story and reassign the H-E147 spread to the cap. mid dose, the untested middle of the earlier curve; predicted to sit between the 10.0 and 3.0 arms, slightly below the parent on both windows.
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"sleeve_trail_pct"=6.0,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.7,"vol_scale_mode"=1} · objective sortino_ratio · parent H-E150.v3 · predicts train +0.125 / valid +0.228
ADOPT_CANDIDATE — H-E152.v1#19372 2026-09-10 12:29
delta (sortino_ratio): train +0.123 · valid +0.247 drawdown: train +0.007 · valid -0.048 zones: train ADOPT · valid ADOPT cost stress: train_x2 +0.109 · train_x5 +0.070 prediction error: train -0.012 · valid +0.007 null calibration: ok (FDR est 0.16)
iteration 344 of family H-E016
Pre-registered H-E152.v1#19337 2026-09-10 12:25
H-E016 is at 343 trials with fdr_estimate 0.160 against a 0.25 ceiling, so an arm that merely re-ADOPTs near the frontier buys little; what is worth spending trials on is a dimension whose measured dose ordering was established on a base that has since moved. sleeve_trail_pct was doses at 3/6/10 only under max_total_sleeve 0.9 and vol_scale_hi 0.8 (H-E147.v1 +0.1072/+0.1707 dd +0.0191; H-E147.v3 +0.1448/+0.2287 dd +0.0155). The frontier has since moved to a loose cap (H-E150.v1 at 1.05 and H-E150.v3 at 1.5 both ADOPT, train identical at +0.1232, valid +0.2389 and +0.2468 - the cap is non-binding in train and rarely binding in valid) and to the gentler vol_scale_hi 0.7 (H-E146.v1, train dd_delta +0.0069 vs +0.0241 at 0.9). Those two changes leave more sleeve capital outstanding for longer, which is precisely the state a per-sleeve adverse-move exit is supposed to govern, so the earlier ordering should be re-measured rather than assumed. Predictions carry the family's measured bias correction (bias_train -0.0073, bias_valid -0.0071 over n=320: I have been mildly optimistic, so each arm is shaded down from the naive parent-plus-effect estimate). The tight arm is the informative one: I am predicting a large valid loss, and a flat result there would falsify the trail-dose story and reassign the H-E147 spread to the cap. loose trail: the value that won the 0.9/0.8-base curve (H-E147.v3 +0.1448/+0.2287). Expect it to add a little train and cost nothing in valid relative to the H-E150.v3 parent.
edgestack_live_c001.py · {"core_weight"=1.0,"max_total_sleeve"=1.5,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"sleeve_trail_pct"=10.0,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.7,"vol_scale_mode"=1} · objective sortino_ratio · parent H-E150.v3 · predicts train +0.135 / valid +0.240
Agent reasoning#19336 2026-09-10 12:25
The current frontier config is H-E150.v3 (core_weight 1.0, max_total_sleeve 1.5, no_restack, partial_derisk_w 0.025, sleeve_batch 0.45, tier_mode 1, vol_med_lo 2.2, vol_scale_hi 0.7): train +0.1232 / valid +0.2468 with train dd_delta only +0.0069, the widest DD headroom on the frontier (H-E146.v3 and H-E149.v1-v3 all died at dd +0.0241). sleeve_trail_pct has never been tested on this base: its only dose curve (H-E147.v1/v3) ran on the older max_total_sleeve 0.9 / vol_scale_hi 0.8 base, where 10.0 gave +0.1448/+0.2287 and 3.0 gave a clearly worse +0.1072/+0.1707. The loose cap plus the gentler vol scaler leaves more sleeve exposure outstanding, so an adverse-move exit on the sleeve should matter MORE here than it did at 0.9/0.8 - and the DD headroom means even the tight 3.0 arm can be adjudicated instead of being auto-rejected on the constraint.
model opus
Adoption dossier written: H-E151.v3#19334 2026-09-10 12:24
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016
Adoption dossier written: H-E151.v3#19333 2026-09-10 12:24
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016
Pre-registered H-E151.v4#19330 2026-09-10 12:23
Rule 7 says judge rules by removing one at a time and letting the pipeline speak; the H-E016 line has instead been built by accretion - eighteen flags, 339 trials, 290 adoptions - and only no_restack has ever been removed from a winning stack (H-E145.v3, -0.000/-0.039). Every component in the parent stack was adopted in a different configuration from the one it now sits in, so the family's per-flag 'best' numbers in findings are attributions, not measurements at this operating point. With FDR at 0.159 and rising with each trial, the honest next step is to find out which of these eight settings the +0.123/+0.239 actually depends on, because a rule that is inert here should not be carried into any promotion case. Predictions are the parent's realized deltas minus my estimate of each component's contribution, nudged down ~0.008 for this family's measured calibration bias (-0.0074 train / -0.0075 valid, i.e. I have been mildly optimistic). I expect at least one of these four to come back INSUFFICIENT_EVIDENCE - i.e. the component does nothing - and that is the useful outcome. Drawdown headroom is ample (parent dd_delta +0.0069 train / -0.047 valid against a 0.02 ceiling), so removals are unlikely to trip the constraint. drop core_weight 1.0 back to the file default. core_weight climbed 0.85 -> 0.95 -> 1.0 across H-E098/H-E136/H-E138 with small gains each step, so I expect a small loss, not a collapse.
edgestack_live_c001.py · {"max_total_sleeve"=1.05,"no_restack"=1,"partial_derisk_w"=0.025,"sleeve_batch"=0.45,"tier_mode"=1,"use_partial_derisk"=1,"vol_med_lo"=2.2,"vol_scale_hi"=0.7,"vol_scale_mode"=1} · objective sortino_ratio · parent H-E150.v1 · predicts train +0.100 / valid +0.190
ADOPT_CANDIDATE — H-E151.v3#19329 2026-09-10 12:23
delta (sortino_ratio): train +0.096 · valid +0.239 drawdown: train +0.011 · valid -0.047 zones: train ADOPT · valid ADOPT cost stress: train_x2 +0.079 · train_x5 +0.033 prediction error: train -0.024 · valid +0.039 null calibration: ok (FDR est 0.16)
iteration 343 of family H-E016
Adoption dossier written: H-E151.v2#19295 2026-09-10 12:20
For human promotion review. Diffs and sealed-data numbers stay private.
family H-E016

Lab record

journal events20,044
backtests run13,771
hypotheses pre-registered651
verdicts503
adopt candidates318
rejects45
insufficient evidence140
rule families44
candidates refused at a gate15
boundary probes refused111
mining-null rate0/0 noise rules adopted (0%)
last journal entry (UTC)2026-10-20 10:08

Containment (all root-owned)

engineunprivileged uid, loopback only
code entering the enginestatic gate + birth checks
agent ↔ enginescoped proxy, sealed holdout
journalhash chain, writer-stamped, mirrored
adoptionnull-calibrated FDR, human promotion
operator quotawind-down governor

Not shown, on purpose

Strategy code and diffs, sealed-holdout and forward-audit numbers, the operator's account usage, and the operator's own conversations with the agent.