Predictika · ServiceNow IT operations · Calderwood Logistics

An AI agent's ServiceNow action, checked before it is written to the record

Calderwood Logistics runs IT operations on ServiceNow and lets an IT operations agent work its change requests, incidents and access requests. The agent prepares an action on a ticket and says it is ready. Before it goes out, the agent sends it to Predictika's validator, which checks it against Calderwood's change, incident and access rules, computes the risk, priority and SLA figures, and reports every problem it finds in one pass.

Scope: ServiceNow change requests (standard, normal and emergency), incidents and access requests handled by an AI agent: 41 rules covering change risk and approval routing, maintenance windows and collisions, CMDB blast radius, incident priority, SLA, holds, resolution and reassignment, and access governance. CMDB context is loaded from an extract. See everything this validator covers

This validator checks the process around an AI agent's action on three ServiceNow record types. It does not judge whether the technical change itself is correct.

  • Change requests — change type and Change Model (and whether a standard model fits the CI), a risk score and level with the approval route it requires (pre-approved, change manager, CAB or Emergency CAB), maintenance windows and freezes, collisions with a change already booked on the CI or a related CI, CMDB criticality and blast radius against what the agent may change alone, HA pairs, backout plan, test evidence and notice, and database ports opened to the internet.
  • Incidents — priority from impact and urgency and when an agent may override it, SLA targets and time remaining, state transitions, hold reasons, resolution code and notes, open tasks and open related changes that block resolution, assignment group coverage and repeated reassignment, and P1 major incidents, which stay with a person.
  • Access requests — segregation of duties, time-bound grants, clearance level, active-employee and contract-term checks, independent approval (no self-approval, the right approver for the role), and privileged roles routed to a person.
  • Every action — the agent may work only the ticket assigned to it, while it is open, with an action that fits the ticket type and the agent's permissions.

Any change request, incident action or access request an agent proposes, on any CI, ticket, group or role, is checked against this same set of rules, not only the scenarios pictured here. Not covered in this version: change closure and post-implementation review, service catalog item fulfillment, and problem and knowledge management. The CMDB context (blast radius, booked change windows, recent failures) is taken from an extract loaded with the validator, not looked up live in ServiceNow, and the facts the caller states are taken as given.

The IT operations agentPrepares an action on a ServiceNow ticket and says it is ready.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

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

What the agent proposes

The IT operations agent says

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

Proposing agent: IT operations agent (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      

        
        
        
      

      
Waiting for the call.

      
    

  

  
  

    
Where a rules-based change workflow gets this wrong
Click to expand
    
Our assessment of what a typical rules-based ITSM workflow (conditions, business rules and approval rules, each checking one thing on its own) does with the same cases. It is a judgment about effort and reliability, not a claim that nothing can be built.

    
What the validator caughtA typical rules-based workflowPredictika
A fix that creates a new violationOnly with workarounds
Each condition is checked on its own. Moving the change after the booked one lands it outside the maintenance window, and the person finds out on the next submit.		The slot, the window, the booked change and the approvals are in one request and re-evaluated together on every call, and the validator offers a compliant slot.
An approval route that depends on computed riskOnly with care
Whether a normal change needs CAB or only the change manager depends on a risk score built from the CI, the environment, test evidence, notice and recent failures. Hand-written approval rules drift from that score.		The risk score and level are computed on every call from those facts, and the approval route follows from the score.
A collision with a change already bookedOnly with workarounds
The check needs the booked windows for the CI and for its related CIs and the overlap arithmetic against the proposed window, which a field-by-field rule does not do.		Booked windows travel with the CI, and overlap with the proposed window is computed for the CI and for a related CI.
A low-criticality CI with a large blast radiusOnly with workarounds
The CI itself is a low tier, so a criticality check passes, while nine services depend on it. The agent's authority has to be compared with the blast radius, not the CI.		The CI's blast radius is compared with the agent's authority on every call, and a wider radius sends the action to a person.
Every problem returned in one answerOnly with workarounds
Conditions usually stop at the first failure, so the agent fixes one problem and meets the next.		All findings come back together, whatever order the choices arrived in.

  

  

    
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 action; approval findings need a person to sign off; everything else is computed.

    
1Edge firewall 01 may only be changed on Saturday between 1:00 and 5:00. The plan starts day 2 at 14:00 for 2 h.
2Normal change on Edge firewall 01 is high risk (score 6) and needs CAB approval; none is recorded.
3Rtr-core-01 and rtr-core-02 are the two halves of an HA pair. Change one, verify, then raise a separate change for the other.
4The change request is for sw-acc-3f but the change targets rtr-core-01. Work only on the CI named on the change request.
5Core router 01 (HQ) has no standard change model. Raise it as a normal change and get approval.
6Core router 01 (HQ) is criticality 4; this agent may change up to criticality 2 on its own. A human engineer must approve.
7Service payments is in a change freeze (blackout). Only emergency changes are allowed.
8Emergency change on Payments database 01 bypasses the window and freeze, so the Emergency CAB must approve it first.
9Production change on Web load balancer 01 has no backout plan. Attach one before implementing.
10No test evidence is attached for the change on Web load balancer 01. A change manager must accept the risk.
11CHG1007 is closed. Do not act on a finished ticket; open a new one if more work is needed.
12Opening database port 5432 to the internet is never allowed. Use the vendor VPN or a private link.
13CHG1009 is assigned to agt_itsm_net, not to agt_itsm_l1. Work only on tickets assigned to you.
14Agent agt_iam is not permitted to implement_change.
15RITM2001 is a ticket of type access; implement_change is not a valid action for it.
16Raj Menon already holds ap_vendor_create, which conflicts with ap_payment_release (segregation of duties).
17Production DB administrator can be granted for at most 7 days; the action asks for 30. Use a shorter, time-bound grant.
18Sam Keller is terminated. Access can only be granted to active users.
19Kofi Mensah is a contractor with 20 days left on contract; access for 90 days would outlive the contract.
20Marco Ruiz approved their own access request. Someone else must approve.
21The request is pending, not approved. Wait for approval.
22AWS account administrator needs clearance 4; Dana Whitfield has clearance 2.
23AWS account administrator is a privileged role and this agent may not grant privileged access on its own. Route to the IAM team.
24Production DB read-only must be approved by u_marco (manager), but it was approved by u_priya.
25The ticket asks for vpn_access for u_sam; the action is crm_user for u_sam. Act only on what the ticket requests.
26CRM database 01 already has a change scheduled on Saturday from 20:00 to 22:00 that overlaps this plan (Saturday, 21:00 for 2 h). Schedule it after 22:00.
27A change is already scheduled on db-crm-01, which CRM application server 01 depends on, on Saturday from 20:00 to 22:00 and it overlaps this plan. A change manager must resolve the conflict.
28A change to Internal DNS server 01 (criticality 2) can take down 9 business service(s) (dns+payments+orders+web+internet_edge+corp_network+office_lan_3f+guest_wifi+crm), the most critical at level 4; this agent may change up to level 2 on its own. A human engineer must approve.
29Standard changes on Access switch 3rd floor must be raised from the change model vlan_add; this one was raised from firewall_rule_add.
30Normal change on Access switch 3rd floor is moderate risk (score 4) and has no change manager or CAB approval recorded.
31INC3001 has impact 2 and urgency 2, so its computed priority is P3; the agent proposes P4. Do not lower a priority without a stated justification.
32Lowering INC3001 from P3 to P4 overrides the computed priority. An incident manager must approve.
33INC3002 is a P1 major incident. The agent may only add work notes; a human incident manager must handle resolve_incident.
34INC3003 is P2; putting it on hold pauses its SLA clock, so an incident manager must approve.
35Putting INC3001 on hold needs a hold reason, because on hold pauses the SLA clock.
36INC3004 is new; resolve is not a valid next step. An incident is resolved or held only from In Progress.
37Resolving INC3001 needs a resolution code and resolution notes.
38INC3005 still has 1 open task(s). Close or cancel them before resolving.
39INC3006 was caused by a change that is still open. Resolve it after the change is closed.
40Network Operations covers network incidents, but INC3007 is a database incident. Assign it to a group that covers it, or to the Service Desk.
41INC3007 has already been reassigned 3 times. An incident manager should review before another hand-off.

  

  

    
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. Upgrading the CRM database: A normal change on the CRM database, proposed for Saturday evening

    
The agent's request. Please implement CHG1011, the CRM database minor-version upgrade, on db-crm-01 as a normal change on Saturday at 21:00 for two hours. The requester gave one day of notice. It is ready to implement.

    
Verdict: Blocked.

    
    
      
  • CAB approval missing. Normal change on CRM database 01 is high risk (score 10) and needs CAB approval; none is recorded.
    • 
      
  • No backout plan. Production change on CRM database 01 has no backout plan. Attach one before implementing.
    • 
      
  • Collides with a booked change. CRM database 01 already has a change scheduled on Saturday from 20:00 to 22:00 that overlaps this plan (Saturday, 21:00 for 2 h). Schedule it after 22:00.
    • 
      
  • No test evidence. No test evidence is attached for the change on CRM database 01. A change manager must accept the risk.
    • 
      
  • Risk. score 10 (high). Approval route: cab.
    • 
      
  • Compliant alternative. re-plan for Saturday from 22:00, approval route cab.
    • 
    

    
2. Upgrading the CRM database: The agent resubmits after fixing the errors

    
The agent's request. Please implement CHG1011, the CRM database minor-version upgrade, on db-crm-01 as a normal change on Saturday at 23:00 for two hours. The backout plan and the test results are attached, and one day of notice was given. It is ready to implement.

    
Verdict: Blocked.

    
    
      
  • CAB approval missing. Normal change on CRM database 01 is high risk (score 8) and needs CAB approval; none is recorded.
    • 
      
  • Outside the maintenance window. CRM database 01 may only be changed on Saturday between 20:00 and 24:00. The plan starts Saturday at 23:00 for 2 h.
    • 
      
  • Risk. score 8 (high). Approval route: cab.
    • 
      
  • Compliant alternative. re-plan for Saturday from 22:00, approval route cab.
    • 
    

    
3. Upgrading the CRM database: The agent resubmits after fixing the errors

    
The agent's request. Please implement CHG1011, the CRM database minor-version upgrade, on db-crm-01 as a normal change on Saturday at 22:00 for two hours. The backout plan and the test results are attached, one day of notice was given, and the CAB has approved it. It is ready to implement.

    
Verdict: Allowed.

    
    
      
  • Risk. score 8 (high). Approval route: cab.
    • 
    

    
4. Resolving an incident: Resolving the orders portal incident

    
The agent's request. Please resolve INC3001, the orders portal slowdown for some customers. The service is performing normally again.

    
Verdict: Blocked.

    
    
      
  • No resolution code. Resolving INC3001 needs a resolution code and resolution notes.
    • 
      
  • Priority. INC3001 has impact 2 and urgency 2, so its computed priority is P3.
    • 
      
  • SLA. P3 resolution target is 1440 min; the incident has been open 120 min, so 1320 min remain.
    • 
    

    
5. Resolving an incident: The agent resubmits after fixing the errors

    
The agent's request. Please resolve INC3001, the orders portal slowdown for some customers, with the resolution code Solved permanently and resolution notes attached. The service is performing normally again.

    
Verdict: Allowed.

    
    
      
  • Priority. INC3001 has impact 2 and urgency 2, so its computed priority is P3.
    • 
      
  • SLA. P3 resolution target is 1440 min; the incident has been open 120 min, so 1320 min remain.
    • 
    

    
6. Held for a person: A DNS record added by the L1 agent

    
The agent's request. Please implement CHG1014, adding an A record for the new intranet host on the internal DNS server, as a standard change using the DNS record add model on Saturday at 02:00 for two hours. The backout plan and the test results are attached.

    
Verdict: Needs approval.

    
    
      
  • Blast radius above the agent's authority. A change to Internal DNS server 01 (criticality 2) can take down 9 business service(s) (dns+payments+orders+web+internet_edge+corp_network+office_lan_3f+guest_wifi+crm), the most critical at level 4; this agent may change up to level 2 on its own. A human engineer must approve.
    • 
      
  • Risk. score 4 (moderate). Approval route: pre_approved.
    • 
      
  • Compliant alternative. re-plan for Saturday from 1:00, approval route pre_approved.
    • 
      
  • Do not execute yet. Put the ticket in Awaiting Approval and continue with other tickets.. Do not execute yet. Put the ticket in Awaiting Approval and continue with other tickets.
    • 
    

    
7. Held for a person: Resolving the P1 payments outage

    
The agent's request. Please resolve INC3002, the payments API outage affecting all customers, with the resolution code Solved by workaround and resolution notes attached. The payments API is responding again.

    
Verdict: Needs approval.

    
    
      
  • P1 major incident needs a person. INC3002 is a P1 major incident. The agent may only add work notes; a human incident manager must handle resolve_incident.
    • 
      
  • Priority. INC3002 has impact 1 and urgency 1, so its computed priority is P1.
    • 
      
  • SLA. P1 resolution target is 240 min; the incident has been open 45 min, so 195 min remain.
    • 
      
  • Do not execute yet. Put the ticket in Awaiting Approval and continue with other tickets.. Do not execute yet. Put the ticket in Awaiting Approval and continue with other tickets.
    • 
    

    
8. Passing an incident along: Sending a database incident to Network Operations

    
The agent's request. Please reassign INC3007, the reporting queries timing out, to Network Operations.

    
Verdict: Blocked.

    
    
      
  • Group does not cover this incident. Network Operations covers network incidents, but INC3007 is a database incident. Assign it to a group that covers it, or to the Service Desk.
    • 
      
  • Reassigned too many times. INC3007 has already been reassigned 3 times. An incident manager should review before another hand-off.
    • 
      
  • Priority. INC3007 has impact 2 and urgency 3, so its computed priority is P4.
    • 
      
  • SLA. P4 resolution target is 2880 min; the incident has been open 600 min, so 2280 min remain.
    • 
    

  

  

    
Narration transcript
Click to expand
    
The text of the narrated walkthrough, step by step.

    
    
      
  1. Welcome to a demo of Predictika's Validator. Calderwood Logistics runs IT operations on ServiceNow and lets an IT operations agent work its change requests, incidents and access requests. The agent prepares an action on a ticket and says it is ready. Before it goes out, the agent sends it to Predictika's validator, which checks it against Calderwood's change, incident and access rules, computes the risk, priority and SLA figures, and reports every problem it finds in one pass.
    2. 
      
  2. I will start with the first request by the agent.
    3. 
      
  3. The agent says. Please implement CHG1011, the CRM database minor-version upgrade, on db-crm-01 as a normal change on Saturday at 21:00 for two hours. The requester gave one day of notice. The rest of the request is on screen.
    4. 
      
  4. Before it goes out, the agent calls the validator.
    5. 
      
  5. Blocked, with three findings and one approval, all in one answer. Normal change on CRM database 01 is high risk (score 10) and needs CAB approval; none is recorded. Production change on CRM database 01 has no backout plan. Attach one before implementing. CRM database 01 already has a change scheduled on Saturday from 20:00 to 22:00 that overlaps this plan (Saturday, 21:00 for 2 h). Schedule it after 22:00.
    6. 
      
  6. The validator returned three 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 action are checked against each other.
    7. 
      
  7. What this shows: for a fix that creates a new violation, a typical rules-based workflow can do this only with workarounds.
    8. 
      
  8. Now the agent resubmits.
    9. 
      
  9. The corrected request. It changes the start hour to 23:00, the backout plan attached to yes and the test evidence attached to yes.
    10. 
      
  10. It calls the validator again.
    11. 
      
  11. Still blocked, with two findings, all in one answer. Normal change on CRM database 01 is high risk (score 8) and needs CAB approval; none is recorded. CRM database 01 may only be changed on Saturday between 20:00 and 24:00. The plan starts Saturday at 23:00 for 2 h.
    12. 
      
  12. Three findings cleared; still blocked on CAB approval missing, and newly found: outside the maintenance window.
    13. 
      
  13. The agent resubmits once more.
    14. 
      
  14. The revised request. It changes the start hour to 22:00 and the CAB approved to yes.
    15. 
      
  15. It calls the validator once more.
    16. 
      
  16. This time the validator clears it.
    17. 
      
  17. Both earlier findings are cleared.
    18. 
      
  18. Four problems caught in one call, fixed in two passes, and a clean action. That is the value of Predictika's validator: catching mistakes before the action runs.
    19.