ISO/IEC 42001:2023

None (tenant-level)

—

Tenant-level governance practice, not addressable at the AF layer. Customer demonstrates this through their own AIMS leadership artifacts. Not tracking in AF-7.

AF-3 (per-agent)

agent_charters rows (each is a per-agent policy expression: purpose, scope, riskLevel, may/mayNot, humanOversight, approvalRequirements) signed by the primary owner

Charters are the per-agent policy expressions. The umbrella org-wide AI policy is tenant-level — but a customer can assemble it from the union of their charters. Not tracking in AF-7.

AF-2

agent_owners row with role ∈ {primary, secondary, observer}, priority, verification_status

Owner taxonomy is the per-agent role assignment. Owners card on /members/[id] is the communication surface.

AF-3, AF-0

agent_charters.riskLevel ∈ {low, medium, high}; action_verbs.risk_class per verb; agent_charters.dataAccess[] and .externalSystems[] for impact context

Two-axis risk classification. Cross-references EU AI Act Art 9 (risk management).

AF-3, AF-4, AF-6

agent_charters.mayNotActions, .mustEscalateWhen, .approvalRequirements; AF-4 statement bindings; AF-6 preflight enforcement writing decision='blocked' / 'escalated' to ledger

Treatment options are declared in the charter, bound via AF-4 assignments, and enforced at runtime by AF-6.

None (tenant-level)

—

DPIA-style impact assessments are tenant-wide governance activities (existing exception/governance-event workflows belong to the broader product). Not tracking in AF-7.

AF-7.5 (planned)

—

Per-agent qualification evidence (validated model + skills + prompts) is unbuilt. Tracked in AF-7.5. The human-side competence interpretation is tenant HR, out of AF scope.

AF-3, AF-1

agent_charters (signed, charterHash for integrity, supersedesCharterId chain for version history); agent_action_events (append-only ledger, trigger-enforced — cannot be silently mutated)

Charter is the documented per-agent policy with cryptographic integrity (hash) and version chain. Ledger is the append-only operational record. ADR-044 documents the append-only enforcement.

AF-1, AF-6

agent_action_events row per action with decision; AF-6 preflight check before write

Every operational action goes through preflight (control) and lands in the ledger (record). The two together are operational planning made executable.

AF-6

agent_action_events.decision ∈ {blocked, escalated} with approved_by_user_id populated for escalations

The decision column is the operational treatment record. approved_by_user_id proves the human-in-the-loop step actually executed.

AF-1, AF-1.5

agent_action_events ledger queryable by tenant/agent/time; Recent Actions tab on /members/[id]

ADR-044 cites §9.1 directly: append-only audit evidence is the basis for monitoring. The four indexes on the ledger support per-agent timelines, per-DID lookups, per-subject drilldowns, and per-execution grouping.

AF-1, AF-2

Ledger queryability (above) plus agent_owners.verification_status (audit-visible row of who's actually verified)

The capability to audit is there. The cadence (planned audit intervals + audit-finding workflow) is a tenant-level governance practice. Internal audit of the AIMS itself is out of AF scope.

AF-3 (per-agent), AF-7.2

agent_charters.reviewDueAt (per-agent recertification timer); AF-7.2 #2626 (recertification workflow)

Per-agent charter review is in scope (AF-3 reviewDueAt + AF-7.2 workflow). Org-level management review of the AIMS as a whole is tenant-level.

AF-6 (detection), AF-7.7 (workflow)

agent_action_events rows with decision='blocked' are the nonconformity signal

AF-6 + ledger captures the nonconformity. The corrective-action workflow on top (root-cause, remediation, sign-off) is tracked in AF-7.7.