What is a network source of truth (and how to build one)

Ask five engineers where a given VLAN is documented and you'll often get five answers: a spreadsheet, a wiki page, a device config, someone's memory, and "let me check." That gap — between how the network actually runs and where it's written down — is where outages, duplicate IPs, and 2 a.m. guesswork come from.

A network source of truth closes that gap. It's the single system that holds the intended state of your network: the addresses, devices, cables, and relationships that everything else should agree with.

Intended state vs. observed state

There are two ways to know your network:

• Observed state — what monitoring and discovery report is running right now. Live, but reactive.
• Intended state — what should be running: the design, the allocations, the plan.

A source of truth is the home for intended state. Monitoring tells you a link is down; the source of truth tells you what that link was supposed to be, what's on the other end, and who owns it. You need both, but only one of them can drive automation.

What belongs in it

A useful source of truth covers the things that are painful to reconstruct after the fact:

• IP address management (IPAM) — prefixes, ranges, VLANs, VRFs, and every individual address, with no duplicates and a clear hierarchy.
• Data center infrastructure (DCIM) — sites, racks, devices, and the physical layout, so "which rack, which unit" is a lookup, not a walk.
• Connectivity — cables, interfaces, and circuits: what's plugged into what, at both ends.
• Ownership and context — tenants, tags, contacts, and status, so every object answers "whose is this and is it live?"

Danbyte models all of this in one place. If you want the full breakdown, the features catalog walks pillar by pillar.

Why not a spreadsheet?

Spreadsheets are where most teams start, and they work — until they don't. They can't enforce that two people don't hand out 10.0.4.20 to different hosts. They don't know that deleting a rack should flag the devices in it. And crucially, nothing can query them. The moment you want automation, a spreadsheet becomes a copy-paste bottleneck.

A real source of truth adds three things a spreadsheet can't:

1. Validation — the data model rejects impossible states (overlapping prefixes, an interface cabled to itself).
2. Relationships — objects reference each other, so one change ripples correctly instead of silently going stale.
3. An API — every object is readable and writable by machines, which is what makes the next section possible.

The payoff: automation reads from it

Once intended state lives in one queryable system, your tooling stops guessing. Ansible and Terraform can pull inventory straight from the source of truth instead of a hand-maintained hosts file. Provisioning scripts can ask for the next free address instead of a human eyeballing a sheet.

# Instead of hard-coding hosts, generate inventory from the source of truth
ansible-inventory --list -i danbyte_inventory.py

That's the whole point: the source of truth becomes the input to everything else. Config generation, compliance checks, capacity planning — they all read from the same place, so they all agree.

How to start

You don't need a big-bang migration. Start narrow and let it earn trust:

1. Model one site. Pick a single data center or office and get its racks, devices, and prefixes in.
2. Make it authoritative for one thing. IP allocations are the usual first win — new addresses only come from the tool.
3. Wire up one automation. Point one pipeline at the API. Once something real depends on the data, it stays accurate.
4. Expand outward. Add sites and use cases as the habit sticks.

Danbyte is built to be that system — free and open source, self-hosted on your own hardware, with 100% of the features in the box. When you're ready, it takes an afternoon to stand up.

The best source of truth is the one people actually update. Keep it close to the work, make it the easiest place to get an answer, and it stops being documentation and starts being infrastructure.