When someone asks for a single source of truth, I understand the appeal. They want a dependable place to get an answer, without checking several platforms and deciding which one to believe.
But the answer still depends on what they’re asking.
An inventory system might be authoritative for which network devices the organization intends to operate. Another platform might hold collected configurations or discovered dependencies for those same devices. A CMDB might connect them to application ownership and business services.
Each can be authoritative for particular information. Saying one of them is “the source of truth” for the network doesn’t explain those boundaries.
That’s where I think the phrase starts to create confusion.
The same device, different authority
A switch can appear in several systems because each system needs to know something about it.
The intended inventory records that it should exist at a particular facility. A configuration collection platform records what was configured when it last collected the device. A dependency mapping platform records the relationships it has identified.
Seeing the switch in each platform doesn’t make each platform an equally authoritative inventory.
The organization may have deliberately assigned inventory authority to one system, configuration evidence to another, and dependency information to a third. Their records overlap because they describe the same infrastructure.
I find the distinction between intended and operational state particularly useful here. NetBox’s design philosophy explicitly describes desired network state and calls for human validation of data. That tells us much more than the shortened statement that “NetBox is our source of truth.”
The product name alone doesn’t establish how an organization uses it or what its records represent.
The same applies to configured and observed state. A collected configuration describes what was present at a point in time. It doesn’t necessarily establish that the configuration was approved, or prove which path traffic is taking now.
Finding a discrepancy doesn’t transfer authority
Suppose a platform collecting configurations discovers a switch missing from the intended inventory.
That discovery is useful and it should prompt an investigation.
Someone may have deployed the switch during an urgent situation and missed the documentation step. It may be an unauthorized deployment. The intended inventory may need correction, or the environment may need to change.
The inventory remains the agreed authority for intended devices while that discrepancy is resolved. The collecting platform has exposed a gap; that finding doesn’t automatically make the discovery systems the inventory authority.
This also means we need to distinguish being authoritative from being accurate. If a legitimate device was omitted, the inventory record is incomplete. Its designated role doesn’t make the omission correct.
Reconciliation establishes what needs correcting and where the correction belongs. Simply copying every discovered device into the intended inventory could make the records agree while accepting infrastructure that was never authorized.
OpenGitOps preserves the distinction between declared desired state and actual state through continuous reconciliation. Enterprise inventory may require investigation rather than automatic enforcement, but preserving intent as a separate reference remains useful.
I would be comfortable using discovery to establish an initial inventory, then validating it as intended state. Subsequent changes could come through people, APIs, or an infrastructure-as-code workflow. What matters is that observation doesn’t silently become approval.
And if two systems really do make conflicting claims about the same fact, we need a rule for resolving that conflict. Having several sources doesn’t make every answer equally valid.
Discovery needs something to be compared against
I’ve been in situations where a facility reported a network outage and its infrastructure wasn’t present in the observability platform.
That experience makes me cautious about using a monitoring platform’s discovered inventory as the complete reference for what should be monitored.
Discovery can have excellent coverage and still miss infrastructure. Credentials, reachability, and discovery scope can affect what it finds. If its results also define the expected population, there may be no independent reference to reveal an omission.
An intended inventory can provide that reference. The comparison tests monitoring coverage against an agreed expectation.
There can also be deliberate differences. A platform licensed to manage only part of the network might receive a selected subset from the intended inventory. Its device list could be complete for its assigned purpose while remaining unsuitable as the enterprise inventory.
These responsibilities could exist within one product or across several. I care more about preserving the distinctions than prescribing a particular number of systems.
An aggregate can become authoritative for another purpose
A configuration management database, or CMDB, can consume network inventory, IP allocations, ownership records, and dependency information to produce a shared organizational view.
That view can become the agreed source for a function like disaster recovery planning. The recovery team shouldn’t necessarily have to connect to every underlying platform and reconstruct the relationships itself.
The underlying systems can remain sources of record for particular information while the CMDB provides the authoritative view for that downstream purpose. Some relationships may be established in the CMDB itself. The distinction depends on how the organization has designed the flow.
ServiceNow’s static reconciliation rules illustrate part of this by authorizing and prioritizing sources for particular configuration item attributes. Authority can be more specific than the database containing the record.
Suppose a recovery exercise reveals a missing database dependency. That evidence should inform the exercise and trigger investigation into the shared view. Was an upstream record missing? Did an integration fail? Was a relationship inferred incorrectly?
I would still consider the CMDB the agreed source for recovery planning while correcting the problem. One error wouldn’t automatically justify requiring every consumer to rebuild the abstraction. Repeated failures might justify changing the architecture, but first we need to understand where it failed.
For me, the useful goal is a clear authority for particular information, with a way to accept evidence, correct errors, and carry those corrections to consumers.
“Single source of truth” can be useful shorthand once that agreement exists. Without it, we can use the same phrase while expecting very different things from the same platform.