# Rationale: what was considered and rejected

Every number below is computed from `prime.py` at the deployed stop's mean of 34.8 pips
(cost share γ = 2.87% of the risk with the 0.5-pip spread, 1.44% commission only, 6.70% with
1.33 step-asides at that spread), $3,000 tier, floor on the tick, target clipped, RR 1, or is
quoted from the grounding file named beside it.

## 1. Objective: wallet log growth, rejected as the ranking objective

Section 7 of the paper says the right objective is the wallet's expected log growth under a ruin
cap, and on that objective the paper's own cell wins: notebook section 23 gives +0.577 at 4%/4%
against +0.311 at 4%/1.5%. I did not use it to rank cells, for two reasons. First, the operator's
stated objectives (frequent payouts, shallow drawdown, a record that does not read as gambling)
are not in it: growth rewards a funded account that dies in 16 trades with a 30% chance of ever
paying. Second, growth is a level that depends on P(paid), which nothing in the data measures,
so a ranking on it is a ranking on an assumption. Growth is kept where current_decision.md puts
it: as a gate (positive at 80% of payouts honoured, at the measured cost) on whether to buy at
all, not as the thing to maximise.

## 2. Ranking on the whole grid (RR x risk, both stages) rather than separating the stages

Rejected because the problem separates. P(cash per purchase) = P(pass) x a is a product of a
term that depends only on the assessment cell and a term that depends only on the funded cell,
and the two cells share no variable once RR is allowed to differ between stages (the funded
account is a new account; the strategy takes the risk and the ratio as constructor arguments).
The only couplings are the wallet (the time to first cash adds the two stages' durations) and the
tier. So the two stages are optimised separately and the wallet is checked afterwards. A joint
search over 8 x 8 x 8 x 8 cells would find the same answer at 64 times the cost.

## 3. Trusting the diffusion limit for the funded stage

Proposition 15 gives P(any payout) as a barrier formula in the up-step u with a kink at
u = 0.35 m₁ = 1.667%. I rejected using it for the value or even for the location of the optimum:
`funded_model` at u = 1.667% gives a P(any) far above the chain (it omits the 14-trade clock
and the lattice), and the exact scan puts the peak below the kink, not on it (method.md, part 5).
The diffusion limit is used only for what it proves: monotonicity on either side of the kink,
which is what turns the search into a one-dimensional line search over a short interval.

## 4. A root find on a first-order condition

Rejected. The assessment has no interior optimum (P is monotone in u, so the answer is a
constraint corner), and the funded objective is not differentiable where its maximum is: the
kink from max(m₁, u/0.35) and the sawtooth from the lattice (an integer number of net wins
must clear the request) make the derivative jump. A root finder on a sawtooth stops at the
first tooth it lands on. The exact function is cheap (0.3 s a point), so a dense line search
over the whole admissible interval is both safer and affordable.

## 5. A finer two-dimensional grid

Rejected as the primary method because it spends most of its evaluations on cells calculus has
already ordered (every u above the 35% cap, every funded u above the kink), and because the lot
grid on the $3,000 tier makes any risk finer than 0.116% (one 0.01-lot step at the mean stop)
untradeable anyway. The half-point grid is kept for the final display and as a cross-check of
the line search, not for the search itself.

## 6. Testing "cell A beats cell B" with broker replays of both cells

Rejected as the primary test. Both rates are deterministic functions of the per-trade win
probability p and the cost share γ through the same chain, so a broker replay of two cells tests
nothing about the ordering that the chain does not already settle; what it tests is the engine
(clipping, lot grid, pace), and at RR 1 on the coin side that is already resolved to ±1.35 points
(broker_map.json, `today.eval.p_pass_se`). The declared paired test in current_decision.md has
block SE about 1.7 points and 52% power against a 3.4-point difference: it cannot see the
0.86-point difference between 3% and 4% it is nominally about. The test I declare instead is on
the inputs (p and γ), with the ordering propagated through the chain, and a dominance check over
the region the inputs can occupy.

## 7. Random direction instead of always short

Considered and left to the operator. Under Proposition 17 the direction is free, and the credited
swap on the short side is worth about 0.7% of the risk a trade (0.25 pip a night on a 34.8-pip
stop, about one night held). But always-short makes zero edge an empirical claim about EURUSD
drift over two-day horizons, and 467 trades bound that drift only to ±2.3 points of win rate
(one SE), which is worth ±4.6 points of cost share, more than the swap is worth. A random side
makes each trade an exact coin by construction (the target and stop are equidistant), and the
fairness test becomes a test of the engine, not of the market. I did not change the plan, which
is the operator's, but the inference section says what the choice costs in verifiability.

## 8. Reading the 35% rule as funded-only

Rejected as the working assumption, per the brief: assume the rule applies in the assessment
unless argued otherwise, and the documents do not settle it (rules.json `unverified`). Under
the other reading the assessment corner moves from the 35% cap to the daily-loss cap
(r ≤ 4.42% at γ 2.87%), the pick becomes 4% (+0.86 points of pass rate, 12 days instead of 20),
and nothing in the funded stage changes. Both readings are priced in method.md, part 5.

## 9. Reading the win in the 35% rule as gross rather than net of commission

The rule caps a day's contribution at 35% of the request or target. Whether the firm books the
day net of commission is unverified. I follow current_decision.md and take the day net, so the
assessment cap is RR·r·(1−γ) ≤ 3.15%, corner 3.24% at γ 2.87%. The gross reading gives 3.15%,
0.09 points of risk lower; on the lot grid the two round to the same 0.27 lots at the mean stop.
For the funded request the code (`payout_threshold`) uses the gross win, which is the
conservative side, and so do I.

## 10. Several accounts, other tiers, other entry windows

Not optimised here. The tier is a corner of the wallet rule (fee ≤ 6% of $1,000 admits only
$3,000 at 3.8%; $10,000 is 9.9%), the account count is one by the operator's own rule (a second
waits for the first honoured payout), and the entry window sets the pace and the spread, which
enter as the measured 2.03 calendar days a trade and the assumed 0.5 pip; the map was built at
that window and no other window has broker numbers. Changing any of them is a new measurement,
not a new optimisation.