Why hard-coded IRS constants break every January

Somewhere in your codebase there is a number that was correct when you typed it and is wrong now. Maybe it is the 401(k) elective deferral limit. Maybe it is the standard deduction, an IRMAA threshold, or an RMD divisor. It was accurate the day it shipped. Then the IRS, SSA, or CMS published a new figure, the tax year turned over, and your constant quietly went stale. Nothing failed. No test went red. The number is just wrong now, and it will stay wrong until someone remembers to change it.

That is the quiet failure mode of planning software: the errors that do not crash anything. They surface in a client's projection, a tax estimate, or an audit, long after the commit that caused them.

Where the constants hide

If your software does any planning math, you are carrying dozens of these values, and they change on different cadences:

• Retirement limits (401(k), IRA, SIMPLE, SEP, catch-ups) update annually, often announced late in the prior year.
• Income-tax brackets and the standard deduction move with inflation each year.
• Social Security COLA, the wage base, and bend points change annually.
• Medicare premiums and IRMAA tiers change annually and lag other figures.
• RMD divisor tables change rarely, then all at once when the IRS revises them.
• Estate, gift, and GST exemptions step with inflation and with legislation.
• AFR and Section 7520 rates change every single month.

The monthly ones are the tell. A team can just about keep annual constants in a spreadsheet and update them each January. Nobody keeps a spreadsheet of the AFR current by hand for long.

The three ways teams handle this, and why each leaves a gap

Hard-code the values. Fast to build, cheap to forget. The values are correct until the next publication, and there is no signal when they stop being correct. You are one busy January from shipping a stale number into every projection.

Scrape the source pages. Now you own a brittle pipeline against government HTML that was not designed to be parsed, plus the job of noticing when a page changes shape. You also own the citation problem below.

Ask a language model at runtime. Fine for drafting copy. Not fine for a number you will defend, because the model gives you a value with no source and no guarantee it reflects the current year. "The model said 24,500" is not an answer in a compliance review.

Each approach can produce the right number on a good day. None of them gives you the two things that make a figure defensible: a citation and an effective date.

What "defensible" actually requires

A number your software ships should be able to answer four questions without a human digging:

1. Who issued it? (IRS, SSA, CMS, HHS, Treasury.)
2. Which document? (A specific notice, table, or bulletin.)
3. Which section? (So a reviewer can find it in seconds.)
4. When did it take effect? (So you know it applies to the year in question.)

If a value cannot answer those four, it is a guess wearing a number's clothes. When an auditor or a client asks "where did this come from," the difference between "IRS Notice 2025-67, section 402(g)(1), effective 2026-01-01" and "we think it's right" is the entire conversation.

A concrete example

Ask a cited feed for the 2026 401(k) elective deferral limit and you should not just get a value. You should get the value, the issuer, the exact notice, the section, and the effective date, in one response your code can read:

GET /api/reference/v1/us-federal-2026
{
  "key": "retirement.401k.elective_deferral.under_50",
  "value": 24500,
  "unit": "USD",
  "tax_year": 2026,
  "effective_date": "2026-01-01",
  "source": {
    "issuer": "IRS",
    "document": "Notice 2025-67",
    "section": "402(g)(1)"
  }
}

The point is not the single number. It is that every number arrives with its provenance attached, so the figure your planner shows and the figure your assistant cites are the same figure, and both can show their work.

What it costs you not to have this

• Engineering time spent re-keying constants every year, plus the review to make sure nobody missed one.
• Trust, the first time a client or auditor finds a stale value.
• Point-in-time defensibility. When someone asks what a figure was as of last quarter, "let me check git blame" is not a great look. A feed with history can answer directly.

The alternative: treat figures as a feed, not a constant

Planning figures are not application constants. They are time-varying reference data with a primary source. Treated that way, the fix is small: pull the current, cited figure at request time from an API, or let an agent look it up over MCP, so that when the tax code changes your software is already right and every number carries its receipt.

WealthSchema publishes exactly this: cited, current U.S. planning figures over a JSON API and an MCP server, each value with issuer, document, section, and effective date, federal plus five states today. There is a free tier and no card required, so you can wire it into one code path this afternoon and see whether "defensible by default" is worth the swap.

Bottom line

Hard-coded planning constants do not fail loudly. They rot. A cited feed keeps them current and gives every number a source and an effective date, which is the difference between a value you can defend and one you hope is right.