This unit covers the mechanisms themselves. Concrete ways a third party might check claims about AI development. It is deliberately broad. One reading per track, so you leave knowing what each track covers and can choose one to focus on in Unit 3.
As you read, keep the claim being verified separate from how the evidence for it is gathered. Usually the claim itself is a single thing, say that a given workload is not being run, or that a chip is where it claims to be. What changes from one paper to the next is the evidence channel: an on-chip attestation, an off-chip measurement, a cryptographic proof, physical access for a human inspector, or a certification regime. Read this way the mechanisms stop being a long list and become different answers to the same small set of questions.
Read the system overview first, then move through the tracks in any order.
A working draft of the whole verification stack: what has to be sensed, what has to be proven, what information can safely cross the boundary, and what kind of adversary the system is meant to survive.
Sections 1 to 3.
Mechanisms that try to make the chip, package or attached hardware produce evidence about where it is, what it is allowed to run, or what work it performed.
The policy-facing case for on-chip governance: secure hardware could support export-control enforcement, operating licences and future agreement verification without creating a general surveillance back door.
Executive summary, technical underpinnings, implementation challenges and recommendations.
A concrete architecture for adding a guarantee processor around AI accelerators, so a regulator can get workload guarantees while the operator keeps models and data private.
Abstract, introduction and the system-design section.
Checking whether an output plausibly came from the claimed model, even when exact deterministic replay is unavailable.
A plain-language introduction that frames inference verification as selective recomputation. The verifier checks randomly chosen steps, so the prover cannot know in advance which work must be reproducible.
The full post.
Proving a claim about a model or training run without revealing the weights or data.
The shortest introduction to ZK audit logic: proving that training or evaluation was computed correctly while keeping the model, data or audit details hidden.
The full paper.
A proposal for proving properties of a frontier training run without revealing the model or dataset, using a proving architecture designed around the training trace.
The introduction and the protocol-design sections.
Reading network, timing, memory and other side-channel signals to infer what a cluster is doing.
The main distinction is in the summary: network taps are much more plausible for low-bandwidth north-south traffic than for high-bandwidth east-west accelerator fabric, where link budgets and covert channels dominate.
The three-minute summary only.
The compute-monitoring proposal that later work builds on: inspecting chips and datacentres well enough to detect large training-rule violations. Its most distinctive idea is proof of learning from training checkpoints, which is closer to proving a training run than to telemetry.
The full paper.
Explains why cloud providers are attractive intermediaries for AI regulation. They already sit between users and compute, and can record, verify or enforce some rules at lower cost than direct state inspection.
Introduction, the governance-capacities section, and the conclusion.
Trusted environments, audit protocols and certification regimes that produce evidence someone else can check.
A TEE-based audit protocol for proving that a benchmark ran on a specific model and dataset while keeping sensitive model and benchmark details protected.
The full paper.
Finished this unit? Please give us your feedback on how it went!