Ledger-QA: Verifiable, Auditable QA

• Ledger-QA is a question-answering framework that ensures verifiable cognition by recording every learning update in a tamper-evident ledger.
• It uses Reflexive Formal Learning to convert discrete verifier outcomes into policy updates, aligning system behavior with safety protocols.
• The system incorporates cryptographic attestation and dual commitment to provide auditability and traceability of knowledge and governance actions.

Ledger-QA denotes a question-answering system whose behavior, updates, and safety properties are verifiable and auditable via a ledger and formal verification. In the MathLedger framework, it is not presented as a high-capability QA architecture but as an infrastructural design for verifiable cognition: every learning update and every accepted knowledge entry are driven by verifier outcomes, committed to an append-only monotone ledger, and made replayable through cryptographic attestation (Abdullah, 22 Dec 2025).

1. Architectural definition and epistemic loop

Ledger-QA is instantiated from four coupled components: a reasoning or learning policy, a verifier, a monotone cryptographically attested ledger, and Reflexive Formal Learning (RFL). The stated goal is not raw capability, but verifiable cognition: every learning update and every knowledge entry is backed by a verifier outcome and recorded in a tamper-evident, replayable form. The high-level “chain of verifiable cognition” is

$$\text{Input} \to \text{Proof-or-Abstain} \to \text{Ledger Attestation} \to \text{Dual Commitment} \to \text{Policy Update}$$

and the Phase I “FO cycle harness” pipeline is described as UI Event, Curriculum Gate, Derivation Engine, Verifier, Dual Attestation, and RFL (Abdullah, 22 Dec 2025).

Formally, the ledger $\mathcal{L}$ is a sequence of blocks,

$\mathcal{L} = (B_1, B_2, \ldots),$

where each block contains verifier-accepted proof artifacts together with canonical statement hashes, verifier status, and a Merkle root $R_t$ over sorted proof IDs. The knowledge state after $t$ blocks is

$K_t := \bigcup_{i=1}^{t} B_i,$

with monotonicity

$K_t \subseteq K_{t+1} \quad \forall t.$

The ledger head hash evolves as

$L_t = \mathrm{Hash}(L_{t-1} \| R_t),$

which gives an append-only, hash-chained, tamper-evident log.

Dual attestation binds reasoning state and interface state at each epoch. The reasoning root $r_t$ is a digest over canonicalized proof artifacts, the UI root $u_t$ is a digest over interface state such as DOM, logs, UI events, and user confirmations, and the combined hash is

$\mathcal{L}$0

The triple $\mathcal{L}$1 is the “epistemic fingerprint” of epoch $\mathcal{L}$2: the minimal canonical summary of that cycle. In a Ledger-QA deployment, the paper maps events $\mathcal{L}$3 to $\mathcal{L}$4 tuples, with the verifier checking correctness, policy adherence, and related properties before the answer is treated as valid.

2. Reflexive Formal Learning

RFL is the learning rule that converts verifier outcomes into policy updates. The policy space is $\mathcal{L}$5, interpreted as symbolic reasoning policies, and each policy $\mathcal{L}$6 induces an event distribution $\mathcal{L}$7 over reasoning events $\mathcal{L}$8. Verification produces a ternary outcome

$\mathcal{L}$9

where $\mathcal{L} = (B_1, B_2, \ldots),$0 is pass, $\mathcal{L} = (B_1, B_2, \ldots),$1 is fail, and $\mathcal{L} = (B_1, B_2, \ldots),$2 is abstention.

The optimization target is epistemic risk,

$\mathcal{L} = (B_1, B_2, \ldots),$3

RFL seeks policies with lower $\mathcal{L} = (B_1, B_2, \ldots),$4. Its update rule is

$\mathcal{L} = (B_1, B_2, \ldots),$5

where $\mathcal{L} = (B_1, B_2, \ldots),$6 is algebraic composition on policy space, $\mathcal{L} = (B_1, B_2, \ldots),$7 is the step size, and $\mathcal{L} = (B_1, B_2, \ldots),$8 maps verifier outcome and current policy to a policy adjustment. Under bounded updates, martingale noise, and Robbins–Monro stepsizes, the update can be written in stochastic approximation form as

$\mathcal{L} = (B_1, B_2, \ldots),$9

with mean drift $R_t$0 and martingale-difference noise $R_t$1.

This differs from gradient descent in both signal and objective. Standard learning uses continuous loss and gradients; RFL uses a discrete verifier signal $R_t$2. Standard objectives minimize prediction error or maximize likelihood; RFL minimizes the probability of failing formal verification. Standard training tolerates silent behavior drift so long as empirical loss decreases; RFL makes failed and abstained events visible as logged negative knowledge. The paper also treats abstention as first-class: abstention avoids false positives, can indicate appropriate caution, and, in a QA setting, directly supports “I don’t know” behavior when verification fails (Abdullah, 22 Dec 2025).

3. Measurement substrate and fail-closed governance

Phase I is explicitly framed as a validation of measurement and governance infrastructure rather than of capability. The core measurements are abstention rate, $R_t$3 as a per-cycle “success rate proxy,” and variance tracking between experimental arms. In CAL-EXP-3, the baseline arm uses learning rate $R_t$4 with RFL off and a static policy, while the treatment arm uses $R_t$5 with RFL on. The reported behavior is oscillatory $R_t$6 dynamics around a decision threshold in both arms, and no convergence or improvement is claimed; the point is that $R_t$7 computation, variance tracking, and governance-predicate wiring function as intended (Abdullah, 22 Dec 2025).

The governance layer is fail-closed. Predicates monitor measurements and trigger when they move out of pre-specified bounds. Two stress-tested examples are F5.2, a variance-ratio predicate, and F5.3, a windowed-drift predicate. When these fire, the system caps the claim level at L0, meaning no capability claim is allowed, and some updates may be marked as INADMISSIBLE_UPDATE, recorded in the governance evidence but excluded from learning. In Phase I this is run in SHADOW mode: governance effects are non-blocking for production, but the evidence is still recorded with binding hashes, and governance verdicts still cap claims.

For Ledger-QA, this governance logic is directly extensible. If verified accuracy drifts unexpectedly, if safety-metric variance exceeds tolerated levels, or if abstention behavior becomes anomalous, governance could freeze updates, force abstention in governed domains, escalate to human review, and log all such interventions. A plausible implication is that Ledger-QA treats safety not as a post hoc moderation layer but as a governed property of the learning substrate itself.

4. Ledger-attested QA operation and negative knowledge

The paper’s concrete mapping of MathLedger to QA gives a seven-step flow for a single interaction. A user question $R_t$8 arrives as a UI event; a curriculum or policy gate decides whether the query is within a governed domain; the learner $R_t$9 proposes an answer $t$0 and reasoning trace $t$1; the verifier computes $t$2; logging records pass, fail, or abstain artifacts; dual attestation computes $t$3, $t$4, and $t$5; and RFL applies the update rule

$t$6

Only verified events with $t$7 serve as positive learning signals (Abdullah, 22 Dec 2025).

In the QA setting, the verifier may be a proof assistant kernel such as Lean, a consistency checker for domain invariants, a policy verifier for safety or regulatory rules, or a provenance checker ensuring that disallowed sources were not used. For successful events, the ledger stores canonical hashes of $t$8, $t$9, and $K_t := \bigcup_{i=1}^{t} B_i,$0, together with verifier status and metadata such as timestamp and policy version. The combined epoch hash $K_t := \bigcup_{i=1}^{t} B_i,$1 may also be recorded as ledger metadata.

A central notion is negative knowledge. Refuted artifacts, abstentions, and inadmissible updates are logged as governance-bound evidence, classified through artifact_kind values such as REFUTED, ABSTAINED, and INADMISSIBLE_UPDATE. They are explicitly excluded from the monotone knowledge ledger and from RFL’s positive structural learning signal, but they remain part of the replayable evidence pack. This allows later statements such as “this QA pattern was attempted and rejected under governance version $K_t := \bigcup_{i=1}^{t} B_i,$2.” In operational terms, Ledger-QA is therefore not only a store of accepted knowledge; it is also a typed record of failure, refusal, and blocked adaptation.

5. Cryptographic attestation, replay, and auditability

The cryptographic substrate is deliberately simple and explicit. The paper describes SHA-256 hashes for evidence manifest entries, the governance registry hash, and files in the evidence pack. The evidence manifest contains fields such as commitment_registry_sha256, which hashes the Governance Commitment Registry (GCR), and artifact_kind, which tags artifacts as VERIFIED, REFUTED, ABSTAINED, or INADMISSIBLE_UPDATE. The replay verifier checks that artifact_kind is present and valid, that commitment_registry_sha256 matches the actual registry file, and that any mismatch fails verification with exit code 1 (Abdullah, 22 Dec 2025).

This makes governance itself cryptographically visible. Even if policy semantics remain informal, the existence and version of the active governance commitments are bound into the evidence. The lemma on dual attestation’s binding property states that once

$K_t := \bigcup_{i=1}^{t} B_i,$3

is published, the pair $K_t := \bigcup_{i=1}^{t} B_i,$4 is effectively immutable absent a hash collision. Any learning update can therefore be traced back to verifier outcome, accepted artifacts, UI context, and the frozen GCR hash active for that run.

Implementation details reinforce the prototype status. Phase I uses a synthetic proxy verifier; Phase II+ is intended to integrate Lean. Evidence-pack tooling uses SHA-256 and RFC 8785 canonical JSON for hashing the Governance Commitment Registry, together with a replay verifier verify.py that checks file hashes, governance registry hash, and artifact kinds. The paper also notes version pinning via Git tag v0.9.4-pilot-audit-hardened, and Python plus uv for running drop-in demos. In a different ledger-backed QA lineage, offline-verifiable registry answers have been implemented through Ledger State Attestations, aggregate BLS signatures, and offline verification of smart-contract responses, illustrating that “ledger-attested answers” can also denote provenance-checked query results rather than verifier-driven learning updates (More et al., 2022).

6. Limits, non-claims, and broader significance

The paper is explicit about what Ledger-QA does not establish. There are no convergence guarantees for RFL under Phase I conditions; all runs failed the variance gate. There is no claim of improved theorem proving, question answering, or general reasoning capability. There are no generalization guarantees, no out-of-distribution or real-world tests, and no claim that the frozen governance thresholds are optimal. Phase I runs only in SHADOW mode, so verification is observational rather than actively gating production behavior. The threat model assumes honest-but-fallible operators and does not handle Byzantine adversaries, compromised verifiers, or malicious governance authors (Abdullah, 22 Dec 2025).

These limitations matter because the framework is easy to misconstrue as a turnkey safety layer for large QA models. The paper states the opposite. MathLedger supplies infrastructure to measure, attest, and govern; it does not make a QA system accurate by construction, and it does not automatically make one safe. A plausible implication is that the hardest open problems are shifted, not removed: verifier strength, specification design, admissibility rules, threshold calibration, and the translation of probabilistic model outputs into formally checkable artifacts.

In that respect, Ledger-QA belongs to a broader family of work that treats ledger systems as formal or cryptographically structured substrates rather than mere storage backends. Formalization of the FA1.2 ledger standard as a reusable Coq theory shows how ledger semantics can be made mathematically precise and verified across multiple implementations, while MathLedger extends formalization into an epistemic loop where verifier outcomes drive admissible learning (Gabbay et al., 2021). The conceptual significance of Ledger-QA lies less in a new QA benchmark or model class than in a particular claim about system architecture: a question-answering system can, in principle, be organized so that accepted knowledge, rejected knowledge, governance state, and policy updates are all jointly auditable, replayable, and cryptographically bound.