For IT leadership, the technical mandate of the last decade has been to automate network operations to eliminate human error, slash provisioning times, and match the agility of the cloud. To get there, some enterprises adopted a Network Source of Truth (NSoT), a centralized database designed to serve as the master digital blueprint of the network. And it worked – until the network outgrew it.
As enterprise environments sprawl across distributed multi-cloud fabrics and hyperscale compute clusters, it’s almost impossible to keep up to date.
Most of these tools were built to inventory devices, not to model everything a modern service depends on: servers, virtual machines, customer contracts, and the relationships between all of them.
So teams end up bolting on plugins, standing up side databases, stitching together the gaps by hand, opening the door to (very costly) errors and drift that NSoT was supposed to eliminate.
Over the next three pieces in this series, we’ll unpack:
- What comes after the source of truth (and why “truth” isn’t really the goal here)
- How NSoT is stalling some of the enterprise’s biggest initiatives (hint: AI)
- Why your automation stack keeps getting more and more expensive
But first, a recap of the network source of truth evolution.
The Four Phases of Network Source of Truth
Phase 1: The Spreadsheet Era (Manual Records)
A decade ago, infrastructure data lived in fragmented spreadsheets and static diagrams. This era was defined by “tribal knowledge.” Data was manually maintained, entirely disconnected from live environments, and outdated the moment it was saved.
True automation was impossible, simply because software orchestration tools had no reliable data layer to query.
Phase 2: The Core Network Source of Truth Era (Centralized Asset Inventory)
The industry took a massive leap forward with dedicated NSoT applications.
These tools stabilized operations by centralizing IP Address Management (IPAM) and asset tracking into structured, API-first databases. They successfully answered a vital baseline question: What hardware do we own, and how is it configured right now?
Phase 3: The Evolved Network Source of Truth Era (Layered Governance and Staging)
As enterprise automation matured, leading NSoT applications evolved rapidly to meet modern demands. Recognizing that writing data directly to a production database was too risky, platforms introduced staging plug-ins, change-management approval workflows (similar to software pull requests), and automated validation extensions.
In this era, engineering teams solved a real operational problem, delivering a polished, production-hardened framework that moved the industry forward significantly.
Phase 4: The Programmable Platform Era (The Native Architecture Frontier)
As evolved NSoT applications have expanded their feature sets, high-scale automation and high-velocity Infrastructure-as-Code (IaC) workflows have exposed an underlying architectural boundary.
Advanced capabilities like data branching, custom objects, and policy validation must be engineered on top of a traditionally rigid SQL asset database – a foundation that was never designed to carry them.
Infrahub, on the other hand, is not a traditional network application that has been extended to support GitOps. It’s a programmable infrastructure data platform built from the ground up where version control and graph-native relationships are architectural defaults, not add-ons.
Why does that matter?
Well, when you’re trying to model literally everything, from the fiber connections between sites to the data centers themselves, with all the networking equipment, server clusters, and virtual environments, you need a data model that’s flexible enough to bend to your business, but structured enough that automation can still trust it.
Take Eurofiber. They offer infrastructure-as-a-service, virtualization, and data center solutions across France. And the faster they can provision new services, the happier the customers and the faster they can start billing.
But because their infrastructure spans an unusually long value chain, every new service deployment touches multiple layers of it. A schema built to inventory network devices wasn’t going to cut it. They needed the flexibility to model their whole environment, exactly as their business works.
They’ve done it in Infrahub, and cut service deployment from 5 days to 15 minutes as a result.
As Senior Cloud Architect Cédric Grard puts it:
“Infrahub is our source of truth, what we consider to be the desired state of everything that’s inventoried within it. It’s the entry point for any new service creation and the authoritative source of information for the entire infrastructure. The model can be entirely modified in every way.”
Note what he’s describing here. Not a record of what exists, but the desired state of what should exist. In other words, a source of intent, a distinction we’ll address in the next piece.
Evolution vs. Revolution: The Architectural Matrix
To understand where a modern Source of Intent fits into your platform engineering roadmap, take a look at how a native data platform differs from an evolved application framework:
| Dimension | Evolved NSoT Applications | Native Infrastructure Data Platforms |
|---|---|---|
| Core Architecture | Application-First: A highly optimized, feature-rich network management application. | Platform-First: A programmable data infrastructure fabric designed to be flexible and extensible to business needs. |
| Database Engine | Relational (SQL): Built on traditional tables, with branching and staging layered on top. | Graph-Native: Built on a graph database where every node, relationship, and attribute can be modified, and is natively version-controlled like Git. |
| Data Philosophy | Opinionated Core: Comes out of the box with a pre-defined data model for traditional networking hardware, extended via custom plugins. | Schema-First: A complete blank canvas. The platform enforces zero pre-defined models, adapting entirely to your infrastructure and business logic. |
| AI Integration | Contextual Wrapper: Exposes application data to AI agents via MCP and agent skills, providing readable access to inventory records. | Native Graph Context: Maps the entire infrastructure as a deeply relational graph with full historical lineage, enabling AI agents to reason about dependencies, blast radius, and business impact — not just retrieve records. |
What This Means for CIOs
The shift from spreadsheets to API-first applications stabilized the industry, no question. And the subsequent evolution of those applications to support staging, branching, and automated validation has given engineering teams unprecedented control over their systems of record, hands down.
But if your goal is a fully automated infrastructure that moves at software speed – where your data model adapts to your business, not the other way around – and your AI agents operate on structure rather than guesswork, then a retrofitted application will always be the ceiling.
That ceiling, unfortunately, is where your competitors who built on native platforms will outpace you.
Infrahub offers a native, programmable data foundation that transforms your infrastructure logic into an active, secure, and dynamic corporate asset.
Evolved NSoT got us further than anyone expected. But it was more of a response to a symptom than a root cause.
Which raises a more fundamental question: What exactly should a source of truth be a source of?
Stay tuned: we’re answering that next.
