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

Proof

We don’t ask you to trust us. We hand you the means to check.

Every Worthune model is Concordance-tested before release: a second implementation, written independently in a different language from the published spec alone, must agree with the production engine on 250 cases per model, to one part in a billion. The harness runs in CI on every change and a mismatch stops the release.

Every trust claim Worthune makes resolves to an artifact you can open or a job you can watch run. This page is the index of all of them — and the definition of the method behind the mark.

Last reviewed

Concordance testing

con·cor·dance — agreement between independent witnesses.

Every Worthune model is implemented twice: once in the engine that serves you, and a second time — separately, in a different language, from the published spec alone, with no access to the engine's code. The two must agree on 250 cases per model, to one part in a billion, before any release. When they disagree, the release stops. The harness re-runs on every change.

Our mark is a picture of it: two squares drawn independently, solid only where they overlap. The answer is the shape they share, and nothing outside it.

What it does mean

  • The engine implements its documented model exactly.
  • The spec is precise enough for independent reproduction — that's what the second implementation proves.
  • Regressions are caught: the harness re-runs on every change, and a mismatch blocks the release.

What it does not mean

  • That a model's financial judgment is right for your situation — models simplify, and each spec names what it leaves out.
  • That we've never shipped a mistake. We have; the fixes are in the public changelog. The method exists because we decided never to rely on trust again — ours included.
  • Outputs are planning illustrations, not financial advice.

The artifacts

Nine things you can open right now

Specs

A versioned contract per model

Inputs, valid domains, exact formulas, assumptions, and what the model deliberately leaves out. Three specs are published in full — the proof of the method; the full catalog's specs come with a subscription, and every model's input contract is public.

browse the catalog →

Cases

Open test vectors

The exact 250 cases per model the Concordance harness runs — deterministic and re-runnable against your own integration. Three datasets are open downloads; the full set comes with a key. Not a sample of our testing; the testing itself.

download the datasets →

Constants

A sourced facts registry

Every IRS limit, bracket, and SSA factor the models consume, with its primary source, effective period, and the date a human last checked it. We publish what we run.

open the registry →

Changelog

No silent changes

Model behavior changes only through a spec version bump with a public changelog entry — including our own bug fixes, stated plainly. Pin a version and hold us to it in CI.

read the changelog →

Records

A fingerprint in every response

Each run returns a SHA-256 record over the model, spec version, inputs, and outputs. Store it, recompute it months later, and prove where a number came from — paste one here and check it now.

check a record →

Verdicts

A claim check that can refuse

Send us a claim about a model's outputs and it comes back verified, violated, or out-of-scope — with the engine's own value as the proof. The third verdict is the one that matters: we don't rule on numbers a model doesn't compute, so an assistant can say "I can't verify that" instead of inventing something.

POST /api/v1/verify →

Documents

A run you can hand to a reviewer

Any computation renders as a print-ready report that carries the payload its own hash was taken over, so it can be checked with nothing but the file. Per-model evidence packs bundle the spec, the cases, the constants and the changelog for a vendor review. Both say plainly what they are: a record of a computation, not a compliance certificate.

see a report →

Benchmark

The same cases, pointed outward

FinPlanBench hands language models a published spec and asks for the exact numbers. It renders only committed runner artifacts — no artifact, no row — which is also why an empty leaderboard would render honestly.

read the leaderboard →

Usage

Even our traction is public

We ask you to trust our numbers, so ours are checkable: aggregate API usage, updated daily, honest zeros included.

GET /api/v1/telemetry →

61 models in the catalog today. The maintenance posture, in writing: we maintain the registry and the models against primary sources on a best-efforts basis and version every change publicly — the artifacts above are how you hold us to it.

Questions

Common questions

What does Concordance testing actually mean?
Each model is implemented twice: once in the TypeScript engine that serves requests, and once in Python, written separately from the published specification alone with no access to the engine's code. The two must agree on 250 cases per model, at one part in a billion, before any release. Where they disagree, the release stops until the spec, the engine, or the second implementation is wrong and fixed.
Who verified Worthune?
Nobody. No third party has audited or certified Worthune, and the site does not claim otherwise. The verification described here is our own discipline, run in our own CI. What makes it checkable by an outsider is that the specifications, the test cases, and the results are published — not that anyone accredited us.
What does Concordance testing not prove?
That a model's financial judgment is right for a particular situation. Models simplify, and each specification names what it deliberately leaves out. It also does not mean we have never shipped a mistake — we have, and the fixes are in the public changelog. The method exists because of them.
How do I validate a financial calculation engine of my own?
The same shape works: write the specification first, implement it twice independently, and diff the two across a large deterministic case set in CI. If you would rather not build the second implementation, the eval datasets let you diff your engine against ours instead.
How do I prove months later where a number came from?
Store the decision record returned with the run — a SHA-256 hash over the model, spec version, inputs, and outputs. Recompute it later, or paste it into the record checker, and it either matches or it does not. Because behavior changes only through a version bump with a changelog entry, the spec version in the record tells you exactly which rules produced the number.