Practical systems support, shaped around the work.
Resources - Explainer
Source systems, identity, attribute precedence, reconciliation, and lineage decide whether configuration data can be trusted. This guide walks through the flow in plain terms, using generic, non-confidential examples.
Interactive
Select a stage to see what happens at that step. The stages build on each other: identity decisions shape reconciliation, and reconciliation feeds everything downstream.
Stage 1 of 6
The long version
The same six stages, written out for readers who prefer the full story.
Every configuration record begins downstream of the systems that observe the environment. Endpoint discovery is current but shallow. Asset lifecycle records carry ownership and financial context that discovery never sees. Cloud inventories are authoritative inside their own boundary and silent outside it. Security and network tools notice what matters to them, on their own schedule. None of these views is wrong; none is complete. Naming what each source can and cannot see is the first act of CMDB design, because every later rule inherits those boundaries.
Identity matching decides whether observations can be combined at all. Stable, source-native keys - a serial number, a service tag, a fully qualified name, a cloud resource identifier - do most of the work. Names and IP addresses do not, because both move. Where evidence is strong but incomplete, the safe move is to hold the item as a candidate rather than create a duplicate or merge unrelated things. Every later step inherits identity decisions, which is why this stage is where trust is won or lost.
Disagreement between sources is normal and usually informative. The discipline that resolves it is attribute-level precedence: asset lifecycle records may be authoritative for who owns an item and where it is assigned, endpoint discovery may be authoritative for last-seen activity, and the security tool may be the only source worth trusting on agent state. Recency is not authority, and a source that is authoritative for one attribute can be merely evidence for another. Writing these rules down before configuring tools is what keeps the merge reviewable.
Once identity holds and precedence is defined, reconciliation combines the inputs into a single reconciled record. The mark of a good merge is not that disagreement disappeared - it is that the record shows the winning value and retains the losing observations as recorded evidence. A reviewer can then ask why a value says what it says and get a real answer. Silent overwrites destroy exactly that answer, which is why reconciliation is treated as a recorded decision, not a bulk copy.
Lineage is what turns a reconciled record into evidence. Each field keeps its provenance - the contributing source, the capture time, and the version of the rule that resolved it - so questions like "where did this value come from" and "what breaks if this source changes" have concrete answers. Lineage is also what makes change safe: when a source is migrated, retired, or re-scoped, its blast radius can be traced instead of guessed. Without lineage, every data-quality debate ends in assertion; with it, the debate ends in a lookup.
The reconciled record exists for what consumes it: reporting that has to survive scrutiny, automation that acts on what the data says, and increasingly AI-assisted analysis that amplifies whatever the data already implies. None of those consumers can fix identity gaps or undocumented precedence on their own. That is the practical meaning of AI-ready data - it is not a product feature but a governance outcome, reached when identity is consistent, authority is documented, and lineage is retained. At that point the answers produced downstream can be defended to the people who depend on them.
Worked example
One example asset, three disagreeing sources, and the attribute-level rules that resolve the record. All values are illustrative.
Authority rule. Asset lifecycle records are authoritative for assignment. Login evidence is retained as usage context, never promoted to assignment on its own.
Reconciled outcome. Unassigned, with the discovery login retained as usage evidence.
Authority rule. Asset lifecycle records are authoritative for assigned location. Network sightings are evidence of activity, not of assignment.
Reconciled outcome. Staging area 2, with the last-seen observation retained alongside it.
Authority rule. Lifecycle status comes from the asset record of authority. A missing cloud record raises an identity question; it does not retire the asset.
Reconciled outcome. In service, with the unmatched cloud inventory held as an identity candidate for review.
Evidence flow
After reconciliation, every field still knows where it came from. That provenance is what lets a reviewer - or an auditor - reconstruct any value.
| Field | Reconciled value | Source | Recorded | Rule applied |
|---|---|---|---|---|
| Primary user | Unassigned | Asset lifecycle records | Daily refresh | Assignment authority rule |
| Primary user (usage evidence) | A. Rivera (example) | Endpoint discovery | Observed 09:12 | Usage-evidence capture |
| Assigned location | Staging area 2 | Asset lifecycle records | Daily refresh | Location authority rule |
| Lifecycle status | In service | Asset lifecycle records | Daily refresh | Lifecycle authority rule |
FAQ
Short answers about what this explainer is, and what it is not.
No. The explainer describes the architecture and decisions that hold up across tools. The same questions apply whether the configuration database is a commercial platform or a well-governed internal system, and no vendor behavior is implied.
Because every later decision inherits it. If two records for the same item stay split, precedence and reconciliation merge the wrong things; if unrelated items are merged, reporting quietly becomes fiction. Identity is where trust is won or lost.
AI-assisted analysis amplifies whatever the data already says. Consistent identity, documented precedence, and retained lineage are what make aggregated answers defensible instead of merely plausible-looking.