FlightSentry: context-aware alert triage
Built an alert triage workbench that checks trusted command and plan records before an anomaly becomes an investigation, with a human making the final call.
On a paired replay of two ESA events, trusted context cleared the planned event (609), kept the real anomaly (618) under investigation, preserved 100% anomaly recall, and passed a 2-of-2 counterfactual check. This is a deliberately narrow n=2 demo, not an official ESA-ADB result.
The problem
Detectors flag unusual behavior, but some rare events are planned, and an alert can't tell planned from broken. Every false positive costs analyst time, and letting a language model improvise the explanation adds a different risk.
What I built and owned
Two alerts that look the same
ESA Mission 2 events 609 and 618 produce similar telemetry changes. Event 609 was commanded and planned; event 618 was not. With telemetry alone, both become investigations.
Context decides, not the model
A deterministic gate requires six checks to pass before an alert can drop to MONITOR, including a command record before onset and an overlapping planned event. If any check fails or is ambiguous, the result is INVESTIGATE. With trusted context, 609 moves to MONITOR and 618 stays INVESTIGATE.
Proving it changes for the right reason
Removing either the command record or the planned-event record from event 609 sends it back to INVESTIGATE, without calling the model. Both removals flip the decision: a 2-of-2 counterfactual check.
A bounded, validated model
IBM Granite gets only a server-built evidence packet. Responses are schema-checked, any evidence ID not in the packet is rejected, and any failure falls back to a labeled reference brief. An analyst accepts the recommendation or raises severity, records a rationale, and exports the decision record.
Hardened for a public demo
A strict Content-Security-Policy and security headers ship from the app config, and the analysis endpoint is rate-limited per client, returning 429 with Retry-After when exceeded.