Diagram: Change Approval Lifecycle
Relevant source files
The following files were used as context for generating this wiki page:
The Change Approval Lifecycle is the core safety mechanism of the AI Network Operations Platform, ensuring that no AI-driven or engineer-requested modification to the network occurs without human verification. It functions like a "Two-Man Rule" for network infrastructure, where one person (or the AI) drafts a change and a second human must sign off before any packets are moved or configurations are pushed.
This system provides a standardized "write spine" (a single, secure path for all changes) across diverse vendors including Cisco, Juniper, Arista, and Palo Alto. By moving through a defined set of states—from a technical draft to a verified execution—the platform prevents unauthorized changes, maintains a perfect audit trail, and ensures that the "blast radius" of any automated action is always reviewed by a senior engineer.
Sources: README.md, backend/app/agents/ddi/agent.py, backend/tests/agents/eval/test_m5_exit_criteria.py:81-95
Overview
The platform acts as an AI Network Engineer that handles complex tasks like troubleshooting, DDI (DNS/DHCP/IPAM) management, and packet analysis across multi-vendor environments. To maintain security in these critical environments, the platform follows a strict "local-first" and "human-in-the-loop" philosophy.
Key aspects of the platform's design include:
- Specialized Agents: Specialized "team members" or agents (such as the DDI Agent, Troubleshooting Agent, or Security Agent) handle specific domains.
- The Change Request Spine: Every request to ADD, MODIFY, or DELETE network state (like a DNS record or a firewall policy) is intercepted by an "Approval Gate."
- Audit Everything: Every decision made by the AI and every action taken by a human is logged in a permanent audit chain.
- Supported Vendors: The platform normalizes interactions with Cisco (IOS, IOS-XE, NX-OS), Juniper, Arista, Palo Alto, Fortinet, F5, BlueCat, Infoblox, AWS, Azure, and VMware into a consistent format.
Sources: CLAUDE.md, backend/app/agents/ddi/agent.py, README.md
Platform Architecture
The platform is composed of seven primary components that work together to manage the network and facilitate the change lifecycle:
| Component | Purpose (Plain English) |
|---|---|
| frontend | The operations console where you chat with the AI, view the topology map, and approve changes. |
| api | The central brain that handles requests, checks permissions, and manages agent sessions. |
| worker | The background engine that runs discovery jobs, takes config backups, and captures packets without blocking your session. |
| postgres | The system of record that stores all permanent data, including your inventory, audit logs, and change requests. |
| neo4j | A living topology map that tracks how every device, interface, subnet, DNS zone, and application connects to everything else. |
| redis | A high-speed messenger used by the worker engine to coordinate tasks and cache information. |
| ollama | An optional component that runs the AI models (LLMs) locally on your own hardware for maximum privacy. |
Deployment Options
- Docker Compose: Ideal for lab environments or small teams. It runs the entire platform on a single server using a few simple commands.
- Kubernetes (Helm): Designed for production, multi-node environments. It provides high availability and advanced security hardening, such as network isolation and signed-image verification.
Sources: README.md, deploy/docker/README.md, deploy/kubernetes/netops/README.md
Agent Routing and Change Drafting
When you send a request to the platform, it is first evaluated by the Master Architect Agent. This agent determines which specialist is best suited to handle the task.
The diagram above shows how the Master Architect routes a user request to specialized agents. Read-only tasks (like checking a route) happen immediately, while write tasks (like adding a DNS record) are forced through an Approval Gate.
Sources: backend/app/agents/ddi/agent.py, backend/app/agents/security/agent.py, backend/app/agents/consultant/agent.py
The Change Approval Flow
The lifecycle of a change request is a strictly defined transition through several states. Each state ensures that the change is documented, reviewed, and executed safely.
1. The Draft Phase
When a specialist agent (like the DDI Agent) identifies a needed change, it calls a tool that is intercepted by the ChangeRequestGate. This creates a DRAFT entry in the database. Crucially, the AI "redacts" or hides sensitive information like SNMP community strings or passwords from the AI's reasoning process while keeping the actual technical payload intact for the final execution.
2. Approval and Verification
Once drafted, the change moves to PENDING_APPROVAL. A second human (following the Four-Eyes Principle) must review the change. The platform prohibits "self-approval"—the person who requested the change cannot be the one to approve it.
3. Execution and Rollback
Only the Automation Agent is permitted to execute an APPROVED change. Before any configuration is pushed, the Worker component takes a pre-change backup (baseline). If the change fails or verification doesn't match the expected result, the platform automatically triggers a rollback to the baseline configuration.
This diagram illustrates the lifecycle of a network change from the initial request to final completion or rollback, highlighting the safety controls at each step.
Sources: backend/tests/agents/eval/test_m5_exit_criteria.py:81-150, backend/app/agents/framework/approval.py, backend/app/agents/automation/agent.py
Data Relationships (Topology Model)
The platform maintains a detailed "topology map" in Neo4j that understands the relationships between different network entities. This allows the AI to understand how a change to a DNS record might affect an application.
| Entity | Relationship | Connects To | Description |
|---|---|---|---|
| Device | HAS_INTERFACE | Interface | Physical or virtual routers/switches. |
| Interface | IN_SUBNET | Subnet | Logical port on a device. |
| Subnet | HAS_VLAN | VLAN | IP address ranges and local segments. |
| DNS Record | RESOLVES_TO | Device/IP | Maps hostnames to infrastructure. |
| Application | DEPENDS_ON | Service/Device | High-level business apps mapped to hardware. |
Sources: README.md, backend/tests/agents/eval/test_m5_exit_criteria.py:465-495, CLAUDE.md
Summary
The Change Approval Lifecycle ensures that the AI Network Operations Platform remains "enterprise-ready" by enforcing human oversight on every network modification. By combining automated drafting with the mandatory "Four-Eyes" approval process and automated rollback capabilities, the platform allows network teams to use AI safely without losing control over their infrastructure. This structured "write spine" ensures that whether you are changing a Cisco BGP neighbor or an Infoblox DNS record, the process is consistent, audited, and secure.