Validation

Tested on real ServiceNow data.

Simulated data shows a method finds what was planted in it. Real data shows it copes with a real export. This page does both: a public log from a real ServiceNow instance, with known failures planted in it.

Real export read
24,918
incidents from 141,712 events
Came back after a person's resolution
10.1%
same type of issue, within 7 days
Made to fail: 10%
9.8%
found on average, over 50 runs

1. The engine read the real export

The log is the audit trail of an IT company's ServiceNow instance, from 2016-02-29 to 2017-02-16: every update to every incident, from 5,244 callers. The engine kept each incident's last state (141,712 events became 24,918 incidents), mapped it with its ServiceNow preset, and read its day-first dates. Its health check flagged:

  • 3 week(s) with no records at all, e.g. 2016-06-13; check the extract is complete

The log has no time worked or survey scores, so the effort and satisfaction measures cannot run on it; the resolution audit needs neither.

2. Real return rates after people's resolutions

How often the same caller opened another incident within 7 days after one was resolved. These are the normal rates an AI's resolutions are compared with, and they vary a lot by category, which is why the audit compares like with like.

IncidentsResolvedCame back, any issueCame back, same type
All23,33641.3%10.1%
Category 423,12443.2%16.5%
Category 263,04537.7%7.4%
Category 532,58736.4%7.0%
Category 462,35647.3%8.8%
Category 321,26843.0%9.7%
Category 91,12138.7%3.3%
Category 371,09836.1%5.7%
Category 231,05541.0%6.9%

Categories are anonymized codes in the published log. Many callers in it open incidents often, so the rate for any issue is high; the same-type rate is the one the audit uses.

3. The audit finds failures planted in real data

In each run, 2,000 real resolved incidents, chosen at random, were relabelled as an AI's claimed resolutions, so they carry real callers, categories and timing. Before planting, they are the same kind of resolution as the rest, so the true share that did not hold is zero. For a planted share, a return incident about the same type of issue was added within 7 days for that share of the claims that did not come back. 50 runs at each level.

Made to failFound, on averageAverage errorRange held the truthFlagged
0%−0.2%0.7 pts94% of runs0% of runs
10%9.8%0.6 pts100% of runs100% of runs
20%19.7%0.4 pts100% of runs100% of runs

With nothing planted, the audit should rarely flag a problem; with failures planted, it should flag them every time, and its 95% range should hold the truth about 95% of the time.

4. What this does not show

  • An AI's effect. The log predates AI agents. Results on real AI come from design partners, and are published only with their permission.
  • How real failures cluster. The planted returns are spread at random; real ones may bunch by topic or week, which the audit's month-by-month check is there for.

5. Run it yourself

pip install probative-labs
probative validate --real incident_event_log.csv --runs 50 --report real-validation.json

Data: Amaral, C., Fantinato, M., & Peres, S. (2018). Incident management process enriched event log [Dataset]. UCI Machine Learning Repository. https://doi.org/10.24432/C57S4H Licensed CC BY 4.0; dataset page. Engine 0.4.0. Validation on simulated desks, including the evidence pack: docs/validation.md.