Every automation programme that stalls, stalls for the same reason. Not the tooling, not the skills, not the budget. It stalls because nobody could say with confidence what was actually on the network.
The pattern is familiar. A team buys an orchestration platform, runs a successful proof of concept on twelve devices in a lab, and then tries to extend it to two thousand devices in production. At that point the questions start. Which of these switches is still in service? Which VLAN is that subnet on? Who owns this firewall rule? Is that circuit the primary or the backup? The answers live in four spreadsheets, an ageing IPAM, a diagram someone drew in 2021, and the memory of two engineers.
Automation cannot be built on that. Not because the tooling is weak, but because automation is a function that takes data and produces change. Feed it uncertain data and it produces uncertain change, quickly, at scale, across the estate.
What a source of truth actually is
A network source of truth is not an inventory. An inventory records what exists. A source of truth records what is intended to exist, in a structured, queryable, machine-readable model, and becomes the authority that every other system defers to.
That distinction matters more than it sounds. A discovery tool tells you the network has a VLAN 340 on a particular switch. It cannot tell you whether that VLAN is supposed to be there. Only a source of truth can, because only a source of truth carries intent.
The practical test is simple. If two systems disagree about the network, which one wins? If the answer is "it depends who you ask", you do not have a source of truth yet.
What belongs in it
Teams new to this tend to either under-model or drown. A workable starting scope:
- Physical and logical inventory. Sites, racks, devices, modules, interfaces, cables, circuits. Device roles and platforms as first-class types, not free-text fields.
- Address management. Prefixes, IP ranges, VLANs, VRFs, ASNs. This is usually where the first real win appears, because IPAM chaos is nearly universal and immediately painful.
- Service and tenancy context. Which business service, tenant or application a given piece of infrastructure serves. Without this, automation can act correctly and still cause an outage that matters.
- Intended configuration state. The abstracted definition from which device configuration is generated, not the configuration text itself.
- Relationships. The connections between all of the above. The relationships are where the value is; a flat list of devices is a spreadsheet with extra steps.
What does not belong: real-time performance data, log content, ticket history, and anything that changes every few seconds. Those belong in observability and service management platforms that reference the source of truth, not inside it.
A useful rule
If a human has to type it twice, it is in the wrong place. If a machine has to guess it, it is missing.
Populating it without stopping the business
The instinct is to model everything perfectly before going live. That project never finishes. A better sequence:
- Model one domain end to end. Pick something bounded and painful. IPAM is usually the right first choice. Get it complete and authoritative rather than getting everything half done.
- Import, then reconcile. Bulk load from whatever you have, however imperfect, then run discovery against the live network and treat every difference as a finding to be resolved by a human. The reconciliation backlog is the project.
- Make it the path of least resistance. As long as it is faster to edit the spreadsheet, people will edit the spreadsheet. The source of truth has to become the easiest way to get work done, which usually means wiring it into request and change workflows early.
- Close the loop. Continuous reconciliation against the live network, with drift raised as an exception. A source of truth that is not continuously checked degrades into another stale inventory within a year.
Why security teams should care as much as network teams
This is the part that usually gets missed. Most organisations run two disconnected inventories: one the network team maintains for operations, and one the security team maintains for exposure, compliance and audit. Neither is fully current, and the gap between them is precisely where risk accumulates.
You cannot defend what you have not inventoried. Vulnerability management prioritised without service context produces a list nobody can action. Segmentation designed without an authoritative record of what talks to what produces policy that either breaks applications or permits everything. Audit evidence assembled by hand at the end of a quarter is evidence of effort, not of control.
One authoritative record, read by both practices, removes an entire class of argument. It also makes the compliance question answerable on demand rather than reconstructed under pressure.
What it looks like when it works
A new branch is provisioned from a service definition rather than a change window and a runbook. A subnet request is answered by a system, not by an engineer with a spreadsheet. A configuration drift is detected within minutes and raised as an exception rather than found during an incident. An auditor asks which assets sit inside a control boundary and receives a query result rather than a promise to come back next week.
None of that is exotic. All of it depends on the same unglamorous thing: knowing, authoritatively, what is out there and what it is supposed to be doing.
The source of truth is the least interesting part of an automation programme and the reason the interesting parts hold.