How to evaluate an Infrastructure Operating Model
A neutral framework for assessing any solution that claims IOM capability — commercial or open source — against the published standard. The criteria to require, the questions to ask, and the claims that do not qualify.
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.
Capability, not products
This guide is maintained by the IOM working group as a community resource. It evaluates by capability, never by product — no solution is named, ranked, or recommended here. Conformance is demonstrated against the published standard, not granted, and recognition is never purchased.
An honest evaluation sometimes concludes that you do not need a new tool at all — that existing infrastructure, configured and governed differently, already meets a requirement. That is a valid outcome. The goal is governance, not procurement.
What to require
A conformant IOM must provide all seven mandatory capabilities. Each should be demonstrated against your own infrastructure — not described in a deck. If any is absent, the solution is not an IOM, regardless of what it is called.
- ✓
Authoritative state modeling
A continuously updated canonical model of assets, relationships, configuration, and dependencies — not periodic snapshots or human-curated records.
- ✓
Explicit intent and blueprint governance
Intent encoded as machine-readable blueprints, separate from IaC, and declared rather than inferred from runtime behavior.
- ✓
Continuous built-vs-running-state reconciliation
Intended, built, and actual running state compared in real time — not a scheduled scan.
- ✓
Pre-execution validation
Governance decisions made before execution; violating changes blocked deterministically rather than routed to review by default.
- ✓
Explicit ownership and blast-radius awareness
Machine-readable ownership for every element, with deterministic blast radius known before a change executes.
- ✓
Automated evidence generation
Audit evidence produced continuously as a byproduct of governed operation — structured, queryable, traceable from intent to action.
- ✓
AI-safe reasoning substrate
AI systems consume authoritative context and explicit intent boundaries; decisions are bounded, explainable, and auditable.
Questions to ask in an evaluation
Ask for a live demonstration using your data, not synthetic examples. The answers separate an operating model from a collection of tools.
Show me how the model updates when a new service is deployed. How quickly does it reflect reality, and how are relationships captured?
Show me a blueprint. Where does intent live, how is it versioned, and how does it differ from an IaC module?
Show me a change being validated before it executes. What happens when it violates a constraint — can it still proceed?
Show me who owns this service and the blast radius of this change. How is ownership kept current?
Show me the evidence trail for a recent change. How would I answer an auditor's question about what changed and who authorized it?
Show me how an AI agent's action is bounded by the model. What prevents it from acting outside defined intent?
Warning signs — for any vendor
These apply equally to every solution in the category, with no exceptions. Treat them as disqualifying until demonstrated otherwise.
- !
Demonstrations use synthetic data
If the demo won't run against your infrastructure, you are evaluating a brochure.
- !
Key capabilities are “on the roadmap”
A capability in beta or backlog does not satisfy a mandatory requirement today.
- !
Governance happens after the fact
Detecting violations after execution is not the same as preventing them before it.
- !
AI bounds are inferred, not declared
If an agent reads intent from logs and metrics rather than an explicit model, its actions are not governed.
- !
State is updated, not reconciled
A model that reflects what was deployed — rather than reconciling it against what was intended — is an inventory.
- !
Conformance is asserted, not shown
“We're IOM-compliant” is a claim. Ask which requirements, demonstrated how, against whose infrastructure.
Claims that do not qualify
As the term gains recognition, adjacent categories will adopt it. Each below is a useful input or a partial capability — none is an IOM on its own.
| The claim | Why it does not qualify | 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 reconciled against declared intent, or just updated to reflect what was deployed? |
| “We enforce policy” | Policy engines evaluate rules in isolation. An IOM evaluates them in the context of an authoritative model of state, intent, and ownership. | Are policies evaluated against an authoritative 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? |
| “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 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? |
A simple, strict rubric
Score each of the seven capabilities as Present, Partial, or Absent, based on what was demonstrated — not described.
There is no weighted average. The mandatory requirements are mandatory: a solution with any capability Absent is not a conformant IOM, however strong the rest. Partial is a roadmap conversation, not a pass.
Seven of seven
All seven mandatory capabilities Present, each demonstrated against real infrastructure. Anything less is a partial implementation — useful, perhaps, but not an operating model.
Read the normative requirementsEvaluating now?
Take the framework further: read the normative requirements, or run a structured readiness assessment with the Starter Kit.