The Genealogy of Infrastructure
Why CMDB Agentic Discovery Needs Confidence Metrics
The Genealogy of Infrastructure
Why CMDB Agentic Discovery Needs Confidence Metrics
Do you trust your CMDB? Do your users? Confidence is a problem that needs to be tackled head on. Thankfully some stuffy british professor types have a few tricks on how we tackle that, especially as we head into an Agentic Discovery future.

I’ve always dreamed of being on Who Do You Think You Are?
For those who haven’t seen it, the show takes a celebrity on a journey through their family history. With the help of historians and genealogists they follow paper trails through census records, immigration manifests, church registries and occasionally some dusty archive that looks like it hasn’t been opened since Queen Victoria was still answering the mail.
What fascinates me about the show isn’t really the celebrity.
It’s the process.
I’ve often caught myself wondering what it would be like to sit across the table from a historian and watch them slowly reconstruct my family tree from fragments of history. Maybe they would discover that I’m distantly related to Charlemagne, like Sharon Stone famously did on the show. Apparently half of Europe eventually connects to him if you go back far enough, so statistically speaking my odds aren’t terrible.
Or perhaps something stranger would turn up. Maybe there’s a pirate somewhere in the family line. The show has uncovered some wild ones — smugglers, revolutionaries, long-lost aristocrats, the occasional scandal that makes the modern descendants visibly reconsider their life choices. Who knows, perhaps I’d discover I share some improbable ancestry with Katy Perry through a long line of Cornish pirates who eventually traded rum, plunder and questionable navigation skills for a quieter life somewhere in Canada.
The mind wanders.
But what always strikes me when I watch the show is how the discoveries actually happen. If you watch the show closely, there’s another moment that happens in almost every episode. At some point the celebrity leans back in their chair and recounts a family story that has been confidently repeated at gatherings for generations.
“My great aunt always used to say…”
What follows is usually a wonderfully dramatic piece of inherited folklore. Perhaps the gardener ran off with the lady’s maid. Perhaps a scandal forced someone to flee the estate. The details vary, but the conclusion is almost always the same: the two of them ran away together and started a new life somewhere down the road.
The story is delivered with complete confidence, the way family legends often are when they’ve been repeated for long enough. Then the historian smiles politely and there is usually a brief pause. Then, with that characteristic combination of British understatement and scholarly precision, the documents appear.
— A census record here — A parish registry there — A property ledger that quietly places the supposed runaway couple living quite respectably in the same village for the next forty years.
The family story dissolves, not dramatically, but gently — replaced by something far more reliable. We build confidence from a conclusion built from corroborated evidence, supported by signals from family lore, but solidified in concrete artifacts.
This is the moment I always find the most fascinating because it illustrates something genealogists understand instinctively : stories may feel true but it is evidence that builds confidence. Genealogy, it turns out, isn’t really about discovering the truth.
It’s about accumulating confidence in what is most likely true.
The Illusion of CMDB Truth
Years later, working on Configuration Management Databases, I realized something slightly uncomfortable. Our CMDBs behave as though they know the truth with absolute certainty. In modern infrastructure environments, that assumption is almost certainly wrong.
When most organizations talk about their CMDB, they describe it as a single source of truth.
It’s a comforting idea. A clean model of the infrastructure where every server has a clear owner, every application has a known dependency chain, and every relationship between systems is perfectly documented. However, modern infrastructure doesn’t really work that way because configuration data comes from everywhere.
- Discovery scans
- Cloud APIs
- Security agents
- Asset inventories
- Manual entries in ticket systems
- Occasionally a spreadsheet someone swears is authoritative because “we’ve always used it.”
Each of these sources tells part of the story, but none of them alone prove anything which to me starts to sound suspiciously familiar. In many ways, building a CMDB looks exactly like building a family tree. You gather fragments of evidence and compare independent sources. Then, you reconcile contradictions and slowly, over time, a picture of the system begins to emerge. Which brings us back to genealogy.
CMDBs, it turns out, aren’t really about discovering the truth.
It’s about accumulating confidence in what is most likely true.
That insight applies well to infrastructure knowledge. However there is an important difference: most CMDB implementations pretend the uncertainty doesn’t exist. They store the conclusion, but none of the reasoning that led to it.

Enter Agentic Discovery
For years, that limitation has been more than merely annoying — it is absolute anathema to good IT estate management.
Traditional discovery tools run deterministic scans. Administrators can usually trace the origin of a data point back to a credentialed query, a known integration, or a specific system of record. When something looks wrong, it’s often possible to follow the trail backward, figure out why, or — at worst — ask someone to recount the family story.
Agentic discovery changes that dynamic.
An autonomous discovery agent doesn’t just run predictable queries. It interprets environments, correlates signals, synthesizes relationships, and returns conclusions derived from thousands — sometimes millions — of observations. These real-time observations produce a massive body of configuration data, including topology inferred off the wire and relationships derived from configuration files. In moments, agentic systems can produce dependency maps that would take a room full of SMEs days or weeks to validate manually.
All of this data is often presented with the same quiet confidence as a deterministic scan. Yet the reasoning chain behind those conclusions is frequently opaque. The agent disappears with its instructions, returns with an answer, and suddenly the old problem of CMDB trust becomes something much larger.
Before, engineers might have had a vague sense that the CMDB was “a little wrong.” With agentic discovery, that uncertainty becomes far harder to reason about at all — unless there is a way to gauge the efficacy of the process and the trustworthiness of the data.
Agentic discovery doesn’t eliminate the CMDB trust problem.
It multiplies it.
Borrowing Tradecraft from Genealogists
Fortunately, this isn’t a new problem.
Historians and genealogists have been dealing with uncertain evidence for centuries. They solved it by refusing to pretend that any single document represents absolute truth. Instead, they built a discipline around confidence. Sources are evaluated for reliability. Independent records are compared for corroboration. Conflicting evidence is documented. Conclusions are expressed in terms of probability rather than certainty.
In other words, genealogy doesn’t attempt to eliminate uncertainty.
It seeks to expose likelihood — confidence — as a first-class metric.
This is the important part: confidence has to be surfaced and tracked. With that realization, a useful model for the next generation of CMDB systems begins to emerge. If agentic discovery is going to produce enormous volumes of infrastructure knowledge, then CMDBs must learn to do something they were never originally designed for.
Not simply record configuration data.
But represent how confident we should be in what we believe to be true about our infrastructure.
The CMDB as an Evidence Model
Once you begin thinking about configuration data as evidence rather than fact, the architecture of the CMDB starts to look different.
Instead of storing a single authoritative value, the system records observations. Multiple sources may report the same hostname. Several systems might suggest the same application dependency. Ownership might be inferred through service models and business capabilities. Each observation becomes a piece of evidence.
Confidence grows when independent sources agree — Confidence drops when they conflict.
Over time the CMDB stops behaving like a rigid database of assumed truths and begins to resemble something closer to a knowledge graph built from corroborated evidence.

A simple vertical progression showing how confidence accumulates. (Thanks CoPilot!)
Which is precisely how genealogists build family trees.
Confidence as Infrastructure Knowledge
In this model, configuration data isn’t simply right or wrong.
It carries confidence as a metric.
Confidence might depend on several factors.
- Source reliability
- Number of corroborating observations
- Distance from direct measurement
- Recency of the data
Some attributes — like IP addresses discovered directly from cloud APIs — might carry very high confidence. Others — like inferred application ownership — may carry much less.
The system doesn’t pretend to know with certainty.
It calculates how confident it should be. It shows you and brings the receipts. This introspection layer is precisely how to keep humans in the loop, and can be used recursively to improve confidence — surfacing low confidence CIs to additional curation steps. Confidence grows over time.
The Future CMDB
For decades, the CMDB has been described as a single source of truth. That was always a convenient simplification. As infrastructure becomes more distributed, more automated, and increasingly interpreted by autonomous agents, the idea of perfect certainty becomes less realistic.
Historians learned this long ago — and genealogists followed in their wake. They don’t claim absolute truth about the past. Instead, they gather evidence, compare sources, and accumulate confidence through the preponderance of evidence.
Perhaps that’s the lesson modern infrastructure systems need to learn as well.
Genealogy, as it turns out, isn’t really about discovering the truth.
It’s about accumulating confidence in what is most likely true.
If agentic discovery is going to build the next generation of CMDB knowledge, then confidence may turn out to be the most important metric in the system.
Christopher David Hill is an Enterprise Architect and IT Consultant at Sun Life. He takes a “MacGyver” approach to solving technology problems, leveraging what business groups have at hand, while advising where investment is required to lead to advantage. He lives in Ontario, Canada where, if you don’t like the weather, just wait 10 minutes. It’ll change.
CMDB #ConfigurationManagement #AgenticDiscovery #InfrastructureArchitecture #ConfidenceMetrics #Evidence‑BasedSystems #SystemsThinking
메타데이터
- post_id
- 81dbb6ca2b8a
- slug
- the-genealogy-of-infrastructure-81dbb6ca2b8a
- url
- https://medium.com/@tatonca/the-genealogy-of-infrastructure-81dbb6ca2b8a
- canonical_url
- https://medium.com/@tatonca/the-genealogy-of-infrastructure-81dbb6ca2b8a
- author_url
- https://medium.com/@tatonca
- status
- ok
- fetched_at
- 2026-06-13 09:11:36