TY2026 Retirement and Estate Numbers, With Receipts

Most of the writing on this site is about formulas: specs as contracts, an independent reimplementation diffed against the engine, sentinels instead of silent clamps. This post is about the other half of getting a financial computation right — the constants. A retirement projection can implement its spec perfectly and still be wrong, because the 401(k) limit it multiplied by belongs to a tax year that ended sixteen months ago.

Below are the TY2026 numbers our models actually run on, grouped the way our facts registry groups them, each with its primary source and the date a human last checked the value against that source. Then the part that matters more than any individual number: the machinery that keeps this list honest after publication day.

Constants don't break, they expire

Wrong formulas fail tests. Wrong constants pass them — the arithmetic is internally consistent, the numbers are plausible, and nothing in the type system knows that $69,000 was the §415(c) limit for 2024, not 2026. Tax constants are the only inputs to our engine that go stale on a legislative schedule while the code around them stays green.

We know because we shipped exactly that. The audit that started our accuracy program in August 2026 found three constants hardcoded inline with nothing marking their vintage: a TY2024 federal bracket table in the RSU calculator, the TY2024 §415(c) limit ($69,000) in the mega-backdoor Roth model, and the TY2024 estate exclusion ($13,610,000) as a UI default — all running as if current, in mid-2026. None of them was a typo. Each was correct the day it was written and nobody was assigned to notice when it stopped being correct.

Each constant was correct the day it was written. Nobody was assigned to notice when it stopped being correct.

The fix was a versioned registry: one module, src/lib/facts.ts, that every government-defined constant lives in. Each entry carries the value, the period it applies to, a primary source with URL, the date a human last checked value-against-source, and a status that is computed honestly (more on that below). The engine imports its constants from the registry — IRS_415C_LIMIT, FEDERAL_ORDINARY_BRACKETS, FEDERAL_ESTATE_BASIC_EXCLUSION — and a test guards the wiring. The three 2024 values are still in the registry, marked historical, because half the point of a registry is being able to say what a number was and when it changed.

One scope note before the tables: the registry covers what our models consume, not everything the IRS publishes. If a constant isn't below, no Worthune model's output depends on it. That is a smaller promise than “we track the whole tax code,” and a keepable one.

The TY2026 numbers

Every row is copied from the registry. “Checked” is the registry's verifiedOn date — the day a human last compared the value to the cited primary source, not a claim about anything after that day. Full source URLs are in the sources list at the end, and the live versions of these rows are at worthune.com/facts.

Retirement plan limits

The §401(a)(17) compensation limit is the newest of these entries. It went into the registry on 2026-08-14 after an adversarial review of the employer-match model caught the calculation ignoring it — a qualified plan may not base contributions or match on compensation above that limit. The registry entry's note records why it exists, which is the other thing a registry is for.

Federal ordinary-income brackets, top lines

The engine's bracket helper reads the full TY2026 table from the registry's FEDERAL_ORDINARY_BRACKETS export. In the per-entry registry the table is pinned by two vintage markers — the top of the 10% bracket for each filing status — and a drift test pins the rest. Both markers were checked against the primary source (Rev. Proc. 2025-32, via the IRS newsroom TY2026 page) on 2026-08-13.

Long-term capital gains thresholds

These came from the Rev. Proc. 2025-32 PDF itself — §.03, Maximum Capital Gains Rate — checked on 2026-08-14. That detail matters: the IRS newsroom summary page omits the capital-gains table entirely, so a pipeline that stops at the press release has nothing to check against.

Net investment income tax

NIIT is a different maintenance case: statutory, permanent, and deliberately not inflation-indexed. The thresholds have been the same dollar amounts since 2013, which means more people cross them every year — a constant that changes meaning without changing value.

Estate and gift

The $15,000,000 exclusion applies to estates of decedents dying in 2026, set by OBBBA and confirmed on the IRS newsroom page. The annual gift exclusion held at $19,000 — an inflation-indexed number that didn't move is still a fact worth a dated check, because “unchanged” is exactly the kind of claim people repeat without looking.

RMD Uniform Lifetime Table

The RMD model reads the full Uniform Lifetime Table — applicable denominators for ages 73 through the published “120 and over” factor — from the registry's UNIFORM_LIFETIME_TABLE export. This is the 2022 update currently in force. Two entries pin its provenance:

The full table was read against the Pub 590-B (2025) PDF on the same date — every factor from 73 to 119 plus the terminal 2.0 — and cross-checked against the reference file our concordance harness uses (spot values there: 75 → 24.6, 80 → 20.2, 85 → 16.0, 90 → 12.2, 100 → 6.4). Concordance testing is its own story; here it just means the table exists in two independently sourced places that must agree.

Social Security claiming factors

Since spec v1.1.0 the Social Security timing model derives claiming factors from the general SSA formulas — 5/9 of 1% per month for the first 36 months early, 5/12 of 1% per month beyond that, 8% per year in delayed credits — exact for any integer FRA from 65 to 67. These two registry entries pin the FRA-67 endpoints the formulas must reproduce: 0.70 at 62 and 1.24 at 70. A formula plus two pinned endpoints beats a lookup table plus hope.

§6654 estimated-tax safe harbors

The newest registry-backed group, added for the quarterly-estimates model and checked on 2026-08-15. All five are fixed by statute and not inflation-indexed.

The registry also carries constants outside this post's retirement-and-estate scope — the TY2026 standard deduction, the CY2026 HSA and HDHP figures, the FY2026 SBA 7(a) fee schedule. One of those earned a correction worth admitting: our original HSA entries cited Rev. Proc. 2025-32 / Notice 2025-67 as the source, but HSA figures are actually set by the spring §223 revenue procedure — Rev. Proc. 2025-19 for CY2026. The values were right; the receipt was wrong. We fixed the citation on 2026-08-14 and re-checked the values against the Rev. Proc. 2025-19 PDF itself. A registry that tracks sources catches source errors too.

How the registry stays honest

A table of numbers with citations is easy to publish once. The failure mode is the second year: the post stays up, the numbers drift, and the citations become decoration. Three mechanisms in the registry are aimed at exactly that.

1. A status enum with a word for every bad state

export type FactStatus =
  /** Confirmed against the cited primary source. */
  | "verified"
  /** Asserted elsewhere in this repo (see source) but not yet re-confirmed
   *  against the primary source by a human. Confirm before API exposure. */
  | "repo-asserted"
  /** Production code uses this value as if current; it belongs to a past
   *  period. Each carries a note describing the required fix. */
  | "stale-in-use"
  /** Superseded value kept for the historical record; no longer used by
   *  production code. */
  | "historical";

The uncomfortable one is stale-in-use: production code currently uses this number as if current, and it is not. During the August audit, that status was occupied — the 2024 values above wore it while the fixes landed. Today it is empty, and a staleFactsInUse() helper exists so a test can keep it that way. An honest registry needs a name for the state you hope never to be in, or the state just goes unreported.

2. Freshness claims that expire on their own

A check date is a fact about the past. The verified status would quietly become a lie if a 2026 check were still presented as current in 2028 — so the registry serves a computed status, not the stored one:

export const REVIEW_INTERVAL_DAYS = 400;

export function effectiveStatus(fact: Fact, now: Date = new Date()): FactStatus {
  if (fact.status !== "verified") return fact.status;
  const checkedMs = Date.parse(`${fact.verifiedOn}T00:00:00Z`);
  if (Number.isNaN(checkedMs)) return "repo-asserted";
  const ageDays = (now.getTime() - checkedMs) / 86_400_000;
  return ageDays > REVIEW_INTERVAL_DAYS ? "repo-asserted" : "verified";
}

400 days is a year plus slack for the IRS's fall publication cycle: a value checked last August demotes itself the following September if nobody has looked since. The demoted status renders as “Pending re-check” on the public page and serves as repo-asserted from the API. No cron job, no dashboard nobody watches — the /facts page computes it at build time and the facts API computes it per request, off the wall clock. The registry cannot claim freshness nobody performed.

3. Every response cites the constants it consumed

Each model in the catalog declares which registry entries it reads, and coverage is total and explicit — every model appears, and an empty list is a statement (“this model's outputs are fully determined by its inputs”), not an omission. A test pins the declaration set to the catalog, so a new model can't ship without declaring what it consumes.

export const MODEL_FACTS: Record<string, string[]> = {
  rmd: ["irs.uniform-lifetime.divisor-at-73", "irs.uniform-lifetime.divisor-at-120plus"],
  "backdoor-roth": ["irs.ira.contribution-limit.2026"],
  "employer-match": ["irs.401k.elective-deferral.2026", "irs.401a17.comp-limit.2026"],
  "capital-gains": [
    "irs.brackets.single.top-of-10pct.2026",
    "irs.brackets.mfj.top-of-10pct.2026",
    "irs.ltcg.zero-rate-top.single.2026",
    "irs.ltcg.zero-rate-top.mfj.2026",
    "irs.niit.rate",
    "irs.niit.threshold.single",
    "irs.niit.threshold.mfj",
  ],
  // ... every catalog model appears; [] means "no statutory constants"
};

At run time those declarations surface in the response envelope: every API result carries a facts array with the id, label, value, period, and source name of each constant the model consumed. When the capital-gains model tells you the 15% band ends at $545,500, the same response tells you that number is irs.ltcg.zero-rate-top.single.2026's sibling from Rev. Proc. 2025-32, checked on a date you can read. An agent building on the API can cite its constants because we cite ours first.

And the whole registry is public, free, and ungated at GET /api/v1/facts — id, label, value, unit, period, source with URL, check date, and the computed status for every entry, historical ones included. It is the same module the engine imports. We publish what we run.

When Washington moves a number

This post is the first in a recurring series with an unusual editorial calendar: it updates when the registry does. A new revenue procedure lands, the registry entry changes with a fresh source and check date, the old value moves to historical, and this page gets a dated edit. If you find a number above that disagrees with the live registry at worthune.com/facts, the registry wins — and we'd like to hear about it, because that means the narration drifted from the source of truth, which is exactly the failure this whole system exists to catch.