# AI Verification Landscape

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

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 or data have not left the facility](https://trustbutveri.fyi/claims/weights-have-not-left/) (C-0009): No copy of specified model weights or sensitive data 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 R1): Capping or removing the network links between groups of accelerators, so that serving models still works but large training runs become impractically slow.
- [Bounding unexplained information in outputs](https://trustbutveri.fyi/mechanisms/bounding-unexplained-information/) (M-0024, readiness R2): 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): 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): 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): 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 R2): 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): 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): 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): Overwriting all of a device's memory in a way a verifier can check, so that nothing from earlier, undeclared work survives the wipe.
- [Model identity attestation](https://trustbutveri.fyi/mechanisms/model-identity-attestation/) (M-0012, readiness R2): 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): 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): Uses timing, memory-residency and performance-counter signals measured on AI accelerators as evidence about which workloads they are running.
- [Proof-of-learning and training-transcript verification](https://trustbutveri.fyi/mechanisms/proof-of-learning/) (M-0006, readiness R2): A trainer logs checkpoints, data order and settings, so a verifier can re-run sampled training segments and check that the claimed training happened.
- [Proofs of useful work and resource exhaustion](https://trustbutveri.fyi/mechanisms/proofs-of-useful-work/) (M-0007, readiness R1): Cryptographic evidence that hardware performed a given amount of agreed computation, proposed as a way to show no spare capacity remained for other work.
- [Remote detection of data centres](https://trustbutveri.fyi/mechanisms/remote-detection-of-data-centres/) (M-0020, readiness R1): 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.
- [Reproducible computation packets](https://trustbutveri.fyi/mechanisms/reproducible-computation-packets/) (M-0003, readiness R1): Organizing all AI workloads in a facility into discrete, reproducible units, so that a verifier can recompute a random sample and check each one.
- [Safeguard attestation](https://trustbutveri.fyi/mechanisms/safeguard-attestation/) (M-0023, readiness R2): 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 R2): 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): Shielding, filtering, jamming and inspecting an AI facility so that no hidden physical channel can bypass the checks placed on its official links.
- [Tamper evidence for verifier devices](https://trustbutveri.fyi/mechanisms/tamper-evidence-for-verifier-devices/) (M-0017, readiness R2): 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 R2): 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 R1): A verifier sends unpredictable questions that a device can answer in time only if it holds specified data, or dedicates specified resources, locally.
- [Workload classification from telemetry and side channels](https://trustbutveri.fyi/mechanisms/workload-classification-from-telemetry/) (M-0021, readiness R2): 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): 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): 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): 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.
- [Attestable Audits](https://trustbutveri.fyi/implementations/attestable-audits/) (I-0007, readiness R2): 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): Attestable's zero-knowledge prover, which the company reports proves large language model outputs came from committed weights at tens of tokens per second.
- [DiFR (Divergence From Reference)](https://trustbutveri.fyi/implementations/difr/) (I-0002, readiness R2): 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.
- [Low-trust AI compute verification system overview](https://trustbutveri.fyi/implementations/low-trust-compute-verification-system-overview/) (I-0012, readiness R1): 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): 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 R2): A blockchain whose mining is designed to be a by-product of GPU matrix multiplications in AI workloads, with public node and miner code.
- [RAND secure inference data center (SIDC) design](https://trustbutveri.fyi/implementations/rand-secure-inference-data-centers/) (I-0010, readiness R1): 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): 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 R2): 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 R2): 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.
- [zkLLM](https://trustbutveri.fyi/implementations/zkllm/) (I-0003, readiness R2): 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 isolated groups with restricted communication between them, so that no group can join a larger prohibited workload.
- [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 runs fixed weights to produce outputs, and 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 also solves 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.

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