Two layers of network automation
Enterprise network automation is often discussed as a single problem with a single solution. In practice, it spans two distinct layers that serve different purposes — and conflating them is one of the most common reasons automation initiatives underdeliver.
The first layer is the Source of Truth (SoT): a structured model of your network — devices, sites, IP addresses, circuits, tenants, and the relationships between them. This is where Nautobot excels. It provides a canonical data model, extensible through plugins, that teams use to document intent, drive provisioning workflows, and integrate with Ansible, Terraform, and other automation tools.
The second layer is operational intelligence: the actual running state of every device in your estate — configurations captured from live equipment, compliance validated against policies, drift detected against baselines, and changes tracked with version history. This is where Orion operates. It does not replace your SoT; it answers a different question entirely.
The question Nautobot answers is: what should our network look like? The question Orion answers is: what does our network actually look like right now — and does it match what we expect?
What Nautobot does well
Nautobot is a mature, open-source Network Source of Truth built on Django. It provides a rich data model for DCIM, IPAM, circuits, virtualization, and tenancy — with a plugin ecosystem that extends its capabilities into device lifecycle management, chatops, and custom automation workflows.
For organizations building a NetDevOps practice, Nautobot is often the foundation. It centralizes network inventory, eliminates spreadsheet-driven CMDBs, and provides REST APIs, GraphQL, and webhooks that automation pipelines consume. Teams model their infrastructure once and reuse that data across provisioning, documentation, and reporting.
The extensibility model is a genuine strength. Custom plugins add models, APIs, and UI elements without rebuilding authentication, permissions, or change logging from scratch. This is why the Nautobot ecosystem continues to grow — and why vendors and integrators invest in building plugins for it.
Nautobot is not trying to be a configuration management or compliance platform. It was never designed to log into thousands of devices nightly, parse running configurations, and compare them against security policies. That is not a weakness — it is a scope decision. The platform's job is to maintain authoritative data about your network's intended state.
Where Source of Truth alone falls short
A Source of Truth is only as accurate as the processes that keep it updated. In most enterprise environments, the gap between documented intent and operational reality grows silently over time.
During incident response, engineers make quick CLI fixes that restore service but never get reflected in the SoT. Vendor technicians apply workarounds during maintenance windows. Software upgrades reset parameters to defaults. New devices are provisioned from templates but field configurations diverge during commissioning. Each undocumented change widens the gap between what the CMDB says and what the network actually does.
This gap creates real operational risk. Automation pipelines that consume SoT data assume the model is current. When it is not, provisioning workflows push incorrect configurations. Compliance reports based on documented standards miss violations that exist only on the device. Incident investigations start from an inaccurate inventory because devices were added outside the formal onboarding process.
Closing this gap manually does not scale. A team managing 2,000 devices cannot reconcile SoT records against live configurations through periodic audits. The reconciliation must be continuous, automated, and independent of the documentation system itself.
- Incident fixes applied directly on devices rarely flow back into the SoT
- Running configurations diverge from startup configurations without anyone noticing
- Compliance validation requires reading actual device configs, not documented intent
- Drift between peer devices goes undetected when only the model is maintained
- Audit evidence must come from live configuration snapshots, not CMDB records
- Multi-vendor estates need unified operational visibility that a data model alone cannot provide
Intended state vs actual state
The distinction between intended and actual network state is fundamental to understanding why SoT platforms and operational intelligence platforms coexist rather than compete.
Intended state lives in your Source of Truth: device roles, site assignments, IP allocations, VLAN definitions, and the relationships that describe how your network is designed to operate. It represents engineering decisions, architectural standards, and provisioning templates.
Actual state lives on the devices themselves: the running configuration in memory, the ACLs that were added during last month's outage, the SNMP community string that a contractor changed, the routing policy that drifted after a partial rollback. It represents what the network is doing right now — including every undocumented deviation from design.
Most network problems trace back to a mismatch between these two states. A firewall rule documented in the SoT was never applied to the device. A switch was reconfigured during troubleshooting but the change was never saved to startup config. A router's peer group was updated on nine of ten devices, leaving one outlier that causes intermittent failures.
Detecting and managing this mismatch requires direct interaction with device configurations — not just maintaining a data model. It requires automated backup collection, configuration parsing, policy validation, diff comparison, and drift alerting at a scale that manual processes cannot sustain.
What an operational intelligence layer provides
An operational intelligence platform like Orion sits alongside your Source of Truth and continuously validates the actual state of your network against defined standards, baselines, and policies.
Configuration backup is the foundation. Orion collects running and startup configurations from every managed device on a defined schedule — across Cisco, Arista, Juniper, MikroTik, and other supported platforms. Each backup is timestamped, versioned, and stored in a centralized repository with access controls.
Compliance validation runs against those live configurations. Policies are defined once — in vendor-neutral terms — and applied uniformly across the entire estate. Violations surface with severity ratings and remediation guidance, not during quarterly audits but on the schedule you define: daily, weekly, or after every detected change.
Drift detection compares current configurations against golden baselines, peer groups, or policy requirements. Devices that deviate receive alerts before the deviation spreads. Configuration diffs between any two points in time compress incident investigation from hours to minutes.
Pre-change and post-change validation integrates with your change management process. Before a maintenance window, Orion captures the baseline. After the change, it confirms the outcome matches intent and flags anything unintended — while engineers are still in the window and rollback is still practical.
This is not a replacement for Nautobot's data model. It is the operational layer that keeps your automation honest by continuously verifying that reality matches documentation.
Side-by-side: different tools, different jobs
Comparing Nautobot and Orion directly is only useful when you understand they solve different problems. The table below maps common network automation capabilities to where each platform focuses.
- Network inventory and data modeling: Nautobot — structured CMDB with extensible data model, custom fields, and relationships
- Live configuration backup: Orion — automated multi-vendor collection with version history and diff comparison
- Compliance validation against live configs: Orion — continuous policy scanning with severity ratings and audit-ready reports
- Configuration drift detection: Orion — automated comparison against baselines, peers, and golden templates
- IPAM and circuit management: Nautobot — native IPAM, VLAN, circuit, and tenancy models with API access
- Pre-change and post-change validation: Orion — automated baseline capture, diff analysis, and rollback readiness
- Plugin ecosystem and custom models: Nautobot — Django-based extensibility with a growing community plugin library
- Multi-vendor automation workflows: Orion — unified workflows across Cisco, Arista, Juniper, MikroTik without per-vendor scripting
- REST API and GraphQL for automation pipelines: Both — Nautobot for data model access, Orion for operational state and compliance data
- Device discovery and onboarding: Both — Nautobot for inventory population, Orion for configuration collection and baseline establishment
When Nautobot alone is enough
Not every organization needs an operational intelligence layer on day one. Nautobot alone may be sufficient when certain conditions apply.
Small to mid-size networks with strong change management discipline can maintain SoT accuracy through process rather than automation. If every configuration change flows through formal workflows and is reflected in the data model within hours, the intended-vs-actual gap stays manageable.
Teams with mature NetDevOps practices and dedicated engineering capacity may prefer building operational capabilities as custom Nautobot jobs, Ansible playbooks, or integrated scripts. This approach works when the team has time to maintain those integrations and the network estate is homogeneous enough that vendor-specific logic does not multiply complexity.
Organizations in early automation maturity stages benefit from establishing a Source of Truth first. Modeling your network accurately is a prerequisite for every downstream automation initiative. Attempting compliance validation or drift detection before you have reliable inventory creates false results.
If your primary need is documentation, inventory management, and data-driven provisioning — and your team accepts the engineering investment to build operational workflows on top — Nautobot provides an excellent foundation without additional platforms.
When you need operational intelligence
Certain conditions make an operational intelligence layer not just useful but essential.
Large multi-vendor estates where manual configuration review is impractical. When your network spans thousands of devices across Cisco, Arista, Juniper, and MikroTik platforms, periodic manual audits cannot maintain visibility. Continuous automated validation is the only approach that scales.
Regulated industries with continuous compliance requirements. PCI DSS, HIPAA, NIST, and SOC 2 demand evidence that network configurations meet defined standards — not quarterly, but continuously. Generating audit-ready reports from live device configurations requires a platform built for that purpose.
Organizations experiencing recurring incidents rooted in configuration drift. If post-mortems consistently reveal undocumented changes, partial rollbacks, or devices operating outside baseline, the problem is operational visibility — not data modeling.
Teams preparing for or recovering from failed automation projects. Many automation initiatives stall because they assume the SoT is accurate. An operational layer validates assumptions before automation pipelines act on them — preventing the cascading failures that give network automation a bad reputation.
Change-heavy environments where pre-change and post-change validation must be embedded in every maintenance window. When the cost of a failed change exceeds the cost of validation, automated baseline capture and diff analysis become operational requirements rather than nice-to-haves.
Building a complete automation stack
The most effective network automation architectures use both layers deliberately — not as competing alternatives but as complementary components of a unified stack.
Nautobot maintains the authoritative model: what devices exist, where they are located, how they are classified, and what relationships connect them. Custom plugins extend this model with organization-specific data — such as function codes for device classification, lifecycle states, or operational metadata that drives automation decisions.
Orion maintains operational truth: what configurations are actually running, whether they comply with defined policies, how they have changed over time, and whether they match expected baselines. It provides the continuous verification loop that keeps automation pipelines trustworthy.
Together, they answer the complete question. Nautobot tells your provisioning workflow which device to configure and what role it plays. Orion confirms the configuration was applied correctly, remains compliant, and has not drifted since deployment. When drift occurs, Orion detects it. When the SoT needs updating, the detection triggers a reconciliation workflow.
At Hibulla, we build for both layers. Our open-source Nautobot plugins — such as the Function Codes plugin for device classification — extend the Source of Truth with reusable operational metadata. Orion provides the operational intelligence layer that validates, monitors, and reports on the actual state of multi-vendor estates at enterprise scale.
The goal is not to choose between Nautobot and Orion. It is to recognize that Source of Truth and operational intelligence serve different purposes — and that enterprise network teams need both to automate with confidence.