The Concordance Manifesto

Concordance is the test: two implementations, written independently from the same published spec, must agree on 250 cases per model — at one-part-in-a-billion tolerance — before any release. Four artifacts are the evidence it leaves behind: the spec, the 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.

Concordance testing is our name for the alternative. Two implementations, written independently from the same published spec, must agree on 250 cases per model — at one-part-in-a-billion tolerance — before any release. Either they agree and the release ships with the evidence attached, or they disagree and the disagreement is a defect — in the spec or in an implementation — that gets fixed first. The method exists because we shipped wrong numbers once and decided never to rely on trust again — ours included; the fixes are in the public changelog. What the method leaves behind is a stack of four artifacts. Each artifact either exists where a caller can open it or it does not exist — 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 specification — inputs, ranges, formula, assumptions, exclusions, all in a human-readable document at a stable URL.
• ✓A second implementation, written independently from the same spec, that must agree with the first on 250 cases per model — at one-part-in-a-billion tolerance — before any 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 in the method. 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 spec is also what makes Concordance possible at all — there is nothing to reimplement independently until the behavior is 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 all 250 cases — at one-part-in-a-billion tolerance — 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. That agreement is Concordance, and no model ships without it.

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 test the first implementation has to pass before 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 names its spec and version. 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 three sample models — emergency-fund, relocation, side-business — are the shortest way to see the method whole: their specs and eval datasets are fully public, as the proof of the method. The rest of the catalog ships its full specs and datasets with a Pro key, and every model's input contract — inputs, domains, sentinels — is public. Every model pulls its constants live from the facts registry and returns a response schema that includes the audit envelope by default. Reading one full sample spec takes about ten minutes and demonstrates the pattern more compactly than any manifesto can.

A note on what Concordance does not mean

Concordance 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 Concordance means, precisely, is that the model behaves the way the spec says it will behave, that an independent second implementation agrees on every one of the 250 cases, 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.