docs(examples): align ai-register manifest with EU AI Act, NIST RMF, ISO 42001

examples/governance/ai-register/.ai-register.yaml

@@ -1,14 +1,38 @@
 system:
   id: example-support-agent
   name: Example Customer Support Agent
+  version: v1.0.0
   owner: support-platform-team
+  contact: support-platform-oncall@example.com
   risk_tier: high                  # EU AI Act vocabulary: prohibited | high | limited | minimal
-  deployment: production
   data_classification: restricted
+  created_at: 2025-06-01
   description: >-
     Answers customer support questions over chat. Routes to humans when the
     user requests a refund or asks anything outside the documented FAQ.
 
+  # The specific contexts where this system is authorised to operate, separate
+  # from the general description. Required by EU AI Act Annex IV §1(a) and
+  # NIST AI RMF GOVERN-1.1.
+  intended_use: >-
+    Authorised for registered customers via the public chat interface only.
+    Not authorised for internal employee support, financial advice, or any
+    context outside the documented FAQ scope.
+
+  # Known limitations and out-of-scope uses. Required by NIST AI RMF
+  # MEASURE-1.1 and EU AI Act Annex IV §2.
+  limitations: >-
+    May produce incorrect answers for queries outside the training FAQ.
+    Does not retain conversation history between sessions. Not suitable
+    for legally sensitive or regulated financial inquiries.
+
+  # Human oversight process. Required for high-risk systems under EU AI Act
+  # Art. 14 and NIST AI RMF GOVERN-4. Document who holds override authority
+  # and under what conditions escalation occurs.
+  human_oversight: >-
+    On-call engineer (contact above) holds override authority. Escalation
+    triggers automatically on refund requests and low-confidence responses.
+
   # Models actually in use. Versioned strings so an auditor a year from now
   # can see which family + model identifier was running, not just "Anthropic".
   models:
@@ -21,17 +45,19 @@ system:
   # can `git ls-tree HEAD evals/` to count cases, or run `agentv eval` on demand.
   evals:
     path: evals/
-    runs_in_ci: true
 
-  # Cross-framework controls. Format follows the convention in #1161:
-  # <FRAMEWORK>-<VERSION>:<ID>. Custom prefixes are explicitly supported.
+  # Cross-framework controls. Format: <FRAMEWORK>-<VERSION>:<ID>. Custom
+  # prefixes are explicitly supported. This same string format appears in eval
+  # result JSONL — that's the correlation point between manifest and eval evidence.
   controls:
     - NIST-AI-RMF-1.0:GOVERN-1.3
     - NIST-AI-RMF-1.0:MEASURE-2.7
     - ISO-42001-2023:Clause-7
+    - EU-AI-ACT-2024:Art.14
     - EU-AI-ACT-2024:Art.55
     - INTERNAL-AI-POLICY-1.0:CTRL-CUSTOMER-ISOLATION
 
-  # When the system was last reviewed by the owning team. Aggregators flag
-  # entries older than your governance cadence (quarterly is typical).
+  # Lifecycle dates. Aggregators flag last_reviewed entries older than your
+  # governance cadence (quarterly is typical).
+  created_at: 2025-06-01
   last_reviewed: 2026-04-24

examples/governance/ai-register/README.md

@@ -23,8 +23,8 @@ manifest and the aggregator workflow file.
 - **`.ai-register.yaml`** — example manifest. Drop a copy at the **repo root**
   of each AI system you want to inventory, and edit the fields. `controls`
   uses the same `<FRAMEWORK>-<VERSION>:<ID>` shape as the eval-level
-  governance schema in #1161, so the same string appears in the manifest and
-  in eval result JSONL — that's the correlation point.
+  governance schema, so the same string appears in the manifest and in eval
+  result JSONL — that's the correlation point.
 
 - **`.github/workflows/aggregate.yml`** — copy this into a dedicated
   governance repo (commonly named `ai-register`). It runs weekly (and on
@@ -34,6 +34,27 @@ manifest and the aggregator workflow file.
   workflow summary and can be wired to an issue comment, Slack webhook, or
   whatever notification channel you already use.
 
+## Field reference
+
+| Field | Required by | Notes |
+|---|---|---|
+| `id` | internal | Stable machine identifier; use in dashboards and audit trails |
+| `name` | — | Human-readable display name |
+| `version` | EU AI Act Annex IV Art. 11; ISO 42001 A.9; CycloneDX-ML | Version of the AI system (not the underlying model) |
+| `owner` | — | Team that owns the system |
+| `contact` | EU AI Act Art. 8; NIST RMF GOVERN-2 | Contact surface for compliance inquiries and incident reports |
+| `risk_tier` | EU AI Act Art. 6 | `prohibited \| high \| limited \| minimal` |
+| `data_classification` | internal data policy | Restrict aggregators from publishing sensitive manifests |
+| `created_at` | ISO 42001 A.9 lifecycle records | ISO date; combined with `last_reviewed` tracks system age |
+| `description` | — | General description of what the system does |
+| `intended_use` | EU AI Act Annex IV §1(a); NIST RMF GOVERN-1.1 | Authorised contexts — separate from general description |
+| `limitations` | NIST RMF MEASURE-1.1; EU AI Act Annex IV §2 | Known failure modes and out-of-scope uses |
+| `human_oversight` | EU AI Act Art. 14; NIST RMF GOVERN-4 | Required for `risk_tier: high`. Document override authority and escalation triggers |
+| `models[]` | — | Versioned model identifiers so auditors can reconstruct which model was running at any point in time |
+| `evals.path` | — | Path to agentv evals that exercise this system |
+| `controls[]` | — | `<FRAMEWORK>-<VERSION>:<ID>` strings; same format as eval result JSONL |
+| `last_reviewed` | NIST RMF GOVERN-1.3; ISO 42001 Clause 7 | Aggregators flag entries older than your governance cadence (90 days typical) |
+
 ## Why this stays out of agentv core
 
 agentv does not parse `.ai-register.yaml`. The convention is deliberately