DEV Community

Mads Hansen
Mads Hansen

Posted on

The useful output of anomaly detection is a review queue, not another dashboard

A natural-language database workflow should not produce a longer dashboard.

It should produce a bounded review queue.

That means every exception needs:

  • an approved rule and metric version
  • trusted tenant, environment, and time scope
  • observed value, baseline, and threshold
  • source freshness and filters
  • a stable exception identity
  • a trace that another reviewer can verify

Detection and explanation should also be separate.

The first query finds a bounded set of candidates. A second lookup explains one selected candidate. That avoids joining every detail into every alert and supports progressive disclosure.

Then keep review separate from action.

Finding a failed job, risky renewal, or unusual order should not automatically update a status, send a message, or retry a workflow. Those are separate tools with fresh authorization, preview, validation, idempotency, and approval where required.

The practical test is simple: run the same detection twice. If the queue creates duplicate alerts instead of recognizing unchanged conditions, it does not yet have operational identity.

Full guide: Natural language SQL exception reporting

Top comments (0)