# 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-0014&hide=io,training

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.

- **Keep hidden from the verifier: inputs and outputs, training data.** Removes mechanisms that show the asset to the verifier. Conditional or unspecified exposure stays with a note and needs checking against the privacy requirement. Model weights: the checked model's parameters. Inputs and outputs: the requests a deployed model serves and its responses. Training data: what a model was trained on. Each mechanism's exposure is the editors' reading of its record: shown, depends on the design (kept, with a note), hidden, not involved, or unspecified for a selected implementation. Code and configuration are not covered yet.

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 |
| Bandwidth limits and compartmentalization | Research demonstration | Published security analysis | Adversarial | Analysis | Retrofit device | 0 / 2 / 0 | not involved | not involved | 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.
- Filter note: May show inputs and outputs, depending on the design. 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.
- Filter note: May show training data, depending on the design. 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.

### Bandwidth limits and compartmentalization

Capping or removing network links between groups of AI chips, so each group can serve models but large training runs across groups become far slower. ([Bandwidth limits and compartmentalization](https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/))

- Assessment: mechanism family.
- Development: Research demonstration (legacy code R2), assessed for monitoring inter-node traffic with operator-run software on four GPUs.
- 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: required. Attack testing: analysis. Category: Isolation & system architectures.
- What the verifier sees: model weights not involved; inputs and outputs not involved; training data not involved. Caps traffic between groups of chips; it does not read the traffic's content.


## Properties

**Built for an adversarial prover**

- Whole-workload recomputation (reproducible packets)
- Bandwidth limits and compartmentalization


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

- Bandwidth limits and compartmentalization: Analysis


## Limits

**Open significant failures**

- Operator control of pod routing collapses the bound (known failure, theoretical argument, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/evidence/flaws/2/) [7]. Lucid's analysis finds that if the operator can freely assign pods to routers, it could dedicate a whole cell of 100 or more pods to one pipeline stage. The bound then falls to about 90–220x uncompressed and as low as about 25x with compression. The proposed mitigation, auditor-controlled random assignment that is periodically re-randomized, has not been implemented.
- Parallel scale-up switches are hard enforcement points (known failure, theoretical argument, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/evidence/flaws/5/) [10]. In GB200 topologies, GPUs reach GPUs in other nodes through NVSwitches without a NIC on the path. Amodo notes that limits are hard to enforce there because many switches work in parallel, so compromising one or two would bypass the limit.

**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, not in the proposal). Proposed as one input to accounting for spare capacity on declared hardware.
- Undeclared local storage raises per-pod capacity (scope limitation, theoretical argument, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/evidence/flaws/3/) [7]. More memory or storage per pod helps an adversary. Lucid requires per-pod storage to be declared, capped and physically inspected.
- Training within one pod is not covered (scope limitation, open question, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/evidence/flaws/4/) [7]. Lucid's bounds concern pre-training models larger than the pods are sized for. Training models that fit in one pod, fine-tuning and reinforcement-learning post-training within one pod are outside the modelled threat.

**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.
- Low-communication training reduces the bandwidth training needs (open question, theoretical argument, in Bandwidth limits and compartmentalization; https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/evidence/flaws/1/) [7][11][12]. DiLoCo matched fully synchronous training on 8 workers while communicating 500 times less. Rahman writes that this family of methods theoretically allows large-scale training with less than 100 Mbps. Lucid includes these methods in its bounds, but notes that extreme activation compression, architectures with unusually small inter-layer widths, or modular paradigms could erode the margin.

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


## 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.
- **Tamper evidence for verifier devices** (Research demonstration (legacy code R2), assessed for detecting probing of proposed verifier hardware, using server and electronics prototypes as evidence)
  - Bandwidth limits and compartmentalization waits on it: Shaping devices and routing assignments must be trusted by both parties; Amodo has not yet fully analysed resilience to a compromised DPU.
- **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.
  - Bandwidth limits and compartmentalization waits on it: The verifier must know that all traffic leaving a pod crosses the capped, monitored links.


## 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)
- Tamper evidence for verifier devices (Research demonstration (legacy code R2), assessed for detecting probing of proposed verifier hardware, using server and electronics prototypes as evidence), needed by Bandwidth limits and compartmentalization

**Shared foundations**

- Network taps and certifiers, relied on by Whole-workload recomputation (reproducible packets) and Bandwidth limits and compartmentalization

**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]
- Bandwidth limits and compartmentalization: No cap that a verifier can check has been implemented or red-teamed. (adversarial validation) [7]
- Bandwidth limits and compartmentalization: The verifier must know that all traffic leaving a pod crosses the capped, monitored links. (coverage & hidden compute; waits on Network taps and certifiers) [8]
- Bandwidth limits and compartmentalization: Shaping devices and routing assignments must be trusted by both parties; Amodo has not yet fully analysed resilience to a compromised DPU. (hardware trust; waits on Tamper evidence for verifier devices) [7][10]
- Bandwidth limits and compartmentalization: Advances in low-communication training could shrink the margin that the cap enforces. (capacity bounds) [7][11][12]


## What the verifier sees

- Model weights: shown by none; depends on the design for Whole-workload recomputation (reproducible packets); hidden by none; not involved in Bandwidth limits and compartmentalization; unspecified for none.
- Inputs and outputs: shown by none; depends on the design for Whole-workload recomputation (reproducible packets); hidden by none; not involved in Bandwidth limits and compartmentalization; unspecified for none.
- Training data: shown by none; depends on the design for Whole-workload recomputation (reproducible packets); hidden by none; not involved in Bandwidth limits and compartmentalization; 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)
- Bandwidth limits and compartmentalization: [AI 2040 inference-only verification stack](https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/) (R1, proposed architecture); [RAND secure inference data center (SIDC) design](https://trustbutveri.fyi/implementations/rand-secure-inference-data-centers/) (R1, proposed architecture)

## 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. Traffic Shaping for Workload Classification, Lucid Computing (2026). https://lucidcomputing.substack.com/p/traffic-shaping-for-workload-classification
8. 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
9. De-risking Interconnect Limits for AI Verification, A. Scher et al. (2026). https://techgov.intelligence.org/blog/de-risking-interconnect-limits-for-ai-verification
10. The Tray as a Bandwidth Boundary, Amodo Design (2026). https://amododesign.com/notes/2026-03-16-dpu-bandwidth-limiter/
11. DiLoCo: Distributed Low-Communication Training of Language Models, A. Douillard et al. (2024). https://arxiv.org/abs/2311.08105
12. Does Distributed Training Undermine Compute Governance?, R. Rahman (2026). https://arxiv.org/abs/2605.29359