Chapter 9. Data Readiness and Gate G2: S4

The stage that determines whether an AI system’s outputs can be traced to governed inputs, and the gate that assesses architecture and data together.

9.1 What S4 establishes

Three facts, each recorded in the Data Lineage and Sensitivity Record.

Lineage. Which governed data sources ground, train, or otherwise feed the system, named individually. “The knowledge base” is not lineage; “Data Product PD-114, Policy Documents, owner Legal Operations” is.

Classification. The sensitivity classification of each source, using the enterprise’s existing scheme. IRGF does not define a classification scheme and should not; it consumes yours.

Governance status. Whether each source has an owner, a maintenance commitment, and a refresh cadence. This is the field most often left blank and most often responsible for later failure.

9.2 The stale-grounding problem

A retrieval-augmented system grounded on a source nobody maintains will pass every gate and then degrade silently. Its outputs remain fluent and become progressively wrong. No infrastructure telemetry detects this, because nothing about the deployment has changed.

This is why S4 asks for a maintenance commitment, not only a classification. A grounding source without a named owner and a refresh cadence should be treated as a G2 finding, not a documentation gap.

[Practice recommendation] Record a maximum acceptable staleness per grounding source at S4, and treat exceeding it as a drift condition in the Data Lineage category (Chapter 19). For a policy corpus that changes quarterly, ninety days may be right. For a pricing table, a day may be too long. The number matters less than the existence of an agreed one.

9.3 Grounding lineage as the AI-specific extension

Data governance is otherwise deferred to your existing DAMA-aligned practice. IRGF extends it at exactly one seam: the relationship between a governed data source and an AI system it grounds.

That seam matters because it is where two failure modes meet. Data governance tracks sources and their quality. Model governance tracks model behavior. Neither, on its own, notices when a model’s behavior changes because its grounding source changed. Keeping the lineage relationship as a first-class governed fact is what allows the two to be distinguished at diagnosis time, and it is one of the framework’s few genuinely original mechanisms.

9.4 Gate G2 — Architecture and Data Readiness

Table 30.

Sequencing inside G2

S3 and S4 are frequently iterative, not sequential. An architecture choice constrains which data sources are usable; a data constraint forces an architecture change. The framework was revised to permit parallel and iterative resolution of S3 and S4 sub-components before a joint G2 exit, instead of requiring S3 to close before S4 opens.

What must be true at G2 exit is that both records are complete and consistent with each other. What need not be true is that they were produced in order.

The risk re-score at G2

The provisional tier from G1 was assigned before the architecture was known. Architecture routinely changes the score in both directions: a decision to use a private hosted model lowers D5; a decision to grant an agent write access to a system of record raises D2 and D3 together.

A G2 that does not revisit the tier is incomplete. If the tier changes, the decision authority for G2 itself may change with it, which occasionally means a gate in progress must escalate mid-review. That is inconvenient and correct.

9.5 Vendor and procured AI at G2

Procured AI is where G2 most often fails to function, because the evidence a reviewer wants is held by a third party who may decline to provide it.

The framework’s answer has three parts.

Procurement is a named consulted role at S1 and S2 for procured or integrated AI, not merely a purchasing function invoked after the architecture is set.

The ADR carries extended due-diligence fields for procured systems: what evaluation evidence the vendor supplies, what the vendor’s model update policy is, what data the feature processes and where, and what contractual audit rights exist.

There is a defined resolution for evidence stalemate. When a vendor will not supply evidence the tier requires, two outcomes are available: cap the system at Tier 2 by constraining its use so that the higher-tier requirements do not apply, or obtain a documented risk acceptance from the AI Governance Body. What is not available is proceeding at Tier 3–4 with the evidence gap unrecorded.

[Practice recommendation] Build the evidence requirements into procurement templates before you need them. Asking a vendor for model evaluation evidence during contract negotiation is a different conversation from asking after deployment, and the second conversation usually fails.

9.6 Common G2 failures

Table 31.