Exact ledger tournament margin over MILP dollars

After-tax-estate margin by which the full-projection winner beats the solver schedule.

Field: marginOverMilpDollars Unit: US dollars Basis: nominal dollars Computed by: Engine Status: Complete chain

Appears in: optimize-page (winner margin over solver schedule); monte-carlo-page (WhySuccessPanel (explainPanels) "beat the solver's own schedule by $X")

Calculation records

• Full projection tournament margin Model record, justified by derivation

  Purpose: Report how far the tournament winner beat the solver schedule it displaced, and zero when it displaced none.

  Statement: projection/optimizePlan.ts#runExactLedgerTournament publishes ExactLedgerTournament.marginOverMilpDollars as the winning candidate's exact after-tax estate delta minus the displaced recommendable MILP schedule's exact after-tax estate delta, and as exactly 0 whenever no MILP comparison was made, which includes the MILP-winner branch and both the incumbent and none fallbacks; a candidate replaces a recommendable MILP only when its delta is more than that schedule's delta plus DEFAULT_TOURNAMENT_SWITCH_MARGIN_DOLLARS, which is 1000 dollars.

  Formula: marginOverMilpDollars = milpRecommended ? winnerEstateDelta - milpDelta : 0; the candidate replaces the MILP only when winnerEstateDelta > milpDelta + 1000

  • winnerEstateDelta: Winning candidate's exact after-tax estate delta over the shared baseline (unit: nominal USD at horizon) (domain: finite)
  • milpDelta: Recommendable post-processed MILP schedule's exact after-tax estate delta, 0 when none is recommendable (unit: nominal USD at horizon) (domain: finite)
  • switchMarginDollars: DEFAULT_TOURNAMENT_SWITCH_MARGIN_DOLLARS (unit: nominal USD) (domain: 1000)

  Timing: one tournament over the plan's simple candidates and its post-processed MILP schedule

  Rounding: none; the dollar figures carry binary floating-point representation and the switch comparison is strict

  Limits:

  • The zero convention is the evidenced branch: with no MILP result supplied the published margin is 0 on both the none and the incumbent outcome, so a candidate-versus-incumbent difference must never be reported there, and a no-traditional plan reports source none with an empty schedule rather than an incumbent request. The worksheet's third case (a candidate that beats a recommendable MILP by more than the 1000-dollar switch margin, and the strictness of that threshold at exactly 1000) is a solver-run limit and was NOT constructed: the worksheet supplies no estate inputs for the MILP schedule, and the entry takes a post-processed solver schedule rather than a dollar figure, so no assertion here can pin that branch or its published difference. Beyond the worksheet's two inputs the test assumes, for the none case, a validated single-person plan with one cash account, zero returns, zero inflation, zero state tax and zero base spending, and for the incumbent case a validated single-person retiree plan with an 800000-dollar traditional account beside a taxable and a cash account, 4 percent returns, a 25 percent heir rate, 45000 dollars of base spending and a planning age of 85, both run with the production federal tax calculator from start year 2026 so Y1 is 2026; on the incumbent plan the tournament's own candidate winner is withheld by the retirement-action readiness veto, which is what routes the run to the incumbent fallback the worksheet describes. Both runs exercise the real ledger; nothing is supplied at a seam.

  Provenance: derived by codex, implemented by claude.

  Independent review: cursor

  Gates (6 of 6 pass): fixture registers a test: pass; pins resolve: pass; families exist: pass; worksheet exists: pass; mutation receipt exists: pass; provenance independent: pass

  Worksheet: exact-ledger-tournament-margin.md Mutation receipt: exact-ledger-tournament-margin.mutation.md

  Evidence tests: optimizePlan.evidence.test.ts

  Implemented in: optimizePlan.ts

  Is the number of: exact-ledger-tournament-margin-over-milp-dollars

Records that feed this number

• Full projection cleaned schedule Model record, justified by derivation

  Purpose: Trim a raw solver conversion schedule to what the full year-by-year projection actually executes.

  Statement: projection/optimizePlan.ts#postProcessExactLedgerSchedule publishes ExactLedgerPostProcessing.cleanedSchedule as the per-year minimum of the raw requested conversion and the ledger's executed conversion, taking that minimum only when execution exceeds the neutral tolerance and zero otherwise, and records each materially changed year as an ExactLedgerScheduleAdjustment whose reason is ledger-capped when the cleaned amount survives, dropped-zero when it does not, and estate-pruned when the trailing prune pass removes the year. Those three are the only members of the reason union.

  Formula: cleaned_y = executed_y > neutralTolerance ? min(requested_y, executed_y) : 0; reason_y = cleaned_y <= neutralTolerance ? dropped-zero : ledger-capped, or estate-pruned when the prune pass drops year y

  • requested_y: Raw solver schedule amount for year y (unit: nominal USD) (domain: nonnegative)
  • executed_y: max(0, the rerun ledger's rothConversion for year y) (unit: nominal USD) (domain: nonnegative)
  • neutralTolerance: DECISION_NEUTRAL_TOLERANCE_DOLLARS (unit: nominal USD) (domain: 1)

  Timing: raw request, full-projection execution, rerun, repeated to a fixed point within the stabilization budget

  Rounding: adjustment rows carry cents-rounded requested, executed and cleaned amounts; the dollar totals carry binary floating-point representation

  Limits:

  • Cleaned is the per-year minimum, not the request: keeping the request republishes 15000 dollars in a year the ledger funded with 5000, and summing the raw requests publishes 30000 dollars rather than the cleaned 20000. The reason on that year is ledger-capped. A fourth member, rounding, was once declared on the reason union and never assigned; decision D-ADJUSTMENT-ROUNDING-REASON removed it on 2026-09-25, and the evidence still asserts it is not among the reasons the run assigns. Of the worksheet's three live reasons only ledger-capped is realized by its stated inputs; dropped-zero and estate-pruned were NOT constructed from them, because each needs a different raw schedule and, for estate-pruned, a plan whose trailing conversion year harms the exact estate; the worksheet states neither, so the test asserts instead that the run's reasons lie inside the three live values and that rounding is not among them. Beyond the worksheet's inputs the test assumes a validated single-person plan with a 10000-dollar cash account and an empty Roth account beside the 20000-dollar traditional one, zero healthcare expenses, a planning age of 67 and the production federal tax calculator from start year 2026, so Y1 is 2026 and Y2 is 2027; the raw schedule is a full OptimizedSchedule literal whose per-year solver rows are zero apart from the conversion, which the entry requires and the worksheet does not name. The MILP-sourced winning schedule the worksheet mentions is a solver-run limit with no number and is not asserted here.

  Provenance: derived by codex, implemented by claude.

  Independent review: cursor

  Gates (6 of 6 pass): fixture registers a test: pass; pins resolve: pass; families exist: pass; worksheet exists: pass; mutation receipt exists: pass; provenance independent: pass

  Worksheet: exact-ledger-cleaned-schedule.md Mutation receipt: exact-ledger-cleaned-schedule.mutation.md

  Evidence tests: optimizePlan.evidence.test.ts

  Implemented in: optimizePlan.ts

  Is the number of: optimizer-recommended-conversion-annual

  Feeds: exact-ledger-tournament-margin-over-milp-dollars

Engine source: engine/src/projection/optimizePlan.ts (ExactLedgerTournament.marginOverMilpDollars)