NSoT (Network Source of Truth) has become the standard industry shorthand for the centralized database tasked with holding your network configuration data.
But as enterprise networks grow increasingly complex, hyper-distributed, and software-driven, leadership teams must confront a difficult architectural reality: is a “Source of Truth” actually the right framework for managing infrastructure data?
At Opsmill, we believe it isn’t. In fact, relying on the concept of a “Source of Truth” is subtly steering enterprise IT strategies down a high-risk path.
Most network teams are managing a source of truth that tells them what exists. Very few are managing one that tells them what should exist and why. That distinction is the difference between a database and a Source of Intent.
The “Truth” Trap: Why Legacy NSoTs Become Historical Diaries
The word “truth” implies a static, immutable fact. In the early days of network automation, a source of truth was treated much like a digital filing cabinet, a structured application where engineering teams manually cataloged IP addresses, hardware serial numbers, and device locations.
But a filing cabinet only tracks the present asset state.
In practice, this has meant traditional NSoT tools frequently degrade into glorified CMDBs (Configuration Management Databases), a source of record for inventory documentation rather than a dynamic engine that enables an automation infrastructure and drives the business forward.
Quick terminology refresh:
- A source of record tracks the past. What did we change?
- A source of inventory tracks the present. What hardware do we own right now?
- A source of intent drives the future. How must the business operate tomorrow?
The core flaw of the traditional framework is that the running infrastructure is the only absolute source of truth. If a core switch fails in the middle of the night, it’s down – regardless of what your database says.
If an engineer manually updates a live device to fix an outage and logs it in a database after the fact, that database isn’t a source of truth. It’s a historical diary. And you cannot run high-scale, safe automation out of a historical diary.
The Shift to “Intent-Driven” Infrastructure
Modern software engineering stopped building systems around static documentation years ago. Today, the cloud-native world doesn’t care about static snapshots, it runs entirely on intent.
For example, when a platform team deploys a new microservice to the cloud, they don’t manually manipulate live servers or check a static inventory list. They define a precise desired end state using declarative code, and automated continuous deployment (CI/CD) pipelines handle the rest.
Your physical and hybrid network infrastructure requires the exact same philosophy. Infrastructure Intent allows you to:
- Be proactive. It represents exactly how your network and other infrastructure should behave, look, and be secured to satisfy business and compliance policies – now, and next week, next month, or next year.
- Test and log changes. A static spreadsheet doesn’t track adjustments and modifications well. A version-controlled source of intent shows you exactly what changed. A branching system lets you see and fix any potential conflicts before those changes go live.
Traditional NSoT applications are structurally limited when managing this dynamic lifecycle. Because they are designed around rigid, opinionated schemas.
The Greenfield Proof: Why “Truth” Fails on Day Zero
The structural limitations of a traditional NSoT become crystal clear when you’re doing a greenfield data center deployment.
Because when building a new facility from scratch, the physical hardware has not been delivered, the cables have not been run, and the switches are not powered on. There is no physical reality yet, so an inventory-style source of truth is functionally useless. Your engineering teams are left staring at a blank database.
A native source of intent platform, on the other hand, treats the design pattern, the data validation, and the infrastructure lifecycle as a single, unified codebase:
By utilizing a version-controlled, schema-first platform, your architects can simulate and validate the greenfield environment natively on an isolated branch before a single database row is ever finalized, with:
- Automated Generators. Instead of using external scripts to populate database rows, engineers write infrastructure design patterns directly into an intent platform. The system automatically scaffolds the topology, IP addresses, and cabling on an isolated data branch.
- Programmatic checks. Rather than checking data sanity after objects are created in the database, the platform runs automated validation checks natively against the branch. That way, you catch any mistakes before they become big, costly errors in production.
If an architectural flaw exists, the platform blocks the data merge. The engineering team catches the design error in software, on an isolated branch, weeks before physical hardware arrival or provisioning even begins.
Where Infrahub Fits: The Source of Intent Platform
Every design decision we made when building Infrahub – the graph database, the native branching, the schema-first architecture – all came from a single premise: infrastructure intent is a living codebase, not a database record.
That means your teams can propose a new network architecture on an isolated data branch, validate it against compliance policy in isolation, and merge it only when it passes.
And your data model adapts to your business. Build, deploy, and manage AI clusters, cloud overlays, edge fabrics, and without consultants or schema migrations.
All while giving AI agents a deeply relational map of your infrastructure, with full historical context, rather than guessing from a flat asset list.
A Dutch fintech needed a core source of Intent to enable the next phase of network and infrastructure automation across multiple teams. The strategic decision: save developer time by leveraging a proven platform vs. spending time building custom solutions in-house and dealing with vendor lock-in.
For CIOs or VPs of infrastructure looking to hit near-impossible AI and automation targets with fewer resources, fewer errors, in less time, an inventory database isn’t going to get you there.
You need a programmable platform to manage your infrastructure intent.
But how do you frame that in business terms? What’s it costing you the longer you wait? We dive into that next.
