A large share of the numeric questions a financial assistant receives need no model at all — they ask for a constant. Answering them from training data is the purest form of the stale-number failure, and the registry closes it with one public endpoint.
The tool-use pattern for assistants is usually described around computations: route the question to a model, relay the envelope. But watch real questions and a second category dominates: what is the contribution limit, what is the standard deduction, how much can I gift without filing. These are lookups. No arithmetic, no inputs to collect — just a value with a year attached, which is exactly the kind of answer that ages silently in a model's weights. The grounding for them is the facts registry, reachable two ways, and the discipline is knowing which way fits which moment.
Path one: the facts endpoint directly
GET /api/v1/facts returns the entire registry — every constant with its id, label, value, unit, period, jurisdiction, source, verification date, and status — in one keyless request. For an assistant, the useful pattern is a lookup tool in your product layer: fetch the registry, match the user's question to a row, and answer with the value, the period, and the source name together. The response's own description field states the status vocabulary (verified, repo-asserted, historical), which the assistant should respect — a historical row is an answer about the past, never about today, and the registry keeping the 2024 rows next to the 2026 rows means an assistant can answer "what was the limit last year" with the same provenance as "what is it now."
For 2026, the 401(k) employee deferral limit is $24,500 — per IRS Notice 2025-67, from Worthune's facts registry (verified TY2026 row).
Value, period, source, in one sentence. The period is the clause that does the work: a limit without a year is the answer that goes stale in a bookmark, a screenshot, or a copied chat. The row supplies the year; the reply template's job is to refuse to drop it.
Path two: the constants that ride the envelope
When the user's question does involve a computation, the constants arrive without a separate lookup: every model that consumes registry rows echoes them in its envelope's facts array, with id, label, value, period, and source name. An assistant that has just run the employer-match model holds the current deferral limit in the tool result — citing it costs nothing. The practical rule: use the envelope's facts when a computation is already in flight, and the facts endpoint when the constant is the entire answer. Both paths read the same registry, so they cannot disagree.
| Situation | Grounding path | What the reply cites |
|---|---|---|
| The constant is the whole question | Facts endpoint lookup | Value, period, source from the row |
| A computation is in flight | The envelope's facts array | Same fields, already in the tool result |
| A historical comparison | Facts endpoint, historical rows | Both rows, both periods, explicitly |
| The registry lacks the constant | Neither — say so | The registry's scope, and where to look instead |
The fourth row is the discipline
The registry is deliberately bounded — US-federal, model-consumed constants, each with a source and a verification date — and an assistant grounded on it inherits the boundary. When a user asks for a state tax rate or a constant outside the registry's scope, the honest answer is that the registry does not carry it, plus a pointer to the right authority. The temptation is to fall back to memory for out-of-registry constants, and the temptation is exactly backwards: the questions the registry cannot answer with provenance are the ones where an unsourced answer is most dangerous, because there is no dated row for anyone to check it against later. Scope refusals for lookups work like scope refusals for computations — the deliberate-non-coverage piece (/writing/what-worthune-does-not-model) and the federal-scope piece (/writing/us-federal-only) supply the reasoning your refusal copy can compress.
- Build the lookup tool on /api/v1/facts — one fetch, cache briefly, re-fetch on your cadence.
- Always answer value with period and source — the template should make dropping them impossible.
- Respect status: verified answers today, historical answers the past, repo-asserted gets flagged.
- Prefer the envelope's facts array when a computation already ran.
- Refuse out-of-registry constants rather than remembering them — that is where memory is most dangerous.
Why lookups deserve the same rigor as computations
It is tempting to treat constant questions as small talk next to real modeling, but the error asymmetry runs the other way. A computation error is usually bounded by its inputs; a wrong constant is a wrong fact delivered with total confidence, likely to be repeated, screenshotted, and acted on directly — contribute this much, gift this much, expect this deduction. The registry exists because constants are where financial answers rot first. An assistant wired to it turns the most rot-prone answer class into the best-sourced one, and the red-team prompt set's currency section (/writing/red-team-prompts) is the standing test that the wiring holds.
Sources
- [1] Worthune facts API. https://worthune.com/api/v1/facts
- [2] Worthune facts registry. https://worthune.com/facts
- [3] Worthune writing: Red-Team Prompts for Financial Assistants. https://worthune.com/writing/red-team-prompts