The category, stated plainly.
A single reference surface for defining, bounding, and situating the Infrastructure Operating Model. No positioning language — the definition, the boundary, what it requires, what it explicitly excludes, and how it relates to adjacent markets. Everything here is drawn from the published v1.0 Standard and the whitepaper library.
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. It is a governance discipline and a proposed standard, not a product.
Legitimacy is the boundary. Authority is declared, not assembled.
Adjacent categories model, observe, simulate, or execute infrastructure. What defines the IOM boundary is a different function: continuously reconciling infrastructure state, intent, and ownership, and holding the authority to decide whether a change is legitimate before it runs. A capability falls inside the category when it establishes that authority as an independent reference; it falls outside when it only executes against, or reports on, a state it cannot itself authorize.
Authority of this kind cannot be produced by integrating enough execution tools. It has to be declared as a model that execution answers to — which is why the boundary is legitimacy, not coverage.
What an IOM must do — and what it explicitly does not.
Required (what an IOM must provide)
Summarized from the Standard’s normative MUST requirements. See conformance requirements for exact wording.
- An authoritative, maintained model of what exists and how it relates.
- Declared intent, ownership, constraints, and decision rights, held independently of execution tools.
- A clean separation of intended, built, and running state.
- Continuous reconciliation of reality against declared intent.
- The authority to validate, approve, constrain, or refuse a change before it executes.
- Evidence and learning captured from each decision.
Excluded (what an IOM is not)
Stating what is out of scope is what makes the boundary credible.
- It does not execute or provision infrastructure — execution tools remain the execution mechanism.
- It does not replace CMDBs, digital twins, AIOps, control planes, or policy engines — it governs above them.
- It is not an inventory, a simulation, or an inference system.
- It is not a single vendor’s product; conformance is earned against published requirements.
- It does not mandate a specific implementation, data model, or deployment topology.
Each adjacent category was designed for a different job.
These are established, valuable categories named as prior art. The point is not that any is deficient — it is that none was designed to determine legitimacy, which is the function the IOM adds above them.
| Category | Designed to | Does not establish |
|---|---|---|
| CMDB / inventory | record what exists | what is legitimate |
| Digital twin | simulate behavior | what is authorized |
| AIOps | infer from telemetry | what was intended |
| Control plane | execute change | whether it should run |
| CSPM / posture | assess posture after the fact | intent, continuously |
| Policy engine | enforce rules within a scope | cross-domain authority |
Full arguments: Twelve Tools, Representation vs. Authority, Control Plane or Operating Model?
Every infrastructure era produced a governing model. This is the one AI requires.
Mainframes → servers → virtualization → cloud → automation → AI. Each era increased change velocity, complexity, distribution, and autonomy. The IOM emerges at the point where those variables cross the threshold at which human understanding can no longer keep pace with change — the point at which an authority layer becomes mandatory rather than optional.
The vocabulary, as the standard fixes it.
Authority layer
The layer that determines what is legitimate before execution — the category primitive.
Intent
Declared allowable states, constraints, and ownership — distinct from observed state.
Legitimacy
Whether a state or change is permitted, by whom, and under what constraints.
Reconciliation
Continuous comparison of reality against declared intent, not against a tool’s own last output.
Three-state distinction
Intended, built, and running state, kept separate and reconciled.
Conformance
Meeting the Standard’s published requirements — evaluated against criteria, not a reference implementation.
The v1.0 Standard is written in RFC 2119 conformance language (MUST / MUST NOT / SHOULD / MAY) with stable section numbering. Implementations — commercial or open-source — are evaluated against the published requirements, not against any reference implementation. A conformance test suite is in development.