Predictika · AI back-end Ethernet fabric

An AI agent's fabric change ticket, checked before it reaches a switch

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.

Scope: change tickets for an AI back-end Ethernet fabric: RoCE settings (PFC, DSCP, ECN) and the change policy around them. See everything this validator covers

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.

  • PFC — PFC must match at both ends of a link; a no-drop priority other than 3 needs approval.
  • DSCP — RoCE DSCP other than 26 and CNP DSCP other than 48 need approval, because switches and NICs must agree.
  • ECN — the minimum threshold may not exceed the maximum; the marking probability may not exceed 100 percent; thresholds other than the guide's two examples need approval.
  • Redundant pairs — both halves of a pair may not be changed in the same ticket.
  • Change velocity — the spine-tier changes already made plus those in the ticket may not exceed the policy limit.
  • Windows — a spine-tier change needs an active maintenance window; nothing may be changed during a freeze window.
  • Scope and rollback — a fabric-wide change needs change-board approval and a staged rollback reference.

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.

The AI change agentBuilds the change ticket and says it is ready to apply.
Predictika validatorChecks every rule at once and returns the verdict and each finding.

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

What the agent proposes

The AI sales agent says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: AI sales agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      
Waiting for the call.

Where rules-based CPQ gets it wrong

Click to expand

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 caughtTypical rules-based CPQPredictika
PFC turned on at one end of a linkOnly 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 ticketOnly 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 maximumOnly 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 policyOnly 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 ticketOnly 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 windowOnly 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.

What this validator catches: findings from its test cases

Click to expand

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.

1Command 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.
2Command 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.
3Command cmd-02 targets leaf-02, whose redundant partner (leaf-01) is also targeted elsewhere in this same ticket.
4Command cmd-01 targets leaf-01, whose redundant partner (leaf-02) is also targeted elsewhere in this same ticket.
5Command 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.
6Command 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.
7Command cmd-01 targets a spine-tier device with no active approved maintenance window.
8Command cmd-01 has fabric-wide scope, which the change policy sends to the change board; the ticket's current approval tier is engineer.
9Command cmd-01 has fabric-wide scope with no staged rollback reference; stage a rollback before proceeding.
10This ticket would bring spine-tier changes to 4 within the policy window, exceeding the limit of 3.
11Command 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.
12Command 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.
13Command 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.
14Command cmd-01 sets the ECN maximum marking probability to 120 percent; a probability cannot exceed 100 percent.
15Ai-fabric-9 does not match any network. Command aborted
16Chg-9999 does not match any change ticket. Command aborted
17Command 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.

Scenarios and results

Click to expand

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.

1. Several problems in one ticket: Two leaves, PFC on at one end, reversed ECN thresholds, priority 5

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.

  • Both halves of a redundant pair in one ticket (leaf-02). Command cmd-02 targets leaf-02, whose redundant partner (leaf-01) is also targeted elsewhere in this same ticket.
  • Both halves of a redundant pair in one ticket (leaf-01). Command cmd-01 targets leaf-01, whose redundant partner (leaf-02) is also targeted elsewhere in this same ticket.
  • PFC on one end of the link only. 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.
  • ECN minimum above maximum. 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.
  • PFC priority differs from the guide. 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.

2. Several problems in one ticket: The agent resubmits after fixing the errors

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.

  • PFC priority differs from the guide. 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.
  • ECN thresholds differ from the guide examples. 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.

3. Several problems in one ticket: The agent resubmits after fixing the errors

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.

4. PFC on both ends of the link: PFC on at the leaf only

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.

  • PFC on one end of the link only. 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.

5. PFC on both ends of the link: The agent resubmits after fixing the errors

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.

6. A change during the year-end freeze: Scheduled for December 20

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.

  • Change during a freeze window. 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.

7. A change during the year-end freeze: The agent resubmits after fixing the errors

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.

Narration transcript

Click to expand

The text of the narrated walkthrough, step by step.

  1. Welcome to a demo of Predictika's Validator. 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.
  2. I will start with the first request by the agent.
  3. The agent says. 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 rest of the request is on screen.
  4. Before it goes out, the agent calls the validator.
  5. Blocked, with four findings and one approval, all in one answer. Command cmd-02 targets leaf-02, whose redundant partner (leaf-01) is also targeted elsewhere in this same ticket. Command cmd-01 targets leaf-01, whose redundant partner (leaf-02) is also targeted elsewhere in this same ticket. 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. The other one is on screen.
  6. The validator returned four blocking findings and one approval in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the change are checked against each other.
  7. What this shows: for both halves of a redundant pair in the same ticket, a rules-based CPQ can do this only with workarounds.
  8. Now the agent resubmits.
  9. The corrected request. It changes the command 1: PFC at the other end to on, the command 1: ECN minimum to 400 kbytes, the command 1: ECN maximum to 1,200 kbytes, the command 1: ECN max mark probability to 30 percent and the command 2: Device to leaf-03.
  10. It calls the validator again.
  11. Not blocked, but held for a person.
  12. The four blocking findings are cleared; two approvals remain for a person: PFC priority differs from the guide and ECN thresholds differ from the guide examples.
  13. The agent resubmits once more.
  14. The revised request. It changes the command 1: PFC no-drop traffic class to 3, the command 1: ECN minimum to 500 kbytes, the command 1: ECN maximum to 1,500 kbytes and the command 1: ECN max mark probability to 25 percent.
  15. It calls the validator once more.
  16. This time the validator clears it.
  17. Both earlier findings are cleared.
  18. Five problems caught in one call, fixed in two passes, and a clean change. That is the value of Predictika's validator: catching mistakes before they reach production.