Tax-rule registry

2026 eligible long-term care premium attained-age caps Out of scope

Interpretation and scope: The 2026 attained-age caps ($500 / $930 / $1,860 / $4,960 / $6,200) are read from the revenue procedure’s table rather than rewritten into quotedText. The quotation carries the introducing sentence; the table rows are not linearized into prose. Companion to irc-213-a-medical-expense-deduction, which folds the missing medical-input filter without publishing these dollars on a staticStatute record.

• Rev. Proc. 2025-32, section 4.27

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( itemizedDeductionsSchema ) ; federalTax.ts ( itemizedTotal )

Verified 2026-08-27, re-verification due 2026-12-25

A HECM borrower (or spouse) must be at least 62 Settled

Interpretation and scope: First housing-law record in the registry, admitted on the same test as its Title 42 and POMS records: an engine gate whose refusal traces to an operative statutory clause. Two deliberate deviations from the clause itself: the screen requires the YOUNGEST member to be 62 where the statute is satisfied by either spouse - conservative, because the principal limit factor is keyed to the youngest age anyway and a candidate the statute would allow is merely not suggested - and age is measured at year granularity, so a member attaining 62 during the start year is treated as eligible for the suggestion a few months early. Neither deviation touches a tax figure; the card is a scenario suggestion.

• 12 U.S.C. 1715z-20(b)(1)

Tested by: hecmBufferCandidate.test.ts (no HECM buffer candidate below age 62) : “refuses at 61 and surfaces at 62 for an otherwise qualifying home” , “holds the conservative youngest-member screen the record discloses” , “pins the year-granularity admission the record disclosed”

Implemented in: hecmBufferCandidate.ts ( hecmBufferCandidate )

Verified 2026-08-29, re-verification due 2027-08-29

A PLESA distribution receives designated-Roth qualified-distribution treatment Out of scope

Interpretation and scope: This rule requires the PLESA source, separately allocated earnings, and a PLESA withdrawal. The plan schema has none of those fields, and the action contract has no PLESA distribution kind; their absences are the schema and vocabulary gates in model/plan.test.ts and actions/contract.test.ts.

• IRC 402A(e)(7)(B)(i)
• IRC 402A(d)(1)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( rothAccountSchema , traditionalAccountSchema )

Verified 2026-08-26, re-verification due 2026-11-24

A PLESA is an optional designated-Roth subaccount of an employer plan Out of scope

Interpretation and scope: This is a schema refusal, not a zero-dollar result: traditionalAccountSchema and rothAccountSchema have no PLESA subaccount, separate earnings, or plan-feature fields, and the retirement-action unions have no PLESA arm. The absent account vocabulary is pinned in model/plan.test.ts and the absent action vocabulary in actions/contract.test.ts. The enacting provision is SECURE 2.0 section 127(e)(1), not section 115.

• IRC 402A(e)(1)(A)(i)
• P.L. 117-328, division T, title I, section 127(e)(1)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( rothAccountSchema , traditionalAccountSchema )

Verified 2026-08-26, re-verification due 2026-11-24

A PLESA withdrawal is excepted from the section 72(t) additional tax Out of scope

Interpretation and scope: The necessary distribution source and its section 402A(e) status cannot be represented. The absent PLESA account surface is tested in model/plan.test.ts; the absent withdrawal-action surface is tested in actions/contract.test.ts. This avoids treating an ordinary employer-plan withdrawal as proof of the PLESA exception.

• IRC 72(t)(2)(J)
• IRS Notice 2024-22, section II (Background)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( rothAccountSchema , traditionalAccountSchema )

Verified 2026-09-07, re-verification due 2026-12-06

A QCD does not create an under-59.5 penalty exception Out of scope

• IRC 72(t)(1)
• IRC 72(t)(2)
• IRC 72(t)(2)(A)(i)
• IRC 408(d)(8)(B)(ii)

Refusal tested by: accountEligibility.test.ts : “refuses a QCD below age 70½ instead of pricing an early distribution” , “accepts the same request once the donor is past 70½, which is also past 59½”

Implemented in: annualQcdActionExecutionEvidence.ts ( publishAnnualQcdActionExecutionEvidence ) ; annualQcdExecutionPrerequisite.ts ( evaluateAnnualQcdExecutionPrerequisites ) ; accountEligibility.ts ( evaluateQcd )

Verified 2026-08-25, re-verification due 2027-08-25

A QCD is drawn from pre-tax dollars first Settled

• IRC 408(d)(8)(D)
• IRS Publication 590-B (2025), Are Distributions Taxable?
• Instructions for Form 8606 (2025), Line 7

Tested by: annualQcdTaxCharacterPostPass.test.ts : “caps the QCD at aggregate pre-tax dollars and leaves the rest to basis”

Implemented in: annualQcdTaxCharacterPostPass.ts ( stageAnnualQcdTaxCharacterPostPass ) ; ownedNonRothIraRuntimeSourceSeries.ts ( validateOwnedNonRothIraRuntimeSourceSeries )

Verified 2026-08-02, re-verification due 2027-08-02

A QCD recipient must be a qualified direct charity recipient Settled

• IRC 408(d)(8)(B)(i)
• IRC 170(b)(1)(A)

Tested by: annualQcdActionExecutionEvidence.test.ts (DAF / supporting organization) : “executes an attested public charity and refuses without the no-DAF attestation” , “refuses an explicitly designated donor-advised fund even with affirmative attestations” , “refuses an explicitly designated supporting organization even with affirmative attestations”

Tested by: annualQcdActionExecutionEvidence.test.ts (direct-from-custodian attestation) : “refuses a QCD without the direct-from-custodian attestation”

Tested by: annualQcdActionExecutionEvidence.test.ts (eligible-organization attestation) : “refuses a QCD without the eligible-organization attestation”

Implemented in: annualQcdExecutionPrerequisite.ts ( evaluateAnnualQcdExecutionPrerequisites ) ; accountEligibility.ts ( evaluateQcd )

Verified 2026-08-25, re-verification due 2027-08-25

A QLAC may defer, but not past the first of the month after the owner’s 85th birthday Settled

Interpretation and scope: THE BOUND IS A BIRTH MONTH, NOT THE CONSTANT 85, and the record leads with that because it is the only part a reader would otherwise assume was a bug. The regulation’s deadline is a DATE and this model’s start ages are calendar years, so the two have to be bridged, and the bridge is the same one the required-beginning-date record is built on: simulatePlan pays a contract twelve monthly amounts in the calendar year the owner attains startAge (startCalendarYear = dobYear + startAge, the guaranteed-income pass), so the engine’s model of commencement is January 1 of that year. Ask of each candidate start age whether that January 1 falls on or before the first day of the month next following the 85th anniversary. A start age of 85 or lower commences no later than January 1 of the year the owner attains 85, and the deadline is at the earliest February 1 of that same year (a January birthday), so every such contract clears it. A start age of 87 or higher is late for everyone. A start age of 86 is the whole question: it commences on January 1 of the year the owner attains 86, which for a birthday in any month but December is a full year after a deadline that fell in the previous calendar year — but for a DECEMBER birthday the 85th anniversary is in December and the first day of the next month IS that January 1, so the contract commences on the last day the regulation permits, exactly. The ceiling is therefore 85, and 86 for a December birth. WHY THE DECEMBER CASE IS NOT TIDIED AWAY. It is the same arithmetic that gives the neighbouring bound its + 1, which exists because THAT deadline — April 1 of the year following attainment of the applicable age — also falls in the calendar year after the one the age names. Refusing 86 for a December-born owner would be a refusal stricter than the authority for it, and it would force that household to model a contract commencing a full year before the one they actually hold; a refusal stricter than its authority is not this rule, which is the discipline the neighbouring record’s second term was written to state. THE TEST IS DERIVED, NOT DECLARED. A Plan already carries the contract’s startAge and the owner’s date of birth, so no new field is added. OWNER RESOLUTION AT PARSE, LOAD AND PROJECTION VERSUS THE GENERATOR. Historical parse, load and projection seams resolve the IRA owner as the named person when that id resolves in the household, or the first household member when the account carries no ownerPersonId — but planCrossFieldChecks rejects null or dangling ids on individually owned accounts (traditional included), so a stored parsed plan does not legally carry those shapes. The projection additionally suppresses dangling annuity contract owners rather than inventing a substitute. THE GENERATOR IS A RAW CALLER ON THE IN-MEMORY PLAN: it gates and sizes the QLAC candidate only when the selected traditional account’s ownerPersonId resolves to a household member, uses that person’s age and identity for the younger-than-83 product gate and min(85, max(age + 1, 80)) preferred start (a product-policy window of 80–83, not the statutory 85/December-86 ceiling enforced at parse above), and suppresses the candidate entirely when the id is null or dangling rather than substituting the primary or first person. Treas. Reg. 1.408-8(a)(3) substitutes the IRA owner for the employee when applying the § 401(a)(9) rules underlying (q)(1)(ii); that substitution governs whose birth month anchors the legal deadline — it does not supply the generator’s <83 product gate. THE MESSAGE NAMES THE OTHER BOX ONLY WHEN THE OTHER BOX WOULD WORK. Each of the two refusals has two conceivable remedies — move the start age, or change which bound applies by ticking or unticking QLAC — and the second is a dead end whenever the other bound refuses the same age too. A QLAC refused at a start age of 90 cannot be rescued by unticking the box, because the required-beginning-date bound is lower still in every case but an annuitization bought at that very age; a non-QLAC refused at 90 cannot be rescued by ticking it, because 90 is past this ceiling as well. Both messages are therefore derived from which of the two shapes the plan could actually store, and the earlier message’s unconditional "or tick QLAC" was corrected to match when this bound landed. THE SAME DERIVATION GOVERNS EVERY SURFACE THAT NAMES THE BOX, added on review because two of them had been left asserting what the parse had stopped asserting. The accounts editor’s field help and the load-repair notice each carried an unconditional claim that the QLAC box is the way to start later, and neither is reliably true: the required-beginning-date ceiling is the LATER of the applicable RMD age plus one and the owner’s age in the purchase year, so it climbs with a late annuitization and overtakes the QLAC’s fixed 85 or 86 — an owner buying at 96 is held to 95 without the box and would be dropped to 85 by ticking it. Both now compare the two ceilings for the owner in front of them, offer the box only where it admits a later start, and otherwise say which age the other shape would impose. The editor reads both ceilings from one helper, and the load repair carries both numbers on the repair record, so no surface re-derives the comparison for itself. WHAT "ONE SEAM" DOES AND DOES NOT MEAN, tightened on a second review that found the migration and the editor disagreeing about a limit that is not in this record at all. A Plan will not store an annuity start age past ANNUITY_MAX_START_AGE, which is the model’s own projection range and not a tax rule — nothing here says a contract commencing at 96 is unlawful. That constant is now exported once and read by the schema that enforces it, the editor, and the load repair, because all three had been carrying their own copy. It is applied to the ceiling a message OFFERS, since a suggestion has to name a start age the household can actually store, and deliberately NOT to the ceiling that decides whether the stand-down fires: the repair exists because a shape has no legal expression, and a start age this program merely declines to project is not that shape. Capping the trigger would destroy a lawful purchase for a range limit, and would not even buy the parse, because the stand-down preserves the start age on purpose. Such a document is refused whole, with the schema naming the field that is out of range. THE REPAIR, AND WHY IT IS A STAND-DOWN. A stored document carrying the shape has its purchase cleared and its monthly amount zeroed, so the premium never leaves the funding balance and the contract pays nothing. The same three repairs were available as for the neighbouring bound and the same two are refused by the never-richer bar the load seam is under. Unticking the QLAC box is the mirror of the relabel that record refuses, and is richer for a second reason of its own: it lifts the statutory premium cap the household’s own election put the contract under, and it lands the contract on the required-beginning-date bound, which is lower than the ceiling it just failed. Advancing the start age would pay a monthly amount quoted for a deferred start across years nobody bought it for, and the argument is stronger here than next door because a QLAC’s entire pricing IS its deferral. The stand-down is the strictly poorer direction and it leaves the account in the plan carrying its name and start age, so the household can see what happened and re-author it. WHAT THIS RECORD DOES NOT COVER. How large the premium may be is a different rule, registered at treas-reg-1-401-a-9-6-q-2-qlac-premium-dollar-limit for its value and at treas-reg-1-401-a-9-6-q-2-ii-qlac-premium-cap-across-every-contract for the running total the engine does not keep. Where the contract’s value sits once paid is treas-reg-1-401-a-9-5-b-4-qlac-excluded-from-the-rmd-account-balance, whose statement has always said a QLAC may defer "as late as the month after the owner’s eighty-fifth birthday" — until 2026-08-07 that sentence described a limit nothing in the engine enforced, and it now describes one that is enforced at parse, at load and in the projection. Paragraphs (q)(1)(i), (iv) and (v) impose further conditions on a QLAC (the premium limitation, the absence of a commutation benefit or cash surrender right after the required beginning date, and the contract’s own statement that it is intended to be a QLAC) and are not modelled; a Plan has no field for the last two, and a household that ticks the QLAC box is taken at its word that the contract it bought is one.

• Treas. Reg. 1.401(a)(9)-6(q)(1)(ii)
• Treas. Reg. 1.401(a)(9)-6(q)(1)(iii)
• Treas. Reg. 1.401(a)(9)-5(b)(4)
• Treas. Reg. 1.408-8(a)(2)
• Treas. Reg. 1.408-8(a)(3)

Tested by: iraAnnuityCharacter.approximation.test.ts (a QLAC deferred past 85) : “refuses a QLAC that commences after the owner’s 85th birthday” , “admits the same contract one year earlier” , “gives a December-born owner the extra year the deadline actually gives them” , “does not send the household to a refusal the other box would give them” , “warns rather than staying silent for a caller that skips the parse”

Implemented in: generators.ts ( annuityPurchaseGenerator ) ; migrations.ts ( migratePlanToCurrent ) ; plan.ts ( latestQlacAnnuityStartAge ) ; planCrossFieldChecks.ts ( checkAccountCrossFieldRules ) ; annualAnnuityPurchaseFunding.ts ( annualAnnuityPurchaseFunding ) ; simulate.ts ( simulatePlan )

Verified 2026-09-07, re-verification due 2027-09-07

A QLAC’s value is excluded from the required-distribution account balance Settled

Interpretation and scope: THE MECHANISM IS NOT THE RULE, and the record says so because the coincidence is load-bearing in one direction and misleading in the other. The regulation excludes the VALUE OF THE CONTRACT from a balance that still notionally contains it; the engine never puts it there, having no contract value at all. On a QLAC the two agree for every year and every return assumption, since the base is the remaining account either way, so nothing here is approximated. On a contract that is NOT a QLAC the same single mechanism produced an exclusion the regulation does not allow, and that is registered separately at treas-reg-1-401-a-9-6-a-3-i-annuity-payments-commence-by-the-required-beginning-date. UNTIL 2026-08-07 THE TWO RECORDS PINNED THE SAME PAIR OF FIGURES with the accepted and produced labels exchanged, and this record said that the day the engine learned to tell the contracts apart, one fixture would flip and the other must not. That day was 2026-08-07: the neighbouring record is now settled, because plan validation refuses a qualified non-QLAC contract that defers past the owner’s required beginning date, and the shape its produced fixture measured is unreachable through any valid plan. What flipped there was that fixture, from an arithmetic gap to the refusal itself. NOTHING HERE MOVED, which is the discipline working rather than a coincidence: this record’s accepted reading and its 33,091.96 are the same figures on the same household, and they have to be, because the mechanism the engine uses to reach them was never the thing that changed. THE AGGREGATION ELECTION IS A SEPARATE RULE and is not what this record covers. Treas. Reg. 1.408-8(e)(1)(ii) and 1.401(a)(9)-5(a)(5)(iv) let an owner ELECT to put the contract’s value back into the base and reduce the requirement by the annuity payments; Publication 590-B walks the same election through an example. It is an election, so declining it is the default and the engine’s silence is a permitted position rather than an omission — but it is a position, and a Plan has no field with which to take the other one. The QLAC premium cap is a third rule again, registered at treas-reg-1-401-a-9-6-q-2-qlac-premium-dollar-limit for its value and at treas-reg-1-401-a-9-6-q-2-ii-qlac-premium-cap-across-every-contract for the running total the engine does not keep; this record says nothing about how large the premium may be, only about where its value sits once paid. THE "AS LATE AS THE MONTH AFTER THE EIGHTY-FIFTH BIRTHDAY" IN THE STATEMENT ABOVE IS NOW AN ENFORCED LIMIT, added 2026-08-07. That clause has been in this record since it was written, and it described the deferral (q)(1)(ii) permits — but until that date nothing in the engine held a contract to it, and a plan could carry a QLAC starting at 95 and receive this exclusion for every one of those years. Plan validation now refuses a QLAC whose payments commence past that date, a stored document carrying one is repaired at load, and the projection warns for any caller that reaches the purchase pass without parsing first. That rule is registered separately at treas-reg-1-401-a-9-6-q-1-ii-qlac-commences-by-the-85th-birthday. NOTHING HERE MOVED AGAIN: this record’s accepted reading and its 33,091.96 are still the same figures on the same household, because a start age of 85 was always within the ceiling and the mechanism that reaches the base was never what changed.

• Treas. Reg. 1.401(a)(9)-5(b)(4)
• Treas. Reg. 1.408-8(h)(1)
• Treas. Reg. 1.401(a)(9)-6(q)(1)(ii)
• IRS Publication 590-B, annuity contract purchased with a portion of the account balance

Tested by: iraAnnuityCharacter.approximation.test.ts (the QLAC carve-out) : “computes the requirement on what the account kept” , “reaches the regulation’s base by a mechanism that is not the regulation”

Implemented in: annualAnnuityPurchaseFunding.ts ( annualAnnuityPurchaseFunding ) ; simulate.ts ( simulatePlan ) ; rmd.ts ( requiredMinimumDistribution )

Verified 2026-08-07, re-verification due 2027-08-07

A SEPP series belongs to one participant and one source account Settled

Interpretation and scope: The statute and Notice establish participant identity and calculation with respect to an account balance. They do not define the engine’s household or account-inventory proof. Binding one persisted sourceAccountId to one election and rejecting foreign inventory are reconciliation conventions that prevent amounts from another person or modeled account from being counted toward the series.

• IRC 72(t)(5)
• IRS Notice 2022-6, section 3.02(f)
• IRS Notice 2022-6, section 3.02(e)

Tested by: ownedNonRothIraSeppAnnualReconciliation.test.ts : “scores the series for the participant it belongs to, not the household” , “names the inventory member as foreign to this participant”

Implemented in: ownedNonRothIraSeppAnnualReconciliation.ts ( reconcileOwnedNonRothIraSeppAnnualSchedule ) ; ownedNonRothIraSeppCurrentPaymentCandidate.ts ( validateOwnedNonRothIraSeppCurrentPaymentCandidate )

Verified 2026-09-07, re-verification due 2027-09-07

A SIMPLE plan may elect the enhanced elective-deferral dollar amount Out of scope

Interpretation and scope: Separated from irc-401-k-11-simple-401-k-elective-deferral-limit so each record carries one claim: that record is the generally applicable (i)(III) amount; this one is the election limb. model/plan.test.ts gates employer-plan-type membership against a simple401k arm, and actions/contract.test.ts gates the absence of a plan-term election/action.

• IRC 401(k)(11)(B)(i)(I)
• IRC 408(p)(2)(E)(i)(II)
• IRC 408(p)(2)(E)(ii)
• Notice 2025-67, SIMPLE retirement account and SIMPLE 401(k) limitation
• Notice 2025-67, enhanced SIMPLE limitation under section 408(p)(2)(E)(i)(I) or (II)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( traditionalAccountSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-09-07, re-verification due 2027-01-05

A conversion must come out of and go into the same individual’s own accounts Settled

Interpretation and scope: The authority fixes whose dollars may move and whose account may receive them. It selects nothing about how a household-level conversion request is divided between two people who each hold convertible balances, and nothing about which of one person’s several Roth accounts receives their share, so both are engine conventions. The split is pro rata on each owner’s GROSS convertible balance, not on the taxable fraction of it, because what an owner may convert is limited by what they hold and not by how much of it is pre-tax; the weight is snapshotted after the RMD block, which Treas. Reg. 1.408A-4 A-6(b) requires the forced distribution to precede, and before the drain loop reduces any balance, because reading it mid-loop would weight each owner by whatever the earlier owners happened to leave behind. A genuine split is allocated in exact cents by largest remainder so the parts sum to the whole with no floating-point residue deciding whose dollars move; a household with one convertible owner is deliberately NOT routed through cents, because quantizing a target the sizer produced in raw Plan dollars would change an answer the owner boundary has no quarrel with. The receiving account is that owner’s first Roth account in Plan order, which is arbitrary between two accounts of the same kind and is not arbitrary between kinds -- see the vehicle record. An owner whose slice is trimmed for want of a destination is excluded from the shortfall total the year reports, because an owner who cannot convert is not a shortfall against anyone’s balance and saying so would answer the wrong question with the wrong fix.

• IRC 408A(e)(1), through clause (B)(ii)
• IRC 408(d)(3)(A), complete
• IRC 408A(d)(3)(B), complete
• Treas. Reg. 1.408A-4, A-1(a), second requirement

Tested by: conversionOwnerIdentity.test.ts : “does not convert one spouse’s IRA into the other spouse’s Roth” , “says whose share was skipped and what would let it convert” , “does warn when the destination is missing entirely, so the household case is distinct” , “converts the same amount when the owners do match, so the fixture is about identity” , “credits each owner’s own Roth with that owner’s own pro-rata slice” , “never credits one owner’s Roth out of another owner’s dollars”

Implemented in: aggregateRothConversionOwnerAllocation.ts ( allocateAggregateRothConversionByOwner ) ; ownedNonRothIraAnnualPhysicalTransaction.ts ( preparePlanOwnedNonRothIraAnnualPhysicalTransaction ) ; retirementActionCandidateIdentityAllocator.ts ( conversionDestinationIssue , conversionSourceIssue ) ; retirementActionManualReview.ts ( targetIdentitySemanticsIssue ) ; rothConversionCandidateAdapter.ts ( adaptFillTargetRothConversionGeneratorCandidate ) ; ownedNonRothIraRuntimeSourceSeries.ts ( validateOwnedNonRothIraRuntimeSourceSeries ) ; annualAggregateRothConversionPlan.ts ( annualAggregateRothConversionPlan ) ; optimizerAggregateConversionPromotion.ts ( promoteOneYear ) ; simulate.ts ( simulatePlan )

Verified 2026-08-04, re-verification due 2027-08-04

A conversion must land in a Roth IRA, never a designated Roth account Settled

Interpretation and scope: Two choices sit under this record and only one of them is the engine’s. WHICH of an owner’s several Roth IRAs receives the dollars remains a convention -- the first in Plan order, arbitrary between two accounts of the same kind, exactly as the sibling record irc-408-d-3-A-i-conversion-benefits-the-distributee already states. WHETHER an employer designated Roth account may receive them is not a convention at all, because 402A(c)(4)(B) settles it. Where the engine did have to choose is what to do for an owner who holds both kinds with the designated Roth account earlier in Plan order, and it passes over that account rather than refusing the slice. Plan order is insertion order and nothing else in this codebase reads it as a preference, so refusing would let array position decide a five-figure answer: a household holding a Roth 401(k) at index 1 and a Roth IRA at index 3 would convert nothing, while the same household with the two swapped converted in full. Trimming is kept for the owner who genuinely has no lawful destination, and that owner is named. A second reason keeps designated Roth accounts out of the candidate set entirely: a pre-tax employer balance CAN reach a designated Roth account under 402A(c)(4), but only the one maintained under the same plan, and the Plan schema carries no plan-identity link between an employer traditional account and an employer Roth account -- kind ira against kind employer is the whole discriminant -- so the engine cannot establish "such plan" from its data even where the route exists. A Roth IRA is the only destination whose lawfulness this engine can verify. Reading the vehicle also files the conversion layer in the right basis pool: rothPoolKey aggregates an owner’s Roth IRAs under one key and gives each employer Roth account its own, so a layer credited to the wrong account would carry its 408A(d)(3)(F) five-year clock into a pool that later Roth withdrawals never read. What this record does NOT reach is whether the source balance was distributable in the first place; that is registered separately as irc-401-k-2-B-i-employer-plan-conversion-source-not-gated-by-distributability.

• IRC 408A(d)(3)(A), complete
• IRC 408A(d)(3)(B), complete
• IRC 408A(d)(3)(C)
• IRC 408A(b)
• IRC 402A(b)(2)
• IRC 402A(c)(4)(B)
• Treas. Reg. 1.408A-4, A-1(b), complete
• IRC 408A(c)(5)(A)
• IRC 402A(c)(3)(A)
• Notice 2010-84, A-1

Tested by: conversionDestinationVehicle.test.ts : “converts into the Roth IRA and leaves the designated Roth account alone” , “names the Roth IRA on the destination credit, not the earlier Roth account” , “recognises the income and says nothing, because nothing was refused” , “converts nothing, and says the employer account is what stands in the way” , “trims only the designated-Roth owner’s slice, and names them” , “keeps the destination-less copy for a household holding no Roth at all” , “refuses a named employer Roth destination on the action executor without moving money”

Implemented in: aggregateRothConversionOwnerAllocation.ts ( allocateAggregateRothConversionByOwner ) ; ownedNonRothIraAnnualPhysicalTransaction.ts ( preparePlanOwnedNonRothIraAnnualPhysicalTransaction ) ; retirementActionCandidateIdentityAllocator.ts ( conversionDestinationIssue ) ; annualAggregateRothConversionPlan.ts ( annualAggregateRothConversionPlan ) ; simulate.ts ( simulatePlan ) ; accountEligibility.ts ( evaluateRetirementActionEligibility )

Verified 2026-08-05, re-verification due 2027-08-05

A converted Roth layer must consume its taxable portion first Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. `splitRothWithdrawal` computes each partial taxable take as take × taxableAmount / layer.amount, so it leaves 2,400 taxable principal after a 4,000 withdrawal from the 10,000/4,000 layer. Section 408A(d)(4)(B) instead allocates that withdrawal entirely to the taxable portion first. The 240 of additional tax that reading would have imposed is deferred only if the remaining taxable principal is tapped while still unseasoned and pre-59½; otherwise it is permanently omitted. The same pro-rata take lives in `applyConversionPrincipalDebt` and `assumedSeedConsequentialSpill` in this file — a fix must change those copies together. The fixture pins the current 160 produced value until a separately authorized implementation fix changes it.

• IRC 408A(d)(4)(B)(ii)(II), final sentence
• IRC 408A(d)(3)(F)(i)
• IRC 72(t)(1)

Tested by: rothBasis.test.ts (the taxable portion of a conversion layer precedes its nontaxable portion) : “prorates a conversion layer taxable portion across a partial withdrawal, diverging from the statute”

Implemented in: rothBasis.ts ( applyConversionPrincipalDebt , assumedSeedConsequentialSpill , splitRothWithdrawal )

Verified 2026-08-25, re-verification due 2027-08-25

A current-spouse survivor’s later remarriage is outside the Plan Out of scope

Interpretation and scope: Absence-record surface is model/plan.ts: a Social Security stream for a current household spouse has no post-death remarriage age, date, or status. formerSpouseSchema has `remarriedAtAge` only for an already-deceased former spouse, which is why maritalBenefits.ts can model that separate input path but cannot supply the missing future fact for the current-couple survivor pass. No accepted Plan can therefore trigger the current-spouse rule without inventing a remarriage.

• 42 U.S.C. 402(e)(1)(A)
• 42 U.S.C. 402(e)(3)(A)
• 42 U.S.C. 402(e)(3)
• 20 CFR 404.335(e)
• 20 CFR 404.335(e)(1)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( socialSecurityIncomeSchema )

Verified 2026-09-07, re-verification due 2027-09-07

A disability computation changes AIME indexing and computation years Approximated

Interpretation and scope: The companion worksheet conditions the accepted value on an established 2019 period of disability, a 2019 DIB benchmark with insured status met no later than onset, first DIB entitlement after June 1980, and no prior-DIB, child-care-dropout, or higher-alternate-computation adjustment. Those are authority-side preconditions, not facts that `disability.onsetAge` proves. With 1986–2018 earnings equal to each year's published AWI, 2017 is the indexing year. The 32 earnings years through 2017 become 50,321.89 dollars each; 2018 remains its nominal 52,145.80 dollars. Thirty-three elapsed years yield five disability dropout years and 28 computation years, so the accepted AIME is floor((27 × 50,321.89 + 52,145.80) / 336) = 4,198. A partial implementation that uses the 2017 index but retains an ordinary 35-year divisor gives 3,958. The current retirement-only helper instead uses 2026 age-62 eligibility, the 2024 index, and 35 years and produces the already observed 5,487. The old 5,820 figure was a fixed-2024-index diagnostic, not a statutory reading, and is not retained as the accepted fixture. A wrong Social Security amount changes both taxable benefits and replacement funding, so taxpayer tax can move either way.

• 42 U.S.C. 415(b)(2)(A)(ii)
• 42 U.S.C. 415(b)(2)(B)(ii)
• 42 U.S.C. 415(b)(2)(B)(iii)
• 42 U.S.C. 415(b)(3)(A)
• 42 U.S.C. 415(b)(3)(B)
• 20 CFR 404.211(b)(2)
• 20 CFR 404.211(d)(1)
• 20 CFR 404.211(d)(3)
• 20 CFR 404.211(e)(1)
• 20 CFR 404.211(e)(3)
• 20 CFR 404.211(e)(4)
• 20 CFR 404.211(f)
• SSA national average wage index series, 2016–2018

Tested by: socialSecurityEarnings.approximation.test.ts (conditional 2019 DIB benchmark; unit AIME) : “uses retirement indexing and 35 years instead of the conditional disability computation”

Implemented in: piaFromEarnings.ts ( computePiaFromEarnings )

Verified 2026-09-06, re-verification due 2027-09-06

A disabled widow(er) may qualify at 50 only with timely statutory disability Out of scope

Interpretation and scope: This folds the age-50 and seven-year limbs into one record. Section 402(e)(1)(B)(ii) makes the age exception conditional on disability beginning before paragraph (4)'s period ends, and 20 CFR 404.335(c)(1) supplies the seven-year timing test. A separate record would name the same missing DWB claim surface and would not identify an independent implemented calculation. The generic survivor path and the generic worker-SSDI onset field do not make a DWB claim: formerSpouseSchema has no death date or prescribed-period anchor, and the disability object has only an onset age.

• 42 U.S.C. 402(e)(1)(B)(ii)
• 20 CFR 404.335(c), (c)(1)
• SSA POMS DI 10110.001, § A
• SSA POMS DI 10110.001, § D

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( socialSecurityIncomeSchema )

Verified 2026-08-27, re-verification due 2027-08-27

A divorced-spouse benefit can continue after remarriage to another entitled beneficiary Out of scope

Interpretation and scope: Absence-record surface is model/plan.ts: claimantIsSingle is derived from household size, and formerSpouseSchema has no prior-entitlement or new-spouse-beneficiary fact. 404.331(c) still requires a new divorced-spouse claim to start from currently unmarried; this record is only the 404.332(b)(3) / 402(b)(3) continuation exception after entitlement already exists. Treating a currently-married household as a refused new claim is the living-divorced eligibility gate, not this exception.

• 20 CFR 404.332(b)(3)
• 42 U.S.C. 402(b)(3)
• 42 U.S.C. 402(c)(3)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( formerSpouseSchema )

Verified 2026-09-04, re-verification due 2027-09-04

A donor advised fund is not a modeled contribution vehicle Out of scope

• IRC 4966(d)(1)
• IRC 4966(d)(2)(A)
• IRC 170(f)(18)
• IRC 170(f)(18)(B)
• IRC 4966(a)(1)
• IRC 4967(a)(1)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( itemizedDeductionsSchema )

Verified 2026-08-27, re-verification due 2027-08-27

A following-calendar-year contribution is excluded from the current distribution fraction Settled

• Instructions for Form 8606 (2025), Line 4

Tested by: ownedNonRothIraWithdrawalCharacter.test.ts (following-calendar-year contribution window) : “removes the line-4 amount before characterizing a positive distribution”

Implemented in: ownedNonRothIraAnnualFilingEvidence.ts ( buildPlanOwnedNonRothIraAnnualFilingEvidence ) ; ownedNonRothIraAnnualPostCandidateEvidence.ts ( buildPlanOwnedNonRothIraAnnualPostCandidateClassificationInput ) ; ownedNonRothIraWithdrawalCharacter.ts ( classifyOwnedNonRothIraAnnualWithdrawals )

Verified 2026-08-25, re-verification due 2027-08-25

A living divorced spouse is entitled on a disability-entitled worker under 62, and independently only after two years when the worker is not entitled Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. 20 CFR 404.331 splits the worker-entitled path (paragraphs (a) through (e), including a disability-entitled worker under 62) from the independently entitled path (paragraphs (a) through (f), worker at least 62 and not yet entitled, two years divorced). formerSpouseSchema carries relationship, dob, piaMonthly, and marriageYears, and has no worker-entitlement, fully-insured, or divorce-date fact, so isDivorcedSpouseEligible substitutes a calendar-year age-62 blanket. The companion fixture holds the claimant at FRA so the half-PIA amount is 1,500; worksheet-only facts projected out of the schema are an already-disability-entitled ex at 61 and a not-yet-entitled ex at 62 divorced one year. The claimant age-62 condition is supplied by a valid Plan claimAge and by spousalBenefitFactor, not by an explicit 62 predicate here, and the own-PIA restriction is a dual-entitlement offset this menu does not adjudicate.

• 20 CFR 404.331
• 20 CFR 404.331(a)(2)
• 20 CFR 404.331(c)
• 20 CFR 404.331(f)
• 42 U.S.C. 402(b)(1)
• 42 U.S.C. 402(b)(4)(A)
• 42 U.S.C. 402(c)(4)(A)
• 42 U.S.C. 416(d)(1)

Tested by: maritalBenefits.eligibility.test.ts : “pins the calendar-year age-62 blanket against worker entitlement and the two-year independently entitled path”

Implemented in: maritalBenefits.ts ( isDivorcedSpouseEligible )

Verified 2026-09-04, re-verification due 2027-09-04

A long-term 529-to-Roth rollover is not modeled Out of scope

Interpretation and scope: This is a schema boundary, not a Roth-contribution result. accountUnionSchema's closed type set is taxable, equityComp, traditional, roth, hsa, cash, pension, annuity, property, and debt; there is no 529 or qualified-tuition-program member, which model/plan.test.ts already pins. retirementActionRequestSchema carries ordinary-withdrawal, Roth-conversion, QCD, and legacy aggregate arms, none of which carries a 529 source or rollover fact, so a 529-to-Roth rollover cannot be expressed as an action. The 15-year account-age test, the 5-year contribution seasoning, the annual 408A(c)(2) room, and the $35,000 lifetime cap share that one absence surface and are folded here rather than registered separately. The annual Roth IRA ceiling for ordinary Roth contributions remains the settled irc-408A-c-2-roth-shares-the-section-219-ceiling record; this record is only the 529(c)(3)(E) path. effectiveFrom is floored at 2026; the enacting applicability is distributions after December 31, 2023.

• IRC 529(c)(3)(A)
• IRC 529(c)(3)(E)(i)
• IRC 529(c)(3)(E)(ii)(I)
• IRC 529(c)(3)(E)(ii)(II)
• P.L. 117-328, division T, title I, section 126(d)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( accountUnionSchema )

Verified 2026-08-27, re-verification due 2027-08-27

A lower-compensation spouse on a joint return may use combined compensation for an IRA Settled

Interpretation and scope: Section 219(c)(2)(B) is a strict-lesser compensation gate: section 219(c)(1) applies only when one spouse's compensation is less than the other's, so equal or higher earners remain on section 219(b)(1) alone. Each owner still faces the annual dollar limit ($7,500 in 2026 before age 50) regardless of pooling. The lesser earner's combined-compensation room is both spouses' compensation minus the other spouse's traditional, designated nondeductible, and Roth IRA contributions already made (section 219(c)(1)(B)(ii)). When scarce room remains, competing requests apply in Plan account order — a modeling convention under scarcity, not a statutory priority rule. Pooling every living MFJ pair without the strict-lesser gate overfunds equal and higher earners; applying only each spouse's own wages denies the non-earning spouse an IRA the statute allows.

• IRC 219(c)(1)
• IRC 219(c)(2)

Tested by: simulate.contributions-growth.test.ts : “allocates MFJ IRA contributions per owner under section 219(c)”

Implemented in: annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch )

Verified 2026-09-07, re-verification due 2027-09-07

A net capital loss offsets ordinary income only up to 3,000 dollars Settled

Interpretation and scope: The statute sets 1,500 dollars for a married individual filing separately. The projection collapses every filing status to single or married-filing-jointly, so that case is out of scope rather than handled at half the cap. The 3,000 dollar figure has never been indexed since 1978.

• IRC 1211(b)

Tested by: federalTax.test.ts : “deducts only the annual cap and carries the rest forward”

Implemented in: year2026.ts ( year2026 ) ; federalTax.ts ( applyCapitalLossCarryforward )

Verified 2026-08-29, re-verification due 2027-08-29

A non-QCD charitable remainder does not create a line-8 conversion Settled

• IRC 408(d)(8)(B), flush text
• Instructions for Form 1040 (2025), line 4a/4b Exception 3
• Instructions for Form 8606 (2025), Line 7
• Instructions for Form 8606 (2025), Line 8

Tested by: annualQcdResidualForm8606.test.ts (non-QCD remainder enters line 7 and cannot create line 8) : “rejoins the non-QCD remainder only with annual line-7 distributions”

Implemented in: annualQcdResidualForm8606.ts ( stageAnnualQcdResidualForm8606 ) ; annualQcdTaxCharacterPostPass.ts ( stageAnnualQcdTaxCharacterPostPass )

Verified 2026-08-25, re-verification due 2027-08-25

A nonspouse inherited IRA cannot be rolled over or converted Out of scope

• IRC 408(d)(3)(C)(i)
• IRC 408(d)(3)(C)(ii)
• IRC 408A(e)(1), clause (B)(i)

Refusal tested by: accountEligibility.test.ts : “refuses an inherited source instead of computing a conversion” , “accepts the same request from an owned IRA, so the refusal is the inherited fact and not the shape of the fixture”

Implemented in: beneficiaryTraditionalIraResidualRmdAnnualRefinalization.ts ( prepareBeneficiaryTraditionalIraResidualRmdAnnualRefinalization ) ; retirementActionCandidateIdentityAllocator.ts ( conversionSourceIssue ) ; rothConversionExecution.ts ( executeRothConversions ) ; ownedNonRothIraRuntimeSourceSeries.ts ( validateOwnedNonRothIraRuntimeSourceSeries ) ; accountEligibility.ts ( evaluateConversion , isConvertibleToRoth )

Verified 2026-08-25, re-verification due 2027-08-25

A positive TIPS inflation adjustment is annual OID Settled

• Treas. Reg. 1.1275-7(a)
• Treas. Reg. 1.1275-7(b)(1)
• Treas. Reg. 1.1275-7(d)(4)(i)
• Treas. Reg. 1.1275-7(d)(4)(iii)

Tested by: federalTax.test.ts (2027 positive indexation is a phantom OID character) : “records positive inflation accretion as OID in the cash-flow ledger”

Implemented in: ladderMath.ts ( ladderRealFlowsAtOffset ) ; tipsLadderAnnualCashFlow.ts ( tipsLadderAnnualCashFlows ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

A pre-tax employer plan balance may be converted to a Roth IRA only when a 401(k)(2)(B)(i) event is provable Settled

Interpretation and scope: The authority fixes that a Roth-IRA rollover needs a distribution, and that elective deferrals are not distributable before a 401(k)(2)(B)(i) event. It selects nothing about how a year-granularity projection proves those events from the facts a Plan already carries, so those two proofs are engine conventions. Separation is the owner’s attained age at or past retirementAge, the same proxy the Rule of 55 and the 72(t)(3)(B) SEPP path already use; no separation-from-service schema field was added. Age 59½ is the attained-age-60 threshold the 72(t) additional-tax path already uses, because the aggregate conversion has no day-of-year execution date on which a half-year test could be proved. kind employer is the only discriminant a traditional account carries, so 403(b) and governmental 457(b) balances fail closed under the same gate rather than being told apart. Hardship is not treated as convertible: it is distributable but not rollable. 402A(c)(4)(E), added by ATRA section 902 for transfers after 2012-12-31, is a different act -- an optional in-plan transfer of otherwise nondistributable amounts to a designated Roth account in the same plan, which Notice 2013-74 Q-3 keeps under the old distribution lock -- and is not this path. Match and nonelective in-service distributions, and a real in-plan feature flag, are later splits.

• IRC 401(k)(2)(B)(i)
• IRC 408A(e)(1)(B)(ii)
• IRC 402(c)(4), lead-in and (C)

Tested by: employerPlanConversionSource.approximation.test.ts : “does not convert a 401(k) balance the plan may not distribute” , “names the employer plan it refused to draw from” , “refuses the account through the predicate that now carries the gate” , “names the unused locked 401(k) when an IRA only partly fills the request” , “agrees with the statute for a separated participant past 59½”

Implemented in: aggregateRothConversionOwnerAllocation.ts ( allocateAggregateRothConversionByOwner ) ; annualAggregateRothConversionPlan.ts ( annualAggregateRothConversionPlan ) ; optimizerAggregateConversionPromotion.ts ( promoteOneYear ) ; simulate.ts ( simulatePlan ) ; accountEligibility.ts ( isConvertibleToRoth )

Verified 2026-08-20, re-verification due 2027-08-20

A prior-year IRA contribution must be made by the unextended due date Settled

• IRC 219(f)(3)
• IRS Publication 590-A, When Can Contributions Be Made

Tested by: ownedNonRothIraAnnualFilingEvidence.test.ts : “refuses a prior-year contribution made after the unextended deadline” , “counts a contribution made inside the window toward that year basis”

Implemented in: ownedNonRothIraAnnualFilingEvidence.ts ( buildPlanOwnedNonRothIraAnnualFilingEvidence ) ; ownedNonRothIraAnnualPostCandidateEvidence.ts ( buildPlanOwnedNonRothIraAnnualPostCandidateClassificationInput ) ; retirementActionAnnualTaxFacts.ts ( persistedPlanOwnedNonRothIraAnnualFilingSourceRecordSchema )

Verified 2026-08-04, re-verification due 2027-08-04

A reduced retirement claim before later disability onset carries into DIB Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. For claimAge 62, onsetAge 65, FRA 67, and a 2,000-dollar PIA, the authority-side amounts are 16,800 before onset (70 percent retirement factor) and 19,200 from onset (402(q)(2) treats retirement age as attained in the first DIB month, so a 36-month reduction period yields an 80 percent factor). The engine observably pays 0 before onset and 24,000 from onset. Extra or missing benefit changes taxable Social Security income, and a spending shortfall can be funded from accounts whose tax character differs, so the taxpayer-tax sign is not one-sided.

• 42 U.S.C. 423(a)(2)
• 42 U.S.C. 402(q)(1)
• 42 U.S.C. 402(q)(2)

Tested by: simulate.social-security.test.ts : “pays nothing before onset and the full PIA afterward when claimAge precedes onsetAge”

Implemented in: plan.ts ( socialSecurityIncomeSchema ) ; annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

A required minimum distribution cannot be converted to a Roth IRA Settled

• Treas. Reg. 1.408A-4, A-6(a)
• Treas. Reg. 1.408A-4, A-6(c)
• Treas. Reg. 1.408A-4, A-7(a)

Tested by: retirementActionExecution.test.ts (named-action RMD-reserve evidence) : “bars the conversion when every aggregated IRA was emptied before the sum came out” , “clears the conversion when the sweep took the whole sum from another owned IRA”

Tested by: simulate.rmd-roth.test.ts : “satisfies the whole RMD before any dollar becomes a conversion”

Implemented in: rothConversionExecution.ts ( executeRothConversions ) ; ownedNonRothIraRuntimeSourceSeries.ts ( validateOwnedNonRothIraRuntimeSourceSeries ) ; annualAggregateRothConversionPlan.ts ( annualAggregateRothConversionPlan ) ; annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; simulate.ts ( simulatePlan ) ; accountEligibility.ts ( resolveOwnerIraRmdSatisfaction )

Verified 2026-08-03, re-verification due 2027-08-03

A section 1211(b) allowance cannot burn the carryforward pool without adjusted taxable income Approximated

Interpretation and scope: applyCapitalLossCarryforward burns up to the annual ordinary-income allowance from the pool whenever a loss remains, even when ordinary income is zero and there is no taxable income for a section 1211(b) deduction to offset. A smaller remaining pool overstates tax when a later year's gains would otherwise have been absorbed. The companion fixture pins a zero-income year's remaining pool against statutory preservation.

• IRC 1212(b)(2)(A)
• IRC 1212(b)(2)(B)

Tested by: federalTax.test.ts : “burns the annual allowance from the pool even when ordinary income is zero”

Implemented in: federalTax.ts ( applyCapitalLossCarryforward )

Verified 2026-08-27, re-verification due 2027-08-27

A split-interest QCD must be paid directly to the entity and carry a nonassignable income interest Out of scope

• IRC 408(d)(8)(F)(i)
• IRC 408(d)(8)(F)(ii)(I)
• IRC 408(d)(8)(F)(ii)(II)
• IRC 408(d)(8)(F)(ii)(III)
• IRC 408(d)(8)(F)(iv)(II)

Refusal tested by: accountEligibility.test.ts (the direct-payment limb, not the missing attestation) : “refuses a direct trustee payment to a split-interest entity” , “does not let the direct-payment attestation buy the entity class back” , “accepts the same transfer to an ordinary public charity, so the refusal is the entity class”

Implemented in: annualQcdExecutionPrerequisite.ts ( evaluateAnnualQcdExecutionPrerequisites ) ; annualRetirementActionPublication.ts ( publishAnnualRetirementActions ) ; accountEligibility.ts ( evaluateQcd )

Verified 2026-08-27, re-verification due 2027-08-27

A spousal benefit is half the PIA and earns no delayed credits Settled

Interpretation and scope: Section 402(b)(2) is expressly subject to subsection (q), which supplies the early-claim reduction. The engine applies a steeper schedule for the spousal case than for a retirement benefit -- 25/36 of 1 percent for the first 36 months rather than 5/9 -- and the spouse base remains one-half of worker PIA without worker delayed credits. The guarded ordinary current-spouse composition is owned by `usc-42-402-q-3-B-k-3-A-current-spouse-dual-entitlement`; excluded current-spouse shapes retain disclosed legacy behavior. MFJ, a two-person household, and the worker’s configured start date are product proxies and do not establish current-spouse eligibility or actual worker entitlement. Living-divorced entitlement is governed by `cfr-20-404-331-living-divorced-spouse-eligibility`. The ssClaimMilestone pin covers the numerical statutory base in a prior-year insight comparator, not proof of actual historical payment or payable ledger, or complete winner, month, family-maximum, or timing logic.

• 42 U.S.C. 402(b)(2)
• 42 U.S.C. 402(c)(2)

Tested by: claimFactor.test.ts : “holds spousal at FRA with no delayed credits and brackets the current-spouse half-PIA comparator”

Implemented in: ssClaimMilestone.ts ( resolveCurrentSpouseSpousalAnnualPriorYear ) ; annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan ) ; claimFactor.ts ( spousalBenefitFactor ) ; maritalBenefits.ts ( maritalBenefitFor )

Verified 2026-09-07, re-verification due 2027-09-07

A state deduction defined by reference to the federal one moves when the federal one moves Settled

Interpretation and scope: This record is anchored federally because the proposition it settles is federal: it does not decide how a state adjusts a figure of its own, it keeps a borrowed federal figure equal to the federal figure, and it says what that federal figure comprises. The roster is deliberately no longer part of it. An earlier version named nine packs (AZ, CO, DC, IA, ID, MO, MT, ND, NM) and asserted that their law defines the state deduction by reference to the federal one, on the strength of two citations that are both federal and neither of which mentions any state -- a settled record whose disputed half rested on nothing. Research outside this record, resting on no authority carried here, reports two of the nine wrongly tagged: Arizona conforming in method rather than in amount, and the District of Columbia decoupled from the OBBBA increase. Neither is asserted here and neither can be, because confirming either needs an Arizona or a District of Columbia primary source and the conformance guard admits no publisher for either state; the pack corrections are separately decided work. The right long-term shape is a per-state record carrying that state’s own authority for its own conformity, one for each pack that claims to borrow the federal figure. That is a larger piece of work than this correction and is scoped as a follow-up, not attempted here. Three boundaries survive from the earlier version and are deliberate. State BRACKETS are not touched -- those are state dollar amounts under state law, some indexed, some fixed by statute, several on legislated rate ramps, and the per-state research to move any of them does not exist yet -- and neither are the state retirement-exclusion caps, which are likewise state figures (the Colorado 24,000 dollar pension subtraction is not indexed by Colorado law). A state that decouples from the federal basic amount loses the tag and keeps its own basic figure, which this path does not federally scale; whether an age-65 additional amount rides along is each state’s own adoption policy, not this tag. Maine and South Carolina decoupled the basic for 2026 and are untagged; Maine separately incorporates the federal age addition under its own statute. And the scaling factor is the plan assumed general inflation rather than the C-CPI-U of section 1(f)(3), with the statutory rounding of the increase to the next lowest multiple of 50 dollars not reproduced -- the same two approximations indexFederalTaxPack already makes, and they must be the same ones, because a conformed copy indexed on any other basis would diverge from the federal figure it is a copy of.

• IRC 63(c)(7)(B)(ii)
• IRC 63(c)(7)(A)
• IRC 63(c)(1)
• IRC 63(c)(3)
• IRC 63(f)(1)

Tested by: stateTax.test.ts : “measures nominal income against the federal deduction prescribed for that year” , “leaves a published year exactly as published”

Implemented in: index.ts ( indexFederalTaxPack ) ; year2026.ts ( CO , DC , IA , ID , MO , MT , NM , states.ND ) ; index.ts ( conformStateStandardDeduction ) ; stateTax.ts ( computeStateTaxableIncome )

Verified 2026-08-04, re-verification due 2026-12-02

A surviving spouse does not hold an inherited IRA Settled

• IRC 408(d)(3)(C)(ii)

Tested by: beneficiarySpousalElectionStatus.test.ts : “keeps a surviving spouse inside the election rules” , “takes a non-spouse beneficiary out of scope”

Implemented in: beneficiarySpousalElectionAnnualGate.ts ( gateBeneficiarySpousalElectionForAnnualCoordinator ) ; beneficiarySpousalElectionStatus.ts ( evaluateBeneficiarySpousalElection )

Verified 2026-09-12, re-verification due 2027-09-12

A survivor claim at 60 starts at 71.5 percent and rises to the survivor FRA amount Settled

Interpretation and scope: This record is confined to the reduction curve after a survivor FRA has been supplied. The nra.ts age-60-cohort error for 1961-and-later survivors is recorded separately at usc-42-416-l-survivor-fra-age-60-attainment-cohorts; it is not a competing reading of this helper’s month interpolation.

• 42 U.S.C. 402(e)(1)(B)
• 42 U.S.C. 402(q)(1)
• 42 U.S.C. 402(q)(1)(A)
• 42 U.S.C. 402(q)(1)(B)(i)
• 42 U.S.C. 402(q)(6)(A)(iii)
• 42 U.S.C. 402(q)(6)(B)
• SSA POMS RS 00615.301, § B.1.b

Tested by: survivorBenefit.test.ts : “reduces a non-disabled age-60 survivor to 71.5 percent of the base”

Tested by: survivorBenefit.test.ts (midpoint claim at 63) : “prorates the widow reduction by the varying fraction at a midpoint before survivor FRA”

Implemented in: survivorBenefit.ts ( survivorReductionFactor )

Verified 2026-08-26, re-verification due 2027-08-26

A survivor’s own delay past survivor FRA earns no delayed-retirement credits Settled

Interpretation and scope: This rule is intentionally distinct from the deceased worker’s DRC pass-through. The survivor amount is not a retirement claim by the survivor, so the helper permits the deceased’s already-earned credits in the base but does not manufacture new credits from the survivor’s post-FRA delay.

• 42 U.S.C. 402(e)(2)(A)
• 20 CFR 404.313(a)

Tested by: survivorBenefit.test.ts : “does not add credits when the survivor waits from FRA to 70”

Implemented in: survivorBenefit.ts ( survivorBenefitMonthly )

Verified 2026-08-26, re-verification due 2027-08-26

A timely excess-elective-deferral distribution avoids taxing the deferral twice Out of scope

Interpretation and scope: The contribution allocator prevents modeled requests from exceeding its aggregate ceiling; it is not a record of an actual excess or a corrective distribution. actions/contract.test.ts gates the request and persisted action unions against a correction kind. The correction facts are absent from model/plan.ts; the current model/plan.test.ts membership list does not separately assert those correction facts.

• IRC 402(g)(2)(A)(i)
• IRC 402(g)(2)(A)(ii)
• IRC 402(g)(2)(C)
• IRC 402(g)(2)(C)(ii)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( traditionalAccountSchema )

Verified 2026-08-26, re-verification due 2027-08-26

A widow benefit is the whole PIA, not half of it Settled

Interpretation and scope: This record covers the whole-PIA limb only: its fixture holds the deceased at FRA so the whole-versus-half readings discriminate without delayed credits in play. The subparagraph (C) deeming that carries the deceased’s delayed credits into the survivor base is fixture-pinned at cfr-20-404-338-survivor-deceased-drc-pass-through. The early-deceased RIB-LIM amount and its ordering relative to the survivor’s own age reduction are registered separately at poms-rs-00615-320-rib-lim-after-survivor-reduction.

• 42 U.S.C. 402(e)(2)(A)

Tested by: survivorBenefit.test.ts : “pays the whole primary insurance amount to an unreduced survivor”

Implemented in: survivorBenefit.ts ( survivorBenefitMonthly )

Verified 2026-08-26, re-verification due 2027-08-26

A zero-basis traditional-IRA conversion is wholly includible Settled

• IRC 408A(d)(3)(A)(i)
• Treas. Reg. 1.408A-4, A-7(a)

Tested by: rothConversionExecution.test.ts (proven zero aggregated traditional-IRA basis) : “publishes the entire gross as taxable only when the basis numerator is proven zero”

Implemented in: rothConversionExecution.ts ( executeRothConversions ) ; accountEligibility.ts ( resolveOwnerAggregatedIraBasis )

Verified 2026-09-09, re-verification due 2027-09-09

ACA applicable percentage table for 2026 Settled

Interpretation and scope: The engine interpolates linearly between the published breakpoints. The revenue procedure gives an initial and a final percentage per band rather than a formula, and linear interpolation is the construction that reproduces both endpoints of every band. Section 3.01 presents those percentages as a table, so the quotation carries only the sentence introducing it; the bands and rates are stated above in this record rather than rewritten into prose and attributed to the revenue procedure.

• Rev. Proc. 2025-25, section 3.01

Tested by: aca.test.ts : “steps to the 133 band at exactly 133 percent of the poverty line”

Implemented in: year2026.ts ( year2026 ) ; aca.ts ( acaApplicablePct )

Verified 2026-08-04, re-verification due 2026-12-02

AMT is the excess of tentative minimum tax over regular tax Settled

Interpretation and scope: Section 55(b)(1) states the breakpoint as $175,000 and it is inflation-adjusted; the 2026 pack carries 244,500. The record is annually indexed for that reason, and the statutory figure should not be read as the current one.

• IRC 55(a)
• IRC 55(b)(1)

Tested by: federalTax.test.ts : “owes nothing when the regular tax already exceeds the tentative amount”

Implemented in: year2026.ts ( year2026 ) ; federalTax.ts ( computeFederalTax , tentativeMinimumTax )

Verified 2026-08-28, re-verification due 2026-12-26

ARF credits every full or partial work-deduction month Approximated

Interpretation and scope: The annualized convention is explicit in annualSocialSecurity.ts: after applying one annual earnings-test amount, it calculates `Math.round((withheld / benefit) * payableMonths)` and caps that integer to the year's payable months. That is not a record of the calendar months carrying a full or partial work deduction. The companion fixture withholds 2,000 dollars in each of the five below-FRA working years: the statute charges 1,400 dollars to the first month and 600 to the next, so POMS credits two months per year, ten in all, and a post-FRA year pays 17,800 dollars. The engine's annual ratio rounds to one credited month per year, five in all, and observably pays 17,300.

• 42 U.S.C. 403(f)(1)
• 20 CFR 404.415(a)
• SSA POMS RS 00615.482, § B.1
• SSA POMS RS 00615.482, § B.1 note

Tested by: simulate.social-security.test.ts : “rounds annual withholding to one ARF crediting month per year”

Implemented in: annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan ) ; claimFactor.ts ( claimFactor )

Verified 2026-09-07, re-verification due 2027-09-07

Absence of a disqualifying modification must be proven through the payment date Settled

Interpretation and scope: Section 72(t)(4) sets the consequence of a modification but no evidentiary standard for proving one did not happen, so the engine had to choose what suffices. It takes a dated attestation covering the payment and refuses anything earlier, because a proof running only to the start of the year cannot speak to a modification made in March. That is an engineering decision rather than a legal conclusion, and the attestation is not a test of the three events section 3.02(e) of Notice 2022-6 enumerates.

• IRC 72(t)(4)(A)

Tested by: ownedNonRothIraSeppAnnualReconciliation.test.ts : “refuses a payment its no-modification proof does not reach” , “names the insufficient modification evidence on the payment” , “reconciles once the proof reaches the payment date”

Implemented in: ownedNonRothIraSeppAnnualReconciliation.ts ( reconcileOwnedNonRothIraSeppAnnualSchedule ) ; ownedNonRothIraSeppCurrentPaymentCandidate.ts ( validateOwnedNonRothIraSeppCurrentPaymentCandidate )

Verified 2026-08-04, re-verification due 2027-08-04

Adjustment for a period-certain guarantee on a life annuity Approximated

• IRC 72(c)(2)
• Treas. Reg. 1.72-7(b)

Tested by: annuityAndProperty.approximation.test.ts (a guarantee longer than the single-life multiple) : “the accepted multiple is the pack Table V entry, not a figure chosen here” , “raises the denominator to the certain period instead of adjusting the investment” , “makes no adjustment at all where the guarantee is shorter than the life multiple”

Implemented in: annuityForms.ts ( annuityExclusionMultiple ) ; annualPensionAndAnnuityIncome.ts ( annualPensionAndAnnuityIncome ) ; simulate.ts ( simulatePlan )

Verified 2026-08-03, re-verification due 2027-08-03

After the election the spouse is the owner for all Code purposes Settled

Interpretation and scope: The annualOwnedAccountDrawsPhase planner computes the election-year owner requirement, credits only caller-accepted actual distributions, and takes the unpaid amount within live capacity without refunding excess prior distributions. The adapter admits completed current-year beneficiary history or coherent same-year j(4) pre-election actuals; a proposed/display row is not credit. The forced-distribution coordinator publishes electionYearOwnerRmdObligations with full requirement, evidence-bearing credit, pre-settlement unpaid, settled and unsatisfied amounts, and routes remaining owner obligations through the existing RMD gate and section 4974 contract. The describeRule production suite in simulate.spousalElectionYearOwnerRmd.test.ts binds the under-age, age-75, contribution-alone with prior history only, completed-shortfall and insufficient-balance discriminators. Its Roth suppression fixture gives two same-pool Roths identical verified elections and uses a distinct-decedent non-electing Roth as the nonqualified control. Both elected balances remain unchanged with no state facts; a pass-through observer of the actual production characterization callback delegates unchanged and requires calls only for the non-electing control. The control retains its source-derived 100 distribution and 40 taxable earnings, distinguishing suppression before characterization from a later cosmetic removal. This linkage is not a test-pass or closure claim. Mixed-year Form 8606 and transaction-tax chronology remain typed incomplete.

• Treas. Reg. 1.408-8(c)(3)
• IRC 72(t)(2)(A)(ii)

Tested by: beneficiaryTraditionalIraDeathPenalty.test.ts : “stops answering once the spouse has become the owner” , “still applies the death exception before any election”

Tested by: simulate.spousalElectionYearOwnerRmd.test.ts (election-year owner-RMD production) : “uses a verified contribution alone to refinalize owner RMD without a current-year history row” , “suppresses the elected Roth draw before shared basis consumption or state tax facts” , “publishes owner requirement 0 under RMD age without refunding already-paid cash” , “applies age-75 owner RMD 4065.04 and leaves 3065.04 unpaid after 1000 already paid” , “keeps the known owner-RMD shortfall and §4974 obligation when live balance cannot settle it” , “refinalizes a completed current-election-year 5000/4000 shortfall under owner rules without erasing its trigger”

Implemented in: beneficiarySpousalElectionStatus.ts ( evaluateBeneficiarySpousalElection ) ; beneficiaryTraditionalIraDeathPenalty.ts ( evaluateBeneficiaryTraditionalIraDeathPenalty ) ; annualForcedDistributionQcdAndRetirementActionsPhase.ts ( annualForcedDistributionQcdAndRetirementActionsPhase ) ; annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; annualOwnedAccountDrawsPhase.ts ( planElectionYearOwnerRmdDraws ) ; annualSeppDistributions.ts ( annualSeppDistributions ) ; beneficiarySpousalElectionGateAdapter.ts ( acceptedElectionYearQualifyingDistributions , electionYearOwnerRmdReferenceBalance , gateSpousalElectionFromInheritedAccount ) ; simulate.ts ( simulatePlan )

Verified 2026-08-03, re-verification due 2027-08-03

After-tax employer-plan rollover allocation to multiple destinations is not modeled Out of scope

• IRS Notice 2014-54, section III, first paragraph
• IRS Notice 2014-54, section III, second paragraph

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRothConversionRequestSchema ) ; plan.ts ( strategiesSchema )

Verified 2026-08-25, re-verification due 2027-08-25

Age 50 or 25 years of service for qualified public safety employees Out of scope

• IRC 72(t)(10)(A)

Refusal tested by: traditionalEmployerPlanPenaltyPrerequisite.test.ts : “refuses the age-50 claim rather than adjudicating it” , “does not quietly substitute age 50 into the Rule of 55 assessment” , “accepts the age-55 separation it does model, so the refusal is the age-50 substitution”

Implemented in: traditionalEmployerPlanPenaltyPrerequisite.ts ( evaluateTraditionalEmployerPlanPenaltyPrerequisite )

Verified 2026-08-28, re-verification due 2027-08-28

Age 59.5 exception to the early-distribution tax Settled

Interpretation and scope: No authority at any level defines when age 59.5 is attained: there is no section 1.72(t) regulation series, and the threshold appears throughout the regulations without ever being defined. The engine applies the six-calendar-months convention by analogy to Treas. Reg. 1.401(a)(9)-6(g)(1)(iv), which defines it for age 70.5 inside a defined-benefit provision addressed to something else. That analogy is universal industry practice but the IRS has never stated it for 59.5, and it carries the same unresolved month-end and leap-day edge as the age-70.5 rule - here against a 10 percent penalty rather than QCD eligibility.

• IRC 72(t)(2)(A)(i)
• IRC 72(t)(5)

Tested by: ownedNonRothIraPenaltyPrerequisite.test.ts : “accepts a distribution taken exactly on the 59.5 threshold”

Implemented in: ownedNonRothIraPenaltyPrerequisite.ts ( evaluateOwnedNonRothIraPenaltyPrerequisites ) ; traditionalEmployerPlanPenaltyPrerequisite.ts ( evaluateTraditionalEmployerPlanPenaltyPrerequisite )

Verified 2026-08-28, re-verification due 2027-08-28

Age 59.5 modelled as an annual attained-age-60 threshold Approximated

Interpretation and scope: The direction of the error is knowable but it is not one-sided, and a reader who assumes it is will mis-state the exposure. Attained age here is the calendar-year age, the projection year minus the birth year, so the proxy waives from January 1 of the year the owner turns 60 while the statute waives from the date six calendar months after the 59th birthday. For a birthday in the first half of the year that statutory date falls in the preceding calendar year, so the proxy waives late and over-penalizes, by up to about six months at a January 1 birth. For a birthday in the second half it falls inside the same calendar year the proxy is already waiving, so the proxy waives early and under-penalizes, again by up to about six months at a December 31 birth. Only a July 1 birthday makes the two agree exactly. It is out of scope rather than settled because the annual projection carries an attained age and no distribution date, so there is no boundary to compare anything against. Two reachable paths therefore disagree about the same taxpayer: the exact-cent path in actions/ownedNonRothIraPenaltyPrerequisite.ts and actions/traditionalEmployerPlanPenaltyPrerequisite.ts computes the boundary as addCalendarMonths(dob, 714) with the month-end clamp and accepts equality, which is the reading registered as irc-72-t-2-A-i-age-59-half. Only that path is filing-relevant; a penalty figure produced from the annual proxy must not be reported as one.

• IRC 72(t)(2)(A)(i)
• IRC 72(t)(1)

Tested by: accountEligibility.approximation.test.ts (December birthday — a January draw six months before 59½) : “places the statutory boundary at 2027-06-30, so a January 2027 draw precedes it” , “waives the penalty on an owned IRA from attained age 60, not from 59½” , “charges nothing on the projected 2027 draw, which the statute penalizes until June 30” , “does charge the statutory rate in 2026, where the two readings agree”

Tested by: accountEligibility.approximation.test.ts (January birthday — a December draw six months after 59½) : “places the statutory boundary at 2027-07-01, so a December 2027 draw follows it” , “still penalizes an owned IRA in the year the owner passes 59½” , “charges 10% on the projected 2027 draw, which the statute waives from July 1” , “does reach the statutory rate in 2028, where the two readings agree”

Implemented in: accountEligibility.ts ( traditionalWithdrawalPenaltyRate )

Verified 2026-08-03, re-verification due 2027-08-03

Age-65 waiver of the HSA 20 percent additional tax Settled

• IRC 223(f)(4)(C)
• IRC 72(t)(2)(A)(i), drafting contrast
• Instructions for Form 8889, line 17b

Tested by: annualHsaPenaltyEvaluation.test.ts : “still taxes a distribution taken on the 65th birthday itself”

Implemented in: annualHsaPenaltyEvaluation.ts ( evaluateAnnualHsaPenalty )

Verified 2026-08-03, re-verification due 2027-08-03

Allowed HSA contributions reduce adjusted gross income Settled

Interpretation and scope: The plan model has one HSA contribution stream and does not carry a separate employer-salary-reduction fact under section 106(d); the contribution allocator therefore applies the section 223(a) above-the-line treatment to the modeled HSA deposit. The contribution cap and the catch-up are registered separately. After this subtraction, annualFundingApplicationAndClosePhase commits the accepted realized MAGI entry that supplies the IRMAA lookback and passes the same reduced federal AGI into ACA MAGI assembly; simulatePlan owns and threads the longitudinal history. The independent MAGI add-back composition is registered at irc-36B-d-2-B-aca-household-magi-composition and usc-42-1395r-i-4-a-magi-agi-plus-tax-exempt-interest.

• IRC 223(a)
• IRC 62(a), (a)(19)

Tested by: simulate.contributions-growth.test.ts : “reduces realized MAGI and ACA household MAGI by the allowed HSA contribution”

Implemented in: annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; annualFundingApplicationAndClosePhase.ts ( annualFundingApplicationAndClosePhase ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

An HSA may reimburse the expenses of the beneficiary, spouse, and dependents Settled

Interpretation and scope: The reimbursement ledger consumes caller-supplied patient relationship facts. A qualifyingDependent input means a dependent under section 152 as modified by section 223(d)(2)(A); this function does not determine dependency from household, support, residency, or other underlying facts. It requires a nonblank patientRelationshipEvidenceId, binds that identifier to the owner, expense, relationship, and evaluation date, and rejects a self relationship that contradicts the patient identity. That structural evidence binding does not independently verify a spouse or dependent classification. The related-person fixture tests reimbursement conditional on the supplied qualifying relationship, not automatic dependency determination; callers must establish the relationship before submitting the claim.

• IRC 223(d)(2)(A)
• IRS Notice 2004-2, A-26

Tested by: annualHsaReimbursementLedger.test.ts : “qualifies spouse and qualifying-dependent reimbursements” , “refuses a relationship claim that contradicts the patient identity”

Implemented in: annualHsaReimbursementLedger.ts ( evaluateAnnualHsaReimbursementLedger ) ; annualHsaWithdrawalCharacter.ts ( classifyAnnualHsaWithdrawalCharacter )

Verified 2026-08-04, re-verification due 2027-08-04

An IRA annuity payment takes the year’s share of basis like any other distribution Settled

Interpretation and scope: THE FIXTURE NO LONGER HOLDS THE DENOMINATOR FIXED, and that change is the measure of what closed. While the contract sat outside line 6 this fixture had to price both of its readings over the ENGINE’S pool, or it would have become a second measurement of the companion defect rather than a measurement of this one. Both defects are closed, so the figures below are the statute’s throughout. An 80-year-old with a 1,000,000 dollar IRA carrying 200,000 of basis pays a 200,000 dollar qualified premium in 2026 and receives 12,000 from the contract in the same year, at a 0 percent return. Line 7 is the 49,504.95 required distribution plus the 12,000 payment, 61,504.95. Line 6 is the 750,495.05 the account kept plus the 188,000 the contract still holds, 938,495.05; line 9 is 1,000,000 exactly, the fraction is 0.2, and the year’s ordinary income is 49,203.96. Turning the contract’s payments on moves that figure by 9,600, which is 12,000 at the year’s own 0.8 — the payment taking its share, which is what this record exists to say. WHAT THE OLD ENTRY CLAIMED AND WHERE IT LANDED. It pinned 49,128.71 produced against 46,128.71 accepted and called the 3,000 between them the basis the payment was refused, while saying in terms that "the true statutory figure is larger than 3,000 and is deliberately not claimed" because the correct denominator was unavailable. It is available now, and the true figure is 49,203.96 — 75.25 ABOVE the old produced figure rather than 3,000 below it. That is not a contradiction: this record’s overstatement and its companion’s understatement ran in opposite directions on the same household, and the companion’s was the larger of the two here. A reader who expected the fix to lower this household’s tax should read that as the reason a pair of opposed approximations must never be netted in prose. WHAT WOULD CLOSE IT, said the old entry, “is a single change with a wide blast radius: routing an IRA-funded annuity payment through the owned-non-Roth-IRA withdrawal character path instead of the fully-ordinary branch.” That is what was done. WHERE THE FULLY-ORDINARY BRANCH SURVIVES, enumerated rather than gestured at, because the first version of this paragraph said “one shape” and was wrong. It survives in two places and both are correct. First, a contract outside the section 408(d)(2) aggregate altogether: Plan validation requires a qualified purchase to be funded from an owned traditional ACCOUNT and does not require an IRA, so an employer plan can pay a premium, and a contract its pre-tax dollars bought is not in this aggregation and its payments carry no Form 8606 basis to share. Second, a year the settlement does not commit, where the payment keeps the legacy treatment rather than being split against a pro-rata state opened on a pool the contract is not in — a second approximation invented to paper over the first. A THIRD SHAPE WAS FOUND AND CLOSED while verifying this sentence: a qualified purchase quoting a ZERO premium was excluded from staging, so a contract that paid without having been paid for had no occurrence and charged its payments in full while the year’s other distributions shared the basis — 2,400 a year on the fixture household. Nothing in 408(d)(2)(B) turns on how a contract was acquired, so it is staged like any other, contributing nothing to line 6 because it holds nothing. A CROSS-OWNER PURCHASE IS NOT ON THE LIST EITHER, and for one revision it silently was: the character was looked up under the contract’s own owner while the settlement published it under the pool owner, so a Plan naming one spouse’s contract against the other’s IRA charged the payment in full AND spent the basis the settlement had already allocated — tax charged, basis gone, every paying year, and nothing recording that it had happened. The lookup asks under the pool owner now, and the two households report the same figure to the cent.

• IRC 408(d)(2)(A), (B)
• IRS Publication 590-B, Distribution of an annuity contract from your IRA account, Tax treatment
• IRS Publication 590-B, Distribution of an annuity contract from your IRA account

Tested by: iraAnnuityCharacter.approximation.test.ts (the payment’s share of basis) : “prices the annuity payment at the fraction the aggregate produced” , “adds the payment at its taxable share and not at its face” , “prices a payment the same whoever the contract is named for” , “keeps a cross-owner contract whole across every paying year”

Implemented in: ownedNonRothIraContiguousReplay.ts ( replayOwnedNonRothIraContiguousYears ) ; ownedNonRothIraRuntimeSourceSeries.ts ( validateOwnedNonRothIraRuntimeSourceSeries ) ; annualPensionAndAnnuityIncome.ts ( annualPensionAndAnnuityIncome ) ; simulate.ts ( simulatePlan )

Verified 2026-08-07, re-verification due 2027-08-07

An IRA contribution is capped by compensation, not only by the dollar limit Settled

Interpretation and scope: This is the same shape as the section 415(c) annual additions cap: a two prong lesser of where applying only the dollar prong silently overstates. The engine previously applied only the dollar prong here. Wages are the engine only compensation source, so the compensation prong reads from projected wages for the year.

• IRC 219(b)(1)

Tested by: simulate.contributions-growth.test.ts : “holds a low earner to compensation rather than to the dollar limit”

Implemented in: annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-03, re-verification due 2027-08-03

An IRA receives its section 219 age-50 catch-up, not the employer-plan super catch-up Settled

Interpretation and scope: simulate.ts separates employer accounts, which call employerCatchUpForAge, from traditional and Roth IRA accounts, which add only contributionLimits.iraCatchUp50 at age 50 or later. The fixture in employerRothCatchUp.test.ts discriminates the published 2026 7,500 plus 1,100 IRA total from the employer-plan 7,500 plus 11,250 reading for an age-62 owner. The 11,250 comparison value comes from Notice 2025-67; it is not calculated from the statutory formula.

• IRC 219(b)(5)(B)(i)-(ii)
• IRC 414(v)(6)(A)(i)-(iv)
• IRS Notice 2025-67, IRA catch-up limit
• IRS Notice 2025-67, ages 60-63 catch-up limit

Tested by: employerRothCatchUp.test.ts (an age-62 IRA has the IRA catch-up, not the employer-plan amount) : “does not apply the employer-plan super catch-up to an IRA”

Implemented in: year2026.ts ( year2026 ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2026-12-24

An IRA repurchase disallows the wash-sale loss without an IRA basis adjustment Out of scope

Interpretation and scope: TaxRuleAuthorityKind has no revenue-ruling member. This is recorded as irsNotice, the closest existing kind for IRB guidance — a revenue ruling is IRB guidance; a publication is not.

• Rev. Rul. 2008-5, FACTS
• Rev. Rul. 2008-5, HOLDING

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( taxableAccountSchema )

Verified 2026-08-27, re-verification due 2027-08-27

An SSDI spouse auxiliary is one-half PIA before the disability-family reduction Approximated

Interpretation and scope: The disability limb of section 402(c)(1) quoted on this record lets a husband qualify on a worker entitled to disability insurance benefits without waiting for that worker to claim old-age benefits. annualSocialSecurity.ts nevertheless calculates `higherPayableMonths` from the worker stream's 62–70 `claimAge`, even though the SSDI branch disregards it for the worker payment. Section 425(a) also makes the worker's disability-benefit suspension suspend auxiliaries on that wage record, while the generic post-top-up SGA pass zeros only the worker. Benefit errors can affect taxable Social Security or trigger a taxable, tax-free, or gain-bearing replacement withdrawal, so the taxpayer-tax sign varies.

• 42 U.S.C. 402(c)(1)
• 42 U.S.C. 402(c)(2)
• 42 U.S.C. 425(a)

Tested by: simulate.social-security.test.ts : “does not start the SSDI spouse auxiliary before the worker reaches claimAge” , “zeros only the SSDI worker when wages exceed annual SGA, leaving the spouse paid”

Implemented in: annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan ) ; familyMaximum.ts ( capAuxiliaryForFamilyMaximum )

Verified 2026-08-27, re-verification due 2027-08-27

An annuity contract an IRA bought stays inside the Form 8606 aggregate Settled

Interpretation and scope: WHAT THE PROBE SHOWED, kept because it is the proof and not the history. Take a 76-year-old with a 1,000,000 dollar traditional IRA carrying 200,000 of nondeductible basis, a 42,194.09 required distribution, a 100,000 dollar Roth conversion, and a 0 percent return assumption. Run that household twice, once as it stands and once with a 200,000 dollar qualified annuity premium paid out of the same IRA in the same year. Under the compelled reading the two households report the SAME ordinary income, to the cent, because the premium moves value from one line-6 asset to another and line 9 is 1,000,000 either way: 142,194.09 of lines 7 and 8 at a basis fraction of 0.2 is 113,755.27. The engine reports 113,755.27 for both of them. It used to report 106,645.57 for the household with the premium — 7,109.70 less, in one year, for a transaction that changed nothing the statute measures — and the fixture that pinned that gap now pins its absence. THE ZERO PERCENT RETURN IS STILL DELIBERATE and still does the same work: it makes the contract’s December 31 value exactly the premium, so the figure needs no valuation convention and the fixture measures aggregation rather than valuation. WHAT IS NOT CLOSED HERE, and must not be read as closed. This record is about WHETHER the contract is in the denominator, not about what number goes in. The engine supplies premium accumulated less payments, floored at zero, with no growth, because no authority supplies an actuarial fair market value and the Plan carries no contract growth rate; that convention is registered separately, with both of its directions and their magnitudes, as irc-408-d-2-C-annuity-contract-close-of-year-value. At a 0 percent return the two questions do not interact at all, which is why the figures above are unaffected by it. SETTLED ON 2026-08-07, having been approximated since 2026-08-05. The record as written then said the fix "cannot be" made "without a contract value the model does not carry", and that the value "belongs to the slice that adds the field, not to the slice that found the gap". Both sentences were right about the sequencing and wrong about the difficulty: the field is a channel rather than a balance, and the reason the gap survived was not that the value was unavailable but that no arm of the engine had been asked to carry one. The old entry also predicted its own end correctly — "the day a contract value enters the denominator the pin fails and names this entry" — and that is how this reclassification was found.

• IRC 408(d)(2)(A), (B)
• IRC 7701(a)(37)
• Instructions for Form 8606 (2025), IRAs Generally; Line 6
• Instructions for Forms 1099-R and 5498 (2026), Form 5498 Box 5

Tested by: iraAnnuityCharacter.approximation.test.ts (the line 6 denominator) : “recovers basis at the fraction the whole aggregate produces” , “makes a purchase the form cannot see invisible to the engine too” , “carries the contract at the value the aggregate lost, and no more”

Implemented in: iraAnnuityContractValue.ts ( openingAnnuityContractValuePlanDollars ) ; ownedNonRothIraContiguousReplay.ts ( replayOwnedNonRothIraContiguousYears ) ; ownedNonRothIraRuntimeSourceSeries.ts ( validateOwnedNonRothIraRuntimeSourceSeries ) ; annualPensionAndAnnuityIncome.ts ( annualPensionAndAnnuityIncome ) ; simulate.ts ( simulatePlan ) ; accountEligibility.ts ( isAggregatedIra )

Verified 2026-08-07, re-verification due 2027-08-07

An eligible 457(b) plan may provide a final-three-taxable-year catch-up Out of scope

Interpretation and scope: The generic employer-deferral allocator treats 457b only as a plan class and has no final-three-year state. model/plan.test.ts gates the missing sponsor, normal-retirement-age, and unused-deferral fields; actions/contract.test.ts gates the absence of an attested special-catch-up action. The id drops "governmental" because section 457(b)(3) is not limited to governmental sponsors.

• IRC 457(e)(1)(A)
• IRC 457(e)(1)(B)
• IRC 457(b)(3)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( traditionalAccountSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2026-12-24

An employer plan may permit, but need not offer, a catch-up contribution Approximated

Interpretation and scope: The input model identifies an account as kind employer but has no plan-permits-catch-up fact. simulate.ts consequently assigns employerCatchUpForAge to every employer account at the eligible age. The fixture in employerRothCatchUp.test.ts uses an age-62 participant who requests 24,500 plus 11,250: a plan without the optional feature allows only 24,500, but the engine accepts 35,750 as a pre-tax contribution and understates tax. The published 11,250 figure used by that fixture is Notice 2025-67's 2026 figure, not a reconstruction of SECURE 2.0's formula.

• IRC 414(v)(1)
• P.L. 117-328, division T, title I, section 109(a)(1)
• IRS Notice 2025-67

Tested by: employerRothCatchUp.test.ts (a missing plan term makes the optional age-62 catch-up automatic) : “accepts the super catch-up even though the plan-permission fact is absent”

Implemented in: plan.ts ( rothAccountSchema , traditionalAccountSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2026-12-24

An employer-plan distribution is not a QCD source Settled

• IRC 408(d)(8)(B)
• IRC 7701(a)(37)

Tested by: annualQcdActionExecutionEvidence.test.ts : “executes an IRA source and refuses an employer-plan source” , “allocates identity for an ordinary IRA and blocks an employer-kind source that differs only in kind”

Implemented in: annualQcdDerivedTaxCharacter.ts ( finalizeAnnualQcdDerivedTaxCharacter ) ; annualQcdExecutionPrerequisite.ts ( evaluateAnnualQcdExecutionPrerequisites ) ; retirementActionCandidateIdentityAllocator.ts ( qcdSourceIssue ) ; accountEligibility.ts ( evaluateQcd )

Verified 2026-09-05, re-verification due 2027-09-05

An excluded QCD cannot also produce a section 170 deduction Settled

• IRC 408(d)(8)(E)
• IRC 170(a)(1)

Tested by: annualQcdActionExecutionEvidence.test.ts : “lets the non-excluded portion proceed to section 170 treatment” , “pins notApplicable treatment on a wholly excluded QCD”

Implemented in: annualQcdDeductionTreatmentCoordinator.ts ( coordinateAnnualQcdDeductionTreatment ) ; annualQcdDerivedTaxCharacter.ts ( finalizeAnnualQcdDerivedTaxCharacter ) ; annualQcdTaxCharacterPostPass.ts ( stageAnnualQcdTaxCharacterPostPass )

Verified 2026-08-25, re-verification due 2027-08-25

An expense already deducted under section 213 cannot also be reimbursed Approximated

Interpretation and scope: Approximated rather than out of scope because the engine does not refuse here; it returns a figure computed on the assumption that the expense was never deducted, which is precisely the assumption that flatters the taxpayer. There is no better convention available: assuming the expense was deducted would disqualify every reimbursement in a household that itemizes and would be wrong far more often. The missing input is a per-expense prior-deduction flag, which is a data question rather than a modelling one, and the engine should carry the flag before it carries an answer.

• IRS Notice 2004-50, A-39
• IRC 223(f)(6)

Tested by: seppHsaAndCharacter.approximation.test.ts (nonqualified cents on a reimbursement of a deducted expense) : “excludes the whole distribution though the expense was deducted last year” , “cannot be told about the prior deduction at all”

Implemented in: annualHsaReimbursementLedger.ts ( evaluateAnnualHsaReimbursementLedger )

Verified 2026-08-04, re-verification due 2027-08-04

An expense incurred before the HSA existed is never reimbursable Settled

• IRS Notice 2004-2, A-26
• IRS Notice 2008-59, A-38

Tested by: annualHsaReimbursementLedger.test.ts : “refuses to reimburse an expense incurred before the HSA existed” , “admits the same claim once establishment precedes the expense”

Implemented in: annualHsaReimbursementLedger.ts ( evaluateAnnualHsaReimbursementLedger ) ; annualHsaWithdrawalCharacter.ts ( classifyAnnualHsaWithdrawalCharacter )

Verified 2026-08-04, re-verification due 2027-08-04

An expense is qualified only to the extent it is not already compensated Settled

• IRC 223(d)(2)(A)
• IRS Notice 2004-50, A-39

Tested by: annualHsaReimbursementLedger.test.ts : “measures a claim against the remainder, not the original amount” , “chains the remainder across allocations within the year”

Implemented in: annualHsaReimbursementLedger.ts ( evaluateAnnualHsaReimbursementLedger ) ; annualHsaWithdrawalCharacter.ts ( classifyAnnualHsaWithdrawalCharacter )

Verified 2026-08-04, re-verification due 2027-08-04

An ongoing SEP or SIMPLE IRA is not a QCD source Settled

• IRC 408(d)(8)(B)
• IRS Notice 2007-7, Q&A-36
• IRS Publication 590-B (2025), Qualified charitable distributions (QCDs)

Tested by: annualQcdActionExecutionEvidence.test.ts (inactive SEP/SIMPLE) : “executes a QCD from an inactive SEP IRA under Notice 2007-7” , “executes a QCD from an inactive SIMPLE IRA under Notice 2007-7”

Tested by: annualQcdActionExecutionEvidence.test.ts (ongoing SEP/SIMPLE) : “does not execute a QCD from a SEP IRA whose activity is unknown” , “does not execute a QCD from a SIMPLE IRA whose activity is unknown” , “does not execute a QCD from an ongoing SEP IRA” , “does not execute a QCD from an ongoing SIMPLE IRA”

Implemented in: annualQcdDerivedTaxCharacter.ts ( finalizeAnnualQcdDerivedTaxCharacter ) ; annualQcdExecutionPrerequisite.ts ( evaluateAnnualQcdExecutionPrerequisites ) ; accountEligibility.ts ( evaluateQcd )

Verified 2026-08-25, re-verification due 2027-08-25

An ordinary early current-spouse benefit adds reduced own and reduced excess Settled

Interpretation and scope: This record settles component arithmetic only after RetireGolden’s narrow Plan proxy admits the case. The proxy requires marriedFilingJointly with exactly two people; exactly one resolved Social Security stream per person; no disability declaration on either stream; the claimant’s original raw claim age strictly before the claimant’s retirement FRA; strict DOB-plus-raw-claim-age civil dates, with month-end clamping rejected, showing the worker’s configured date no later than the claimant’s; both people alive and both streams payable in the priced period; and a positive half-PIA excess. The helper uses the claimant’s existing actual own monthly amount plus the existing spouse factor applied to max(0, one-half worker PIA minus claimant own PIA). Raw original claim age selects the branch even in later post-FRA projection years; attained age and ARF-credited age do not. A worker configured earlier, including at or after the worker’s FRA, may enter because the spouse base is the worker PIA. MFJ, configured dates, and payable rows are planning proxies, not proof of marriage, application, insured status, prescribed application, or an actual SSA entitlement month. The helper returns null outside the complete guard, leaving staggered later-worker, claimant delayed-own, disability, multiple-stream, clamped-date, and nonpositive-excess shapes on the disclosed legacy paths. POMS RS 00615.694 confirms that delayed-credit composition needs a different sequence and is deliberately excluded.

• 42 U.S.C. 402(q)(3)(A)-(B)
• 42 U.S.C. 402(k)(3)(A)
• SSA POMS RS 00615.250, A. Policy
• SSA POMS RS 00615.694, A. Policy

Tested by: simulate.social-security.test.ts : “adds reduced own and the separately reduced spouse excess in the full year after simultaneous early claims”

Implemented in: currentSpouseBenefit.ts ( ordinarySimultaneousEarlyCurrentSpouseComponents )

Verified 2026-09-06, re-verification due 2027-09-06

Annual QCD exclusion limit Settled

• IRS Notice 2025-67

Tested by: annualQcdTaxCharacterPostPass.test.ts : “excludes only the indexed annual limit”

Implemented in: year2026.ts ( year2026 )

Verified 2026-08-02, re-verification due 2026-11-30

Annual additions are capped by pay as well as by the dollar limit Settled

Interpretation and scope: Section 415(c)(3) compensation is broader than wages, and the engine uses wages as the stand-in, so the pay prong binds slightly earlier here than under the statute. Annual additions under 415(c)(2) are employer contributions, employee contributions and forfeitures; the engine models the first two and has no concept of forfeitures.

• IRC 415(c)(1)
• IRC 415(c)(2)

Tested by: simulate.contributions-growth.test.ts : “binds both total additions and the deferral to the participant pay prong”

Implemented in: year2026.ts ( year2026 ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-04, re-verification due 2026-12-02

Annual pro-rata basis recovery across all owned non-Roth IRAs Settled

Interpretation and scope: The exclusion of inherited IRAs from the owner pool has no authority above publication level. IRC 408(d)(2)(A) says "all individual retirement plans" without qualification, and an inherited IRA is one from which the beneficiary takes distributions; the separation rests on Publication 590-B and the Form 8606 instructions, neither of which binds. Roth separation, by contrast, is statutory under 408A(d)(4)(A). The engine follows the IRS position because it is uniform administrative practice and the literal reading has no practitioner following, but the asymmetry in authority is worth knowing. Note the pooling is per decedent, not merely owned versus inherited.

• IRC 408(d)(2)
• IRC 408A(d)(4)(A)
• IRS Publication 590-B, inherited IRA basis

Tested by: ownedNonRothIraWithdrawalCharacter.test.ts : “derives one annual denominator across owned non-Roth IRAs and excludes inherited balances”

Implemented in: annualIraBasisAllocation.ts ( allocateAnnualIraBasis ) ; beneficiaryTraditionalIraWithdrawalCharacter.ts ( classifyBeneficiaryTraditionalIraWithdrawal ) ; ownedNonRothIraWithdrawalCharacter.ts ( classifyOwnedNonRothIraAnnualWithdrawals )

Verified 2026-08-04, re-verification due 2027-08-04

Annual-ledger attribution of a household QCD scalar to its donors Settled

Interpretation and scope: TWO CONVENTIONS THE STATUTE DOES NOT SUPPLY, because the plan input is a household scalar and section 408(d)(8) speaks only of an individual’s gift. Neither affects how much the household may exclude; both decide which donor’s pool pays, and therefore which donor’s Form 8606 fraction moves. ATTRIBUTION. The routed half is charged in proportion to each owner’s share of the owned-IRA required distribution it is capped against, clamped at that owner’s own requirement so no share can reach past what Treas. Reg. 1.408-8(e)(2)(i) aggregates for them, with the last owner in sorted id order taking the rounding residue. The beyond-requirement half is charged exactly, at the account it drains, in the arm’s existing plan-account balance order. REALLOCATION. What one donor’s own limit refuses is offered to the other donors, in sorted owner id order, up to what each may still route — their unrouted requirement and their unspent limit. Sorted order rather than a second proportional pass because the scalar carries no donor intent to honour: nothing in the section says whose gift it is, so the tie is broken by the same stable key the residue rule already uses rather than by plan account ordering, which would make WHICH DONOR GIVES depend on how the accounts happen to be listed. THAT MUCH IS ORDER-FREE AND THE NEXT STEP IS NOT, which an earlier version of this sentence elided by stopping one clause too soon. Once an owner’s share is fixed, it is carved out of that owner’s own required distributions greedily in mutation order — plan account order — and each entry’s Form 8606 line-7 gross is rounded to cents on its own. Every entry the carve consumes whole lands on zero and one entry is left partly consumed, so which entry carries the fractional remainder moves with the account listing, and the SUM of the independently rounded grosses can differ by one cent: a household with three IRAs and a routed gift publishes a line-9 denominator of 62,666,600 or 62,666,601 cents depending on the permutation, and exactly one figure in all six with no gift at all. The bound is one cent on the year’s denominator and it is not removable without cost: the annual ledger carves in plan dollars at the commit site and the settlement matches an assumed character only when its gross agrees to the cent, so rounding the carve earlier would make the two arms disagree and stop the year settling at all. A one-cent denominator spread is smaller than the cent-level tolerance every settled fixture on this engine already asserts at; a year that stopped settling is not. Whatever no donor can route falls through to the beyond-requirement arm, which charges it against the same capacities; whatever that arm cannot place either is not given, because giving it would mean excluding dollars past a taxpayer’s limit. Every eligible donor takes the same indexed figure, because (A) states one amount and (G) indexes that one amount — nothing in the section makes it depend on the donor’s age, filing status, or which IRA gave.

• IRC 408(d)(8)(A)
• IRC 408(d)(8)(B)(ii)
• Treas. Reg. 1.408-8(e)(2)(i)

Tested by: annualLegacyQcdGiftPlan.test.ts (two eligible donors each receive the Notice 2025-67 limit) : “allows two eligible taxpayers one indexed cap apiece”

Tested by: annualLegacyQcdGiftPlan.test.ts (stranded routed dollars are reallocated) : “offers a capped owner’s stranded routed share to the other owner”

Tested by: simulateContributionsAndQcd.approximation.test.ts (a couple giving more than one limit and less than two) : “excludes a couple’s gift above one limit against their two limits”

Tested by: simulateContributionsAndQcd.approximation.test.ts (a single donor asking for more than their own limit) : “still clamps one donor at one limit”

Tested by: simulateContributionsAndQcd.approximation.test.ts (an eligible donor beside an ineligible spouse) : “funds a household gift only from the eligible donor”

Implemented in: annualLegacyQcdGiftPlan.ts ( annualLegacyQcdGiftPlan ) ; simulate.ts ( simulatePlan )

Verified 2026-08-07, re-verification due 2026-12-05

Annual-ledger ordering of the QCD against pro-rata basis recovery Settled

Interpretation and scope: Two engineering conventions survive inside the corrected arm, because this arm’s gift is a household scalar the statute has no way to read. FIRST, ATTRIBUTION. Section 408(d)(8)(D) measures against ONE individual’s plans, and every owner has their own Form 8606 denominator, so the scalar has to be charged to owners before it can be measured. The part routed out of the required distribution is charged in proportion to each owner’s share of the owned-IRA required-distribution total the gift is already capped against; the part taken beyond the requirement is charged exactly, at the account it drains. Nothing in the authority selects a proportion, but every owner carrying an owned-IRA required distribution has reached the applicable age, which is above 70 and a half in every year the parameter pack covers, so no share of the gift can land on an IRA that could not lawfully have funded it under 408(d)(8)(B)(ii). SECOND, THE EXCESS. A gift larger than the owner’s whole aggregate includible amount is not a QCD in the excess, and that excess is an ordinary distribution which stays in the denominator, stays on line 7, and recovers basis. Where the year has both a routed and a beyond-requirement gift, the engine charges the excess against the routed half first. No authority orders them; the ordering is chosen because those dollars are already inside the year’s required-distribution gross and its line-7 gross, so the treatment needs no separate income term and the household’s reported income is identical either way. CORRECTION HISTORY. The figures this record carried while it was approximated were: on a $10,000 required distribution from an IRA that is 20 percent basis with a $5,000 gift, $3,000 of income and $2,000 of basis consumed, against a statutory $4,000 and $1,000 stated at the time; and on a $1,000,000 IRA carrying $200,000 of basis, a 76-year-old with a $42,194.09 requirement giving $40,000, $0 of income and $8,438.82 of basis consumed, against a statutory $1,755.27 and $438.82 stated at the time. THE STATUTORY FIGURES THEMSELVES WERE ALSO WRONG, and were corrected on 2026-08-07 when they were re-derived rather than inherited: both applied the UNREDUCED basis fraction to the residual distribution, which keeps the gift in the pro-rata denominator it has just been held to leave. The Form 8606 line-7 instructions exclude a QCD by name and line 6 is already net of it, so the denominator is the pre-distribution pool less the qualified gift. The corrected statutory answers, which the engine now produces and both fixtures pin, are $3,980.77 of income with $1,019.23 of basis on the first shape (53,000 / 260,000) and $1,736.99 of income with $457.10 of basis on the second (200,000 / 960,000).

• IRC 408(d)(8)(D)
• IRC 408(d)(8)(B), flush text
• IRC 408(d)(2)
• Instructions for Form 8606 (2025), Line 7

Tested by: simulate.qcdAggregateIncludible.test.ts (the ordering, with the aggregate ceiling not yet binding) : “taxes only the requirement the household kept, at the reduced denominator”

Tested by: simulate.qcdAggregateIncludible.test.ts (the ceiling the exclusion is measured against) : “excludes the whole gift and taxes the residual at the reduced denominator”

Tested by: simulate.qcdAggregateIncludible.test.ts (a gift that runs past the aggregate includible amount) : “qualifies only the pre-tax pool and turns the rest of the year into basis”

Implemented in: annualLegacyQcdOwnerCharacterPlan.ts ( annualLegacyQcdOwnerCharacterPlan ) ; simulate.ts ( simulatePlan )

Verified 2026-08-07, re-verification due 2027-08-07

Annual-ledger stand-in for the age 70.5 QCD date Approximated

Interpretation and scope: Direction of error: uniformly permissive, by up to twelve months, and the same sign for every birth month. The ledger reads the birth month rather than rounding to the calendar age — a donor born in months 1 through 6 is admitted in the year the calendar age is 70, and one born in months 7 through 12 in the year it is 71 — so the year the half-birthday falls in is always the year eligibility is granted. What annual granularity cannot express is where in that year it starts: a January-born donor is treated as eligible from 1 January though 70.5 arrives in July, and a December-born donor from the following 1 January though 70.5 arrives that June. There is no offsetting restrictive case, because no birth month puts the half-birthday in a year the ledger refuses. Superseded claim: this record previously said the ledger gates on a calendar age of at least 71 and so denies the whole crossing year, erring restrictively. That gate was replaced when the pre-RMD window was opened, and the argument that the permissive half was harmless — that no QCD could arise before the applicable age anyway, since a positive RMD was required — fell with the condition it rested on. The threshold date itself is the subject of irc-408-d-8-B-ii-age-70-half, whose leap-day and month-end convention is an engineering decision; this record is only about the annual proxy layered on top of it.

• IRC 408(d)(8)(B)(ii)
• Treas. Reg. 1.401(a)(9)-6(g)(1)(iv)

Tested by: annualLegacyQcdGiftPlan.test.ts (scalar planner annual age proxy) : “admits a June-born age-70 donor for the annual scalar” , “excludes a July-born age-70 donor from the annual scalar”

Tested by: hsaLimitAndQcdOffset.approximation.test.ts (when in the crossing year eligibility starts) : “admits a donor from 1 January of the year they cross 70.5 in December” , “refuses a donor whose half-birthday falls in the following year”

Implemented in: annualLegacyQcdGiftPlan.ts ( annualLegacyQcdGiftPlan ) ; simulate.ts ( simulatePlan )

Verified 2026-08-04, re-verification due 2027-08-04

Applicable age 70½ before July 1, 1949 and age 72 through 1950 Settled

Interpretation and scope: RECORD SCOPE AND PROJECTION CONVENTIONS. When year-only 1949 precision leaves both the 70½ and age-72 candidates open and they disagree on death-versus-RBD for a given death year, the engine refuses rather than guessing. The year-granular comparison consumes an asserted RBD-status fact when death falls in the RBD calendar year; it does not observe an exact death date inside that year. This record does not settle the born-1959 73/75 contest, the SECURE 2.0 73/75 tiers, or QCD day-level 70½ month-end arithmetic. YEAR-GRANULAR 70½ PLACEMENT. Former Treas. Reg. 1.401(a)(9)-2 Q&A-3 (T.D. 8987) states that age 70½ is attained six calendar months after the 70th anniversary of birth and works the June 30, 1933 → December 30, 2003 → April 1, 2004 and July 1, 1933 → January 1, 2004 → April 1, 2005 examples. Former 1.408-8 Q&A-1(a)–(b) incorporates those general RMD rules into IRAs and substitutes the IRA owner for the employee; former 1.408-8 Q&A-3 then fixes the IRA RBD as April 1 following the 70½ year. At month granularity the engine therefore places a January–June birth's 70½ attain year at birthYear+70 and a July–December birth's at birthYear+71. The unsettled QCD record (irc-408-d-8-B-ii-age-70-half) keeps month-end and leap-day day-resolution; this record does not claim day-level QCD eligibility. HISTORICAL APPLICABILITY. T.D. 10001's preamble states that the final regulations under section 401(a)(9) apply for distribution calendar years beginning on or after January 1, 2025, and that for earlier distribution calendar years taxpayers must apply the 2002 final regulations and 2004 final regulations, taking into account a reasonable, good faith interpretation of the amendments made by sections 114 and 401 of the SECURE Act. Current 1.401(a)(9)-2(b)(2)(ii)–(iii) and 1.408-8(b)(1)(i) corroborate the cohort cut and IRA April-1 form under present numbering; they are not claimed to have governed distribution year 2020. OWNER LIVING RMD PROJECTION SURFACE. The owner living RMD pass uses params/index.ts#rmdStartAgeForBirthYear as a distinct birth-year-only surface: it compares calendar-year age attained against that table rather than recomputing applicable age from month and day on every owned account. That collapses the SECURE §114 July 1949 cut and the 70½ tier, which is correct for nearly all living owners in a forward projection but wrong for inherited-regime classification when decedent birth precision matters — hence this record and applicableAge.ts. The 1951–1958 → 73 and 1960+ → 75 limbs rest on irc-401-a-9-C-v-applicable-age; the 1959 selection rests on treas-reg-1-401-a-9-2-b-2-v-applicable-age-1959. Pre-72 historical owner cohorts still in force before the projection start are out of scope for that birth-year table: the calculator does not attempt to re-derive whether a living owner born in 1948 should already be in year fifteen of distributions when the plan begins in 2026. BOUNDARY VERSUS SIBLINGS. irc-401-a-9-C-v-applicable-age and treas-reg-1-401-a-9-2-b-2-v-applicable-age-1959 own the 73/75 tiers and the 1959 contest; first-distribution-calendar-year booking and April 1 deferral elections stay on their existing C(i) / 1.401(a)(9)-5(a)(2) records; the employer-plan still-working exception stays on irc-401-a-9-C-i-II-still-working-exception. EFFECTIVE SCOPE. effectiveFrom is 2020 as the first distribution-applicability year of the SECURE §114 transition: both §114(d) conditions must hold — distributions required after December 31, 2019, and individuals attaining 70½ after that date. It is not the enactment date of the older 70½ rule, not T.D. 10001's 2025 applicability, and not the first required-distribution year of the age-72 cohort (a July 1949 birth attains 72 in 2021 with IRA RBD April 1, 2022; a July 1948 birth attains 70½ in 2019 and retains the historical IRA RBD of April 1, 2020). Dating this record 2026 would invent a represented-horizon convention the authority does not use.

• IRC 401(a)(9)(C)(i) (2011 ed., pre-SECURE)
• IRC 401(a)(9)(C)(ii) (2011 ed., pre-SECURE)
• Pub. L. 116-94, div. O, sec. 114(a), (d) (SECURE Act)
• Treas. Reg. 1.401(a)(9)-2, Q&A-3 (T.D. 8987, 67 FR 18988, 18996)
• Treas. Reg. 1.408-8, Q&A-1(a)-(b) (T.D. 8987, 67 FR 18988, 19024)
• Treas. Reg. 1.408-8, Q&A-3 (T.D. 8987, 67 FR 18988, 19025)
• T.D. 10001, preamble on distribution-calendar-year applicability
• Treas. Reg. 1.401(a)(9)-2(b)(2)(ii), (iii) (current corroboration; T.D. 10001 numbering)
• Treas. Reg. 1.408-8(b)(1)(i) (current corroboration)

Tested by: applicableAge.test.ts : “keeps the June 30 / July 1, 1949 cut, 70½ attain years, IRA RBD-year placement, and age-72 cohort RBD tie-break”

Implemented in: applicableAge.ts ( applicableAgeAttainYears , deriveRbdComparison )

Verified 2026-09-04, re-verification due 2027-09-04

Applicable age for an owner born in 1959 Unsettled

Interpretation and scope: OWNER VERSUS INHERITED. The owner living-RMD path has to select one start age and follows the proposed 73. The inherited deriveRbdComparison path keeps both candidate RBD dates (April 1, 2033 at age 73; April 1, 2035 at age 75) and refuses with born-1959-applicable-age-contested only where those candidates disagree on before versus on-or-after; deaths outside both candidate RBD years resolve when the asserted fact agrees, and at the same candidate RBD year the existing year-only asserted-status tie-break applies. The applicable age remains legally contested even when a particular comparison resolves. The two paths are independent: collapsing the inherited candidates onto the owner's 73 would change the between-RBD-years outcome from the contest refusal into the ordinary assertion-contradicts-derivation guard, and collapsing onto 75 would treat that same death year as before-rbd. This slice registers only deriveRbdComparison for born 1959; applicableAgeAttainYears stays listed on treas-reg-1-401-a-9-2-b-2-ii-iii-applicable-age-70-half-and-72, irc-401-a-9-C-v-applicable-age, and treas-reg-1-401-a-9-5-d-1-ii-greater-of-employee-life-expectancy unchanged.

• IRC 401(a)(9)(C)(i)-(ii)
• IRC 401(a)(9)(C)(v)
• Treas. Reg. 1.401(a)(9)-2(b)(2)(iv), (v), (vi)
• Prop. Treas. Reg. 1.401(a)(9)-2(b)(2)(v), REG-103529-23, 89 FR 58644
• Announcement 2026-7 section III, 2026-11 I.R.B. 697

Tested by: params.test.ts : “fixes owner RMD at 73 and refuses inherited comparison only when contested candidates disagree”

Implemented in: index.ts ( rmdStartAgeForBirthYear ) ; applicableAge.ts ( deriveRbdComparison ) ; rmd.ts ( requiredMinimumDistribution )

Verified 2026-09-05, re-verification due 2026-12-04

Basis treatment of a QCD that is only partly excludable Unsettled

• IRC 408(d)(8)(D)
• Instructions for Form 8606 (2025), Line 7
• IRC 408(d)(8)(E)
• Instructions for Form 1040 (2025), line 4a/4b Exception 3

Tested by: annualQcdTaxCharacterPostPass.test.ts : “keeps the includible excess inside the QCD and discloses the reading”

Implemented in: annualQcdTaxCharacterPostPass.ts ( stageAnnualQcdTaxCharacterPostPass )

Verified 2026-09-08, re-verification due 2026-12-07

Beneficiary remaining life expectancy: which table, and whether it is fixed Settled

Interpretation and scope: Three notes on how far this reaches. First, on the labeled legacy path — accounts with only the two-field inherited block and classifier-refusal fallbacks — the fixed subtract-one branch is what inheritedForcedAmount can reach; that path holds no beneficiary-category fact and cannot select the (d)(3)(iv) spouse redetermination arm. Classified schedules execute the spouse-redetermined path in the exact ledger via classifyInheritedRegime and inheritedRequirementForYear in strategies/inheritedIra.ts (S0/S1 spouse remain-beneficiary and K2 spouse rows). Second, the table is read at a whole age, as singleLifeExpectancyYears in params/index.ts does, and the fixed entry may fall to zero or below for a beneficiary who inherits past about 110; the module then requires the whole remaining interest, since there is nothing left to divide by. Third, this record covers the beneficiary expectancy only. The greater-of test that compares it against the employee expectancy is a separate paragraph and is registered separately as treas-reg-1-401-a-9-5-d-1-ii-greater-of-employee-life-expectancy, where it remains out of scope. Until this record was settled the module divided by a sex-specific SSA period life expectancy looked up at the beneficiary current age, described in its own header as a documented proxy for the Single Life Table; the fixture asserting that behaviour called the same SSA function the module called and could not have failed.

• Treas. Reg. 1.401(a)(9)-5(d)(3)(i)
• Treas. Reg. 1.401(a)(9)-5(d)(3)(iii)
• Treas. Reg. 1.401(a)(9)-5(d)(3)(iv)
• Treas. Reg. 1.401(a)(9)-9(b)

Tested by: inheritedIra.test.ts (which table supplies the expectancy) : “sizes the annual amount from the Single Life Table, not the SSA period table” , “carries the published divisor, not an approximation of it” , “is unisex, so no SSA column can be recovered from the amount”

Tested by: inheritedIra.test.ts (fixed at the first distribution year or redetermined each year) : “reduces the initial expectancy by one a year rather than re-reading the table” , “reads the table once, at the age reached in the year after death” , “does not turn on the age the beneficiary happens to be now”

Implemented in: index.ts ( singleLifeExpectancyYears ) ; inheritedIra.ts ( beneficiaryRemainingLifeExpectancy )

Verified 2026-08-04, re-verification due 2027-08-04

Blind SGA is a separate wage-indexed monthly amount Out of scope

Interpretation and scope: This follows the authority shape of cfr-20-404-1574-b-2-sga-non-blind-monthly-amount: the current-year amount is a wage-indexed determination, not an OACT table lookup. The staged eCFR text establishes that blindness has a distinct guideline and wage-indexing method. The implementation surface is absent in both model/plan.ts and params/types.ts/year2026.ts: there is no blindness input, `sgaMonthlyBlind`, or branch selecting one.

• 20 CFR 404.1584(d)(3)
• SSA, Cost-of-Living Increase and Other Determinations for 2026, 90 FR 49047 (Nov. 3, 2025)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( socialSecurityIncomeSchema ) ; year2026.ts ( year2026 ) ; types.ts ( sgaMonthlyNonBlind )

Verified 2026-08-27, re-verification due 2026-12-25

Buying an annuity contract with IRA dollars is not a distribution Settled

Interpretation and scope: WHY THE TWO STRUCTURES DO NOT HAVE TO BE DISTINGUISHED, which is the question the Plan schema raises by carrying neither. A Plan annuity purchase records a premium, a funding account, a tax qualification and a QLAC flag; it does not record who issues the contract, and it therefore cannot say whether the result is a section 408(b) individual retirement annuity or an annuity contract sitting inside a section 408(a) trust. That silence is harmless here because the two roads arrive at the same place. On the first, the contract is itself an individual retirement plan and the movement into it is a trustee-to-trustee transfer, which Treas. Reg. 1.408-8(d)(4) states is not a distribution and which the Form 1099-R instructions direct the issuer not to report. On the second, nothing moved between plans at all — the trust exchanged cash for a contract, the way it would exchange cash for a bond. Section 408(a)(3) forbids the trust to invest in life insurance contracts and says nothing against an annuity contract, and the Form 1099-R instructions name the shape explicitly when they extend the Roth-conversion valuation rule to "a traditional IRA holds an annuity contract as an account asset". So the schema is not missing a fact the answer turns on. IT WOULD MATTER FOR A DIFFERENT QUESTION, and this is worth recording because the temptation to derive it here is real. Section 408(b)(2)(B) caps the annual premium of an individual retirement annuity at the section 219(b)(1)(A) dollar amount, and unlike section 408(a)(1) — which carves rollover contributions out of the parallel cap on an account — subsection (b) states no such exception in its text. A large single premium therefore sits uneasily with the first structure and not at all with the second. That asymmetry is not resolved here, because nothing this engine computes turns on it: the character of the purchase, the aggregation of the contract, and the taxation of the payments are the same either way. It is registered so that a later reader who needs the distinction knows it was seen and set aside rather than missed. ONE ROUTE TO THE CONTRARY READING IS NOT CLOSED, and the statement above should be read against it. The schema refuses a `nonQualified` premium drawn on a traditional account, which is the distribution-and-purchase shape said in so many words, but an annuity account’s `ownerPersonId` is independent of its funding account’s, so a Plan may name ONE spouse’s contract and pay for it out of the OTHER’s IRA. On the reading this record takes that is still not a distribution -- nothing was paid out to anybody -- and the engine treats it that way: the contract enters the funding owner’s section 408(d)(2) aggregate, its payments are that owner’s line-7 distributions AND are priced at that owner’s annual basis fraction — the two travel together, and separating them is a defect this engine wrote and caught: the gross joined the pool owner’s line 7 while the character was looked up under the contract’s owner, so the payment was charged in full and the basis its own allocation had already spent was never applied. Its `startAge` goes on being measured against the person the Plan named, which is the one question that field does answer. The competing reading is that a contract belonging to somebody else could only have been reached by distributing to the IRA owner first and gifting the proceeds, which would put the whole premium on that owner’s line 7 and raise a transfer question the model has no field for. Nothing here decides between them. What is recorded is that the engine takes the first, that the second would produce a materially larger tax in the purchase year, and that a shape a saved plan file already contains is a poor place to discover the question -- refusing it would only have sent the year to a ledger that drops the contract from line 6 altogether, which neither reading supports.

• IRC 408(d)(1)
• IRC 408(b)
• IRC 7701(a)(37)
• Treas. Reg. 1.408-8(d)(4)
• IRS Publication 590-B, Distribution of an annuity contract from your IRA account
• Instructions for Forms 1099-R and 5498 (2026), Transfers; Roth IRA conversions

Tested by: iraAnnuityCharacter.approximation.test.ts (the character of the premium) : “reports no income for a 200,000 dollar premium paid out of the IRA” , “reports the same income as the household that bought nothing”

Tested by: iraAnnuityCharacter.approximation.test.ts (the funding arms) : “refuses to draw a non-qualified premium from a traditional account” , “admits the qualified arm from the same account”

Implemented in: iraAnnuityContractValue.ts ( ownedIraFundedAnnuityContracts ) ; ownedNonRothIraRuntimeSourceSeries.ts ( validateOwnedNonRothIraRuntimeSourceSeries ) ; planCrossFieldChecks.ts ( checkAccountCrossFieldRules ) ; simulate.ts ( simulatePlan )

Verified 2026-08-07, re-verification due 2027-08-07

Carryover generated in a standard-deduction year Unsettled

• IRC 170(d)(1)(A)
• Treas. Reg. 1.170A-10(a)(2)
• IRC 170(d)(1)(C)(ii)

Tested by: annualQcdStandardSection170pLedger.test.ts : “carries the excess over the ceiling from a standard-deduction year” , “carries nothing below the ceiling, which is what the shorthand describes”

Implemented in: annualQcdStandardSection170pLedger.ts ( stageAnnualQcdStandardSection170pLedger )

Verified 2026-08-04, re-verification due 2026-11-02

Catch-up cannot exceed compensation minus other elective deferrals Settled

Interpretation and scope: Wages are the engine's only 415(c)(3) compensation source, the same stand-in the 415(c) pay prong already uses. IRA catch-up under 219(b)(5) is outside 414(v).

• IRC 414(v)(2)(A)

Tested by: employerRothCatchUp.test.ts (catch-up is limited to pay minus the 402(g) base) : “caps redirected catch-up at compensation minus other electives”

Implemented in: employerRothCatchUp.ts ( allocateEmployerElectiveDeferrals ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-19, re-verification due 2027-08-19

Category order in which the 0.5% floor is absorbed Settled

Interpretation and scope: The stable record id retains its historical I-ii suffix. The operative citation is IRC 170(b)(1)(I), clauses (i) through (vi), as quoted below; clause (ii) alone supplies only the second category.

• IRC 170(b)(1)(I)
• IRC 170, Editorial Notes, Effective Date of 2025 Amendment, Pub. L. 119-21, sec. 70425(c)

Tested by: annualQcdItemizedSection170Ledger.test.ts : “leaves the cash category unreduced once earlier categories consume the floor”

Implemented in: annualQcdItemizedSection170Ledger.ts ( stageAnnualQcdItemizedSection170Ledger )

Verified 2026-09-05, re-verification due 2027-09-05

Certain early Saver's Match distributions create a recovery tax Out of scope

Interpretation and scope: The recovery rule depends on a section 6433(a)(2) contribution history, end-of-year Saver's Match balance, and the specified-early-distribution classification. None is expressible on an account or a retirement action. The missing Saver's Match schema and action vocabulary are refused by the additive gates in model/plan.test.ts and actions/contract.test.ts. effectiveFrom is 2027 because the enacting applicability is taxable years beginning after December 31, 2026 — the rule cannot govern a 2026 pack year.

• IRC 6433(f)(6)(A)
• IRS Notice 2026-48, section I

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( planSchema )

Verified 2026-08-26, re-verification due 2026-11-24

Chapter 43 excise taxes are not deductible Settled

• IRC 275(a)
• IRC 275(a)(6)

Tested by: simulate.healthcare.test.ts (RMD-shortfall excise remains outside AGI, taxable income, and MAGI) : “keeps a chapter 43 RMD-shortfall excise out of the income-tax base”

Implemented in: annualFundingApplicationAndClosePhase.ts ( annualFundingApplicationAndClosePhase ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

Charitable remainder trust payout, remainder, and distribution-character mechanics are not modelled Out of scope

Interpretation and scope: The 5-to-50-percent payout bounds, the 10-percent remainder tests, the four-tier distribution ordering, and the CRAT probability-of-exhaustion question all share this absent CRT entity and payout surface. The supplied text of Treas. Reg. 1.664-2 contains no probability-of-exhaustion language to quote, so that practical test is not separately registered on this source set.

• IRC 664(a)
• IRC 664(c)(1)
• IRC 664(c)(2)(A)
• IRC 664(d)(1)(A)
• IRC 664(d)(1)(D)
• IRC 664(d)(2)(A)
• IRC 664(d)(2)(D)
• IRC 664(b)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( planSchema )

Verified 2026-08-27, re-verification due 2027-08-27

Child survivor benefits are outside the Plan Out of scope

Interpretation and scope: Absence-record surface is model/plan.ts: `household.hasQualifyingDependent` is a tax-filing boolean, not a child identity, dependency, age, student, disability, or Social Security-benefit record. familyMaximum.ts therefore caps only a modeled current-spouse auxiliary and has no child allocation to price. No accepted Plan supplies the trigger facts for a child survivor benefit.

• 42 U.S.C. 402(d)(2)
• 42 U.S.C. 403(a)(1)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( socialSecurityIncomeSchema )

Verified 2026-08-26, re-verification due 2027-08-26

Confirmed pre-RBD non-designated five-year emptying schedule Settled

Interpretation and scope: Verified classification is an explicit Plan input; the engine does not classify trusts. simulatePlan routes confirmed facts through classifyInheritedRegime, annualInheritedIraDistributions and coordinateInheritedDeadlineAnnualRuntime. simulate.inheritedRegimeExecution.test.ts covers the annual zeros before the deadline, the complete deadline sweep, unknown-trust refusal and rejection of contradictory post-RBD facts. Historical unsupported facts remain refused.

• IRC 401(a)(9)(B)(ii)
• Treas. Reg. 54.4974-1(c)(2)

Tested by: inheritedFiveYearAndPostDeadline.test.ts : “requires $0 annually 2027-2030 and full $50,000 by 2031-12-31 for a 2026 pre-RBD death” , “refuses unknown trust classification and rejects post-RBD on this pathway” , “refuses tax years before death, invalid civil dates, year mismatches, and blank provenance” , “routes deadline-plus-one to the post-deadline leaf without a second dollar requirement”

Implemented in: beneficiaryTraditionalIraAnnualRuntimeCoordinator.ts ( coordinateInheritedDeadlineAnnualRuntime ) ; annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan ) ; inheritedFiveYearAndPostDeadline.ts ( fiveYearEmptyingRequirement ) ; inheritedIra.ts ( classifyInheritedRegime )

Verified 2026-09-12, re-verification due 2027-09-12

Current eligible old-age and current-spouse benefits are deemed filed together Settled

Interpretation and scope: This record owns deemed-filing application coupling and the Plan’s single-claim-age representation; it does not own the dollar composition of dual entitlement. `usc-42-402-q-3-B-k-3-A-current-spouse-dual-entitlement` owns reduced-own-plus-reduced-excess arithmetic only inside its complete ordinary early guard. MFJ, two people, and configured stream dates remain product proxies rather than proof of eligibility, application, or entitlement month, and all excluded shapes retain their separately disclosed partial behavior.

• 42 U.S.C. 402(r)(1)
• 42 U.S.C. 402(r)(2)
• 42 U.S.C. 402(r)(3)
• 42 U.S.C. 402, Editorial Notes, Effective Date of 2015 Amendment (BBA 2015 § 831(a)(3))

Tested by: simulate.social-security.test.ts : “deems own filed so year-one benefit is the own amount, not restricted spouse-only” , “exposes exactly one claimAge and no restricted-application vocabulary on the SS stream”

Implemented in: plan.ts ( socialSecurityIncomeSchema ) ; annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2027-08-26

Date a donor attains age 70.5 for QCD eligibility Unsettled

Interpretation and scope: The six-calendar-months sentence survives, but only in a provision written for something else: T.D. 10001 removed it from Treas. Reg. 1.401(a)(9)-2 and it now sits in 1.401(a)(9)-6(g)(1)(iv), a defined-benefit actuarial-increase rule. It has also been dropped from current IRS publications and survives there only in Publication 575 (2019). So the convention is sourced, but not from any provision addressed to IRC 408(d)(8)(B)(ii). What no source resolves at any level is a month-end or leap-day birth: no IRS guidance, ruling, case, publication example, or practitioner source addresses what "six calendar months after" means when the target day does not exist. The month-end clamp is chosen because it matches 29 CFR 4000.43, the one federal regulation resolving this class of problem, and because it is the prevailing practitioner convention. That regulation governs PBGC filings under ERISA Title IV and the IRS has never adopted it here, so the clamp is an engineering convention and not a legal conclusion. It errs permissive: for an August 31 birth it falls up to three days before a roll-forward reading, and a QCD taken in that window would not be a QCD at all. The date is load-bearing twice, because the SECURE 1.0 offset in 408(d)(8)(A) also keys the sweep of section 219 deductions to it.

• IRC 408(d)(8)(B)(ii)
• Treas. Reg. 1.401(a)(9)-6(g)(1)(iv) (relocated from 1.401(a)(9)-2 A-3 by T.D. 10001)
• IRS Publication 575 (2019)

Tested by: annualQcdActionExecutionEvidence.test.ts (month-end birth) : “clamps a nonexistent target day to the last day of that month”

Tested by: annualQcdActionExecutionEvidence.test.ts (leap-day birth) : “adds 846 months in one step rather than clamping the 70th anniversary first”

Implemented in: annualQcdActionExecutionEvidence.ts ( publishAnnualQcdActionExecutionEvidence ) ; annualQcdExecutionPrerequisite.ts ( evaluateAnnualQcdExecutionPrerequisites ) ; plan.ts ( personSchema ) ; accountEligibility.ts ( evaluateQcd )

Verified 2026-08-05, re-verification due 2026-11-03

Death exception to the early-distribution tax Settled

Interpretation and scope: The engine reads this exception off the inherited marker on the account rather than off the identity of the person receiving the distribution. Those are the same test only for so long as an account a surviving spouse has elected to treat as their own stops being marked inherited. That election is registered separately as irc-408-d-3-C-ii-surviving-spouse-not-inherited and treas-reg-1-408-8-c-3-spouse-treated-as-owner; once it is made the spouse takes distributions in their own right and 72(t) applies to them normally, so a plan that left the marker in place would waive a tax that is actually due. The exact-cent beneficiary path is stricter than the marker proxy: beneficiaryTraditionalIraDeathPenalty.ts requires recipient death-beneficiary evidence with a death date on or before evaluation and refuses once spousal owner treatment has begun, and beneficiaryTraditionalIraAnnualSimulatorDelta.ts propagates that zero only when the upstream module produced it.

• IRC 72(t)(2)(A)(ii)
• IRC 72(t)(5)

Tested by: beneficiaryTraditionalIraDeathPenalty.test.ts (beneficiary traditional IRA death-penalty module) : “publishes zero from the death path, not the 10 percent early rate”

Tested by: accountEligibility.test.ts : “exempts an inherited account at every age the age test would penalize” , “does not borrow the Rule of 55, which an inherited employer account would fail”

Implemented in: beneficiaryTraditionalIraAnnualSimulatorDelta.ts ( prepareBeneficiaryTraditionalIraAnnualSimulatorDelta ) ; beneficiaryTraditionalIraDeathPenalty.ts ( evaluateBeneficiaryTraditionalIraDeathPenalty ) ; ownedNonRothIraPenaltyPrerequisite.ts ( evaluateOwnedNonRothIraPenaltyPrerequisites ) ; accountEligibility.ts ( traditionalWithdrawalPenaltyRate )

Verified 2026-08-03, re-verification due 2027-08-03

Death waives the HSA 20 percent additional tax Out of scope

• IRC 223(f)(4)(B)
• IRC 223(f)(8)(A)
• IRC 223(f)(8)(B)(i)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: annualHsaPenaltyEvaluation.ts ( evaluateAnnualHsaPenalty )

Verified 2026-09-07, re-verification due 2027-09-07

Death-year spouse election retains the decedent’s unsatisfied RMD Settled

Interpretation and scope: The election-year owner planner emits zero spouse-owner requirement in the decedent death year and leaves beneficiary forced-distribution suppression off, preserving the unsatisfied decedent RMD. The death-year describeRule block in simulate.spousalElectionYearOwnerRmd.test.ts distinguishes the 5000 decedent residual from an incorrectly substituted spouse-owner amount. A structured zero owner obligation is distinct from the decedent requirement; chronological transaction-tax limitations remain disclosed. No validation success is asserted.

• Treas. Reg. 1.408-8(c)(3)

Tested by: simulate.inheritedRegimeExecution.test.ts (same-calendar-year treat-as-own election) : “E6b S2 same-year flip: keeps the decedent year-of-death RMD and suppresses owner RMD” , “S2 post-election: SEPP distributes from the flipped account” , “blocks scheduled contributions to an inherited Roth” , “E7: refuses an unestablished estate schedule without a fabricated legacy distribution” , “E8: keeps voluntary inherited-traditional draws out of the forced-only distribution total” , “E9: preserves the two-field legacy amounts at three annual Single Life walk-back points” , “E10: enters owner RMD rules at the S2 identity flip after a synthetic refusal” , “E11 K1: voluntary inherited Roth draws stay outside the beneficiary owned-Roth ordering pool” , “P5: emits successor-scope evidence and stops forcing after the beneficiary dies” , “P6: marks the R1 relief-year amount notice-waived for non-execution” , “P7: stamps pre-horizon year-of-death RMD limitation on the legacy refusal path” , “consumes one shared 60 basis across two 100 mandatory draws and survives annual replay” , “mandatory and voluntary inherited Roth withdrawals consume the same annual basis pool” , “preserves known qualified clocks with unknown basis without inventing ordinary income”

Tested by: simulate.spousalElectionYearOwnerRmd.test.ts (death-year election production) : “death-year election keeps 5000 decedent residual and publishes spouse-owner RMD 0”

Implemented in: annualForcedDistributionQcdAndRetirementActionsPhase.ts ( annualForcedDistributionQcdAndRetirementActionsPhase ) ; annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; annualOwnedAccountDrawsPhase.ts ( planElectionYearOwnerRmdDraws ) ; simulate.ts ( simulatePlan ) ; accountEligibility.ts ( isTreatAsOwnEffective ) ; inheritedIra.ts ( classifyInheritedRegime )

Verified 2026-08-25, re-verification due 2027-08-25

Deceased-spousal unused exclusion requires a timely estate-tax-return election Out of scope

Interpretation and scope: The statute and the regulation share one absence surface: model/plan.ts has no Form 706, DSUE amount, or portability-election field, and neither tax/federalTax.ts nor projection/compare.ts computes estate tax. compare.ts's heirTax remains an assumed heir income-tax haircut, which is not a portable unused exclusion and does not become one when a spouse dies in the projection. The timely-filing mechanics of Treas. Reg. 20.2010-2(a) and (a)(1) are folded here rather than split from 2010(c)(5)(A). The $15,000,000 basic exclusion itself is irc-2010-c-3-basic-exclusion-amount-not-modeled.

• IRC 2010(c)(5)(A)
• Treas. Reg. 20.2010-2(a)
• Treas. Reg. 20.2010-2(a)(1)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( planSchema )

Verified 2026-08-27, re-verification due 2027-08-27

Deducted state and local taxes are an AMT add-back Settled

Interpretation and scope: The add-back is the amount actually deducted, so the 164(b)(6) cap applies first and the AMT add-back is the capped figure rather than the taxes paid. Two refinements are unmodelled. 56(b)(1)(B) substitutes qualified housing interest for qualified residence interest, which can make part of a deducted mortgage interest amount an AMT add-back where the loan was not used to acquire, construct, or substantially improve the residence. And the final sentence of 56(b)(1)(A) preserves taxes allowable in computing adjusted gross income, which never arises in this engine because it deducts no above-the-line taxes.

• IRC 56(b)(1)(A)
• IRC 56(b)(1)(B)

Tested by: federalTax.test.ts : “adds back capped state and local taxes but leaves charitable gifts alone”

Implemented in: federalTax.ts ( computeFederalTax )

Verified 2026-08-03, re-verification due 2027-08-03

Deferral of the first required minimum distribution to April 1 Settled

Interpretation and scope: Paying in the attainment year is always permitted under Treas. Reg. 1.401(a)(9)-5(a)(3); the remaining engineering choice is only the default when no election is supplied. The engine defaults to attempting the first-year payment in the attainment year—when fully funded, the whole requirement is booked there—and requires an explicit opt-in for the whole-deferral April 1 path rather than inventing a household preference. Capacity-constrained default first-year payment and any unpaid remainder carried to the April 1 deadline year are registered at treas-reg-54-4974-1-f-first-year-rbd-excise-tax, without settling income recognition on that path here. The settled claim stops at the fully funded default and the clean elected path; an intervening attainment-year distribution is not part of either fixture.

• IRC 401(a)(9)(C)(i)
• Treas. Reg. 1.401(a)(9)-5(a)(3)

Tested by: rmdAndInherited.approximation.test.ts (default books attainment-year without election) : “books the first-year amount in the attainment year when no deferral is elected” , “leaves the following year carrying one distribution rather than two under the default”

Tested by: rmdAndInherited.approximation.test.ts (clean elected owned-IRA April 1 deferral) : “holds the owned-IRA first-year amount until the following receipt year when elected”

Implemented in: annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; simulate.ts ( simulatePlan ) ; rmd.ts ( requiredMinimumDistribution )

Verified 2026-08-27, re-verification due 2027-08-27

Delayed retirement credits accrue at 2/3 of 1 percent and stop at 70 Settled

Interpretation and scope: The 2/3 of 1 percent rate applies to individuals born after 1 January 1943; earlier cohorts have lower rates that the engine does not model, because a person reaching full retirement age in a projected year is necessarily in the later group.

• 20 CFR 404.313(a), (b)(2)

Tested by: benefitFactor.test.ts : “stops crediting at age seventy however long the delay”

Implemented in: benefitFactor.ts ( delayedRetirementFactor ) ; claimFactor.ts ( claimFactor )

Verified 2026-08-04, re-verification due 2027-08-04

Designated Roth employer account has no lifetime RMD after 2023 Settled

• IRC 402A(d)(5)(A)
• IRC 402A, Editorial Notes, Effective Date of 2022 Amendment (SECURE 2.0 Act § 325(b)(1))

Tested by: rmdShortfallExcise.test.ts (living designated Roth employer-account owner past the ordinary RMD age) : “never creates a lifetime §4974 obligation for a living designated Roth account owner”

Implemented in: annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; simulate.ts ( simulatePlan ) ; accountEligibility.ts ( followsOwnerRmds )

Verified 2026-08-26, re-verification due 2027-08-26

Disability waives the 10 percent additional tax, not the income Settled

Interpretation and scope: The statutory test is any substantial gainful activity, which is materially stricter than an occupation-specific disability determination of the kind a private policy uses. Section 72(m)(7) also requires the individual to furnish proof in such form and manner as the Secretary may require, which is why the engine takes a dated attestation with an evidence id rather than inferring disability from plan data.

• IRC 72(t)(2)(A)(iii)
• IRC 72(m)(7)

Tested by: ownedNonRothIraPenaltyPrerequisite.test.ts : “keeps the distribution in income while waiving the additional tax” , “keeps employer taxable treatment while waiving the additional tax”

Implemented in: ownedNonRothIraPenaltyPrerequisite.ts ( evaluateOwnedNonRothIraPenaltyPrerequisites ) ; traditionalEmployerPlanPenaltyPrerequisite.ts ( evaluateTraditionalEmployerPlanPenaltyPrerequisite )

Verified 2026-08-04, re-verification due 2027-08-04

Disabled-worker Medicare continuation after trial work is not modeled Out of scope

Interpretation and scope: This is an input and result boundary, not a cash-benefit TWP/EPE trim. socialSecurityIncomeSchema carries only disability.onsetAge; annualSocialSecurity.ts prices an annual SSDI cash stream. disability.ts#inSsdiWindow and ssdiSuspendedBySga remain cash-benefit enforcers and are not Medicare-continuation determinations. assertSsdiMedicareContinuationNotDeterminedFromCashBenefitFacts enumerates the missing Part A facts and the 93-month authority floor. A generic healthcare expense cannot invent an entitlement interval. Do not add 36 months of EPE to another 93.

• 42 U.S.C. 426(b)
• SSA POMS DI 28055.001
• SSA Red Book, Extended Medicare Coverage (SSDI only)
• SSA Red Book, Extended Medicare Coverage (SSDI only), When does this start?

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( socialSecurityIncomeSchema ) ; disability.ts ( assertSsdiMedicareContinuationNotDeterminedFromCashBenefitFacts )

Verified 2026-09-12, re-verification due 2027-09-12

Distributions satisfy the RMD in the order they occur Settled

Interpretation and scope: The consequence the engine must honour is derived rather than stated: because the RMD is satisfied in the order distributions actually occur, an ordinary withdrawal taken before a QCD in the same year irrevocably consumes RMD dollars, and the later QCD cannot retroactively displace it or make it nontaxable. No IRS pronouncement states that negative proposition directly; it follows from combining 1.408-8(b)(3) with 1.408-8(g)(1), and is uniform practitioner understanding. Note the annual-aggregation rule of 408(d)(2) does not extend here - that provision governs basis recovery under section 72, not RMD satisfaction, and an engine reasoning from it alone would wrongly conclude the ordering is irrelevant.

• Treas. Reg. 1.408-8(b)(3)
• Treas. Reg. 1.408-8(g)(1)
• IRS Notice 2007-7, Q&A-42

Tested by: annualQcdPhysicalExecution.test.ts : “caps RMD satisfaction at the exact opening RMD remaining”

Implemented in: annualQcdPhysicalExecution.ts ( stageAnnualQcdPhysicalExecution )

Verified 2026-08-04, re-verification due 2027-08-04

Dollar cap on the charitable deduction of a taxpayer who does not itemize Settled

Interpretation and scope: The engine hard-codes $1,000 and $2,000 while the codified text quoted below reads "not in excess of 1,000 ($2,000 in the case of a joint return)", with no currency symbol on the first figure. That is a compilation artifact, not a reading: Pub. L. 119-21 section 70424(a) substituted "$1,000 ($2,000" for "$300 ($600" as a single quoted fragment, and the Office of the Law Revision Counsel reports it that way in its own amendment note, which is the second authority below. The engine takes the enacted figure. The other trap here is the predecessor: this subsection carried $300 ($600 joint) for 2021 under the CARES-era rule, and code or test data ported from that era is wrong by a factor of more than three in the taxpayer’s disfavour.

• IRC 170(p)
• IRC 170(p), Editorial Notes, Amendments, 2025
• Pub. L. 119-21, sec. 70424(b) (OBBBA)

Tested by: charitableAndSection68.approximation.test.ts (a gift far above the cap, with percentage-ceiling capacity to spare) : “claims the statutory cap and not the CARES-era figure” , “adds the capped amount to the standard deduction rather than replacing it” , “doubles the cap on a joint return and only there” , “loses the excess over the cap outright, because 170(p) is not a carryover rule”

Implemented in: annualQcdStandardSection170pLedger.ts ( stageAnnualQcdStandardSection170pLedger ) ; annualCharitableDeductionParameters.ts ( annualCharitableDeductionParameters )

Verified 2026-08-04, re-verification due 2027-08-04

EDB ten-year election automatic waiver has stated conditions Settled

• Treas. Reg. 54.4974-1(g)(2)

Tested by: rmdShortfallExcise.test.ts (each independently modeled automatic-waiver condition) : “requires the EDB, default-life-expectancy, ninth-year-election, and Commissioner conditions”

Implemented in: simulate.ts ( simulatePlan ) ; rmdShortfallExcise.ts ( automaticWaiverReason )

Verified 2026-08-25, re-verification due 2027-08-25

Each year's indexed earnings are rounded to the nearer penny Approximated

Interpretation and scope: A 1962-06-15 worker with 2020 earnings of 55,628.60 (that year's AWI) and 2023 earnings of 44.88, last year 2023, indexes 2020 to 63,795.13 and leaves 2023 nominal. Authority AIME is floor((63,795.13 + 44.88) / 420) = floor(63,840.01 / 420) = 152. The annual whole-dollar floor yields 63,795 + 44.88 = 63,839.88 and observably 151. Using unindexed nominals instead predicts floor((55,628.60 + 44.88) / 420) = 132. A lower or higher Social Security benefit can alter taxable benefits or the tax character of replacement withdrawals, so the taxpayer-tax sign varies.

• 42 U.S.C. 415(b)(3)(A)
• 42 U.S.C. 415(b)(3)(B)
• 20 CFR 404.211(d)(3)
• 42 U.S.C. 415(b)(1)
• 42 U.S.C. 415(e)(2)
• 20 CFR 404.211(f)

Tested by: socialSecurityEarnings.approximation.test.ts (2020 AWI year plus 2023 cents) : “floors the indexed 2020 year to a whole dollar and drops AIME from 152 to 151”

Implemented in: piaFromEarnings.ts ( computePiaFromEarnings , indexCoveredEarnings )

Verified 2026-09-04, re-verification due 2027-09-04

Education savings-bond interest exclusion is limited by qualified expenses and modified AGI Out of scope

Interpretation and scope: The absence surface is model/plan.ts and tax/federalTax.ts: the Plan has no qualified savings-bond redemption or education-expense vocabulary, and the federal calculator has no section 135 exclusion line. Generic taxable interest and one-time income cannot be relabeled as bond interest used for a qualifying student without inventing the required redemption, expense, and MAGI facts.

• IRC 135(a)
• IRC 135(b)(1)(A)
• IRC 135(b)(1)(B)
• IRC 135(b)(2)(A)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( taxableAccountSchema ) ; federalTax.ts ( computeFederalTax )

Verified 2026-08-27, re-verification due 2027-08-27

Elected first-year deferral ignores attainment-year IRA distributions Approximated

• IRC 401(a)(9)(C)(i)
• Treas. Reg. 1.401(a)(9)-5(a)(3)
• Treas. Reg. 1.408-8(b)(3)

Tested by: rmdAndInherited.approximation.test.ts (elected deferral with attainment-year IRA income) : “defers the full first-year amount even after an attainment-year IRA draw”

Implemented in: annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

Eligibility tests that gate the principal-residence exclusion Approximated

• IRC 121(a)
• IRC 121(b)(2)(A)
• IRC 121(b)(3)
• IRC 121(b)(5)(A) and (B)
• IRC 121(b)(5)(C)(i)
• IRC 121(b)(5)(C)(ii)

Tested by: annuityAndProperty.approximation.test.ts (a seller who fails the two-year test entirely) : “excludes the whole gain from a sale that qualifies for nothing” , “takes no input by which any eligibility test could be expressed”

Tested by: annuityAndProperty.approximation.test.ts (gain allocated to periods of nonqualified use after 2008) : “excludes the nonqualified-use share along with the rest”

Implemented in: missingDataBasis.ts ( missingDataBasis ) ; simulate.ts ( simulatePlan ) ; propertySale.ts ( propertySaleTax )

Verified 2026-09-08, re-verification due 2027-09-08

Eligible designated beneficiary escapes the 10-year rule Approximated

• IRC 401(a)(9)(E)(ii)
• IRC 401(a)(9)(H)(ii)
• IRC 401(a)(9)(E)(iii)

Tested by: rmdAndInherited.approximation.test.ts : “empties an eligible designated beneficiary's account in the tenth year” , “requires nothing inside the window that the life-expectancy rule would require”

Implemented in: annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan ) ; inheritedIra.ts ( classifyInheritedRegime , inheritedRequirementForYear )

Verified 2026-08-03, re-verification due 2027-08-03

Employer contributions are subject to section 411 vesting maxima Out of scope

Interpretation and scope: A projected account balance is not evidence that each underlying employer contribution is vested. model/plan.test.ts gates the absence of vesting schedule and service fields, and actions/contract.test.ts gates the absence of a vesting action or certification.

• IRC 411(a)(2)(B)(i)
• IRC 411(a)(2)(B)(ii)
• IRC 411(a)(2)(B)(iii)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( traditionalAccountSchema )

Verified 2026-09-07, re-verification due 2027-09-07

Employer plan-contribution deduction is a sponsor-side limit Out of scope

Interpretation and scope: IRC 404(a)'s general deduction gate and 404(a)(3)(A)(i)'s amount limit both address the same absent employer-return surface, so they are deliberately one record rather than two non-dispositive fragments. Household wages and a configured employer match are participant-side facts the Plan does carry; they neither identify the sponsor nor make a sponsor deduction calculation reachable.

• IRC 404(a)
• IRC 404(a)(3)(A)(i)
• IRC 404(a)(3)(A)(i)(I)
• IRC 404(a)(3)(A)(i)(II)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( traditionalAccountSchema )

Verified 2026-08-27, re-verification due 2027-08-27

Employer-plan SEPP must begin after separation from service Settled

• IRC 72(t)(3)(B)
• IRC 72(e)(5)(D)(ii), (II)-(III)

Tested by: traditionalEmployerPlanPenaltyPrerequisite.test.ts : “does not apply the employer-plan SEPP exception when the series starts before separation” , “keeps the employer-plan SEPP assessment provisional when the series begins after separation”

Implemented in: traditionalEmployerPlanPenaltyPrerequisite.ts ( evaluateTraditionalEmployerPlanPenaltyPrerequisite , seppSeriesBeginsAfterSeparation )

Verified 2026-09-07, re-verification due 2027-09-07

Employer-plan SEPP separation modelled from the plan retirement age Approximated

Interpretation and scope: Registered as approximated rather than settled for the same reason as the Rule of 55 proxy alongside it: the plan model carries one retirement age per person and no employment history, so there is no separation date and no employer for the plan to test. It errs in both directions. It under-refuses where the employer plan is one the participant left long ago, because the statute reaches only the plan of the employer separated from and no employer identity is tested. It under-refuses again inside the year of separation, because the projection resolves years rather than days and cannot see a series that began in March from a job left in September; the first year the wage model stops paying the participant is treated as a separated year throughout, which is the same convention that lets the Rule of 55 waive the penalty in that year. Both layers name that year by rounding the retirement age UP to an attained age, which is not a rounding preference but the only reading that agrees with the other two: wages are paid while attained age is below the retirement age and the Rule of 55 waives from the first attained age that is not, so a retirement age of 65.5 is paid for the year the participant attains 65 and separated from the year they attain 66. Rounding down would separate them in a year the plan still pays them wages. It over-refuses where a participant has genuinely separated but the plan states no retirement age, which is how the plan model spells someone with no wages to stop. The exact-date reading lives in actions/traditionalEmployerPlanPenaltyPrerequisite.ts, and both layers order the two events through the same seppSeriesBeginsAfterSeparation predicate. What is not a proxy is the structural limit: 72(t)(3)(B) does not reach individual retirement accounts, and the projection tests separation only for an account of employer kind.

• IRC 72(t)(3)(B)

Tested by: seppHsaAndCharacter.approximation.test.ts (separated participant whose plan states no retirement age) : “refuses the series because no retirement age stands in for the separation” , “pays the same series the moment a retirement age is stated, on facts 72(t)(3)(B) does not mention”

Tested by: seppHsaAndCharacter.approximation.test.ts (still-paid participant past a stated retirement age) : “excepts an employer-plan series for a participant the wage model is still paying”

Implemented in: annualRetirementPhysicalEventInventory.ts ( buildAnnualRetirementPhysicalEventInventory ) ; annualSeppDistributions.ts ( annualSeppDistributions ) ; simulate.ts ( simulatePlan )

Verified 2026-08-04, re-verification due 2027-08-04

Employer-plan after-tax basis comes out pro rata, not first Settled

Interpretation and scope: The statute supplies the investment-to-account-balance ratio and is silent on rounding. Exact bigint nearest-cent half-up is the engine currency convention; the exact-cent fixture lands on whole cents independently of that rounding. The penalty-side validator recomputes that same ratio against an already-accepted characterization; it does not adjudicate external qualification.

• IRC 72(e)(8)(B)
• IRC 72(e)(8)(A)

Tested by: traditionalEmployerPlanWithdrawalCharacter.test.ts : “recovers basis in the investment-to-account-balance ratio” , “leaves a distribution smaller than the basis partly taxable”

Implemented in: traditionalEmployerPlanPenaltyPrerequisite.ts ( characterCoverage ) ; traditionalEmployerPlanWithdrawalCharacter.ts ( classifyTraditionalEmployerPlanWithdrawal )

Verified 2026-08-04, re-verification due 2027-08-04

Employer-plan distributions are taxable in the year received Settled

• IRC 402(a)

Tested by: simulate.rmd-roth.test.ts (April 1 first-RMD deferral receipt-year income) : “books the deferred employer-plan RMD as ordinary income in the following receipt year”

Implemented in: annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

Employer-plan employee-contribution mega-backdoor Roth path is not modeled Out of scope

Interpretation and scope: The IRA-only nondeductibleBasis field is intentionally not an employer-plan after-tax contribution record: model/plan.ts rejects it on an employer traditional account. The employer-account schemas retain neither a separate employee-contribution/basis pool nor the plan permission and distribution facts that select a route. model/plan.test.ts pins that schema vocabulary, and actions/contract.test.ts pins the absence of a corresponding action from both request unions. The existing Notice 2014-54 record remains narrower: it covers allocation of an already-expressible simultaneous employer-plan disbursement to multiple destinations, not the absent source and feature facts here.

• IRC 401(m)(3)(A)
• IRC 402(c)(1)(A)-(B)
• IRC 402A(c)(4)(E)(i)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( traditionalAccountSchema ) ; accountEligibility.ts ( evaluateConversion )

Verified 2026-08-26, re-verification due 2027-08-26

Equity-compensation execution is not universally ordinary income at execution Approximated

Interpretation and scope: DEFECT — no behavior change in this registration slice. actions/execution.ts emits fullyTaxableCompensationAtExecution with ordinaryIncomeAmount equal to the whole executed amount. One structured fixture drives both alreadyVested and sameYearCliff readings, exercised by two preserved observation tests. The alreadyVested test derives a zero section 83(a) compensation amount in the later execution year while the engine classifies the whole 75-dollar execution as ordinary income (overstates tax). The sameYearCliff test stipulates a zero-basis cliff vesting 100 dollars in the execution year with only 75 executed: section 83(a) includes the full 100 of vested value, but the executor reports ordinary income only on the executed 75 (understates tax). Both signs are pinned until a separately authorized implementation fix changes them.

• IRC 61(a)(1)
• IRC 83(a)

Tested by: execution.test.ts (already-vested and same-year cliff partial execution) : “classifies an already-vested equity execution as ordinary income anyway” , “reports ordinary income only on the executed part of a same-year cliff vest”

Implemented in: execution.ts ( executeOrdinaryWithdrawals ) ; plan.ts ( equityCompAccountSchema )

Verified 2026-08-26, re-verification due 2027-08-26

Events that modify a series are not detected by the engine Out of scope

• IRS Notice 2022-6, section 3.02(e)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: ownedNonRothIraSeppAnnualReconciliation.ts ( reconcileOwnedNonRothIraSeppAnnualSchedule ) ; ownedNonRothIraSeppCurrentPaymentCandidate.ts ( validateOwnedNonRothIraSeppCurrentPaymentCandidate )

Verified 2026-08-04, re-verification due 2027-08-04

Excess earnings are charged to calendar months, not annual benefit fractions Approximated

Interpretation and scope: The annual earnings amount itself is implemented by the existing `usc-42-403-f-3-retirement-earnings-test` record. This distinct convention record covers its missing month-charging unit: annualSocialSecurity.ts neither carries an ordered sequence of monthly entitlements nor consumes excess earnings against that sequence. In the companion fixture each below-FRA working year's 2,000 dollars of excess earnings must charge a 1,400-dollar first month and a 600-dollar second month, two partial-or-full deduction months per year; the annual ratio rounds to one per year, and the observed post-FRA benefit is 17,300 dollars against the statute-derived 17,800. This record and `poms-rs-00615-482-arf-crediting-months` share a single engine observable (the annualized month count feeds the ARF), so their fixtures intentionally pin the same produced figure from distinct legal limbs. A charging-only implementation could not be verified apart from the ARF credit with this observable — reclassifying either record requires a distinct charging observable (ordered months or unequal monthly entitlements).

• 42 U.S.C. 403(f)(1)

Tested by: simulate.social-security.test.ts (shares the ARF observable) : “collapses the charging sequence into the annual ratio”

Implemented in: annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

Excise tax on a required minimum distribution shortfall Settled

Interpretation and scope: The law fixes the arithmetic, applicable-plan restriction, correction-window endpoints, and relief fact patterns. Three implementation choices remain. First, ordinary employer plans fail closed per account; only an account explicitly classified as a 403(b) joins the owner’s other explicit 403(b)s. Second, inherited IRAs join only when the Plan carries the same explicit decedentId; absent identity fails closed per account, because matching birth/death facts cannot prove one decedent. Third, correction and waiver inputs are evidence, not money movements. The §4974 calculator therefore cannot manufacture a distribution, tax character, or cash flow: callers model the corrective distribution separately in the year received and use the evidence seam only to price the original excise. That separation keeps the chapter 43 tax out of MAGI and prevents a correction from silently satisfying a current-year RMD while proposed §1.401(a)(9)-5(g)(2)(iv) remains reserved in the final regulations.

• IRC 4974(a)
• IRC 4974(e)(1)
• IRC 4974(d)
• Treas. Reg. 54.4974-1(a)(2)(iii)
• Treas. Reg. 54.4974-1(e)
• Treas. Reg. 54.4974-1(f)
• Treas. Reg. 54.4974-1(h)
• Former Treas. Reg. 54.4974-2 Q&A-6, April 1, 2023 edition
• Treas. Reg. 54.4974-1(g)(2)
• Treas. Reg. 54.4974-1(g)(3)
• 2025 Instructions for Form 5329, Part IX

Tested by: rmdShortfallExcise.test.ts : “applies 25 percent to required minus timely distributed” , “requires the corrective distribution and the reflecting return inside the window” , “uses the earliest statutory correction-window endpoint” , “does not turn a waiver request or denial into a grant” , “uses zero only for an explicit modeled grant” , “requires the entire remaining benefit after the emptying year and prices the excise on the shortfall”

Tested by: rmdAndInherited.approximation.test.ts : “charges 25 percent when the whole required amount goes undistributed”

Implemented in: annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; simulate.ts ( simulatePlan ) ; rmdApplicablePlanForAccount.ts ( rmdApplicablePlanForAccount ) ; rmdShortfallExcise.ts ( computeRmdShortfallExcise )

Verified 2026-09-09, re-verification due 2027-09-09

Exclusion ratio for a non-qualified annuity, and the cap at unrecovered investment Settled

Interpretation and scope: Table V rather than Table I is the correct table because Tables V through VIII govern any contract whose investment includes post-June-1986 money, which is every contract a plan under this engine could be buying. The distinction is load-bearing and not cosmetic: at age 66 the Table I male multiple is 14.4 and the Table V multiple is 19.2, a difference of about a third in the expected return and therefore in the ratio.

• IRC 72(b)(1)
• IRC 72(b)(2)
• Treas. Reg. 1.72-5(a)(1)
• Treas. Reg. 1.72-9

Tested by: guaranteedIncomeEstate.test.ts : “taxes each payment net of the ratio fixed at the annuity starting date”

Tested by: guaranteedIncomeEstate.test.ts : “taxes the whole payment once the investment in the contract is recovered”

Implemented in: year2026.ts ( year2026 ) ; index.ts ( annuityExpectedReturnMultiple ) ; annuityForms.ts ( annuityExclusionMultiple ) ; annualAnnuityPurchaseFunding.ts ( annualAnnuityPurchaseFunding ) ; annualPensionAndAnnuityIncome.ts ( annualPensionAndAnnuityIncome ) ; simulate.ts ( simulatePlan )

Verified 2026-08-03, re-verification due 2027-08-03

Exhausting the account is not a modification Out of scope

• IRS Notice 2022-6, section 3.03(a)

Refusal tested by: ownedNonRothIraSeppAnnualReconciliation.test.ts : “refuses the depleted year rather than preserving the series” , “gives depletion and underpayment the identical refusal, which is why the notice cannot be applied” , “reconciles only when the caller restates the schedule as the reduced payment”

Implemented in: ownedNonRothIraSeppAnnualReconciliation.ts ( reconcileOwnedNonRothIraSeppAnnualSchedule )

Verified 2026-08-04, re-verification due 2027-08-04

Expected return for a joint and survivor annuity paying a reduced survivor amount Approximated

• Treas. Reg. 1.72-5(b)(2)
• Treas. Reg. 1.72-5(b)(2), Example 2

Tested by: annuityAndProperty.approximation.test.ts : “the accepted figure is Example 2 arithmetic, not a number chosen here” , “understates the expected return prescribed by Table VI” , “varies by sex, which a unisex Table VI cannot do”

Implemented in: mortality.ts ( jointLastSurvivorExpectancy ) ; annuityForms.ts ( annuityExclusionMultiple ) ; annualPensionAndAnnuityIncome.ts ( annualPensionAndAnnuityIncome )

Verified 2026-08-03, re-verification due 2027-08-03

Expedited reinstatement is available within 60 months of work termination Out of scope

Interpretation and scope: A `disability.onsetAge` is a prospective worker-SSDI switch, not a terminated-entitlement history or a medical finding. Treating a new onset age as a reinstatement would invent all of the facts that distinguish EXR from a new application. The annual SGA suspension is not EXR workflow and must not be presented as one.

• 20 CFR 404.1592b

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( socialSecurityIncomeSchema )

Verified 2026-08-27, re-verification due 2027-08-27

First distribution calendar year is the year the applicable age is attained Settled

• IRC 401(a)(9)(C)(i)
• Treas. Reg. 1.401(a)(9)-5(a)(2)(ii)
• Treas. Reg. 1.401(a)(9)-5(a)(3)

Tested by: rmd.test.ts : “recognises the first required distribution in the attainment year”

Implemented in: index.ts ( rmdStartAgeForBirthYear ) ; annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; rmd.ts ( requiredMinimumDistribution )

Verified 2026-08-03, re-verification due 2027-08-03

First-year RMD shortfall is taxed in the year containing its April 1 deadline Settled

• Treas. Reg. 54.4974-1(f)
• Treas. Reg. 54.4974-1(h)
• Former Treas. Reg. 54.4974-2 Q&A-6, April 1, 2023 edition

Tested by: rmdShortfallExcise.test.ts (April 1 excise in the deadline year) : “covers explicit deferral, no-option whole/partial miss, and rejects attainment-year excise”

Implemented in: annualOwnerRmdPlan.ts ( annualOwnerRmdPlan )

Verified 2026-09-06, re-verification due 2027-09-06

Five-year 529 front-loading uses the annual gift exclusion, which is not computed Out of scope

Interpretation and scope: Authority pin only. Runtime remains unmodeled gift tax; this record does not invent a 529 gift-tax calculator. Shares the 2026 $19,000 annual amount with irc-2503-b-annual-gift-exclusion-not-modeled.

• Revenue Procedure 2025-32 section 4.42(1)
• Instructions for Form 709 (2025), Contributions to Qualified Tuition Plans or Programs
• IRC 529(c)(2)(B)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( planSchema ) ; year2026.ts ( year2026 ) ; types.ts ( ParameterPack )

Verified 2026-09-12, re-verification due 2027-01-10

Five-year deadline carries the remaining interest as its RMD Out of scope

Interpretation and scope: Deadline-year limb for unknown-classification refusals. Confirmed schedules and post-deadline remaining-benefit enforcement are sibling settled helpers; do not levy 100% excise on the original deadline balance.

• Treas. Reg. 54.4974-1(c)(1)
• Treas. Reg. 54.4974-1(c)(2)
• IRC 401(a)(9)(B)(ii)

Refusal tested by: inheritedRegime.test.ts (the five-year deadline amount, not the modeled ten-year sweep) : “never reaches a five-year deadline, because the classes that would use it are refused” , “produces the ten-year deadline, and only the ten-year deadline, for the class it does model”

Implemented in: plan.ts ( inheritedBeneficiarySchema ) ; annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan ) ; inheritedIra.ts ( classifyInheritedRegime )

Verified 2026-08-25, re-verification due 2027-08-25

Five-year recapture on a conversion layer tapped early Settled

Interpretation and scope: Each conversion runs its own clock, because 408A(d)(3)(F)(i)(II) begins the period with the taxable year of that contribution and not with the year the Roth was opened. That is why the layers are held separately and drawn oldest first, and it is why this record is distinct from the account-level five-year period in irc-408A-d-2-roth-qualified-distribution: one decides whether earnings are taxable, this one decides whether already-taxed conversion principal carries the additional tax. Two things about the surrounding code so this is not read as broader than it is. The period is counted in calendar years, which is exact for the calendar-year taxpayers the engine models and would not be for a fiscal-year taxpayer it does not. And the recapture lifts through the 72(t) exceptions themselves, so the 59.5 boundary applies to it; the engine uses its attained-age-60 proxy for that boundary, recorded under irc-408A-d-2-roth-qualified-distribution.

• IRC 408A(d)(3)(F)(i)
• IRC 408A(d)(3)(F)(ii)
• IRC 408A(d)(3)(C)

Tested by: rothBasis.test.ts : “recaptures only so much of the conversion as was includible at the time” , “applies 72(t) without taxing the conversion principal a second time” , “runs the five-taxable-year period from the year of that conversion”

Implemented in: simulate.ts ( simulatePlan ) ; rothBasis.ts ( ROTH_SEASONING_YEARS , splitRothWithdrawal )

Verified 2026-08-03, re-verification due 2027-08-03

Floor-disallowed amounts carry forward only from a year with an excess Settled

• IRC 170(d)(1)(C)(i)
• JCT, General Explanation of P.L. 119-21 (JCS-1-26)
• IRC 170, Editorial Notes, Effective Date of 2025 Amendment, Pub. L. 119-21, sec. 70425(c)

Tested by: annualQcdItemizedSection170Ledger.test.ts : “permanently loses the floor amount when no excess exists to increase” , “refuses to deny the carryforward in a year that does have an excess”

Implemented in: annualQcdItemizedSection170Ledger.ts ( stageAnnualQcdItemizedSection170Ledger )

Verified 2026-09-05, re-verification due 2027-09-05

Form 8606 keeps ordinary distributions and Roth conversions in separate totals Settled

• Instructions for Form 8606 (2025), Line 7
• Instructions for Form 8606 (2025), Line 8

Tested by: ownedNonRothIraAnnualPhysicalTransaction.test.ts (ordinary distribution and Roth conversion use separate annual lines) : “stages a conversion onto line 8 rather than folding it into line 7”

Implemented in: annualQcdResidualForm8606.ts ( stageAnnualQcdResidualForm8606 ) ; annualRetirementPhysicalEventInventory.ts ( buildAnnualRetirementPhysicalEventInventory ) ; beneficiaryTraditionalIraResidualRmdAnnualRefinalization.ts ( prepareBeneficiaryTraditionalIraResidualRmdAnnualRefinalization ) ; ownedNonRothIraAnnualPhysicalTransaction.ts ( preparePlanOwnedNonRothIraAnnualPhysicalTransaction )

Verified 2026-08-25, re-verification due 2027-08-25

General life-insurance death proceeds are excluded from gross income Settled

Interpretation and scope: Narrow registration of the practiced general death-proceeds path. annualPermanentLifeTransitions pays max(face, cash value) into the death-benefit channel; federal tax calculators do not treat that channel as ordinary income. Interest and excepted contracts remain out of scope.

• IRC 101(a)(1)
• IRS, Are proceeds paid under a life insurance contract taxable?

Tested by: insurance.test.ts : “pays the face amount on the insured death, income-tax-free” , “pays a single-person plan its benefit in the final year, into the estate” , “pays the benefit on a policy held by the last survivor” , “never pays less than the accumulated cash value” , “pays the benefit exactly once”

Implemented in: annualPermanentLifeTransitions.ts ( annualPermanentLifeTransitions ) ; simulate.ts ( simulatePlan )

Verified 2026-09-12, re-verification due 2027-09-12

Greater of the beneficiary and the employee remaining life expectancy Approximated

• Treas. Reg. 1.401(a)(9)-5(d)(1)(ii)
• Treas. Reg. 1.401(a)(9)-5(d)(3)(ii)

Tested by: rmdAndInherited.approximation.test.ts : “divides by the beneficiary expectancy where the employee expectancy is the greater”

Implemented in: plan.ts ( inheritedAccountSchema ) ; annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan ) ; applicableAge.ts ( applicableAgeAttainYears ) ; inheritedIra.ts ( inheritedRequirementForYear )

Verified 2026-08-04, re-verification due 2027-08-04

HECM maximum claim amount and MIP rates for HUD-validated openings Settled

Interpretation and scope: Case-assignment year owns the ceiling — do not inflate a future unpublished year. Test PLF 0.5 is a stipulated input. Update 18 supports monthly division and remittance capitalization, not a guessed ordering of an arbitrary same-month advance. simulatePlan opens the loan through hecmLineOpeningsWithHudValidation and prices supported annual assessment evidence through priceHecmHudMipAssessmentYear. simulate.hecmHudProduction.test.ts distinguishes closing cash already received from modeled closing proceeds and verifies capitalized monthly MIP; the opening-adapter tests preserve quoted versus HUD-table-verified PLF provenance and refuse unverified inputs. Missing assessment timing or unsupported transaction facts remain incomplete rather than an exact HUD result. The hecmLineState adapter keeps servicer-observed balances separate from accepted modeled draws, so later observed balances do not erase modeled debt. The annual growth estimate for modeled draws and the estimated baseline growth when servicing timing is incomplete are simulator planning conventions outside this settled monthly-assessment claim; their presence does not establish a complete HUD servicing result.

• HUD Mortgagee Letter 2025-22, HECM Maximum Claim Amount Limits
• HUD Mortgagee Letter 2017-12, Initial and Annual MIP Rates
• HUD Handbook 4000.1 Update 18, II.A.1.b.3.b.ii, Annual Mortgage Insurance Premium
• HUD Handbook 4000.1 Update 18, III.A.2.a.v(B)(C), Calculation of Monthly Mortgage Insurance Premium
• HUD Handbook 4000.1 Update 18, III.A.2.a.v(C)(3)(c)(ii), Standard

Tested by: hecmHudValidated.test.ts : “caps MCA at the 2026 ceiling and distinguishes case assignment from closing” , “includes every verified closing-day financed amount in opening debt (H4)” , “refuses to turn a case year into a missing closing date or invalid closing evidence” , “uses appraisal below the ceiling and retains typed invalid/unsupported controls” , “keeps simple annual pre-timing arithmetic distinct from invalid input”

Implemented in: year2026.ts ( year2026 ) ; hecm.ts ( accrueHecmAnnualMip ) ; hecmHudValidated.ts ( computeHecmHudValidatedOpening , priceHecmMonthlyMipFromOutstandingBalances ) ; hecmHudValidatedOpeningAdapter.ts ( hecmLineOpeningsWithHudValidation , priceHecmHudMipAssessmentYear ) ; hecmLineOpenings.ts ( hecmLineOpenings ) ; simulate.ts ( simulatePlan )

Verified 2026-09-12, re-verification due 2027-01-10

HSA age-65 waiver modelled as a whole attained-age year Approximated

Interpretation and scope: This proxy errs in one direction only, which is the reason it is worth setting beside the age-59.5 proxy rather than dismissing the two together as a single rounding habit. Attained age here is the calendar-year age, the projection year minus the birth year, so the waiver switches on at January 1 of the year the account beneficiary turns 65 while the statute switches it on the day after the 65th birthday. The proxy is therefore never late and always early, so it under-penalizes: by one day at a January 1 birth, and by nearly a full year at a December 31 birth, where a non-qualified distribution taken in January bears nothing under the proxy and 20 percent of the includible amount under the statute. The age-59.5 proxy registered as irc-72-t-2-A-i-age-59-half-annual-proxy does not behave this way. The half-year offset there puts the statutory boundary on either side of the calendar boundary depending on the birth month, so that one errs both ways and is bounded by about six months each way, and assuming the two proxies share a sign gets the HSA exposure wrong. The exact-date reading is registered as irc-223-f-4-hsa-age-65-boundary and implemented in actions/annualHsaPenaltyEvaluation.ts, so here too two reachable paths disagree about the same account beneficiary and only the exact-date path is filing-relevant.

• IRC 223(f)(4)(C)
• IRC 223(f)(4)(A)
• Instructions for Form 8889, line 17b

Tested by: accountEligibility.approximation.test.ts (December birthday — the whole year before the 65th birthday) : “places the 65th birthday at 2027-12-31, so no 2027 distribution is after it” , “waives the non-qualified penalty from attained age 65, not from the day after the birthday” , “charges nothing on the projected 2027 draw, which the statute penalizes in full” , “does charge the statutory rate in 2026, where the two readings agree”

Implemented in: accountEligibility.ts ( hsaNonQualifiedPenaltyRate )

Verified 2026-09-07, re-verification due 2027-09-07

HSA coverage tier, monthly proration, and Medicare entitlement Approximated

Interpretation and scope: The projection applies three shortcuts, and the direction of error depends on which shortcut dominates. Monthly eligibility is not modelled: the annual ledger applies the whole-year limit regardless of how many months the taxpayer was an eligible individual, which is permissive when eligibility is partial. Medicare entitlement is not modelled: the Plan carries no title XVIII entitlement fact, and calendar age does not establish entitlement, so a taxpayer the authority facts treat as Medicare-entitled still receives a positive limit the statute sets at zero once entitlement begins — again permissive. Coverage tier is not modelled either: household size substitutes for the HDHP election, and paragraph (5) division then halves the family base across two MFJ spouses even when the authority facts stipulate self-only coverage with only one HSA owner; in the 2026 MFJ one-owner fixture that yields $4,375 produced versus the $4,400 self-only statute reading. Eligible months and Medicare entitlement are source-side facts absent from the plan schema, not derivable from the dates the engine already holds. The three stipulated fixtures span both directions: omitted monthly proration and Medicare zeroing permit excess contributions, while the household-size proxy with spousal division permits less than the self-only limit in the two-person case. Superseded claim: this record previously said the ledger gives every owner in a two-person household a full family limit; 223(b)(5) division is now implemented in irc-223-b-5-hsa-family-limit-divided-between-spouses, and this record documents what the annual coverage shortcut still gets wrong.

• IRC 223(b)(2)(B)
• IRC 223(b)(7)
• IRC 223(b)(1)
• IRC 223(b)(2)(A)

Tested by: hsaLimitAndQcdOffset.approximation.test.ts (coverage tier, monthly proration, and Medicare entitlement) : “allows self-only base plus age-55 catch-up when Medicare entitlement is source-side stipulated, not inferred from age 73” , “caps one MFJ HSA owner at half the family base ($4,375) when self-only coverage is source-side stipulated” , “applies the whole self-only annual limit ($4,400) despite six eligible months being source-side stipulated”

Implemented in: plan.ts ( hsaAccountSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-09-07, re-verification due 2027-01-05

HSA disability waives the additional tax, not the inclusion Settled

Interpretation and scope: The section 223(f)(1) qualified-medical exclusion sits in the same subsection and does remove inclusion, which makes the two easy to conflate. Section 72(m)(7) also requires the individual to furnish proof in such form and manner as the Secretary may require, which is why the engine models this as dated attestation evidence rather than inferring disability from plan data.

• IRC 223(f)(4)(A)
• IRC 223(f)(4)(B)
• IRC 72(m)(7)

Tested by: annualHsaPenaltyEvaluation.test.ts : “keeps the distribution in income while waiving the additional tax”

Implemented in: annualHsaPenaltyEvaluation.ts ( evaluateSegment )

Verified 2026-08-03, re-verification due 2027-08-03

High MAGI phases the SALT limitation down to no less than $10,000 Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. A research bot's 2026-08-26 change alert surfaced the OBBBA MAGI phasedown, and review verified that `saltCapForYear(pack, year)` takes only a pack and year while `itemizedTotal` applies that result without the phasedown. The calculator does compute MAGI for other rules, but neither function carries it into the SALT limitation. The fixture pins the current full-cap result until a separately authorized implementation fix changes it.

• IRC 164(b)(6)(B)
• IRC 164(b)(7)(A)
• IRC 164(b)(7)(B)(i)
• IRC 164(b)(7)(B)(ii)
• IRC 164(b)(7)(B)(ii)(II)-(III)
• IRC 164(b)(7)(B)(iii)
• IRC 164(b)(7)(B)(iv)

Tested by: federalTax.test.ts (2026 MAGI $705,000 reaches the $10,000 SALT floor; mid-phase locks 30%) : “keeps the full scheduled cap rather than applying the high-MAGI floor” , “keeps the full scheduled cap mid-phase rather than the 30% reduction” , “understates tax compared with the itemized return using the statutory floor”

Implemented in: federalTax.ts ( itemizedTotal , saltCapForYear )

Verified 2026-08-26, re-verification due 2027-01-23

High-earner employer-plan catch-up must be designated Roth in 2026 and later Settled

Interpretation and scope: The wage figure the engine compares to the threshold is a user-entered prior-calendar-year FICA amount on the employer account, not a Form W-2 Box 3 retrieved per sponsoring employer; that input gap is registered separately at irc-414-v-7-A-prior-year-fica-wage-proxy. Roth capability is inferred from the presence of a Roth employer account for the same owner, because the plan model has no employer identity and no qualified-Roth-contribution-program flag. Catch-up redirected onto that sibling remains elective deferral of the source plan for employer match. SEP and SIMPLE IRA are the IRA kind and never enter this allocator. Regular (non-catch-up) elective deferrals keep the account type the plan already states. Named-arm RMD coordination and the age-70½ proxy are outside this record. Desired incremental requests are not historical evidence — prior YTD amounts are the sibling prior-offset record.

• IRC 414(v)(7)(A)
• IRC 414(v)(7)(C)
• IRC 414(v)(6)(A)(iv)
• Notice 2025-67, section on the Roth catch-up wage threshold
• T.D. 10033, 26 CFR 1.414(v)-2(b)(2)
• T.D. 10033, DATES / Applicability Dates
• T.D. 10033, preamble on FICA wages and self-employment

Tested by: employerRothCatchUp.test.ts (exactly 150,000 is not over the threshold) : “leaves the catch-up pre-tax when prior-year FICA equals 150,000”

Tested by: employerRothCatchUp.test.ts (150,000.01 forces the catch-up slice into Roth) : “recharacterizes the age-50 catch-up as designated Roth one cent over the threshold”

Tested by: employerRothCatchUp.test.ts (ages 60-63 super catch-up is the same 414(v) dollars) : “Roth-mandates the 11,250 super catch-up at age 62, not only 8,000”

Tested by: employerRothCatchUp.test.ts (zero prior FICA is not subject) : “leaves the catch-up pre-tax when prior-year FICA is zero”

Tested by: employerRothCatchUp.test.ts (no Roth feature zeroes the high-earner catch-up) : “drops the catch-up rather than keeping it pre-tax when there is no Roth employer account”

Tested by: employerRothCatchUp.test.ts (2026 is statute plus good-faith, not delayed to 2027) : “applies the Roth mandate in 2026 rather than waiting for T.D. 10033 applicability”

Tested by: employerRothCatchUp.test.ts (IRA catch-up is not recharacterized) : “does not recharacterize an IRA catch-up when the employer wage test is met”

Tested by: employerRothCatchUp.test.ts (redirected catch-up stays elective deferral for match) : “applies the source match formula to the redirected catch-up”

Implemented in: year2026.ts ( year2026 ) ; employerRothCatchUp.ts ( allocateEmployerElectiveDeferrals , highEarnerRothCatchUpMandated ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-19, re-verification due 2027-08-19

IRMAA MAGI tax-exempt-interest addback Settled

• 42 U.S.C. 1395r(i)(4)(A)
• 42 U.S.C. 1395r(i)(4)(A)(ii)

Tested by: simulate.healthcare.test.ts : “carries known tax-exempt interest into later IRMAA MAGI without taxing it as ordinary income”

Implemented in: annualFundingApplicationAndClosePhase.ts ( annualFundingApplicationAndClosePhase ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

IRMAA MAGI without-regard addback is omitted from the lookback feed Approximated

Interpretation and scope: Matches the shipped usc-42-1395r-* premium-direction pattern: understatesTax names fisc exposure that includes the Medicare premium surcharge (the type’s fisc referent already spans that channel; the statement’s premium understatement is the same sign).

• 42 U.S.C. 1395r(i)(4)(A)(i)

Tested by: simulate.healthcare.test.ts (foreign-exclusion addback raises ACA MAGI but not IRMAA magiHistory) : “raises ACA household MAGI by the known foreign-exclusion addback without moving IRMAA MAGI history”

Implemented in: annualFundingApplicationAndClosePhase.ts ( annualFundingApplicationAndClosePhase ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

IRMAA life-changing-event evidence and redetermination request is not modeled Out of scope

Interpretation and scope: Keep outOfScope because the remaining claim is genuinely an absent administrative redetermination-request surface, not a mispriced MAGI. The planning toggles and min lookback are accepted Plan/annualHealthcareExpenses behavior already disclosed on the sibling lookback record; model/plan.ts and annualHealthcareExpenses.ts still have no fields or results for event-category evidence, supporting documentation, or a filed redetermination request under 418.1230. This record deliberately does not re-settle the SSA-44 lookback math.

• 20 CFR 418.1205
• 20 CFR 418.1230(a)
• POMS HI 01120.000, New Initial Determinations Using Beneficiary Information, table of contents
• POMS HI 01120.005 A

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( healthcareConfigSchema ) ; annualHealthcareExpenses.ts ( annualHealthcareExpenses ) ; simulate.ts ( simulatePlan ) ; medicare.ts ( medicareAnnualPremiumPerPerson )

Verified 2026-09-12, re-verification due 2027-09-12

IRMAA raises the beneficiary share of cost from 25 percent Settled

Interpretation and scope: The statute expresses the result as an adjustment amount, the applicable percentage minus 25 percentage points; the engine computes the whole premium as the standard one times the applicable percentage over 25. Those are the same quantity written from different ends, which is why no explicit 25-point subtraction appears in the code.

• 42 U.S.C. 1395r(i)(3)(A)
• 42 U.S.C. 1395r(i)(4)
• 42 U.S.C. 1395r(i)(3)(C)(i)(III)

Tested by: medicare.test.ts : “scales the standard premium by the applicable percentage over 25”

Implemented in: year2026.ts ( year2026 ) ; medicare.ts ( medicareAnnualPremiumPerPerson )

Verified 2026-09-07, re-verification due 2027-01-05

IRMAA uses modified AGI from the second preceding tax year Settled

Interpretation and scope: The quoted text is expressly subject to clause (ii) and subparagraph (C). The engine’s opt-in SSA-44 path (`expenses.healthcare.ssa44`) can select the more-recent year−1 MAGI after a qualifying event, but that (C) exception surface is a queued residual with no registry record of its own rather than a claim settled here.

• 42 U.S.C. 1395r(i)(4)(B)(i)

Tested by: simulate.healthcare.test.ts : “raises Medicare premiums two years after an income spike”

Implemented in: annualHealthcareExpenses.ts ( annualHealthcareExpenses ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

Individual capital-loss carryforwards continue into succeeding tax years Settled

Interpretation and scope: The plan stores one combined pool rather than separate short- and long-term carryovers. That missing character is already registered with the account-level lot and holding-period approximation (treas-reg-1-1012-1-c-lot-basis-and-holding-period). The section 1212(b)(2) adjusted-taxable-income limit on how much of a section 1211(b) allowance burns the carryforward pool in a zero-income year is registered separately. The describeRule fixture drives the pool through simulatePlan: annualFundingApplicationAndClosePhase applies the current-year producer and simulatePlan threads its returned pool into the next year.

• IRC 1212(b)(1)

Tested by: federalTax.test.ts : “threads the unabsorbed pool through simulatePlan into year-two capital-gains tax”

Implemented in: annualFundingApplicationAndClosePhase.ts ( annualFundingApplicationAndClosePhase ) ; simulate.ts ( simulatePlan ) ; federalTax.ts ( applyCapitalLossCarryforward )

Verified 2026-08-27, re-verification due 2027-08-27

Inherited IRA as a QCD source Out of scope

Interpretation and scope: The Form 8606 projection basis pool may honor an effective spouse treat-as-own election, folding an inherited source into the owner’s traditional IRA pool. QCD eligibility and the identity allocator still refuse inherited markers even when that election is effective. This narrower unsupported QCD path is not a legal bar; the cited authority still records inherited IRAs as eligible when the beneficiary has attained age 70½.

• IRS Notice 2007-7, Q&A-37
• IRS Publication 590-B, inherited IRA basis
• Treas. Reg. 1.408-8(e)(2)(i), owner-versus-beneficiary RMD aggregation

Refusal tested by: accountEligibility.test.ts : “refuses an inherited source rather than borrowing the donor own-IRA basis pool” , “does not mistake the inherited IRA for a non-IRA source” , “accepts the same request from the donor own IRA, so the refusal is the inherited fact” , “allocates an owned traditional IRA and blocks an inherited source as qcd-inherited-basis-unsupported” , “refuses an effective spouse treat-as-own inherited IRA at eligibility and identity allocation”

Implemented in: annualQcdExecutionPrerequisite.ts ( evaluateAnnualQcdExecutionPrerequisites ) ; annualQcdPhysicalExecution.ts ( stageAnnualQcdPhysicalExecution ) ; retirementActionCandidateIdentityAllocator.ts ( qcdSourceIssue ) ; ownedNonRothIraRuntimeSourceSeries.ts ( validateOwnedNonRothIraRuntimeSourceSeries ) ; accountEligibility.ts ( evaluateQcd )

Verified 2026-09-05, re-verification due 2027-09-05

Inherited Roth nonqualified earnings are ordinary income; death exception removes the 10% tax Settled

Interpretation and scope: Replaces disclosure-only residual once facts are supplied. Legacy plans without facts retain an explicit unsupported tax-character result.

• Treas. Reg. 1.408A-6 A-8(a)
• Treas. Reg. 1.408A-6 A-11
• Publication 590-B (2025), What Are Qualified Distributions?

Tested by: inheritedRothTaxCharacter.test.ts : “taxes only earnings on a nonqualified $50,000 distribution with $40,000 basis” , “produces $0 ordinary income once the inherited five-tax-year clock is met” , “consumes conversion layers FIFO after regular basis” , “consumes taxable conversion dollars first and preserves that remainder for spouse owner handoff” , “fails closed on unknown clock or basis rather than silent tax-free” , “establishes zero ordinary income from a known completed clock without inventing unknown basis” , “rejects invalid basis evidence rather than normalizing it” , “applies sequential depletion across two positive withdrawals from returned facts” , “hands remaining conversion layers to owner Roth basis on spouse owner treatment” , “refuses unknown regular basis or conversion layers before owner-basis mapping”

Implemented in: annualForcedDistributionQcdAndRetirementActionsPhase.ts ( annualForcedDistributionQcdAndRetirementActionsPhase ) ; annualFundingApplicationAndClosePhase.ts ( annualFundingApplicationAndClosePhase ) ; annualFundingCandidateEvaluation.ts ( annualFundingCandidateEvaluation ) ; annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; inheritedRothTaxCharacter.ts ( evaluateInheritedRothDistributionTaxCharacter ) ; inheritedRothTaxCharacterPoolState.ts ( applyInheritedRothDistributionToPool , initializeInheritedRothPoolState ) ; simulate.ts ( simulatePlan )

Verified 2026-09-12, re-verification due 2027-09-12

Inherited property generally takes date-of-death fair-market-value basis Approximated

Interpretation and scope: Approximated rather than out of scope because both surfaces produce figures the rule touches. compare.ts's after-tax estate treats taxable (and equity-comp) balances as stepped-up and untaxed to heirs, while simulate.ts leaves costBasis unchanged through a death year, so the surviving path can realize the pre-death embedded gain. One half understates heir tax relative to a no-step-up reading; the other overstates tax on a post-death sale relative to a consistent step-up. The companion fixture discriminates those readings through simulatePlan and summarizeProjection.

• IRC 1014(a)(1)
• Treas. Reg. 1.1014-1(a)

Tested by: federalTax.test.ts : “keeps original basis on a post-death taxable sale while the estate metric assumes step-up”

Implemented in: plan.ts ( taxableAccountSchema ) ; compare.ts ( summarizeProjection ) ; simulate.ts ( BalanceState )

Verified 2026-08-27, re-verification due 2027-08-27

Inherited-RMD transition relief ended after 2024 Settled

• Notice 2022-53, section IV.B
• Notice 2022-53, section IV.C
• Notice 2023-54, section V.B
• Notice 2023-54, section V.C
• Notice 2024-35, section IV.B
• Notice 2024-35, section IV.C
• Notice 2024-35, section I

Tested by: inheritedRegime.test.ts (annual R1 amount after the 2024 relief year) : “stops marking a post-RBD ten-year annual amount as notice-waived in 2025”

Implemented in: annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan ) ; inheritedIra.ts ( inheritedRequirementForYear )

Verified 2026-08-25, re-verification due 2027-08-25

Initial-computation AIME can include years outside the age-22-to-61 elapsed span Approximated

Interpretation and scope: A 1962-06-15 worker has first entitlement in 2029 at FRA 67 on the stream, which this helper projects out and treats as 2024 age-62 eligibility; indexing year 2022 AWI is 63,795.13. One three-cell fixture shares ten published-AWI years 2013-2022. Cell 1 adds 1983 (age 21, AWI 15,239.24) for authority AIME floor(11 × 63,795.13 / 420) = 1,670. Cell 2 adds explicit 2024 (age 62, pre-entitlement) at 42,000 unindexed for floor((10 × 63,795.13 + 42,000) / 420) = 1,618 and pins piaInputFromEarnings, which clamps lastEarningsYear to the age-61 year (2023) even when reported earnings include 2024. Cell 3 keeps last reported year 2023 with zero 2023 earnings and projects 42,000 through age 63 (only 2024), giving the same authority 1,618 while independently pinning computePiaFromEarnings, which iterates only 1984-2023 and ignores projected 2024 unless lastBaseYear is widened (mutation to 2028 yields 1,618 with projectedYearCount 1). Both clamps exclude age-21 and age-62 pre-entitlement earnings, so all three cells observably return 1,518. A competing lower-boundary-only reading includes 1983 but still ends at the year before 62, predicting 1,670, 1,518, 1,518. claimAge is expressible on the stream and unused by this helper. A lower or higher Social Security benefit can alter taxable benefits or the tax character of replacement withdrawals, so the taxpayer-tax sign varies.

• 42 U.S.C. 415(b)(2)(B)(ii)
• 42 U.S.C. 415(b)(2)(B)(iii)
• 42 U.S.C. 415(b)(2)(B)(i)
• 20 CFR 404.211(b)(2)
• 20 CFR 404.211(e)(1)

Tested by: socialSecurityEarnings.approximation.test.ts (three cells: age-21, explicit 2024, projected 2024 via throughAge63) : “omits age-21 and age-62 pre-entitlement years; three cells pin input clamp and compute loop independently”

Implemented in: piaFromEarnings.ts ( computePiaFromEarnings , piaInputFromEarnings )

Verified 2026-09-04, re-verification due 2027-09-04

Interest on federal obligations is outside every state income tax base Settled

Interpretation and scope: This is why the exemption is applied uniformly rather than per state pack: it is federal law binding every state, so no state entry can opt into taxing it. The engine subtracts the interest from the state base because it arrives inside ordinary income.

• 31 U.S.C. 3124(a)

Tested by: stateTax.test.ts : “keeps federal obligation interest out of the state base”

Implemented in: stateTax.ts ( computeStateTaxableIncome )

Verified 2026-08-03, re-verification due 2027-08-03

Interest rate ceiling for the fixed amortization and fixed annuitization methods Settled

Interpretation and scope: The authority fixes a ceiling, not a rate, so the engine had to pick one. It carries no section 1274(d) federal mid-term rate series, and 5 percent is the highest rate permitted without knowing that rate, so a flat 5 percent needs no feed and can never exceed the ceiling. A projection wanting a larger payment would have to source the mid-term rate for one of the two months immediately preceding the month the series begins. The engine source comment used to describe the ceiling as 120 percent of the mid-term rate, which is the superseded Rev. Rul. 2002-62 rule rather than the Notice 2022-6 rule; it was corrected to state both legs when this record was verified.

• IRS Notice 2022-6, section 3.02(c)
• IRS Notice 2022-6, section 2.06
• IRS Notice 2022-6, sections 4 and 5

Tested by: sepp.test.ts : “uses the 5% floor of the ceiling, which no rate environment can breach” , “prices the series above what the superseded 120% ceiling would allow” , “defaults to the ceiling floor rather than requiring a rate argument”

Implemented in: sepp.ts ( SEPP_AMORTIZATION_RATE_PCT )

Verified 2026-08-04, re-verification due 2027-08-04

Itemizing is an election; the section 151 deduction is additive Settled

Interpretation and scope: Nothing in section 63 requires the election to be the one that minimises tax; the engine assumes the taxpayer elects to itemize exactly when the itemized total exceeds the standard deduction, and compares against the standard deduction alone because the senior deduction is common to both branches. That assumption can be wrong in two directions the engine does not explore. Itemizing state and local taxes creates an AMT add-back that the standard deduction branch also creates but at a different amount, so the larger deduction is not always the lower total tax. And because the senior deduction is not an itemized deduction, it also escapes the section 68 overall limitation, which only bites on the itemized side.

• IRC 63(e)(1)
• IRC 63(b)
• IRC 63(d)

Tested by: federalTax.test.ts : “itemizes when larger and adds the senior deduction on top”

Implemented in: federalTax.ts ( computeFederalTax )

Verified 2026-08-03, re-verification due 2027-08-03

Joint and Last Survivor Table divisor literals Settled

• Treas. Reg. 1.401(a)(9)-9(d), Table 3

Tested by: rmd.golden.test.ts (Table 3 row and column literals) : “uses the Treasury Table 3 literal for a qualifying younger spouse” , “uses the Treasury Table 3 literal below the Pub. 590-B age slice”

Implemented in: simulate.ts ( simulatePlan ) ; jointLifeTable.ts ( jointLifeTableDivisor ) ; rmd.ts ( requiredMinimumDistribution )

Verified 2026-08-25, re-verification due 2027-08-25

Joint and Last Survivor Table needs a spouse more than 10 years younger Settled

Interpretation and scope: The regulation measures the age gap between individuals; the engine compares ages attained in the calendar year, which is the granularity the projection runs at and can differ from the exact gap by under a year around a birthday.

• Treas. Reg. 1.401(a)(9)-5

Tested by: rmd.test.ts : “keeps a spouse exactly ten years younger on the Uniform Lifetime Table”

Implemented in: annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; jointLifeTable.ts ( jointLifeTableDivisor ) ; rmd.ts ( requiredMinimumDistribution )

Verified 2026-08-04, re-verification due 2027-08-04

Living-child SSDI auxiliary benefits are outside the Plan Out of scope

Interpretation and scope: Absence-record surface is model/plan.ts: `household.hasQualifyingDependent` is a tax-filing boolean, not a child identity, dependency, age, student, disability, or Social Security-benefit record. familyMaximum.ts therefore caps only a modeled current-spouse auxiliary and has no child allocation to price. No accepted Plan supplies the trigger facts for a living-child SSDI auxiliary.

• 42 U.S.C. 402(d)(2)
• 42 U.S.C. 403(a)(6)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( householdSchema )

Verified 2026-09-07, re-verification due 2027-09-07

Medical expense deduction above 7.5 percent of AGI Approximated

Interpretation and scope: This is the highest-value omission in the itemized set for this engine audience, because the deduction is largest exactly when income is drawn down to pay care costs. It also interacts with the itemize election: a year of heavy medical spending can flip a household from the standard deduction to itemizing, which the engine cannot see, so the error is not confined to households that already itemize. IRC 213(b), 213(d)(9), and 213(d)(10) are folded onto this record as input-granularity, not separate approximations: there is no drug, cosmetic, or LTC-premium tax input on which those filters could run. Omitting the whole deduction overstates tax whenever any qualifying medical remains after those filters; the filters never reverse the sign, because they only reduce the statutory deduction toward the engine's zero. The produced pin is the existing describeRule fixture (statute 124,000 versus engineOmitsMedicalEntirely 59,000). The annually restated 2026 attained-age caps live on the companion record irc-213-d-10-eligible-ltc-premium-caps-2026.

• IRC 213(a)
• IRC 67(b), (b)(5)
• IRC 67(h)
• IRC 213(b)
• IRC 213(d)(9)(A)
• IRC 213(d)(1), flush
• IRC 213(d)(10)(A)
• IRC 213(d)(10)(B)(i)

Tested by: federalTaxAndRothBasis.approximation.test.ts (deductible medical above the 7.5% floor for a household already itemizing) : “omits deductible medical expenses from the itemized total” , “ignores unreimbursed medical costs however they are supplied” , “reaches the statutory deduction only when the medical amount is smuggled in as another itemized dollar” , “overstates tax, by the deduction it cannot see at the marginal rate” , “cannot see the election flip a heavy medical year forces”

Implemented in: plan.ts ( itemizedDeductionsSchema ) ; federalTax.ts ( itemizedTotal )

Verified 2026-09-07, re-verification due 2027-09-07

Miscellaneous itemized deductions are permanently disallowed Settled

Interpretation and scope: The provision moved. OBBBA added a new 67(g) defining educator expenses and redesignated the former 67(g) suspension as 67(h), while striking the January 1, 2026 expiry, so a citation to 67(g) now points at the wrong subsection. The engine builds its itemized total from state and local taxes, mortgage interest, and charitable gifts only, and offers no input channel for advisory or preparation fees. That absence is the correct answer rather than a gap, which is why this rule is registered as settled rather than out of scope.

• IRC 67(h)
• IRC 67(b)
• Amendment note to IRC 67, P.L. 119-21 sec. 70110(a), (b)

Tested by: federalTax.test.ts : “offers no channel by which a miscellaneous itemized deduction is allowed”

Implemented in: federalTax.ts ( itemizedTotal )

Verified 2026-08-03, re-verification due 2027-08-03

Mortgage interest is limited to $750,000 of acquisition debt Approximated

Interpretation and scope: The error scales with the mortgage rather than with income: at $1.5 million of acquisition debt half the interest is disallowed, and a household paying $90,000 of interest would see $45,000 of deduction that does not exist. The grandfather in 163(h)(3)(F)(i)(IV) preserves the older $1,000,000 limit for debt incurred on or before December 15, 2017, so missing origination facts prevent applying any uniform flat-cap stand-in. Omitting the acquisition-debt limit while still deducting the supplied interest is the approximation: `itemizedTotal` emits a deduction that includes the full mortgage-interest figure rather than refusing to itemize or substituting a guessed ceiling.

• IRC 163(h)(3)(F)(i)
• IRC 163(h)(3)(B)(ii)

Tested by: federalTaxAndRothBasis.approximation.test.ts (interest on acquisition debt of $1.5M, twice the $750,000 limit) : “deducts the whole interest figure with no principal limit applied” , “ignores the acquisition-debt principal however it is supplied” , “understates tax against the return that respects the cap”

Implemented in: plan.ts ( itemizedDeductionsSchema ) ; federalTax.ts ( itemizedTotal )

Verified 2026-08-03, re-verification due 2027-08-03

NIIT and senior MAGI use different foreign-exclusion addbacks Approximated

Interpretation and scope: DISCLOSED APPROXIMATION. TaxYearInput carries a broad foreignExclusionAddback for section 151 senior MAGI and an optional niitSection911A1NetAddback for the NIIT threshold leg; omission of the narrow member reuses the broad amount. The fixture's established $20,000 earned-income and $10,000 housing exclusions have no allocable deductions, so the broad amount is $30,000 and the narrow NIIT net addback is $20,000. At $180,000 AGI and $10,000 included investment income, omitting the narrow input overstates NIIT by $380 (see sibling irc-1411-a-net-investment-income-tax for the 3.8% lesser-of and $200,000 single threshold). At $70,000 AGI the broad addback preserves the legally correct $4,500 senior deduction (see sibling irc-151-d-5-C-iii-I-senior-deduction-per-individual-phase-out for the $6,000 / 6% / $75,000 parameters); supplying the narrow amount for both rules would instead overstate that deduction to $5,100. The overstatesTax direction applies only to this characterized extra-housing omitted-narrow fallback; unknown, missing, or conflicting annual evidence does not establish a direction. The calculator accepts characterized amounts as inputs and does not determine exclusion eligibility or section 911(d)(6) allocation; this record does not certify a gross/net mapping for other compositions. Schedule 1-A's Form 2555 line 45 carrier is already net of line 44; the broad senior definition is not an instruction to add gross amounts or net them twice.

• IRC 1411(d)
• IRC 151(d)(5)(C)(iii)(II)
• Form 2555 (2025), page 3, lines 36 and 42 to 45
• Instructions for Form 8960 (2025), Part III, Line 13—MAGI, Section 911
• Schedule 1-A (Form 1040) (2025), Part I, lines 1 to 3

Tested by: federalTax.test.ts : “separates broad senior MAGI from narrow NIIT MAGI at computeFederalTax”

Implemented in: federalTax.ts ( computeFederalTax )

Verified 2026-09-05, re-verification due 2027-09-05

NUA in employer securities: distribution exclusion and sale treatment Out of scope

Interpretation and scope: The plan model carries an employer-plan balance only: traditionalAccountSchema's nondeductibleBasis is IRA-only, and the schema comment says employer-plan after-tax money is not modeled. After-tax employee basis exists only as runtime classifier evidence (afterTaxEmployeeBasisBeforeDistribution) on traditionalEmployerPlanWithdrawalCharacter, whose withdrawal character is basis return or ordinary income. The action contract rejects a NUA action kind. The action-kind refusal is covered in actions/contract.test.ts. Notice 98-24 now extends this record because its sale-side holding-period treatment is inseparable from the excluded NUA whose amount the Plan cannot state; it does not warrant a computed result or a separate record when the engine has neither the NUA/security facts nor the later sale facts.

• IRC 402(e)(4)(B)
• IRC 72(t)(1)
• IRS Notice 98-24, 1998-17 I.R.B.

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; traditionalEmployerPlanWithdrawalCharacter.ts ( classifyTraditionalEmployerPlanWithdrawal ) ; plan.ts ( traditionalAccountSchema )

Verified 2026-08-27, re-verification due 2027-08-27

Named QCD in a tax year with no sourced exclusion limit Out of scope

• IRC 408(d)(8)(A)
• IRC 408(d)(8)(G)
• IRS Notice 2025-67

Refusal tested by: annualQcdTaxCharacterPostPass.test.ts : “refuses the unsourced year instead of inflating the pack limit into it” , “produces the sourced limit for the pack year, so the refusal is the missing source and not the batch”

Implemented in: annualQcdTaxCharacterPostPass.ts ( stageAnnualQcdTaxCharacterPostPass ) ; annualForcedDistributionQcdAndRetirementActionsPhase.ts ( annualForcedDistributionQcdAndRetirementActionsPhase ) ; annualLegacyQcdGiftPlan.ts ( annualLegacyQcdGiftPlan )

Verified 2026-08-05, re-verification due 2026-12-03

Named QCD modelled as beyond the required distribution Approximated

Interpretation and scope: Direction of error: restrictive, by the amount of the required distribution the gift could have satisfied, and the balance sheet is drawn down by that same amount again. A donor with a $21,097 required distribution who schedules a $20,000 gift intends to give $20,000 out of the requirement and take $1,097 in cash: $1,097 of ordinary income and $21,097 out of the IRA. The projection distributes all $21,097 in cash first and then debits the gift separately: $21,097 of ordinary income and $41,097 out of the IRA. Ordinary income is overstated by the satisfiable amount and the IRA is understated by it, so the error compounds through every figure that reads either. The cause is ordering, not missing facts. The gift settles at phase rank 6 and the forced distributions at rank 3, and the ranks are themselves statutory: Treas. Reg. 1.408A-4 A-6(b) forbids a conversion from absorbing an unsatisfied requirement, which puts the gift ahead of the conversions, and 1.408-8(b)(3) satisfies the requirement in the order distributions actually occur, which is what makes an earlier cash distribution irrevocable. The retirement path is an RMD reserve: hold a scheduled same-year gift amount out of the forced cash distribution before rank 3 runs, which is the shape the plan already contemplates for conversion-linked withdrawals. Until it lands the executed record states the coordination truthfully rather than omitting it - `rmdSatisfiedAmount` is zero and the typed `coordination` field says the requirement had already been distributed before the gift.

• Treas. Reg. 1.408-8(g)(1)
• Treas. Reg. 1.408-8(b)(3)
• IRC 408(d)(8)(A)

Tested by: simulateContributionsAndQcd.approximation.test.ts (a scheduled gift cannot displace cash already distributed) : “taxes the whole required distribution beside an excluded gift”

Implemented in: annualQcdExecution.ts ( executeAnnualQcds ) ; simulate.ts ( simulatePlan )

Verified 2026-08-05, re-verification due 2027-08-05

Net capital gain stacks on top of ordinary taxable income Settled

Interpretation and scope: The statute frames the result as a ceiling -- the tax "shall not exceed" the sum of its components -- and enumerates the bands as offsets from the amount of taxable income otherwise taxed below 25 percent. The engine computes the bands directly from the ordinary taxable amount, which reaches the same figure for the rate schedule it models and is the reason the code carries no explicit 25 percent reference.

• IRC 1(h)(1)

Tested by: federalTax.test.ts : “measures the preferential bands from the top of ordinary income”

Implemented in: year2026.ts ( year2026 ) ; federalTax.ts ( capitalGainsTaxStacked )

Verified 2026-08-03, re-verification due 2026-12-01

Net investment income tax is the lesser of two amounts Settled

Interpretation and scope: The thresholds are not indexed, so this lesser-of record is static rather than annually indexed. This record settles only the 3.8 percent lesser-of calculation and fixed threshold selection once net investment income and MAGI are supplied. Construction of statutory IRC 1411(d) MAGI is a separate dependency on sibling `irc-1411-d-modified-agi-foreign-exclusion-addback` (classification approximated): the direct calculator accepts an optional narrow field for the NIIT threshold leg and reuses the broad amount as a compatibility approximation only when that narrow field is omitted; the broad field alone feeds senior MAGI. Effective from 2013 reflects statutory applicability; implementation verification uses the current 2026 parameter pack and does not certify other historical pack values or a complete historical return.

• Pub. L. 111-152, §1402(a)(4)
• IRC 1411(a)(1)
• IRC 1411(b)

Tested by: federalTax.test.ts : “taxes the smaller of investment income and the threshold excess”

Implemented in: year2026.ts ( year2026 ) ; federalTax.ts ( computeFederalTax )

Verified 2026-09-05, re-verification due 2027-09-05

New TIPS issues carry a one-eighth percent minimum coupon when auction yield is below 0.125% Settled

Interpretation and scope: The supported model applies the floor to interpolated par-yield proxies on synthetic rungs, not to actual Treasury auction award prices or full coupon-setting mechanics, and does not reset coupons on outstanding securities. Annual coupons, linear interpolation, and par-yields-as-spot pricing remain planning-grade conventions.

• 31 CFR 356.20(b), 87 FR 40438, 40440 (July 7, 2022), amendment 9

Tested by: ladderMath.test.ts : “floors synthetic rung coupons at the regulatory minimum for negative and positive sub-minimum curve yields across two payout rungs”

Implemented in: ladderMath.ts ( tipsCouponRatePct )

Verified 2026-09-05, re-verification due 2027-09-05

Non-designated beneficiary uses the five-year rule before the RBD Out of scope

Interpretation and scope: Unknown classification remains a typed refusal. Confirmed non-designated pre-RBD facts use the sibling settled schedule helper; do not pretend every trust is non-designated. inheritedRegime.test.ts and inheritedFiveYearAndPostDeadline.test.ts cover both limbs.

• IRC 401(a)(9)(E)(i)
• IRC 401(a)(9)(H)(i)
• IRC 401(a)(9)(B)(ii)
• Treas. Reg. 54.4974-1(c)(1)

Refusal tested by: inheritedRegime.test.ts (the non-designated-beneficiary classification itself) : “refuses a see-through trust alike, because the regime and not the trust test is unimplemented” , “classifies the same death for a designated individual, so the refusal is the beneficiary class”

Implemented in: plan.ts ( inheritedBeneficiarySchema ) ; annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan ) ; inheritedIra.ts ( classifyInheritedRegime )

Verified 2026-08-25, re-verification due 2027-08-25

Old-age computation years are elapsed years reduced by five, starting at 1951 Approximated

Interpretation and scope: A 1962-06-15 worker with official AWI in 1984-2023 except zeros in 1984, 1992, 2000, 2008, and 2016 has 35 positive years: 34 index to 63,795.13 and 2023 stays 66,621.80, so authority and the always-35 path both give floor((34 × 63,795.13 + 66,621.80) / 420) = 5,322. A 1928-06-15 worker with 1979-1988 AWI has 39 elapsed years 1951-1989 and 34 computation years: floor(10 × 19,334.04 / 408) = 473, while the engine still uses 35 years and observably 460. Dropping no years predicts floor(2,235,656.22 / 480) = 4,657 and floor(193,340.40 / 468) = 413. Dropping the first five calendar years of each elapsed span predicts 4,715 and 473. A lower or higher Social Security benefit can alter taxable benefits or the tax character of replacement withdrawals, so the taxpayer-tax sign varies.

• 42 U.S.C. 415(b)(2)(A), (b)(2)(A)(i)
• 42 U.S.C. 415(b)(2)(B)(i)
• 42 U.S.C. 415(b)(2)(B)(iii)
• 42 U.S.C. 415(b)(1)
• 20 CFR 404.211(e)(1)
• 20 CFR 404.211(e)(2)

Tested by: socialSecurityEarnings.approximation.test.ts (modern 35-year vs 1951-floor 34-year) : “uses 35 computation years even when elapsed years start at the 1951 floor”

Implemented in: piaFromEarnings.ts ( computePiaFromEarnings )

Verified 2026-09-04, re-verification due 2027-09-04

One-time split-interest entity QCD sublimit Out of scope

• IRS Notice 2025-67
• Instructions for Form 1040 (2025), line 4a/4b Exception 3

Refusal tested by: accountEligibility.test.ts : “requires the affirmative not-a-split-interest attestation the record describes” , “refuses a destination the request itself names as a split-interest entity” , “stays quiet on an ordinary public charity with the attestation given”

Implemented in: annualQcdExecutionPrerequisite.ts ( evaluateAnnualQcdExecutionPrerequisites ) ; accountEligibility.ts ( evaluateQcd )

Verified 2026-08-03, re-verification due 2026-12-01

One-time switch to the required minimum distribution method Out of scope

• IRS Notice 2022-6, section 3.03(b)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: ownedNonRothIraSeppCurrentPaymentCandidate.ts ( validateOwnedNonRothIraSeppCurrentPaymentCandidate ) ; plan.ts ( seppElectionSchema ) ; sepp.ts ( seppAnnualAmount )

Verified 2026-08-04, re-verification due 2027-08-04

Only a QLAC may sit outside the RMD account balance while its payments are deferred Settled

Interpretation and scope: THE TEST IS DERIVED, NOT DECLARED, which is what made the refusal cheap enough to be worth taking. A Plan carries the contract’s startAge, the purchase year and the owner’s date of birth, and that is everything the required beginning date needs: 1.401(a)(9)-2(b)(1) puts it at April 1 of the calendar year FOLLOWING the year the owner attains the applicable age, and the projection pays a contract twelve monthly amounts in the year the owner attains startAge, so the engine’s own model of commencement is January 1 of that year. The last permissible start is therefore the year the owner attains the applicable age plus one, and no new field is added. THE SECOND TERM, AND WHY IT IS NOT OPTIONAL. The bound above is the later of that year and the PURCHASE year. An owner who annuitizes at 80 passed their required beginning date years ago, so every contract they could buy commences after it; the first term alone would refuse the ordinary immediate annuity, which the regulation plainly allows and which this engine’s own Form 8606 fixtures are built on. What (a)(3)(i) forbids is using the annuity form to postpone distributions, and a contract paying from the year its premium is paid postpones nothing — the account was already distributing under the account rules and the contract takes over on purchase. A refusal stricter than its authority would not have been this rule. WHAT THE ACCEPTED READING ASSUMES, kept from the approximated version because it is still the load-bearing step. A contract failing 1.401(a)(9)-6(a)(3) is a qualification failure rather than a valuation rule, and the regulation does not spell out an arithmetic remedy; the reading taken is that a bifurcation the regulation does not permit does not happen. The alternative — that the value leaves the base anyway and the failure is the custodian’s problem — would make 1.401(a)(9)-5(b)(4) and 1.401(a)(9)-6(q)(1)(iii) do no work at all, since every deferred contract would already enjoy what the QLAC rules were written to grant. That is a reading which erases its own authority, which is why refusing the shape rather than pricing it is not a shortcut. HISTORY, APPENDED RATHER THAN DELETED. Until 2026-08-07 this record was classified approximated with errorDirection understatesTax, and it pinned these figures: a 76-year-old with a 1,000,000 dollar traditional IRA and a 0 percent return pays a 200,000 dollar qualified premium in 2026 for a contract whose payments start at age 85, nine years past the required beginning date and not declared a QLAC. The 2026 requirement was unaffected either way, resting on the prior December 31 balance; the 2027 requirement parted, the accepted reading leaving the contract in the base for 41,825.59 on 957,805.91 while the engine computed 33,091.96 on 757,805.91 — a shortfall of 8,733.62 in the second year alone, recurring and compounding. The same household with qlac: true produced the identical 33,091.96, which was the sharpest statement of the defect available: the engine had exactly one mechanism and could not tell a QLAC from a non-QLAC because it never had a second one. THE REMEDY AS THE RECORD STATED IT, AND WHAT WAS ACTUALLY BUILT. The approximated version offered a two-way choice and named no migration: "Either a contract value the RMD base can re-include when the contract is not a QLAC and its payments start after the required beginning date, or a plan-validation refusal of that combination. The second is much cheaper and loses only a shape the regulation does not permit anyway; neither is done here." The cheaper arm is the one taken. Extending it with a load-time repair and a projection warning is this slice’s design decision rather than something the record had registered: parse alone would have locked every household holding the old shape out of the plan the new message tells them to fix, and the repair discipline this repo settled on for the pension lump-sum election and the inherited-funded annuity premium is what that seam already exists for. THE REPAIR, AND WHY IT IS A STAND-DOWN. A stored document carrying the shape has its purchase cleared and its monthly amount zeroed, so the premium never leaves the funding balance and the contract pays nothing. Two other repairs were available and both are refused by the never-richer bar the load seam is under. Marking the contract a QLAC would confer precisely the grant the regulation withholds — the household never chose it, the relabel would keep the exclusion the refusal exists to remove, and it is not even safe on its own terms, since the premium would then be clamped to the statutory cap and a start past 85 would still fail (q)(1)(ii). Advancing the start age to the required beginning date would pay a monthly amount quoted for a deferred start across years nobody bought it for. The stand-down is the strictly poorer direction and it leaves the account in the plan, so the household can see what happened and re-author it either way. TWO CORRECTIONS ENTERED 2026-08-07 when the companion ceiling landed at treas-reg-1-401-a-9-6-q-1-ii-qlac-commences-by-the-85th-birthday, so that neither sentence above is read for more than it can carry. First, the aside that "a start past 85 would still fail (q)(1)(ii)" is true of every owner but one: (q)(1)(ii)’s deadline is the first day of the month after the 85th anniversary, which for a DECEMBER birthday falls on January 1 of the next calendar year, and the engine’s January-1 model of commencement puts a start age of 86 exactly on it. The ceiling is 85, and 86 for a December birth; the relabel argument is unaffected, because the ceiling is a ceiling either way. Second, the refusal message quoted here as an unconditional "lower Start age, or tick QLAC" is now conditional. Ticking the box is a real remedy only where the start age also clears the (q)(1)(ii) ceiling, so the message names it only then and otherwise says why it would not help — the same treatment the companion record’s message gives to unticking.

• Treas. Reg. 1.401(a)(9)-6(a)(3)(i)
• Treas. Reg. 1.401(a)(9)-5(a)(5)(iii)
• Treas. Reg. 1.401(a)(9)-6(q)(1)(iii)
• Treas. Reg. 1.408-8(a)(1)

Tested by: iraAnnuityCharacter.approximation.test.ts (a deferred contract that is not a QLAC) : “refuses a deferred contract that is not a QLAC” , “admits the same contract the moment it is declared a QLAC” , “admits an immediate contract bought after the required beginning date” , “leaves the requirement on the household that bought no contract untouched”

Implemented in: migrations.ts ( migratePlanToCurrent ) ; plan.ts ( latestNonQlacQualifiedAnnuityStartAge ) ; planCrossFieldChecks.ts ( checkAccountCrossFieldRules ) ; annualAnnuityPurchaseFunding.ts ( annualAnnuityPurchaseFunding ) ; simulate.ts ( simulatePlan )

Verified 2026-08-07, re-verification due 2027-08-07

Optional in-plan transfer of otherwise nondistributable amounts is not modeled Out of scope

Interpretation and scope: This is a schema boundary, not a conversion result. traditionalAccountSchema and rothAccountSchema record only an employer account kind and an optional plan class; neither records a particular employer-plan identity, an in-plan-Roth feature election, or the restriction carried by a transferred amount. retirementActionRequestSchema and the separately persisted request union have no in-plan transfer arm. The vocabulary gates are asserted in model/plan.test.ts and actions/contract.test.ts; named Roth conversions separately refuse an employer designated Roth destination in actions/rothConversionExecution.test.ts.

• IRC 402A(c)(4)(E)(i)
• IRC 402A(c)(4)(E)(ii)
• IRS Notice 2013-74, Q&A-3

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( rothAccountSchema , traditionalAccountSchema ) ; accountEligibility.ts ( evaluateConversion )

Verified 2026-08-26, re-verification due 2027-08-26

Order of the 0.5% floor and the percentage ceiling Settled

• IRC 170(b)(1)(I)
• IRC 170, Editorial Notes, Effective Date of 2025 Amendment, Pub. L. 119-21, sec. 70425(c)

Tested by: annualQcdItemizedSection170Ledger.test.ts (The rejected reading survived for a whole chain because the prior fixture returned the same number under both orderings.) : “claims the post-ceiling amount reduced by the floor”

Implemented in: annualQcdItemizedSection170Ledger.ts ( stageAnnualQcdItemizedSection170Ledger )

Verified 2026-09-05, re-verification due 2027-09-05

Order of the QCD taxable trim, the annual limit, and the deduction offset Settled

• IRC 408(d)(8)(A), both sentences
• IRC 408(d)(8)(B), flush sentence
• IRC 408(d)(8)(D)

Tested by: annualQcdTaxCharacterPostPass.test.ts (The 408(d)(8)(B) taxable trim runs before the annual limit, not after it.) : “limits what survives the taxable trim, not the gross distribution” , “reproduces the contract's $100,000-pool worked example”

Tested by: annualQcdTaxCharacterPostPass.test.ts (The post-70.5 offset reduces the already-limited amount, not the amount going into the limit.) : “subtracts the deduction offset after the annual limit has bound” , “floors the reduction at zero rather than going negative” , “reproduces the contract's fully-taxable worked example”

Implemented in: annualQcdTaxCharacterPostPass.ts ( stageAnnualQcdTaxCharacterPostPass ) ; annualLegacyQcdOwnerCharacterPlan.ts ( annualLegacyQcdOwnerCharacterPlan ) ; simulate.ts ( simulatePlan )

Verified 2026-08-04, re-verification due 2027-08-04

Ordinary nationwide April federal filing deadline with weekend and D.C. holiday adjustments Settled

Interpretation and scope: The helper returns the ordinary nationwide April date only. It does not apply return-filing extensions, disaster-relief postponements, or state-office statewide holiday adjustments under the second clause of IRC 7503. Integer tax years 2006 through 9998 are the engine's supported calendar scope for this arithmetic. Announcement 2007-16 demonstrates the 2006-return deadline under that calendar; it does not establish holiday enactment.

• IRC 6072(a)
• IRC 7503
• IRS Notice 2011-17
• IRS Announcement 2007-16

Tested by: ordinaryFederalFilingDeadline.test.ts : “moves the 2027 tax-year deadline past the Monday-observed Emancipation Day” , “covers an ordinary weekday, Friday-observed Saturday holiday, Monday holiday, and the 2006 floor” , “drives the post-candidate builder on the 2027 tax-year adjusted deadline”

Implemented in: ordinaryFederalFilingDeadline.ts ( ordinaryFederalFilingDeadline )

Verified 2026-09-04, re-verification due 2027-09-04

Ordinary rate schedule is marginal, and permanent after OBBBA Settled

Interpretation and scope: Two things about the 2026 tables are easy to get wrong from memory. First, the 37 percent bracket begins at the same figure for unmarried individuals and for heads of household ($640,600), while the married-filing-separately table diverges from the unmarried table only at the top, at $384,350. Second, OBBBA gave the boundaries of the 10 and 12 percent brackets one extra year of indexing by confining the 2017-base substitution in 1(j)(3)(B)(i) to brackets above 12 percent, so those two thresholds move on a different base than the rest of the table. The engine models only unmarried and married-filing-jointly, mapping every other status onto one of the two. The optimizer prices that same marginal schedule: bracketSegments supplies the widths and rates, buildOptimizerModel allocates taxable ordinary income across those convex segments, and federalTaxOn is the readout. That pricing is exact only for the taxable ordinary income supplied to the model; it does not certify section 86 inclusion, the deduction stack, AMT, or projection indexing as exact. optimizeSchedule is a caller of those functions, not a separate implementation of the table.

• IRC 1(j)(1)
• IRC 1(j)(2)(C)
• Amendment note to IRC 1, P.L. 119-21 sec. 70101(a)(1), (b)
• Rev. Proc. 2025-32, section 4.01, Table 3

Tested by: federalTax.test.ts : “taxes each bracket slice at its own rate”

Implemented in: year2026.ts ( year2026 ) ; optimizer.ts ( bracketSegments , buildOptimizerModel , federalTaxOn ) ; federalTax.ts ( bracketTax )

Verified 2026-08-03, re-verification due 2026-12-01

Ordinary widow nine-month duration, age-60, and remarriage gates, including currently unmarried after an intervening marriage ends Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. 20 CFR 404.335(e) starts from currently unmarried; a later marriage that has ended leaves the claimant unmarried and inside that lead-in. isWidowEligible instead rejects whenever remarriedAtAge is below 60, including when claimantIsSingle is true. Independently, isWidowEligible never reads claimantIsSingle, so a schema-valid coupled context with remarriedAtAge null still receives a candidate; a null remarriedAtAge lacks the facts of any 404.335(e) exception and does not prove a marriage before 60. maritalBenefits.test.ts already characterizes that coupled-null admission. The companion fixture holds the deceased at FRA so RIB-LIM and the survivor-FRA cohort error are not in play: 9-month ordinary, 8-month with no duration exception, remarried at 59 now single, remarried at 60 still married, the same 9-month no-remarriage facts at claimant age 59 and 60, then the same FRA-67 9-month facts with claimantIsSingle false and remarriedAtAge null where the worksheet current pre-60 marriage is projected out. The age-60 gate is the helper's own claimantAge test. The age-59 and age-60 cells use a direct helper contract (claimantClaimAge equal to claimantAge so the claim-age guard passes and age 59 is refused by isWidowEligible); a whole-plan stream claimAge is clamped to 62–70 and is outside this fixture. Fully-insured status, application (including the 404.335(b)(1) through (4) exceptions), and the 404.335(d) own-old-age-benefit restriction have no formerSpouse or stream fields and are not adjudicated here; the dual-entitlement offset is a pricing comparison elsewhere. The disabled-widow age-50 limb is `usc-42-402-e-1-b-ii-cfr-20-404-335-disabled-widow-age-50-prescribed-period`; the 9-month statutory exceptions are `cfr-20-404-335-a-widow-duration-exceptions`.

• 20 CFR 404.335
• 20 CFR 404.335(a)(1)
• 20 CFR 404.335(b)
• 20 CFR 404.335(c)
• 20 CFR 404.335(d)
• 20 CFR 404.335(e), (e)(1)
• 42 U.S.C. 402(e)(1)
• 42 U.S.C. 402(e)(1)(C)(i)
• 42 U.S.C. 402(e)(3)(A)
• 42 U.S.C. 402(e)(3)
• 42 U.S.C. 416(c)(1)(E)

Tested by: maritalBenefits.eligibility.test.ts : “pins the ordinary nine-month widow path, including currently-single after a pre-60 intervening marriage and coupled null remarriage timing”

Implemented in: maritalBenefits.ts ( isWidowEligible , passesModeledOrdinaryWidowRecordGates )

Verified 2026-09-04, re-verification due 2027-09-04

Overall limitation on itemized deductions Settled

Interpretation and scope: Publication 505 states the rate as 5.4 percent, which is a truncation of 2/37 (0.0540540...), not the rule. The engine computes the exact rational because the difference is roughly $5.41 per $100,000 of limitation base and this provision only bites at incomes where that is real money. Note also that the amended section has no exempt categories and no 80 percent cap, both features of the pre-2018 Pease rule, so logic ported from that era would carry forward carve-outs that no longer exist. The indexed thresholds are the starts of the 37 percent rows in Rev. Proc. 2025-32 section 4.01, quoted below. Its filing-status rows map directly to the parameter carrier: joint and surviving-spouse share one row, while head of household, unmarried individuals, and married filing separately each retain their own row. This preserves the same rate-table convention as irc-1-j-2-progressive-ordinary-rate-schedule while retaining every status-specific threshold required by section 68.

• IRC 68(a)
• IRC 68(b)
• Rev. Proc. 2025-32, section 4.01, Tables 1-4

Tested by: annualSection68ItemizedDeduction.test.ts : “reduces by the exact rational rather than the published 5.4 percent”

Tested by: charitableAndSection68.approximation.test.ts (the live projection path applies it) : “reduces the itemized total on the live path” , “leaves a household below the bracket threshold untouched” , “does not reach a year the limitation does not govern”

Implemented in: annualSection68ItemizedDeduction.ts ( buildAnnualSection68ItemizedDeductionEvidence ) ; annualCharitableDeductionParameters.ts ( annualCharitableDeductionParameters ) ; federalTax.ts ( section68Reduction )

Verified 2026-08-29, re-verification due 2026-12-27

Own retirement and survivor benefits combine to the higher amount, not both full amounts Settled

Interpretation and scope: The ledger publishes one Social Security amount rather than separate technical-entitlement components. That representation is valid for this rule because the statutory offset leaves the total equal to the larger amount; it must not be read as allowing both unreduced full benefits.

• 42 U.S.C. 402(k)(3)(A)
• SSA POMS RS 00615.301, § A.1

Tested by: simulate.social-security.test.ts : “steps the survivor up to the deceased spouse’s larger benefit without adding both” , “keeps the survivor’s own larger benefit when the deceased’s amount is smaller”

Implemented in: annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2027-08-26

Owned IRA ordinary distributions stage on Form 8606 line 7 Settled

• Form 8606 (2025), line 7

Tested by: ownedNonRothIraMovementCandidate.test.ts (executed owned-IRA withdrawals stage as line 7 distribution candidates) : “stages the executed withdrawal as a line-7 distribution candidate”

Implemented in: ownedNonRothIraMovementCandidate.ts ( stageOwnedNonRothIraOrdinaryWithdrawalMovements )

Verified 2026-08-29, re-verification due 2027-08-29

PLESA participant contributions stop at the indexed or sponsor-set lower cap Out of scope

Interpretation and scope: The cap turns on a PLESA-only participant-contribution balance and a sponsor-selected lower cap. Neither field exists on traditionalAccountSchema or rothAccountSchema, and there is no PLESA contribution action; model/plan.test.ts and actions/contract.test.ts explicitly gate those vocabulary surfaces. Notice 2024-22 confirms that the lower sponsor amount is an independent statutory limb, not an inferred account limit.

• IRC 402A(e)(3)(A)
• IRS Notice 2024-22, section II (Background)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( rothAccountSchema , traditionalAccountSchema )

Verified 2026-08-26, re-verification due 2026-11-24

Part B initial, general, and special enrollment periods are not modeled Out of scope

Interpretation and scope: Absence surface is model/plan.ts and projection/internal/annualHealthcareExpenses.ts: healthcareConfigSchema and person demographics have no IEP/GEP/SEP election or enrollment month, and annualHealthcareExpenses derives Medicare months solely from attained age 65 (and birth month in the attainment year). This record is the enrollment-period umbrella; the separate Part B late-enrollment premium increase is registered at usc-42-1395r-b-part-b-late-enrollment-penalty.

• 42 U.S.C. 1395p(d)
• 42 U.S.C. 1395p(e)
• 42 U.S.C. 1395p(i)(3)(A)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( healthcareConfigSchema ) ; annualHealthcareExpenses.ts ( annualHealthcareExpenses ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

Part B late-enrollment premium increase is not modeled Out of scope

Interpretation and scope: Absence surface is model/plan.ts, tax/medicare.ts, and the pack Medicare table: annualHealthcareExpenses starts Part B months from attained age 65 with no enrollment-election fact, and medicareAnnualPremiumPerPerson multiplies the pack standard premium by the IRMAA applicable-percentage scale only. A late-enrollee history is not expressible, so there is no mispriced penalty figure to approximate — only the absent increase.

• 42 U.S.C. 1395r(b)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( healthcareConfigSchema ) ; year2026.ts ( year2026 ) ; annualHealthcareExpenses.ts ( annualHealthcareExpenses ) ; simulate.ts ( simulatePlan ) ; medicare.ts ( medicareAnnualPremiumPerPerson )

Verified 2026-08-27, re-verification due 2027-08-27

Part D late-enrollment and drug-cost rules are not modeled Out of scope

Interpretation and scope: healthcareConfigSchema admits a generic medicareExtrasMonthlyPerPerson amount, but it is a user-entered aggregate expense rather than a Part D result. model/plan.ts has no accepted fields for uncovered months, a national base beneficiary premium, a PDP or MA-PD plan, drug claims, a covered insulin product, negotiated or maximum fair prices, or incurred cost sharing; simulate.ts consequently cannot derive a late penalty or product-level copayment. The CY 2026 $2,100 out-of-pocket threshold is a pack parameter sourced from CMS final instructions; runtime benefit design remains out of scope without claim inputs.

• 42 U.S.C. 1395w-113(b)(3)(A)-(B)
• 42 U.S.C. 1395w-113(b)(3)(B)
• P.L. 117-169, section 11201(a)(1)(A)
• P.L. 117-169, section 11201(a)(3)(B)(i)(III)
• CMS Final CY 2026 Part D Redesign Program Instructions, section 10 and appendix section 100
• P.L. 117-169, section 11406(a), adding 1860D-2(b)(9)(D)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( healthcareConfigSchema ) ; year2026.ts ( year2026 ) ; types.ts ( ParameterPack ) ; annualHealthcareExpenses.ts ( annualHealthcareExpenses ) ; simulate.ts ( simulatePlan )

Verified 2026-09-12, re-verification due 2027-01-10

Pension lump-sum direct-rollover eligibility is assumed Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. checkAccountCrossFieldRules requires an election to have an offer and an existing non-inherited traditional destination, and pensionTakeLumpSumPatch selects or creates an owned traditional IRA destination, but neither can establish that the source is a qualified trust, that the offer is an eligible rollover distribution, or that a plan may distribute it. pensionLumpSumRollovers then selects every elected offer in its election year at its full amount; simulatePlan credits that amount; and annualPensionAndAnnuityIncome suppresses the pension stream from that year forward. The approximation fixture uses a 300,000 offer for a 60-year-old, deliberately outside the RMD regime: facts the Plan cannot encode hide a genuinely nonqualifying or ineligible offer, for which the statutory reading is a 300,000 currently taxable pension distribution with no rollover credit, while the engine instead credits 300,000 to the traditional destination with zero pension income and MAGI. The RMD-specific sibling remains the only record for a qualifying offer whose required-distribution portion must be carved out.

• IRC 402(c)(1)
• IRC 402(c)(4)
• IRC 402(c)(8)(A)-(B)(i)
• IRC 401(a)(31)(A)
• IRC 402(e)(6)

Tested by: pensionRolloverEligibility.approximation.test.ts (hidden nonqualifying offer is currently taxable) : “credits the entire elected offer to the traditional destination with no current pension income or MAGI”

Implemented in: pensionElection.ts ( pensionTakeLumpSumPatch ) ; planCrossFieldChecks.ts ( checkAccountCrossFieldRules ) ; annualPensionAndAnnuityIncome.ts ( annualPensionAndAnnuityIncome ) ; pensionLumpSumRollovers.ts ( pensionLumpSumRollovers ) ; simulate.ts ( simulatePlan )

Verified 2026-09-04, re-verification due 2027-09-04

Pension, annuity and deferred income are not compensation for IRA purposes Settled

Interpretation and scope: This is what makes the compensation prong bite in a retirement projection. Most years in a plan have no wages at all, and a reading that counted any income as compensation would leave the section 219(b)(1) cap inert for exactly the span the projection is about.

• IRC 219(f)(1)

Tested by: simulate.contributions-growth.test.ts : “gives a retiree living on a pension no contribution room”

Implemented in: annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-29, re-verification due 2027-08-29

Post-70.5 deductible IRA contributions reduce the excludable QCD Settled

Interpretation and scope: The statute measures the offset against deductions allowed to the taxpayer, so it is an individual-level figure even on a joint return, and the engine tracks it per donor for that reason. The registered annual limit is likewise per taxpayer, which can read as though the two use different bases; they do not.

• IRC 408(d)(8)(A), flush sentence

Tested by: annualQcdTaxCharacterPostPass.test.ts : “nets the prior reductions off the aggregate deductions”

Implemented in: annualQcdActionExecutionEvidence.ts ( publishAnnualQcdActionExecutionEvidence ) ; annualQcdTaxCharacterPostPass.ts ( stageAnnualQcdTaxCharacterPostPass ) ; qcdDeductibleContributionOffset.ts ( applyIrc408d8AContributionOffset )

Verified 2026-08-03, re-verification due 2027-08-03

Post-deadline RMD is the entire remaining benefit, with ordinary 25%/10% excise on shortfall Settled

Interpretation and scope: Separate from irc-4974-rmd-shortfall-excise-tax percentage authority. Do not reuse the original deadline balance after it has been distributed. simulatePlan passes the inherited account completedDeadlineObservation through annualForcedDistributionQcdAndRetirementActionsPhase to annualInheritedIraDistributions and coordinateInheritedDeadlineAnnualRuntime. Completed observations produce the existing correction/waiver-aware excise obligation without replaying observed cash or ordinary income. simulate.inheritedRegimeExecution.test.ts distinguishes $2,500 ordinary excise from $1,000 after qualifying correction, and unknown or premature observations remain incomplete.

• Treas. Reg. 54.4974-1(e)
• Treas. Reg. 54.4974-1(a)

Tested by: inheritedFiveYearAndPostDeadline.test.ts : “returns a $10,000 entire-remaining-benefit obligation with no distribution” , “does not invent an obligation on an emptied opening balance after the deadline” , “refuses negative or nonfinite history instead of coercing to zero” , “prices shortfall through computeRmdShortfallExcise at 25% and 10% with complete facts”

Implemented in: beneficiaryTraditionalIraAnnualRuntimeCoordinator.ts ( coordinateInheritedDeadlineAnnualRuntime ) ; annualForcedDistributionQcdAndRetirementActionsPhase.ts ( annualForcedDistributionQcdAndRetirementActionsPhase ) ; annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan ) ; inheritedFiveYearAndPostDeadline.ts ( postDeadlineRemainingBenefitObligation )

Verified 2026-09-12, re-verification due 2027-09-12

Post-entitlement covered earnings can recompute a higher PIA Approximated

Interpretation and scope: simulate.ts has a real PIA-from-earnings path, so this is not an absence record: before projecting any year it resolves each Social Security stream's PIA once from `socialSecurityIncomeSchema.earnings` and optional pre-retirement `earningsProjection`. Later `wagesIncomeSchema` income is not appended to that history or recomputed. Closing 415(f)(2) also requires widening the base-year window in piaFromEarnings.ts (`computePiaFromEarnings` clamps `lastBaseYear` to eligibility-1), which is why that file stays in implementedBy. The companion fixture gives a fully insured worker ten AWI-level covered years (2013-2022), claims at 2029 FRA, and supplies 10,000 dollars of covered wages in 2030. The authority-side recomputation replaces a zero in the top-35 set: indexed earnings rise by 10,000, AIME from 1,518 to 1,542, and 2024 second-band PIA from 1,166.60 to 1,174.30 (delta 7.70, above the one-dollar threshold), so 2031 pays 14,091.60; the engine observably leaves the initially resolved 1,166.60 PIA in force and pays 13,999.20.

• 42 U.S.C. 415(a)(1)(A)(ii)
• 42 U.S.C. 415(a)(1)(A)
• 42 U.S.C. 415(b)(2)(A)(i)
• 42 U.S.C. 415(b)(2)(B)(i)
• 42 U.S.C. 415(b)(2)(B)(ii)
• 42 U.S.C. 415(f)(2)(A)
• 42 U.S.C. 415(f)(2)(C)
• 42 U.S.C. 415(f)(2)(D)(i)
• 42 U.S.C. 415(f)(4)
• 20 CFR 404.211(b)(2)
• 20 CFR 404.211(e)(2)

Tested by: simulate.social-security.test.ts : “does not recompute a higher PIA from post-FRA covered wages”

Implemented in: simulate.ts ( simulatePlan ) ; piaFromEarnings.ts ( computePiaFromEarnings )

Verified 2026-08-27, re-verification due 2027-08-27

Pre-1987 employee contributions are recovered before the pro-rata rule bites Approximated

Interpretation and scope: Approximated rather than out of scope because the engine applies the ordinary pro-rata rule and returns a number; it never refuses for want of the grandfathered layer. The direction is recorded as both because this is a timing error: tax is overstated in the early withdrawal years while basis the statute would return in full is instead spread across the account, and understated later as that basis comes out. It nets to zero over a full drawdown, but an annual projection is exactly where the year matters, and the overstated years are the ones a retiree is drawing on the account. Worth recording rather than dismissing as historical, because this engine audience is the cohort it reaches: a participant who made after-tax contributions to a plan that allowed in-service withdrawals in 1986 is in their late sixties or older today, and the balance has had forty years to grow, so the grandfathered layer can be large in dollars even where it is small as a fraction of the account. It is not modelled because the two facts it needs, the December 31, 1986 investment in the contract and whether the plan permitted pre-separation withdrawal on May 5, 1986, appear on no statement a household can produce and would have to come from the plan administrator.

• IRC 72(e)(8)(D)

Tested by: seppHsaAndCharacter.approximation.test.ts (ordinary income on a distribution inside the grandfathered layer) : “taxes four fifths of a distribution the statute returns whole” , “carries no pre-1987 layer and no May 5, 1986 plan-terms flag to carry one”

Implemented in: traditionalEmployerPlanWithdrawalCharacter.ts ( classifyTraditionalEmployerPlanWithdrawal )

Verified 2026-08-04, re-verification due 2027-08-04

Preferential capital gain rates survive into the AMT Settled

Interpretation and scope: The engine stacks the AMT preferential income on top of the AMT ordinary excess and applies the regular-tax breakpoints to that stack, which is the Form 6251 Part III construction. Two layers of 55(b)(3) are not modelled anywhere in this engine: the 25 percent layer for unrecaptured section 1250 gain in subparagraph (E) and, in the regular tax, the 28 percent collectibles rate. Both would raise tax, so their absence understates it for a taxpayer holding depreciated real property or collectibles.

• IRC 55(b)(3)
• IRC 55(a)

Tested by: federalTax.test.ts : “caps the tentative minimum tax on capital gain at the preferential rates”

Implemented in: federalTax.ts ( tentativeMinimumTax )

Verified 2026-08-03, re-verification due 2027-08-03

Prior designated Roth elective deferrals offset the §414(v)(7) Roth catch-up requirement Settled

Interpretation and scope: allocateEmployerElectiveDeferrals accepts an explicit priorContributions snapshot and treats catch-up as the excess of the annual elective-deferral total over the §402(g) base (not a chronological first-in assignment of prior dollars). Prior designated Roth credits the mandate even when deferred before the base was exhausted. Callers must supply verified YTD amounts; omitting the field remains known-zero for backward compatibility, while status unknown leaves additionalRothCatchUpStillRequired null. simulatePlan maps employerElectiveDeferralHistory by contribution year, owner and employer plan into annualContributionReconciliationPhase. Duplicate snapshots become unknown with a warning; verified prior amounts are passed into the allocator, and the reconciliation publishes the remaining Roth requirement and prior-contribution status.

• T.D. 10033; 26 CFR 1.414(v)-2(b)(1)
• T.D. 10033; 26 CFR 1.414(v)-2(d)(6) Example 6

Tested by: employerRothCatchUp.test.ts : “matches T.D. 10033 Example 6 remaining Roth catch-up” , “requires no additional Roth when prior Roth already covers the catch-up slice” , “leaves $4,000 required Roth when prior Roth is $4,000 and annual total is $32,500”

Implemented in: employerRothCatchUp.ts ( additionalRothCatchUpRequiredAfterPrior , allocateEmployerElectiveDeferrals ) ; annualContributionReconciliationPhase.ts ( annualContributionReconciliationPhase ) ; simulate.ts ( simulatePlan )

Verified 2026-09-12, re-verification due 2027-09-12

Private-activity-bond interest as an AMT preference item Approximated

Interpretation and scope: The plan model carries tax-exempt interest as a single annual amount with no issue-level detail, so identifying a specified private activity bond under 57(a)(5)(C) — an issue-date test with carve-outs for qualified 501(c)(3) bonds, certain housing bonds, refundings, and 2009–2010 issues — cannot be expressed in the input model. Treating the whole amount as non-preference matches the common diversified-fund case, and the omission is disclosed here rather than guessed per issue.

• IRC 57(a)(5)(A)
• IRC 57(a)(5)(C)(i)

Tested by: federalTax.test.ts : “adds no tax-exempt interest to AMTI, even when it is all PAB interest”

Implemented in: federalTax.ts ( computeFederalTax )

Verified 2026-08-07, re-verification due 2027-08-07

Qualified dividends are folded into net capital gain Settled

Interpretation and scope: The engine carries qualified dividends as a separate input rather than as a slice of ordinary income, and adds them to AGI once. That matters because a qualified dividend is simultaneously ordinary income for AGI, provisional income, and NIIT modified AGI, and preferential income for the rate schedule. Note also that 1(h)(11)(B) and (C) impose holding-period and qualified-foreign-corporation tests the engine cannot verify: it takes the qualified character of the supplied figure on trust.

• IRC 1(h)(11)(A)
• IRC 1(h)(11)(B)(i)
• Rev. Proc. 2025-32, section 4.03

Tested by: federalTax.test.ts : “runs qualified dividends through the preferential stack”

Implemented in: federalTax.ts ( capitalGainsTaxStacked , computeFederalTax )

Verified 2026-08-03, re-verification due 2027-08-03

Qualified medical HSA distributions are excluded from income Settled

• IRC 223(f)(1)
• IRS Publication 969

Tested by: annualHsaPenaltyEvaluation.test.ts : “reports no taxable exposure for the qualified medical segment”

Implemented in: annualHsaPenaltyEvaluation.ts ( evaluateAnnualHsaPenalty )

Verified 2026-08-04, re-verification due 2027-08-04

Qualified mortgage-insurance premiums again count as qualified residence interest Approximated

Interpretation and scope: What this is NOT is a typed refusal — `itemizedTotal` still emits a dollar figure that simply omits PMI, which is why this is approximated rather than outOfScope, the same shape as the medical-expense and §170(p) projection records. The fixture pins the produced total without the hypothesized premium until a separately authorized input and implementation fix closes the gap.

• IRC 163(h)(3)(E)(i)
• IRC 163(h)(3)(E)(ii)
• IRC 163(h)(3)(E)(iii)
• IRC 163(h)(3)(E)(iv)
• IRC 163(h)(3)(F)(i)(III)
• IRC 163, Editorial Notes, Effective Date of 2025 Amendment (P.L. 119-21 § 70108(b))

Tested by: federalTax.test.ts (qualifying PMI omitted from itemized total for a household already itemizing) : “omits qualifying PMI from the itemized total” , “ignores PMI however it is supplied under plausible field names” , “reaches the statutory deduction only when the premium is smuggled in as mortgage interest” , “overstates tax, by the deduction it cannot see at the marginal rate”

Implemented in: plan.ts ( itemizedDeductionsSchema ) ; federalTax.ts ( itemizedTotal )

Verified 2026-08-26, re-verification due 2027-08-26

Qualified opportunity fund investment defers eligible gain and can receive a ten-year basis election Out of scope

Interpretation and scope: One record keeps both limbs quote-carried from the staged compiled text. The body still prints the pre-2027 December 31, 2026 election and inclusion cutoffs; the Amendment of Section note carries the Pub. L. 119-21 post-2026 permanent text (rolling five-year deferral, amended (a)(2) without a new-sale cutoff, qualified rural opportunity fund). volatility is staticStatute because the program is permanent after the amending act — sunsetting would fit only a legacy-only record — and the legacy cutoff stays in the statement rather than effectiveThrough, which moots a dueOn-after-cutoff alarm for a still-open permanent regime.

• IRC 1400Z-2(a)(1)(A)
• IRC 1400Z-2(a)(2) (legacy pre-2027 elections)
• IRC 1400Z-2(b)(1) (legacy pre-2027 elections)
• Amendment note to IRC 1400Z-2, P.L. 119-21 sec. 70421 - post-2026 (a)(2)
• Amendment note to IRC 1400Z-2, P.L. 119-21 sec. 70421 - post-2026 (b)(1)
• IRC 1400Z-2(c) (legacy / continuing ten-year election)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( taxableAccountSchema )

Verified 2026-08-27, re-verification due 2027-08-27

Qualified-plan compensation taken into account is capped Approximated

Interpretation and scope: DEFECT — no behavior change in this registration slice. The match dollars are not current-year taxable income; they inflate tax-deferred balances and therefore defer and understate future tax while overstating resources. That is the same resource-inflating / future-tax-understating shape as irc-414-v-1-plan-permitted-catch-up and irc-408A-c-3-roth-contribution-agi-phase-out, which also use understatesTax when the engine admits more tax-advantaged contribution than the authority allows. The fixture pins employerMatch at the uncapped 24,500 against the statute's 21,600 until a separately authorized implementation fix changes it. model/plan.test.ts still gates the absent plan-defined compensation field.

• IRC 401(a)(17)(A)
• Notice 2025-67, annual compensation limitation

Tested by: simulateContributionsAndQcd.approximation.test.ts (uncapped wages inflate the 6%-of-pay match) : “computes employer match from uncapped wages above the 401(a)(17) cap”

Implemented in: plan.ts ( employerMatchSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2026-12-24

RIB-LIM is tested after the widow(er) age reduction Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. The code evaluates `max(deceasedActualMonthly, 0.825 × deceasedPiaMonthly)` before `survivorReductionFactor`, while POMS evaluates the widow(er) benefit after the age reduction before imposing the larger RIB-LIM amount. The companion fixture sets a 2,000-dollar PIA, a 1,400-dollar deceased reduced benefit, and a survivor claim at 63 against a 66-year survivor FRA: the authority-derived amount is 1,650 dollars because the widow(er) amount after reduction for age (2,000 x .8575 = 1,715) exceeds both limits, while the engine reduces that 1,650-dollar limit again. The observed engine amount is 1,414.875 - the 1,650-dollar limit reduced again by the .8575 age factor - pinned in the companion fixture.

• 42 U.S.C. 402(e)(2)(D)
• 20 CFR 404.338(c)
• SSA POMS RS 00615.320, § A.2
• SSA POMS RS 00615.320, § A.3

Tested by: survivorBenefit.test.ts : “pins the engine’s pre-reduction RIB-LIM ordering”

Implemented in: survivorBenefit.ts ( survivorBenefitMonthly )

Verified 2026-08-26, re-verification due 2027-08-26

RMD numerator is the prior December 31 balance Settled

• Treas. Reg. 1.408-8(b)(2)
• Treas. Reg. 1.401(a)(9)-5(b)(1)
• Treas. Reg. 1.401(a)(9)-5(a)(1)

Tested by: simulate.rmd-roth.test.ts : “computes the RMD on the untouched prior year-end balance”

Implemented in: annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; simulate.ts ( simulatePlan ) ; rmd.ts ( requiredMinimumDistribution )

Verified 2026-08-03, re-verification due 2027-08-03

Reduction of the QCD exclusion by post-70.5 deductible IRA contributions Settled

Interpretation and scope: TWO CONVENTIONS THE STATUTE DOES NOT SUPPLY, because the aggregate arm is a household scalar and section 408(d)(8)(A) speaks only of an individual's deductions and gifts. DATA. The projection is the authority for years it simulates, so in-run traditional IRA contributions for years ending on or after the 70½ threshold year are counted and a declared fact for the same year is not added on top of them; years before the projection starts can be seen only through declared deductibleIraContributions, and those facts are themselves refused when they precede the threshold year. Roth, employer, and HSA deposits are omitted because they are not deductions allowed under section 219. LIMB (ii). The Plan records no sourced already-taken reductions. Reconstructing them from a pre-start named request amount would invent execution the run never performed. When that history is unprovable and section 219 is positive, both arms fail closed: the named arm refuses the gift, and the aggregate arm — whose gift has already moved — claims none of the exclusion and writes no guessed leftover into consumed. Zero consumed is used only when there is no section 219 total to have been reduced. LEFTOVER. The leftover after the reduction is ordinary income. A section 170 itemized deduction for those dollars is not booked on this arm — the household may enter itemized charitable separately — and that leftover does not lower MAGI. The named arm still fails closed when a scalar year has made its declared-fact history unprovable, because the two arms do not share one contribution ledger. PUBLICATION. YearResult.qcd is the physical gift so the owned-IRA source series can exact-rejoin overlay plus moving occurrences; shrinking it to the excludable remainder would break that settlement.

• IRC 408(d)(8)(A)

Tested by: hsaLimitAndQcdOffset.approximation.test.ts (same-year §219 contribution swallows the gift) : “sweeps a gift the statute offsets to nothing” , “does not sweep the same gift when the contribution is Roth, not §219”

Tested by: hsaLimitAndQcdOffset.approximation.test.ts (Pub. 590-B Jim multi-year carryforward) : “carries Jim’s unused §219 offset into the next gift year”

Tested by: hsaLimitAndQcdOffset.approximation.test.ts (pre-70½ contributions do not reduce the exclusion) : “does not reduce a post-threshold gift by a contribution from a year that ended before 70½” , “does reduce the same gift when the contribution is for the threshold year”

Tested by: hsaLimitAndQcdOffset.approximation.test.ts (pre-start named QCD makes limb (ii) unprovable) : “does not claim the exclusion when a pre-start named QCD makes prior reductions unprovable” , “applies the unused §219 when no pre-start gift has made limb (ii) unprovable”

Implemented in: annualQcdTaxCharacterPostPass.ts ( stageAnnualQcdTaxCharacterPostPass ) ; qcdDeductibleContributionOffset.ts ( applyIrc408d8AContributionOffset ) ; annualLegacyQcdOwnerCharacterPlan.ts ( annualLegacyQcdOwnerCharacterPlan ) ; simulate.ts ( simulatePlan )

Verified 2026-08-17, re-verification due 2027-08-17

Required beginning date deferred while still employed by the plan sponsor Approximated

• IRC 401(a)(9)(C)(i)(II)
• IRC 401(a)(9)(C)(ii)

Tested by: rmdAndInherited.approximation.test.ts : “forces an employer-plan distribution from a participant still seven years from retiring”

Implemented in: plan.ts ( personSchema ) ; annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; simulate.ts ( simulatePlan ) ; accountEligibility.ts ( followsOwnerRmds )

Verified 2026-08-03, re-verification due 2027-08-03

Required distribution below one cent is discharged rather than distributed Approximated

Interpretation and scope: Direction of error: permissive, and bounded below half a cent per owned account per year. The undistributed fraction stays in the account rather than entering income, so ordinary income is understated by it and the year-end balance overstated by the same amount, and both persist for as long as the residue does. Nothing compounds: the residue never grows, and the fraction is below the smallest unit any published figure carries. What the convention buys is that the movement is representable at all. A fraction of a cent is not transferable in currency, no custodian can move it, and the exact-cent runtime journal has no way to hold a gross that rounds to nothing — so the alternatives were to record an occurrence for a movement that did not happen, or to move dollars with no occurrence explaining them, and the journal contract that every movement is explained forbids the second while the first is a false record. The half that is a decision rather than a consequence is the owner-side DISCHARGE. Reserve and QCD-coordination seams do not read that zero movement as an outstanding owned-IRA requirement, because doing so would refuse lawful conversions and misreport lawful gifts under this registered approximation. The convention stops at the inherited §4974 boundary. There the planner aggregates required amounts and actual movements by applicable plan, reports zero distributed for every zero-movement residue, and the excise calculator prices the resulting shortfall. The retirement path is an exact-cent balance ledger, which would remove the owner-side residue rather than manage it; until then the fixtures pin the bounded owner-side deviation and the inherited shortfall separately.

• Treas. Reg. 1.408-8(e)(1)(i)

Tested by: annualLegacyQcdGiftPlan.test.ts (aggregate scalar-QCD sub-cent source-residue discharge) : “discharges a scalar-QCD source residue below one ledger cent”

Tested by: annualWithdrawalPlanning.test.ts (need-based traditional-withdrawal half-cent boundary) : “discharges a below-half-cent traditional quantum without publishing it” , “retains an above-half-cent quantum that the exact ledger publishes as one cent”

Tested by: rmdAndInherited.approximation.test.ts : “distributes nothing where the required amount rounds to zero cents” , “leaves the residue inert rather than working it down year by year”

Implemented in: planBalanceAdapter.ts ( planDollarsMoveNoLedgerCent ) ; annualForcedDistributionQcdAndRetirementActionsPhase.ts ( annualForcedDistributionQcdAndRetirementActionsPhase ) ; annualLegacyQcdGiftPlan.ts ( annualLegacyQcdGiftPlan ) ; annualSeppDistributions.ts ( annualSeppDistributions ) ; annualWithdrawalPlanning.ts ( annualWithdrawalPlan )

Verified 2026-08-05, re-verification due 2027-08-05

Required distributions are not eligible rollover distributions Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. projection/simulate.ts's pension lump-sum rollover phase (model/plan.ts validates the election into an owned traditional account; projection/internal/pensionLumpSumRollovers.ts selects and sizes it and projection/simulate.ts credits it) moves the entire lumpSumOffer.amount as a tax-free direct rollover. Section 402(c)(4)(B) excludes the §401(a)(9)-required portion from the eligible-rollover-distribution definition; on the fixture an owner past the RBD with a 237,000 offer has a 10,000 RMD portion (237,000 ÷ Uniform Lifetime 23.7 at age 76) that should stay taxable and only 227,000 should roll. The engine rolls the full 237,000 and pays no taxable pension income in the election year. The fixture pins the produced zero taxable pension income and bounds the rolled balance above the eligible 227,000 until a separately authorized implementation fix changes it.

• IRC 402(c)(4)
• IRC 402(c)(4)(B)
• Treas. Reg. 1.408-8(b)(3)

Tested by: simulate.annualCashFlow.transfer.test.ts (pension lump-sum past RBD) : “credits the entire pension lump-sum offer as a tax-free rollover past the RBD”

Implemented in: plan.ts ( pensionSchema ) ; pensionLumpSumRollovers.ts ( pensionLumpSumRollovers ) ; simulate.ts ( simulatePlan )

Verified 2026-08-25, re-verification due 2027-08-25

Retirement age keys on attaining age 62, not on birth year Settled

Interpretation and scope: Because the statute turns on attaining age 62 rather than on a birth year, the boundary moves for anyone born on 1 January: the Social Security Administration treats a person as attaining an age on the day before their birthday, so a 1 January 1960 birth attains 62 in 2021 and falls under the 66-plus-factor branch rather than the flat 67. The engine expresses this as an effective birth year of the prior calendar year.

• 42 U.S.C. 416(l)(1)
• 42 U.S.C. 416(l)(2)

Tested by: nra.test.ts : “sends a January 1 birth to the prior cohort”

Implemented in: nra.ts ( fraForBirthYear )

Verified 2026-08-29, re-verification due 2027-08-29

Retirement plan distributions are not net investment income Settled

Interpretation and scope: This is the mechanism behind the most common NIIT surprise in retirement planning, and it only appears correctly if the two halves of 1411(a)(1) are kept separate: the distribution is absent from the net investment income leg and present in the modified AGI leg. The engine gets this right structurally by carrying plan distributions in ordinary income and building net investment income from a separate set of inputs. Note the exclusion is keyed to the type of plan, not to the character of the earnings inside it, so the investment return accumulated in an IRA never becomes net investment income.

• IRC 1411(c)(5)
• IRC 1411(a)(1)

Tested by: federalTax.test.ts : “leaves plan distributions out of net investment income but not out of modified AGI”

Implemented in: federalTax.ts ( computeFederalTax )

Verified 2026-08-03, re-verification due 2027-08-03

Retroactive Medicare enrollment can make HSA contributions excess Out of scope

Interpretation and scope: This is narrower than, and not a duplicate of, irc-223-b-2-7-projection-coverage-proration-and-medicare: that approximated record documents the annual HSA coverage shortcut. The Part A entitlement/backdating fact itself is absent and cannot be inferred from age. model/plan.test.ts gates those missing HSA fields.

• IRC 223(b)(7)
• IRS Publication 969, Enrolled in Medicare

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( hsaAccountSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2027-08-26

Retroactive recapture when a SEPP series is modified Out of scope

• IRC 72(t)(4)(A)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: traditionalEmployerPlanPenaltyPrerequisite.ts ( evaluateTraditionalEmployerPlanPenaltyPrerequisite )

Verified 2026-09-07, re-verification due 2027-09-07

Roth IRA as a QCD source Out of scope

• IRS Notice 2007-7, Q&A-36
• IRC 408(d)(8)(B), flush text

Refusal tested by: accountEligibility.test.ts : “refuses a Roth source instead of proving how much would otherwise be includible” , “does not confuse the Roth source with the generic not-an-IRA refusal” , “allocates an owned traditional IRA and blocks a Roth source as qcd-source-not-ira”

Implemented in: annualQcdExecutionPrerequisite.ts ( evaluateAnnualQcdExecutionPrerequisites ) ; annualQcdPhysicalExecution.ts ( stageAnnualQcdPhysicalExecution ) ; retirementActionCandidateIdentityAllocator.ts ( qcdSourceIssue ) ; ownedNonRothIraRuntimeSourceSeries.ts ( validateOwnedNonRothIraRuntimeSourceSeries ) ; accountEligibility.ts ( evaluateQcd )

Verified 2026-09-05, re-verification due 2027-09-05

Roth IRA owner has no lifetime RMD Settled

• IRC 408A(c)(4)(A)

Tested by: rmdShortfallExcise.test.ts (living Roth IRA owner past the ordinary RMD age) : “never creates a lifetime §4974 obligation for a living Roth IRA owner”

Implemented in: annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; simulate.ts ( simulatePlan )

Verified 2026-08-25, re-verification due 2027-08-25

Roth and traditional IRA contributions share one annual ceiling Settled

Interpretation and scope: The engine expresses this by putting traditional and Roth IRAs owned by the same person into a single annual limit group rather than by ordering one before the other. Ordering would matter if the two ceilings differed, and under this section they do not.

• IRC 408A(c)(2)

Tested by: simulate.contributions-growth.test.ts : “does not give a second ceiling to someone holding both IRA flavours”

Implemented in: annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-03, re-verification due 2027-08-03

Roth qualified distribution and the five-taxable-year period Approximated

Interpretation and scope: Two independent errors sit under the single age test, and this record states both because neither covers the other. The five-taxable-year period is not modelled at all, and its absence under-taxes: a 62-year-old whose first Roth IRA was opened two years ago is shown tax-free earnings that the statute makes ordinary income and exposes to the 72(t) tax, which is exactly the case a conversion ladder started late in life produces. The attained-age-60 test is a second and separate error: it is the same annual proxy registered for the traditional path as irc-72-t-2-A-i-age-59-half-annual-proxy, appearing here as ROTH_QUALIFIED_AGE, and because attained age is the calendar-year age it runs both ways by up to about six months depending on the birth month rather than in a single direction. The five-year period cannot be recovered from account state the projection already holds, because 408A(d)(2)(B) runs it per individual from the first contribution to any Roth IRA rather than per account; closing this needs a household-level first-Roth-year fact, not a change to the withdrawal split. Until then nothing from this path is filing-grade on the taxability of Roth earnings.

• IRC 408A(d)(2)(A)
• IRC 408A(d)(2)(B)
• IRC 408A(d)(1)

Tested by: federalTaxAndRothBasis.approximation.test.ts (earnings taxed inside the five-taxable-year period, past the age event) : “treats earnings as tax-free inside the five-taxable-year period” , “has nowhere to put the first-Roth-year fact that would change the answer” , “runs the other way too, on the attained-age-60 proxy for 59.5”

Implemented in: rothBasis.ts ( ROTH_QUALIFIED_AGE , splitRothWithdrawal )

Verified 2026-08-03, re-verification due 2027-08-03

Roth withdrawals consume contributions, conversions, then earnings Settled

• IRC 408A(d)(4)(B)
• IRS Publication 590-B (2025), Ordering Rules for Distributions

Tested by: rothBasis.test.ts (regular contributions, conversion principal, then earnings) : “consumes regular contributions before conversion principal”

Tested by: rothBasis.test.ts (earnings reached last) : “reaches earnings only after both basis pools are exhausted”

Tested by: rothBasis.test.ts (qualified rollover contribution layers are first-in, first-out) : “debits the oldest conversion layer before later conversion layers”

Implemented in: rothBasis.ts ( splitRothWithdrawal )

Verified 2026-08-25, re-verification due 2027-08-25

Rule of 55 modelled from the plan retirement age Approximated

Interpretation and scope: The annual proxy can err in both directions and neither direction is bounded by a fixed number of months. It can waive too early because it treats a household retirement-age assumption as proof that the statutory separation predicate has been met for every employer-plan account; it can waive too late where a real separation has occurred but the plan retirement age is later. The plan model carries one retirement age per person and no separation event or account-to-employment linkage, so it cannot evaluate the statutory event directly. The calendar-year crossing case addressed by the IRS gloss cannot arise here: retirementAge is a calendar-year age, resolved as dobYear + retirementAge, so a recorded retirement age of 55 is waived. The engine does preserve the structural IRA limit: section 72(t)(3)(A) denies the exception to individual retirement plans, and the proxy waives only an employer-kind account. The exact-date reading remains in actions/traditionalEmployerPlanPenaltyPrerequisite.ts.

• IRC 72(t)(2)(A)(v)
• IRC 72(t)(3)(A)

Tested by: accountEligibility.approximation.test.ts (a plan left behind at 40, waived like the plan retired from) : “waives the plan the owner left at 40, which 72(t)(2)(A)(v) does not reach” , “cannot tell that plan from the plan actually separated from at 57” , “does return the statutory rate for an IRA, where the two readings agree” , “charges nothing on the projected employer-plan draw at 57”

Tested by: accountEligibility.approximation.test.ts (separated from the plan at 56 but still working elsewhere) : “penalizes a plan separated from after 55 because the owner has not reached the modelled retirement age” , “does waive once the retirement age is reached, where the two readings agree” , “charges 10% on the projected draw at 58 from a plan the statute has already released”

Implemented in: accountEligibility.ts ( traditionalWithdrawalPenaltyRate )

Verified 2026-09-07, re-verification due 2027-09-07

Rule of 55 separation test Settled

Interpretation and scope: The calendar-year form of the test is IRS administrative position rather than statutory text: 72(t)(2)(A)(v) says only "after attainment of age 55", which read literally would require the participant to have turned 55 before separating. The calendar-year gloss comes from Notice 87-13 Q&A-20 and is restated in Publication 575, the Form 5329 instructions, and the IRS exceptions chart. The engine follows the IRS position.

• IRC 72(t)(2)(A)(v)
• IRC 72(t)(3)(A)
• Instructions for Form 5329, exception 01

Tested by: traditionalEmployerPlanPenaltyPrerequisite.test.ts : “accepts separation before the birthday in the qualifying year”

Implemented in: traditionalEmployerPlanPenaltyPrerequisite.ts ( evaluateTraditionalEmployerPlanPenaltyPrerequisite )

Verified 2026-08-28, re-verification due 2027-08-28

SECURE Act ten-year rule for a designated beneficiary Settled

Interpretation and scope: Two limits on how far this record reaches, stated so it is not read as covering more than it does. First, an account using the legacy two-field inherited block without beneficiary facts remains on the labeled non-EDB-style legacy-planning-approximation. The current Plan schema also carries beneficiaryClass, edbCategory, election, sole-beneficiary, withdrawal-right, and beneficiary-age facts, and classifyInheritedRegime uses those facts for spouse and eligible-designated-beneficiary paths. This record’s legacy fixture therefore demonstrates only that fallback path; it must not be read as saying every inherited account lacks a beneficiary category or that classified spouse and EDB schedules are unmodeled. Second, the size of the annual amount required in years one through nine when the decedent had reached the required beginning date is a separate question from the ten-year deadline registered here. The divisor is registered as treas-reg-1-401-a-9-5-d-3-beneficiary-single-life-denominator, and the greater-of test omitted only on the legacy path is registered as treas-reg-1-401-a-9-5-d-1-ii-greater-of-employee-life-expectancy.

• IRC 401(a)(9)(H)(i)
• IRC 401(a)(9)(B)(ii)
• IRC 408(a)(6)
• Treas. Reg. 1.401(a)(9)-3(c)(3)

Tested by: accountEligibility.test.ts : “keeps an inherited account off the owner RMD schedule entirely” , “sweeps the balance in the tenth year after the death and not the fifth” , “forces nothing in the interim years when the decedent had not begun distributions”

Implemented in: annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan ) ; accountEligibility.ts ( followsOwnerRmds ) ; inheritedIra.ts ( inheritedTenYearDeadline )

Verified 2026-08-03, re-verification due 2027-08-03

SIMPLE 401(k) elective deferrals use the separate SIMPLE limit Out of scope

Interpretation and scope: The generic 402(g) aggregate record is deliberately not extended to call a 401(k) SIMPLE: that plan-document status is absent. model/plan.test.ts gates the employer-plan-type membership, and actions/contract.test.ts gates the absence of a plan-term correction/action arm. The enhanced-limit election under 408(p)(2)(E)(i)(II) is not carried here — one claim per record.

• IRC 401(k)(11)(B)(i)(I)
• Notice 2025-67, SIMPLE retirement account and SIMPLE 401(k) limitation

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( traditionalAccountSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2026-12-24

SIMPLE IRA 25 percent rate during the initial two-year period Settled

• IRC 72(t)(6)(A)
• IRS SIMPLE IRA plan FAQs
• IRC 72(t)(2), lead-in

Tested by: ownedNonRothIraPenaltyPrerequisite.test.ts : “lets a 72(t)(2) exception zero the tax inside the two-year window” , “applies 25 percent only where no exception reaches the distribution”

Implemented in: ownedNonRothIraPenaltyPrerequisite.ts ( evaluateOwnedNonRothIraPenaltyPrerequisites )

Verified 2026-09-07, re-verification due 2027-09-07

SIMPLE IRA two-year bar on rollover and Roth conversion Settled

Interpretation and scope: This is not the rule already registered as irc-72-t-6-simple-two-year-rate, and neither record covers the other. That one is the rate substitution in 72(t)(6)(A): it prices a distribution the taxpayer is nonetheless permitted to take, and every 72(t)(2) exception still zeroes it. This one is the eligibility bar in 408(d)(3)(G): it makes the movement unavailable at all. They share a period and nothing else, so a distribution can sit inside the period, carry no additional tax because an exception applies, and still be ineligible for rollover or conversion. Reading either record as coverage of the other would leave a conversion the statute forbids being merely repriced at 25 percent. The period itself is measured as 24 calendar months from the participation start date using the month-end clamp in actions/civilDate.ts, and the comparison is strict, so a conversion dated on the 24-month anniversary is permitted and one dated the day before is refused. That follows from a 2-year period beginning on the participation date, which runs through the day before the anniversary.

• IRC 408(d)(3)(G)
• IRC 408A(e)(1)(B)(i)
• IRC 72(t)(6)(A)

Tested by: accountEligibility.test.ts : “refuses the conversion outright inside the two-year period” , “lifts the bar on the 24-month anniversary itself” , “does not reach an ordinary traditional IRA of the same owner”

Implemented in: accountEligibility.ts ( evaluateConversion )

Verified 2026-08-03, re-verification due 2027-08-03

SSDI begins only after a five-month waiting period Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. For a January-equivalent onset and a 2,000-dollar PIA, section 423 pays at most seven months (14,000) in the onset year while the engine observably pays twelve (24,000). Extra early benefit raises taxable Social Security income; when spending is instead funded from a traditional account the missing-benefit case replaces each dollar with a fully taxable withdrawal, so the taxpayer-tax sign flips with the funding channel.

• 42 U.S.C. 423(c)(2)
• 42 U.S.C. 423(a)(1)

Tested by: simulate.social-security.test.ts : “pays a full onset-year SSDI benefit where the waiting period leaves at most seven months”

Implemented in: annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan ) ; disability.ts ( inSsdiWindow )

Verified 2026-08-27, re-verification due 2027-08-27

SSDI pays the full PIA until retirement age, then the PIA continues as retirement Settled

Interpretation and scope: The stream's `claimAge` is deliberately ignored while its disability onset is active before FRA, so importing the ordinary age-62 factor would give the wrong amount. At FRA the code stays on the SSDI branch and only relabels the published source to own retirement at the same full PIA, rather than treating the change as a new claim or a DRC opportunity. The companion fixture extends the observed object through the first post-FRA year so the no-DRC continuation is pinned, and adds a 1959-born (FRA 66y10m) cohort observation for the fra.years-only gate.

• 42 U.S.C. 423(a)(2)
• 42 U.S.C. 423(a)(1)
• 20 CFR 404.317

Tested by: simulate.social-security.test.ts (integer FRA 67 cohort) : “pays the full PIA during SSDI, at FRA, and in the first post-FRA year”

Tested by: simulate.social-security.test.ts (1959 FRA 66y10m cohort) : “observes the unreduced PIA for a 66y10m FRA cohort around fra.years”

Implemented in: annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan ) ; disability.ts ( ssdiMonthlyBenefit )

Verified 2026-08-27, re-verification due 2027-08-27

Same-year Roth conversions are ordered in aggregate, taxable portion first Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. Pub 590-B’s year-aggregate reading takes the year’s taxable conversion principal before any nontaxable principal from that year. The engine records one layer per named conversion action (projection/internal/annualForcedDistributionQcdAndRetirementActionsPhase.ts) and `splitRothWithdrawal` walks those layers in array order, so a nontaxable 2024 layer ahead of a taxable 2024 layer can be fully consumed first. On the fixture — two same-year $5,000 layers with the nontaxable one first, then a $5,000 draw at age 50 — year-aggregate taxable-first yields $500 of additional tax; array order yields $0. The per-contribution FIFO record cannot carry this gap because both layers share a year.

• IRC 408A(d)(4)(B)(ii)(II)
• IRS Publication 590-B (2025), Ordering Rules for Distributions
• IRS Publication 590-B (2025), Aggregation rules

Tested by: rothBasis.test.ts (same-year nontaxable layer ahead of taxable layer understates 72(t)) : “consumes a same-year nontaxable conversion layer before a later taxable one in array order”

Implemented in: annualForcedDistributionQcdAndRetirementActionsPhase.ts ( annualForcedDistributionQcdAndRetirementActionsPhase ) ; rothBasis.ts ( splitRothWithdrawal )

Verified 2026-09-09, re-verification due 2027-09-09

Saver's Match is a post-2026 contribution for eligible savers Out of scope

Interpretation and scope: This is deliberately registered ahead of the first statutory tax year rather than projected as a 2026 credit. The plan model has no Saver's Match eligibility, qualifying-contribution, match-payment, or match-account fields, and the action contract has no claim or deposit kind. Those schema and action-vocabulary refusals are covered in model/plan.test.ts and actions/contract.test.ts. effectiveFrom is 2027 because the enacting applicability is taxable years beginning after December 31, 2026 — the rule cannot govern a 2026 pack year.

• IRC 6433(a)(1)
• IRC 6433(a)(2)(A)
• P.L. 117-328, division T, title I, section 103(a), (f)
• IRS Notice 2026-48, section I

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: contract.ts ( persistedRetirementActionRequestSchema ) ; plan.ts ( planSchema )

Verified 2026-09-07, re-verification due 2026-12-06

Savings-bond interest is deferred until redemption, maturity, or disposition unless elected Out of scope

Interpretation and scope: The absence surface spans model/plan.ts, projection/internal/distributedTaxableYieldRows.ts, and projection/simulate.ts. taxableAccountSchema.interestYieldPct is a generic current-year yield; distributedTaxableYieldRows prices it for the current year, and simulate.ts immediately adds the returned interest to ordinary income. None of those surfaces identifies a savings bond, a redemption/disposition/final-maturity event or date, accounting method, or the section 454 election that would select current inclusion. Treating generic interest as a savings bond would conflate an ordinary brokerage yield with a deferred savings-bond obligation.

• IRC 454(a)
• IRC 454(c)
• 26 CFR 1.454-1(a)(1)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( taxableAccountSchema ) ; distributedTaxableYieldRows.ts ( distributedTaxableYieldRows ) ; simulate.ts ( simulatePlan )

Verified 2026-09-08, re-verification due 2027-09-08

Section 168 straight-line real-property depreciation can produce unrecaptured section 1250 gain subject to a 25-percent maximum rate Approximated

• IRC 1(h)(1)(E)
• IRC 1(h)(6)(A)(i)
• IRC 1250(b)(1)
• IRC 168(b)(3)(A)-(B)

Tested by: annuityAndProperty.approximation.test.ts : “classifies the depreciation as ordinary income rather than capital gain” , “leaves the capital-gain slice short by the depreciation” , “returns no field in which a 25 percent ceiling could be carried”

Implemented in: simulate.ts ( simulatePlan ) ; propertySale.ts ( propertySaleTax )

Verified 2026-09-08, re-verification due 2027-09-08

Section 414(v) catch-up is not an annual addition under 415(c) Settled

Interpretation and scope: The engine already split the §402(g) base from the 414(v) catch-up slice for the Roth-character mandate. That same slice is the paragraph (1) contribution paragraph (3)(A) names. IRA catch-up under 219(b)(5) is outside 414(v) and never enters this carve-out. Current-year wages stand in for 415(c)(3) compensation, as they already do for the 415(c) pay prong.

• IRC 414(v)(3)(A)
• IRC 414(v)(7)(A)

Tested by: employerRothCatchUp.test.ts (catch-up is not taken into account for match room) : “leaves leftover 415(c) room for match after the 402(g) base only”

Implemented in: employerRothCatchUp.ts ( allocateEmployerElectiveDeferrals ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-19, re-verification due 2027-08-19

Section 415(d) is the adjustment mechanism the other retirement limits borrow Settled

Interpretation and scope: Most limits in the 415(d) family — including 402(g), the ordinary age-50 catch-up, and the 415(c)(1)(A) cap — multiply the pack figure by limitGrowth, the plan or Monte Carlo inflation path from the parameter year; neither path uses actual future IRS annual CPI determinations. The ages-60-through-63 catch-up is the exception: it sends the pack greater-of amount through indexWithStatutoryRounding, flooring the cumulative dollar increase to 500-dollar steps. Matching future IRS-published limits would require future CPI inputs; plan inflation is a deliberate planning approximation, and its divergence from the statutory series is not bounded by one rounding step. What this convention must not be extended to is a figure with no adjustment provision at all, where the same multiplication produces a number the statute never allows.

• IRC 415(d)(1), (d)(2), (d)(3)(D), (d)(4)(B)
• Notice 2025-67, section on the section 415 limitations

Tested by: params.test.ts : “moves the annual additions limit on a thousand-dollar step” , “leaves every borrowing limit on the step its own provision names”

Implemented in: year2026.ts ( year2026 ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-03, re-verification due 2026-12-01

Section 72(t) does not reach non-retirement withdrawal sources Out of scope

Interpretation and scope: The executor represents the absence of the statutory predicate rather than computing a zero section 72(t) tax. Its one-cent cash fixture in actions/execution.test.ts makes both the notApplicable status and nonRetirementSource reason observable, while also proving that no penalty exposure enters the result.

• IRC 72(t)(1)
• IRC 4974(c)

Refusal tested by: execution.test.ts : “answers a non-retirement source with notApplicable rather than a penalty figure” , “does not extend that answer to a retirement source”

Implemented in: execution.ts ( executeOrdinaryWithdrawals )

Verified 2026-08-25, re-verification due 2027-08-25

Section 7520 and section 2522 split-interest valuation are not modelled Out of scope

• IRC 7520(a)
• IRC 2522(c)(2)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( planSchema )

Verified 2026-08-27, re-verification due 2027-08-27

Self-employed health insurance is not an above-the-line deduction surface Out of scope

• IRC 162(l)(1)
• IRC 162(l)(2)(A)

Refusal tested by: simulate.selfEmployedHealthInsuranceRefusal.test.ts : “fails the credit closed instead of computing a self-employed deduction” , “prices the same year once the assertion is notApplicable, so the refusal is the deduction claim”

Implemented in: plan.ts ( acaYearContractSchema ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

Self-employment earned income is not a modeled compensation source Approximated

Interpretation and scope: The direction of this gap is the opposite of the Roth phase-out gap: it understates rather than overstates, denying contribution room to a self-employed household that is entitled to it. It is recorded here so the section 219(b)(1) compensation prong is not read as complete. The engine income model has no self-employment stream to read from, so closing this needs a model change and not a calculation change.

• IRC 401(c)(2)(A)

Tested by: simulateContributionsAndQcd.approximation.test.ts : “denies IRA contribution room to a household whose only earnings are self-employment” , “allows the identical amount when the same dollars arrive as wages”

Implemented in: plan.ts ( wagesIncomeSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-04, re-verification due 2027-08-04

Separate-account treatment requires a timely separate account Out of scope

Interpretation and scope: The account model has no dated separate-account establishment fact. Its typed multiple-beneficiary refusal is already exercised in inheritedRegime.test.ts; projection still routes that refusal through the registered inheritedForcedAmount fallback so a plan that parsed still projects. No numeric describeRule is lawful for this out-of-scope record.

• Treas. Reg. 1.401(a)(9)-8(a)(1)(i)
• Treas. Reg. 1.401(a)(9)-8(a)(1)(ii)(A)

Refusal tested by: inheritedRegime.test.ts : “refuses multiple beneficiaries rather than inferring a timely separate account” , “refuses the post-deadline case the quoted rule governs the same way as any other” , “classifies the same account for a sole beneficiary, so the refusal is the missing separate-account fact”

Implemented in: plan.ts ( inheritedAccountSchema ) ; annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan ) ; inheritedIra.ts ( classifyInheritedRegime )

Verified 2026-08-25, re-verification due 2027-08-25

Series EE/I book-entry annual purchase principal limit is not modeled Out of scope

Interpretation and scope: The absence surface is model/plan.ts: taxableAccountSchema carries an aggregate brokerage balance, cost basis, and generic annual contribution, but no savings-bond instrument, TreasuryDirect owner, or annual bond-purchase history. The generic contribution field cannot be treated as a book-entry savings-bond purchase without inventing the instrument and owner facts on which the annual limit turns.

• 31 CFR 363.52

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( taxableAccountSchema )

Verified 2026-08-27, re-verification due 2027-08-27

Sixty percent ceiling for cash gifts to public charities Settled

Interpretation and scope: The sixty-percent rate for cash gifts to public charities dates from taxable years beginning after December 31, 2017. The amendment note quoted below shows that clause (G)(i) formerly capped such contributions at 60 percent of contribution base for taxable years beginning after December 31, 2017, and before January 1, 2026; the operative (G)(i) text in the first authority below expresses the net-of-(A) combined formula and applies for taxable years beginning after December 31, 2025 under section 70425(c). effectiveFrom is 2026 because this record states that post-amendment combined reading.

• IRC 170(b)(1)(G)(i)
• IRC 170(b)(1)(G)(ii)
• IRC 170(b)(1)(G)(iii)(I)
• IRC 170(b)(1)(G)(iii)(II)
• IRC 170(b)(1)(G)(i), Editorial Notes, Amendments, 2025, prior text
• IRC 170, Editorial Notes, Effective Date of 2025 Amendment, Pub. L. 119-21, sec. 70425(c)

Tested by: annualQcdItemizedSection170Ledger.test.ts : “fills only the headroom left by contributions already counted”

Implemented in: annualQcdItemizedSection170Ledger.ts ( stageAnnualQcdItemizedSection170Ledger ) ; annualCharitableDeductionParameters.ts ( annualCharitableDeductionParameters )

Verified 2026-09-05, re-verification due 2027-09-05

Social Security inclusion is two tiers with a capped carry Settled

Interpretation and scope: The statute caps the carried amount at 4,500 dollars single and 6,000 joint. The engine computes half the spread between the base and adjusted base amounts instead, which equals those figures exactly -- 0.5 x (34,000 - 25,000) and 0.5 x (44,000 - 32,000) -- so the cap stays correct if the thresholds are ever re-indexed, rather than drifting from two hard-coded constants.

• IRC 86(a)(1)
• IRC 86(a)(2)
• IRC 86(b)(2)
• IRC 86(c)

Tested by: federalTax.test.ts : “carries the capped tier-one amount into the 85 percent band”

Implemented in: federalTax.ts ( taxableSocialSecurity )

Verified 2026-09-07, re-verification due 2027-09-07

Spousal deemed election on an undistributed post-death-year amount Settled

Interpretation and scope: The annual gate separates completed prior-year history from current-year event evidence. A verified current-year affirmative election or non-rollover contribution can use completed history through the preceding year at the end-of-year gate; a same-year shortfall-only deemed election still needs its completed deadline, observation and provenance. A future contribution does not route owner treatment at opening, and unproven contribution evidence remains refused. simulatePlan routes a verified effective current-year event to the owner-RMD planner while retaining the beneficiary requirement as immutable trigger evidence. The forced-distribution phase suppresses the replaced beneficiary take before tax characterization and publishes a separate structured owner obligation. simulate.spousalElectionYearOwnerRmd.test.ts carries owner-treatment production discriminators, including a completed current-year 5000/4000 shortfall. Mixed-year transaction tax chronology remains typed incomplete; source linkage does not certify unresolved event sequences or full original acceptance.

• Treas. Reg. 1.408-8(c)(2)

Tested by: beneficiarySpousalElectionStatus.test.ts : “begins owner treatment when a post-death-year amount goes undistributed” , “does not read the year of death as a trigger year” , “treats a non-rollover contribution as a trigger” , “refuses an unobserved year rather than assuming it was satisfied”

Implemented in: beneficiarySpousalElectionAnnualGate.ts ( gateBeneficiarySpousalElectionForAnnualCoordinator ) ; beneficiarySpousalElectionStatus.ts ( evaluateBeneficiarySpousalElection ) ; beneficiarySpousalElectionGateAdapter.ts ( gateSpousalElectionFromInheritedAccount ) ; simulate.ts ( simulatePlan )

Verified 2026-08-04, re-verification due 2027-08-04

Spouses share one family HSA limit but keep whole catch-ups Settled

Interpretation and scope: Two facts the statute turns on are absent from the plan model, and each is resolved toward the statutory default. The division by agreement under (5)(B)(ii) cannot be observed, so the engine takes the equal division the statute applies in its absence. Coverage election is likewise unmodelled: a two-person household is treated as having family coverage, which is already what selects the family base, and paragraph (5)(A) then makes that coverage apply to both spouses. Paragraph (5) opens on individuals who are married to each other, so the division is applied only where the two-person household is also a married one with both spouses living. Household size does not carry that fact by itself: the plan schema requires two people for a joint return but does not require a joint return of a two-person household, so an unmarried pair is representable. Each of them is then simply an eligible individual with family coverage under (b)(2)(B) whom paragraph (5) never reaches, and each keeps a whole family limit. A sole survivor keeps the undivided base for the same reason, having nobody left to divide with. The per-person contribution group key is retained rather than replaced by a household one precisely so the (b)(3) catch-up stays attached to the spouse who earned it.

• IRC 223(b)(5)
• IRC 223(b)(2)(B)

Tested by: simulate.contributions-growth.test.ts : “halves the family base between spouses but leaves each catch-up whole” , “leaves a one-person household on the undivided self-only limit” , “leaves an unmarried two-person household a whole family limit each”

Implemented in: annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-03, re-verification due 2027-08-03

State and local bond interest is excluded from gross income Settled

• IRC 103(a)

Tested by: federalTax.test.ts : “keeps municipal-bond interest out of federal AGI and taxable income by direct inclusion” , “raises AGI only by the taxable-Social-Security increment when munis enter provisional income”

Implemented in: distributedTaxableYieldRows.ts ( distributedTaxableYieldRows ) ; simulate.ts ( simulatePlan ) ; federalTax.ts ( computeFederalTax )

Verified 2026-08-27, re-verification due 2027-08-27

Successor schedules after an in-horizon beneficiary death are not modeled Out of scope

Interpretation and scope: The planner already knows the inherited class from cache but has no successor identity, successor election, or post-beneficiary-death schedule facts. Suppressing movement and shortfall obligations is therefore a typed refusal rather than a silent zero. inheritedRegime.test.ts continues to own the initial successor-beneficiary classifier path; this record registers only the in-horizon beneficiary-death branch in annualInheritedIraDistributions. The common dead-beneficiary branch also fails closed for a pre-2020 X1 legacy row; that row is outside this record's governing period and retains its X1 reason and authority rather than being attributed to H(iii).

• Pub. L. 116-94, div. O, sec. 401(b)(1)
• IRC 401(a)(9)(H)(iii)
• Treas. Reg. 1.401(a)(9)-5(e)(1)
• Treas. Reg. 1.401(a)(9)-5(e)(3)

Refusal tested by: annualInheritedIraDistributions.test.ts : “refuses successor schedules once an eligible designated beneficiary dies in horizon”

Implemented in: annualInheritedIraDistributions.ts ( annualInheritedIraDistributions ) ; simulate.ts ( simulatePlan )

Verified 2026-09-09, re-verification due 2027-09-09

Surviving-divorced remarriage gate under 404.336(e) and (e)(1) Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. 20 CFR 404.336(e) starts from currently unmarried; a later marriage that has ended leaves the claimant unmarried and inside that lead-in. passesSurvivorRemarriageGate instead rejects whenever remarriedAtAge is below 60, including when claimantIsSingle is true. Independently, passesSurvivorRemarriageGate never reads claimantIsSingle, so a schema-valid coupled context with remarriedAtAge null still receives a candidate; a null remarriedAtAge lacks the facts of any 404.336(e) exception and does not prove a marriage before 60. The companion fixture holds ten-year duration, claimant age 67, deceased ex at FRA, and PIA 2,400 so the unreduced survivor amount is 2,400 when the gate passes: remarried at 55 now single (worksheet currently unmarried pays; engine null), then remarried at 60 still married ((e)(1) pays; engine 2,400). Paragraph (e)(2) and (e)(3) disabled-remarriage facts have no formerSpouse fields and are not adjudicated here.

• 20 CFR 404.336(e), (e)(1)
• 42 U.S.C. 402(e)(1)(A)
• 42 U.S.C. 402(e)(3)(A)

Tested by: maritalBenefits.eligibility.test.ts : “pins the historical remarriedAtAge gate against currently unmarried and (e)(1) preservation”

Implemented in: maritalBenefits.ts ( passesSurvivorRemarriageGate )

Verified 2026-09-09, re-verification due 2027-09-09

Surviving-divorced ten-year marriage-immediately-before-divorce duration under 404.336(a)(2) Settled

Interpretation and scope: formerSpouseSchema.relationship accepts surviving-divorced alongside divorced and deceased; saved plans with relationship deceased keep the ordinary-widow nine-month path. passesModeledSurvivingDivorcedDurationGates is pinned here. The fixture uses marriageYears [0.75, 10] as boolean refused/accepted duration outputs with remarriage held out. remarriedAtAge is carried on formerSpouseSchema and is enforced by passesSurvivorRemarriageGate, which the composite passesModeledSurvivingDivorcedRecordGates calls but which is owned by `cfr-20-404-336-e-surviving-divorced-remarriage`. Unadjudicated residuals not carried in formerSpouseSchema: fully insured status, valid marriage under (a)(1), application and its 404.336(b)(1)–(4) exceptions, age-60 non-disabled and disabled-age-50 paths and their conditions in (c), the (d) own-old-age-benefit restriction, and claim-age sequencing between own and survivor benefits.

• 20 CFR 404.336
• 20 CFR 404.336(a)(1)
• 20 CFR 404.336(a)(2)
• 42 U.S.C. 416(d)(2)
• 42 U.S.C. 402(e)(1)

Tested by: maritalBenefits.eligibility.test.ts : “pins the surviving-divorced ten-year duration against the ordinary nine-month proxy”

Implemented in: maritalBenefits.ts ( passesModeledSurvivingDivorcedDurationGates )

Verified 2026-09-09, re-verification due 2027-09-09

Surviving-spouse late-election catch-up uses one adjusted current reference balance Settled

Interpretation and scope: The Uniform Lifetime values come from the versioned RMD parameter pack. The 1959 applicable-age conflict remains a typed incomplete result rather than choosing a proposed clarification as current law. The production beneficiarySpousalElectionGateAdapter maps dated Plan facts to this calculation and gate; simulatePlan consumes the opening result. A current-year event is distinct from completed prior-year observation.

• Treas. Reg. 1.402(c)-2(j)(4)(ii)-(iv) (2025 CFR)
• Treas. Reg. 1.408-8(c)(1)(iii)-(iv)
• IRS, Internal Revenue Bulletin 2024-33, proposed worked example

Tested by: beneficiarySpousalElectionAnnualGate.test.ts : “exposes the regulated recurrence rather than an asserted catch-up worksheet”

Tested by: simulate.spousalElectionYearOwnerRmd.test.ts (production affirmative-election catch-up gate) : “blocks affirmative effectiveness until official j4 catch-up 10383.68 is satisfied”

Implemented in: beneficiarySpousalElectionAnnualGate.ts ( determineSection402c2j4CatchUp , gateBeneficiarySpousalElectionForAnnualCoordinator ) ; index.ts ( uniformLifetimeDivisor ) ; beneficiarySpousalElectionGateAdapter.ts ( gateSpousalElectionFromInheritedAccount ) ; simulate.ts ( simulatePlan )

Verified 2026-09-12, re-verification due 2027-09-12

Survivor FRA follows age-60 attainment cohorts, reaching 67 for 1962+ Approximated

Interpretation and scope: DEFECT — no behavior change in this registry slice. survivorFraForBirthYear returns 66y8m for 1960 and every later effective birth year. For an effective 1962 birth, age 60 is attained in 2022, so section 416(l)(1)(E) supplies age 67; the companion fixture pins the statute-derived 804 months against the observed engine value of 800 months.

• 42 U.S.C. 416(l)(1)(D)
• 42 U.S.C. 416(l)(1)(E)
• 42 U.S.C. 416(l)(2)
• 42 U.S.C. 416(l)(3)(B)

Tested by: survivorBenefit.test.ts : “pins the separate survivor-FRA table for the 1962 age-60 cohort” , “pins the 1961 age-60 cohort at the engine’s 66y8m cap, not statutory 66y10m”

Implemented in: nra.ts ( survivorFraForBirthYear )

Verified 2026-08-26, re-verification due 2027-08-26

Survivor benefits are exempt from deemed filing, but a whole-plan survivor/own switch is not representable Out of scope

Interpretation and scope: model/plan.ts defines a Social Security stream with one `claimAge` whose years are schema-clamped to 62–70. annualSocialSecurity.ts derives both the own and survivor ages from that same stream field, so no accepted Plan can supply the two claim dates a switch requires (including a survivor-only claim at 60). The separate planner-ui survivorSwitching view illustrates two dates but does not make them ledger inputs.

• 42 U.S.C. 402(r)(1)
• 42 U.S.C. 402(r)(2)
• SSA POMS GN 00204.035, § B

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( socialSecurityIncomeSchema ) ; annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2027-08-26

TIPS acquisition premium reduces OID under acquisition-premium rules Out of scope

Interpretation and scope: The absence surface is model/plan.ts, ladder/ladderMath.ts, and projection/simulate.ts. tipsLadderSchema stores only target real income, payout years, and an optional aggregate purchase transfer; ladderMath.ts retains synthetic rung cost but no holder basis, issue price, or acquisition-premium ledger, and simulate.ts carries no premium balance to offset OID. Bond premium amortization under section 171 is registered separately at irc-171-tips-bond-premium-amortization.

• Treas. Reg. 1.1275-7(f)(3)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: ladderMath.ts ( LadderRung ) ; plan.ts ( tipsLadderSchema ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

TIPS bond premium amortization requires bond-level facts Out of scope

Interpretation and scope: The absence surface is model/plan.ts, ladder/ladderMath.ts, and projection/simulate.ts. tipsLadderSchema stores only target real income, payout years, and an optional aggregate purchase transfer; ladderMath.ts retains synthetic rung cost but no holder basis or issue-price ledger, and simulate.ts carries no premium balance to offset coupon or OID. A taxable account costBasis is an aggregate brokerage basis and cannot identify a TIPS rung or a section 171 election, so it is not an accepted premium fact. Acquisition premium on TIPS is registered separately at treas-reg-1-1275-7-f-3-tips-acquisition-premium.

• IRC 171(a)(1)
• Treas. Reg. 1.171-2(a)(1)
• Treas. Reg. 1.171-2(a)(3)(iii)
• Treas. Reg. 1.1275-7(f)(3)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: ladderMath.ts ( LadderRung ) ; plan.ts ( tipsLadderSchema ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

TIPS deflation adjustments reduce interest with an ordinary-loss carry limit Approximated

Interpretation and scope: DEFECT — no behavior change in this registration slice. projection/internal/tipsLadderAnnualCashFlow.ts computes `accretion` as `outstandingFace * Math.max(0, inflFactor - prevInflFactor)`, so a deflation year contributes no negative adjustment, no ordinary-loss carry, and no interest reduction. A paired market path with prior positive inflation followed by deflation drives the gap: the authority reduces current interest (and may permit a bounded ordinary loss), while the engine still reports the coupon as taxable ordinary income. The fixture adds 100,000 of ordinary wages so the tax line remains above zero and pins the produced annual MAGI. The basis decrease under (f)(2) is registered separately at treas-reg-1-1275-7-f-2-deflation-basis-decrease-not-modeled.

• Treas. Reg. 1.1275-7(f)(1)(i)

Tested by: federalTax.test.ts (paired positive-inflation then deflation path; 2027 non-maturity) : “pins the engine output while distinguishing the deflation reading”

Implemented in: ladderMath.ts ( ladderRealFlowsAtOffset ) ; plan.ts ( tipsLadderSchema ) ; tipsLadderAnnualCashFlow.ts ( tipsLadderAnnualCashFlows ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

TIPS deflation basis decrease is not modeled Out of scope

Interpretation and scope: The absence surface is ladder/ladderMath.ts and projection/internal/tipsLadderAnnualCashFlow.ts: ladder accretion is clamped at zero and no holder-basis ledger records deflation adjustments taken into account under (f)(1). Omitting the (f)(2) basis decrease leaves basis too high and can understate later gain tax when that basis is recovered, but that limb is separate from the income-year clamp registered at treas-reg-1-1275-7-f-1-deflation-adjustment-income.

• Treas. Reg. 1.1275-7(f)(2)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: ladderMath.ts ( LadderRung ) ; plan.ts ( tipsLadderSchema ) ; tipsLadderAnnualCashFlow.ts ( tipsLadderAnnualCashFlows ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2027-08-27

Tax-exempt interest enters neither leg of the net investment income tax Settled

• IRC 103(a)
• IRC 1411(c)(1)(A)(i)
• IRC 1411(d)

Tested by: federalTax.test.ts : “keeps tax-exempt interest out of investment income and out of the threshold leg”

Implemented in: federalTax.ts ( computeFederalTax )

Verified 2026-08-07, re-verification due 2027-08-07

Taxable-account basis and holding period are properties of a lot Approximated

Interpretation and scope: Approximated rather than out of scope because the engine emits a realized gain or loss for every taxable sale; nothing here fails closed. Both of its errors run in both directions, which is why the direction cannot be narrowed: the basis recovered on a partial sale is too high or too low depending on which lots a first-in-first-out or specific-identification seller would have sold, and the missing holding-period character understates tax on a short-term sale and overstates it on a long-term one. The average-cost approximation is defensible for a long-horizon projection and indefensible for a filing-grade statement of a particular year, and the two uses are not distinguished here. Across a full drawdown the account-level ratio and true lot accounting converge, because every lot is eventually sold and the total basis is the same either way, so the approximation costs little over a lifetime. It costs a great deal in any single year a user might act on. The missing holding-period character is the larger of the two gaps and is not an approximation at all: it is a fact the engine never had, since no lot acquisition dates enter the account model, and no convention over a single blended number can recover it.

• 26 CFR 1.1012-1(c)(1)(i)
• 26 CFR 1.1012-1(e)(1)(i)-(ii)
• IRC 1222(3)

Tested by: seppHsaAndCharacter.approximation.test.ts (basis recovered on a partial sale of two lots) : “recovers blended basis where the regulation charges the earliest lot” , “takes one cost-basis figure for the account and no lot at all”

Tested by: seppHsaAndCharacter.approximation.test.ts (holding-period character of the realized gain) : “reports gain with no holding period, so short-term and long-term are one number” , “never receives an acquisition date it could derive one from”

Implemented in: taxableWithdrawalCharacter.ts ( classifyIndividuallyOwnedTaxableWithdrawal ) ; annualAnnuityPurchaseFunding.ts ( annualAnnuityPurchaseFunding )

Verified 2026-09-08, re-verification due 2027-09-08

Terminal HSA inclusion omits the 223(f)(8)(B)(ii)(I) predeath-expense reduction Approximated

Interpretation and scope: The helper preserves the existing spouse-zero versus gross-for-other decision. Overstatement is claimed only for the omitted (B)(ii)(I) expense reduction at a stipulated death value, a fixed comparison heir rate, and a designated non-spouse natural-person case. A spouse destination follows (A) and is a zero inclusion. Charity exemption, generic default destination, and Form 8606 basis remain outside this helper. The nonSpouse enum also stands in for unmodeled legal classes, including an estate, for which (B)(ii)(I) does not reduce the inclusion. Missing legal beneficiary class, death date or value, and qualifying predeath expense and payment facts stay disclosed rather than inferred from healthcare spending or reimburseLater, which debit a different household cost. The companion fixture stipulates no relevant estate tax, so the (B)(ii)(II) section 691(c) deduction is zero and does not move the delta. The 223(f)(4)(B) additional-tax death exception remains a separate out-of-scope record; this metric is not that waiver.

• IRC 223(f)(8)(A)
• IRC 223(f)(8)(B)(i)
• IRC 223(f)(8)(B)(ii)(I)
• IRC 223(f)(8)(B)(ii)(II)

Tested by: estateHsa.approximation.test.ts : “taxes ending HSA gross at the heir rate and omits the predeath-expense reduction”

Implemented in: estateHsaIncome.ts ( estateHsaIncomeBase )

Verified 2026-09-04, re-verification due 2027-09-04

Terminal estate basis is spread across the household traditional pool Approximated

Interpretation and scope: The referent is assumed future income-tax exposure allocated per account, not a death-year filing tax. Inheritance is not a section 408(d)(1) distribution, so this terminal metric is a planning stand-in for later section 72 recovery, not Form 8606 in the year of death. Compare applies the helper's household-basis fraction to every traditional gross, inherited included; this rationale fixture isolates the owned-account slice by carrying no inherited traditional balances, so the all-traditional formula reduces to owned gross only. On that public-path three-account couple fixture (one year 2026, both age 60, zero growth and spending, 25 percent heir rate, three 120,000 non-spouse traditional accounts, 90,000 of basis on p1's IRA only) the authority worksheet is taxable bases 30,000 / 120,000 / 120,000 and haircuts 7,500 / 30,000 / 30,000. The helper returns 90,000 / 90,000 / 90,000 and haircuts 22,500 / 22,500 / 22,500. p1's IRA overstates assumed future exposure; the spouse IRA and the 401(k) understate it. The three haircuts sum to 67,500 under both readings because the rate and destination are common; that cancellation is a fact of this fixture only. On the mixed-destination two-IRA cells in the same fixture (p1 non-spouse, p2 spouse, 25 percent heir rate, 90,000 basis on p1 only or p2 only) the authority aggregate haircuts are 7,500 and 30,000 while the helper returns 18,750 in both cells, so the household aggregate can overstate or understate assumed future exposure depending on which owner holds the basis; a spouse destination's zero haircut is the terminal metric's existing valuation convention, not an automatic statutory rollover or tax exemption. An IRA-only cross-owner reading (75,000 / 75,000 / 120,000) and an ignore-basis reading (120,000 / 120,000 / 120,000) are the other candidate allocations the three-account cell rejects. The exclusions 408(d)(2) does not state in its own words — spouses file separate Forms 8606; an employer plan is not an individual retirement plan under 7701(a)(37) — are the publication-level and definitional boundaries the helper ignores, not a second reading of 408(d)(2) alone.

• IRC 408(d)(1)
• IRC 408(d)(2)
• IRC 7701(a)(37)
• Instructions for Form 8606 (2025), More than one Form 8606 required
• IRS Publication 590-B (2025), Inherited from someone other than spouse

Tested by: estateBasis.approximation.test.ts (owned cross-owner IRA-plus-401(k) household and mixed-destination IRA cells) : “returns the household-spread vector, not the owner-retained or alternative-allocation readings”

Implemented in: estateTraditionalBasis.ts ( estateTraditionalTaxableBase )

Verified 2026-09-04, re-verification due 2027-09-04

The $255 Social Security lump-sum death payment is outside the Plan Out of scope

Interpretation and scope: The engine has no death-payment surface at all — no simulate.ts pass emits a lump sum and no accepted input feeds one — and the further statutory facts (fully or currently insured status as such, the application within two years, alternative payees) have no Plan fields. A married couple where one dies is expressible, so outOfScope does not rest on unrepresentable household facts. A one-time $255 payment is an absence, not an approximation, because the engine emits no figure the rule could correct.

• 42 U.S.C. 402(i)
• 20 CFR 404.390

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( socialSecurityIncomeSchema )

Verified 2026-08-26, re-verification due 2027-08-26

The 0.5% floor on an itemizer’s charitable contributions Settled

• IRC 170(b)(1)(I)
• IRC 170(b)(1)(H)
• IRC 170, Editorial Notes, Effective Date of 2025 Amendment, Pub. L. 119-21, sec. 70425(c)

Tested by: charitableAndSection68.approximation.test.ts : “allows only the excess over the floor” , “allows nothing for a gift that does not clear the floor” , “does not reach a year the floor does not govern”

Implemented in: annualQcdItemizedSection170Ledger.ts ( stageAnnualQcdItemizedSection170Ledger ) ; annualCharitableDeductionParameters.ts ( annualCharitableDeductionParameters ) ; federalTax.ts ( charitableAfterFloor )

Verified 2026-09-05, re-verification due 2027-09-05

The 10 percent additional tax falls on the includible portion Settled

Interpretation and scope: The includible portion is whatever character the upstream path produces. For owned IRAs that is the annual section 408(d)(2) pro-rata calculation against the owner-wide Form 8606 IRA pool, so this rule sits downstream of the basis-recovery rule rather than restating it. Employer plans are not in that pool: the accepted traditional-employer-plan character path recovers after-tax employee basis by single-distribution pro rata against the pre-distribution account balance under section 72, so the taxable treatment amount bound into the penalty evaluator is the ordinary-income segment of that accepted character. That is also why the additional tax cannot be computed from the distribution amount alone.

• IRC 72(t)(1)

Tested by: ownedNonRothIraPenaltyPrerequisite.test.ts : “charges the additional tax on the taxable half of a basis-bearing distribution”

Implemented in: ownedNonRothIraPenaltyPrerequisite.ts ( evaluateOwnedNonRothIraPenaltyPrerequisites ) ; traditionalEmployerPlanPenaltyPrerequisite.ts ( evaluateTraditionalEmployerPlanPenaltyPrerequisite )

Verified 2026-08-03, re-verification due 2027-08-03

The 2026 HSA base limits are 4,400 self-only and 8,750 family Settled

Interpretation and scope: Section 223(b)(2) supplies the self-only and family coverage categories, while Rev. Proc. 2025-19 publishes the inflation-adjusted 2026 dollar amounts. The projection reads those values from the versioned parameter pack; the age-55 catch-up and the monthly/Medicare limits are separate records.

• IRC 223(b)(2)(A)
• IRC 223(b)(2)(B)
• Rev. Proc. 2025-19, section 2.01(1)

Tested by: simulate.contributions-growth.test.ts : “matches the published 2026 self-only and family HSA limits”

Implemented in: year2026.ts ( year2026 ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-27, re-verification due 2026-12-25

The 2026 basic exclusion amount is a chapter 11 credit base, not an income-tax deduction Out of scope

Interpretation and scope: Transfer-tax computation, not income tax. tax/federalTax.ts returns chapter 1 income tax and never reads a basic exclusion amount. projection/compare.ts's heirTax and endingAfterTaxEstate discount inherited pre-tax balances at assumptions.heirTaxRatePct; that is an income-tax-basis estate metric, not the section 2001 tax or the section 2010 credit. The $15,000,000 figure is pinned on ParameterPack.transferTax.basicExclusionAmount from 2010(c)(3)(A); indexing does not begin until a decedent dying after 2026, so 2026 is the unindexed statutory year. Do not treat this record as the same tax base as irc-151-d-5-C-senior-deduction-not-indexed. Portability is registered at irc-2010-c-5-dsue-portability-election-not-modeled.

• IRC 2010(a)
• IRC 2010(c)(1)
• IRC 2010(c)(2)
• IRC 2010(c)(3)(A)
• IRC 2010(c)(3)(B)
• IRC 2010, Editorial Notes, Effective Date of 2025 Amendment

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( planSchema ) ; year2026.ts ( year2026 ) ; types.ts ( ParameterPack )

Verified 2026-09-12, re-verification due 2027-01-10

The 30 percent capital-gain-property ceiling is not an input or calculation surface Out of scope

• IRC 170(b)(1)(C)(i)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( itemizedDeductionsSchema )

Verified 2026-08-27, re-verification due 2027-08-27

The 36-month extended period of eligibility tests SGA by month Approximated

Interpretation and scope: The companion fixtures use the same expressible 20,281-dollar annual wage total after trial work has ended. When it is earned in January alone, January and the next two months are payable under the grace rule and payment restarts from April, for a 24,000-dollar annual benefit on a 2,000-dollar PIA. When it is spread at more than monthly SGA across all twelve months, only the three grace months are payable, for 6,000 dollars. annualSocialSecurity.ts cannot distinguish the two monthly histories and produces its whole-year SGA suspension for both. The taxpayer-tax direction changes with the monthly pattern and with the account used to fill any spending shortfall.

• 20 CFR 404.1592a(a)(2)(i)
• 20 CFR 404.1592a(b)(2)(ii)

Tested by: simulate.social-security.test.ts : “cannot distinguish January-only EPE from every-month SGA on annual wages”

Implemented in: plan.ts ( socialSecurityIncomeSchema ) ; annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan ) ; disability.ts ( ssdiSuspendedBySga )

Verified 2026-08-27, re-verification due 2026-12-25

The 403(b) 15-year catch-up is not the 414(v)(1) Roth-mandated catch-up Out of scope

Interpretation and scope: This is not a duplicate of irc-414-v-7-A-high-earner-roth-catch-up-mandate: that record covers the 414(v)(1) catch-up, including SIMPLE IRA and Roth-program limbs. The missing 402(g)(7) membership facts are gated in model/plan.test.ts.

• IRC 414(v)(7)(A)
• IRC 402(g)(7)(A)

Tested by: no fixture, by design: the engine refuses this rule rather than modeling it

Implemented in: plan.ts ( traditionalAccountSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-26, re-verification due 2027-08-26

The 414(v)(7) wage test uses a user-entered Box 3 proxy, and omission fails closed Approximated

Interpretation and scope: The mandate itself is enacted; the approximation is the input. Inferring Box 3 from current-year wages, MAGI, or the HCE test would invent a wage test the statute does not use and would over-apply the mandate to self-employment and to wages from a different employer. Leaving the field at zero matches T.D. 10033's no-FICA result and is the fail-closed reading the fixtures pin. The field is a single static figure for every contribution year 2026 and later; the engine does not reconstruct a year-by-year Box 3 series.

• IRC 414(v)(7)(A)
• T.D. 10033, preamble on FICA wages and self-employment
• Notice 2025-67, section on the Roth catch-up wage threshold

Tested by: rothCatchUpWageProxy.approximation.test.ts (omitted prior-year FICA fails closed to not subject) : “does not infer Box 3 from current-year wages when the field is omitted”

Implemented in: plan.ts ( traditionalAccountSchema ) ; employerRothCatchUp.ts ( priorYearFicaExceedsRothCatchUpThreshold ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-19, re-verification due 2027-08-19

The 60 percent ceiling on cash gifts is not applied to the projected charitable deduction Approximated

Interpretation and scope: This is the timing case the errorDirection doc comment describes, and the sign really does turn on the year rather than being undetermined. In the gift year the engine’s deduction is too large and tax is understated; in a succeeding year when the statutory carryforward is usable, the engine’s deduction is too small because the carryforward is absent, and tax is overstated. It need not net to zero: if a carryforward remains unused through expiry, the engine’s year-one generosity is a permanent understatement. Nor is an annual projection indifferent to which year a deduction lands in, since the year decides the bracket it offsets and the capital-gain stacking threshold. Itemized deductions do not directly reduce AGI or IRMAA MAGI. effectiveFrom is 2018 because the projection gap — no percentage ceiling and no carryforward — predates the 2025 amendment: packForYear supports earlier years via a first-pack stand-in, and computeFederalTax for 2025 returns the raw gift without applying any (G)(i) cap even under the pre-amendment 60-percent-of-base reading. The amendment note quoted below preserves that historical reading without pretending the post-amendment net-of-(A) formula governed 2018. The sibling settled record irc-170-b-1-G-cash-percentage-ceiling keeps effectiveFrom 2026 because it states the current combined ceiling only; this approximated record’s broader date reflects the wider temporal scope of the live omission, not a different claim about the statute. The correct implementation lives in packages/engine/src/actions/annualQcdItemizedSection170Ledger.ts and is registered at irc-170-b-1-G-cash-percentage-ceiling; the live path does not reach it.

• IRC 170(b)(1)(G)(i)
• IRC 170(b)(1)(G)(ii)
• IRC 170(b)(1)(G)(i), Editorial Notes, Amendments, 2025, prior text
• IRC 170, Editorial Notes, Effective Date of 2025 Amendment, Pub. L. 119-21, sec. 70425(c)

Tested by: charitableAndSection68.approximation.test.ts (an $80,000 gift against a $100,000 contribution base) : “deducts a gift above the ceiling in full in the year it is made” , “understates tax in the gift year” , “overstates tax in the following year, which is why the direction is bothDirections” , “has nowhere to put a carryforward, however it is supplied”

Implemented in: federalTax.ts ( itemizedTotal )

Verified 2026-09-05, re-verification due 2027-09-05

The AMT exemption phases out at 50 percent from 2026 Settled

Interpretation and scope: One authority per claim in the statement, because each claim rests on a different provision. 55(d)(2) carries the reduction formula and the not-below-zero floor; its 25 percent is the unmodified figure the substitution below replaces, so the two have to be read together. The codified 55(d)(4)(A)(ii) carries the rest: subclause (I) substitutes the 1,000,000 dollar threshold and subclause (IV) substitutes 50 percent for 25 percent. 55(d)(4)(B)(i) carries the indexing, and independently names the 1,000,000 dollar amount as the subparagraph (A)(ii)(I) amount. Paragraph (2)(A) is the joint-return figure and (B) is 50 percent of it, which is where the 500,000 dollar amount for an unmarried taxpayer comes from. The enrolled bill is kept beside it as the amending authority, because (IV) exists only because section 70107(c) added it and a reader tracing the 50 percent figure should be able to see the instruction that created it. Corrected 2026-08-04: an earlier version of this record said neither uscode.house.gov nor law.cornell.edu carried the amended text and cited the enrolled bill alone for that reason. That was true when the quote sweep ran and is no longer true -- uscode has since published the OBBBA text. A rationale that explains why a citation looks unusual has to be re-checked when the reason expires, or it becomes the next stale claim. Corrected again on the same day: this paragraph opened "Two authorities" after two more were added, so it failed its own instruction inside one commit. The count is now stated nowhere in this paragraph, because a number in prose beside a list is a second place to keep in step, and this one had already gone stale once. Extended on 2026-08-04: the statement keys the figures to filing status, and effectiveFrom keys the whole record to 2026, and neither was visible in what was quoted. Both were one clause away in spans already cited -- the chapeau continues into subparagraphs (A) and (B), which tie the amounts to paragraph (1)(A) and (1)(B), and section 70107 continues into subsection (d), which supplies the applicability date. The date deliberately stays in effectiveFrom rather than being added to the statement: a structured field already carries it, and restating it in prose would create exactly the second place to keep in step that this paragraph gave up its own count to avoid. The chapeau was widened in place. The enrolled bill could not be, because subsections (c) and (d) are not contiguous in the enrolled text: govinfo prints a codification annotation between them, and that annotation is the publisher speaking rather than Congress, so it cannot sit inside a quotedText. That left an elision or a split, and a split is better here -- each subsection is then quoted whole and verbatim, which is what a reader checking the citation expects to find, and neither quote depends on the checker honouring an ellipsis to read as accurate.

• IRC 55(d)(2), phase-out chapeau and subparagraphs (A)-(B)
• IRC 55(d)(4)(B)(i), inflation adjustment
• IRC 55(d)(4)(A)(ii), as amended by Pub. L. 119-21
• Pub. L. 119-21, sec. 70107(c) (OBBBA)
• Pub. L. 119-21, sec. 70107(d) (OBBBA), effective date

Tested by: federalTax.test.ts : “reduces the exemption by fifty cents per dollar above the threshold”

Implemented in: year2026.ts ( year2026 ) ; federalTax.ts ( amtExemptionAmount )

Verified 2026-08-04, re-verification due 2026-12-02

The HSA establishment date is per account, and relates back only on a test Approximated

Interpretation and scope: Approximated rather than out of scope because the relate-back test is not refused, it is skipped: the engine computes a qualified amount from the owner-level date and returns it. The per-person shape is right for the common case and wrong for a narrow one, which is what makes it worth recording rather than fixing in passing. Most households with two HSAs opened the second while still holding the first, or funded it by transfer, and in both of those cases the single owner-level date is exactly correct. The shape cannot express the failing case at all: the establishment record is keyed by person, the allocation names a source account, and nothing joins the two, so no caller can supply account-level dates even where they have them. Repairing it is a change to the evidence contract rather than to a calculation, which is why it is recorded here instead of patched.

• IRS Notice 2008-59, A-41
• IRS Notice 2008-59, A-40

Tested by: seppHsaAndCharacter.approximation.test.ts (expense incurred between two establishment dates) : “qualifies a distribution from the newer account against the older account date” , “has no shape in which the two accounts could carry different dates”

Implemented in: annualHsaReimbursementLedger.ts ( evaluateAnnualHsaReimbursementLedger )

Verified 2026-08-04, re-verification due 2027-08-04

The OASDI contribution and benefit base is wage-indexed, not price-indexed Settled

Interpretation and scope: The parameter pack carries the base but no engine calculator reads it yet, and the engine has no national-average-wage path to carry it forward on: the plan supplies a general inflation assumption and nothing else. When a calculator does read it, scaling by general inflation will be a stand-in for wage indexing rather than a reading of section 230, and this record is where that has to be said. The same caution applies to the retirement earnings test exempt amounts, which are wage-indexed by the same ratio.

• 42 USC 430(b)
• SSA, Cost-of-Living Increase and Other Determinations for 2026, 90 FR 49047 (Nov. 3, 2025)

Tested by: params.test.ts (The price reading takes the 2025 base of 176,100 and the benefit increase the same notice announces for 2026.) : “derives the base from the wage index rather than from prices”

Implemented in: year2026.ts ( year2026 ) ; types.ts ( ParameterPack )

Verified 2026-08-03, re-verification due 2026-12-01

The PIA formula is marginal across two bend points Settled

Interpretation and scope: The bend points are not fixed dollar figures. Section 415(a)(1)(B) sets them at 180 and 1,085 dollars for 1979 eligibility and re-derives them for every later year from the ratio of the national average wage index two years prior to the 1977 index, which is why the engine carries a table by eligibility year rather than a constant.

• 42 U.S.C. 415(a)(1)(A), (a)(1)(A)(i)-(iii)

Tested by: piaFromEarnings.test.ts : “applies each rate only to the earnings inside its own band”

Implemented in: piaFromEarnings.ts ( piaMonthlyFromAime ) ; ssaWageData.ts ( PIA_BEND_POINTS )

Verified 2026-08-04, re-verification due 2026-12-02

The QLAC premium cap is a household-wide running total that moves in ten-thousand-dollar steps Settled

Interpretation and scope: The regulation moves the cap as a step function while the projection multiplies it by a continuous inflation factor, so a projected year can sit between two published steps and a premium within one step of the cap can read as eligible when the regulation would refuse it, or the reverse. The error is bounded by a single ten-thousand-dollar step. Holding the step would require index values for years that have not happened, so the continuous factor is the same deliberate approximation taken for every other limit that borrows the section 415(d) mechanism. WHAT THIS RECORD DOES NOT COVER, added 2026-08-07 so the statement above is not read for more than it settles. The statement describes the cap as one running total across every retirement arrangement of an individual, and that is what the subsection says; it is not what this engine enforces. The projection holds each purchase to the cap on its own and never reads what another contract has already used, so a household with two QLACs can exceed the total without anything objecting. That gap is registered and pinned separately at treas-reg-1-401-a-9-6-q-2-ii-qlac-premium-cap-across-every-contract. What remains settled here is the FIGURE the pack carries and the indexing mechanism that produces it.

• Treas. Reg. 1.401(a)(9)-6(q)(2)(ii), (q)(4)(ii)(A)
• Notice 2025-67, section on the qualifying longevity annuity contract limitation

Tested by: params.test.ts : “carries the published cap on a ten-thousand-dollar step”

Implemented in: generators.ts ( annuityPurchaseGenerator ) ; year2026.ts ( year2026 ) ; annualAnnuityPurchaseFunding.ts ( annualAnnuityPurchaseFunding ) ; simulate.ts ( simulatePlan )

Verified 2026-08-03, re-verification due 2026-12-01

The QLAC premium cap is checked one contract at a time, not against the household’s running total Approximated

Interpretation and scope: PINNED FIGURES. A 76-year-old with a 1,000,000 dollar traditional IRA and a 0 percent return pays two 150,000 dollar QLAC premiums in 2026 out of that IRA, 300,000 together against a 210,000 cap. Neither premium exceeds the cap alone, so the per-contract test the engine applies is silent and no warning fires. The 2026 requirement is unaffected either way, resting on the prior December 31 balance. In 2027 the accepted reading has 210,000 of QLAC-eligible premium outside the base and the excess 90,000 still inside it, for a base of 747,805.91 and a requirement of 32,655.28; the engine puts the whole 300,000 outside, for a base of 657,805.91 and a requirement of 28,725.15. The gap is 3,930.13 in that year and it recurs. DIRECTION. Understates tax, by the same route the QLAC carve-out itself runs: a smaller base is a smaller required distribution, less ordinary income in the year, and a larger balance compounding into later years. WHAT THE ACCEPTED READING TAKES AS GIVEN. The regulation says a premium above the limitation means the contract is not a QLAC, and it supplies a correction mechanism rather than an arithmetic haircut. This record does not re-derive that; it takes the engine’s OWN convention for a single over-cap contract — reduce the premium to the cap, warn, and treat the excess as ineligible, which treas-reg-1-401-a-9-6-q-2-qlac-premium-dollar-limit registers as settled — and asks only that the cap be the running total the subsection defines rather than a fresh allowance per contract. The departure is therefore about the AGGREGATION and nothing else, which is why the fixture holds every other term fixed and varies only the number of contracts. NOT THE SAME RULE AS THE CAP’S VALUE. That the pack carries 210,000 for 2026, and that a projected year multiplies it by a continuous inflation factor rather than stepping it, are both settled at treas-reg-1-401-a-9-6-q-2-qlac-premium-dollar-limit and are not restated here. WHAT IT WOULD TAKE TO FIX. A per-owner running total carried across the purchase pass and reduced by every QLAC premium already funded in the projection, ordered by purchase year and then by a stable account order so the reduction is deterministic; premiums in the same year would have to agree on an order before the second one could be measured against the first. It is not done here. This record was opened on 2026-08-07 while the neighbouring commence-by-the-required-beginning-date defect was being closed, because the reg was open and the gap was found rather than because it was in that slice’s scope.

• Treas. Reg. 1.401(a)(9)-6(q)(2)(ii), (q)(4)(ii)(A)
• Treas. Reg. 1.401(a)(9)-5(b)(4)

Tested by: iraAnnuityCharacter.approximation.test.ts (two contracts against one cap) : “lets a second QLAC spend the whole cap again” , “says nothing while the pair passes the cap”

Implemented in: annualAnnuityPurchaseFunding.ts ( annualAnnuityPurchaseFunding ) ; simulate.ts ( simulatePlan )

Verified 2026-08-07, re-verification due 2027-08-07

The RMD applicable age steps 72 to 73 to 75, never 74 Settled

Interpretation and scope: The engine maps birth year to applicable age rather than restating the attainment windows, which is equivalent: a 1959 birth attains 73 in 2032, inside the window, while a 1960 birth attains 73 in 2033 and 74 in 2034, landing in the later rule. Expressing it by birth year is why no 74 appears anywhere in the code, and that absence is correct rather than a missing case.

• IRC 401(a)(9)(C)(v)

Tested by: objectives.cohortBoundary.test.ts (objective bridge window ends at the cohort-dependent applicable age) : “keeps ages 73 and 74 in the window for the first 75-cohort (born 1960)” , “ends the window at the applicable age for the final 73-cohort (born 1959)” , “changes nothing reachable for pre-1951 cohorts, whose applicable age already passed”

Tested by: rothBridgeHeadroom.test.ts (detector bridge window ends at the cohort-dependent applicable age) : “last included year is age 74 for the first 75-cohort (born 1960)” , “last included year is age 72 for the final 73-cohort (born 1959); the RMD start year is excluded”

Tested by: params.test.ts : “sends the first post-window cohort straight to 75”

Implemented in: objectives.ts ( bridgeYearFilter ) ; rothBridgeHeadroom.ts ( rothBridgeHeadroom ) ; index.ts ( rmdStartAgeForBirthYear ) ; annualOwnerRmdPlan.ts ( annualOwnerRmdPlan ) ; applicableAge.ts ( applicableAgeAttainYears )

Verified 2026-08-29, re-verification due 2027-01-26

The Roth catch-up wage threshold moves in five-thousand-dollar steps Settled

Interpretation and scope: The pack carries the published 2026 step. The projection now reads that figure for the 414(v)(7)(A) wage test; the character mandate and the Box 3 input proxy are registered separately at irc-414-v-7-A-high-earner-roth-catch-up-mandate and irc-414-v-7-A-prior-year-fica-wage-proxy. What remains settled here is the FIGURE and the five-thousand-dollar rounding, not the character of the catch-up.

• IRC 414(v)(7)(A), (v)(7)(E)
• Notice 2025-67, section on the Roth catch-up wage threshold

Tested by: params.test.ts : “carries the adjusted threshold on a five-thousand-dollar step”

Tested by: employerRothCatchUp.test.ts (an increase of 4,999.99 holds the prior step) : “holds 150,000 when the COLA increase is 4,999.99”

Tested by: employerRothCatchUp.test.ts (an increase of 5,000 is a whole step) : “returns 155,000 when the COLA increase is 5,000”

Implemented in: year2026.ts ( year2026 ) ; types.ts ( rothCatchUpWageThreshold ) ; employerRothCatchUp.ts ( indexRothCatchUpWageThreshold )

Verified 2026-08-03, re-verification due 2026-12-01

The Roth contribution income phase-out is not modeled Approximated

Interpretation and scope: Recorded as an explicit gap rather than left silent, because the direction of the error is knowable: a high income household will show Roth contributions it could not actually make, and the overstatement grows with income. The engine never applies the section 408A(c)(3) phase-out in any pass; there is no later clawback once adjusted gross income is known, and the classification stays approximated.

• IRC 408A(c)(3)(A)

Tested by: simulateContributionsAndQcd.approximation.test.ts : “funds a Roth IRA for a single filer far above the phase-out range” , “charges the same contribution at an income the phase-out does not reach”

Implemented in: plan.ts ( rothAccountSchema ) ; annualContributionsAndEmployerMatch.ts ( annualContributionsAndEmployerMatch ) ; simulate.ts ( simulatePlan )

Verified 2026-08-29, re-verification due 2026-12-27

The SALT cap is a schedule and reverts to 10,000 in 2030 Settled

Interpretation and scope: The cap is halved for a married individual filing separately, which the projection cannot express because it collapses every filing status to single or married-filing-jointly. The high-income phase-out that OBBBA also added is not modelled either — that gap is registered separately as irc-164-b-7-B-magi-phasedown — so the cap here binds later than it would for a taxpayer above that threshold.

• IRC 164(b)(6)(B)
• IRC 164(b)(7)(A)

Tested by: federalTax.test.ts : “drops the cap to ten thousand for years after 2029” , “compounds the one percent steps on the preceding year through 2029” , “does not carry the 2025 figure back before the schedule begins”

Implemented in: year2026.ts ( year2026 ) ; federalTax.ts ( saltCapForYear )

Verified 2026-08-04, re-verification due 2027-01-01

The SSDI family maximum is AIME-based, not the retirement/survivor bend-point formula Approximated

Interpretation and scope: Section 403(a)(6)'s 85/100/150 percentages are the controlling disability-family formula. POMS RS 00615.736 is omitted here because it instructs the ordinary PIA bend-point maximum for people who become disabled — the exact retirement/survivor reading this record rejects. The sign is not one-sided in taxpayer-tax terms: a too-large or too-small Social Security amount changes taxable benefits, and a spending shortfall can instead be funded with withdrawals whose tax character depends on the account used.

• 42 U.S.C. 403(a)(6)

Tested by: simulate.social-security.test.ts : “uses the retirement/survivor maximum for an SSDI worker and spouse”

Implemented in: annualSocialSecurity.ts ( annualSocialSecurity ) ; simulate.ts ( simulatePlan ) ; familyMaximum.ts ( capAuxiliaryForFamilyMaximum , familyMaximumMonthlyFromPia )

Verified 2026-08-27, re-verification due 2027-08-27

The Social Security base amounts are fixed dollars, and the joint figure is not double Settled

Interpretation and scope: The base amount is zero rather than 25,000 for a married taxpayer who files separately and did not live apart from the spouse for the whole year, which makes the whole benefit taxable at the 85 percent rate. The engine has no married-filing-separately status, so that case cannot arise; the record notes it because a later filing status added without reading 86(c)(1)(C) would inherit the unmarried figure and understate the tax by the largest margin the section allows.

• IRC 86(c)

Tested by: params.test.ts (Values are the joint adjusted base amount, above which up to 85 percent of the benefit is included.) : “keeps the joint amounts at the figures the statute states” , “is the opposite of the standard deduction, which does double”

Implemented in: year2026.ts ( year2026 ) ; federalTax.ts ( taxableSocialSecurity )