Proposal Explorer
Filter mechanisms
Filters apply to mechanisms only. They describe the setting a proposal is for, and all are off by default. A mechanism that a filter rules out is flagged and does not count towards coverage.
All 25 mechanisms match.
Prover
How far can the party being checked be trusted?
The prover is the party being checked. Semi-trusted designs rely on part of its stack: usually the chip vendor's hardware root of trust, its firmware or counters, or its supply-chain records. Adversarial designs aim to hold even if it cheats wherever the checks allow. No mechanism assumes only a cooperative prover, so only Adversarial removes any today.
Keeps mechanisms whose threat model holds against at least this prover. Adversarial is the strongest assumption. Definitions
Verifier devices on site
May the verifier install its own hardware at the prover's sites?
Some mechanisms need a device the verifier owns or trusts at the prover's facility, such as a network tap, a bandwidth limiter or a sealed sensor. Choose Not allowed when the setting rules that out. Inspectors are not covered.
"Not allowed" removes mechanisms that need a retrofit device, such as a network tap or a sealed sensor. Definitions
Prover cooperation
How much must the prover take part?
Required: the prover takes part, for example by logging requests, producing proofs or opening records. Partial: some access, such as installing a device. Not required: works from outside, such as satellite imagery.
"Partial at most" removes mechanisms that need the prover's active participation. "Not required" keeps only those that work without it. Definitions
Chips
May the proposal depend on new 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.
"Existing chips only" removes mechanisms that need changes to future chip designs. Definitions
Minimum readiness
How mature must each mechanism be?
- Any (selected)25 match
- R1 Proposed25 match
- R2 Demonstrated15 match
- R3 In production4 match
- R4 Deployment-ready0 match
A level describes the public evidence for a mechanism's stated use, not its cost or feasibility. R3 can still have open critical flaws. No mechanism is R4 yet.
Keeps mechanisms whose readiness level is at least this one. Definitions
Attack testing
How hard has each mechanism been attacked in public?
The strongest published attempt to break the mechanism for its verification use: a security analysis, red-teaming by its developers or collaborators, or a red team independent of them.
Keeps mechanisms whose strongest published attack testing is at least this. Definitions
Keep hidden from the verifier
What must the verifier never see? Choose any.
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 read from its record: shown, depends on the design (kept, with a note), hidden, or not involved. Code and configuration are not covered yet.
Removes mechanisms that show the asset to the verifier. Mechanisms that may show it, depending on the design, stay with a note.
Claims
A claim is something one party wants to verify about another party's AI hardware or software. Each claim's number shows how the proposal covers it.
- Covered. A mechanism in the proposal is aimed at this claim and passes the filters.
- Partly covered. Only supporting mechanisms, or mechanisms aimed at it that the filters exclude.
- Not covered. No mechanism in the proposal addresses this claim.
Mechanisms
A mechanism is a general technique for verifying claims. Its badge is its readiness level for its stated use. Lines join it to the claims it addresses. Click a line for details.
- Aimed at the claim: verifying it is a direct purpose of the mechanism.
- Supports the claim: helps verify it without being aimed at it.
- Faint: excluded by your filters, so it does not count towards coverage.
Overview
One row per mechanism in the proposal. Every mark is read from the mechanism's record, as listed in the panels below. Nothing is added up across mechanisms.
What the verifier sees
For model weights, inputs and outputs, and training data, read from each mechanism's record. Shown: the verifier sees it. Depends: on the design or variant, or the verifier sees only samples. Hidden: the verifier sees only commitments, hashes, proofs or results. Not involved: the mechanism does not handle it.