Inverse Prediction Anomaly

The problem

Anomaly detection in business systems is usually solved with hand-authored rules. "Flag invoices above €10,000." "Flag any vendor without a PO." "Flag amounts that deviate more than 2σ from the supplier's mean." The rules are honest, they are auditable, and they catch a portion of the real anomalies — but they also flag a lot of false positives, and they miss the cases where the surface fields look fine but the combination is wrong.

The combination is where the anomalies actually live. A €1,200 invoice from a stationery vendor is normal; a €1,200 invoice from a stationery vendor coded to the IT-infrastructure GL account is not. The amount is unremarkable; the vendor is unremarkable; the combination is the anomaly. Rules do not catch this because rules look at one field at a time.

The predictive system catches it because the predictive system knows what to expect from the combination. If the prediction is confident and gives the actual posting little probability, it is not just unusual — it is contradictory.

How it works

Inverse prediction is the simplest anomaly pattern in Aito. The system predicts what a normally-coded transaction should look like given its surrounding fields. The actual posted value is then looked up in that prediction: its probability p gives the anomaly score, (1 − p) × 100. A value the history often uses scores low; one it rarely uses scores high; one that is not among the listed alternatives at all gets at most the smallest listed probability. In the ERP demo, 85 and above is high severity and 60 and above medium.

The same query that drives auto-routing on a forward prediction drives anomaly detection on a backward check. No separate anomaly model; the same _predict is read in two directions. The system runs the check at posting time, before the entry is committed, so the anomaly is caught while it is still cheap to fix.

The ERP demo shows it beside two related checks: amount-spike (how few of the supplier's past POs were this large) and unknown-vendor (no purchase on file names the vendor). Those two read the history with _search rather than _predict, but all three are scored on the same (1 − p) × 100 scale, so they rank in one list.

{
  "from": "purchases",
  "predict": "account_code",
  "where": {
    "supplier": "Wärtsilä Components"
  },
  "select": [
    "$p",
    "$value",
    {
      "$why": {
        "highlight": {
          "posPreTag": "«",
          "posPostTag": "»"
        }
      }
    }
  ],
  "limit": 10
}

// Look up the actual account_code among these hits. Its $p is p;
// if it is absent, p is at most the smallest listed $p.
// Score = (1 - p) * 100; 85 and above is flagged high.

For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.

See it live

This use case runs in 2 live demos today, the 📋 ERP and 🧾 Accounting demos. Each link opens the view that shows it, where you can inspect the queries that produce the result.

• ERP demo →
• Accounting demo →

Frequently asked