Building a Retirement Income Sequencing Engine: Design Principles and Test Methodology

The integrated decumulation problem

The temptation when designing a retirement-income engine is to handle each decision in isolation. Pick a Social Security claiming age. Then optimise the withdrawal sequence given that claiming age. Then layer Roth conversions on top. Then check IRMAA tiers.

This sequential approach produces locally-optimal-but-globally-wrong answers. A common pattern: the engine recommends delaying Social Security to 70 (locally optimal for break-even at typical longevity), then recommends pre-RMD Roth conversions in the 65-70 gap (locally optimal for tax-rate arbitrage), then notices the conversions drove the household across an IRMAA tier (locally suboptimal but already committed). The integrated optimum might be claim-at-FRA + smaller-Roth-conversions + lower-IRMAA-tier — a sequence the layered approach can't surface.

The right design treats the six decisions as variables in a single optimisation problem with a multi-decade time horizon. The objective function is typically after-tax-equivalent net worth at end-of-plan (typically age 95 or 100), or some related risk-adjusted variant.

What the test corpus must support

To validate the engine, the test corpus must structurally support all six decisions. Most retirement-data fixtures fail at least one of these structural requirements.

Integration: where the seams matter

Three integration seams in the engine are where most implementation bugs live. Address them explicitly in the design.

First, the IRMAA / Medicare seam. IRMAA tier for year N is computed from the household's MAGI in year N-2 (the 2-year Medicare lookback). The engine must propagate income decisions in year N forward by two years to evaluate the Medicare premium impact. Engines that compute IRMAA in the same year as the income event miss the lookback and produce wrong recommendations.

Second, the Social Security / provisional-income seam. Social Security taxation depends on provisional income, which itself depends on Social Security receipts. This is a circular dependency that requires either iterative solution or closed-form simplification. Engines that pretend the dependency is one-way produce wrong tax projections.

Third, the Roth-conversion / IRMAA / tax-bracket seam. A Roth conversion increases this year's MAGI (affecting IRMAA two years out), this year's taxable income (affecting bracket fill), and next-year's RMD trajectory (affecting income trajectory through to end of plan). The engine must propagate the conversion through all three timelines.

Test methodology

Validate the engine against the WealthSchema Retirement Income Sequencing Pack (210 households spanning pre-retirement through late-retirement). The validation has three parts: (1) compare the engine's recommended Social Security claiming age against the structured `breakeven_age` field for each household and verify the recommendation is within tolerance; (2) compare the recommended Roth conversion amount for each year of the gap window against the structured `bracket_fill_capacity` and verify the engine's recommendation respects IRMAA-tier limits; (3) end-to-end, project the household's net worth at age 95 under both the engine's recommendation and a naive baseline (claim-at-62, no Roth conversions, withdraw-from-taxable-first) and verify the engine's recommendation produces meaningfully higher end-of-plan wealth.

// End-to-end validation pseudocode
const corpus = loadWealthSchemaB03Corpus();
for (const household of corpus) {
  const engineRecommendation =
    engine.recommend(household);
  const naiveBaseline = {
    claimAge: 62,
    rothConversions: [],
    withdrawalOrder: ['taxable', 'tax_deferred', 'roth']
  };
  const engineEndOfPlan =
    project(household, engineRecommendation, age=95);
  const naiveEndOfPlan =
    project(household, naiveBaseline, age=95);
  // Engine should produce >5% improvement
  // for a meaningful share of the corpus
  if (engineEndOfPlan / naiveEndOfPlan < 1.05) {
    flagForReview(household, 'engine vs naive < 5%');
  }
}

What 'good' looks like

A retirement-income engine that performs well on the test corpus typically demonstrates the following patterns: it delays Social Security to 70 for a meaningful share of households (those with longevity above average and sufficient bridge-funds); it recommends Roth conversions in the 65-72 gap years that fill the bracket below the IRMAA tier; it sequences withdrawals to avoid the IRMAA cliff while respecting RMD floors; and it handles surviving-spouse trajectories explicitly rather than glossing over them.

The sign of a poor engine is the opposite: blanket 'claim at FRA' or 'claim at 70' recommendations regardless of household specifics; Roth conversion recommendations that don't respect IRMAA tiers; withdrawal sequencing that defaults to taxable-first regardless of bracket-fill opportunities; and surviving-spouse calculations that assume continued joint filing.

Key takeaways

• Decumulation requires solving six interacting decisions as a single integrated problem — Social Security, pension, withdrawal sequence, Roth conversion, IRMAA, RMD.
• Three integration seams are bug magnets: IRMAA's 2-year lookback, Social Security's provisional-income circularity, and Roth conversion's three-timeline propagation.
• Validate the engine against a corpus structured for all six decisions (the WealthSchema B03 pack is purpose-built for this) — partial fixtures produce partial validation.
• End-to-end validation projects net worth at age 95 under the engine's recommendation vs. a naive baseline; meaningful improvement on a meaningful share of households is the bar.

FAQ