| name | lockbox-holdout |
| description | The single-touch lockbox — a final anti-overfitting holdout run once, after design freeze, on a window held out from every fold, sweep, and search. Use when finalizing a bakeoff winner before deploy, setting up the A/B/C baselines as OOS bars, or running the S1.5 gate-coherence auto-relax. Covers why looking at the lockbox twice burns it, the lockbox pass conditions, and the three baselines. The lockbox is distinct from the walk-forward OOS folds. |
| license | MIT |
| metadata | {"author":"Austin Starks","version":"1.0.0","created":"2026-07-03T00:00:00.000Z","last_reviewed":"2026-07-03T00:00:00.000Z","review_interval_days":90} |
| activation | /lockbox-holdout |
| provenance | {"maintainer":"Austin Starks","source":"public-portfolio-challenge episode-10 / episode-11 runbooks"} |
Single-Touch Lockbox & Baselines
The lockbox is a final holdout that no fold, sweep, or search ever touches — the last line of defense
against calendar-fit selection pressure. It is distinct from the walk-forward OOS folds
(walk-forward-oos), which are used repeatedly during search; the lockbox is touched exactly once.
The lockbox
- What: the walk-forward span stops
lockbox_width_days = 126 (~6 months) before the run date.
That final window (run date − 126d) → run date is the lockbox — held out from ALL folds, ALL
sweeps, ALL search.
- How: only the assembled deploy-shape book that already passed every gate on the walk-forward
aggregate runs over the lockbox, exactly once, after design freeze (Stage S2).
- Pass conditions (frozen at S0, do not move them after seeing results):
- lockbox OOS return ≥ worst single-fold walk-forward OOS return;
- lockbox maxDD ≤ 55%;
- posture clean (
audit_backtest_posture, all four conditions);
- breadth ≥ 9 eligible names (
audit_backtest_breadth — see breadth-audit).
Single-touch is absolute
If you look at the lockbox and then iterate the design, the lockbox is burned — move the
walk-forward span back and hold out a fresh tail before any deploy. A lockbox failure is treated as
calendar-fit selection pressure and means no deploy, except by a logged owner override that
explicitly names the lockbox.
The three baselines (A/B/C) as OOS bars (Stage S1)
Loaded from committed snapshots/*.json via create_portfolio. Score A and B on the current engine;
copy C's frozen published numbers as the bar to beat.
- A — equity buy&hold (the full universe). A return bar only, never a Sortino bar — its Sortino
reflects an equity-rally smoothness a leveraged long-premium book can't match.
- B — naive LEAP ladder (canonical spec: all names, no rank/filter, 14-day cadence, 8%-of-portfolio
per name under 95% budget, structure = first affordable rung of
[Δ0.50 call → Δ0.55/0.25 → Δ0.55/0.40 → Δ0.50/0.42 vertical], all 180–365 DTE, single exit at
DTE ≤ 45). A Sortino bar only in folds with ≥ 9/20 breadth.
- C — frozen incumbent bar with published per-fold OOS numbers, copied verbatim (do not re-run to
"improve" them).
S1.5 — Gate-coherence auto-relax (deterministic, no owner round-trip)
Before designing, check whether "beat Baseline B" and the ≤55% posture cap are jointly satisfiable
— B is a ~95%-deployed book, so a posture-capped finalist can't out-deploy it. If unsatisfiable,
AUTO-RELAX Baseline B: derate B's totalBudget until its own median daily deployment ≤ 55%, re-run
its S1 scoring, and log original vs posture-matched B. This is not a gate relaxation and not an owner
decision — only the benchmark is made comparable; the thresholds stay frozen.
