I · Module reference

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.