Chapter 24. The Artifact Set
Sixteen primary records, four derived views, and the non-duplication rule that keeps them from going stale.
24.1 The rationalization test
Every candidate artifact was tested against one question: what decision would become impossible or materially weaker without it? Artifacts failing the test were rejected outright or reclassified as derived views compiled from records that pass.
Three candidates were rejected entirely. An Enterprise Transformation Map duplicates a portfolio roadmap the framework does not own. An AI Capability Map is a filtered view of the business capability map. A Model Card is ML engineering documentation; only a reference to it is architecture-relevant.
Four were reclassified from records to views: Business Capability Map, AI System Card, Benefit Map, and Assurance Dashboard. Each is genuinely valuable and none should be independently authored.
24.2 The non-duplication rule
Every primary record has exactly one authoritative owner and one location. Every derived view is compiled by reference and never re-entered.
This is the rule that determines whether your governance data stays accurate. The AI System Card illustrates why. It is the single-pane summary practitioners most want: tier, owner, architecture, controls, authorization, open changes, open exceptions, assurance status. Every one of those fields already exists in another record.
Maintaining it by hand means every field has two homes, and the copy drifts from the source within weeks. Governance data that is confidently displayed and quietly wrong is worse than data that is visibly absent, because nobody checks it.
[Practice recommendation] If you cannot compile the AI System Card automatically, do not create it. A manually maintained version will be out of date at the moment it matters most.
24.3 The primary records
Table 64.
| # | Record | Purpose | Owner | Created at |
|---|---|---|---|---|
| 1 | Capability Record | Baseline and target maturity, gap, dependencies, AI-enablement flag | Sponsor with Architect | T1 |
| 2 | AI Use-Case Canvas | Business justification and provisional risk signal | Business Sponsor | S1 |
| 3 | TG0 Initiative Qualification Record | Evidence for the transformation qualification questions | PMO, with mandatory architecture input | T2 |
| 4 | Architecture Decision Record | Architecture decision and rationale, AI-extended | Architect | S3 |
| 5 | Reference Pattern Library entry | Pre-approved pattern enabling self-certification | Architect | On pattern proposal |
| 6 | Data Lineage and Sensitivity Record | Grounding lineage and classification | Data Owner | S4 |
| 7 | Risk Classification Record | D1–D5 scores, computed tier, override flag | Risk Lead | S2 |
| 8 | Control Matrix | Control-to-risk-to-standard mapping | Risk Lead | S6 |
| 9 | AI Assurance Summary | Pass/fail evidence reference from technical evaluation | System Owner | S6 |
| 10 | Agent Card | Agent identity, tools, boundaries, kill-switch | System Owner with Security | S3 |
| 11 | Deployment Authorization Record | The G3 decision | System Owner or AI Governance Body | S7 |
| 12 | AI Change Record | Change classification and evidence | System Owner | S9 |
| 13 | Architecture Exception | Time-boxed exception | Requester | Any point |
| 14 | Benefit Record | Realized value against baseline | Sponsor | T6 |
| 15 | Drift/Alert Record | Control Plane output | System-generated | On detection |
| 16 | Regulatory Overlay Reference | Mapping of applicable regimes to affected systems | Risk Lead | On adoption, maintained |
Four derived views compile from these: Business Capability Map, AI System Card, Benefit Map, Assurance Dashboard.
Three optional artifacts improve decision quality without being load-bearing: Technical Debt Register entry, Pattern Retrospective, and Stakeholder Map.
24.4 Worked templates
Risk Classification Record
Table 65.
| Field | Content |
|---|---|
| Purpose | Record D1–D5 scoring and the resulting tier |
| Owner | Risk and Compliance Lead |
| Trigger | S2 initial; any Material or Major change; any risk-relevant drift alert; annual for Tier 3–4 |
| Mandatory fields | D1–D5 scores each with a one-line justification; D5 sub-scores for sensitivity and uncertainty; computed Impact and Control Deficit; resulting tier; safety-override flag; countersignature with date and any adjustments made |
| Approval | Self-service for downward or lateral change at Tier 1–2; AI Governance Body for any upward change at Tier 3–4 |
| Update | Re-scored on every Major trigger; history preserved, never overwritten |
| Retention | Life of system plus 3 years |
| Related | Use-Case Canvas (input), Change Record (trigger), Control Matrix (downstream) |
Example. Claims triage assistant. D1=3 (misrouting delays a claim and may disadvantage a claimant). D2=2 (proposes routing, adjuster approves each). D3=2 (routing reversible; elapsed delay is not). D4=3 (all claims; feeds claims system of record). D5=3 (sensitivity 3 restricted personal data; uncertainty 3 generative; composite = higher of the two). Impact = 3. Control Deficit = 2. Tier 2 by matrix. No override. Countersigned by Risk Lead, D3 raised from 1 to 2 — original score reasoned from mechanism reversibility.
Architecture Decision Record, AI-extended
Table 66.
| Field | Content |
|---|---|
| Purpose | Record an architecture decision and rationale, with AI-specific criteria |
| Owner | AI / Enterprise Architect |
| Trigger | S3 for any new or materially changed AI System, Application, or Platform component |
| Mandatory fields | Decision statement; alternatives considered; rationale; pattern conformance result or documented deviation; model or service named; hosting pattern; grounding sources named; authority boundary for agentic systems; risk tier at decision; accountable owner. For procured systems: vendor evaluation evidence, model update policy, data processed and location, contractual audit rights |
| Approval | G2 — self-certified at Tier 1–2 against the pattern library; ARB at Tier 3–4 |
| Update | Superseded, never edited; supersession references the prior ADR |
| Retention | Life of component plus 3 years |
| Related | Pattern library (checked against), Risk Classification (referenced), Data Lineage (referenced) |
Example. ADR-0142. Use Enterprise RAG pattern v2, unmodified. Model: [approved list entry], version policy pinned minor with vendor patch auto-accepted. Hosting: vendor API, EU region. Grounding: Data Product PD-114 (Policy Documents, Restricted) only. Alternatives: fine-tuned model rejected on recurring revalidation cost; no-AI rejected, rule-based routing tested at 61% accuracy against a 90% requirement. Pattern conformance: conformant. Risk tier at decision: Tier 2. Owner: A. Mensah.
Agent Card
Fields and a worked example appear in Chapter 16, §16.3.
Architecture Exception
Table 67.
| Field | Content |
|---|---|
| Purpose | Record a time-boxed decision to proceed without meeting a requirement |
| Owner | Requesting role |
| Mandatory fields | The specific requirement excepted; justification; compensating control if any; hard expiry date; approving authority |
| Approval | Per decision rights; always ≤ 90 days; no auto-renewal at Tier 4 |
| Update | Never silently renewed; expiry notifies the approving authority |
| Related | Feeds portfolio health reporting as “initiatives operating under exception” |
AI System Card, derived view
Table 68.
| Field | Content |
|---|---|
| Purpose | Single-pane governance status, compiled not authored |
| Owner | No independent owner; the System Owner is accountable for the underlying records |
| Fields, all by reference | Current ADR; current tier; Control Matrix status; Agent Card if applicable; latest Deployment Authorization; open Change Records; open Exceptions; latest assurance status |
| Approval | Not applicable; a compiled view has no approval step |
| Update | Real-time or near-real-time from evidence-as-code capture |
24.5 Tier-scaled documentation depth
Documentation depth scales with tier. This is where much of the framework’s proportionality actually lives.
Table 69. Tier-scaled documentation depth
| Record | Tier 1 | Tier 4 |
|---|---|---|
| ADR | Architect self-certified, minimal narrative | Full ARB-reviewed rationale |
| AI Assurance Summary | Pass or fail reference | Full underlying evaluation reference chain |
| Agent Card | Kill-switch field not required | Kill-switch conditions mandatory and separately approved |
| Risk Classification | Countersigned, brief justifications | Countersigned, full justification per dimension, annual re-score |
| Control Matrix | Mapped controls listed | Mapped controls with current effectiveness evidence |
24.6 Where to keep records
The framework does not mandate tooling. Three properties matter more than product choice.
One authoritative location per record type. Records split across a wiki, a ticketing system, and a spreadsheet cannot be compiled into derived views, which means the views get maintained by hand, which returns you to §24.2.
Machine-readable where the Control Plane must read it. Model family, hosting pattern, grounding sources, authority boundaries, and tier need to be fields, not prose in a document.
Referenceable identifiers. Every record needs a stable identifier that other records cite. This sounds trivial and is the thing most often missing; without it, the traceability chain is a set of documents that mention each other by name.