The Verified-Computation Layer for Financial Software

Categories get named when the shape of the work becomes recognizable across firms. The shape has been recognizable for years. The name is the last artifact.

This essay is the capstone of the Worthune writing library and was deliberately written last. The reason it is last is deliberate. Category definitions produced before the category exists are marketing exercises; category definitions produced after the category exists are descriptions of what has already been built. The library that precedes this piece — the manifesto, the vocabulary, the model catalog, the engineering and comparison pieces — is what the category consists of when described in specific artifacts. The essay that follows names the category the artifacts have been building toward.

The name is the verified-computation layer for financial software. The layer sits between the regulatory sources at the bottom and the customer-facing surfaces at the top. It is the specific set of artifacts, disciplines, and commitments that make a financial UI’s numbers defensible over time. Firms that have not been thinking of this as a category have been building it anyway, in fragments, because the pressure to build it has been continuous. The category exists; it has not been named. Naming it is what makes the fragments legible as parts of the same object.

What the layer contains

The verified-computation layer contains four artifacts, four disciplines, and one commitment. Each is described in specific detail elsewhere in the library; the summary below is the layer’s working shape.

The four artifacts are the specification, the second implementation, the sourced constants, and the audit envelope. The specification is a human-readable document naming what a model computes, its inputs and their valid ranges, its formula, its assumptions, and its exclusions. The second implementation is an independent codebase honoring the same specification, run against a substantial suite of verification cases on every release, whose agreement with the primary implementation is what ‘verified’ refers to. The sourced constants are the tax-year, actuarial, and regulatory figures the models depend on, held in a public registry with periods and source names attached to each row. The audit envelope is the per-answer response object: the model name, the specification version, the caller’s inputs echoed back, the outputs, sentinel annotations, assumptions, facts referenced, a SHA-256 record over model plus specVersion plus inputs plus outputs canonical key-sorted, and a disclaimer.

The four disciplines are versioning behavior, publishing constants, refusing out-of-domain inputs, and storing envelopes. Versioning behavior means that any change to what a model computes produces a new specification version rather than a silent update. Publishing constants means that no tax-year or regulatory constant is hard-coded; every value is a row in a public registry with a source and a period. Refusing out-of-domain inputs means that a model does not clamp a paradoxical input into a defensible-looking answer; it returns an error or a specifically-named sentinel and lets the caller handle the case. Storing envelopes means that the caller preserves the per-answer envelope for the retention window applicable to the calculator’s use case, so any past answer can be recomputed and verified.

The commitment is durability. What a public artifact promises today is what the public artifact promises tomorrow. Free tiers that are free today remain free with their published fair-use guidelines. Specifications that are public today remain public. Constants that name their sources today continue to name them. Behavior that is version-pinned today remains version-pinned. The commitment is what turns the four artifacts and the four disciplines from a technical shape into a category commitment; without it, the artifacts are engineering, and with it, the artifacts are trust.

Why the category exists now

Categories emerge when several forces converge on the same working shape at the same time. Three forces converged on the verified-computation layer over the last several years.

The first is regulatory. Supervised financial firms have been asked to substantiate customer-facing math under model-risk-management principles that predate this category and have been applied with increasing attention to customer-facing math.^[1] The firms’ internal calculator practices have not always kept pace with the reading. Compliance functions that inherited undocumented calculators have been quietly building the specific artifacts — written specs, documented change logs, sourced constants — the layer names. What the compliance functions have been building in fragments is what the layer contains in aggregate.

The second is architectural. Language-model interfaces have been pressed into service producing numbers users act on, and language models produce numbers by predicting tokens rather than by computing. The failure mode — fluent, confident, wrong — has become visible enough that a specific class of financial products has moved to a tool-use pattern in which the language model delegates numeric answers to deterministic models and cites the version. The tool-use pattern requires a specific artifact for the assistant to cite. That artifact is a specification. The layer supplies it by construction; the alternative is that each assistant’s vendor produces the artifact ad hoc, which is what each vendor does ad hoc in the absence of a common surface.

The third is economic. The engineering hours consumed by internal calculator maintenance have become visible on ledgers that used to hide them. Firms that scoped a two-month retirement calculator and watched it become a two-year maintenance tail have accumulated enough of these tails to notice the pattern. The economic pressure to externalize the layer has been present for years; what has changed is the availability of an external layer worth externalizing to.

Where the boundary of the layer sits

The layer’s boundary is worth naming because categories that do not name their boundaries end up including everything or nothing. The verified-computation layer includes the arithmetic, the specifications, the constants, and the audit surface. It does not include the UI, the acquisition flow, the customer relationship, or the firm’s specific product framing.

The UI is above the layer. A calculator is a UI on top of a model; a chat interface is a UI on top of an assistant on top of a model. Different UIs can share the same model call and produce different user experiences from the same envelope. The layer does not produce UIs; UIs are the firm’s to build, and the differentiation firms compete on above the layer is where product design actually lives.

The customer relationship is above the layer. Advisors, planners, coaches, and self-serve products all use the layer differently because their customer relationships are different. The layer produces the specific numbers each relationship needs; the relationship itself is not the layer’s scope, and firms that try to buy customer relationships from an infrastructure vendor are usually disappointed for good reason.

The primary sources are below the layer. IRS revenue procedures, SSA POMS documents, agency bulletins, state tax rules, and actuarial tables are what the layer’s registry cites; they are not part of the layer itself. When a primary source moves, the layer’s registry moves; when the layer’s registry moves, callers inherit. The layer is a mediator between the primary sources and the customer-facing surfaces, and mediation is a specific role that neither the sources nor the surfaces play.

How firms use the layer

Firms use the layer in three general shapes. As embedded consumers, they call the layer through an API and render its outputs in their own UI. As white-label consumers, they call the layer through a paid tier that removes attribution and treat the layer as invisible infrastructure. As reference consumers, they read the specifications and constants and implement against them internally, using the layer’s artifacts as canonical sources without depending on the layer’s hosted services.

The three shapes are not mutually exclusive. A single firm can consume the layer as an API for its consumer product, as a white-label integration for its advisor tool, and as a reference for its internal analytics. Each shape has different economics and different technical commitments; the layer’s artifacts are what make the shapes compatible with each other, because the underlying specifications, constants, and envelope schemas are the same across all three.

Where Worthune sits in the category

The final section of a category-definition essay is where the vendor names its own position honestly. Worthune is one vendor in the verified-computation layer. It is not the only possible vendor; the layer is a shape, not a company. Worthune’s specific bet is that the layer is best served by a vendor whose entire product is the layer itself — the specifications, the second implementations, the sourced constants, the audit envelope, the versioning discipline, the durability commitment. Firms that use Worthune are using a vendor whose incentives are aligned with the layer’s properties. Firms that use a different vendor should evaluate whether that vendor’s incentives are similarly aligned; the Vendor Risk Interview Kit for Model Vendors (/writing/vendor-risk-interview) is the working list for that evaluation.

Worthune does not claim to be the only durable vendor in the category. It claims that the category exists, that the artifacts and disciplines above are what a durable vendor in the category ships, and that Worthune ships them. Callers evaluating vendors should look for the same artifacts and disciplines wherever they consider going; the category’s health depends on multiple vendors meeting the standard, not on a single vendor holding the standard alone.

What the category name is for

Category names do specific work. They let a buyer describe what they are looking for without walking through the ingredients. They let a compliance function ask a vendor whether the vendor is in the category rather than reciting the tests one at a time. They let an engineering team scope a project in a way that a leadership team recognizes. Naming the verified-computation layer is what makes each of these conversations shorter.

The name also makes the alternative visible. A firm building customer-facing math without a verified-computation layer — without specifications, without a second implementation, without sourced constants, without an audit envelope — is a firm whose calculator surface has a specific set of failure modes the layer is designed to prevent. Naming what the layer prevents is easier once the layer has a name. Firms that recognize themselves in the description of the alternative usually recognize the value of adopting the layer without needing further argument.

“The layer has been getting built one calculator at a time for years. Naming it is what lets the next decade of work be about the surfaces above the layer instead of the layer itself.”

The library as evidence

This essay does not stand alone. The category the essay names is the specific object the rest of the library describes. The manifesto argued for verified computation as a principle. The vocabulary defined the working terms. The model catalog documented what a specification looks like. The engineering pieces developed the integration mechanics — pinning, envelopes, error handling, observability. The comparisons distinguished the layer from adjacent choices. The playbooks translated the layer into vertical use cases. The toolkits produced the artifacts callers need to adopt the layer. The buyer-and-leadership pieces produced the executive-legible case for the layer.

Each piece is a specific artifact. The category is what emerges when the artifacts are read together. This essay is the label on the aggregate, published last because the aggregate had to exist first. Readers arriving at this essay from search or from a link should read at least one piece from each of the surrounding pillars before returning; the category is more legible in the artifacts than in the label.

What comes next

Categories that get named enter a specific phase. Vendors compete on the category’s properties. Buyers evaluate against the category’s standards. Adjacent categories draw their boundaries against the new one. Trade press writes about the category. Analysts publish maps of the category. None of that is this essay's claim; the essay's claim is only that the category exists now, in shape, and is ready to be discussed as one.

The next essays worth writing about the category are ones this piece is not the right one to write. Case studies from firms that have adopted the layer at scale. Comparative analyses between vendors in the category. Retrospectives on the specific failure modes the layer prevents, drawn from real incidents rather than from principles. Each of those essays will be more useful than this one once the material exists to write them from. Publishing this one now is what makes those essays possible; category definitions are not the culmination of the discourse, they are the first artifact the subsequent discourse references.

“The category has existed as a shape for years. Publishing the name is what lets the next round of conversation start.”

The specific commitment this piece makes

The specific commitment this essay makes on behalf of the library it caps is that the artifacts described above will continue to exist. The specifications will remain public. The constants will remain sourced. The envelope will remain durable. The commitment will remain in writing. The library will continue to expand around the category as new artifacts become worth publishing. And the category name will continue to refer to the same specific set of artifacts and disciplines, whether the industry adopts the name or coins a different one for the same shape.

The naming is a claim about what the object is. The commitment is a claim about what the object will remain. Both claims are made in the specific artifacts the library contains, not in the label attached to them. Readers who want to verify the claim should read the artifacts; readers who want a shorter version can use the label. Both readings converge on the same thing. That convergence is what a category is for.