every model spec’d & versioned · Concordance-tested changelog →

Vendor review

Due diligence

The answers a vendor review asks for, on one page, so you can get most of the way through your questionnaire before you talk to us. Every limitation below is extracted from the model specification that governs it, so nobody can soften one here without changing the contract itself — and the section on what we don’t have is not an appendix.

What the service is, and what it is not

What are we actually buying, and where does your responsibility end?

Worthune is a computation service. You send a household or a set of inputs; we return computed results and an evidence record that lets anyone re-derive them from a published specification. We do not hold accounts, execute trades, custody assets, or communicate with your clients.

We are not an investment adviser and give no investment advice. Results are mathematical projections under assumptions you supply or select, and they are hypothetical: they do not reflect actual trading and are not a guarantee of future results. Every projection surface renders that language alongside the numbers, and your compliance team can append firm-specific text to it.

  • No trading, execution, custody, or money movement.
  • No account aggregation — you send us a normalized household.
  • No house view: capital-market assumptions and mortality tables come from you or from a profile you select.
  • No advice to a named individual, from us, in any channel.

Assumptions governance

Who chose the assumptions behind a number, and can we prove it later?

Assumptions are versioned objects, not settings. An organization creates an assumption profile with a required provenance statement saying where its figures came from, and every profile version is immutable once an evidence record references it. A profile cannot be edited after the fact to make an old result look different.

Each computed response echoes the assumptions it used and the source it resolved them from, so a reviewer reading a stored result a year later can see which profile version was in force without asking us.

  • Profiles are org-scoped, versioned, and immutable once referenced.
  • Provenance text is required at creation — a profile with no stated source cannot be saved.
  • The engine never selects assumptions on a caller's behalf, and no AI feature chooses them.
  • White-label tenants bind a profile, so an embedded surface cannot silently use a different one.

How a number is verified before release

How do we know the arithmetic is right?

Every model is written twice from one published specification: the production engine and an independent reference implementation, in different languages, built without sight of each other. Randomized cases compare the two on every commit, and disagreement beyond one part in a billion fails the build — the model does not ship.

Two implementations written from one specification are wrong in the same way only if the specification itself is wrong, which is the one class of error a human review can catch and a test suite cannot. Constants are carried in a registry where each entry cites its primary source and carries a check date; a constant that ages out is demoted rather than served quietly.

  • Specifications are published, versioned, and changelogged.
  • Each response pins the specification version that produced it.
  • Every response carries an evidence record with a digest that any third party can re-run against the public checker.
  • Errata are published rather than silently corrected.

Data handling

What do you store, where does it go, and how do we get it out?

Single calculations are stateless: inputs are computed and not stored. Stored households exist only when you create them through the household endpoints, and they hold the household document you sent — financial structure, not identity documents. We do not ask for and have no field for a Social Security number, an account number, or a date of birth finer than a birth year.

Subprocessors and their roles are listed in the Data Processing Addendum, which is the controlling statement; the AI features send content to a model provider only when you call them, and never as part of a calculation.

  • Transport is TLS throughout; the database provider encrypts at rest.
  • Data is segregated by organization at the query layer, and a deployment without billing configured refuses to serve tenant surfaces rather than risk serving across them.
  • Retention windows are executable code with a weekly sweep, not a policy document — the windows in the code are the policy.
  • Compliance artifacts — the request audit log and terms acceptances — are deliberately retained with no scheduled purge.
  • Households and decisions are never deleted by a sweep: evidence integrity means archive rather than delete, and removal happens through organization offboarding, which leaves a tombstone digest.
  • Export is the same API you write with — every stored object is readable back through it.

Security controls in place

What is actually implemented, today?

The controls below are implemented and covered by tests in the codebase. This is a description of a system, not a certification: see the next section for what we do not have.

  • Per-organization tenancy with org-scoped API keys, and role-based access — a viewer key cannot write, and tenant, legal, embed and audit surfaces require an owner key.
  • A request-level audit trail covering API outcomes, agent tool access, administrative actions, key lifecycle, and scheduled jobs, exportable through the API.
  • Self-service key rotation, webhook-secret rotation with a dual-accept window, and embed-secret rotation with immediate cutover.
  • Per-organization rate limits on stateful surfaces; model runs are never metered or throttled.
  • Credentials are never carried in URLs; keys are stored as hashes.
  • Outbound webhook delivery re-checks its destination at delivery time and refuses private address ranges.
  • Scheduled jobs and administrative routes fail closed when their secrets are absent, rather than running unauthenticated.
  • Click-through acceptance of the terms and the addendum is recorded append-only and enforced at key issuance — a subscription without recorded acceptance issues no key.

What we do not have

Where are the gaps?

A vendor review is worth more when the vendor names its own gaps, so here are ours as of the date on this page.

  • No SOC 2 report. The policy work is done and the Type I audit is triggered by the first enterprise letter of intent; we will not imply a certification we do not hold.
  • No SSO. Access is by API key with roles; SAML and OIDC are built when a contract requires them.
  • No penetration-test report from a third party.
  • No formal SLA instrumentation, and no uptime commitment beyond what a contract states.
  • State income tax covers a subset of states, with the excluded ones named per state in the specification rather than approximated silently.
  • Married-filing-separately and head-of-household are approximated with single-filer ceilings, disclosed on every affected response.

Methodology disclosures

Every model states, in its published specification, the boundaries it chose (exclusions) and the defects we have found and not yet fixed (known issues). Those are different things and are kept apart. What follows is 212 exclusions and 101 known issues across 61 models in 9 families, lifted from the specifications themselves.

The full specification for any model — inputs, formulas, constants and their sources, verification anchors, changelog — is linked from the catalog.

Housing & mortgages

rent vs. buy, refinance break-even, down payment, points, PMI, ARM vs. fixed

rent-vs-buy

Exclusions

  • No selling costs, no capital-gains treatment, no tax deductions, no closing costs on purchase, no PMI below 20% down.
  • Buyer's net worth ignores the cash-flow ledger entirely (costs enter only through the renter's investable difference) — the standard "equal-outlay" comparison.

Known issues

  • rentPortfolio floors at 0 — a renter deep underwater stops losing, which slightly favors renting in extreme cost gaps.

refinance

Exclusions

  • Payment-delta ≠ interest-delta: extending the term lowers the payment while potentially raising lifetime interest; this model compares cash flow to the move date only, and says so. Total-interest comparison is a candidate v1.1 output.
  • No points/rate trade-off modeling, no PMI changes, no tax effects, no reinvestment of the monthly savings.

down-payment

Exclusions

  • The projection always runs the full 600 months regardless of when the goal is hit; projectedSavings is not truncated at the goal month.
  • No PMI, closing-cost, or home-price-appreciation modeling; the target is fixed at computation time.
  • Contributions are end-of-month (no intra-month return on the deposit).

Known issues

  • Sentinel ambiguity: a goal reached exactly at month 600 is indistinguishable from "never reached" — both return monthsToGoal = 600. The first-crossing guard (monthsToGoal === 600) is also what makes the sentinel work, so a fix must change both.
  • The sentinel yields yearsToGoal = 50 exactly; the UI's "50+ yrs" display checks yearsToGoal > 50, which never fires — the never-case renders as "50.0 yrs".
  • Sentinel is the number 600, not Infinity — callers must treat it as "never".

second-home

Known issues

  • Tax/maintenance are charged on purchase price forever (rent-vs-buy uses appreciated value) — understates late-year costs; cross-model inconsistency worth a product decision.
  • Net costs in (8) are undiscounted/uncompounded nominal sums.

points-break-even

Exclusions

  • Full-term hold: lifetime savings assume the loan runs to term. Selling or refinancing before break-even forfeits the points — that is the point of the break-even output.
  • Points paid in cash at closing (not financed); no tax deductibility of points.

Known issues

  • Adversarial review 2026-08-14: an earlier pre-release draft used a 9999 sentinel, which legitimate break-even values can reach and exceed (e.g. a 0.001-point rate reduction on a large loan). Fixed pre-release: Infinity sentinel + explicit zero-cost rule.

pmi-removal

Exclusions

  • Original-value LTV only: no home appreciation, no reappraisal-based early cancellation, no extra principal payments — this is the contractual/scheduled cancellation path (the federal Homeowners Protection Act framework: borrower may request at 80%, automatic at 78%, based on the original amortization schedule).
  • PMI cost is flat monthly (no rate-based recalculation as balance falls).

arm-vs-fixed

Exclusions

  • One deterministic adjustment to a single assumed rate, held to payoff. Real ARMs adjust periodically with caps and an index; this model answers "what if it adjusts to X and stays there" — the honest scenario question, not a rate forecast.
  • Both loans held to full term; no refinance-before-adjustment path.

biweekly-mortgage

Exclusions

  • True biweekly interest accrual (26 periods on a 14-day grid) is NOT simulated; the 13/12-monthly equivalence slightly understates the acceleration benefit (by the intra-month timing of half-payments). The contract states the rule so the number is reproducible, not mysterious.
  • No lender biweekly-program fees.

extra-payment

Exclusions

  • The extra amount is applied every month from month 1, entirely to principal (after normal interest accrual), with no prepayment penalty.
  • No comparison against investing the extra amount — that trade-off is the student-loan-payoff model's job.

Known issues

  • Adversarial review 2026-08-14: an earlier pre-release draft rounded the payment half-up, which could round it to at-or-below monthly interest for small-balance/high-rate/long-term inputs — a rounding-induced perpetuity. Fixed pre-release by the ceilCents rule above.

Retirement & withdrawal

FIRE, Roth vs. traditional, conversion ladders, RMDs, Social Security timing

fire

Exclusions

  • Savings amount is fixed forever (no raises, no inflation adjustment of expenses or the FIRE target); contributions are annual, end-of-period.
  • retirementAge compares against the balance before that year's growth, consistent with the recorded series.

Known issues

  • The FIRE number is in today's dollars while growth is nominal — use a real (inflation-adjusted) expectedReturn for a consistent read. (v1.0.1 removed the dead inflationRate input that implied otherwise.)
  • Sentinel: retirementAge = 100 also means "not reached by 100"; indistinguishable from genuinely reaching it at 100.

roth-vs-traditional

Exclusions

  • No employer match, no RMDs, no contribution-limit distinction between Roth/Traditional, no state taxes, single flat rate at each end.
  • Because both paths compound identically, the entire outcome is decided by the two tax rates; time horizon scales the gap but never flips it.

Known issues

  • The off-by-one-flavored "years + 1 contributions" convention (record then update) is intentional-looking but worth an explicit product decision; it slightly overstates both paths symmetrically.

roth-conversion-ladder

Exclusions

  • The TY2026 bracket table is applied to every ladder year: no bracket inflation, no rate-schedule changes. Ladder taxes in later years are therefore an estimate in current-law, current-year terms.
  • Federal only — no state income tax on conversions.
  • annualOtherTaxableIncome is already taxable income; the model applies no standard deduction (a deduction would double-count).
  • The 5-year mapping accessibleInYear = y + 5 is exact in calendar-year terms: the statutory clock starts January 1 of the conversion year, so a rung converted in ladder year y (calendar year Y + y − 1) is penalty-free on January 1 of calendar year Y + y + 4 — ladder year y + 5. (A late-December conversion waits barely four elapsed years, but the ACCESS YEAR is the one this model reports.)
  • IRMAA surcharges, ACA subsidy cliffs, and the pro-rata rule for after-tax basis are out of scope (see backdoor-roth for pro-rata).

backdoor-roth

Exclusions

  • Existing IRA balances are 100% pre-tax: no prior nondeductible basis is carried in. With prior basis the taxable fraction would be lower.
  • The $7,500 contribution ceiling is the under-50 TY2026 limit; the age-50+ catch-up ($1,100, for an $8,600 total per the same IRS Notice 2025-67 COLA table) is not modeled.
  • Conversion happens in the contribution year with zero interim earnings; any earnings between contribution and conversion would be taxable on top.
  • The pro-rata fraction is fixed at conversion time. Strictly, Form 8606 computes it from the December 31 year-end aggregate; a year-end balance differing from totalIraBalance (growth, rollovers) shifts the real fraction.
  • marginalRate is supplied, not derived — compose with capital-gains / ladder models or the facts-registry brackets when the marginal rate itself is in question.
  • 401(k)-side "mega backdoor" is a separate model (mega-backdoor-roth).

mega-backdoor-roth

Exclusions

  • Contributions are constant every year for n years; no limit growth, no salary linkage (salary is dead), no catch-up contributions.
  • The taxable path taxes only the annual drag — no capital-gains tax on liquidation at the horizon, and no LTCG-vs-ordinary distinction (the drag uses incomeTaxRate).
  • Roth conversion is frictionless and instant (no gains between contribution and conversion, no pro-rata complications).

Known issues

  • Dead input: salary is accepted but never read (not even destructured).
  • standardRothWealth is misnamed — it is the *taxable-account* counterfactual (the interface comment "just standard Roth IRA" is wrong; the UI correctly labels it "Taxable Account (after tax)").
  • The 0.5 blend in taxDragRate is an invented constant, documented here as a modeling assumption — it is not derived from any tax rule.
  • Closed-form vs. chart mismatch: headline wealth is ordinary-annuity, yearlyData is annuity-due (step 8) — the chart's last point overshoots the metric cards by a factor of (1 + rate).
  • annualTaxSavingsAtWithdrawal is misnamed — it is additionalTaxFreeWealth / n, not a withdrawal-tax computation.
  • The UI metric card label says "IRS 415 Limit (2024)" while the value is the TY2026 $72,000 — stale label (display-only, outside this contract, but noted).

employer-match

Exclusions

  • Single-tier match formula only (rate × contributions up to a percent of salary). Multi-tier formulas ("100% of the first 3%, 50% of the next 2%") and dollar-cap formulas are not modeled.
  • Annual totals; no per-paycheck true-up modeling. Plans WITHOUT true-up can under-match front-loaded contributors — this model assumes the match is computed on annual figures (equivalently, a true-up exists).
  • The §402(g) limit is the under-50 employee deferral limit; catch-up contributions (age 50+, $8,000) are not added.
  • Compensation above the §401(a)(17) limit earns no deferral or match — the model caps it, matching qualified-plan law.
  • Employer match does not count against §402(g) (correct) and the §415(c) overall limit is not checked (match + deferral stay far below it inside this domain).
  • No vesting schedule — match dollars are counted when contributed.

Known issues

  • Adversarial review 2026-08-14 (fixed pre-release): an earlier draft ignored the §401(a)(17) compensation cap, overstating the match for salaries above $360,000 by up to 13% (e.g. $24,500 vs the legal $21,600 at a $450,000 salary with a 100%-of-6% formula) and telling those users to defer more than full match requires. Fixed with the cappedCompensation step above.

rmd

Exclusions

  • Uniform Lifetime Table only — assumes the owner's sole beneficiary is not a spouse more than 10 years younger (that case uses Table II, not modeled) and the account is not inherited (Table I / 10-year rule, not modeled).
  • The birth cohort is derived from currentAge under the pack's TY2026 pin. If the model is run in a later year without re-pinning, the cohort boundary (66/67) shifts by one per year.
  • Each year's RMD is computed on the running balance (start-of-year balance = prior year's ending balance), a standard projection convention; the statutory RMD uses the December 31 prior-year balance, which this equals when the year's growth is booked after withdrawal, as step 3 does.
  • Taxes on distributions are not modeled here (RMDs are ordinary income; compose with progressive-tax models for tax impact).

Known issues

  • Adversarial review 2026-08-14 (fixed pre-release): an earlier draft pinned the RMD age at 73 for the whole domain, which is wrong law for owners aged 60–66 in 2026 (born 1960+, statutory age 75) — on a $1M balance projected 30 years from age 60, the error moved ending balance by roughly 8%. The draft's firstRmdAge = max(currentAge, 73) also reported an 80-year-old's "first RMD age" as 80. Fixed with the cohort rule above and the rename to rmdStartAge.

ssa-pia

Exclusions

  • AIME computation from a wage history (indexing factors, top-35 selection) — a later version; the earnings record is upstream.
  • Eligibility years other than 2026. Bend points index to the AWI; each year is a new registry pair.
  • Month-granular claiming — claiming ages are whole years here; SSA adjusts by month.
  • Spousal, survivor, and disability benefits; the family maximum; the earnings test; WEP/GPO (repealed 2025, noted for history); Medicare premium withholding.
  • COLA after claiming — amounts are in eligibility-year dollars.

social-security-timing

Exclusions

  • Benefits are not COLA-indexed: the nominal monthly benefit is constant for life, and inflation enters only through the discount rate. Combined with the 1 + r − i approximation, the "discounted" totals are approximate real present values at currentAge.
  • Annual (not monthly) payment granularity; a full year of benefits is credited at each integer age including lifeExpectancy.
  • No taxation of benefits, no spousal/survivor benefits, no earnings test.

Known issues

  • "67" naming is hardcoded while the actual start age is fullRetirementAge: cum67/lifetimeBenefit67/cumulative67, breakEvenAge62vs67, breakEvenAge67vs70, and the optimalClaimAge literal 67 all mean "FRA", not literally 67.
  • Break-even sentinels collide with real values: "never crosses" returns 62 (resp. 67), the same numbers a genuine immediate break-even would produce.
  • Break-evens are nominal, optimal age is discounted — the two outputs answer different questions and can disagree.
  • Negative discount exponents for ages before currentAge (currentAge up to 70) inflate rather than exclude already-past benefit years.

Equity comp & taxes

AMT on ISO exercise, QSBS, 83(b), wash sales, RSUs, ESPP, capital gains, income cliffs, state income tax

iso-exercise

Exclusions

  • AMTI proxy. Real AMTI starts from taxable income and adds back AMT-disallowed deductions (the standard deduction, SALT, and others, §56(b)). This model treats ordinaryTaxableIncome as both the regular-tax base and the pre-preference AMTI. Where the taxpayer's regular deductions exceed their AMT-allowed deductions — which is the common case — the model understates AMTI and therefore the AMT. Documented tradeoff for a deduction-free input contract (the same pattern as capital-gains's NIIT MAGI proxy).
  • Capital gains and qualified dividends are excluded. They are taxed at the same preferential rates under AMT (§55(b)(3)) but shift both bases; combining is the caller's job — see capital-gains.
  • The AMT credit (§53): amtTopUp is the carryforward candidate for future years, but credit recovery is not projected.
  • Disqualifying dispositions (same-year sale converts the spread to ordinary income and removes the preference) are out of scope.
  • The $100,000 ISO limit (§422(d)) is a grant-level qualification rule, not modeled.
  • MFS and head-of-household filing statuses; state AMT (notably CA); NIIT (no investment income in this model); payroll taxes; multi-year exercise laddering (run the model once per candidate year).

qsbs-exclusion

Exclusions

  • Eligibility is assumed, not tested. Original-issuance acquisition from a domestic C corporation, the active-business/qualified-trade requirements (§1202(c), (e)), and the aggregate-gross-assets test — $50,000,000 at issuance for legacy stock, $75,000,000 for after-2025-07-04 issuances (§1202(d)(1), indexed from 2027) — are the caller's representations.
  • No tax dollars are computed. The included portion's 28%-rate-class treatment and the capped portion's LTCG treatment interact with the taxpayer's other income; use capital-gains for band math (its spec excludes the 28% class — the interaction is documented, not modeled).
  • The AMT preference is reported as an add-back amount only; feed it to an AMT computation (iso-exercise models the §55 machinery) manually. The 7% rate is applied uniformly to sub-100% exclusions; the historical pre-2001-acquisition preference-rate variations are not modeled (all in-domain acquisition periods postdate 2000, except that the 50% band starts 1993-08-11 — for 1993–2000 acquisitions the 7% figure is an approximation, stated here).
  • Married-filing-separately halving (§1202(b)(3)), §1045 rollovers, per-issuer aggregation across simultaneous sales, empowerment-zone variants (§1202(a)(2)), the (b)(4)(B) cross-regime reduction nuance beyond priorExclusionsUsed, and state non-conformity (notably CA) are out of scope.
  • Whole-year holding granularity; the legacy statute's "more than 5 years" is modeled as holdingYears ≥ 5.

83b-election

Exclusions

  • Ordinary-income layer only. Capital gains at sale (elect: everything above fmvAtGrant from the grant date; no elect: everything above each vest-date FMV, from each vest date) are not simulated — the basis outputs and the capital-gains model cover the sale year. Holding-period differences are prose, not numbers.
  • The 30-day election deadline (§83(b)(2)) is a note, not an input — the model assumes a timely election is available.
  • Constant ordinaryTaxableIncome and constant TY2026 brackets across all vest years (same convention as roth-conversion-ladder); no discounting; deterministic geometric FMV path.
  • Forfeiture is priced only as forfeitureTaxAtRisk — no probability weighting.
  • Cliff and monthly vesting schedules (annual tranches only), RSUs (§83(b) unavailable — prose note), §83(i) deferrals, early-exercise ISO/NSO interactions (see iso-exercise), payroll/FICA taxes, NIIT, the §83(b) basis interaction with a nonzero pricePaid disposition, and state tax are out of scope.

wash-sale

Exclusions

  • One sale lot, one replacement lot. Multiple tax lots, partial fills, and the ordering rules for matching multiple purchases to multiple sales (Rev. Rul. 70-231's chronological matching) are out of scope.
  • Substantially identical is the caller's determination — the model does not opine on share classes, options, contracts to acquire, or "similar" funds. Options and short sales (§1091(e)–(f)) are out of scope entirely.
  • Cross-account and IRA replacements are out of computation scope. Prose warning the spec commits to: a replacement purchase inside an IRA triggers §1091 and the disallowed loss is permanently lost — no basis adjustment anywhere (Rev. Rul. 2008-5). Everywhere else, wash-sale defers the loss; it does not destroy it.
  • Holding-period tacking (§1223(3): the sold shares' holding period attaches to the washed replacement shares) is a prose note, not an output.
  • Year-boundary timing (a December loss deferred into January's basis), the $3,000 capital-loss limitation, and netting against gains belong to the capital-gains layer, not here. Gains on the sale (the model clamps to loss ≥ 0). State conformity. Dividend-reinvestment micro-purchases (a replacement purchase is a replacement purchase).

retirement-income-cliffs

Exclusions

  • Income proxies. Taxable income is proxied by ordinary income + taxable SS (no standard/itemized deduction — overstates tax); IRMAA-MAGI's AGI is proxied the same way. Documented tradeoff for a deduction-free contract, the capital-gains/iso-exercise pattern.
  • IRMAA timing. Real IRMAA uses a two-year MAGI lookback (2026 premiums keyed to 2024 MAGI). The model prices this year's MAGI at this year's tier table — the planning question ("what will this conversion do to a future year's premiums") — and does not simulate calendar years. The lookback is named here so no one reads the output as this year's premium change.
  • All additionalIncome is ordinary; capital-gain character (and its separate stacking) is capital-gains' turf. NIIT excluded. The 2026 senior deduction (OBBBA §70103) and all other deductions excluded.
  • IRMAA: both-spouses-enrolled doubling for MFJ; Part B and Part D surcharges only (no base premiums, no Part D plan premium); married-filing-separately tiers out of scope; life-changing-event appeals (SSA-44) out of scope; immunosuppressive-drug-only coverage tiers out of scope.
  • ACA: 48-contiguous-states + DC FPL only (AK/HI have higher guidelines); the tax-family = coverage-family simplification; cost-sharing reductions, employer-coverage affordability tests, and the Medicaid gap are out of scope. Below 100% FPL the model reports no subsidy — in expansion states the household would typically be Medicaid-eligible instead, which is prose, not math.
  • One tax year, TY2026 constants throughout; no discounting.

rsu

Exclusions

  • Every year's sale is taxed entirely as ordinary income at the vest price — the sell-at-vest idealization. There is no capital-gains treatment of post-vest appreciation even though currentPrice grows between years.
  • Salary is constant; no FICA/Medicare, no withholding-vs-liability distinction, no standard deduction (the bracket stack uses gross income).
  • State tax is a flat user-supplied rate on the full proceeds (see step 3.4).

Known issues

  • holdingPeriodYears is misnamed — it is the number of modeled selling years, not a holding period; nothing is held.
  • filingStatus has no UI control (always "single" in production), yet the married table is live code — keep both in the vector set.
  • Bracket boundary is inclusive (income exactly at a bracket top is fully taxed inside that bracket; the next rate starts strictly above it).

espp

Exclusions

  • Immediate-sale (disqualifying disposition) scenario only. Qualifying dispositions (2 years from grant + 1 from purchase, part of the gain re-characterized at LTCG rates) are not modeled in v1.
  • FICA on the bargain element is not added — correctly so: under IRC §3121(a)(22) (AJCA 2004), §423 ESPP spreads are excluded from FICA wages regardless of disposition, including disqualifying ones.
  • Contribution is treated as a single purchase-date pool: no intra-period share price averaging across paychecks.
  • Sale exactly at priceAtPurchase — no price movement between purchase and sale, no commissions.
  • The $25,000 §423 cap is NOT recomputed against grant-date FMV: the domain only caps contributions, so in-domain inputs can imply share purchases a real plan would truncate at the FMV cap.

Known issues

  • Adversarial review 2026-08-14 (fixed pre-release, doc-only): the FICA exclusion was originally justified with backwards law (§423 spreads are FICA-excluded under IRC §3121(a)(22) regardless of disposition — the exclusion was right, the stated reason wrong), and the §423 $25,000 cap claim overstated what the contribution-only domain enforces. Both statements corrected; formulas unchanged.

capital-gains

Exclusions

  • Gains only — loss netting, the $3,000 ordinary-income offset, and carryforwards are not modeled.
  • The LTCG bands are keyed to taxable income; the model uses ordinaryTaxableIncome + gains directly, which is exact under the statute's taxable-income definition given the input is already taxable income.
  • NIIT MAGI is approximated by taxable income + gains. Real MAGI is AGI (pre-deduction) with add-backs, which is HIGHER — so the model can understate NIIT near the threshold. Documented tradeoff for a deduction-free input contract.
  • Collectibles (28%), §1250 unrecaptured gain (25%), and qualified small-business stock rates are not modeled. State tax excluded.

Known issues

  • Adversarial review 2026-08-14 (fixed pre-release): the LT effective rate was originally named effectiveLongTermRate while excluding NIIT — misleading next to totalTax/afterTaxGain, which include it. Renamed to effectiveLongTermRateExNiit.

quarterly-estimates

Exclusions

  • The 110% trigger is the non-MFS threshold; married-filing-separately ($75,000) is not modeled (no filing-status input).
  • Prior-year harbor assumes a full 12-month prior tax year (a §6654 precondition).
  • Four equal installments only — the annualized-income installment method (uneven income within the year) is out of scope.
  • Withholding is treated as evenly credited (its statutory default); installment timing penalties within the year are not computed.
  • Federal only; state estimated-tax regimes differ.

Known issues

  • Adversarial review 2026-08-14 (fixed pre-release): an earlier draft computed the payment fields before the de minimis test, so a taxpayer under the $1,000 threshold could see deMinimisNoPenalty: true next to a positive quarterlyPayment — two contradictory signals. Fixed: de minimis now zeroes the payment fields.

state-income-tax

Exclusions

  • State deductions, exemptions, and base modifications are not applied. IL's per-person exemption, PA's eight-class income definition, CO's federal-taxable-income base, CA/NY standard deductions, NJ's exemptions, and VA's age deductions are all upstream of this model's input. The caller — later, the household projection — owns the state-taxable-income derivation.
  • New York's tax-benefit recapture (supplemental tax) is not modeled — the pure marginal table understates NY tax for high incomes where the recapture phases out lower-bracket savings.
  • Massachusetts's separate rates for short-term capital gains (and collectibles) are not modeled; the table applies to ordinary income.
  • Washington's capital-gains excise is out of scope. WA has no tax on wage/ordinary income but levies a 7% excise on long-term gains above an annual deduction, with a surtax above $1M of gains (RCW 82.87, WA DOR).
  • New Hampshire's interest-and-dividends tax is repealed effective taxable periods beginning after 2024-12-31 (NH DRA).
  • Local income taxes are not modeled (NYC and Yonkers resident taxes, PA municipal earned-income taxes, and similar).
  • Credits, AMT-like add-ons, and recapture are not modeled.

Longevity, insurance & care

longevity horizon, annuity payout, life-insurance need, long-term care, estates

longevity-horizon

Exclusions

  • Population, period mortality. The SSA table is all-covered-worker mortality frozen at 2023 rates: no cohort improvement (younger users' actual longevity is likely better than period tables imply), and no annuitant/insured selection. Personal health, smoking status, and socioeconomic gradients are out of scope.
  • Sex-distinct only, because the source table is; blended or unisex views are out of scope (run both and compare).
  • Integer-age granularity; the planning age is an integer age, not an interpolated fraction.
  • This model states probabilities; it does not recommend a spending rule. Cross-links: social-security-timing (claiming math), rmd (drawdown minimums), long-term-care (tail-cost sizing).

annuity-payout

Exclusions

  • This is the actuarially fair payout under population mortality. Real SPIA quotes are lower for two compounding reasons the model deliberately excludes: insurer loads (expenses, profit, capital) and annuitant self-selection (annuity buyers live longer than the population table assumes, which *reduces* fair payouts further). The model is the clean upper benchmark, and says so.
  • Single life, level payments, annual mode, no period-certain, no cash refund, no COLA/inflation rider, no joint-and-survivor — each of those is a different contract, not a variant of this one.
  • Sex-distinct pricing (the table is sex-distinct); some markets require unisex pricing, which is out of scope.
  • The pricing rate is an input, not a market lookup; no yield curve (one flat rate), and taxes (exclusion ratio) are out of scope.

life-insurance-needs

Exclusions

  • A needs *sizing*, not an underwriting or product recommendation: term vs permanent, laddering, riders, and premiums are out of scope.
  • Level real income need over the whole replacement window (no step-downs as children age out); survivor Social Security benefits, spousal earnings changes, and taxes on the invested benefit are out of scope — each would lower the need, so the model errs conservative and says so.
  • Education is a lump input, not a per-child projection (529-college-savings models the projection; cross-link).
  • liquidAssets nets against needs dollar-for-dollar; illiquid assets (home equity) deliberately don't appear.

long-term-care

Exclusions

  • No contributions to savings — balances only grow at annualReturn and shrink by withdrawals.
  • Insurance benefits are a flat dailyBenefit × 365 per care year with no benefit inflation rider.
  • Premiums are level (no age-rated increases) and, in the headline totals, stop at care start.

Known issues

  • Benefit-period ignored in the trajectory: the yearly loop applies the insurance benefit for every care year, while ltcInsuranceTotalBenefit caps at ltcInsuranceBenefitPeriodYears — the chart and the out-of-pocket totals disagree whenever careDurationYears > ltcInsuranceBenefitPeriodYears.
  • Premiums diverge between headline and trajectory: totals stop premiums at care start; the loop charges them for the entire window (through care + 5 years).
  • Two inflation conventions: the headline total prices all care years at care-start cost; the loop keeps inflating during care.
  • "Impact" outputs are usually negative (initial minus final balance, with growth included) — a gain is reported as a negative impact.
  • annualReturn and ltcInsuranceBenefitPeriodYears have no UI control — users can never change them from 0.06 / 3.

eldercare

Exclusions

  • Care costs come from the hardcoded five-row table above, uninflated over the whole projection.
  • Parent assets grow at your annualReturnRate until care starts, then deplete with no growth during care.
  • Your projection horizon is a fixed 30 years from today — your own age plays no role in the model (which is why the yourAge input was removed in v1.0.1).
  • Your care burden is modeled purely as reduced contributions — never a withdrawal from principal (see issues).

Known issues

  • Burden capped at your savings rate: in the loop your contribution floors at 0, so when annualCareTypeCost > yourMonthlySavings × 12 the excess is silently unpaid — retirementSavingsImpact understates the cost, and disagrees with yourShareOfCost (which bills the full shortfall years).
  • Chart parentAssets resurrects: outside the care window the field shows the full undepleted parentAssetsAtCareStart, including in the years *after* care ends.
  • Chart cumulativeCost is wrong twice over: it multiplies by (y + 1) — years since *today*, not years you've actually paid — and snaps back to 0 in any non-paying year.
  • parentAssetsRunoutAge has no "never" sentinel: assets lasting the whole window return careStartAge + careDurationYears, identical to running out in the final year.

Estate & legacy

estate-tax exposure, step-up vs. gift-now basis, the inherited-IRA 10-year rule, QCDs, 529 superfunding

estate-planning

Exclusions

  • retirementAccounts is assumed to already be *inside* totalEstateValue; it only adds the 24% income-tax haircut, it is not added to the gross estate.
  • 24% effective income-tax rate on inherited retirement distributions (step 7) — an inline modeling assumption, not a registry fact. It approximates heirs' blended ordinary-income rate over the (post-SECURE) 10-year distribution window.
  • Life insurance is fully includible in the gross estate (no ILIT).
  • Flat top-rate federal tax above the exemption (no graduated sub-$1M brackets); flat user-supplied state rate on the entire adjusted estate (no state exemption or brackets); no portability, no marital deduction.
  • The projection ignores the retirement-account income tax and treats cumulative gifting as a simple linear subtraction.

Known issues

  • State tax has no exemption — any nonzero stateTaxRate taxes from the first dollar, unlike every real state regime.
  • giftingBenefit10Years is a nominal 10-year sum unrelated to yearsToProject and never feeds the tax outputs.

step-up-vs-gift-now

Exclusions

  • Single asset, single horizon, constant appreciation. Both arms end at the same horizon; post-death appreciation is out of scope.
  • Estate tax is not modeled here — that is the estate-planning model's job. For estates above the exemption the bequest arm carries estate-tax consequences this comparison deliberately does not net.
  • The gift arm assumes a sale at the horizon. An heir who never sells never pays the embedded-gain tax; the advantage shown is the liability difference at a sale, which is the honest way to price the basis treatment.
  • Loss assets excluded by constraint (costBasis ≤ assetValue): §1015's dual-basis rule for loss property (and the wasted loss on gifting) is not modeled — sell first, harvest the loss, gift cash.
  • Not modeled: gift-tax payable (exclusion/exemption usage is reported, tax is not computed), GST tax, community-property double step-up, carryover-basis holding-period tacking, state regimes, wills/trusts/probate, legal advice.

inherited-ira-10-year

Exclusions

  • Flat marginal rate across all ten years and both schedules. A bunching-driven bracket jump is exactly what the caller should probe by re-running with different rates per schedule; the model refuses to guess a bracket path.
  • Applies to non-eligible designated beneficiaries. Eligible designated beneficiaries (surviving spouse, disabled/chronically ill, minor child until majority, beneficiary within 10 years of the decedent's age) have other options not modeled here.
  • Annual RMD minimums within the 10 years are not modeled (v1 limitation, disclosed): when the owner died on/after their required beginning date, years 1–9 carry single-life-table minimums. The even schedule generally dominates those minimums early; the lump schedule may violate them — treat the lump arm as the analytical bound it is. Single-life-table support arrives with a registry transcription of the table, not before.
  • Not modeled: state tax, IRMAA/SS-taxability interactions of the withdrawal income, Roth inherited IRAs (no tax — the timing question collapses), estate-tax basis interactions, trusts as beneficiaries.

qcd

Exclusions

  • Flat marginal rate; the AGI channel is excluded. Lower AGI from a QCD can reduce IRMAA surcharges, Social Security taxability, and AGI-floored deductions — real benefits this model does not compute (the household engine's IRMAA machinery is the right tool for that interaction).
  • Per-person cap. Spouses each have their own limit from their own IRAs; run the model per spouse.
  • Not modeled: the one-time $55,000 split-interest QCD (CRUT/CRAT/CGA mechanics), the deductible-IRA-contribution offset rule (post-70½ deductible contributions reduce QCD exclusions), donor-advised funds / private foundations / supporting organizations (statutorily ineligible recipients — route gifts accordingly), state tax treatment.

plan529-superfunding

Exclusions

  • The 529 arm assumes qualified withdrawals — non-qualified withdrawals owe tax plus penalty on earnings and would erase the advantage shown.
  • Exclusion arithmetic uses the current-year exclusion for all five years. The exclusion indexes upward, so real capacity in later years is at least what is shown; the model does not forecast IRS inflation adjustments.
  • Donor death during the five-year spread claws unspread years back into the estate — reported here as an exclusion, not modeled.
  • Not modeled: state 529 deductions/credits (state regimes are a published exclusion for this family), other same-year gifts to the same beneficiary competing for the exclusion, GST allocation, plan-level contribution maximums (state-set), financial-aid treatment.

Debt & loans

payoff strategies, student loans, auto loans, loan comparison, card minimums

debt-payoff

Exclusions

  • Fixed minimum payments per debt; no minimum-payment recalculation as balances fall. The total monthly budget is likewise fixed at totalMinimums + extraMonthlyPayment — a retired debt's minimum rolls into the strategy payment instead of disappearing.
  • All debts start at month 0; no new charges.
  • If all starting balances are ≤ 0.01 in total, both strategies return months: 0 with a single schedule entry.

Known issues

  • interestSaved = snowball − avalanche is expected to be ≥ 0 now that both strategies spend the same fixed budget every month (avalanche is the interest-minimizing greedy allocation under a fixed budget). It is exactly 0 whenever the two orderings coincide (e.g. a single debt). Tiny negative values from floating-point noise are conceivable in exact-tie configurations, though none are known; callers should treat small negatives as 0.
  • Minimum payments are capped at the balance and the strategy payment is capped at what's left — cash paid is never an output, but any future "total paid" output must sum the actual per-month outlay (min(totalMinimums + extra, balance after accrual)), not minimumPayment × months.
  • 600-month sentinel conflation (above); sentinel is a number, not Infinity.
  • Interest keeps compounding for the full 600 months when payments don't cover interest — totalInterest grows very large but stays finite.

student-loan-payoff

Exclusions

  • Fixed rate, fixed payments, no forbearance/IDR modeling.
  • Investment returns are untaxed; the loan-side tax deduction enters only through effectiveRate (recommendation), see issues.

Known issues

  • Mismatched horizons in netBenefitPayoff: interestSaved accrues over the *minimum-payment* horizon (up to payoffMonthsMinimum months) while investmentFVIfInvested is measured at the *aggressive* payoff month — nominal dollars from different dates are subtracted directly. The output systematically favors payoff.
  • taxDeductionRate affects only the recommendation via effectiveRate; the interest totals and interestSaved are pre-tax. The real student-loan interest deduction cap ($2,500/yr) and income phase-out are ignored entirely.
  • investmentReturn = 0 produces NaN for investmentFVIfInvested and netBenefitPayoff (0/0 in the annuity factor) — guarded only by the UI slider floor.
  • 600-month sentinel conflation on both payoff loops; when the payment doesn't cover interest, the balance grows unboundedly for 600 months and totalInterest* becomes very large but finite. Sentinel is a number, not Infinity.
  • Final-month interest is charged on the full month even when the closing payment is partial (slight interest overstatement in the payoff month).

auto-loan

Exclusions

  • Trade-in reduces the sales-tax base (most US states). States that tax the full price (e.g. a minority including California) will see slightly higher tax — out of scope; the model states one rule and names it.
  • No negative-equity rollover from a prior loan, no manufacturer rebates, no gap insurance or add-ons.
  • titleAndFees are NOT taxed (fee taxability varies by state and fee type; out of scope — the tax base is vehiclePrice − tradeInValue only).
  • Fully financed sales tax and fees (rolled into the loan) when they exceed cash paid — implied by step 3.

loan-comparison

Exclusions

  • Cost = lifetime interest + fees, undiscounted. No time-value adjustment between a shorter and longer term — a cheaper 30-year total can still be worse in present-value terms; this model compares nominal dollars and says so.
  • Same principal both sides; fees paid out of pocket (not financed).

credit-card-minimum

Exclusions

  • Minimum is interest + percent-of-balance with a dollar floor — the convention major US issuers adopted after the 2003 OCC negative- amortization guidance. Older pure-percent-of-balance formulas (which can never amortize) are deliberately not modeled: they would overstate the minimum-payment trap for modern cards.
  • No new charges, no fees, no promotional APR periods, fixed APR throughout.

Known issues

  • Adversarial review 2026-08-14: an earlier pre-release draft used a pure percent-of-balance minimum (pre-2003 convention), which produced never-amortizing paths and astronomically horizon-truncated interest figures presented as genuine dollars. Fixed pre-release: modern interest-plus-principal convention plus explicit never-pays-off flags.

Life decisions & household

relocation, a child, a wedding, a sabbatical, one income, divorce, windfalls

relocation

Exclusions

  • Salaries are used gross; taxes are the user's job to bake into inputs. Break-even uses the net *delta* while the wealth paths use each path's own gross surplus — the two outputs answer different questions.
  • No salary growth, no expense inflation, annual compounding of monthly contributions (contributions earn no intra-year return).
  • A negative move balance still compounds at annualReturn (symmetric growth on negative balances — effectively borrowing at the investment rate). Flagged below.

Known issues

  • Negative-balance compounding (above): overstates the move path's drag when movingCosts > currentSavings. Candidate v1.1 fix: floor at 0 or use a distinct borrowing rate.
  • Break-even sentinel is the number 9999, not Infinity — callers must treat it as "never".

having-a-child

Exclusions

  • One child, born at t = 0, costs smeared flat over exactly 18 years.
  • 529 contributions are modeled as an *extra* drag on savings (step 2) and also accumulate in their own bucket (step 5) — the 529 balance is not included in either retirement-wealth figure.
  • No cost inflation, no income growth, no child tax credits.

Known issues

  • savingsRateImpact is misnamed: it is baseMonthlySavings − reducedMonthlySavings, a USD/month amount, not a rate.
  • totalFirstYearCost is a pure echo of the firstYearCost input.
  • Cost roll-up double-structure (step 1): year 1 contributes firstYearCost *and* a childcare year when childcareYears ≥ 1, while ongoingAnnualCost covers 18 − childcareYears years rather than the "years 2–18" the interface comment claims.
  • FIRE-with uses the reduced savings rate forever (step 6), overstating fireImpactYears whenever FIRE lies beyond the 18 child years; and the FIRE number ignores child spending entirely. Sentinel 600 months on both sides can silently clamp the impact to 0.
  • yearlyData uses annual compounding, so its last element does not equal retirementWealthWithChild/retirementWealthWithout (chart and headline numbers disagree by construction).
  • The y < 18 switch in step 7 uses years-from-now; with the reduced savings already ending at 18 in step 4 they agree, but both silently assume birth at t = 0.

wedding

Exclusions

  • The wedding happens entirely at t = 0. In savings mode the counterfactual lump (the budget kept invested) also sits at t = 0; in debt mode there is no counterfactual lump at all.
  • In savings mode a budget larger than currentSavings drives the with-path starting balance negative; the negative balance compounds at annualReturn (a stylized borrowing-at-the-return-rate stand-in). This is the same documented negative-balance convention as relocation, whose move path starts at currentSavings − movingCosts and may go negative.
  • Debt carries no impact beyond the payment-vs-savings substitution during the repayment window — no credit-score, no minimum-payment dynamics.
  • debtInterestRate/debtRepaymentMonths are conditionally dead: in savings mode they do not affect wealthWithWedding, opportunityCostAtHorizon, netWealthImpact, or yearlyData — but they still drive the always-returned totalDebtCost.

Known issues

  • totalDebtCost is returned in savings mode too, computed from whatever the (hidden-slider) debt inputs hold — misleading alongside a savings-mode result.
  • netWealthImpact and opportunityCostAtHorizon are redundant exact negations.
  • yearlyData compounds annually while the headline wealth figures use the mixed annual/monthly closed form — the chart's final year does not equal wealthWithWedding/wealthWithoutWedding.
  • monthsToSave sentinel is 9999 and the quantity ignores both interest and existing savings.

divorce

Known issues

  • monthsToRebuildEmergencyFund is a constant 30 by construction — either surface the savings-rate input or drop the output.
  • Hardwired 20%/15% savings-rate assumptions are invisible to the user.
  • projectedRetirementAt65 is misnamed; breakEvenAge rounds to whole years.
  • Alimony/child-support tax treatment ignored (documented on-page).

sabbatical

Known issues

  • Compounding basis mismatch in step 1: the lump compounds annually, the annuity monthly; the with-path (step 5) compounds the lump *monthly*. The two paths therefore differ slightly even with a 0-month sabbatical. Candidate v1.1: one basis for both.
  • The FIRE target uses break spending as permanent spending.
  • Post-sabbatical salary assumed identical (no penalty, no growth).

one-income

Known issues

  • One-income savings are decoupled from the surplus: the model saves savingsRateOnOneIncome × afterTax1 even when oneIncomeMonthlySurplus is negative — simultaneously depleting runway and contributing to retirement. The two-income path, by contrast, saves its entire surplus. The asymmetry is documented, but candidate v1.1 should cap one-income savings at max(0, oneIncomeMonthlySurplus) or make the asymmetry a labeled choice.
  • FV lump uses annual compounding while contributions use monthly — same mixed-basis convention as sabbatical; consistent across both paths, so the *difference* is less distorted than the levels.
  • Runway ignores investment growth on savings during drawdown (simple division) — conservative, by declaration.

renovation

Exclusions

  • The renovation adds estimatedValueIncrease × currentHomeValue of value instantly at year 0, and that bump appreciates at the same rate as the rest of the house.
  • HELOC interest is not tax-deductible in the model; no closing costs.
  • netGain compares appreciated (future) home values against a nominal payment sum — no discounting anywhere.
  • Transaction/selling costs to realize the home-value gain are ignored.

Known issues

  • Dead inputs under "savings": helocRate and helocTermMonths are accepted but never read when fundingMethod === "savings" (the UI hides them, but the exporter still emits them; the oracle must ignore them on that branch).
  • Break-even sentinel is 999, not relocation's 9999 and not Infinity — the sentinels are inconsistent across models; callers must treat 999 as "never" here.
  • netGain mixes conventions: appreciated future values minus a nominal payment stream; opportunityCost (which includes principal) is computed but never enters any comparison output.
  • roi divides by renovationCost with no guard (out-of-domain 0 → Infinity/NaN).

windfall

Exclusions

  • Debt overflow is silently idle: if debtAmt > debtBalance, the excess is not re-routed to another bucket and earns nothing — it simply disappears from the projection (see issues).
  • Emergency fund earns 0% by design (stability, not yield).

Known issues

  • totalFutureValue mixes time frames: FVs at yearsToRetirement plus a flat 5-year interest estimate plus undated emergency dollars. Directionally useful, dimensionally impure — candidate v1.1: express everything as FV at the same horizon (interest saved compounded, debt overflow routed to taxable).

salary-jump

Exclusions

  • The jump happens instantly at t = 0; no salary growth on either path afterwards.
  • One flat marginalTaxRate applies to both salaries — a raise that would cross a bracket is not modeled.
  • FIRE expenses are derived from salary and savings rate (spend = after-tax minus savings), not entered directly.

Known issues

  • Mixed compounding basis in step 2 (lump annual vs annuity monthly) — same convention as sabbatical, consistent across both paths here so the *difference* is not biased, but the levels are convention-bound.
  • Sentinel soup: calcYearsToFire caps its loop at 600 months yet returns 50 (years) when unreached — a month-601 hit and a never-hit are indistinguishable, and 600/12 = 50 collides with the sentinel.
  • fireYearsGained clamps at 0 (step 5), hiding downgrades.
  • additionalWealth reduces algebraically to the annuity-factor times the monthly-savings delta; currentSavings cancels. Not a bug, but a fuzzer will find the output insensitive to it.

emergency-fund

Exclusions

  • Deposits land end-of-month, after interest; the goal check sees the start-of-month balance, so a deposit that crosses the target counts in the following month.
  • No inflation on the expense target; the target is fixed at t = 0.
  • If currentSavings ≥ targetAmount, monthsToGoal = 0 and interestEarned = 0.

Known issues

  • Sentinel collision: monthsToGoal = 240 means *either* "goal first reached at exactly month 240" *or* "never reached within 240 months" — the two are indistinguishable. The UI treats ≥ 240 as "Never". Correspondingly yearsToGoal = 20 is the never-sentinel in years.
  • When the goal is never reached, interestEarned is still computed — over the full 240-month window, not "to goal" as the name implies.
  • Chart arrays are hard-truncated at 61 elements (months 0–60): for slow savers the plotted series ends well short of the goal/sentinel.
  • target is duplicated into every projectedBalance element.
  • The monthlyExpenses > 0 guard on coverage returns 0 (not Infinity/NaN) at zero expenses; note targetAmount is then also 0, so the goal is met at month 0. Out of domain, but defined behavior.

Education

529 savings, private school

529-college-savings

Exclusions

  • Contributions stop at college start; no drawdown modeling during the college years (cost and balance are compared as lump sums at start).
  • 529 withdrawals assumed fully qualified (tax-free); no state tax deduction on contributions; no gift-tax or aggregate-limit checks.
  • Taxable gains taxed at ordinary income rate in one shot at college start.

Known issues

  • Chart costTarget disagrees with projectedTotalCost: the chart multiplies one inflated year of tuition by yearsInCollege flat ((1 + i)^y × yearsInCollege), while the headline cost keeps inflating through the college years (step 2). At y = N the chart target understates the real projected cost whenever i > 0.
  • requiredMonthlySavings silently reports 0 when N = 0 even with a genuine shortfall — 0 is doing double duty as "fully funded" and "no time left".
  • Closed-form monthly annuity for headline balances vs. annual-deposit loop for the chart (same class of mismatch as side-business); chart balanceTaxable is pre-tax.
  • taxAdvantage conflates tax treatment with any return-rate spread between annualReturn529 and annualReturnTaxable (the UI defaults them equal but only exposes a slider for the 529 rate).
  • Rate = 0 on either account → NaN (out-of-domain; keep rates positive).

private-school

Exclusions

  • Fixed 30-year projection horizon regardless of the child's or parent's age.
  • The public path invests the inflated tuition bills as annual deposits in the years they would have been paid, with annual compounding (the chart recurrence); the headline wealthWithPublic is defined as that recurrence's terminal value.
  • No financial aid, no tax treatment of anything, no college phase.

Known issues

  • Private headline vs. chart inconsistency remains: the private closed form (step 3, monthly compounding of contributions) still differs from the private chart column (annual compounding), and opportunityCostAtRetirement therefore mixes a chart-basis public number with a closed-form private number.
  • Unpayable tuition vanishes: when monthlyTuitionCost > monthlySavings, the floor in step 2 means the excess is never paid from anywhere — the private path looks cheaper than it is.

Startup & business finance

runway, SAFE dilution, option pools, SBA loan cost, lease vs. buy, side business

burn-rate-runway

Exclusions

  • Smooth monthly compounding of both lines — no seasonality, no step-function hires, no fundraising injections mid-window.
  • Revenue is collected cash (no AR timing), burn is paid cash (no AP float); gross margin is embedded in the burn input.
  • A cash-flow-positive month does not end the simulation: growth of burn can flip the company negative again later, and the cash path reflects that.
  • 120-month horizon; a company that survives it has at least 10 years of runway under these assumptions, nothing more is claimed.

safe-dilution

Exclusions

  • Valuation-cap post-money SAFE only. YC's current instruments are cap-only, discount-only, or MFN — never cap + discount; the discount-only and MFN variants (conversion price set by the round, not computable in advance) are out of scope.
  • One SAFE (or one aggregated cap): stacked SAFEs at different caps add their investment / cap percentages — run the model per SAFE and sum.
  • "Founders" means all pre-SAFE holders (founders + earlier employees).
  • The percentages are floors. When the priced round values the company below — or, the guide warns, "too close to" — the post-money cap, the SAFE converts into MORE than investment / cap (Company Capitalization excludes the new money and the pool increase, so the price-per-share conversion can beat the cap conversion even slightly above the cap). safePctPostSafes and safePctPostRound assume a round comfortably above the cap; the caveat travels in the catalog constraint note so API consumers see it.
  • Pro rata side letters, mid-stage option grants between SAFE and round (the guide's 8% example), and liquidation events before conversion are not modeled.

Known issues

  • Adversarial review 2026-08-14 (fixed pre-release, disclosure-only): the near-cap warning was originally stated too narrowly ("down-round conversion below the cap") and never reached API consumers. The floors caveat above now also travels in the catalog constraint note.

option-pool

Exclusions

  • The pool increase is created pre-money (standard term-sheet convention), so it dilutes existing holders only — that asymmetry is the entire point of the model.
  • "Existing holders" aggregates founders and prior employees; allocated (issued) options count inside it, only the UNALLOCATED pool is tracked separately.
  • No SAFEs or convertibles converting in the same round (compose with safe-dilution for that); no secondary sales; single closing.

sba-loan-cost

Exclusions

  • FY2026 standard 7(a) fee schedule; the fee tiers reset each federal fiscal year. WCP/EWCP maturity-based fees are separate schedules, not modeled.
  • Financed-fee convention: the fee and the guaranty split are computed on the PRE-fee gross amount; financing the fee does not recompute either (the notice bases both on "the gross loan approval amount," which strictly includes a financed fee — recomputing would be circular; the model's convention understates the fee by at most the fee-on-the-fee, under 0.2%). At the $5,000,000 statutory maximum a financed fee would push the note above the gross cap — a real loan at the cap pays the fee out of pocket; the model still returns the financed arithmetic if asked, with this caveat as the contract.
  • FY2026 waivers are NOT applied: small manufacturers (NAICS 31–33, gross ≤ $950,000, 0% upfront) and veteran-owned SBA Express ($0 upfront) borrowers pay less than this model shows.
  • The 0.55% Lender's Annual Service Fee is a LENDER cost that the notice explicitly bars lenders from passing to the borrower — it is deliberately NOT included in borrower cost (most third-party SBA calculators get this wrong).
  • Fixed rate for the full term (real 7(a) loans are commonly variable, Prime-indexed); no packaging, closing, or extraordinary-servicing fees; fully amortizing, no balloon.
  • The 90-day multiple-loan aggregation rule (loans combined for fee tiers) is out of scope — one loan per run.

Known issues

  • Adversarial review 2026-08-14 (fixed pre-release, disclosure-only): the financed-fee convention (fee computed pre-fee; the $5M corner not writable with a financed fee) was applied but undocumented, and the Verification text cited a $1M-break vector looser than the true edge. Convention now in Assumptions; vectors pin both tier edges exactly.

equipment-lease-vs-buy

Exclusions

  • Nominal dollars, undiscounted, and the two terms may differ — the same time-value caveat as loan-comparison, stated in the catalog constraint note. A longer lease's lower nominal cost can still be worse in present-value terms.
  • The tax rate can never change the answer under this contract. The buy-side deduction (interest + write-down to residual) exactly equals the pre-tax net buy cost, so afterTaxBuyCost = (1 − t) × netBuyCostPreTax — and the lease side is (1 − t) × totalLeaseOutlay by construction. Both costs rescale by the same factor: cheaperOption is mathematically independent of marginalTaxRate, and afterTaxSavings is the pre-tax gap times (1 − t). Taxes change the real lease-vs-buy decision only through deduction TIMING (MACRS, §179, bonus depreciation) and discounting — both excluded here. Use the after-tax figures as costs, not as a tax-driven tiebreaker.
  • The buy-side depreciation convention is straight-line down to the residual over the analysis window. Accelerated schedules (MACRS, §179 expensing, bonus depreciation) front-load real-world deductions and can materially favor buying — excluded for a solver-free, timing- free contract; the nominal TOTAL deduction is the same.
  • Lease is a true operating lease: no bargain buyout, no ownership at the end (finance leases that transfer ownership behave like the buy side). Residual purchase options are not modeled.
  • Tax shield assumes profitable operation (deductions usable in full, at a constant marginal rate).
  • Insurance, maintenance, and sales-tax treatment differences are excluded.

Known issues

  • Adversarial review 2026-08-14 (fixed pre-release, disclosure-only): an earlier draft presented the model as an after-tax comparison without disclosing that, under its own assumptions, the tax rate rescales both sides identically and can never flip cheaperOption (see the bolded assumption above). Its Verification section also claimed a tie vector and an after-tax-decisive vector that cannot exist under this algebra. Formulas unchanged; contract text corrected.

side-business

Exclusions

  • SE tax is applied to the full net-of-expenses amount: no 92.35% SE-base factor, no employer-half deduction, no QBI — the flat SE + income sum is the contract.
  • The entire after-tax side income is invested (0% lifestyle inflation).
  • Headline wealth outputs use monthly annuity compounding; the chart and the FIRE loop use annual deposit compounding. The chart's final point is therefore below wealthAtHorizonWith(out) for the same inputs.

Known issues

  • grossSideIncome is misnamed — it is income *minus expenses* (i.e. pre-tax net), not gross.
  • Mixed compounding conventions (step 6): because the annual-deposit loop grows slower than the monthly-annuity target, yearsWithSide is biased high and fireAccelerationYears clamps to 0 for small side incomes even though wealth strictly increased. The max(0, …) hides the inconsistency.
  • Loop cap: yearsWithSide stops at 100; with the clamp the output is then 0 (there is no explicit "never" sentinel).
  • annualReturn = 0 → NaN in the annuity factors (out-of-domain).
  • Negative netSideIncome is reported as-is but contributes nothing to savings (floored at step 4) — the model never charges the loss.

Questions this page does not answer, or a questionnaire you need completed in your own format: contact us. The controlling contractual statements are the terms, the data processing addendum and, for embedded deployments, the white-label addendum. Where this page and a contract differ, the contract governs.