The IOM Standard
The normative definition of what an Infrastructure Operating Model is — and the criteria any implementation must meet to claim conformance. Open, versioned, and vendor-neutral.
Three questions. Three documents.
Every new category must answer three questions before the market takes it seriously. The IOM answers them across three documents — read them in this order.
The IOM Standard
The normative specification — the conformance requirements an IOM is measured against.
You’re reading it — see the requirements ↓Why AI Needs an IOM
AI can tell what exists and approximate what is intended — but not what is legitimate. That gap is the authority layer.
Read the whitepaper (PDF) →Representation Is Not Authority
Observability, AIOps, and digital twins represent infrastructure. Only an IOM governs it — defining intent before execution.
Read the whitepaper (PDF) →An Infrastructure Operating Model is the authoritative layer that defines what infrastructure exists, what it is intended to do, and what actions are legitimate — before execution occurs.
Rigor without ceremony
The standard adopts the discipline of a formal specification without the overhead of a wire protocol. It uses RFC 2119 normative language (MUST, MUST NOT, SHOULD, MAY), stable section numbering, and a clean separation between binding requirements and explanatory material — modeled on testable standards like OWASP ASVS rather than published as a literal IETF RFC.
Normative specification
The binding layer. Terse, leveled, conformance-oriented requirements with controlled vocabulary and verification criteria. This is what an implementation is measured against.
Narrative primer
The explanatory layer — rationale, context, and adoption guidance. Explicitly non-binding, it points to the normative specification rather than restating it.
What a conformant IOM MUST provide
A solution that cannot satisfy all mandatory requirements does not constitute a conformant IOM. Ask any solution to demonstrate — not describe — each capability against your own infrastructure.
- ✓
Maintains an authoritative state model
A continuously reconciled, canonical model of what exists across cloud, network, identity, and on-premises — not human-maintained records or periodic snapshots.
- ✓
Derives intent from versioned blueprints
Intent encoded as versioned, attributable blueprints, separate from IaC, and declared — not inferred from runtime behavior or telemetry.
- ✓
Encodes ownership and decision authority
Ownership, decision rights, and blast radius are machine-readable and deterministic before execution — not reconstructed under pressure.
- ✓
Enforces constraints before execution
Governance decisions are made before a change executes. Violating changes are blocked deterministically — not routed to review by default.
- ✓
Governs before, during, and after change
Authorization before, constraint enforcement during, and verification and evidence after — not ticket- or approval-only governance.
- ✓
Treats observability as evidence rather than authority
Observability informs decisions but is never the source of intent or authority.
- ✓
Evaluates AI actions against intent before execution
AI-proposed actions are checked against authoritative intent and constraints before they execute; nothing acts outside the IOM’s authority.
Version history and change policy
The standard is formally versioned and change-controlled. Any implementation claiming compliance is evaluated against the published standard, not a vendor's interpretation of it.
| Version | Status | Date | Description | Change policy |
|---|---|---|---|---|
| v1.0 | Draft · Foundational | 2024 | First canonical release. Defines scope, normative requirements, core principles, and conformance criteria. | Draft for review. Changes are versioned with public change memos. |
| v1.x | Working group | In progress | Implementation guidance, conformance test suite, and extended domain coverage. | Open for working group contribution. |
What the standard defines
- ✓
The concept of an IOM
Formal definition, purpose, and scope — including explicit exclusions (CMDB, digital twin, control plane, policy engine).
- ✓
Minimum functional and structural requirements
The normative requirements a system MUST exhibit to qualify. Systems lacking any requirement are not conformant.
- ✓
The role of IOM in governing automation and AI
How IOM functions as the authority substrate for safe, explainable, auditable autonomous operations.
What the standard does not define
- —
Vendor products or implementations
Implementation-agnostic. Any vendor or open-source project may implement IOM without reference to a specific product.
- —
Implementation architectures
How an IOM is technically constructed is out of scope. The standard defines behavior and capability, not architecture.
- —
Tooling choices
Tool-agnostic. Conformant implementations may use any combination of existing infrastructure, security, and governance tooling.
Claims that do not satisfy the standard
As IOM gains recognition, adjacent categories will claim the term. Each of these is a necessary input or a partial capability — none is an IOM on its own.
| The claim | Why it does not satisfy IOM | The question to ask |
|---|---|---|
| “We provide a digital twin” | A twin describes infrastructure through observation. It sits outside the execution path and is advisory. An IOM sits upstream of execution and makes binding determinations of legitimacy. | Does your twin sit in the execution path as an authority layer, or observe after the fact? |
| “We manage infrastructure state” | State management describes what exists. An IOM continuously reconciles what exists against what is intended — and enforces that relationship. | Is your state continuously reconciled against declared intent, or just updated to reflect what was deployed? |
| “We enforce policy” | Policy engines evaluate rules in isolation. An IOM evaluates rules in the context of an authoritative model of state, intent, and ownership. | Are policies evaluated against an authoritative infrastructure model, or rule-checked in isolation? |
| “We have continuous compliance” | Compliance scanning detects violations after they occur. An IOM prevents them through pre-execution validation; compliance is a byproduct. | Does compliance happen before execution, or do you detect non-compliance after it occurs? |
| “We support AI operations” | Supplying telemetry or recommendations is not an authoritative substrate. AI must consume explicit intent and boundaries, not infer them. | Does your AI operate on authoritative, pre-validated context, or infer intent from operational data? |
| “We do continuous discovery” | Discovery builds an inventory. It does not encode intent, enforce constraints, or validate actions before execution. | Is your discovery model used to validate actions before execution, or is it a visibility tool? |
Practitioner-led. Vendor-neutral.
The standard is not owned by any vendor. It is governed as a community resource — developed by practitioners, for practitioners. No company's product roadmap determines its direction.
Open governance
Curated by BrightTech.ai, the founding member, and published open under CC BY 4.0. Changes are proposed and refined through open review and versioned with public change memos — including from its curator. How it stays neutral →
Practitioners and organizations
Architects, security leaders, and technology organizations are invited to contribute to deliberations, propose refinements, and endorse the standard as co-signatories.
Conformance program (in development)
A conformance test suite is in development. Implementations — commercial or open-source — are evaluated against the published requirements, not a reference implementation.
What v1.0 deliberately leaves open.
v1.0 is intentionally bounded. These are questions the working group considers candidates for future versions. They are published to invite contribution — not because the answers are settled. A standard is stronger for stating what it has not yet decided.
- Q1Within a single estate an IOM requires one authoritative source of legitimacy. How should authority federate across organizational or trust boundaries, where that single model no longer holds — and how is precedence resolved when two enterprises’ intents conflict?
- Q2How should authority attestations expire, renew, and be revoked over time?
- Q3How should blueprints compose — and what governs resolution when composed intents conflict?
- Q4What is the right model for multi-enterprise authority, where more than one party asserts intent over shared infrastructure?
- Q5How should an IOM represent AI-generated or probabilistic intent without collapsing the intent/observation distinction?
- Q6What belongs in a portable conformance test, and what must remain implementation-defined?
- Q7How should authority decisions be made explainable and auditable to non-experts?
Have a position? Join the working group →
Assess your readiness
The Starter Kit turns the standard into a working assessment: score your maturity across six dimensions, map your tools, and plan a four-phase adoption path.