Decision Analytics
The Analytics page shows how an environment's rules actually behave in production: how many runs happened and how they turned out, how often each rule fires, and what decisions your rule sets are producing.
Where to find it
Open an environment and choose Analytics in the environment menu, next to Logs. The page always covers one environment — production numbers and test-environment numbers never mix.
Three filters sit above the charts, and a Refresh button re-reads them:
| Filter | What it does |
|---|---|
| Project | Limits everything to one project's rule sets. Defaults to the project you navigated from. |
| RuleSet | Limits everything to a single rule set. The list is scoped to the selected project and shows each rule set's run count. |
| Window | The date range: the last 7, 14, 30, 60, or 90 days. Defaults to 30. |
Headline numbers
Four tiles summarise the selected window:
- Runs — total runs, plus how many days in the window had any activity.
- Success Rate — the share of runs that completed, counting runs that completed with warnings as successes. The supporting line gives the number of runs that ended in errors or failures.
- Average Duration — mean run time, with the fastest and slowest run underneath.
- Rules Never Fired — how many of the rules seen in this window never fired once.
Runs per day
A stacked bar per day, split by outcome: Completed, Warnings, Errors, Failed, and Cancelled. Outcomes that never occurred in the window are left out of the legend entirely. Hover a segment for its exact count. Days are UTC.
Rule fire rates
Fire rate is the share of the runs that evaluated a rule in which the rule actually fired. Rules are ranked by fire rate, highest first. The chart draws the top 20; when there are more, it says so, and the table below it always lists every rule.
| Column | Meaning |
|---|---|
| Rule | The rule's name, or its identifier if it has none. |
| Fire Rate | Fired ÷ Evaluated, as a percentage. |
| Fired | Runs in which the rule fired at least once. |
| Evaluated | Runs in which the rule's condition was actually tested — the denominator. |
| Activations | Total firings. Higher than Fired only under forward-chaining inference, where a rule can fire more than once in a run. |
| Skipped | Runs in which the rule was passed over without being evaluated — it was disabled, or the run fell outside its effective or expiration date. |
A rule at 0% either never matched or was never really in play. The Skipped column tells you which: a high skipped count means the rule was switched off or out of its date window, while a high evaluated count with zero fires means its condition is genuinely never true.
Fire rates are the runtime counterpart to verification. Verification finds rules that can never fire by inspecting the rule set; analytics shows which rules simply don't fire against your real traffic.
Decision distribution
A rule set's decision is whatever context key holds its outcome — an approval status, a routing category, a risk band. Name those keys and the page charts how often each value came out, as a doughnut plus a written list of value, count, and share.
To name them, open the rule set in the editor and expand the Decision keys panel underneath the Rules view. It starts collapsed, and its header shows the keys currently in use (or Not set) so you can check the setting without opening it. The panel appears once the rule set has at least one rule. Enter one or more context keys separated by commas — for example decision, riskBand. Leave it blank for none.
A rule set exposed as an MCP tool and with no decision keys of its own falls back to the output keys it already declares, so its outcomes are charted with no extra configuration.
Decision keys work best on keys with a small, repeating set of values. A few limits keep the data usable:
- Up to 10 decision keys per rule set.
- Up to 50 distinct values per key per day; anything past that folds into an
(other)bucket. The chart itself folds the long tail into an Other slice so no two values ever share a colour. - Values longer than 80 characters are truncated, and a run where the key is missing records
(absent). - Values marked secret are never recorded.
A key holding order numbers, customer ids, or free-text messages produces one bucket per run and tells you nothing. Pick keys whose values you could list on one hand.
How the data is collected
Counters are rolled up per rule set, per day, as each run finishes — the page never scans your logs, so it stays fast no matter how much history an environment has. That also means a few things worth knowing:
- Test runs are excluded. Runs from the test sandbox never move production numbers.
- Nested rule sets count separately. A rule set invoked by another gets its own rollup under its own name.
- Recording never breaks a run. If a rollup cannot be written, the run still succeeds and only the counter is lost.
- Rollups are retained for roughly 400 days.
When there's nothing to show
A brand-new environment — or one whose runs are all older than the selected window — shows an empty state instead of charts. Widen the window, or run a rule set and come back. If the decision panel is empty, no rule set in scope has decision keys configured yet.