Chapter 33. Module Reference: Foundations, Classification, Lifecycles

Modules M1 to M9, each specified to a uniform template. This part is written for reference rather than reading: when you need to know what a module consumes, produces, and depends on, look here; when you need to know how to run it well, follow the cross-reference to the narrative chapter.

33.1 How to read a module entry

TOGAF gives each ADM phase a standard treatment — objectives, approach, inputs, steps, outputs. The module entries below follow the same discipline, adapted to what IRGF actually needs a practitioner to know.

Table 87. How to read a module entry

Twenty modules are grouped as they appear on the module map. The grouping is a reading aid, not a governance structure: nothing in the framework depends on a module’s group.

33.2 Module map at a glance

Table 88.

Which modules are load-bearing

Not all twenty carry equal weight. If you are sequencing adoption, three modules determine whether the rest function.

M4 and M5 together produce the tier, and almost every other module reads it. M6 is what makes the tier trustworthy, and the framework’s own review found unverified scoring to be its most confirmed weakness. M18 supplies the approved state that M12 compares against; without trustworthy records the Control Plane produces noise.

The Minimum Viable Framework in Chapter 27 is, in module terms, exactly M4, M5, M6, a reduced M7, and three records from M18.

33.3 Foundations

M1 — Core Model

Table 89.

Status caveat. The eight entities are asserted rather than derived. No minimality test has been performed and no expert panel has validated the set. Record any case the model cannot express; those are what a future revision needs.

M2 — Architecture Domains

Table 90.

The domain’s scope is deliberately bounded: AI Architecture governs the existence, connection, and authority boundary of a component, not its internal construction. Scope creep into model engineering is the most common way this module fails.

M3 — Three Views

Table 91.

33.4 Classification

M4 — Risk Dimensions

Table 92.

M5 — Tiering Method

Table 93.

Known limitation. The override floor catches extremes only. Mid-range judgment calls under delivery pressure remain the framework’s live gaming vector, which is why M6 exists.

M6 — Independent Verification

Table 94.

This is the highest-leverage module in the framework and the one most often dropped during adoption because it costs a person’s time. Dropping it does not remove the cost; it moves the cost to whatever the mis-tiered system eventually does.

33.5 Lifecycles

M7 — AI Build Lifecycle

Table 95.

Adoption note. Gate consolidation reduced labeled checkpoints from eleven to five but did not reduce evidentiary burden proportionally. Do not introduce this module as a lighter process; introduce it as a proportionate one.

M8 — Transformation Lifecycle

Table 96.

Governance depth is deliberately non-uniform across this chain: deep at capability, architecture and outcome; shallow at theme, portfolio and delivery. The T5 stage is an external input interface with no architecture role at all.

M9 — Architecture Lifecycle

Table 97.

This lifecycle was implicit across the framework before being named. It is an organizing device rather than a new governance mechanism, and it is included because pattern maintenance is the activity most often left unowned.