# AI verification proposal

A proposal built with the Proposal Explorer of the AI Verification Tech Map (https://trustbutveri.fyi/), from its records of 2026-10-09. Interactive version: https://trustbutveri.fyi/explorer/?mechanisms=M-0003,M-0016,M-0007&chips=existing

How to read it: a claim is something one party wants to verify about another's AI hardware or software. A mechanism is a general technique for verifying claims; it is "aimed at" a claim when that is its direct purpose, and "supporting" when it contributes without being aimed at it. A claim is addressed when a mechanism in the proposal is aimed at it and is not excluded by the filters; addressed does not mean verified, so check that mechanism's development status, security evidence and findings. Definitions: https://trustbutveri.fyi/about/methodology/ (roles, properties and findings) and https://trustbutveri.fyi/about/readiness/ (development status).

## Filters

Filters apply to mechanisms only and describe the setting the proposal is for.

- **Chips: Existing chips only.** "Existing chips only" removes mechanisms that need changes to future chip designs. New chip features take years to reach a deployed fleet and cover only chips made after they ship. Mechanisms that use shipping features, such as trusted execution environments or performance counters, stay.

23 of 25 mechanisms on the map pass these filters.

## Overview

One row per mechanism, read from its record. Open failures: critical / significant / minor. The last three columns are the editors' reading of what the verifier sees. Findings are grouped as known failures, scope limitations and open questions. Only known failures count as failures. Counts are an inventory of published findings, not a risk score.

| Mechanism | Development | Security evidence | Prover | Attack testing | Hardware | Open failures | Weights | Inputs and outputs | Training data |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Whole-workload recomputation (reproducible packets) | Proposed | No published adversarial analysis recorded | Adversarial | None | Retrofit device | 0 / 0 / 0 | depends | depends | depends |
| Timed challenge-response and memory-occupation challenges | Research demonstration | Published security analysis | Adversarial | Analysis | None | 0 / 1 / 0 | not involved | not involved | not involved |
| Proofs of useful work for capacity accounting | Proposed | Published security analysis | Adversarial | Analysis | None | 0 / 1 / 0 | depends | depends | not involved |

## Claims

No claims chosen.

## Mechanisms

### Whole-workload recomputation (reproducible packets)

Organizing all AI workloads in a facility into discrete, reproducible units, so that a verifier can recompute a random sample and check each one. ([Whole-workload recomputation (reproducible packets)](https://trustbutveri.fyi/mechanisms/reproducible-computation-packets/))

- Assessment: mechanism family.
- Development: Proposed (legacy code R1), assessed for recomputing whole workloads to show a cluster runs only declared inference.
- Security evidence: No published adversarial analysis recorded. Independent evaluation: unassessed. Formal proof: unassessed. Deployment assurance: unassessed.
- Claims in this proposal: none of them.
- Threat model: adversarial prover. Hardware: retrofit device. Prover cooperation: required. Attack testing: none. Category: Isolation & system architectures.
- What the verifier sees: model weights depends; inputs and outputs depends; training data depends. Recomputing sampled units needs weights and sampled inputs or training data inside the checking environment. The design depends on securing that environment; disclosure depends on its confidentiality boundary.

### Timed challenge-response and memory-occupation challenges

A verifier times answers to unpredictable questions designed so that answering correctly and in time requires holding specified data locally or dedicating specified resources. ([Timed challenge-response and memory-occupation challenges](https://trustbutveri.fyi/mechanisms/timed-challenge-response/))

- Assessment: mechanism family.
- Development: Research demonstration (legacy code R2), assessed for detecting whether a GPU is doing other work.
- Security evidence: Published security analysis. Independent evaluation: unassessed. Formal proof: unassessed. Deployment assurance: unassessed.
- Claims in this proposal: none of them.
- Threat model: adversarial prover. Hardware: none. Prover cooperation: required. Attack testing: analysis. Category: Cryptographic & computational.
- What the verifier sees: model weights not involved; inputs and outputs not involved; training data not involved. Uses verifier-chosen challenges; it does not handle model data.

### Proofs of useful work for capacity accounting

Cryptographic evidence that a given amount of matrix-multiplication work was completed, proposed as one input to bounding how much spare capacity declared hardware has. ([Proofs of useful work for capacity accounting](https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/))

- Assessment: mechanism family.
- Development: Proposed (legacy code R1), assessed for bounding the spare capacity of declared hardware that could run training.
- Security evidence: Published security analysis. Independent evaluation: unassessed. Formal proof: unassessed. Deployment assurance: unassessed.
- Claims in this proposal: none of them.
- Threat model: adversarial prover. Hardware: none. Prover cooperation: required. Attack testing: analysis. Category: Cryptographic & computational.
- What the verifier sees: model weights depends; inputs and outputs depends; training data not involved. Checking a sampled tile of a matrix multiplication reveals that tile, which may hold model or input data; the authors suggest a zero-knowledge proof when the matrices must stay private.


## Properties

**Built for an adversarial prover**

- Whole-workload recomputation (reproducible packets)
- Timed challenge-response and memory-occupation challenges
- Proofs of useful work for capacity accounting

**No new hardware needed**

- Timed challenge-response and memory-occupation challenges
- Proofs of useful work for capacity accounting


## Attack testing

Attack testing records published testing for this use. It does not by itself show independent review, a formal proof or that a deployed system is secure.

**Testing history**

- Timed challenge-response and memory-occupation challenges: Analysis
- Proofs of useful work for capacity accounting: Analysis


## Limits

**Open significant failures**

- Remote memory narrows the timing margin (known failure, theoretical argument, in Timed challenge-response and memory-occupation challenges; https://trustbutveri.fyi/mechanisms/timed-challenge-response/evidence/flaws/2/) [7]. Data-centre remote memory access returns in about 1–2 µs, against about 70–200 ns for local DRAM. The MIRI overview says verification of memory saturation depends on ruling out remote access by latency or physical disconnection. It names pre-staging data into local memory as the remaining evasion and proposes an unpredictable, capacity-filling challenge to close it.

  Related mechanism: Bandwidth limits and compartmentalization (R2, not in the proposal). Physical disconnection is proposed to exclude remote memory between the separated groups during a challenge. It depends on the isolation boundary being enforced.
- Known shortcuts let a miner claim somewhat more work than it did (known failure, theoretical argument, in Proofs of useful work for capacity accounting; https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/evidence/flaws/3/) [19]. Pearl's specification lists known mining speedups: crafted inputs, precision shortcuts, seed grinding, work reuse, and faster kernels or hardware. A policy check caps the summands a miner may skip at one-sixteenth of those in a tile. For capacity bounding, any gap between work proven and work possible leaves spare capacity.

**Scope limitations**

- Spare compute is outside the scheme (scope limitation, theoretical argument, in Whole-workload recomputation (reproducible packets); https://trustbutveri.fyi/mechanisms/reproducible-computation-packets/evidence/flaws/1/) [1][2]. The plan states that it does not verify that spare compute is not used for unapproved workloads, because this seems very challenging. Recomputation checks the correctness of declared work, not its completeness.

  Related mechanism: Proofs of useful work for capacity accounting (R1, in the proposal). Proposed as one input to accounting for spare capacity on declared hardware.
- Proves that work was done, not that no capacity remains (scope limitation, theoretical argument, in Proofs of useful work for capacity accounting; https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/evidence/flaws/1/) [16]. Proof-of-work accounting bounds unmonitored compute only relative to an estimate of what the actor has. Attestable states that the verifier "needs a credible estimate of the compute available" to the actor, and that a proof "cannot discover a datacenter that was never declared".

  Related mechanism: Chip registries and manufacturing records (R1, not in the proposal). A registry of chips is one basis for the estimate of available compute that the flaw's source says the verifier needs.

  Related mechanism: Remote detection of data centres (R1, not in the proposal). Looks for data centres that were never declared, which a proof cannot discover.

**Open questions**

- Non-compliant work could be encoded inside compliant-looking packets (open question, theoretical argument, in Whole-workload recomputation (reproducible packets); https://trustbutveri.fyi/mechanisms/reproducible-computation-packets/evidence/flaws/2/) [1]. The plan notes that an AI company might try to encode a non-compliant workload inside a workload that looks compliant on the surface.
- Error rates not quantified (open question, open question, in Timed challenge-response and memory-occupation challenges; https://trustbutveri.fyi/mechanisms/timed-challenge-response/evidence/flaws/3/) [8]. Monfared et al. show separable timing distributions. Their acceptance rule passes a GPU when its mean time per round stays at or below a chosen maximum, and an appendix outlines statistical tests for the proof-of-work puzzle. They leave hardware-specific threshold values to future work and report no false-positive or false-negative rates.
- Security rests on new hardness assumptions (open question, open question, in Proofs of useful work for capacity accounting; https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/evidence/flaws/2/) [18][19]. Komargodski and Weinstein base security on hardness assumptions about batches of low-rank random linear equations, and list PoUW "from more standard or well-studied assumptions" as an open problem. Pearl's floating-point variant introduces a further "quantized-subspace hardness" assumption.

**Not yet demonstrated**

- Whole-workload recomputation (reproducible packets): Proposed (legacy code R1), assessed for recomputing whole workloads to show a cluster runs only declared inference
- Proofs of useful work for capacity accounting: Proposed (legacy code R1), assessed for bounding the spare capacity of declared hardware that could run training


## Possible additions

Mechanisms on the map, not in the proposal, that the records connect to an unaddressed or partly addressed claim, an open failure or a dependency. Pointers, not recommendations: each brings its own readiness level and findings, and none is claimed to close a failure.

- **Bandwidth limits and compartmentalization** (Research demonstration (legacy code R2), assessed for monitoring inter-node traffic with operator-run software on four GPUs)
  - Bears on the open significant failure "Remote memory narrows the timing margin" in Timed challenge-response and memory-occupation challenges. Physical disconnection is proposed to exclude remote memory between the separated groups during a challenge. It depends on the isolation boundary being enforced.
  - Timed challenge-response and memory-occupation challenges waits on it: Outside help, such as remote memory, must be excluded during challenges.
- **Deterministic and bit-exact inference** (Operational use (legacy code R3), assessed for reproducing open-model inference from receipts in Gensyn's information-market service)
  - Whole-workload recomputation (reproducible packets) waits on it: Workloads are not reproducible by default, and achieving reproducibility may cost performance.
- **Network taps and certifiers** (Proposed (legacy code R1), assessed for committing a complete record of cluster traffic, so declared inference can be checked)
  - Whole-workload recomputation (reproducible packets) waits on it: All traffic must reach the recomputation server via network taps, and the server's integrity is critical.


## Dependencies

**Missing prerequisites**

- Deterministic and bit-exact inference (Operational use (legacy code R3), assessed for reproducing open-model inference from receipts in Gensyn's information-market service), needed by Whole-workload recomputation (reproducible packets)
- Network taps and certifiers (Proposed (legacy code R1), assessed for committing a complete record of cluster traffic, so declared inference can be checked), needed by Whole-workload recomputation (reproducible packets)

**Blockers**

- Whole-workload recomputation (reproducible packets): Workloads are not reproducible by default, and achieving reproducibility may cost performance. (performance & compatibility; waits on Deterministic and bit-exact inference) [1]
- Whole-workload recomputation (reproducible packets): Network packets are not individually reproducible by default; making them so may need considerable software, firmware and hardware work. Amodo rates this 'not on track'. (performance & compatibility) [4]
- Whole-workload recomputation (reproducible packets): All traffic must reach the recomputation server via network taps, and the server's integrity is critical. (hardware trust; waits on Network taps and certifiers) [1][4]
- Whole-workload recomputation (reproducible packets): Recomputing training steps needs checkpoints: writing one at every step would cost more than 100% overhead, so Amodo's design needs a spare data-parallel replica that tracks the weights instead. (performance & compatibility) [2]
- Timed challenge-response and memory-occupation challenges: No network-level memory challenge across data-centre servers has been demonstrated. (adversarial validation) [7]
- Timed challenge-response and memory-occupation challenges: Challenges that fill memory displace workloads; filling a pod's volatile memory takes tens of minutes and SSDs take hours. (performance & compatibility) [7][8]
- Timed challenge-response and memory-occupation challenges: Outside help, such as remote memory, must be excluded during challenges. (coverage & hidden compute; waits on Bandwidth limits and compartmentalization) [7]
- Proofs of useful work for capacity accounting: Bounding spare capacity needs a credible estimate of the compute available to the actor, including third-party access. (capacity bounds) [16]
- Proofs of useful work for capacity accounting: Proofs of work cannot find facilities that were never declared. (coverage & hidden compute) [16]
- Proofs of useful work for capacity accounting: As of September 2026 no implementation, demonstration or independent evaluation of proofs of work for capacity bounding has been published. (adversarial validation)


## What the verifier sees

- Model weights: shown by none; depends on the design for Whole-workload recomputation (reproducible packets) and Proofs of useful work for capacity accounting; hidden by none; not involved in Timed challenge-response and memory-occupation challenges; unspecified for none.
- Inputs and outputs: shown by none; depends on the design for Whole-workload recomputation (reproducible packets) and Proofs of useful work for capacity accounting; hidden by none; not involved in Timed challenge-response and memory-occupation challenges; unspecified for none.
- Training data: shown by none; depends on the design for Whole-workload recomputation (reproducible packets); hidden by none; not involved in Timed challenge-response and memory-occupation challenges and Proofs of useful work for capacity accounting; unspecified for none.

## Implementations

- Whole-workload recomputation (reproducible packets): [AI 2040 inference-only verification stack](https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/) (R1, proposed architecture)
- Timed challenge-response and memory-occupation challenges: [Data-centre memory challenging](https://trustbutveri.fyi/implementations/data-centre-memory-challenging/) (R1, proposed architecture); [GPU contention probes](https://trustbutveri.fyi/implementations/gpu-contention-probes/) (R2, research prototype); [Low-trust AI compute verification system overview](https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/) (R1, proposed architecture); [SAGE](https://trustbutveri.fyi/implementations/sage-gpu-attestation/) (R2, research prototype); [VRAM-residency challenge](https://trustbutveri.fyi/implementations/vram-residency-challenge/) (R2, research prototype)
- Proofs of useful work for capacity accounting: [Pearl proof-of-useful-work blockchain](https://trustbutveri.fyi/implementations/pearl-proof-of-useful-work/) (R3, open-source project)

## Sources

1. Verification Plan, R. Dean (2026). https://ai-2040.com/supplements/verification-plan
2. Example Schemes for Verifying High-Stakes AI Agreements, Amodo Design (2026). https://amododesign.com/notes/2026-06-23-verification-algorithms/
3. Scaling Recomputation Inference Verification, Amodo Design (2026). https://amododesign.com/notes/2026-09-02-scaling-recomputation-inference-verification/
4. AI 2040 Plan A — Verification SITREP, Amodo Design (2026). https://amododesign.com/ai-verification/plan-a-sitrep/
5. Get Involved in Verification, AI Futures Project (2026). https://ai-2040.com/supplements/verification-plan/get-involved
6. Proof-of-Learning is Currently More Broken Than You Think, C. Fang et al. (2023). https://arxiv.org/abs/2208.03567
7. A System Overview for Near-Term, Low-Trust AI Compute Verification, N. Cankaya (2026). https://intelligence.org/wp-content/uploads/2026/06/A-system-overview-for-near-term-low-trust-AI-compute-verification.pdf
8. Timing and Memory Telemetry on GPUs for AI Governance, S. K. Monfared et al. (2026). https://arxiv.org/abs/2602.09369
9. SAGE: Software-based Attestation for GPU Execution, A. Ivanov et al. (2023). https://www.usenix.org/conference/atc23/presentation/ivanov
10. SWATT: SoftWare-based ATTestation for Embedded Devices, A. Seshadri et al. (2004). https://netsec.ethz.ch/publications/papers/swatt.pdf
11. Proofs of Space, S. Dziembowski et al. (2015). https://eprint.iacr.org/2013/796
12. Secure Code Update for Embedded Devices via Proofs of Secure Erasure, D. Perito & G. Tsudik (2010). https://link.springer.com/chapter/10.1007/978-3-642-15497-3_39
13. Software-Based Memory Erasure with Relaxed Isolation Requirements, S. Bursuc et al. (2024). https://ieeexplore.ieee.org/document/10664348/
14. On the Difficulty of Software-Based Attestation of Embedded Devices, C. Castelluccia et al. (2009). https://s3.eurecom.fr/docs/ccs09_Castelluccia.pdf
15. Refutation of "On the Difficulty of Software-Based Attestation of Embedded Devices", A. Perrig & L. van Doorn (2010). https://netsec.ethz.ch/publications/papers/perrig-ccs-refutation.pdf
16. Pacing AI Requires Proof, Attestable (2026). https://attestable.com/blog/pacing-ai-requires-proof
17. Mechanisms to Verify International Agreements About AI Development, A. Scher & L. Thiergart (2025). https://arxiv.org/abs/2506.15867
18. Proofs of Useful Work from Arbitrary Matrix Multiplication, I. Komargodski & O. Weinstein (2025). https://arxiv.org/abs/2504.09971
19. Pearl Floating Point Scheme Specification, Pearl Research Team (2026). https://pearlresearch.ai/Pearl_Whitepaper.pdf
20. pearl: Monorepo for the Pearl network, Pearl Research Labs (2026). https://github.com/pearl-research-labs/pearl