IRGF
An enterprise architecture framework for governing AI systems from the moment someone proposes one to the moment it is retired — and for keeping what is actually running tied to what was actually approved.
37 chapters of implementation guidance · 20 modules · 11 stages, 5 gates · a 188-page research report · everything works offline
This is a proposal, not settled practice
IRGF has not been deployed in a real organization. Its mechanisms were designed against a structured requirements set and stress-tested through simulated adversarial review, not through field use. Every threshold, cadence, timebox and scoring anchor in it is a reasoned default, not a calibrated one.
That is precisely why it is published now rather than later. What the work needs next is criticism and field data. Here is where help is most useful.
The problem
Three gaps that existing frameworks leave open
None of these are failures of TOGAF, NIST AI RMF or ISO/IEC 42001. Each of those does its own job well. The gaps appear in the seams between them.
Approved architecture drifts from deployed architecture
Architecture governance produces a decision at a point in time. AI systems change after that point — models are swapped, prompts edited, tools added, knowledge bases refreshed — and nothing systematically compares the running system against what was authorized.
The record of accountability is split across bodies
The architecture board holds the design decision, the AI risk committee holds the risk rating, the portfolio holds the business case, and engineering holds the deployment. No single chain runs from enterprise intent through to a running model, so questions that cross those boundaries have no owner.
Software that acts, not just computes
Classical architecture reasons about data flow and integration. An agent raises a different question — what is this permitted to do, and who delegated that authority. Authority boundaries, reversibility and autonomy change are not standard architecture concerns yet.
What it is
One governed chain from intent to runtime
IRGF places eleven lifecycle stages and five decision gates around a hub of risk and governance, wrapped in a band of continuous assurance that compares deployed state against approved state without pause. Governance intensity scales with an assessed risk tier, so a low-risk internal assistant does not carry the burden of a system that makes lending decisions.
- S0–S10Eleven stages from opportunity through classification, architecture, build, assurance, runtime and retirement.
- G1–G5Five gates where authority is exercised. Evidence depth and automation scale with the tier, so the gate that matters gets the attention.
- D1–D5Five risk dimensions scored 1–4 and resolved on two axes — impact and control deficit — rather than averaged into false moderation.
- AgentsAn eight-link governance chain from identity through permission, tool, policy, action and verification to audit.
- RuntimeA control plane and drift taxonomy that treats divergence from approved state as a detectable, triageable event.
- EvidenceSixteen primary records and four derived views — each artifact justified by a decision it supports, not by convention.
The design goal
Seventeen questions an enterprise should be able to answer at any moment
The framework exists to make these answerable continuously, about any AI system in the estate, through one connected chain of record rather than seventeen separate investigations.
- Why are we using this technology or AI?
- Which enterprise capability does it support?
- Who owns it?
- What data does it use?
- Which model or AI service does it depend on?
- What decisions can it make?
- What actions can it perform?
- What level of autonomy does it hold?
- What risks does it introduce?
- Which policies and regulations apply?
- Which controls mitigate those risks?
- Who approved it?
- Is the deployed architecture still the approved architecture?
- Is the AI behaving as expected?
- Has its risk changed?
- What measurable value is it generating?
- Should it be changed, restricted, replaced or retired?
How it is put together
Twenty modules, adopted in the order that suits you
IRGF is modular by design. Few organizations should adopt all of it at once, and the documentation says plainly which modules carry most of the value if you only implement a fraction. Each module is specified to a uniform template: purpose, inputs, mechanics, outputs, accountable role, how it varies by tier, what it depends on, what it feeds, and the signal that tells you it has failed.
- It defers rather than duplicates. Where NIST AI RMF, ISO/IEC 42001, COBIT or DAMA-DMBOK already solve a problem, IRGF references and interfaces with them instead of restating their controls under new names.
- It has a declared minimum. A defined subset is implementable by a mid-sized organization without a large architecture function.
- It documents its own weaknesses. Fourteen known limitations are registered, each with a practical mitigation, rather than left for a reviewer to find.
Read it
Everything published so far
Three documents, all free to read, copy and use inside your organization. Nothing here requires registration and nothing phones home.
Implementation documentation →
The practitioner site. 37 chapters covering how to run each gate, score each risk dimension, stand up the control plane and tell whether any of it is working. Full-text search, works offline.
HTML · browse now
Research report ↓
How the framework was designed and defended: the problem analysis, a coverage matrix rating thirty governance capabilities across the existing framework landscape, formal design requirements, the full specification, adversarial review, and an anti-novelty test that strips out anything existing standards already handle.
Word · 188 pages · 4.2 MB
Implementation handbook ↓
The same content as the documentation site in a single printable document, for reading end to end, circulating internally or marking up.
Word · 135 pages · 2.1 MB
Where you come in
The framework needs criticism more than it needs adoption
A governance framework that has never met a real organization is a hypothesis. These are the specific things that would move IRGF from a defensible design to something with evidence behind it. If any of them describes you, an email is genuinely welcome — short is fine.
Calibrate the numbers
Every threshold, timebox and review cadence is a reasoned guess. If you know what a realistic assurance window looks like in your sector, or you have incident data that contradicts a default, that is the single most valuable thing anyone can send.
Send calibration input →Pilot it on one system
Not the whole estate — one Tier 3 system through the gates, honestly recorded, including where the framework got in the way. Findings can stay confidential or be published, whichever you prefer.
Discuss a pilot →Review it critically
Enterprise architects, AI governance leads, model risk owners, chief data officers, regulators and academics. Tell us what is wrong, what is redundant, and what an existing standard already does better. Disagreement is more useful than endorsement.
Send a review →Adapt it to a sector
Financial services, healthcare, public sector, manufacturing and critical infrastructure each have obligations the generic model only gestures at. Sector overlays are a natural next contribution and would be credited.
Propose an overlay →Build the tooling
The control plane, policy-as-code rules and artifact schemas are specified but not implemented. Reference implementations, integrations with existing EA repositories, and machine-readable artifact formats are all open work.
Talk about tooling →Report a defect
Contradictions between the research report and the documentation, broken logic in a gate, a control that cannot actually be evidenced, a table that says the opposite of the text. Small corrections are as welcome as large ones.
Report it →What makes a comment easy to act on
- The chapter or section it concerns — a number such as §7.2 is enough.
- What you would change, and what you would replace it with.
- Whether it comes from practice, from a standard, or from judgement. All three count; knowing which matters.
- Your sector and rough organization size, if the point depends on either.
- Whether you are happy to be credited by name, credited by role, or would rather stay anonymous.
What happens next. Substantive comments are logged against the version they concern and answered. Accepted changes appear in the next revision with the contribution acknowledged in the version history unless you ask otherwise. Points that are considered and rejected are recorded too, with the reason — a framework that only publishes the criticism it agreed with is not being reviewed.
Before you ask
Reasonable objections
Is this meant to replace TOGAF?
No. TOGAF's method remains sound for the work it was built for, and several of its phases need no change at all. IRGF is positioned as a governance layer that interfaces with an existing architecture method rather than displacing one. The research report contains a phase-by-phase crosswalk showing what stays valid, what is extended, and where a genuine one-to-one mapping does not exist and should not be forced.
We already run NIST AI RMF and ISO/IEC 42001. Does this compete with them?
It should not, and where it did the component was cut. An explicit anti-novelty test was run across every part of the framework, asking whether existing standards combined with competent architecture practice already achieve the same result. Anything that failed that test was removed or repositioned as an interface. What remains is mostly integration — connecting decisions those standards leave in separate places.
Has anyone actually run this?
No, and that is stated at the top of every document rather than buried. It was stress-tested against eight enterprise scenarios and critiqued from seven reviewer perspectives, with the reviews run by independent instances given no access to the design reasoning and instructed to find failure. That is a design method, not evidence of effect. Treat published thresholds as starting positions and expect to change several in the first year.
Won't this add another layer of governance bureaucracy?
That risk is taken seriously enough to be a design constraint: maximum governance effectiveness with the minimum necessary friction. Concretely, it means two governance bodies rather than eight, gates whose evidence requirements scale with risk tier, pre-approved architecture patterns that skip review entirely, and automated evidence collection wherever a control can be machine-checked. Whether that holds under real conditions is exactly what a pilot would tell us.
Can we use it internally before it is validated?
Yes. It is published to be used and argued with. Read Appendix A first — the known limitations register — so you adopt it with the caveats visible. If you do use it, please tell us how it went, including the parts that did not work.
How should I cite it?
As a version 1.0 framework specification, citing the version and year. The suggested form is in the contact section below. Please cite the version, since thresholds and gate definitions are expected to change between revisions.
Contact
Get in touch
One address, read by a person. Comments, questions, pilot enquiries, corrections and collaboration proposals all go to the same place.
info@irgfframework.com