Why discovery, CMDBs, and
telemetry can never produce intent

Buy discovery. Add a CMDB. Layer in telemetry, observability, correlation. Connect them properly, and somewhere in that assembly you arrive at a model complete enough to automate against. This is the roadmap most enterprises are following and most analyst framing assumes.

It is a persuasive story, because every part of it is true except the conclusion.

The descriptive stack.

Consider what each layer actually records.

• Discovery — what exists.
• CMDB — what exists, with ownership attached.
• Telemetry — what is happening.
• Observability — what is happening, in context.
• Correlation — how the things happening relate to each other.
• Configuration — how things are currently set.

Six layers, one question. Every one of them answers what is. Integrating them produces a larger and more elegant description — never a statement of what is allowed.

This is an old distinction in new clothes. You cannot derive an ought from an is: no quantity of facts about how the world is settles the question of how it should be. Infrastructure is not exempt. A perfect record of your estate tells you everything except the one thing governing change requires — which of those states you meant, and which you would refuse.

Observation is not authority. Discovery is not intent. A fact is not a permission.

Three things no amount of integration will tell you.

• A CMDB can tell you a server exists and who owns it. It cannot tell you whether that server is allowed to accept traffic from the internet.
• Telemetry can tell you a configuration changed at 2am. It cannot tell you whether that change should have been permitted.
• Discovery can map every dependency in your estate. It cannot tell you which of those dependencies are intentional and which are accidents nobody has cleaned up.

In each case what is missing is not more data. It is a decision somebody has to have made.

This is the serious counter-argument, and it is getting more credible every year. Feed a model enough change history, enough approvals, enough of how the estate is actually configured, and it will learn your rules. Why declare what can be inferred?

Because inference from history produces a prediction of what you have permitted. It does not produce a statement of what you permit. Those differ in three ways that matter.

• It reproduces your practice including its mistakes. Every unremediated drift becomes evidence of what is normal.
• It cannot distinguish a deliberate exception from an unfixed error. In the data, they look identical.
• It has no standing. When an inferred rule turns out to be wrong, no one decided it — so there is nothing to appeal to, and nothing to correct at the source.

Inference is useful for proposing. It cannot be the thing that authorizes, because authority is not a pattern in data. It is a position somebody holds.

The gap is not new. It has existed in every enterprise for decades. It went unnamed because humans bridged it automatically: an engineer reads the same description an agent would, and then applies everything that is not in the description — who to ask, what broke last time, which exception was granted and why, whether this feels wrong.

That judgment was never written down, so it never looked like a missing system. It looked like competence.

Give the same description to something that acts at machine speed and has no memory of last time, no relationship with the architect, and no capacity to hesitate, and the gap becomes visible immediately — because nothing crosses it. This is why the problem feels new when it is not. AI did not create the authority gap. It removed the thing that was quietly covering it.

Intent already exists in every enterprise. It is simply not in a system. It lives in architecture standards, in review board decisions, in security exceptions granted and documented, in the judgment of the people who know why a thing was built the way it was.

That is why intent cannot be discovered: it was never in the infrastructure to begin with. It is a set of choices your organization made about infrastructure.

Intent is not an emergent property of data. It is an organizational decision.

Isn’t that just a documentation project?

No — and this is where most attempts go wrong. Documentation describes; it does not decide, and nothing consults it before a change runs. Declaring intent means expressing the standards you have already ratified in a form that connected change must clear. The rules mostly exist. What is missing is a place for them to live where they are consulted rather than remembered.

None of this makes the descriptive layers less valuable. It changes what you should expect each of them to be able to do.

• AIOps can detect, correlate and increasingly act. It cannot tell you what its actions are permitted to be — that has to come from somewhere else.
• Digital twins simulate what would happen. Fidelity to reality is not authority over it.
• CMDBs are a record. Improving accuracy makes the record better; it does not make it normative.
• Agentic AI needs something to validate against before it acts, or its safety depends on supervision that does not scale.
• Zero Trust settles who may act. It does not settle what the action is allowed to change.
• Automation executes reliably. Reliability of execution is not correctness of the decision to execute.

Each is necessary. None is sufficient, and no combination of them adds up to the missing piece.

Discovery, CMDBs, telemetry and correlation are necessary. An operating model that does not know what you actually have is worthless, and AuthorIOM reads all of them.

The claim is narrower and more specific: those systems are necessary and not sufficient. They supply the facts. They cannot supply the rules, and no integration of them will.

Not a bigger description. A statement of what is intended and what is allowed — declared by the organization, held against connected change before it executes.

That is why it cannot be assembled, and why building one is a different project from integrating what you already run.

What an Infrastructure Operating Model is →  ·  How it works →  ·  Scope Your IOM →