---
title: Proof-Carrying Numbers (PCN)
url: https://www.emergentmind.com/topics/proof-carrying-numbers-pcn
type: topic
---
# Proof-Carrying Numbers (PCN)
Proof-Carrying Numbers (PCN) is a protocol for trustworthy numeric answers from large language models 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 [2509.06902].
## 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 [2509.06902].
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
```html
VAL
```
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 `` tag is a *Bare number* and defaults to unverified [2509.06902].
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 $u$. Given a policy $\Pi$, defined as a set of allowed modes, the judgment
$$
R(t,c;\Pi)=1
$$
holds iff there exists a permitted mode in $\Pi$ under which $\hat v$ matches $v^*$ [2509.06902].
The standard policy modes are the following.
| Mode | Condition | Notes |
|---|---|---|
| Exact equality | $\hat v=v^*$ | Strict identity |
| Rounded match at $d$ decimal places | $\mathrm{round}_d(\hat v)=\mathrm{round}_d(v^*)$ | Decimal rounding |
| Alias equivalence over a sanctioned set $S$ | $\exists s\in S:\hat v\cdot s=v^*$ | Examples include `K`, `thousand` |
| Tolerance with qualifiers $(\delta,\rho)$ and qualifier set $Q$ | $\hat v\in[v^*-\max(\delta,\rho|v^*|),\,v^*+\max(\delta,\rho|v^*|)]$ and a qualifier $\in Q$ | Example qualifier: `about` |
A global policy $\Pi$ can combine these modes, and $R(t,c;\Pi)=1$ if any allowed mode holds [2509.06902]. 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$; the generator, an LLM, produces text containing `` tags; the verifier in the renderer mechanically checks each token $t$ by looking up its `cid` in $C$ and evaluating $R(t,c;\Pi)$; and the UI marks tokens as Verified with a ✓ badge and provenance tooltip, or leaves them unmarked as Bare or “verify-pending” [2509.06902].
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 [2509.06902].
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
$$
A(y,C;\Pi)=\{(t_j,\mathit{label}_j)\}_j
$$
denote the renderer’s labeling of each numeric span $t_j\in y$ as Verified or Unverified. The protocol states several formal properties [2509.06902].
**Theorem 4.1 (Soundness):** If $A$ labels $t$ as Verified, then there exists $c\in C$ with $R(t,c;\Pi)=1$.
**Theorem 4.2 (Completeness under honest tokens):** If the LLM emits a claim-bound token $t$ referencing $c\in C$ and $R(t,c;\Pi)=1$, then $A$ labels $t$ Verified.
**Theorem 4.3 (Fail-Closed):** Any span that lacks a valid claim reference, references a non-existent `cid`, or fails $R(t,c;\Pi)$ is labeled Unverified.
**Lemma 4.4 (Monotonicity under policy refinement):** If $\Pi_1\preceq\Pi_2$ and $\Pi_1$ is stricter, then
$$
\{t: A_{\Pi_1}(t)=\text{Verified}\}\subseteq\{t: A_{\Pi_2}(t)=\text{Verified}\}.
$$
**Theorem 4.5 (Renderer robustness / anti-spoofing):** If verification marks are computed by the renderer, adversarial attempts to inject badge symbols into $y$ cannot cause an Unverified token to appear as Verified.
**Proposition 4.6 (Linear-time verification):** If claims are indexed by `cid`, verifying all $n$ numeric spans incurs $O(n)$ time, and policy checks such as rounding, alias lookup, and interval checking are constant-time [2509.06902].
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` [2509.06902].
A second TypeScript function, `processPCNClaims(html, claims, policy)`, applies a replacement over claim tags of the form
```html
...
```
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 $\hat v$, 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 [2509.06902].
The paper also defines a cryptographic extension. Each claim $c$ can carry a cryptographic commitment, for example a PKI signature or a Merkle proof path for tabular data. Verification then requires both $R(t,c;\Pi)=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 [2509.06902].
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 `` 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 [2509.06902].
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 [2509.06902].
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 [2509.06902].
Source: https://www.emergentmind.com/topics/proof-carrying-numbers-pcn