Optional: 2.1.7 Independent Verification of Training Claims

Allow 35 minutes of selected reading, 40 minutes for the lesson, and 35 minutes for the exercise and answer review.

Why optional: This supplement goes further into how a declared training history might be checked. You can proceed directly from 2.1.6 and complete the core policy track. Take this lesson if you expect to assess research proposals, commission verification systems, or need to understand what a “proof of training” actually establishes. “Technical” means examining the mechanism and its assumptions; you will not run code, reproduce experiments, or derive cryptographic proofs. The three reading cards are assigned excerpts for readers taking this supplement, not whole papers.

A Different Route to Evidence

In 2.1.4, we asked how much work occurred and what kind of workload produced the observed signals. In 2.1.6, we asked which measurement paths survive a compromised component. Here we examine another route: ask the developer to supply a training history and check parts of the computation independently.

Return to the emergency-pause case. A developer says that a permitted run began from a particular model, used a declared procedure and dataset, and stayed within its authorization. It supplies intermediate model states and says an inspector can reproduce selected intervals. This could make the account much more testable. It also changes the question: a test of a supplied history is not automatically a search for work omitted from that history.

Keep three claims separate:

The second claim depends on how the agreement defines a run. If it covers a development project, a record of one successful training trajectory may omit failed attempts or other experiments that still count. That is the counting-rule problem from 2.1.4, not a defect that replay alone can repair.

What Would the Verifier Replay?

A checkpoint is a saved state of training. It may contain model weights and additional information needed to resume. A training transcript connects checkpoints to the procedure, inputs, and sequence of updates that allegedly produced them.

To replay an interval, the verifier needs more than its starting weights. Depending on the procedure, it may need the optimizer’s accumulated state, the order of training examples, settings controlling updates, random choices, and relevant software and numerical conventions. The optimizer is the procedure that changes the weights; its stored state can affect the next update even when the weights themselves are unchanged.

An illustrative check works like this:

1. The developer fixes a record of the claimed starting state, procedure, and inputs.
2. It preserves intermediate states and records sufficient to reproduce specified intervals.
3. The verifier chooses intervals under an agreed challenge procedure.
4. The verifier reruns them and compares the resulting states with those in the record.
5. The verifier reports the match, mismatch, or inability to complete the check, with the test’s scope and assumptions.

This is a course-authored illustration, not the specification of every protocol below. A commitment binds a party to a value so that changing it later can be detected under the scheme’s assumptions. A commitment does not establish that the original value was true. Nor should a bare hash automatically be treated as concealing predictable data.

Fixing the record before the verifier’s unpredictable selection limits the developer’s ability to prepare only the challenged intervals. But it does not establish how the record relates to physical execution. An internally consistent history, contemporaneous evidence of a particular execution, and a complete account of a project’s compute are different objects of verification.

Research Case: A Proposed Proof Meets Adversarial Testing

Jia et al. introduced proof-of-learning in 2021, motivated partly by model ownership and integrity of outsourced training. Their scheme records intermediate states and checks selected updates by re-execution. The intended assurance includes making a forged history no cheaper to obtain than honest training.

Fang et al. subsequently developed attacks on the proposed verification mechanism. Two issues matter here: tolerated numerical differences can conceal invalid updates, and an efficient selection rule can let an adversary influence which updates receive scrutiny. Their work challenges the scheme’s robustness; it does not establish that every possible method of verifying training is impossible.

For a pause agreement, the threat model also changes. An ownership scheme that deters someone unwilling to spend as much as the original trainer does not necessarily deter a state willing to fund expensive deception. Ask whether the attacker’s budget and objective match the policy problem before borrowing the security claim.

Matching a Checkpoint Is a Test With a Specification

What counts as a match? Repeating floating-point computation on a different stack can yield numerical differences. A replay procedure must either constrain execution sufficiently for exact comparison or justify a tolerance. A permissive tolerance may admit a false account; an excessively strict one may reject an honest one. Fang’s discussion makes this a security question, not merely an engineering inconvenience.

For a procurement review, ask for two kinds of validation: honest runs under the configurations the system will permit, and adversarial attempts to obtain acceptance for false histories. An accuracy figure without the tested deviations and permitted configurations is not enough.

A failed replay is also not automatically a legal finding. Missing replay state, a software discrepancy, and a fabricated checkpoint can each prevent a match. Preserve the evidence and investigate the cause. The response to an unresolved failure belongs in the review and suspension procedures from 2.1.5.

Strengthening the Transcript Check Changes Its Requirements

Choi, Shavit, and Duvenaud propose training-data verification that adds initialization and data-order commitments and tests based on temporary memorization of recently seen data. They report empirical defenses, while explicitly acknowledging attacks not covered and limits of generalization. Their protocol also requires the verifier to access sensitive material; an isolated cluster trusted by both sides is discussed as a possible way to reduce leakage.

This returns us to 2.1.6. A verification cluster is computing capacity used to perform the checks. It may create an independent execution path, but independence depends on who controls its software, inputs, administration, and outputs. Keeping it off the internet restricts one route of disclosure; it does not settle maintenance access or what an inspector can export.

The policy decision is therefore partly about access: who may see weights, data, code, and results, and under what controls? “Independent verification” need not mean public disclosure. It does require a credible account of why the party making the original claim cannot also dictate the test result.

Zero Knowledge Changes Disclosure, Not the Scope of the Statement

In a zero-knowledge proof, a prover can establish a specified mathematical statement while concealing its private supporting information, subject to the proof system’s assumptions. The verifier still learns the public statement and its result; the surrounding system may disclose metadata.

For training verification, distinguish three questions:

• What relation is checked? For example, do committed inputs and a specified update procedure produce a committed output?
• How much is checked? One update, selected updates, or an entire linked computation?
• What connects it to the policy claim? The identity of the model being deployed, the physical execution being monitored, and the legal definition of counted work.

Proving that an output satisfies a computation does not, by itself, identify where or when that computation happened. Nor does it prove the absence of an additional computation. These connections require evidence and assumptions outside the mathematical relation.

There is a terminology trap. In proof-system literature, completeness generally concerns acceptance of valid statements supported by honest proofs. That is different from this course’s question of whether all covered activity has been accounted for. A protocol can have cryptographic completeness while its audit omits an entire facility.

Peigné, Nguyen, and Wang’s 2026 proposal combines commitments, external network observations, and zero-knowledge checks, targeting dense pretraining. Its revised version explicitly limits what sparse auditing establishes. The authors forecast a proof of concept in roughly 36 months; this is their estimate, not an independently established deployment schedule.

The policy task is to evaluate the proposed combination. A valid proof of a sampled statement can coexist with a low probability of selecting a rare violation. Strong cryptography does not turn sparse sampling into exhaustive coverage.

Who Pays for Checking?

“Verification overhead” needs a denominator and a payer. Ask separately about recording during training, storing the record, producing proofs, checking proofs, and investigating discrepancies. A small proof may be quick to check but costly to generate. Low extra training time does not imply low total operating cost.

Replaying fewer intervals reduces work but may not reduce the minimum machine size needed to reproduce one interval. A verifier could need a substantial cluster briefly, even when its total computation is a small fraction of the original run. Compare peak capacity, total compute, storage, staff time, and delay to a usable decision.

A deployment forecast should be tied to milestones: a working implementation of the specified relation; measurements on the intended workload and hardware; adversarial evaluation; a confidentiality assessment; and an integrated pilot with explicit failure handling. Different milestones answer different questions. A component benchmark cannot stand in for all of them. The appropriate procurement response may be to fund a bounded experiment without yet treating its output as sufficient compliance evidence.

Exercise — All Sampled Intervals Passed

Hypothetical evidence review, continuing the pause case. A developer claims that model M’s entire covered development project complied with its authorization. It submits one transcript of 1,000 equal-cost intervals, beginning from an imported checkpoint. The transcript ends at a checkpoint whose identity matches model M. The agreement counts covered work across the project, including relevant earlier stages and failed branches.

The packet contains:

The audit team proposes increasing the sample to 100 distinct intervals. Use these calculated probabilities; you do not need to derive them:

These probabilities assume the selection and perfect replay test specified above. The number of invalid intervals is unknown in the actual packet. The table does not describe the performance of any cited paper.

Questions

Carry Forward

For any training-verification proposal, record the statement checked, the population covered, the attack tested, the information disclosed, and the total cost. Then identify what independent evidence must cover the remaining activity. This is enough to discuss a bounded policy role without implementing the proof system yourself.