Six Answers a Financial UI Should Be Able to Give

A customer, a reviewer, or your own PM asks the question. The good products open a document. The rest draft an explanation.

The question is old. Users ask it about mortgage estimates. Journalists ask it about retirement shortfalls. Compliance asks it about illustration figures. Auditors ask it about anything a customer relied on. The question is the same in every case: where does this number come from?

The wrong answer is a paragraph. The right answer is six artifacts. A UI that can produce them survives the question. A UI that cannot survive the question is a UI that has been getting away with something.

The six artifacts

The formula is first. A written expression of the computation, in language a domain expert can read. Not code. The formula is what a compliance reviewer, a subject-matter expert, or a math-literate customer can inspect without a laptop. If the formula is not written down, no other artifact can be produced honestly, because everything else pretends to describe something that has not been defined.

The version is second. A stable identifier for the exact behavior that produced this answer. Semantic versioning is the industry convention; the mechanism is less important than the discipline. Two answers produced by the same version are guaranteed to be the same for the same inputs. Two answers produced by different versions may differ, and the changelog explains why. Without a version, the same input can produce different outputs at different times with no record, which is the definition of drift.

The inputs are third. The values the user supplied, echoed back exactly. This is the least glamorous artifact and the most frequently omitted. A stored answer without the inputs that produced it cannot be recomputed. Storing the inputs — with the same rounding, the same types, the same units — is what turns an answer into evidence.

The constants are fourth. Every tax-year, actuarial, or regulatory figure used in the computation, each named. A 2026 IRA contribution limit is not seven thousand dollars in a paragraph; it is a named constant, with a value, sourced. If the constant changes, the changelog records it, and every answer stamped with the old constant remains recomputable exactly because the old value is preserved.

The source is fifth. A URL for each constant that resolves to a primary document — an IRS revenue procedure, an SSA POMS section, a state DOI bulletin, a FASB codification section. Not a summary. Not a wiki. The primary document, dated. A source that resolves to a 404 is worse than no source at all, because it advertises a discipline the product does not actually have.

The hash is sixth. A SHA-256 record computed at response time over four fields — the model name, the spec version, the inputs, and the outputs — and returned with the answer, alongside the constants and sources the computation relied on. The hash is what lets an auditor, a customer, or a court recompute the same answer a year later and match byte-for-byte. Without the hash, verification is a promise. With it, verification is a hash comparison.

1. 1. The formula

   A written expression of the computation, in language a domain expert can read.

2. 2. The version

   A stable identifier for the exact behavior that produced this answer.

3. 3. The inputs

   The values the user supplied, echoed back exactly.

4. 4. The constants

   Every tax-year, actuarial, or regulatory figure used, each named and dated.

5. 5. The source

   A URL for each constant that resolves to a primary document.

6. 6. The hash

   A SHA-256 record over model, version, inputs, and outputs, so the answer can be verified byte-for-byte later.

Reading the six as a maturity model

A UI that can produce artifacts one through three is transparent. A user, at least in principle, can understand what the product did. This is more than most consumer financial UIs achieve today, and it is still not enough.

Add four and five and the UI is current. The numbers on the screen match the numbers at the source, and the mechanism by which they stay in sync is documented. Very few consumer-facing surfaces reach this level.

Add six and the UI is auditable. The answer can be verified later, by anyone with the envelope. This is the level at which a customer-facing calculator survives every question a reviewer can ask. It is also the level at which a language model can cite its work and mean it.

“Transparency is the formula. Currency is the constant. Auditability is the hash. All three, or none of them count.”

Where to put them

The six artifacts do not need to be on the main screen. The formula lives in the spec, one click behind the answer. The version and hash live in a Show your work panel that the user opens by choice. Inputs and constants sit inline in that panel. The primary-source URLs are one further click, resolving to the actual IRS page. None of this crowds the main UI. All of it is retrievable.

The negative test

Ask any candidate financial UI a single question: if I ran this exact input a year from now, could you tell me whether the answer would be the same, and if not, exactly what changed?

If the answer is yes because the version pins behavior and the changelog records every diff, the product is verifiable. If the answer is a shrug, the product is not — no matter how right its arithmetic happens to be today. The negative test is the compressed version of the six artifacts. Products that pass it have all six. Products that fail it have some.

What the six replace

The six artifacts are not additive to an existing set of trust practices. They replace three older practices that most financial UIs still rely on and that no longer hold up under audit. The first is the disclosure paragraph — a block of text at the bottom of the screen explaining that results are estimates, that assumptions may vary, that users should consult a professional. The paragraph is legally useful and technically empty. It answers no specific question about the number above it.

The second is the FAQ. A well-written FAQ can substitute for a spec in the eyes of a customer, until the customer asks a question the FAQ did not anticipate. Then the FAQ is a document that answers different questions than the one asked, which is worse than no document at all. The six artifacts replace the FAQ by making the underlying spec the reference document; the FAQ becomes a reading guide, not a load-bearing artifact.

The third is the marketing methodology page — the whitepaper the vendor commissioned three years ago that describes the calculator in general terms without the version, the constants, or the sources. Whitepapers age. Specs are versioned. The six artifacts replace the whitepaper by making the current spec the current answer and preserving previous specs in a changelog that anyone can read.