Replacing monthly operational reporting with continuous exception oversight

An operations function relied on monthly manual reporting and the knowledge of a small number of experienced staff. Exceptions surfaced late, ownership was ambiguous, and there was no defensible record of how issues had been resolved. The work replaced the reporting cycle with continuous rule evaluation over existing systems. Exceptions are now raised as they occur, routed to a named owner with a service level, and recorded in an append-only history. Detection was kept deliberately deterministic so that every exception can be explained and reproduced.

The business processed operational activity across several upstream systems that had been adopted at different times. Each system reported adequately in isolation, but no view existed across them. Senior operations staff compensated by knowing where problems tended to appear, which worked while volumes were modest and while those individuals remained in post.

Three specific failures needed addressing. Exceptions were discovered up to a month after occurring, by which point remediation was more expensive. When an exception was found, ownership was assigned informally, so resolution time varied widely. And when an external party asked how a past issue had been handled, the answer had to be reconstructed from email.

1. 01

   Trace the current process before designing anything

   The existing monthly cycle was mapped with the people who ran it, including the informal checks they performed but had never documented. Those informal checks turned out to be the most valuable rules to encode first.

2. 02

   Encode detection as explicit rules

   Each check was written as a deterministic rule with a stated intent, severity and owner. Anything that could not be stated clearly enough to be reviewed by an auditor was deferred rather than approximated.

3. 03

   Design ownership before dashboards

   The routing model, escalation path and service levels were agreed before interface work began. Exception detection without assigned ownership produces a queue nobody clears.

4. 04

   Deliver against the highest-cost check first

   The first release covered a single rule family that accounted for a disproportionate share of late discovery. It went into daily use before the remaining rules were built.

PostgreSQL as the single system of record

Relational integrity, row-level access policies and mature audit patterns matter more here than horizontal scale.

Server-side rendering for the application shell

Operational users work on constrained networks; first render should not wait on a client bundle.

Scheduled evaluation jobs rather than streaming infrastructure

Near-real-time evaluation met the business requirement at a fraction of the operational complexity of a streaming platform.

Language models restricted to reporting narratives

Summarisation adds value where a human reads the output; it adds risk where a decision depends on it.

Undocumented checks held only in individual knowledge

Working sessions with the staff who performed them, encoding each as a rule with stated intent so the knowledge became institutional.

Early rule sets produced too many low-value exceptions

Severity thresholds were tuned against historic data before rules were enabled, and any rule that could not justify its noise was switched off.

Inconsistent identifiers between upstream systems

A reconciliation layer with explicit unmatched-record handling, so gaps were visible rather than silently dropped.

• Detection logic that cannot be explained to an auditor will not be trusted, however accurate it is.
• Ownership design determines outcomes more than detection sophistication.
• Tuning severity against historic data before go-live is what prevents alert fatigue.
• An append-only audit model is inexpensive at design time and costly to introduce later.