The problem
When a reviewer corrects a predicted GL code or approver, the correction usually disappears into the ledger. It fixes that one invoice and teaches nobody anything. Yet a run of corrections pointing the same way is the clearest signal a team gets that a rule is missing or a pattern has shifted.
The corrections are data. Asked the right question, they say which vendor keeps getting recoded, to what, and by whom, which is exactly what a rule author needs to know.
How it works
Each override is stored as a row: the field, the predicted value, the corrected value, and the context of the invoice. _relate over that table finds which corrected values co-occur with which context, and a second _relate looks for the driver behind the strongest ones. A pattern that keeps recurring surfaces as a rule candidate for review, next to the plain counts of overrides by field and by corrector.
Mining the overrides adds a governance step on top of the predictions: a human decides whether a recurring correction should become an explicit rule.
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 the 🧾 Accounting demo today. Click through to the live application and inspect the queries that produce the result.
