Chapter 18. Standing Up the Control Plane
What to connect first, what to automate, and where automation must stop.
18.1 What the Control Plane is and is not
Seven functions operating as a loop: Observe → Compare → Evaluate → Alert → Recommend → Enforce → Learn.
Table 46. What the Control Plane is and is not
| Function | What it does |
|---|---|
| Observe | Collects telemetry, populating actual-state values on metamodel entities |
| Compare | Checks actual state against approved state recorded in Decision and ADR entries |
| Evaluate | Assesses drift severity using policy rules and the system’s current risk tier |
| Alert | Notifies the accountable owner, scaled by severity |
| Recommend | Proposes remediation without necessarily executing it |
| Enforce | Executes correction, only within the boundaries in §18.4 |
| Learn | Feeds observed patterns back into architecture decisions and pattern quality |
A candid framing, carried from the research: the mechanism itself is not novel. Cloud security posture management, DevOps observability, and policy-as-code engines already do most of this for infrastructure and security. The framework classifies the Control Plane as a recommended implementation pattern instead of a contribution.
What is specific to IRGF is the comparison target. A drift alert here is not “configuration changed” but “configuration changed relative to a Decision made by a named accountable owner under a stated risk tier.” That is a governance fact rather than a technical one, and it is what makes the alert actionable. Three further elements have no direct equivalent in existing tooling: the AI-specific drift categories, the AI-specific policy rules, and the Learn function’s feedback into portfolio and pattern decisions.
The practical consequence: you are probably not buying a new platform. You are more likely extending tooling you already run, and adding the governance context that makes its output meaningful.
18.2 Do decision records first
The most common Control Plane failure is sequencing. Organizations connect telemetry before their Decision records are trustworthy, generate a high volume of alerts nobody can act on, and conclude the mechanism does not work.
Compare needs something to compare against. If ADRs are missing, vague, or unowned, every comparison either fails silently or produces a finding with no approved state to reference and no owner to route to.
[Practice recommendation] Do not connect a telemetry source until the corresponding approved-state field exists in your ADRs and is populated for at least the Tier 3–4 estate. Connect model registry telemetry once ADRs name model families. Connect IAM telemetry once agent boundaries are recorded. Sequencing telemetry to record-readiness is the difference between a working Control Plane and an alert firehose.
18.3 Telemetry sources and connection order
Ten source categories, each mapped to what it can evidence.
Table 47. Telemetry sources and connection order
| Source | Evidence produced | Metamodel target |
|---|---|---|
| Cloud environments, IaC state | Actual deployed infrastructure configuration | Platform, Technology attributes |
| APIs, service meshes, gateways | Actual integration and routing in effect | API, Service, Integration discipline |
| IAM and identity providers | Actual granted permissions, human and machine | Agent authority boundary, actual versus approved |
| Application portfolio and CMDB | Actual inventory and dependency graph | Application existence, dependency map |
| AI platforms and model registries | Actual deployed model family and version | AI System uses Model, actual versus approved |
| Data catalogs | Actual grounding sources and classification | AI System grounded by Data Product |
| CI/CD systems | Deployment events with timestamps | Whether deployment was preceded by a valid Decision |
| Security tooling | Actual posture and incident signals | Control effectiveness |
| Policy engines | Policy evaluation results | Direct input to Compare and evidence capture |
| FinOps | Actual spend against approved budget | Cost drift, often a leading indicator of scale change |
Suggested connection order
Connect two or three sources well rather than ten poorly. The order below front-loads governance value.
Table 48. Suggested connection order
| Order | Source | Why first |
|---|---|---|
| 1 | AI platform / model registry | Directly answers “is the deployed model the approved one” — the highest-value single comparison |
| 2 | IAM | Enables agent boundary comparison, the control with the most consequential failure mode |
| 3 | Cloud / IaC | Broad structural and configuration coverage; usually already instrumented |
| 4 | Data catalog | Enables grounding-lineage drift, an AI-specific category with no equivalent elsewhere |
| 5 | CI/CD | Detects deployment without authorization |
| 6 | Policy engine | Turns comparison into enforcement for objectively defined rules |
| 7+ | Security, FinOps, APIs, CMDB | Valuable, but each adds volume before it adds new governance meaning |
18.4 The automation boundary
Four control types, and a hard line through the middle.
Table 49. The automation boundary
| Control type | What it does | Automation default | Exception path |
|---|---|---|---|
| Advisory | Informs a human, takes no action | Always automated | None needed |
| Detective | Identifies that drift has occurred | Always automated | None needed |
| Preventive | Blocks an action before it takes effect | Automated where the rule is objectively defined | Documented exception process |
| Corrective | Actively remediates a detected violation | Tier 1–2 only, pre-approved and reversible actions | Pre-approved kill-switch at Tier 3–4 |
The corrective line is the one that matters, and it is a permanent design position instead of a maturity gap to close.
Automated corrective enforcement is prohibited by default for Tier 3–4 systems, for any action that would change an agent’s authority, and for any action with low reversibility. The single exception is a kill-switch condition defined and pre-approved at G3 (Chapter 12, §12.3).
This is worth defending internally, because there is persistent pressure to automate remediation as maturity grows. The framework’s position is that maximum maturity means faster and better-evidenced human decisions, not fewer of them. A framework that automated consequential correction for high-tier systems would have abandoned its own human accountability principle.
Preventive controls: objectively defined only
A preventive rule may be automated only where the underlying policy is unambiguous. “Is this model on the approved list” is automatable. “Is this architecture pattern appropriate for this use case” is judgment and must not be.
Every automated preventive control needs a defined exception path. A legitimate edge case blocked with no recourse produces one of two outcomes: the work stops, or someone finds a way around the control. The second is worse than not having the control.
18.5 Policy-as-code: the rules worth writing first
Seven policy domains, with the rules that repay implementation earliest.
Table 50. Policy-as-code: the rules worth writing first
| Domain | Machine-checkable rule | Type | Priority |
|---|---|---|---|
| AI model selection | Deployed model family must be on the approved list | Preventive | First. Cheap, unambiguous, high value |
| Security | No machine identity may hold a permission absent from its approved boundary | Preventive | First. Highest-consequence failure mode |
| Cloud | Resource must carry an approved ADR reference | Preventive | Second. Forces decision-record discipline |
| Agent permissions | Live tool and permission set must match the G2-approved record | Preventive + Detective | Second, once agents exist at Tier 2+ |
| Data location | Data above a sensitivity threshold may not reach an endpoint outside an approved jurisdiction | Preventive | Where sovereignty applies |
| Architecture patterns | System must reference an approved pattern or carry an exception | Preventive | Third. Enables the fast path |
| Approved technologies | System must be built on an approved platform or carry an exception | Preventive | Third |
The first two are the highest-value pair in the framework’s automation surface. Both are objectively evaluable, both have unambiguous failure semantics, and both catch the failure modes most likely to cause real harm.
[Practice recommendation] Deploy every new preventive rule in report-only mode first, for at least one full delivery cycle. The volume of legitimate violations you find is the calibration data you need before enforcement, and it is invariably higher than expected.
18.6 Evidence-as-code
Roughly two-thirds of the framework’s minimum evidence set can be captured automatically as a byproduct of normal operation, not assembled manually.
Table 51. Evidence-as-code
| Evidence item | Automatable | Mechanism |
|---|---|---|
| ADR reference at G2 | Yes | Linked at deployment via IaC tagging |
| Data lineage and classification at G2 | Yes | Pulled from data catalog |
| Pattern conformance result at G2 | Yes | Policy evaluation output |
| Technical evaluation results at G3 | Yes | Captured from the evaluation pipeline |
| Control-to-risk mapping at G3 | Partial | Mapping is judgment; current effectiveness is capturable |
| Human oversight confirmation at G3 | No | Requires confirming an interaction design was implemented |
| Change classification at G4 | Partial | Classification is judgment; delta evidence is capturable |
| Retention and deletion at G5 | Yes | Data platform deletion logs |
| Access revocation at G5 | Yes | IAM deprovisioning logs |
| Knowledge preservation at G5 | No | Inherently a human assessment |
The remaining third requires human input by nature. That is a boundary of the same kind as the corrective-control line, not a gap awaiting better tooling.
Evidence-as-code is where real burden reduction lives. Chapter 4, §4.4 noted that gate consolidation did not reduce evidentiary burden; automated capture does. [Practice recommendation] Measure the proportion of gate evidence captured automatically as a standing metric. It is the most honest available indicator of whether governance is getting cheaper.