# Rationale (candidate 1)

## What I looked at

- **Rules.** `rules.json`, the paper's rules and plan tables, and every place the rules enter code:
  `prime.py` (chains, wallet, `_legs`, `payout_threshold`), `broker_map.py` (`set_account` arguments),
  `prime_academy_strategy.py` (clips, scoring, payout event), `run_live.py` and the deployed
  environment. From `/etc/prime-academy.env` I read only the non-secret keys, with grep.
- **Model code.** `eval_chain`, `funded_chain`, `funded_line_search`, `plateau`, `tooth_edges`,
  `wallet_mc`, `day_split_mc`, `spread.family`, `hedge.shared_wallet` and `hedge.flows`, read line
  by line. The parts that decide numbers were re-run.
- **Notebook.** Sections 23 to 26 of the executed copy `run2.ipynb`, inputs and outputs. I did not
  execute the notebook.
- **Paper.** Sections 1, 14 (the map), 15 (the front), 16 and 17 (checks, open questions),
  `numbers.tex`, `tab_gate`, `tab_front`, `tab_picks`, `tab_ksplit`, and the `make_numbers.py`
  block that builds the decision macros.
- **Data.** The cached broker-map replays (192 cells, read only), the EURUSD hourly bars the
  notebook reads, `decision.json` and `front.json`.
- **Background.** The section 26 formulation and the mdgraph entries for the decision, the gate
  and the front.

## How I audited, and the alternatives I weighed

1. **Reproduce first, then perturb.** I re-ran the deployed row on the exact chains and matched
   `decision.json` and `front.json` to four decimals before trusting any perturbation. A
   sensitivity built on a model that does not reproduce the published number measures my own error.
2. **One input at a time, against common random numbers.** Every wallet variant reuses the same
   seeds, and `wallet_variant.py` reproduces `wallet_mc` to five decimals at zero perturbation. So
   a paired difference has a standard error of about 0.001 while a level has about 0.004. That made
   5,000-path runs enough to price a shift, which the memory limit required.
3. **Flip values, not sensitivities.** For each decision I searched for the value of each input at
   which the decision changes: a zero crossing on a cost grid, an honour grid, a horizon grid, or a
   chain bisection for G. A threshold can be read against a measurement. "Sensitive" cannot.
4. **Measure the pending inputs where the repository's own data allows it.** The paper lists the
   strict daily reading as pending. It can be scored on the hourly bars without a replay, so I
   scored it and put it through the chain and the wallet. The same holds for the variable stop's
   true cost share and the gap fills.

Alternatives I considered and did not use:

- **Re-run the broker on the deployed cell** at a 7-trade clock or a narrower calendar. The brief
  forbids uncached replays, and the cache could answer the clock and pace questions without one.
- **Raise the path count** to settle the gate's sign. The cap is 5,000 paths a run. Paired
  differences on common random numbers answer the question that matters, whether an input moves the
  gate across zero, at far lower cost.
- **Audit the paper sentence by sentence.** It is 57 pages, and most of it supports decisions
  already superseded. I read the sections that carry the deployed decision and checked every claim
  in them that a number depends on.

## What I chose not to examine, and why

- **Sections 1 to 22 of the notebook** (MNQ control, Maven, hedging, instrument ranking, GARCH).
  None of them carries the deployed decision any more, and the mdgraph records their reviews.
- **The news battery and the 1.33 step-aside count.** No cached replay on a narrower calendar
  exists, and producing one is a broker run. I priced the threshold instead: about 0.03 step-asides
  a trade on the log gate and 0.76 on the G gate.
- **Section 24's diagnosis** (protocol bias, block-clustered errors). It is a post-hoc diagnosis of
  a failed declared test, and the paper labels it that way. The deployed gate does not use it.
- **The TradeLocker broker internals and live fills.** The service must not be touched, and the
  questions about live fills (spread, gap slippage) need the soak's data, not code reading.
- **Rules beyond the repository.** I did not browse the web, per the brief. Every rule reading here
  comes from `rules.json` and the paper.

## Limits of these findings

- **Strict daily reading.** The breach rates rest on 8 to 11 events among 695 losing trades.
  The rule's threshold (0.633 of the stop) is the paper's own. With the float counted in the
  day's equity base it would be about 0.70, which lowers the rate a little.
- **Gate thresholds.** They come from one paired cost grid at seed 5, scaled to the pooled level.
  Their brackets span the seed-5 level and the published level, not a formal interval.
- **Gaps.** Whether gaps cost anything depends on how the venue fills a gapped take-profit. That
  is unverified, and the finding is labelled that way.