Predictika · AI back-end Ethernet fabric
An AI change agent proposes RoCE and interface changes to an AI back-end Ethernet fabric. Before anything is pushed, the agent sends the change ticket to Predictika, which checks the RoCE settings against the public Arista and Broadcom deployment guide and the ticket against the operator's own change policy, and returns a verdict and every reason. Nothing here touches a real device.
Source and independence. The RoCE rules come from the public Arista and Broadcom AI Networking Deployment Guide. Its PFC priority, DSCP values and ECN thresholds are examples and defaults for Broadcom NICs, so a different value is sent to a person for approval rather than blocked. The change policy is a fictional customer's, supplied as data: redundant pairs, a limit of three spine-tier changes per window, maintenance windows, a year-end freeze, change-board scope and staged rollback. It is not an Arista or Broadcom rule. The device inventory, the state of the other end of each link, the changes already made in the window, and the windows that apply at the change time are inputs from the customer's own systems. Arista and Broadcom are not involved in this demonstration and have not endorsed it.
This validator handles any change ticket of these kinds for a fabric whose devices and policy are loaded — not just the scenarios shown below. Every command in a ticket is checked independently, and one problem never hides another.
Not covered: device state (the validator does not read switches or NICs), fabric design and optics (see the Etherlink fabric order validator), and rules of other vendors' NICs. The thresholds and priorities in the guide are examples; this validator does not claim they are the right values for any particular fabric.
7 scenarios in 3 groups · each group runs from the agent’s first attempt to the outcome · click one to switch
Illustrative agent statement. The validator receives the structured request below.
Proposing agent: AI sales agent (scripted)
Before sending, the agent must call Recorded run
What this means
Our assessment of what a typical rules-based CPQ or change tool does with the same cases. It is a judgment about effort and reliability, not a claim that nothing can be built.
| What the validator caught | Typical rules-based CPQ | Predictika |
|---|---|---|
| PFC turned on at one end of a link | Only with workarounds Needs the state of the other end of the link as a field and a rule that compares the two ends; most CPQ and change tools check one object at a time. | The other end's state travels with the command and the two are compared on every call. |
| Both halves of a redundant pair in the same ticket | Only with workarounds A rule over the whole batch, not over one line. Usually built as a custom script outside the rules engine. | Every command sees the whole ticket, so each half names its partner. |
| ECN minimum above maximum | Only with care A simple cross-field check, reliable when both fields are on the same line and validated before approval. | Checked with all the other RoCE values together in the same call. |
| Example values from a vendor guide treated as hard policy | Only with workarounds A rule has to be either a block or nothing; routing a deviation to a person needs a separate approval path. | A deviation from the guide's examples becomes a needs-approval finding with the reason. |
| Spine-tier changes counted across the window and the ticket | Only with workarounds Needs an aggregate over history plus the new lines, usually done in code. | The count so far comes with the ticket and is added to the ticket's own spine-tier commands. |
| A change during a freeze window | Only with care A date rule; reliable if the freeze calendar is kept in the same system as the ticket. | The window that applies at the change time is data, and a freeze blocks regardless of approval tier. |
Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the ticket; approval findings need a person to sign off. These are the findings the 28 test cases produced.
| 1 | Command cmd-01 turns PFC on at leaf-01, but the other end of the link has PFC off; priority flow control is a link-layer mechanism between directly connected peers and must match on both ends. |
| 2 | Command cmd-01 sets the ECN minimum threshold to 1,500 kbytes, above the maximum of 500 kbytes; marking starts at the minimum and reaches 100 percent at the maximum. |
| 3 | Command cmd-02 targets leaf-02, whose redundant partner (leaf-01) is also targeted elsewhere in this same ticket. |
| 4 | Command cmd-01 targets leaf-01, whose redundant partner (leaf-02) is also targeted elsewhere in this same ticket. |
| 5 | Command cmd-01 is proposed during freeze window year-end-freeze (Year-end change freeze -- no changes permitted fabric-wide); no approval tier can override a freeze window. |
| 6 | Command cmd-01 sets ECN thresholds of 400 to 1,200 kbytes at 30 percent; the deployment guide gives 500 to 1,500 kbytes at 25 percent and 256 to 256 kbytes at 100 percent as examples, not fixed values. A person must confirm these against the NICs and buffer sizing. |
| 7 | Command cmd-01 targets a spine-tier device with no active approved maintenance window. |
| 8 | Command cmd-01 has fabric-wide scope, which the change policy sends to the change board; the ticket's current approval tier is engineer. |
| 9 | Command cmd-01 has fabric-wide scope with no staged rollback reference; stage a rollback before proceeding. |
| 10 | This ticket would bring spine-tier changes to 4 within the policy window, exceeding the limit of 3. |
| 11 | Command cmd-01 makes priority 4 no-drop; the deployment guide enables PFC for priority 3, the default RoCE priority of Broadcom NICs. Another priority is possible only if the NICs are changed to match; a person must confirm. |
| 12 | Command cmd-01 marks RoCE traffic with DSCP 24; the deployment guide uses DSCP 26 (priority 3), the Broadcom NIC default. The switches and the NICs must agree, so a person must confirm. |
| 13 | Command cmd-01 marks congestion notification packets with DSCP 46; the deployment guide uses DSCP 48 (priority 7), the Broadcom NIC default. The switches and the NICs must agree, so a person must confirm. |
| 14 | Command cmd-01 sets the ECN maximum marking probability to 120 percent; a probability cannot exceed 100 percent. |
| 15 | Ai-fabric-9 does not match any network. Command aborted |
| 16 | Chg-9999 does not match any change ticket. Command aborted |
| 17 | Command cmd-01 makes priority 5 no-drop; the deployment guide enables PFC for priority 3, the default RoCE priority of Broadcom NICs. Another priority is possible only if the NICs are changed to match; a person must confirm. |
The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.
The agent's request. Please apply the RoCE settings to leaf-01 and leaf-02 in ai-fabric-1 under ticket chg-7001. On leaf-01: turn on priority flow control for priority 5, RoCE DSCP 26 and CNP DSCP 48, and set ECN thresholds of 1,500 kbytes minimum and 500 kbytes maximum at 25 percent. The spine-01 end of that link is not part of this ticket. On leaf-02: turn on priority flow control for priority 3, RoCE DSCP 26 and CNP DSCP 48, and set ECN thresholds of 500 to 1,500 kbytes at 25 percent, with PFC already on at the other end of the link. Both switches are in the standing leaf window. It is ready to apply.
Verdict: Blocked.
The agent's request. Please apply the RoCE settings to leaf-01 and leaf-03 in ai-fabric-1 under ticket chg-7001. On leaf-01: turn on priority flow control for priority 5, RoCE DSCP 26 and CNP DSCP 48, and set ECN thresholds of 400 kbytes minimum and 1,200 kbytes maximum at 30 percent, with PFC already on at the other end of that link. On leaf-03: turn on priority flow control for priority 3, RoCE DSCP 26 and CNP DSCP 48, and set ECN thresholds of 500 to 1,500 kbytes at 25 percent, with PFC already on at the other end of the link. Both switches are in the standing leaf window. It is ready to apply.
Verdict: Needs approval.
The agent's request. Please apply the same RoCE settings to leaf-01 and leaf-03 in ai-fabric-1 under ticket chg-7001: turn on priority flow control for priority 3, RoCE DSCP 26 and CNP DSCP 48, and set ECN thresholds of 500 to 1,500 kbytes at 25 percent, with PFC already on at the other end of each link. Both switches are in the standing leaf window. It is ready to apply.
Verdict: Allowed.
The agent's request. Please apply the RoCE settings for the leaf-01 uplink in ai-fabric-1 under ticket chg-7001: turn on priority flow control for priority 3, RoCE DSCP 26 and CNP DSCP 48, and set ECN thresholds of 500 to 1,500 kbytes at 25 percent. The spine-01 end of that link is not part of this ticket. It is ready to apply.
Verdict: Blocked.
The agent's request. Please apply the RoCE settings for the leaf-01 uplink and the matching spine-01 port in ai-fabric-1 under ticket chg-7001: turn on priority flow control at both ends for priority 3, RoCE DSCP 26 and CNP DSCP 48, and set ECN thresholds of 500 to 1,500 kbytes at 25 percent on both. The spine-01 change is scheduled in the weekly spine window, and the change system already shows one spine-tier change this window. It is ready to apply.
Verdict: Allowed.
The agent's request. Please apply the RoCE settings for leaf-03, scheduled for December 20, 2026 in ai-fabric-1 under ticket chg-7001: turn on priority flow control for priority 3, RoCE DSCP 26 and CNP DSCP 48, and set ECN thresholds of 500 to 1,500 kbytes at 25 percent. PFC is already on at the other end of that link. It is ready to apply.
Verdict: Blocked.
The agent's request. Please apply the RoCE settings for leaf-03, rescheduled for December 16, 2026 in ai-fabric-1 under ticket chg-7001: turn on priority flow control for priority 3, RoCE DSCP 26 and CNP DSCP 48, and set ECN thresholds of 500 to 1,500 kbytes at 25 percent. PFC is already on at the other end of that link. It is ready to apply.
Verdict: Allowed.
The text of the narrated walkthrough, step by step.