Guides
Build and tune a monitoring rule
Draft, simulate, approve and revise — without losing the history of what the rule used to say.
Written for: Compliance administrators and MLROs
Written from docs/adr/0016, docs/adr/0028
A rule is a window and a predicate, authored as a condition tree over a declared field vocabulary. The builder will not open a field the vocabulary does not declare, so a rule cannot come to depend on a value whose semantics the evaluator has not defined.
The tuning loopPermalink to this section
- 1
Draft
A new version of the rule document. The version in force is untouched while you work.
- 2
Simulate
Evaluate the draft over historical activity to see what it would have produced, before it produces anything.
- 3
Propose
Submit for approval with the full before-and-after, so the reviewer sees the change rather than a description of it.
- 4
Approve and activate
A different person approves. The new version becomes the version in force from that moment; alerts already raised keep their original version.
Working on false positivesPermalink to this section
Dispositions are the tuning signal. A rule whose alerts are consistently closed as non-suspicious is producing noise, and the disposition history is the evidence for changing it — which is also the evidence a reviewer will want for why it was changed.