Chapter 1. What IRGF Governs

Scope, boundaries, and the specific claim IRGF makes. Read this before anything else, because most adoption failures trace back to a team applying the framework to work it was never designed to govern.

1.1 The one-sentence version

IRGF makes a single AI system traceable from the enterprise intent that justified it, through the architecture that realizes it, the risk tier that governs it, and the authorization that released it, to the runtime evidence that it still behaves as approved. That chain, end to end, without switching frameworks partway, is the whole proposition.

Everything else in this handbook exists to make one link of that chain operable.

1.2 What IRGF is not

IRGF is a complementary governance framework. It is not a replacement for TOGAF, not a next-generation enterprise architecture method, and not a new paradigm. It introduces no AI risk taxonomy, no AI management system standard, no general IT governance model, and no security control catalog. Each of those already exists in mature form, and IRGF defers to them.

This deferral is operationally significant, not a disclaimer. If your organization already runs ISO/IEC 42001, IRGF does not ask you to restate its management-system requirements. If you run COBIT, IRGF operates inside that structure, not beside it. If you have a DAMA-aligned data governance function, IRGF extends it at exactly one seam — the lineage between a governed data source and an AI system it grounds — and leaves the rest alone.

Table 3. What IRGF is not

The last two rows cause the most trouble in practice. Teams adopting IRGF frequently try to pull transformation delivery and model engineering into its scope, because both feel adjacent and both have visible governance gaps. Resisting that pull is a condition of the framework working. A governance framework that absorbs everything nearby stops being architecture governance and becomes an unbounded review function, which is the failure mode the design was built to avoid.

1.3 The boundary that matters most: architecture versus engineering

The single most useful line to internalize is where AI Architecture stops.

AI Architecture governs the existence, connection, and authority boundary of a component. It does not govern the component’s internal construction.

This is the same line TOGAF already draws between enterprise and solution architecture. AI is not exempt from it because the technology is newer.

Table 4. The boundary that matters most: architecture versus engineering

A practical test when you are unsure: could a reasonably informed architecture review board member evaluate this without becoming a machine learning engineer? If yes, it is probably in scope. If evaluating it requires reading training code, it is not.

1.4 What “governance” means here

IRGF’s governance is not primarily a review activity. Reviews exist, but they are the smallest part of the design. Three mechanisms carry most of the weight.

Classification. A risk tier is assigned early and re-assigned whenever a change plausibly moves one of the five risk dimensions. Almost every other decision in the framework keys off that tier. Getting classification right matters far more than getting any individual review right.

Federation with verification. Tier 1 and Tier 2 work is self-service by default. Product and solution teams make their own architecture and deployment decisions inside pre-approved patterns and policy guardrails. This is only safe because the Control Plane checks their self-certifications continuously against the same rules a reviewer would apply. Federation without that verification is delegation without accountability, and the framework does not support it.

Continuous comparison. The framework’s distinguishing claim is that deployed state is compared against approved state on an ongoing basis, not at review checkpoints. The comparison target is specific: not a generic security baseline but a named Decision record made by an accountable owner under a stated risk tier.

If you adopt only the review gates and skip classification discipline and continuous comparison, you will have added ceremony without adding assurance. That is the most common way to implement IRGF badly.

1.5 The seventeen questions

IRGF exists to let an enterprise answer seventeen questions about any AI system, continuously, from one connected structure. The list is worth keeping visible, because it is the acceptance test for whether your implementation is working. If you cannot answer one of these for a production Tier 3 system, you have found a gap.

Table 5. The seventeen questions

Notice that no single artifact answers more than two questions, and that the AI System Card — the one-page summary practitioners most want — is a compiled view over the others instead of a record anyone maintains by hand. That is deliberate, and Chapter 24 explains why duplicating these fields into a hand-maintained summary reliably produces stale governance data.