The whole campaign loop, side by side

Read these before you read the table

• FILL MODEL (attach to every number): the engine books touch fills with zero net slippage and do not check entry-bar SL/TP inside the fill minute. Real fills are worse. These are simulated ceilings, not expected live results — sim is NOT live.
• NOTHING NEW IS SIMULATED. Every number here replays the SAME stored books the eval and funded batteries already publish, through the SAME rule walkers (eval_walk.walk_from; funded_conveyor.conveyor_walk in single-account mode). No engine run, no database write.
• POOLED WINDOW. The chain is walked over the intersection of the two stages' book windows on the MES regular-session spine; the window and any truncation are stamped in `spine` below. The method family is P1 on MES — MGC is regime-dependent and MNQ/MCL are negative, so nothing here extrapolates to another ticker.
• SEEDING. The multi-year books warm their indicators up from full history; borderline signals near a window edge can differ from a 2026-only seeding. The 2026 May-Jul split is NOT a holdout — selection saw it.
• MONTHLY-BILLING CONVENTION. A monthly-billed evaluation SKU is charged NO per-attempt fee. It is billed once per started 30-CALENDAR-DAY block of time spent in evaluation phases, per contiguous evaluation stretch — the trader stops paying when the account goes funded and re-subscribes on the way back. Reset credits granted on rebill are therefore inert here, exactly as they are on the evaluation page, because no reset is ever charged.
• ONE-TIME BILLING CONVENTION. The first purchase of the campaign costs the registry entry price; every later attempt costs the CHEAPER of a reset and a fresh purchase (`eval_walk._retry_price`, the same convention the published evaluation battery prices retries at). OPTIMISTIC on one axis it does not price: promotional entry prices are assumed still available at every rebuy.
• EVALUATION ATTEMPTS CUT OFF BY THE WINDOW ARE NOT COUNTED AS ATTEMPTS. An attempt that begins with fewer than H_eval trading days left in the campaign window cannot be judged by the firm's own clock — the data ran out, not the time — so it is recorded as CENSORED_WINDOW_END and kept out of `evals_consumed` and every rate built on it. It is published as `evals_censored_window_end`, and `evals_started` is the two added back together. Its PURCHASE PRICE REMAINS in `fees_paid`: that money was genuinely spent, and dropping it would flatter the campaign.
• CENSORING. A rolling cohort start that reaches the 365-day truncation with no payout is CENSORED and reported as such — counted in `censored_no_payout` / `censored_fraction`, and excluded only from the days-to-first-payout distribution, which it has no value for. Censored starts are never silently dropped. Starts with less than 365 calendar days of runway are EXCLUDED and counted in `excluded_late_starts`.
• SPLIT-BLOCK ATTRIBUTION — TWO RULES, DELIBERATELY. In every by_year and by_regime block the money fields and event counts are attributed by EVENT DATE, the standing conveyor convention. The attempt trio `evals_started` / `evals_consumed` / `evals_censored_window_end` uses the attempt's START DATE instead: the whole attempt, outcome included, books to the bucket it began in, which keeps `started == consumed + censored` true inside every bucket, not only in the pooled total. `eval_passes` stays an EVENT count and so need not square with `evals_consumed` in a boundary-straddling bucket — it counts passes that LANDED here, the trio counts attempts that BEGAN here.
• OVERLAPPING COHORTS. Rolling starts share trades, so the effective independent sample is far smaller than `n_starts`; `n_eff_independent` is the published honest denominator.
• SENSITIVITY BAND SCOPE. The 3x3 grid is published ONLY as a min/median/max band, per degradation arm, and is walked on the CONTINUOUS view only — spec §5's own compute bound. All five arms are banded (raw, pnl_halved, winners_capped, tick_1, tick_2) and each is banded SEPARATELY: pooling a raw cell with a 2-tick cell would report the gap between two different questions as if it were a sensitivity. No cell of the grid may ever be promoted to a headline — that would be selection after the fact.
• LEDGER EVENT ORDER. Events sharing one calendar day are kept in the order the underlying walkers emitted them, never re-sorted by kind. That is what keeps a payout ahead of the retirement it triggered (the account is retired BECAUSE the payout filled its lifetime cap) and a purchase ahead of the attempt it paid for.
• PAIR_MAP ASSUMPTIONS. Which evaluation feeds which funded account is a modelling decision; every non-default pairing and its reason is listed in `pair_map` on this artifact.
• SINGLE SLOT. The campaign never runs an evaluation and a funded account at the same time, and re-entry after a dead funded account goes back through the evaluation stage — retirement is NOT a free replacement here, unlike the funded battery's own conveyor.
• SPEC VERSION. These chains were rebuilt under the v1.1 amendments of CONVEYOR-CHAIN-SPEC.md (2026-08-27), which came out of an independent adversarial review of the v1 build: the sensitivity grid now runs all five degradation arms instead of the raw arm alone, an evaluation attempt cut short by the end of the window is censored rather than counted as a consumed attempt, and the campaign ledger keeps the walkers' own same-day event order. No money field moved in that rebuild — only attempt counts and the band. The version in the footer below is the artifacts' own stamp, printed verbatim rather than a version this page asserts on their behalf.
• THE DIFFERENCE FROM /funded/. The funded comparison page assumes a dead account is replaced the next day for a replacement fee — free in the sense that no evaluation has to be passed again. This page inserts the real evaluation stage instead: that is the whole difference between the two tables, and it is why a row can be strongly positive there and negative here.
• DERIVED COLUMN. Every figure on this page is read from the chain artifact except the recent-regime net/yr, which divides that regime block's own net by the regime's CALENDAR COVERAGE in the chain window — its start year to the end of the window, tail included. It is deliberately NOT annualised over the span between the regime's first and last event: the last event is always a payout or a blowup, so that span drops the quiet stretch after it and overstates the rate. The pooled net/yr beside it is the artifact's own figure and is never replaced by the derived one. Coverage windows differ from row to row — read the tooltip before comparing two of them.
• REQUESTED ROWS ARE NOT SELECTED RESULTS. 1 of the 81 rows below (over 80 pairs) carry a “requested” pill: Arman named that exact evaluation-method × funded-method pair by hand, after the results existed, and it is published under CONVEYOR-CHAIN-SPEC.md §3a. Such a row is computed the same way as a champion row — same spine, same five arms, same walkers, same stored books, nothing new simulated — but it is NOT a champion, it is not a cell of the 3×3 sensitivity grid (so its band cell is an em-dash, not the champion’s band), and it is excluded from every summary card above so that a hand-picked chain can never become a headline. Its pill tooltip carries who asked, when, and the artifact’s own note; the method cell’s tooltip carries where each method actually ranks in the published battery.
• UNVERIFIED REGISTRY PARAMETERS. 13 of 81 rows inherit at least one registry value the registry itself flags as unverified or stale; those rows carry an “unverified params” pill whose tooltip quotes the flag verbatim.