Live demo
16 series in. 4 alerts out.
A phase III study, 60 days of EDC extracts, 16 series across four investigator sites. On day 42 one site started enrolling three times faster than its own history while the variance of its reported measurements collapsed. The study-wide deviation rate never moved. Find the site. The output is a referral for human monitoring review, not a conclusion about anyone.
Every number on this page is computed in your browser right now, by the same CUSUM and Bayesian changepoint code that runs in production. Nothing here is a screenshot.
The comparison that matters
Against the rule most teams actually ship
The standard configuration is a percentage or sigma threshold against a trailing mean, evaluated per metric. Run it over the exact same 16 series and count what lands in the channel.
The false-alarm count is not a judgement call. The incident was injected at a known index, so every naive alert before that index is wrong by construction.
What the engine found
Detection run
| Metric | Trend | Baseline | Now | Change | Confidence | Method |
|---|---|---|---|---|---|---|
Protocol deviation rate site=047 Groningen | 3.05% | 9.87% | +224% | 99.9% | CUSUM | |
Enrolments per site-week site=047 Groningen | 1.609 | 4.555 | +183% | 99.9% | CUSUM | |
Queries per CRF page site=047 Groningen | 0.449 | 1.144 | +155% | 99.9% | CUSUM | |
Reported measurement variance site=047 Groningen | 7.121 | 2.413 | −66.1% | 99.9% | CUSUM |
Show your work
Protocol deviation rate · site=047 Groningen
Baseline mean μ = 0.0121 and σ = 0.1500, both computed from the first two thirds of the day-over-day percentage changes. The slack k = 0.0750 is half a sigma, and the decision boundary h = 0.6001 is four. The accumulator runs on percentage changes rather than raw levels so a healthy growing series cannot drift across the boundary on its own.
alert if |Δ| > 15% vs 7-day mean fired 13 times across this one metric, including 6 before anything was actually wrong. The statistical pipeline sent one message, on the day the regime actually changed.
What lands in Slack
One message, with the work already done
- 1.Route site 047 to the next risk-based monitoring cycle for a targeted source data review.
- 2.Have data management re-check the Aug 10 onward CRF pages against source for the flagged measurements.
- 3.Confirm with the site whether staffing, equipment, or the recruitment path changed on or around Aug 10.
The written cause is generated only after the statistics confirm the change. The model never decides whether something is an anomaly — it explains one that has already been established. Getting that order backwards is how these products hallucinate.