Readiness
Readiness levels
Every mechanism and implementation has a readiness level from R0 to R3. The level says how close a technique is to being usable for its verification purpose, not how mature the underlying technology is.
Levels run from R0 to R3. Each lists the records currently at it; ⚠ marks a record with an open critical flaw.
R0Idea
Mentioned or sketched, without a written design, claim and assumptions.
Roughly technology readiness levels —.
No record is at this level.
R1Proposed
A design or theory is publicly described, including the claim it would verify and its assumptions.
Roughly technology readiness levels 1–3.
Mechanisms (12)
- Bandwidth limits and compartmentalization
- Chip location verification
- Chip registries and manufacturing records
- Hardware performance throttling and licensing
- Hardware-enabled guarantees (flexHEG) and guarantee processors
- Memory wiping and proofs of secure erasure
- Network taps and certifiers
- Proofs of useful work and resource exhaustion
- Remote detection of data centres
- Reproducible computation packets
- Side-channel suppression for isolated facilities
- Timed challenge-response and memory-occupation challenges
Implementations (6)
R2Demonstrated
A public working implementation, or reproducible published end-to-end results, obtained under conditions representative of the verification use in at least one key respect: realistic model or cluster scale, realistic hardware, or a stated adversary.
Roughly technology readiness levels 4–6.
Mechanisms (13)
- Bounding unexplained information in outputs
- Confidential multi-party verification
- Deterministic and bit-exact inference
- Model identity attestation⚠
- On-chip telemetry from timing, memory and performance counters⚠
- Proof-of-learning and training-transcript verification⚠
- Safeguard attestation
- Sampled inference recomputation
- Tamper evidence for verifier devices
- TEE remote attestation for AI workloads⚠
- Workload classification from telemetry and side channels
- Zero-knowledge proofs of inference
- Zero-knowledge proofs of training constraints
Implementations (6)
R3Deployment-ready
Both of these hold. (a) A party other than its developer relies on it for a verification decision, or it is production-grade and available. (b) At least one independent public evaluation (an audit, a red-team or a peer-reviewed security analysis) left no critical flaw open.
Roughly technology readiness levels 7–9.
No record is at this level.
How levels are assigned
- A record gets the highest level whose criteria all hold.
- The level is assessed for the stated verification use. Trusted execution environments are sold commercially, but that does not make TEE-based verification between rival states deployment-ready.
- "Reproducible" means the method, setup and parameters are published in enough detail for an independent team to repeat the work. Public code is not required, but its absence is noted.
- An open critical flaw does not by itself lower R1 or R2, which describe development and demonstration. A break that invalidates the evidence a level rests on does lower it.
- A mechanism is at least as ready as its most mature implementation for that use, and its rationale names that implementation.
- Ratings can go down.
- Adversarial evaluation is also judged for the verification use. Attacks on related products in other settings are context, not evidence.
What each rating records
Each rating comes with a rationale that walks through the criteria, the sources it rests on, the gaps to the next level, a confidence, who assessed it and when, and a status (current, under review or disputed). Levels are editorial judgments under rubric v1.0, kept apart from the facts, and open to correction.
Confidence is how sure the editors are of the level: 14 low confidence, 23 medium confidence and 0 high confidence. The Status page lists the low-confidence ratings. The Methodology page covers flaws, citations and neutrality.