Pattern: Machine-Readable Evidence (OSCAL)

Control evidence emitted in a machine-readable standard format, OSCAL first, so an audit becomes a query and the same records feed assurance.

By Jorge García Aibar
v0.5.0
Updated 2026-09-25
CC BY 4.0

Layer 05 · Assurance & Continuous Compliance In the chapter 05 catalogue

One working control on the engineering side of AI governance.

Summary: Emit control evidence in a machine-readable, standard format so that the audit is a query and the same evidence feeds continuous assurance. OSCAL, extended with properties for AI, is the organising format: frameworks specify what to assure but provide no executable format for how, and this pattern supplies it¹.

In short

Machine-Readable Evidence (OSCAL) is an assurance control that emits control evidence in a machine-readable, standard format, so the audit becomes a query and the same evidence feeds continuous assurance. It solves evidence that a human must format and file by hand, which does not scale, cannot be verified quickly, is out of date the moment it is saved and is collected again for every audit. Use it when the controls of an AI stack already produce structured records and the assurance function must answer auditors repeatedly and at speed. Control results are emitted as OSCAL component-definition and assessment-results artefacts, building on OSCAL’s native control, implementation and assessment layers, which trace each result back to the control it tested. AI-specific property extensions are still forming and are adopted only where they fit. The screenshot stops being an evidence artefact. Its illustrative mappings are EU AI Act Art. 12, 17 and 72, ISO/IEC 42001 and the NIST AI RMF Manage and Govern functions.

Machine-Readable EvidenceControls, assessments and evidence become OSCAL documents that a validator checks and assurance consumers read without anyone re-typing them. Choose the format your assessor can ingest and generate it from data you already hold. Generated from the Body of Knowledge.Open interactive diagram (opens in a new tab)

Objectives

Make evidence queryable, diffable and aggregatable, and eliminate the screenshot as an evidence artefact.

Target users

AI governance engineer, auditor, platform team.

Impacted stakeholders

Auditors, regulators, model owners.

Relevant principles

Instrument the build to produce its own proof; give every control teeth.

Context

A stack whose controls already produce structured records, and an assurance function that must answer auditors repeatedly and at speed.

Problem

Evidence a human must format and file by hand does not scale, cannot be verified quickly, and is out of date the moment it is saved. Every audit re-collects it from scratch.

Solution

Emit control results as OSCAL component-definition and assessment-results artefacts. OSCAL’s native model is the stable substrate: a control layer (catalog, profile), an implementation layer (component-definition, system-security-plan) and an assessment layer (assessment-plan, assessment-results, POA&M), with traceability from a result back to the control it tested². Build on it first. AI-specific extensions are still forming: one proposed approach, a single 2026 preprint, adds sixteen property extensions for lifecycle phase, enforcement semantics and risk traceability in a three-layer policy/evidence/enforcement architecture that generates OSCAL assessment results automatically and validates them against the NIST JSON schema¹. Adopt the extensions if they fit, but the native assessment models carry most of the load today. Store the evidence so an auditor’s question is answered by a query.

Consequences

The audit becomes a query and evidence composes across tools and jurisdictions. The cost is adopting the schema and instrumenting controls to emit it.

Continuous Assurance Telemetry; Framework Crosswalk; Eval Gate in CI; Incident Pipeline.

Maps to: EU AI Act Art. 12, Art. 17, Art. 72 · ISO/IEC 42001 · NIST AI RMF (Manage, Govern) · Layer 05 Assurance & Continuous Compliance.

Function labels follow the NIST AI RMF³. Mappings are illustrative, not a claim of conformity.

Sources

[1] “Making AI Compliance Evidence Machine-Readable” (OSCAL + 16 property extensions; three-layer policy/evidence/enforcement; “specify what to assure but provide no executable format for how”) (arXiv 2604.13767). UC3M. 2026-04-15. https://arxiv.org/abs/2604.13767 (verified: primary)
[2] OSCAL native model (control layer: catalog, profile; implementation: component-definition, system-security-plan; assessment: assessment-plan, assessment-results, POA&M). NIST. 2026. https://pages.nist.gov/OSCAL/learn/concepts/layer/ (verified: primary)
[3] AI Risk Management Framework (AI RMF 1.0; Govern, Map, Measure, Manage). NIST. 2023-01-26. https://www.nist.gov/itl/ai-risk-management-framework (verified: primary)

Edit this page on GitHub

Cite this pattern

García Aibar, J. (2026). Pattern: Machine-Readable Evidence (OSCAL). In AI Governance Engineering: The Thesis & Body of Knowledge (v0.5.0), chapter 05, Patterns. https://doi.org/10.5281/zenodo.22956197. https://aigovernanceengineer.com/patterns/machine-readable-evidence-oscal. CC BY 4.0

BibTeX

@misc{aige2026bok,
  author  = {Jorge García Aibar},
  title   = {{AI Governance Engineering: The Thesis \& Body of Knowledge}},
  chapter = {05. Patterns: Machine-Readable Evidence (OSCAL)},
  year    = {2026},
  version = {0.5.0},
  doi     = {10.5281/zenodo.22956197},
  url     = {https://aigovernanceengineer.com/patterns/machine-readable-evidence-oscal},
  note    = {Version 0.5.0}
}

Obligations this pattern evidences

Cases where it applies

Related controls