How to Use This Handbook

This handbook is the operational companion to An Enterprise Architecture Framework for the Governance of AI Build and Digital Transformation, the research report that designed and stress-tested IRGF. The report answers whether the framework is defensible. This document answers a different question: what do you actually do on Monday morning.

The two documents divide the work. Where the report justifies a mechanism, the handbook tells you how to run it, what evidence to collect, who signs, what usually goes wrong, and how to tell whether it is working. Where the report records a limitation, the handbook tells you how to operate around it. Nothing here overrides the specification in Chapter 14 of the report; where the two appear to disagree, the specification governs and the discrepancy is a defect in this handbook.

Who this is written for

You are an enterprise architect, AI architect, risk and compliance lead, or governance practitioner in a large organization. You have a standing architecture function, some form of architecture review board, and identifiable risk and security partners. Enterprise architecture vocabulary is assumed throughout: domains, capabilities, reference patterns, decision records, and portfolio governance are used without definition.

The handbook does not explain what enterprise architecture is, why AI governance matters, or how large language models work. It assumes you have already decided to adopt IRGF, or are seriously evaluating it, and need to know what adoption involves.

What is in each part

Part A — Orientation establishes what IRGF governs, what it deliberately does not, and how its eight-entity Core Model maps onto records you probably already keep. It closes with a readiness assessment you can run in a week.

Part B — The AI Build Lifecycle is the operational core. Eleven stages and five gates, one chapter per cluster, each with entry conditions, evidence requirements, decision authority, worked examples, and the failure modes that recur. Risk classification receives the longest treatment because every other tier-scaled decision depends on it.

Part C — Agents and Autonomy covers the governance chain for systems that act, not advise, and the specific problem of detecting autonomy increases that were never authorized.

Part D — Continuous Assurance covers standing up the Control Plane: which telemetry to connect first, how to triage each drift category, and where policy-as-code helps versus where it creates noise.

Part E — The Operating Model covers the two governance bodies, decision rights, escalation, and exception handling.

Part F — The Transformation Interface covers what architecture owes portfolio governance and what it must not try to own.

Part G — Artifacts provides the full record set with filled examples rather than blank templates.

Part H — Adoption covers maturity assessment, the phased roadmap, the Minimum Viable Framework for constrained starts, recurring anti-patterns, and how to measure whether governance is working.

Part I — Reference holds the pattern library, gate checklists, scoring worksheets, and the glossary.

Reading paths

Few practitioners will read this front to back. Three shorter paths cover most needs.

Table 1. Reading paths

A status warning you should not skip

IRGF has not been deployed in a real organization. Its mechanisms were designed against a structured requirements set and then stress-tested through simulated adversarial review, not through field use. No organization has been observed running these gates, scoring these dimensions, or progressing through the maturity levels described in Chapter 26.

This matters for how you should read the specific numbers in this handbook. Thresholds, cadences, timeboxes, and scoring anchors are reasoned defaults, not calibrated ones. The 90-day exception ceiling, the five-business-day Tier 3 alert window, the four-tier granularity, and the eight-entity Core Model are all defensible design choices with no empirical calibration behind them. Treat each as a starting position to be adjusted against your own incident data, and expect to adjust several of them within the first year.

Three known weaknesses deserve particular attention before you commit, and each is addressed practically in the chapter noted.

Table 2. A status warning you should not skip

Presenting an unvalidated framework in a confident operational register creates a specific risk: readers mistake specificity for evidence. Where this handbook gives a precise number, that precision reflects the need to give you something usable, not the existence of data behind it.

Conventions used throughout

Identifiers follow the research report. S0–S10 are lifecycle stages, G1–G5 are governance gates, T0–T7 are transformation lifecycle stages, D1–D5 are risk dimensions, FR-nn are the formal design requirements from Chapter 3 of the report, and D-nn are design decisions recorded in the report’s consolidated design log. Where this handbook recommends something the specification does not require, it is marked [Practice recommendation] so you can tell the framework’s requirements from this handbook’s advice.

Worked examples use a deliberately generic organization. No industry framing is used, because sector-specific detail tends to obscure which parts of a mechanism are general and which are contingent. Where a sector materially changes how a mechanism should run, that is called out as a variation rather than built into the example.