Idea
A sketch without a sufficiently specified public design and assumptions.
Research atlas / Reader’s guide
Know what the evidence buys you.
A signature, a reproducible output, and a monitored network link establish different properties. Follow each observation back to the claim you care about.
Start with the claim. Follow the dependencies.
- Specify the question
Start with a verification claim. Identify the hardware, workload, time period, and actor it concerns.
- Read the scope
Check the exact use attached to a readiness level. A demonstration on one workload may say little about all activity in a facility.
- Inspect the adversary
Check the prover’s capabilities and hardware assumptions. Distinguish practical attacks from analysis.
- Follow the evidence
Read the original source locators, limitations, and version notes before comparing results.
- Trace the institutions
The Consortium case files examine who controls the keys, verifier, update process, and compliance decision.
A stage of development, with a stated scope.
The atlas preserves the Tech Map’s rubric 1.1. These imported editorial judgments are distinct from the Consortium’s three descriptive scores.
0 records
Proposed
A public design describes its intended verification claim and assumptions.
Demonstrated
A working implementation or reproducible result represents the verification setting in at least one relevant respect.
In production
The use is production-grade and available, or a separate party relies on it for a verification decision. Critical flaws may remain.
Deployment-ready
Production use plus independent public evaluation that leaves no critical flaw open, under the stated scope.
Confidence describes certainty in the assessment. It is not a probability of security. Read the source rubric ↗
Five distinctions worth keeping visible.
Direct mechanisms and supporting evidence
A direct mechanism is aimed at a claim; a supporting mechanism contributes evidence or a necessary component. Counts measure catalogue coverage, not the strength of a combined guarantee.
Readiness and resistance to attack
A system can be used in production and still have open critical flaws. Readiness and adversarial evaluation are shown separately for that reason.
Attestation and compliance
An attestation reports measured state under a trust model. The adequacy of the software, completeness of observation, and legitimacy of the policy remain separate questions.
Evidence of absence and absence of evidence
Checking a declared device does not establish that no undeclared device exists. An empty catalogue entry, unreported attack, or missing demonstration should remain an explicit uncertainty.
Performance and whole-system cost
Prover latency, verifier latency, proof size, throughput, memory, model size, token count, and quantization describe different costs. Compare results only when their experimental conditions match.
The review queue is part of the map.
13 records have low-confidence readiness assessments; 5 have an open critical-flaw flag in the imported snapshot.
A dated, inspectable snapshot.
This edition contains 42 mechanisms and implementations, 10 claims, 25 glossary entries, 27 organizations, and 290 sources published in the reference map at import. Draft-only upstream records remain external links. Coverage of the field is still incomplete.
The snapshot is not a live feed. Original source-review dates are retained. New publications, patches, and changed deployments can make records stale. The Consortium’s August 2026 case files retain their own review dates and are not automatically re-reviewed by an import.
Download the research atlas JSON or Consortium case-file JSON. The atlas export preserves source links and attributed assessments. The two scoring systems should not be merged.
For a factual correction, include the record ID and public evidence in a nomination, or suggest a correction to the original map. Consortium editorial corrections follow our corrections policy.