# AI Verification Tech Map

> A neutral, source-grounded reference to technical means of verifying claims about AI software and hardware. Readiness levels and flaws are editorial assessments under a published rubric; every factual statement cites a public source.

A project of the Strategic Stability Alliance (https://strategicstability.com/).

Why verification matters (motivation, nuclear precedents, further reading): https://trustbutveri.fyi/why/

Machine-readable data: https://trustbutveri.fyi/api/v1/bundle.json (all records), https://trustbutveri.fyi/api/v1/index.json (index), https://trustbutveri.fyi/api/v1/schema.json (schemas). Full text: https://trustbutveri.fyi/llms-full.txt.

## Claims
- [Compute stock is at most a declared amount](https://trustbutveri.fyi/claims/compute-stock-is-bounded/) (C-0001): A party holds no more AI-relevant compute, counted in chips or equivalent capacity, than the total it has declared.
- [Chips are where they are declared to be](https://trustbutveri.fyi/claims/chips-are-where-declared/) (C-0002): Specific AI chips are physically located at the sites a party has declared, throughout the declared period.
- [Declared hardware is idle or shut down](https://trustbutveri.fyi/claims/declared-hardware-is-idle/) (C-0003): Specified AI chips or facilities are not performing computation, or are powered off, throughout a declared period.
- [This compute runs inference, not training](https://trustbutveri.fyi/claims/inference-not-training/) (C-0004): A declared cluster is used only to run existing models to produce outputs, and not to train new or more capable models.
- [The declared model is the one being served](https://trustbutveri.fyi/claims/declared-model-is-served/) (C-0005): Outputs delivered to users or auditors come from the specific model, weights and configuration the provider declared, not from a substitute.
- [Declared safeguards were applied during inference](https://trustbutveri.fyi/claims/safeguards-were-applied/) (C-0006): Specified safety measures, such as input filters, output checks or monitoring, actually ran on the requests a deployed model served.
- [A training run stayed within declared limits](https://trustbutveri.fyi/claims/training-within-declared-limits/) (C-0007): A declared training run used no more compute than permitted and had its declared properties, such as data, hyperparameters and resulting weights.
- [Communication between compute groups is bounded](https://trustbutveri.fyi/claims/bandwidth-is-bounded/) (C-0008): Data flowing between specified groups of chips, or out of a facility, stays below a declared rate, so the groups cannot jointly run large workloads.
- [Model weights have not left the facility](https://trustbutveri.fyi/claims/weights-have-not-left/) (C-0009): No copy of specified model weights has left a designated facility through networks, physical media or other channels.
- [There is no undeclared relevant compute](https://trustbutveri.fyi/claims/no-undeclared-compute/) (C-0010): A party controls no AI-relevant computing hardware or facilities, above an agreed threshold, beyond those it has declared.

## Mechanisms
- [Bandwidth limits and compartmentalization](https://trustbutveri.fyi/mechanisms/bandwidth-limits-and-compartmentalization/) (M-0014, readiness R2; assessed use: detecting traffic above a limit between accelerator groups, not enforcing a cap): Capping or removing network links between groups of accelerators, so that serving within each group still works but large training across groups becomes far slower.
- [Bounding unexplained information in outputs](https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/) (M-0024, readiness R2; assessed use: bounding how much hidden information can leave in checked inference outputs): Limits the hidden information a facility's outputs can carry by measuring how much of those outputs the declared computation fails to predict.
- [Chip location verification](https://trustbutveri.fyi/mechanisms/chip-location-verification/) (M-0018, readiness R1; assessed use: bounding how far a chip is from trusted landmark servers when checked): Timing a chip's signed replies to trusted servers at known places, so that the speed of light bounds how far away the chip can be.
- [Chip registries and manufacturing records](https://trustbutveri.fyi/mechanisms/chip-registries-and-manufacturing-records/) (M-0019, readiness R1; assessed use: a checkable record of which chips were made and who declared owning them): Recording each AI chip's identity and owner from the fab onwards, and cryptographically fixing manufacturing records, so that chips can be accounted for later.
- [Confidential multi-party verification](https://trustbutveri.fyi/mechanisms/confidential-multi-party-verification/) (M-0025, readiness R2; assessed use: audits or evaluations of a private model that reveal neither party's inputs): Lets mutually distrusting parties run an agreed check over private models or records inside attested enclaves or zero-knowledge proofs, revealing only the result.
- [Deterministic and bit-exact inference](https://trustbutveri.fyi/mechanisms/deterministic-inference/) (M-0002, readiness R3; assessed use: exact-replay checks that the declared model and setup produced the outputs): Making model inference reproducible bit for bit, so that a verifier's re-run must match the provider's output exactly rather than approximately.
- [Hardware performance throttling and licensing](https://trustbutveri.fyi/mechanisms/hardware-performance-throttling/) (M-0011, readiness R1; assessed use: performance limits a verifier can rely on, against an operator trying to bypass them): On-chip mechanisms that cut an AI accelerator's performance when a license expires or a trusted trigger fires, bounding what the hardware can do.
- [Hardware-enabled guarantees (flexHEG) and guarantee processors](https://trustbutveri.fyi/mechanisms/flexheg-guarantee-processors/) (M-0009, readiness R1; assessed use: checking and enforcing training-compute limits on chips, against adversaries up to states): Proposed chip add-ons, a guarantee processor inside a tamper-protected enclosure, that would check and enforce agreed rules on how AI accelerators are used.
- [Memory wiping and proofs of secure erasure](https://trustbutveri.fyi/mechanisms/memory-wiping-and-secure-erasure/) (M-0015, readiness R1; assessed use: showing that no data from earlier work persists in memory the wipe reaches): Overwriting a device's memory in a way a verifier can check, so that data from earlier, undeclared work cannot persist in memory the wipe reaches.
- [Model identity attestation](https://trustbutveri.fyi/mechanisms/model-identity-attestation/) (M-0012, readiness R3; assessed use: showing users that a service runs the declared model weights): Establishes that responses come from a specific, committed set of model weights, using enclave measurements or recomputation of sampled outputs.
- [Network taps and certifiers](https://trustbutveri.fyi/mechanisms/network-taps-and-certifiers/) (M-0013, readiness R1; assessed use: committing a complete record of cluster traffic, so declared inference can be checked): Devices on a cluster's network links that copy and hash all traffic, so a verifier can later check sampled records against declared work.
- [On-chip telemetry from timing, memory and performance counters](https://trustbutveri.fyi/mechanisms/on-chip-telemetry/) (M-0010, readiness R2; assessed use: a verifier reading workload evidence from GPUs that a hostile operator controls): Uses timing, memory-residency and performance-counter signals measured on AI accelerators as evidence about which workloads they are running.
- [Proofs of useful work for capacity accounting](https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/) (M-0007, readiness R1; assessed use: bounding the spare capacity of declared hardware that could run training): Cryptographic evidence that a given amount of matrix-multiplication work was completed, proposed as one input to accounting for spare capacity on declared hardware.
- [Remote detection of data centres](https://trustbutveri.fyi/mechanisms/remote-detection-of-data-centres/) (M-0020, readiness R1; assessed use: finding undeclared data centres (capacity estimates for known sites would meet at least R2)): Remote detection locates large data centres and estimates their power capacity without site access, using satellite imagery, heat signatures and public records such as permits.
- [Safeguard attestation](https://trustbutveri.fyi/mechanisms/safeguard-attestation/) (M-0023, readiness R2; assessed use: attesting that a declared safeguard mediated a service's responses): Hardware-signed evidence that an AI service ran its declared safeguards, such as a guardrail classifier or monitor, when producing a given response.
- [Sampled inference recomputation](https://trustbutveri.fyi/mechanisms/sampled-inference-recomputation/) (M-0001, readiness R3; assessed use: checking that recorded outputs came from the declared model and settings): A verifier re-runs a random sample of an AI provider's logged queries on a trusted copy of the declared model and checks the outputs match.
- [Side-channel suppression for isolated facilities](https://trustbutveri.fyi/mechanisms/side-channel-suppression/) (M-0022, readiness R1; assessed use: bounding physical covert channels out of a verified enclosure): Shielding, filtering, jamming and inspecting an AI facility to limit hidden physical communication around monitored network links.
- [Tamper evidence for verifier devices](https://trustbutveri.fyi/mechanisms/tamper-evidence-for-verifier-devices/) (M-0017, readiness R2; assessed use: detecting tampering with verifier devices inside facilities the checked party controls): Enclosures, seals and sensors that make physical interference with verification hardware either visible or self-defeating.
- [TEE remote attestation for AI workloads](https://trustbutveri.fyi/mechanisms/tee-remote-attestation/) (M-0008, readiness R3; assessed use: showing which software ran to a party that distrusts the operator holding the hardware): Trusted execution environments (TEEs) in CPUs and GPUs sign reports of loaded software, so a remote party can check which code ran an AI workload.
- [Timed challenge-response and memory-occupation challenges](https://trustbutveri.fyi/mechanisms/timed-challenge-response/) (M-0016, readiness R2; assessed use: detecting whether a GPU is doing other work): A verifier sends unpredictable questions that a device can answer in time only if it holds specified data, or dedicates specified resources, locally.
- [Training-transcript verification (proof-of-learning)](https://trustbutveri.fyi/mechanisms/proof-of-learning/) (M-0006, readiness R2; assessed use: checking from its transcript that a training run followed declared rules): A trainer logs checkpoints, data order and settings, so a verifier can re-run sampled training segments and check that the claimed training happened.
- [Whole-workload recomputation (reproducible packets)](https://trustbutveri.fyi/mechanisms/reproducible-computation-packets/) (M-0003, readiness R1; assessed use: recomputing whole workloads to show a cluster runs only declared inference): Organizing all AI workloads in a facility into discrete, reproducible units, so that a verifier can recompute a random sample and check each one.
- [Workload classification from telemetry and side channels](https://trustbutveri.fyi/mechanisms/workload-classification-from-telemetry/) (M-0021, readiness R2; assessed use: telling training from inference and other work, against an operator disguising workloads): Telling whether chips are training, serving or doing non-AI work from GPU counters or power draw, signals that do not read weights or data.
- [Zero-knowledge proofs of inference](https://trustbutveri.fyi/mechanisms/zk-proofs-of-inference/) (M-0004, readiness R2; assessed use: proving each output came from committed weights, against a prover who cheats): A prover produces a cryptographic proof that an output came from running a committed model on a given input, without revealing the weights.
- [Zero-knowledge proofs of training constraints](https://trustbutveri.fyi/mechanisms/zk-proofs-of-training-constraints/) (M-0005, readiness R2; assessed use: proving a training run followed a committed specification and data): Cryptographic proofs that a training run followed a committed dataset, procedure and rules, checkable without revealing the model or the data.

## Implementations
- [AI 2040 inference-only verification stack](https://trustbutveri.fyi/implementations/ai-2040-inference-only-verification-plan/) (I-0011, readiness R1; assessed use: showing that retrofitted data centres run only inference): A proposed retrofit that isolates data-centre inference units, taps their front-end traffic and recomputes random samples to check that only declared inference runs.
- [Apple Private Cloud Compute](https://trustbutveri.fyi/implementations/apple-private-cloud-compute/) (I-0013, readiness R3; assessed use: showing users which software serves their AI requests, not which model): Apple's cloud AI inference service, in which user devices send requests only to servers that attest to running software published in a public transparency log.
- [Attestable Audits](https://trustbutveri.fyi/implementations/attestable-audits/) (I-0007, readiness R2; assessed use: showing users that the model answering them is the audited one): A research prototype that runs AI safety benchmarks inside a trusted execution environment and publishes attestations binding the model, the audit and the results.
- [Attestable zero-knowledge inference prover](https://trustbutveri.fyi/implementations/attestable-zk-inference/) (I-0005, readiness R1; assessed use: proving an output came from committed weights): Attestable's zero-knowledge prover, which the company reports proves large language model outputs came from committed weights at tens of tokens per second.
- [Batch-invariant inference kernels (Thinking Machines)](https://trustbutveri.fyi/implementations/batch-invariant-inference-kernels/) (I-0016, readiness R2; assessed use: exact recomputation of served outputs by a verifier, with a cooperating provider): Open-source kernels from Thinking Machines Lab that make LLM outputs independent of batch size, adopted in vLLM and SGLang to give reproducible inference.
- [DiFR (Divergence From Reference)](https://trustbutveri.fyi/implementations/difr/) (I-0002, readiness R2; assessed use: checking that outputs match the declared model, precision and sampling settings): DiFR checks that an inference provider ran its declared model by comparing output tokens or activations with a trusted re-run using the same random seed.
- [EZKL](https://trustbutveri.fyi/implementations/ezkl/) (I-0014, readiness R2; assessed use: proving an output came from a committed model, against a prover who cheats): EZKL is a library from Zkonduit that turns neural networks into zero-knowledge circuits, so a prover can show an output came from a committed model.
- [Low-trust AI compute verification system overview](https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/) (I-0012, readiness R1; assessed use: screening challenged records to show declared inference compute is not training): A retrofittable reference design in which network taps commit to all facility traffic, and air-gapped, independently sourced checkers later re-run randomly challenged records.
- [Lucid sovereignty (location) certificates](https://trustbutveri.fyi/implementations/lucid-location-certificates/) (I-0009, readiness R1; assessed use: certifying the region where an attested workload ran at a given time): A draft specification, hosted by Lucid Computing, for short-lived certificates that bound where a workload runs by timing signed exchanges with fixed anchors.
- [Pearl proof-of-useful-work blockchain](https://trustbutveri.fyi/implementations/pearl-proof-of-useful-work/) (I-0004, readiness R3; assessed use: proving GPUs did matrix-multiplication work in blockchain mining, not bounding spare capacity): A blockchain whose mining is designed to be a by-product of GPU matrix multiplications in AI workloads, with public node and miner code.
- [PySyft double-blind evaluations](https://trustbutveri.fyi/implementations/pysyft-double-blind-evaluations/) (I-0017, readiness R2; assessed use: evaluating a private model on private prompts, neither party seeing the other's inputs): PySyft coordinates an attested enclave where a model owner and evaluator run tests without sharing weights or private prompts.
- [RAND secure inference data center (SIDC) design](https://trustbutveri.fyi/implementations/rand-secure-inference-data-centers/) (I-0010, readiness R1; assessed use: the operator's own weight security, with no outside verification described): A RAND design for a purpose-built facility that serves already-trained AI models while protecting weights and inference data against state-level attackers.
- [SASH confidential network logger](https://trustbutveri.fyi/implementations/sash-confidential-network-logger/) (I-0008, readiness R1; assessed use: telling inference from training on a mutually inspected cluster): An open-source prototype that routes a facility's inference traffic through a logger and re-runs requests on a separate cluster to check it serves inference.
- [Tinfoil model identity (Modelwrap)](https://trustbutveri.fyi/implementations/tinfoil-model-identity/) (I-0006, readiness R3; assessed use: showing clients that the served weights match a committed hash): Tinfoil's method for proving which model weights its enclave-hosted inference service runs, by binding a dm-verity hash of the weights into remote attestation.
- [TOPLOC](https://trustbutveri.fyi/implementations/toploc/) (I-0001, readiness R3; assessed use: checking that untrusted providers used the claimed model, prompt and precision): TOPLOC is a hashing scheme from Prime Intellect that lets a verifier check whether an inference provider ran the model, prompt and precision it claims.
- [Verde and RepOps (Gensyn)](https://trustbutveri.fyi/implementations/gensyn-verde-repops/) (I-0015, readiness R3; assessed use: showing a delegated output came from the declared model, if one provider is honest): Gensyn's system for checking delegated machine-learning jobs, which settles disagreements between providers by re-running a single operation with bitwise-reproducible operators.
- [zkLLM](https://trustbutveri.fyi/implementations/zkllm/) (I-0003, readiness R2; assessed use: proving an output came from committed weights, against a prover who cheats): zkLLM is a GPU-accelerated zero-knowledge proof system that proves a large language model's output came from committed weights without revealing those weights.

## Concepts
- [Compartmentalization](https://trustbutveri.fyi/concepts/compartmentalization/) (K-0017): Dividing a facility's accelerators into groups with restricted communication between them, so that combining groups for large training runs becomes slow or impractical.
- [Cryptographic commitment](https://trustbutveri.fyi/concepts/cryptographic-commitment/) (K-0024): A way to fix a value now without revealing it, so that it can later be opened and shown not to have changed.
- [Evidence binding](https://trustbutveri.fyi/concepts/evidence-binding/) (K-0019): Tying verification evidence to the specific device, workload, data and time it describes, so it cannot be substituted, replayed or misattributed.
- [FLOP accounting](https://trustbutveri.fyi/concepts/flop-accounting/) (K-0023): Estimating or verifying how many floating-point operations a training run or other workload used, often to compare against a threshold in a rule.
- [Hardware-enabled mechanism (HEM)](https://trustbutveri.fyi/concepts/hardware-enabled-mechanism/) (K-0007): A governance or verification function built into AI chips or closely attached hardware, such as usage reporting, location attestation or enforced limits.
- [Inference and training workloads](https://trustbutveri.fyi/concepts/inference-and-training-workloads/) (K-0025): Training updates a model's weights from data. Inference uses fixed weights to produce outputs. Their different resource use underpins several verification methods.
- [Interconnect bandwidth](https://trustbutveri.fyi/concepts/interconnect-bandwidth/) (K-0021): The data rate of links between accelerators or groups of them; large-scale training needs far more of it than inference, so limiting it constrains workloads.
- [Network tap](https://trustbutveri.fyi/concepts/network-tap/) (K-0014): A device that copies the traffic on a network link for inspection without disrupting it; proposed for checking what AI data centres compute.
- [Numerical nondeterminism](https://trustbutveri.fyi/concepts/numerical-nondeterminism/) (K-0008): Differences between runs, or between machines, in the results of the same AI computation, because floating-point rounding depends on the order of operations.
- [Positive and negative claims](https://trustbutveri.fyi/concepts/positive-and-negative-claims/) (K-0003): A positive claim asserts that something is present or happened; a negative claim, that an activity or resource is absent; a mixed claim, both.
- [Proof of (useful) work](https://trustbutveri.fyi/concepts/proof-of-useful-work/) (K-0011): Evidence that a party spent a given amount of computation; in useful variants, the same work can also solve a problem someone wants solved.
- [Proof of space](https://trustbutveri.fyi/concepts/proof-of-space/) (K-0012): A protocol in which a prover shows that it is dedicating a given amount of storage or memory, rather than computation, to a task.
- [Prover](https://trustbutveri.fyi/concepts/prover/) (K-0001): The party that makes a claim about its own AI hardware, models or workloads and supplies the evidence a verifier checks.
- [Recomputation](https://trustbutveri.fyi/concepts/recomputation/) (K-0009): Checking a claimed computation by re-running all of it, or a random sample, on hardware the verifier trusts and comparing the results.
- [Remote attestation](https://trustbutveri.fyi/concepts/remote-attestation/) (K-0004): A process in which a device sends signed evidence about its state, such as software measurements, so a remote party can judge its trustworthiness.
- [Root of trust](https://trustbutveri.fyi/concepts/root-of-trust/) (K-0005): A component that anchors security functions such as measurement, storage and reporting, and must be trusted because its misbehaviour cannot be detected.
- [Sampling and assurance](https://trustbutveri.fyi/concepts/sampling-and-assurance/) (K-0020): Checking a random sample of accelerators, workload segments or outputs rather than all of them, so that violations are caught with a calculable probability.
- [Side channel](https://trustbutveri.fyi/concepts/side-channel/) (K-0013): An unintended path by which information leaks from a system through effects of its operation, such as timing, power draw or electromagnetic emissions.
- [Tamper evidence and tamper resistance](https://trustbutveri.fyi/concepts/tamper-evidence/) (K-0015): Tamper evidence makes interference detectable; tamper resistance makes it difficult or costly; tamper response reacts to it, often by erasing secrets.
- [Threat model](https://trustbutveri.fyi/concepts/threat-model/) (K-0018): An explicit statement of who might attack a system, what they can do, and which threats the design covers or leaves out of scope.
- [Trusted execution environment (TEE)](https://trustbutveri.fyi/concepts/trusted-execution-environment/) (K-0006): An execution area protected by the processor that keeps the data inside confidential and unaltered, and the code unaltered, even from the host's own software.
- [Undeclared compute](https://trustbutveri.fyi/concepts/undeclared-compute/) (K-0016): AI-relevant hardware, or uses of declared hardware, that a prover has not reported, and that verification must therefore detect or rule out.
- [Verifier](https://trustbutveri.fyi/concepts/verifier/) (K-0002): The party that examines evidence supplied by, or collected about, a prover and decides whether the prover's claim holds.
- [Weight exfiltration](https://trustbutveri.fyi/concepts/weight-exfiltration/) (K-0022): Unauthorized copying of a model's trained parameters out of the environment meant to contain them, by theft or through covert channels.
- [Zero-knowledge proof](https://trustbutveri.fyi/concepts/zero-knowledge-proof/) (K-0010): A cryptographic protocol by which a prover convinces a verifier that a statement is true while revealing nothing beyond the fact that it is true.

## Methodology
- [Methodology](https://trustbutveri.fyi/methodology/): readiness rubric, citation tiers, neutrality, governance