Assurance and Evidence Control Profile

Scope

AI systems and models from the test plan to the release gate, the evidence records every control emits and how long they are kept, and the model artefacts and AI bill of materials of each build. The environment a model or agent is evaluated in is covered by the evaluation environment profile, and agent-specific runtime controls by the agent runtime profile.

12 controls, AIGE-CTL-ASSURE-001 to AIGE-CTL-ASSURE-012. Each one is anchored to a layer of the five-layer stack and to the patterns that implement it.

How to read a control

Every control has a stable id that never changes and is never reused, and the same record:

• Objective: the outcome the control secures, in one sentence.
• Failure modes: observable events that mean the control failed.
• Scope, enforcement points (on a pull request, at deploy, at runtime or on a schedule) and the failure response (deny, hold for approval or alert).
• Verification: how a third party would check it (inspect, test, observe or attest).
• Evidence: the artefact it leaves and the stack layer that keeps it.
• Mappings: obligations, ISO/IEC 42001 Annex A, the NIST AI RMF, OWASP and other references, each id checked against the site's registers.

Depth says how far a control is written. Specified: a verification procedure, evidence, implementation notes, two example observations and a page of its own. Derived from site material: restates existing site material (an agent control of chapter 23, a pattern, a record schema or a chapter, named on each control) and adds nothing that material does not say. Draft outline: objective, failure modes, scope and open questions only. This profile: 12 derived from site patterns, record schemas and chapters of the Body of Knowledge.

An observation is what a check of a control would emit: the control id, the subject checked, what was expected, what was observed, a status (pass, fail or not_applicable), a timestamp and the evidence behind it.

Mappings

Every control against the obligations, standards and threats it answers. Mappings are illustrative, not a claim of conformity; an empty cell means no mapping has been verified yet. AIUC-1 ids point at the public requirement index of the Artificial Intelligence Underwriting Company, cited here as a reference; this project is not affiliated with AIUC, and each mapping is our own reading of the requirement text. The same mappings, read from the framework side and across every profile, are in the controls crosswalk.

Open questions

The questions this draft leaves open, with the controls that raise each one.

• Verification procedure to be specified: the derivation adds no check its source material does not state; requires technical review. (001, 002, 003, 004, 005, 006, 007, 008, 009, 010, 011, 012)
• Which changes to a frozen plan (a new suite, a larger sample, a stricter threshold) may proceed without a new approval, and which reopen the plan? (001)
• How should the gate treat a suite whose repeated runs straddle the threshold: rerun, enlarge the sample or block, given that the pattern warns against flaky gates? (002)
• When a waiver in the report expires after release, is the release gated again or only the waived suite rerun? (003)
• Which key signs a record that a third-party tool produced and the ingest pipeline normalised: the tool's, the pipeline's or both? (004)
• How long may a control go without emitting a record before its status turns to failing, and should that window differ by control? (005)
• Should an observation an adapter emits and one a reviewer records weigh the same when the status of a control is computed from them? (006)
• Which OSCAL model should carry the result of an AI-specific control that no published catalogue defines: a local catalogue of these reference controls, or a property extension? (007)
• How should a write-once evidence store honour an erasure request for personal data inside a signed record without breaking the record's signature? (008)
• Chapter 22 names clause 9 only at heading level: which inputs and outputs of internal audit and management review should this control cover once they are read against the standard? (009)
• Which SLSA Build level should a model build reach before its provenance is trusted at load, and should that depend on the risk tier of the system? (010)
• How should a legacy checkpoint that cannot be converted to safetensors be handled: blocked, or admitted after a scan with a named acceptor of the risk? (011)
• Should a build fail when its AIBOM changes in a way nobody approved (a new model, dataset or licence), or only flag the difference for review? (012)

Changelog

• v0.1 (2026-09-26): First draft, derived from the Eval Gate in CI, Continuous Assurance Telemetry, Machine-Readable Evidence (OSCAL), Model Artefact Integrity and AIBOM patterns, six record schemas and chapters 14, 18 and 22: 12 controls, open for technical review.

Sources

Machine-readable

• Each control as JSON, for example AIGE-CTL-ASSURE-001: the link sits at the foot of every control above.
• All controls as JSON: every control of every profile, in the envelope of the open data API.
• JSON Schema of the controls dataset: generated from the same registry.
• Control observation schema: the record a check of a control emits: control_id, subject, expected, observed, status, timestamp, evidence.
• Observation example: a filled record that validates against the schema.
• Observation template: the same fields in Markdown, with short guidance.
• This page as Markdown: /controls/assurance-and-evidence.md. Every dataset of the site is in the open data API.

Review this profile

Review happens in the open, on GitHub. Pick a control, check it against a system you run or know, and say what is wrong or missing: an objective that cannot be verified, a failure mode that is not observable, a mapping that does not hold. Each control has its own button above; this one reviews the profile as a whole, through the control review form.

@misc{aige2026page,
  author       = {Jorge García Aibar},
  title        = {{Assurance and Evidence Control Profile v0.1 (draft)}},
  howpublished = {In AI Governance Engineering: The Thesis \& Body of Knowledge},
  year         = {2026},
  version      = {0.5.0},
  doi          = {10.5281/zenodo.22857084},
  url          = {https://aigovernanceengineer.com/controls/assurance-and-evidence},
  note         = {Version 0.5.0}
}