The first question after publishing a rule set is not “is it correct” — it is “is it behaving”. This page covers the three screens that answer it.

​
Live decisions

Live lists decisions as they are recorded: time, outcome, score, scenario, customer, and a link to the case if one was opened. The counters above give the distribution of what has been seen since the screen was opened. Watching for a minute after a publish tells you what the dashboard will say in half an hour: whether the thresholds held, which rule fires more often than expected, and whether the volume landing in the review queue is a number your team can carry.
This is a sample, not a system of record. If more decisions arrive in a busy minute than the screen can carry, it says so; use the decision search for the complete list. What has been seen is lost when the page is closed — nothing here is stored.
The feed reads the decisions themselves rather than the message stream. A feed off the stream would be a second or two fresher and would show decisions that had not been written — including any whose write then failed. Since this screen exists to watch what the platform is actually doing, it reads what the case list and the decision search read.

​
Rule performance

Analytics → Rule performance shows what each rule did, per version: how many times it was evaluated, how many times it fired, what it contributed to the score, and how often it was decisive — whether removing its score would have moved the outcome into a different band. A rule that fires often is not a good rule; a rule that changes the outcome is. A rule that fires on every transaction and never moves a decision’s band is producing nothing but noise. The confirmed risk and false alarm counts from closed cases sit in the same table: how much of the work a rule produced turned out to be real.

​
Threshold simulation

Analytics → Threshold simulation replays the period’s score distribution against candidate thresholds: how many transactions would not have reached review had you moved the threshold from 60 to 70, and how many would arrive as review rather than decline. It is the cheapest way to adjust volume without touching a rule — and it is not sufficient on its own: it tells you the volume, not which transactions would escape. For that there is running against history.

​
Response times

Analytics → Response times gives the latency distribution of the decision and ingestion surfaces as percentiles. It is for seeing the trend, not for explaining one slow transaction. To ask where a single decision spent its time, read the stage breakdown in the decision’s own response — a percentile cannot be asked about one transaction.