The verification story and where judgment comes in

A result on this site can carry two separate kinds of evidence. The formal verification pilot verifies a kernel against a specification that survived independent mechanical validation, and the assumptions sit next to every claim. For eligible kernels, a zero-knowledge compute proof (§18) 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. Those are two separate kinds of evidence, and neither substitutes for the other.

The four kernels in the pilot each carry the kind that fits them. One, the payee name-match scorer, carries a formal claim without a compute proof, because its fuzzy string-matching cost currently exceeds what the zk proving pipeline can practically handle in-guest. Which kernel carries which kind is stated on the methods page.

Name the two kinds of evidence a published result can carry on this site, and state what each one establishes about the output.

Each specification in the pilot is drafted with an LLM, from the regulation text itself and never from the kernel's code: a spec copied from the implementation can only prove the code matches itself. The draft then runs through independent mechanical validation: it must reproduce the kernel's golden fixtures, and where the regulator publishes its own worked examples, it must match those too. A spec that fails this validation goes back for another draft rather than forward to a proof. By the time a proof runs, the spec it proves against is the one that survived validation.

Validation has caught a real mismatch at least once: the payee name-match scorer's spec was initially drafted the wrong way around, from the code instead of the declared contract. Validation caught the mismatch, the spec was re-derived independently from the contract, and the two versions matched, so the validated spec stands.

Walk the path a specification travels from the regulation text to a proof, and name the two checks mechanical validation requires it to reproduce.

Every mechanism on the methods page publishes what it checks and what it leaves unchecked. A compute proof checks that the specific computation ran as published. What it does not check is whether the kernel logic itself is a correct model of the rule: a proof over wrong logic still proves that wrong logic ran correctly. And the proof checks the code against its validated spec, not whether the regulation means what its worked examples show, a question no machine, and no signature, ever answered.

The pilot names its own horizon: as far as it knows, no shipped product yet chains a complete functional spec, proved for all inputs, to a zk proof of faithful execution for general-purpose business logic. The pilot works toward that combined claim on its four kernels, and no claim is made about coverage of any other kernel.

State what a compute proof establishes about a published output, and the two questions it leaves open.

Each proof sits beside published checks. Golden fixtures pin a fixed set of inputs per kernel together with the expected output, and a gate replays them on every change, failing if the output moves. For the solver verified in Dafny, whether the port and the shipped kernel compute the same function is established separately, by differential testing: the compiled proof and the shipped kernel run side by side. And one pilot kernel is verified by property testing backed by a hand proof, checked against the kernel's existing golden fixtures.

Deterministic replay adds its own guarantee: given the same recorded inputs, the same kernel produces byte-identical output on re-run, so a result can be independently reproduced later. Reproducibility and correctness are different properties, and the methods page states what each mechanism establishes and what it does not.

Name the three checks that surround the pilot's proofs, and say what each one watches for.