# 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-0022,M-0007

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.

None set. Every mechanism on the map was available.

## 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 |
| Side-channel suppression for isolated facilities | Proposed | Published security analysis | Adversarial | Analysis | Retrofit device | 0 / 0 / 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.

### Side-channel suppression for isolated facilities

Shielding, filtering, jamming and inspecting an AI facility to limit hidden physical communication around monitored network links. ([Side-channel suppression for isolated facilities](https://trustbutveri.fyi/mechanisms/side-channel-suppression/))

- Assessment: mechanism family.
- Development: Proposed (legacy code R1), assessed for bounding physical covert channels out of a verified enclosure.
- 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: retrofit device. Prover cooperation: partial. Attack testing: analysis. Category: Off-chip devices & sensors.
- What the verifier sees: model weights not involved; inputs and outputs not involved; training data not involved. Shields and filters a facility; 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)
- Side-channel suppression for isolated facilities
- Proofs of useful work for capacity accounting

**No new hardware needed**

- 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**

- Side-channel suppression for isolated facilities: Analysis
- Proofs of useful work for capacity accounting: Analysis


## Limits

**Open significant failures**

- 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/) [11]. 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.
- Openings for airflow, power and optics weaken shielding (scope limitation, theoretical argument, in Side-channel suppression for isolated facilities; https://trustbutveri.fyi/mechanisms/side-channel-suppression/evidence/flaws/2/) [7]. Cankaya notes that keeping attenuation high while passing high-power airflow, cabling and optical links adds complexity beyond existing shielded-enclosure specifications.
- 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/) [8]. 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.
- Supply-chain implants may evade inspection (open question, theoretical argument, in Side-channel suppression for isolated facilities; https://trustbutveri.fyi/mechanisms/side-channel-suppression/evidence/flaws/1/) [7]. Cankaya identifies malicious hardware embedded deep in purchased components as a residual risk that visual inspection and disassembly may not catch. He notes that radiographic examination under high-security standards could mitigate it.
- Inspection assumptions may not hold (open question, open question, in Side-channel suppression for isolated facilities; https://trustbutveri.fyi/mechanisms/side-channel-suppression/evidence/flaws/3/) [7]. The design's statistical argument assumes that visual or disassembly inspection catches every flaw that is present in a sampled unit. Cankaya is unsure whether destructive teardowns are defence-dominant or offence-dominant.
- 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/) [10][11]. 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
- Side-channel suppression for isolated facilities: Proposed (legacy code R1), assessed for bounding physical covert channels out of a verified enclosure
- 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.

- **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]
- Side-channel suppression for isolated facilities: No prototype or red-team exists; the design is a first-pass viability study. (adversarial validation) [7]
- Side-channel suppression for isolated facilities: Volume costs of TEMPEST-grade power-line filters are uncertain, because existing products are mostly made to order. (performance & compatibility) [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) [8]
- Proofs of useful work for capacity accounting: Proofs of work cannot find facilities that were never declared. (coverage & hidden compute) [8]
- 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 Side-channel suppression for isolated facilities; 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 Side-channel suppression for isolated facilities; unspecified for none.
- Training data: shown by none; depends on the design for Whole-workload recomputation (reproducible packets); hidden by none; not involved in Side-channel suppression for isolated facilities 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)
- Side-channel suppression for isolated facilities: [AI 2040 inference-only verification stack](https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/) (R1, proposed architecture); [Low-trust AI compute verification system overview](https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/) (R1, proposed architecture); [RAND secure inference data center (SIDC) design](https://trustbutveri.fyi/implementations/rand-secure-inference-data-centers/) (R1, proposed architecture)
- 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. Suppressing Side Channels in an Untrusted Data Center via Retrofitted Defenses, N. Cankaya (2026). https://techgov.intelligence.org/blog/suppressing-side-channels-in-an-untrusted-data-center-via-retrofitted-defenses
8. Pacing AI Requires Proof, Attestable (2026). https://attestable.com/blog/pacing-ai-requires-proof
9. Mechanisms to Verify International Agreements About AI Development, A. Scher & L. Thiergart (2025). https://arxiv.org/abs/2506.15867
10. Proofs of Useful Work from Arbitrary Matrix Multiplication, I. Komargodski & O. Weinstein (2025). https://arxiv.org/abs/2504.09971
11. Pearl Floating Point Scheme Specification, Pearl Research Team (2026). https://pearlresearch.ai/Pearl_Whitepaper.pdf
12. pearl: Monorepo for the Pearl network, Pearl Research Labs (2026). https://github.com/pearl-research-labs/pearl