Predictika · Network change validator

An AI network agent, checked before anything touches a device

An AI agent proposes a change ticket: one or more commands against real devices. Before any command is pushed, the ticket goes to Predictika's validator, which checks every command, and the batch as a whole, against the network's topology, governance policy and change windows. It reports every problem it finds in one pass.

Scope: batches of proposed network commands (drain, route withdrawal, BGP session change, interface, VLAN, ACL) checked against the network's own topology, change policy, approvals and change windows. See everything this validator covers

This validator checks a change ticket from an AI agent or an engineer: one or more proposed commands of these types: device drain, route withdrawal, BGP session change, interface change, VLAN change and ACL change. It checks the batch against the network's own topology data (device capacity, management paths, the services that run on each device and the BGP sessions), the change policy, the approvals on the ticket, and its maintenance and freeze windows. It does not compute network paths itself (facts such as “traverses the firewall” come from a dedicated verification tool and arrive with the request), it does not validate device configuration syntax, and it does not push changes.

  • Capacity and blast radius — backbone capacity left after drains against peak demand and the headroom policy, devices that would lose their management path, and customer-facing services that depend on the drained devices.
  • Approvals — change-board authorization by scope, route-withdrawal size and customer services affected, and an independent approver: nobody approves their own change.
  • BGP paths — sessions shut that would leave a customer prefix group with no path.
  • ACL, segmentation and VLAN policy — forbidden ACL patterns, rules that an earlier rule would shadow, cross-segment paths that must traverse a firewall, and reserved VLAN ranges.
  • Redundancy, change velocity and rollback — both halves of a redundant pair in one batch, the backbone change budget per window, and a staged rollback for backbone-wide changes.
  • Maintenance and freeze windows — backbone-tier timing requirements, and freezes that no approval tier can override.

It applies to any change ticket made of these command types against this network's devices, in any combination, not just the nine scenarios shown here.

The change ticketCommands the agent wants to run, plus the approval the ticket already carries.
The AI network agentPlans the change and explains why it thinks the ticket is ready to push.
Predictika validatorChecks every command and the batch as a whole, and returns every violation with the rule behind it.

9 scenarios in 6 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

Context the validator resolved or was given

    The agent says

    Before pushing, the agent must call Recorded run

    Predictika validator

    
      
    
        
        
        
      
    
      
    Waiting for the call.
    
      
    
    
  
    

  

  
    Where a change-approval workflow gets it wrong
    Click to expand
    General statements about how such workflows are commonly built, not about any named product. This is our general characterization; we have not tested any specific product.
    ScenarioTypical change-approval workflowPredictika validator
    Draining two backbone routers on engineer approval, with no maintenance windowOnly with workarounds
    A change-approval workflow checks the approval, window and rollback fields on the ticket. How much backbone capacity is left, which devices lose their way in, and how many customer services depend on the drained routers come from the network's topology, so each has to be wired in as a custom check that someone keeps in step with the network.    		The validator reads the topology and the policy together on every call, and returns the capacity left, the device cut off, the services affected and the missing window in one answer.
    A device that is managed through a router the same ticket takes offlineOnly with workarounds
    The ticket names the devices it touches, not the devices that depend on them. Finding the device that would be left unreachable, and unable to be rolled back, needs a custom topology check that the team writes and keeps current.    		The validator follows each device's management path from the network's own data and flags a device that is not in the ticket but would lose its way in.
    A BGP session shut that leaves a customer prefix group with no pathOnly with workarounds
    The workflow sees a session change on a router. Counting the sessions that stay up for each prefix group after the whole ticket, and ignoring sessions that are already down, takes a custom check against the live session list.    		The validator counts the sessions left up for each prefix group after the whole ticket, and states how many the group needs.
    The AI agent that raised the ticket also approving itError-prone
    Approval is usually checked as a tier. Whether the approver is the requester depends on someone checking identities, not only the tier on the ticket.    		The validator compares the approver with the requester on every ticket, whatever the approval tier.
    A change inside a holiday freeze, even with change-board approvalError-prone
    A workflow treats approval as the answer. A freeze that no approval can override is an exception someone has to remember and apply to every ticket.    		The validator checks blackout windows on every call, and no approval level overrides one.
    

  
    
    
    What this validator catches
    Click to expand    
    
    Every rule reports a message and never stops evaluation, so one bad command cannot hide another. Rules marked "whole ticket" reason across the whole batch, not one command at a time.