Methodology
How this reference is built
What qualifies as a runtime control, how each source requirement is selected and labelled, how interpretation is kept separate from the source, and the limits of what this resource claims.
Coverage does not mean compliance.
A technical control may support a compliance or governance objective, but it does not by itself establish legal or regulatory compliance. Nothing here is legal advice, and nothing here implies that any regulator, standards body or authority endorses this resource, Crelis, or any product. The frameworks cited are the property of their respective authors; this is an independent reference to them.
1. What qualifies as runtime-relevant
This reference is about controls that act at agent execution time — the moment an AI agent proposes or takes an action. A source requirement is marked runtime-relevant: yes only when satisfying it plausibly requires a control that operates at or before the point of action: authorizing an action, activating human oversight on it, recording it, monitoring it in production, or being able to stop it.
A requirement is marked partial when it is defined largely at design time or as an organizational process, but is enforced or evidenced at runtime. It is marked no when it is a lifecycle or governance obligation that a runtime control does not satisfy (for example, a risk-management process or dataset-governance duty). We deliberately keep a small number of no rows in the reference to mark the boundary of what a runtime control does and does not cover — the resource is not a claim that everything reduces to runtime.
2. How source requirements are selected
We start from the frameworks that produce genuinely useful agent-runtime mappings and take the specific provisions that speak to execution: authorization, human oversight, logging and records, monitoring, incident handling, and identity. We do not aim for equal coverage across frameworks, and we do not add provisions to make the resource look larger. A candidate that cannot be tied to an execution-time control without forcing the fit is rejected and recorded as such.
3. Mandatory law, recommendations, guidance and concept papers
Each row is labelled with a source type and a binding status:
- Mandatory — a legal obligation (for example, EU AI Act articles). Binding, though application dates may be staged and may have been amended.
- Recommended — a voluntary framework or standard (for example, NIST AI RMF, ISO/IEC 42001). Not law.
- Guidance — supervisory or industry guidance (for example, the MAS SAFR industry white paper). Not binding of itself.
- Interpretive — an initiative or concept paper that is not yet a standard (for example, the NIST AI Agent Standards Initiative). Directional, non-normative.
We never present a recommendation, a piece of guidance, or a concept paper as a legal obligation, and we never present an obligation as satisfied merely because a related control exists.
4. Source hierarchy
Evidence is taken in this order: (1) the current official primary source — the regulation, the standard, the regulator's own publication; (2) official explanatory material from the same body; (3) recognized standards or industry-body material; (4) strong academic or analyst material; (5) vendor or secondary commentary; (6) our own inference. A row cites the highest-standing source available. Secondary commentary may help discovery but does not replace an available primary source, and is never quoted as if it were the primary text.
5. Engineering-interpretation methodology
Every row separates three layers, and they are never merged: what the source says (quoted or closely paraphrased, with a primary-source link), a runtime engineering interpretation(what the requirement could reasonably imply for the design of an agent-execution system — labelled as interpretation, not as the source's words), and a control / evidence implication (examples of the technical control or evidence relevant to implementing the interpretation). The interpretation layer is ours; a reader can disagree with it without disagreeing with the source.
6. Crelis coverage methodology
Separately from the three layers above, each row states whether Crelis currently provides a related capability. This is deliberately understated and is not the point of the resource:
- Direct — Crelis provides a capability that maps closely to the control.
- Partial — Crelis provides part of what the control implies; the rest is broader than one enforcement point.
- Adjacent — Crelis produces something useful to the control (for example, evidence) but does not perform it.
- Not addressed — a runtime control, but not something Crelis does.
- Not applicable — not a runtime control (a scope-boundary row).
Classifications are not biased toward "direct." A row that Crelis does not address says so plainly. The reference is intended to be useful to someone who never uses Crelis.
7. How disagreements and gaps are handled
Disagreements are resolved by evidence, not by opinion or by vote. A candidate row that cannot yet be settled from evidence is held back from publication and carries one of these states:
- Source-review-required — the claim depends on a primary source we could not yet verify (for example, the detailed SAFR checkpoint mechanics that appear only in secondary commentary, or ISO/IEC 42001 Annex A control text, which is under copyright).
- Interpretation-review-required — the runtime interpretation is contestable and awaits reviewer input.
- Rejected — the candidate does not legitimately map to a runtime control.
Only verified rows appear as mappings in the reference. Of the current ledger of 22 candidate rows, 18 are verified and shown; 2 await source review, 1 awaits interpretation review, and 1 was rejected. Those held-back rows are not shown as requirements — they are listed here so the boundary is visible.
8. Update and version process
The reference is versioned and dated (currently 1.0.0, last verified 2026-08-22). Regulation moves — the EU AI Act's high-risk application dates, for instance, were amended by the Digital Omnibus (Regulation (EU) 2026/1744) after the Act's original text — so each row records when it was last verified, and material changes bump the version. The downloadable CSV is generated from the same source as the page, so the two cannot drift.
9. Limitations
- This is a selective reference (~20 mappings), not a complete compliance database. It covers the runtime-relevant subset of a few frameworks, not every provision of any of them.
- Detailed MAS SAFR checkpoint mechanics are drawn from the white paper's public framing; the full paper body was not machine-accessible for verification, so those mechanics are held for source review rather than stated as fact.
- ISO/IEC 42001 Annex A control text is under copyright and is not reproduced; ISO appears here as related context, not as quoted controls.
- EU AI Act article text is verified against the European Commission's AI Act service desk; exact application dates should be confirmed against the Official Journal and the consolidated text, as they have been amended.
- The runtime engineering interpretations are ours and are open to challenge. That is what the source and interpretation layers being separate is for.
This reference is published under CC BY 4.0 — reuse with attribution. Feedback that challenges a source interpretation, a binding-status label, or a runtime-relevance call is exactly what this reference is for.
Back to the reference