Proof-Carrying Numbers (PCN)

• Proof-Carrying Numbers (PCN) is a protocol that binds numeric outputs to structured claims, ensuring only mechanically verified numbers are trusted.
• The system separates retrieval, generation, and verification by using claim-bound tokens and explicit policies like rounding or tolerance to validate numeric spans.
• PCN integrates formal guarantees and cryptographic extensions, offering soundness, completeness, and tamper-evident properties for numeric data verification.

Proof-Carrying Numbers (PCN) is a protocol for trustworthy numeric answers from LLMs by enforcing claim verification at the presentation layer rather than inside the model itself. It is motivated by numeric hallucination, in which LLMs as stochastic systems may generate numbers that deviate from available data. Under PCN, numeric spans intended to be verified are emitted as claim-bound tokens tied to structured claims, and a verifier in the renderer checks each token under a declared policy such as exact equality, rounding, aliases, or tolerance with qualifiers. Only claim-checked numbers are marked as verified; all other numeric spans default to unverified. The protocol is formalized with proofs of soundness, completeness under honest tokens, fail-closed behavior, and monotonicity under policy refinement, and it is described as lightweight, model-agnostic, and extensible to cryptographic commitments (Solatorio, 8 Sep 2025).

1. Protocol object model and tokenization

PCN begins from a retrieval setting in which a query $q$ is resolved by a retriever into a finite claim set

$C=\{c_1,\dots,c_m\}.$

Each claim has the form

$$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$

where $v^*\in\mathbb{R}$ is a real reference value, $u$ is a unit, and $m$ is metadata (Solatorio, 8 Sep 2025).

The generator emits a token sequence $y=(y_1,\dots,y_T)$. Any numeric span intended to be verified must be emitted as a claim-bound token of the form $m$2 Here, CID is the identifier of some claim $c$ in the retrieved claim set $C$, P is an optional policy label such as "exact", "round1", "alias-thousand", or "tol(±0.1%)", and VAL is the surface string such as "5.7%" or "6". Any numeric span emitted without a <claim> tag is a Bare number and defaults to unverified (Solatorio, 8 Sep 2025).

By binding surface text to structured claims, the model output remains fluent while verification is delegated to a downstream renderer. This design makes the token markup the interface between generation and verification rather than the locus of trust itself.

2. Verification semantics and policy space

Verification is defined over the parsed and normalized numeric value. Let $\hat v$ be VAL parsed and normalized into the claim’s unit $C=\{c_1,\dots,c_m\}.$0. Given a policy $C=\{c_1,\dots,c_m\}.$1, defined as a set of allowed modes, the judgment

$C=\{c_1,\dots,c_m\}.$2

holds iff there exists a permitted mode in $C=\{c_1,\dots,c_m\}.$3 under which $C=\{c_1,\dots,c_m\}.$4 matches $C=\{c_1,\dots,c_m\}.$5 (Solatorio, 8 Sep 2025).

The standard policy modes are the following.

Mode	Condition	Notes
Exact equality	$C=\{c_1,\dots,c_m\}.$6	Strict identity
Rounded match at $C=\{c_1,\dots,c_m\}.$7 decimal places	$C=\{c_1,\dots,c_m\}.$8	Decimal rounding
Alias equivalence over a sanctioned set $C=\{c_1,\dots,c_m\}.$9	$$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$0	Examples include K, thousand
Tolerance with qualifiers $$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$1 and qualifier set $$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$2	$$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$3 and a qualifier $$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$4	Example qualifier: about

A global policy $$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$5 can combine these modes, and $$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$6 if any allowed mode holds (Solatorio, 8 Sep 2025). The protocol therefore makes numeric acceptability explicit and configurable. Exact equality supports strict reporting, while rounding, alias equivalence, and tolerance with qualifiers accommodate conventional presentation practices without collapsing them into unchecked free text.

3. Retrieval–generation–verification separation

PCN imposes a strict separation between retrieval, generation, and verification. The stated architecture has four stages: the retriever, such as an MCP server or DB/API, produces $$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$7; the generator, an LLM, produces text containing <claim> tags; the verifier in the renderer mechanically checks each token $$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$8 by looking up its cid in $$c=\langle \mathit{cid},\;\text{indicator},\;\text{entity},\;\text{time},\;v^*,\;u,\;m\rangle,$$9 and evaluating $v^*\in\mathbb{R}$0; and the UI marks tokens as Verified with a ✓ badge and provenance tooltip, or leaves them unmarked as Bare or “verify-pending” (Solatorio, 8 Sep 2025).

This placement of verification in the renderer is central. Because the model does not control the verification mark, prompt-injection attempts or model-generated “✓” characters are ignored; only the renderer’s judgments determine whether a token appears verified. The protocol therefore enforces a fail-closed contract in which unverified is the default state (Solatorio, 8 Sep 2025).

The design addresses a limitation of existing safeguards named in the paper—retrieval-augmented generation, citations, and uncertainty estimation—which can improve transparency but cannot guarantee fidelity because fabricated or misquoted values may still be displayed as if correct. PCN changes the display semantics: a number is not trusted because it is plausible, cited, or stylistically confident, but because it has passed a mechanical verification step.

4. Formal guarantees

Let

$v^*\in\mathbb{R}$1

denote the renderer’s labeling of each numeric span $v^*\in\mathbb{R}$2 as Verified or Unverified. The protocol states several formal properties (Solatorio, 8 Sep 2025).

Theorem 4.1 (Soundness): If $v^*\in\mathbb{R}$3 labels $v^*\in\mathbb{R}$4 as Verified, then there exists $v^*\in\mathbb{R}$5 with $v^*\in\mathbb{R}$6.

Theorem 4.2 (Completeness under honest tokens): If the LLM emits a claim-bound token $v^*\in\mathbb{R}$7 referencing $v^*\in\mathbb{R}$8 and $v^*\in\mathbb{R}$9, then $u$0 labels $u$1 Verified.

Theorem 4.3 (Fail-Closed): Any span that lacks a valid claim reference, references a non-existent cid, or fails $u$2 is labeled Unverified.

Lemma 4.4 (Monotonicity under policy refinement): If $u$3 and $u$4 is stricter, then

$u$5

Theorem 4.5 (Renderer robustness / anti-spoofing): If verification marks are computed by the renderer, adversarial attempts to inject badge symbols into $u$6 cannot cause an Unverified token to appear as Verified.

Proposition 4.6 (Linear-time verification): If claims are indexed by cid, verifying all $u$7 numeric spans incurs $u$8 time, and policy checks such as rounding, alias lookup, and interval checking are constant-time (Solatorio, 8 Sep 2025).

Taken together, these results define a precise trust model. Verified status is justified by a matching claim under policy; honest compliant tokens are not spuriously rejected; malformed or unsupported spans do not silently inherit trust; relaxing policy only expands the verified set; renderer-side badges resist spoofing; and the verification pass is computationally lightweight.

5. Implementation pattern and cryptographic extension

The implementation overview includes a TypeScript example for aggregating claims from retriever outputs. In getClaims(messages), the system iterates over tool-role messages, reads m.toolContent?.output?.parsed?.data, and for each datum with d.claim_id stores an entry keyed by claim_id with value, country, and date (Solatorio, 8 Sep 2025).

A second TypeScript function, processPCNClaims(html, claims, policy), applies a replacement over claim tags of the form $m$3 For each match, it looks up claims[cid]; if no claim is found, it returns markup with a verify-pending ✗. Otherwise it parses and normalizes val into $u$9, invokes verifyMode(v̂, c.value, p || policy), and returns either a verified-mark ✓ or a verify-pending ✗ with a title showing the expected value. Bare numbers remain unmodified and unbadged, and clients can plug the function into any HTML-rendering pipeline (Solatorio, 8 Sep 2025).

The paper also defines a cryptographic extension. Each claim $m$0 can carry a cryptographic commitment, for example a PKI signature or a Merkle proof path for tabular data. Verification then requires both $m$1 and validation of the signature or Merkle proof. Under standard EUF-CMA and hash-collision-resistance assumptions, an adversary cannot forge a valid signature or proof, making the badges tamper-evident as stated in Theorem 4.7 (Solatorio, 8 Sep 2025).

This extension preserves the core PCN structure while adding source-integrity guarantees. A plausible implication is that PCN can operate both as a renderer-level semantic check and, when commitments are present, as a bridge to stronger provenance assurances for retrieved numeric claims.

6. Scope, limitations, and open questions

The protocol’s limitations are explicitly stated. Coverage depends on the LLM actually emitting <claim> tags; poor tagging recall yields many unverified spans. Policy misconfiguration can be problematic in either direction: a policy that is too strict can frustrate users, while one that is too lax can weaken guarantees. Users may also over-generalize the badge to non-numeric claims or reasoning, but PCN does not verify logical inference or free-text facts (Solatorio, 8 Sep 2025).

The paper further notes that extension to derived values such as aggregates and ratios requires verifying functions over multiple claims, and that institutional deployment raises governance questions including liability and multi-provider trust chains. Empirical user-behavior studies and tooling for policy presets are identified as future work (Solatorio, 8 Sep 2025).

These constraints delimit what PCN is designed to solve. It transforms numeric hallucination into a mechanical presentation-layer contract for explicitly tagged numeric spans, not a general framework for validating arbitrary model outputs. Within that scope, the protocol’s central rule is concise: only spans proven by structured claims under an explicit policy receive a verification mark, while the absence of a mark communicates uncertainty (Solatorio, 8 Sep 2025).