Month-3 survival of an anomaly detection system is not decided by the precision number recorded at acceptance testing. It is decided by whether anyone can still answer three questions in month four: why is the threshold what it is, who reviewed last week’s false positives, and has the input distribution moved since baseline. Four artefacts hold those answers. Where they exist and have named owners, an operator’s disagreement with an alert becomes a tuning ticket. Where they don’t, the same disagreement becomes a reason to mute the channel — and a muted channel is indistinguishable, on any dashboard we have looked at, from a healthy one.
This piece is the inventory, not the argument. We work through what each artefact is, who owns it after go-live, and what the smallest acceptable version looks like on an industrial, energy or telecom deployment. The structural reasons these artefacts govern system survival are developed in our work on production AI reliability.
Scope note before the list: this covers operational anomaly detection on machines, plant signals and network telemetry. People-surveillance and behaviour-tracking use cases sit outside it, and we re-verify that boundary at the level of each individual deployment rather than inheriting it from a programme-level statement.
What does “artefact inventory” mean for an anomaly detection system?
An artefact here is a durable, reviewable record — not a document written once for a sign-off gate. The test is whether a person who joins the operations shift in month five can read it and reconstruct a decision they did not witness. A threshold committed to a config file with the reasoning left in a chat thread fails that test. The same threshold with its baseline window, its historical-incident replay results and the name of whoever accepted the alert-volume trade recorded alongside it passes.
The distinction matters because the four artefacts below are the only mechanism by which a tuning dispute stays cheap. Where a team records alert acknowledgement rate, disposition-coded closures, false-positive rate per escalation tier over rolling 30-day windows, and time from drift signal to threshold re-tune, tuning is typically hours of work per month (observed across TechnoLynx anomaly engagements; not a published benchmark). Where those four numbers are absent, the system is usually re-scoped or rebuilt rather than tuned.
The minimum artefact inventory
| Artefact | Minimum viable version | Owner after go-live | Needed before go-live? |
|---|---|---|---|
| Sensitivity calibration record | Per asset class: baseline window used, threshold value, historical incidents caught and missed at that threshold, implied alerts per operator per shift, name of the person who accepted the trade | Delivery team writes it; platform team keeps it versioned with the model | Yes — go-live without it means the first dispute has no reference point |
| False-positive review queue | Structured dismissals: sensor/signal, time window, disposition code, reviewer, reason code. A spreadsheet with those five columns qualifies | Operations shift populates it; platform team owns schema and retention | Schema yes, cadence can start in week 1–2 |
| Drift telemetry | Baseline-recomputation history plus alert-rate-per-asset time series, both retained long enough to cover a full duty cycle or season | Platform team | Instrumentation yes; alerting thresholds on the drift signals can follow in month 1 |
| Escalation-tier evidence | Written tier definitions (low-confidence → named queue, high-confidence → paging route) with false-positive rate tracked separately per tier | Operations, jointly with the delivery team at handover | Yes — tiering added later means retrofitting alert routing under pressure |
Two of these can be staged. Drift instrumentation must be emitting from day one, but the thresholds that turn drift signals into work items are better set once you have a few weeks of real distributions to look at — setting them on synthetic assumptions produces its own noise. The review queue’s schema must exist at go-live because retrofitting disposition codes onto dismissals already made destroys the labelled history you wanted; the weekly review cadence itself can begin in the first fortnight without losing operator trust.
The calibration record and the escalation tiers cannot be staged. Both are referenced the first time an operator disagrees with an alert, and that usually happens inside the first week.
Ownership is the part that gets skipped
Naming an owner per artefact is not administrative tidiness. Each of the four decays in a different direction, and the direction depends on who is holding it.
The calibration record decays when the delivery team rolls off and nobody inherits the obligation to re-record after a re-tune. Version it alongside the model in the same registry — MLflow or an equivalent — so the record moves when the artefact it describes moves. The review queue decays when it is owned by engineering rather than the shift that actually dismisses alerts; engineers dismiss too few alerts to keep it representative. Drift telemetry decays quietly, because a dashboard nobody looks at looks identical to one with nothing to report; the fix is a scheduled read, not a better chart. Escalation tiers decay when a paging route is widened during an incident and never narrowed again.
Early signals the inventory has decayed
Watch four numbers rather than the model’s accuracy metrics, which stay flat while an anomaly detector degrades:
- Acknowledgement rate falling while alert volume holds steady — operators are triaging by ignoring.
- Share of alerts closed without a disposition code rising above a small minority — the review queue is becoming a drain, not a record.
- Drift signal to re-tune latency stretching from days to “we’ll look at it next quarter”.
- Escalation tiers collapsing — everything routed to one tier, which means the tiering document no longer describes reality.
Any one of those is a tuning conversation. Two or more together is the alert-wall trajectory, and it is easier to arrest at that point than after the channel has been muted.
How is this different from an incident-response runbook?
Different question, different reviewer, different change cadence. The reliability artefacts answer why does the detector fire when it fires — they are read by whoever tunes the system, and they change when the model or the threshold changes. A runbook answers what does the operator do at 03:00 when it fires — it is read under time pressure and changes when the operational procedure changes. The handover boundary sits at the alert itself: everything upstream of the alert being raised is a reliability artefact, everything downstream is response procedure. Bundling them is the common shortcut, and it costs you the audit trail on the calibration record the first time someone edits the bundle mid-incident. We treat the two as separate documents with separate owners for exactly that reason.
Scoping the inventory across industrial, energy and telecom
Artefacts Keep Anomaly Detection comes into focus here. Industrial deployments usually calibrate per asset class, because a pump and a press have different normal envelopes. Energy work — transformer and grid-asset monitoring in particular — needs drift telemetry retained across a full seasonal cycle, since load-driven baseline movement over months is the dominant drift source rather than model decay. Telecom network-anomaly work tends to need the finest escalation tiering, because alert volumes per operator are an order of magnitude higher and a single tier saturates fast.
People-surveillance and behaviour-tracking applications are excluded from this inventory deliberately. The artefacts assume the thing being modelled is a machine or a network with a physical normal envelope, and that a false positive costs a technician’s time. Neither assumption transfers to systems whose subject is a person, and the reliability framing here should not be read as an endorsement of applying it there.
Frequently Asked Questions
What does “artefacts that keep an anomaly detection system in active use past month 3” mean in practice?
Stripped down, Artefacts Keep Anomaly Detection is the following. It means a small set of durable records — calibration, false-positive review, drift telemetry, escalation tiers — that let someone reconstruct why the detector behaves as it does without having been present when it was tuned. In practice they are what turns an operator’s disagreement with an alert into a tuning ticket rather than a muted channel.
What is the minimum artefact inventory, and what does the minimum viable version of each look like?
Four items: a sensitivity calibration record (baseline window, threshold, incidents caught and missed, implied alert volume, who accepted it), a false-positive review queue with five structured columns, drift telemetry covering baseline-recomputation history and alert rate per asset, and written escalation-tier definitions with per-tier false-positive rates. The minimum viable versions are deliberately modest — a versioned markdown file and a five-column spreadsheet clear the bar.
Who owns each artefact after go-live?
The delivery team authors the calibration record and the platform team versions it with the model; the operations shift populates the review queue while the platform team owns its schema; drift telemetry sits with the platform team; escalation tiers are owned jointly by operations and the delivery team at handover. Unowned artefacts are the common failure, and each one decays in a different direction depending on who is holding it.
Which artefacts are needed before go-live and which can be stood up in the first month?
The calibration record and the escalation-tier definitions must exist at go-live, because both are referenced the first time an operator disputes an alert. Drift instrumentation must be emitting from day one but its alerting thresholds can wait for real distributions; the review queue needs its schema at go-live and can begin its weekly cadence in the first fortnight.
What early signals indicate the artefacts have decayed?
Falling acknowledgement rate at steady alert volume, a rising share of alerts closed without a disposition code, drift-to-re-tune latency stretching from days to quarters, and escalation tiers collapsing into one. Model accuracy metrics will not move while any of this happens, which is why these four are the ones to watch.
How do these artefacts differ from an incident-response runbook, and where is the handover boundary?
Reliability artefacts explain why the detector fires and are read by whoever tunes it; a runbook explains what the operator does next and is read under time pressure. The boundary is the alert itself — upstream is artefact, downstream is procedure — and keeping them as separate documents preserves the calibration record’s audit trail when the runbook is edited mid-incident.
How is the inventory scoped for industrial, energy and telecom work, and why are people-surveillance use cases excluded?
The four artefacts are constant; granularity varies — per asset class in industrial, season-length drift retention in energy, finer escalation tiering in telecom. People-surveillance and behaviour-tracking are excluded because the inventory assumes a physical normal envelope and a false positive costing technician time, and neither assumption holds when the subject is a person.
If you are commissioning an anomaly engagement, the useful move is to name the owner of each of these four items before sign-off rather than after the first alert storm. Which of the four does your current deployment actually have a named owner for?
Four artefacts that prevent abandonment
Drill logs, annotation trails, escalation playbooks, and feedback loops—these four artefacts turn sporadic curiosity into sustained operational discipline. That answer is workload-specific, and it is worth writing down before you build.
