The Verified-Computation Manifesto

Four artifacts separate math a user trusts from math a user can verify: the spec, a second implementation, sourced constants, and an audit hash.

Financial products compute for a living. A retirement projector estimates a shortfall. A refinance tool decides whether to move. A coverage-timing calculator sets a death benefit. Each of those numbers is the reason the user opened the app. The number is also, in most products, the least documented thing on the screen.

The convention has been to display the answer, hide the formula, and hope the constants are current. That convention has aged badly. Supervised firms are asked to substantiate customer-facing math under model risk management guidance that dates to 2011 and has been read progressively more strictly since.^[1] Language-model interfaces are being asked to compute without a computation layer beneath them. Engineering leaders watch the same weekend project — a payoff planner, a Roth converter — turn into a two-year maintenance tail because the IRS moved a contribution limit in November and nobody on the current team remembered where it lived in the codebase.

Verified computation is our name for the alternative. It rests on four artifacts. Each artifact is either published or it does not exist. There is no partial version, no version that lives only in an internal wiki, no version that is on the roadmap. If a product cannot show all four, the math is a claim rather than a computation.

• ✓A public specification — inputs, ranges, formula, assumptions, exclusions, all in a human-readable document at a stable URL.
• ✓A second, independent implementation of the same spec that must agree with the primary implementation across 250 verification cases per release.
• ✓Sourced constants — every IRS or SSA figure carries a URL and a revision date, held in a public registry, never hard-coded.
• ✓An audit envelope — every response returns a spec version, the constants used, and a SHA-256 hash the caller can store and verify later.

Each artifact does a specific job. The spec answers what was computed. Without a spec, correctness is asserted rather than defined; two engineers reading the same product requirement will implement two slightly different models, and neither can be called wrong because nothing was written down.

The second implementation answers whether the first one is right. A single codebase that produces a number produces exactly one kind of evidence: it produced that number. A second implementation, written from the same spec by a different author, produces the evidence that matters — either the two agree on 250 verification cases, in which case the spec is unambiguous and both implementations honor it, or they disagree, in which case the spec is ambiguous and gets fixed before release.

Sourced constants answer where the numbers come from. Contribution limits, Social Security bend points, HSA family limits, estate exclusion amounts — all of these move on their own schedules, published by their own agencies, at their own URLs. A calculator that hard-codes them is correct on the day it ships and drifting from that day forward. A calculator that reads them from a registry with a source URL and a revision date is correct until the source changes, and visibly stale after.

The audit envelope answers what the user actually saw. A stored envelope containing the spec version, the constants used, and a SHA-256 hash lets any auditor — the customer's compliance team, a regulator, a plaintiff's counsel — recompute the same answer and match the hash byte-for-byte. That is what an audit trail means, and nothing a user meaningfully relies on should ship without one.

“The math is the easy part. The provable trail behind the math is the product.”

The reason this matters at the category level is that the alternative is not less rigorous math. The alternative is math whose rigor is unfalsifiable. A homegrown calculator that returns the right number 999 times out of 1,000 is indistinguishable from one that returns the right number 1,000 out of 1,000, until the thousandth user is a journalist, an auditor, or a plaintiff.

The economics of the falsifiable version have changed in the last five years. Publishing a spec used to be an expense with no return; now it is the artifact a language model needs to cite. Running a second implementation used to be duplicated engineering; now it is the standard against which the first implementation earns its release. Sourced constants used to be a maintenance overhead; now they are the difference between a product that ages with the tax code and one that quietly lies from January 1 onward.

What changes when the four artifacts exist

A support ticket that used to require an engineer to explain what the tool did now resolves to a spec URL. A compliance review that used to require a live walkthrough of code now resolves to a changelog. A journalist question that used to require a hedge now resolves to a primary-source citation. None of this is theoretical; each is a workflow that a product team either has or does not have depending on which artifacts exist.

The four-artifact test is not a maturity model. It is a floor. A product either meets it or does not. The rest of this content library is built on that floor. Every model page cites its spec. Every article that names a tax-year constant links to the registry row that owns it. If the registry updates, this library either updates or it visibly ages — never silently wrong.

The next step

The Worthune catalog is the shortest way to see the four artifacts in one place. Every model has a spec URL, a verification-cases directory, a set of constants pulled live from the facts registry, and a response schema that includes the audit envelope by default. Reading one full spec takes about ten minutes and demonstrates the pattern more compactly than any manifesto can.

A note on what verified does not mean

Verified does not mean correct in the philosophical sense. A model can honor its spec exactly and still be a poor model of reality; the spec captures assumptions, and assumptions can be wrong. What verified means, precisely, is that the model behaves the way the spec says it will behave, that the second implementation agrees, that the constants come from documented sources, and that the answer can be recomputed later. These are the specific claims the four artifacts support. They are not claims about the underlying financial theory. That is a separate conversation, held on the spec page under assumptions, and users deserve to see both — what the model does and what the model deliberately does not.