Change Requests & Approvals Center
Relevant source files
The following files were used as context for generating this wiki page:
Overview
The Change Requests & Approvals Center is the primary safeguard for your network, ensuring that no AI-generated configuration or DDI change is ever executed without explicit human verification. It acts like a "peer review" system for network automation: while specialized AI team members (agents) can draft complex changes to firewall policies, DNS records, or router configurations, they are structurally forbidden from applying those changes directly to your hardware. Sources: CLAUDE.md:27, README.md:10
Every proposed modification is funneled into a central "Change Request" (CR) queue. This system enforces a four-eyes principle, meaning the engineer who requests or triggers a change cannot be the same person who approves it. This provides a critical audit trail and prevents accidental or malicious misconfigurations from reaching production environments. Sources: frontend/src/tests/ChangesPage.test.tsx:162-178, backend/app/agents/security/agent.py:23-28
The platform supports a wide array of vendor families including Cisco (IOS, IOS-XE, NX-OS), Juniper, Arista, Palo Alto, Fortinet, F5, and DDI backends like Infoblox and BlueCat. Sources: README.md:19-21, CLAUDE.md:14-27
Architecture and Components
The system relies on several backend and frontend components to manage the lifecycle of a change. Sources: README.md:26-34
- Frontend (React/TypeScript): The Ops console where engineers view the pending queue, review the "intent" or diff of a change, and provide approval or rejection comments. Sources: frontend/src/tests/ChangesPage.test.tsx:11-15
- API (FastAPI): Manages the state of change requests, enforces RBAC (Role-Based Access Control), and ensures the four-eyes logic is applied before a CR moves to execution. Sources: deploy/docker/README.md:9
- Postgres (Database): Acts as the system of record, storing every change request, its status, the requester, the approver, and the exact configuration "intent" being proposed. Sources: README.md:30
- Worker (Celery): The background engine that handles the actual execution of changes after they have been approved. Sources: deploy/docker/README.md:10
Specialized Agent Integration
Specialized "specialists" on the team do not have "write" access to your devices. Instead, they use a "Change Request Gate" to propose modifications. Sources: backend/app/agents/ddi/agent.py:16-24
| Specialist | Role in Changes | Data/Intent Example |
|---|---|---|
| DDI Agent | Drafts DNS/DHCP changes. | Adding an A record for web-07.example.com. |
| Security Agent | Proposes firewall remediations. | Disabling a shadowed or overly-permissive rule. |
| Configuration Agent | Drafts device config updates. | Updating OSPF timers or interface descriptions. |
| Automation Agent | Executioner only. | Triggers the actual CLI commands for approved CRs. |
Sources: backend/app/agents/ddi/agent.py:46-51, backend/app/agents/security/agent.py:48-52, backend/app/llm/prompts/init.py:186-190
Change Approval Workflow
The workflow ensures a strict progression from an engineer's initial request to the final deployment on the network. A pre-change configuration backup is always taken before execution to ensure a rollback path exists.
Workflow States
- Draft / Pending Approval: The change is created by an agent or engineer but is not yet authorized.
- Approved: A second human has reviewed the intent and authorized the change.
- Executing: The Automation Agent is pushing the configuration to the target devices.
- Completed / Rolled Back: The change successfully finished, or failed and was reverted to the pre-change backup.
Sources: frontend/src/api/changes.ts:28-36, README.md:38-39
The Four-Eyes Principle
The platform prevents self-approval at the UI and API levels. If an engineer attempts to approve their own request, the system surfaces a "Forbidden" error, requiring a different authorized user to sign off. Sources: frontend/src/tests/ChangesPage.test.tsx:162-178, frontend/src/tests/ChangesPage.test.tsx:191-198
The diagram above shows the lifecycle of a network change from the initial request through the mandatory peer-approval gate to execution or rollback.
System Interaction Diagram
This diagram represents how a user interaction flows through the specialist agents to reach the approval gate.
The sequence shows the "Master Architect" routing a request to the "DDI Agent," which then uses the "Approval Gate" to record the intent in the database rather than making a direct change. Sources: backend/app/llm/prompts/init.py:133-145, backend/app/agents/ddi/agent.py:16-24
Data Model: Change Request
The system stores specific details about every request to provide full visibility to the approver.
| Field | Description |
|---|---|
| ID | Unique identifier (e.g., CR-1009). |
| Kind | The type of change (e.g., config, ddi_record, security_remediation). |
| State | Current status (pending_approval, approved, executing, etc.). |
| Target Refs | Specific network objects affected (Device IDs, DNS Zone, Rule Name). |
| Intent Preview | A text-based summary of what the AI plans to do. |
| Reasoning Trace | Link to the AI's explanation of why this change is necessary. |
Sources: frontend/src/api/changes.ts:18-36, frontend/src/tests/ChangesPage.test.tsx:206-218
Summary
The Change Requests & Approvals Center is the cornerstone of the platform's "human-in-the-loop" philosophy. By decoupling the drafting of network changes from their execution, the platform enables high-speed AI assistance without sacrificing the safety and compliance standards required by enterprise network operations teams. Every decision is explainable, every change is audited, and every deployment is authorized by a human professional. Sources: CLAUDE.md:27-30, README.md:1-5