# Rationale (candidate 3)

## What I looked at

- Read in full: `modules/prime.py`, `spread.py`, `hedge.py`, `fxcontrol.py`, `news.py`, `core.py`, `volmodel.py`; `modules/broker_map.py`; `rules.json`; the strategy, `acceptance.py`, `run_live.py`, the systemd unit and env keys (PRIME_SIDE, PRIME_WINDOW only); notebook cells 90-121 (sections 24-26) as text; the paper's answer, rules, funded, wallet, cell, map, front, checks and open sections; `decision.json`, `front.json`; the cached `news_battery.json`; the vault entries on the clock, the deployed decision and the arena.
- Ran (chains and wallet only, at most 5,000 paths, one process at a time): a reproduction of `decision.json`; an independent DP and float MC for the assessment and the funded cycle; `wallet_mc` against the chains; sweeps of every uncertain input on the gate, the cash per fee and the funded risk, with common random numbers; a re-implementation of the strategy's bracket on the hourly EURUSD file to measure stops, cost-share Jensen gap, swap nights, pace, the 14-day clock in trades and the strict daily-loss frequency; a re-implementation of the clip rule on the tick lattice to test the live-cost stall.
- Adversarial order: I started from what would move the purchase gate, because it is the only decision with a margin of 0.013 on a Monte Carlo SE of 0.006, then asked which inputs the code treats as exact that are not (cost at the mean stop, lot flooring, constant clock, refusal semantics, funded risk chosen by a side criterion, horizon).

## What I chose not to examine, and why

- The notebook, `make_numbers.py` and any broker replay: forbidden by the brief and too heavy for the host. I read their outputs (`decision.json`, `front.json`, `broker_map.json`, `news_battery.json`) and re-derived what I could from the chains.
- The broker map's account-level agreement with the chains (section 24) and the news battery's numbers: read the code and the paper's own diagnosis (the declared test failed; the cells that can be resolved agree); not re-run.
- The firm's rules: no web. I took `rules.json` as the source and listed the readings it leaves open (daily rule, 35% rule in the assessment, clock origin) as inputs in the robustness table.
- Sections on Maven, hedging, instrument ranking, GARCH, the continuous-limit calculus and the proofs: outside the question the brief asked, apart from `hedge.shared_wallet` and `spread.family`, which feed the front. Derivations were not re-proved; the chains that implement them were tested numerically.
- The correlation measurement (`pair_corr`) and the walk-forward on the stop: read, not re-run; only its use in the front was assessed.
- Engine-level behaviour of the strategy with a spread-charging broker: no such broker exists in the repo and building one is a replay. The clip-stall finding is therefore from reading the clip and simulating the same rule, not from the engine.

## Alternatives I considered for how to audit

1. Re-run the notebook and the paper build, then diff. Rejected: forbidden, memory, and it would only prove reproducibility, not correctness.
2. Re-implement the whole model independently end to end. Done in part (dict DP for both chains, float MC, a bar-level walker), not for the wallet and front, where I copied `wallet_mc` with switches (refusal, strict-daily kill, random clock) and checked that the switched-off copy reproduces the original to the last digit.
3. Read the code only. Rejected: the three most important findings (the gate's noise and bias stack, the clip stall, the 14-trade clock behind the answer table) needed a number to be findings. Reading found the live-runner and the clock mismatches; execution sized them.
4. One-at-a-time perturbation with common random numbers, with the flip value found by interpolation. Chosen for the robustness table, because the gate's margin is smaller than the Monte Carlo SE of an independent run; independent seeds are used only where I report noise.
5. Sub-agents or a fresh-context second opinion: not used. The host is short of memory, the brief caps concurrency, and the verdicts here rest on execution, not on same-context argument. Where a statement is inference from one measured number to another (the terminal-valuation size, the funded-risk effect on N = 2, the clip as cause of the pace gap) it is labelled [inf].

## Things I would settle first, in order

1. Wire `run_live.py` to the plan (3% then 1.575%, `set_account`, clip including spread and swap), then test one demo assessment trade for the landing (F1, F2).
2. Measure the daily rule's reading on the demo account at the rollover (F6) and the live spread at 07:00-10:00 UTC (the soak feed already has quotes).
3. Re-state the gate with the corrections of F3 and at least 40,000 paths, or replace it with the breakeven honour and a ruin cap.
4. Re-run the broker map's funded cells on a 7-trade clock, or relabel the 46 and 123 days (F8).