Methods

How outputs on AINumbers.co get checked

Verifiability answers whether you can inspect how a result was produced. It does not by itself answer whether the result is correct. This page describes the mechanisms the suite uses to check that, what each one covers, and what it deliberately leaves for the reader to judge.

What gets checked

Six mechanisms, each narrow on purpose

None of these mechanisms alone proves a tool is right for your situation. Each one closes off a specific way a result could be wrong or could drift silently over time. Together they form the checking layer behind the OpenChainGraph-anchored tools; simpler calculators without a ChainGraph node rely on the JS syntax and count-drift gates described below but do not carry a compute proof.

Golden fixtures
A fixed set of inputs is pinned per kernel together with the output that kernel is expected to produce for them. A gate replays the fixture on every change and fails if the output moves.
Checks the kernel still produces the pinned answer for the pinned inputs. Not checked whether the pinned answer was correct in the first place, or whether inputs outside the fixture set behave the same way.
In-page rule citations
Where a tool implements a specific rule, standard, or regulatory formula, the page cites the governing text inline, dated, next to the calculation it applies to.
Checks which text the logic claims to follow, and when that citation was added. Not checked whether the implementation is a correct reading of that text. The citation names the source; it does not audit the reading of it.
Clause binding §28
Where shipped, a ChainGraph node's clause binding names the specific paragraph or line of the source text a computation implements, machine-readably rather than only in prose.
Checks that a named clause maps to a named computation, and that mapping is queryable. Not checked coverage across the catalog. This page does not state what fraction of tools carry a clause binding, because that number changes with every release and a stated figure would go stale.
Conformance gate suite §15
Every push touching the OpenChainGraph data or spec runs a fixed suite: schema validation, spec-version consistency, gate coverage, spec-to-page parity, and golden parity. All five must pass before a change lands.
Checks internal consistency. The data matches its own schema, the spec, and its own prior outputs. Not checked whether the schema or spec themselves model the real-world rule correctly.
Deterministic replay
Given the same recorded inputs, the same kernel produces byte-identical output on re-run. There is no hidden state, no clock dependency in the calculation itself, and no server round-trip that could introduce variance.
Checks that the same inputs always give the same output, so a result can be independently reproduced later. Not checked whether the output is the right answer to the real-world question. Reproducibility and correctness are different properties.
Compute proofs §18
For eligible kernels, a zero-knowledge proof attests that the published output was produced by running the published kernel logic on the recorded inputs, without a third party needing to re-execute the kernel.
Checks that the specific computation ran as published, so a third party can trust the result came from that logic rather than being hand-typed. Not checked whether the kernel logic itself is a correct model of the rule. A proof over wrong logic still proves that wrong logic ran correctly.
The honest boundary

What this establishes, and what it does not

Taken together, these mechanisms establish that a given computation matches its declared specification and the text it cites, that it produces the same output every time it runs, and that changes to it are visible rather than silent. That is a conformance duty the tools carry, and it is checked mechanically on every change.

What it is not

None of this is a promise that your specific use of a tool is compliant with any regulation, or that the tool's model of a rule is the only correct one, or that a result requires no professional judgment before you rely on it. A computation can conform exactly to its own specification and still be the wrong tool for your situation, built on an outdated version of a rule, or misapplied to facts it wasn't designed for. Middle-office review exists precisely because "the calculation ran correctly" and "the number is right for this deal" are two different questions, and these mechanisms only answer the first one.

See Terms & Reliance for the full disclaimer, and SPEC.md for the normative definition of every mechanism named on this page.

Browse the ChainGraph hub Read SPEC.md ↗ Browse all tools