Chapter 2. The Core Model in Practice
Eight entities, what each means when you have to record it, and how they map onto artifacts you may already keep.
2.1 The eight entities
The Core Model holds the entities without which IRGF’s traceability claims stop working. Everything else in the metamodel — roughly twenty-three further entities including Strategy, Objective, Value Stream, Dataset, Model, Agent, Policy, and Metric — is supporting structure.
Table 6. The eight entities
| Entity | Operational meaning | Typically recorded in | Owner |
|---|---|---|---|
| Intent | The enterprise purpose or objective a system serves | Capability Record, Use-Case Canvas | Business Sponsor |
| Capability | The business capability the system enables or improves | Capability Record | Business Sponsor with Architect |
| AI System | The governed unit: a deployed system with a boundary, an owner, and a tier | AI System Card (compiled) | AI System Owner |
| Decision | A recorded, authorized choice with a named accountable human | ADR, Deployment Authorization Record | Architect, governance body |
| Risk | The current classification attached to the system | Risk Classification Record | Risk and Compliance Lead |
| Control | A mitigation mapped to a specific risk | Control Matrix | Risk and Compliance Lead |
| Outcome | The measurable result the system was authorized to produce | Benefit Record | Business Sponsor |
| Assurance | Evidence that the system still performs and conforms | AI Assurance Summary, drift records | Varies by assurance type |
A status caveat carried from the research: this set is asserted rather than derived. No minimality test was performed, and no expert panel has validated that eight is the right number or that these are the right eight. It is the organizing structure because no better tested alternative exists, not because its sufficiency is established.
2.2 Why Decision is the load-bearing entity
Practitioners consistently underestimate Decision. It is worth understanding why the framework treats it as central.
Every tier-scaled control in IRGF ultimately compares something against a Decision. A drift alert is meaningful because it says “actual state diverges from what was decided by a named person under a stated tier.” Without a Decision record, a drift alert degrades into “configuration changed,” which is a technical observation with no governance content and no obvious owner.
This has a direct operational consequence. If your Decision records are thin, late, or unowned, the Control Plane cannot produce governance signal regardless of how good your telemetry is. Organizations that invest heavily in telemetry before their decision records are trustworthy generate a large volume of alerts that nobody can act on, and then conclude the Control Plane does not work.
Get Decision records right first. Telemetry second.
2.3 Mapping to what you already have
Most large organizations already hold some version of most of these entities. Adoption is usually less about creating records than about connecting existing ones and closing specific gaps.
Table 7. Mapping to what you already have
| Core Model entity | Common existing equivalent | Typical gap to close |
|---|---|---|
| Intent | Strategy documents, OKRs | Rarely linked to individual systems |
| Capability | Capability model, business architecture | Often stale; AI-enablement flag absent |
| AI System | Application portfolio or CMDB entry | AI systems frequently absent or recorded as generic applications |
| Decision | Architecture decision records | Exist for major programs, rarely for AI-specific choices; often no risk tier recorded |
| Risk | Enterprise risk register, model risk inventory | Not connected to architecture records; no tier driving gate behavior |
| Control | Control library, compliance mappings | Mapped to regulations, seldom to a specific AI system’s risk |
| Outcome | Benefits tracking | Usually stops at program level, not per system |
| Assurance | Test results, audit evidence | Point-in-time; not continuously refreshed |
The pattern is consistent. The entities exist, but they exist in separate systems owned by separate functions, and nothing joins them at the level of an individual AI system. That join is what IRGF asks you to build, and it is why the framework’s contribution is described as connective, not novel.
[Practice recommendation] Before designing anything, run a one-week exercise: pick three production AI systems and try to answer the seventeen questions in §1.5 using only records that exist today. The specific questions you cannot answer are your adoption backlog, and they are usually more informative than a maturity assessment.
2.4 The three views
The same metamodel is read three ways. These are views over one model, not three separate models, and the distinction matters because it determines where a fact is authored.
The Structural View answers what exists and how it connects: domains, capabilities, systems, data products, models, agents, and the relationships between them. Architects work here most of the time.
The Lifecycle View answers where something is in its governed progression: which stage, which gate passed, what evidence exists, what happens next. Delivery teams and governance bodies work here.
The Control View answers whether reality matches the record: drift signals, policy evaluation results, assurance status. Operations, risk, and the Control Plane work here.
A fact is authored in exactly one view and referenced from the others. An AI system’s risk tier is authored in the Lifecycle View at S2, read by the Structural View as an attribute, and used by the Control View to set alert severity. Re-entering it anywhere else creates the duplicate-maintenance problem the artifact model exists to prevent.