Chapter 34. Module Reference: Autonomy, Assurance, Operating Model, Evidence
Modules M10 to M20, to the same template. The four groups here are what turn a set of documented decisions into a governed estate: they constrain what acts, detect what changed, decide who says yes, and record what happened.
34.1 Autonomy
M10 — Agent Governance Chain
Table 98.
| Field | Specification |
|---|---|
| Purpose | Constrain what a system that acts is permitted to do, and make its authority comparable against what it actually holds |
| Inputs | M5 tier; architecture decision naming the agent; existing identity infrastructure |
| Mechanics | Eight links, each a control point. Register a distinct machine identity. Define the authority boundary in machine-readable form. Publish an explicit tool allow-list. Enforce policy in code, with a mandatory preventive control for standing-authority Tier 3–4 agents. Execute with a pre-approved kill-switch condition. Verify each action within a defined latency ceiling. Log immutably into Control Plane observation |
| Outputs | Agent Card; machine-readable boundary; immutable audit trail |
| Accountable | AI System Owner, co-authored with the Security Architect |
| Tier variation | Kill-switch conditions mandatory at Tier 3–4. Preventive control mandatory for standing authority at Tier 3–4. Never self-service at Tier 1 |
| Depends on | M5, M7 |
| Feeds | M11, M12, M18 |
| Failure signal | Shared service accounts across agents, which makes attribution impossible; or a boundary recorded only in prose, which makes expansion undetectable |
| In depth | Chapter 16 |
An allow-list rather than a deny-list is deliberate. Deny-lists fail open, and for a component that acts, failing open is the wrong default.
M11 — Autonomy Change Control
Table 99.
| Field | Specification |
|---|---|
| Purpose | Ensure that any expansion of what an agent may do is re-authorized, and that the expansion is detectable rather than merely prohibited |
| Inputs | M10 boundary record; change requests; Control Plane comparison output |
| Mechanics | 1. Classify the change against the boundary-widening test. 2. Widening changes are Major, always, and never eligible for self-service classification. 3. Re-enter risk classification, then G2 and G4. 4. Narrowing changes are Minor by construction. 5. Compare live permissions against the approved boundary continuously |
| Outputs | Change classification; re-scored tier where autonomy moved; updated Agent Card |
| Accountable | AI Governance Body for the authorization; System Owner for the record |
| Tier variation | Autonomy grants and increases route to the AI Governance Body at every tier above 1 |
| Depends on | M10, M4, M5 |
| Feeds | M7 at S9, M12 |
| Failure signal | Live agent permissions differ from the approved boundary, at any tier. Treat as an incident, not a drift finding |
| In depth | Chapter 17 |
Open tension. The rule was narrowed during revision from “any autonomy increase” to “boundary-widening changes only,” and the interaction between that narrowing and audit sampling has never been tested. Weight your sample toward agentic systems until you have your own evidence.
34.2 Continuous Assurance
M12 — Control Plane
Table 100.
| Field | Specification |
|---|---|
| Purpose | Establish whether what is deployed is still what was approved, continuously rather than at review checkpoints |
| Inputs | M18 records supplying approved state; telemetry sources; M5 tier for severity |
| Mechanics | Seven functions as a loop. Observe telemetry. Compare against the approved Decision record. Evaluate severity from drift category and tier. Alert the accountable owner. Recommend remediation. Enforce only within the automation boundary. Learn, feeding patterns back upstream |
| Outputs | Drift and alert records; remediation recommendations; pattern-quality signals |
| Accountable | Architecture function, with per-category owners |
| Tier variation | Comparison cadence, alert routing and response windows all scale with tier. Automated corrective enforcement is permitted at Tier 1–2 only |
| Depends on | M18 above all; also M5, M13, M14 |
| Feeds | M4 (re-scoring), M7 (change), M9 (pattern quality) |
| Failure signal | High alert volume with low resolution rate, which almost always means approved-state records are wrong rather than that the estate is |
| In depth | Chapter 18 |
Sequencing warning. Connect no telemetry source until the corresponding approved-state field exists and is populated for the Tier 3–4 estate. Telemetry before records is the most common way this module fails.
Novelty status. The mechanism is not novel; it applies existing posture-management and policy-as-code practice. What is specific to IRGF is the comparison target — a named Decision under a stated tier — plus the AI-specific drift categories and the feedback into pattern decisions.
M13 — Drift Taxonomy
Table 101.
| Field | Specification |
|---|---|
| Purpose | Classify divergence so that it routes to an owner who can act on it, and so that model problems and data problems are diagnosable apart |
| Inputs | Comparison output from M12 |
| Mechanics | Classify into one of eight categories: structural, configuration, integration and dependency, security, data lineage and governance, AI-model behavioral, policy and regulatory, cost. Route to the category owner. Set severity from category and tier. Close to one of four endpoints: revert, ratify, except, escalate |
| Outputs | Classified drift records with named owners and endpoints |
| Accountable | Varies by category; architecture holds structural and integration, security holds security, data owner holds lineage |
| Tier variation | Severity and response window scale with tier. Agent boundary divergence is an incident at any tier |
| Depends on | M12 |
| Feeds | M4, M7, M9 |
| Failure signal | Findings age without resolution; owners disable notifications |
| In depth | Chapter 19 |
Two categories were deliberately excluded as not telemetry-detectable: capability drift and strategic drift. Both are assessed rather than observed, and claiming otherwise would overstate what the mechanism can do.
The separation of category 5 from category 6 is one of the framework’s few original mechanisms. Its value is diagnostic: when behavior changes, the first question is whether the model changed or its grounding changed, and separated signals answer it immediately.
M14 — Policy- and Evidence-as-Code
Table 102.
| Field | Specification |
|---|---|
| Purpose | Make preventive rules executable rather than documented, and capture gate evidence as a byproduct of operation rather than by assembly |
| Inputs | M18 approved-state fields; policy engine; CI/CD and IAM integration |
| Mechanics | 1. Write preventive rules only where the underlying policy is objectively evaluable. 2. Deploy each in report-only mode for a full delivery cycle. 3. Provide a defined exception path for every enforced rule. 4. Separately, wire evidence capture into the pipelines that already produce it |
| Outputs | Enforced preventive rules; automatically captured evidence |
| Accountable | Architecture with platform engineering |
| Tier variation | Rules apply at all tiers. Corrective automation remains Tier 1–2 only |
| Depends on | M12, M18 |
| Feeds | M7 gate evidence; M12 Evaluate |
| Failure signal | Legitimate work blocked with no recourse, which drives people to route around the control |
| In depth | Chapter 18, §18.5–18.6 |
Roughly two-thirds of the minimum evidence set is automatable. The remaining third — human oversight confirmation, the substance of control mapping, change classification judgment, knowledge preservation — requires human input by nature. This module is where real burden reduction lives, since gate consolidation did not deliver it.
34.3 Operating Model
M15 — Two Standing Bodies
Table 103.
| Field | Specification |
|---|---|
| Purpose | Provide review capacity for high-tier work without creating a second bureaucracy alongside existing architecture governance |
| Inputs | Existing ARB; M5 tiers to determine what escalates |
| Mechanics | 1. Expand the ARB’s mandate to cover AI as a fifth domain, and its membership to include AI expertise. 2. Stand up an AI Governance Body activated for Tier 3–4 only, absorbing the independent-challenge function. 3. Keep architecture decisions and deployment authorization with different bodies. 4. Do not create separate data, security, model-risk or transformation councils |
| Outputs | Tier 3–4 G2 decisions from ARB; Tier 3–4 G3 and G4 decisions from the AI Governance Body |
| Accountable | Enterprise Governance Sponsor for the structure; each body for its decisions |
| Tier variation | The bodies exist for Tier 3–4. Tier 1–2 is federated and never reaches them |
| Depends on | M2, M5 |
| Feeds | M7, M16, M17 |
| Failure signal | ARB agendas full of Tier 1 systems, meaning tiering or federation is not working; or lead times long enough that teams route around |
| In depth | Chapter 20 |
Known limitation. The model does not scale on volume within a single jurisdiction. Only the geography axis was addressed, through a conditional Region or Legal Entity level. Expect to hit this if adoption succeeds, and respond by improving tiering accuracy and expanding patterns before adding capacity.
M16 — Decision Rights and RACI
Table 104.
| Field | Specification |
|---|---|
| Purpose | Establish who decides what at which tier, so that federation is a defined delegation rather than an absence of governance |
| Inputs | M5 tier; role catalogue |
| Mechanics | 1. Assign approval authority per decision type across four tiers. 2. Assign responsibility across both lifecycles. 3. Check that no role is accountable at more than roughly a third of stages. 4. Keep the Enterprise Governance Sponsor accountable for principle-setting and cross-body conflict only |
| Outputs | Decision rights matrix; two lifecycle RACIs |
| Accountable | Enterprise Governance Sponsor |
| Tier variation | This module is the tier variation; every row scales |
| Depends on | M5, M15 |
| Feeds | M7, M17 |
| Failure signal | Decisions made by whoever is available rather than by the named authority; or every senior leader accountable for everything |
| In depth | Chapter 21 |
Open gap. The Security Architect is consulted and can block, but is never accountable anywhere in the RACI. Independent review found this under-weighted relative to security’s role in agent failure modes. Elevating the role to co-accountable at G3 for agentic systems is a defensible local variation.
M17 — Escalation and Exceptions
Table 105.
| Field | Specification |
|---|---|
| Purpose | Provide defined routes for what does not fit, so that non-compliance is recorded and time-boxed rather than silent |
| Inputs | Gate outcomes; drift alerts; tier changes |
| Mechanics | 1. Define six escalation triggers with paths and timeliness expectations. 2. Require every exception to name the requirement, the justification, a compensating control, and a hard expiry. 3. Time-box all exceptions to 90 days. 4. Give Tier 4 exceptions no renewal path — expiry returns the system through full re-authorization. 5. Keep one register and report the aggregate |
| Outputs | Escalation records; a single exception register; portfolio-visible exception counts |
| Accountable | AI Governance Lead for the register; the granting authority for each exception |
| Tier variation | Approval authority scales; the 90-day ceiling does not. Tier 4 alone has no renewal |
| Depends on | M15, M16 |
| Feeds | Portfolio health reporting |
| Failure signal | Exception count rising quarter on quarter, or the same exception type recurring across teams — both mean the requirement is wrong or a pattern is missing |
| In depth | Chapter 22 |
Recurring exceptions are design feedback, not compliance failures. Review the recurring types quarterly as candidates for a framework variation or a new pattern.
34.4 Evidence
M18 — Primary Records
Table 106.
| Field | Specification |
|---|---|
| Purpose | Hold every governed fact once, with one owner and one location, so that derived views can be compiled and approved state can be compared |
| Inputs | Outputs of M7, M8, M10, M12 |
| Mechanics | 1. Maintain sixteen primary records, each with a named accountable owner. 2. Never permit an unowned state. 3. Supersede rather than edit, so history survives. 4. Make machine-comparable fields into fields, not prose. 5. Give every record a stable identifier that others cite |
| Outputs | Sixteen record types; the approved state the Control Plane reads |
| Accountable | Per record; see the table in Chapter 24 |
| Tier variation | Depth scales sharply. A Tier 1 assurance summary is a pass reference; a Tier 4 one carries the full evaluation chain |
| Depends on | M1, M3 |
| Feeds | M12, M19 |
| Failure signal | An ADR field a machine cannot compare; a record with no owner; an ADR edited in place |
| In depth | Chapter 24 |
M19 — Derived Views
Table 107.
| Field | Specification |
|---|---|
| Purpose | Present governance status without duplicating the facts that produce it |
| Inputs | M18 |
| Mechanics | 1. Compile four views entirely by reference: Business Capability Map, AI System Card, Benefit Map, Assurance Dashboard. 2. Author nothing in them. 3. If a view cannot be compiled automatically, do not create it |
| Outputs | Four compiled views |
| Accountable | No independent owner; accountability sits with the owners of the source records |
| Tier variation | None |
| Depends on | M18 |
| Feeds | Reporting, and the seventeen questions in Chapter 1 |
| Failure signal | Any field in a view differs from its source record, which means someone is maintaining it by hand |
| In depth | Chapter 24, §24.2 |
The AI System Card is the artifact practitioners most want and the one most dangerous to maintain manually. A confidently displayed summary that is quietly stale is worse than a visible absence, because nobody checks it.
M20 — Reference Pattern Library
Table 108.
| Field | Specification |
|---|---|
| Purpose | Reduce governance load by pre-approving architectures, so that a familiar problem does not require a novel review |
| Inputs | M9 promotions; drift signals from M13 |
| Mechanics | 1. Publish patterns with explicit variation points — what may change and what may not. 2. Assess conformance as conformant, modified, or novel. 3. Grant the automated G2 path to unmodified use at Tier 1–2 only. 4. Review annually and on repeated drift. 5. Deprecation triggers re-review of dependent systems |
| Outputs | Ten patterns, each with problem, architecture, required controls, primary risk and applicability |
| Accountable | Architecture Review Board |
| Tier variation | Fast path at Tier 1–2 only. Patterns themselves apply at all tiers |
| Depends on | M9 |
| Feeds | M7 at G2; M14 pattern-conformance rules |
| Failure signal | Conformance inflation — materially modified architectures claimed as conformant to obtain the fast path. The counter is specificity in the pattern, not suspicion of the team |
| In depth | Chapter 35 |
Track pattern coverage. The share of new builds using an unmodified pattern is the best available proxy for whether the library is reducing load, and it is the number that justifies continued investment in maintaining it.
34.5 Module dependency summary
Table 109.
| Module | Depends on | Feeds |
|---|---|---|
| M1 Core Model | — | all |
| M2 Architecture Domains | M1 | M7, M9, M15, M20 |
| M3 Three Views | M1 | M12, M18, M19 |
| M4 Risk Dimensions | M1 | M5 |
| M5 Tiering Method | M4 | M7, M10, M12, M15, M16, M18 |
| M6 Independent Verification | M5 | confidence in all tier-scaled decisions |
| M7 AI Build Lifecycle | M4, M5, M6, M20 | M10, M12, M18 |
| M8 Transformation Lifecycle | M2, M5 | M7 |
| M9 Architecture Lifecycle | M2, M20 | M20 |
| M10 Agent Governance Chain | M5, M7 | M11, M12, M18 |
| M11 Autonomy Change Control | M4, M5, M10 | M7, M12 |
| M12 Control Plane | M18, M5, M13, M14 | M4, M7, M9 |
| M13 Drift Taxonomy | M12 | M4, M7, M9 |
| M14 Policy- and Evidence-as-Code | M12, M18 | M7, M12 |
| M15 Two Standing Bodies | M2, M5 | M7, M16, M17 |
| M16 Decision Rights and RACI | M5, M15 | M7, M17 |
| M17 Escalation and Exceptions | M15, M16 | portfolio reporting |
| M18 Primary Records | M1, M3 | M12, M19 |
| M19 Derived Views | M18 | reporting |
| M20 Reference Pattern Library | M9 | M7, M14 |
Two dependency facts are worth extracting from this table. M5 feeds more modules than anything else, which is why classification accuracy matters more than any individual review. And M12 depends on M18 before it depends on telemetry, which is why the Control Plane is a later adoption phase rather than an early tooling purchase.