AI safety and security controls.
AI ASSURANCE & EVIDENCE INFRASTRUCTURE
From AI governance requirements to evidence of system behavior.
ODA3 Institute is building evidence structures that connect requirements, controls and consequential system claims to traceable records of what AI systems do. Each conclusion must remain within the evidence examined.
Evidence can exist and still not support the claim.
Policies, evaluations, logs and control records may all be present. The consequential question is whether they establish a defensible claim about a defined system, version, environment and period.
ODA3 keeps the source, collection basis and material limits beside a finding, and records missing or conflicting evidence explicitly.
HOW THE MODEL WORKS
One chain from requirement to bounded conclusion.
Seven elements form three working phases. At each transition, the record should state the basis for moving from one element to the next.
- Requirement
The obligation or question to be addressed.
- Control
The operational condition or safeguard expected to meet it.
- Evidence
The records offered for examination.
- Provenance
Origin, context, system state and time of each record.
- Verification
Evidence checked against defined criteria.
- Finding
What the examined record supports, contradicts or leaves unresolved.
- Bounded Assurance
A conclusion confined to the stated scope and limitations.
Requirement and control context
Evidence, provenance and verification
Finding and bounded assurance
FRAMEWORK ARCHITECTURE
Four instruments with distinct jobs.
Taxonomy and schema for AI incidents.
A lifecycle for investigation, response and learning.
Security controls for physical and kinetic effects.
Publication or adoption of a framework does not by itself establish an assurance conclusion.
Explore the frameworks →A PRACTICAL NEXT STEP
One system. One bounded question. One defined evidence base.
The Evidence Readiness Pilot examines whether available records support a specific claim in a defined operating context. Its report identifies the support, gaps and limits. It is not a certification or maturity score.
About the Pilot →PUBLICATIONS
LATEST INSIGHTS
ODA3-2026-10-INS-114
AI Security Requirements, Runtime Controls and Incident Evidence: A Cross-Framework Mapping
A bounded method for connecting AI security requirements to runtime control evidence and incident records—without mistaking mappings for tested effectiveness.
Read publication →ODA3-2026-10-INS-113
Mapped Is Not Tested: What Boards Should Require From AI Security Controls
A standards crosswalk shows what AI controls are mapped—not whether they work. Board-level questions, an agent authorization example, and a bounded evidence record for control effectiveness.
Read publication →ODA3-2026-10-INS-111
Energy AI Testbeds Must Explain What Transfers to Deployment
A DOE energy AI testbed illustrates why evaluation evidence must match deployed tools, permissions and operating conditions before supporting assurance claims.
Read publication →ODA3-2026-10-INS-112
Defence AI Buyers Need Supplier Evidence They Can Examine
UK defence policy retains MOD accountability for AI assurance while suppliers may control key records. Buyers need proportionate, authorised ways to examine claims and record what remains unknown.
Read publication →ODA3-2026-10-INS-110
When a Hospital’s AI Changes Without a Model Update
A synthetic hospital example shows why changes to documentation, laboratory inputs and alert routing may require a fresh AI release decision even when model weights are unchanged.
Read publication →ODA3-2026-10-INS-109
Hospital AI Release Evidence Must Follow the Local Configuration
Hospital AI release evidence must connect the evaluated version to local data, workflows and approval. Includes a clearly labelled synthetic site-release annex.
Read publication →START WITH YOUR DECISION CONTEXT
Find the right starting point.
Decision-makers
Examine the claim, evidence base and limits behind an AI assurance decision.
Explore Assurance →Security and governance teams
Connect requirements and controls to operational records and defined evidence questions.
Explore Frameworks →Researchers and contributors
Review published methods and bring a bounded technical question for examination.
Explore Research →Bring one system and the claim you need to examine.
A short written description of the question, operating context and records available is enough to begin scoping.
Describe your question →





