Most emergency-fund calculators solve for the contribution: "save $1,850 a month to reach your goal by June." The user cannot save $1,850 a month, which is why they are underfunded. This model takes the real monthly number and answers when.
The emergency-fund question has two directions. Solve for the contribution and you get a prescriptive number that collides with a real budget on day one. Solve for the date and you get something a person can plan around: at what you actually save, funded by March of next year — or funded never, said plainly. The Worthune emergency-fund model runs the second direction, with the account's interest working in the simulation instead of being footnoted away.
The five inputs
Monthly essential expenses, the target buffer in months of those expenses (one to twelve), current savings, the real monthly savings amount, and the savings-account rate. All required, all bounded by published domains, out-of-range requests rejected with structured errors. The target is expenses times months — the model does not adjust it with risk multipliers or income-stability factors; the caller who wants a fatter target for a volatile household asks for more months, which keeps the knob visible instead of burying it in a coefficient.
target = monthly_expenses × target_months; each month: balance = balance × (1 + rate/12) + monthly_savings; months_to_goal = first month the balance meets the target (sentinel: 240 = not within 20 years)
Interest compounds monthly inside the simulation — the model returns the total interest earned on the way to the goal — over the full 240-month window when the goal is never reached — which at today's high-yield rates is a real contributor and not a rounding error. The 240-month sentinel is the honest "never": a goal that monthly saving cannot reach within twenty years is a goal that needs different inputs, and the response says so rather than extrapolating into fantasy. (One documented collision: a goal landing exactly at month 240 is indistinguishable from never — the spec says so.)
What the outputs are shaped for
The response returns the target amount, the months and years to goal, the interest earned along the way, and two chart-ready series: the projected balance against the target month by month, and the coverage in months of expenses as it accumulates. The series are truncated at sixty months — a documented contract detail, not a bug — because a chart of a twenty-year grind to a six-month buffer is not a chart anyone reads; the numbers past the truncation live in the scalar outputs.
The coverage series is the output an integrating UI should lead with. A user three months into the plan is not thirty percent of an abstraction — they are one point four months covered, a number denominated in the thing the fund is for. Coverage reframes the account from a savings goal into an expanding runway, which is what it actually is.
The variable-income question, answered honestly
The model has no income-volatility input. A freelancer's emergency fund and a salaried employee's differ in the target, not the arithmetic: the volatile household needs more months of buffer. The composition the contract supports is to size the months upstream — from income variability, from single-versus-dual-earner status, from whatever heuristic the caller trusts — and pass the result as the target-months input, within its one-to-twelve domain. What the model will not do is dress that judgment call up as computation. Choosing six months over three is a risk decision; compounding a balance toward six months of expenses is arithmetic; the model does the arithmetic and leaves the risk decision visibly with the caller.
- Direction: solves for time-to-funded given real savings, never for a prescribed contribution.
- Interest is in the simulation — the account rate is an input and interest earned is an output.
- The 240-month sentinel says never honestly; series truncate at 60 months by contract.
- No risk-adjustment coefficients — a fatter buffer is more months, chosen by the caller, in the open.
- No income-volatility input — size the months upstream and pass the result.
Reading the response
Alongside the outputs: the spec version, an assumptions array naming that version, an empty facts array — the model consumes no tax-year constants; every number in it belongs to the caller — and the record.sha256 over model, spec version, inputs, and outputs. For a model this simple the envelope may seem like ceremony, but simple models are exactly where silent behavior drift hides longest: nobody re-audits the emergency-fund calculator. The version stamp and the record mean nobody has to.
A worked example
A household with six thousand dollars of essential monthly expenses targets a four-month buffer: twenty-four thousand dollars. They have nine thousand saved, can put away eight hundred a month, and the account pays around four percent. The simulation runs month by month — each month the balance grows by a twelfth of the rate and the eight hundred lands — and the balance crosses twenty-four thousand in the second year, with the interest contribution stated separately in the response rather than dissolved into the total. Change the savings to two hundred a month and the crossing moves out by years; the model reports the later date rather than scolding, because the date is the information and the scolding is the UI's choice to make or skip.
Sources
- [1] Worthune emergency-fund model spec. https://worthune.com/docs/models/emergency-fund
- [2] Worthune model catalog. https://worthune.com/models