Audit
Audit records how your rules are used in production. Every time your application evaluates a live rule, Audit keeps a record of it: which rule and which version ran, against which source version, when, for whom, what the rule decided, and the values it looked at to decide. Those records appear in the Rule Repository, where you can find any decision your rules made, see exactly why it was made, and turn it into a test.
With Audit you can:
- Answer "why did this happen?" for any single decision, such as a declined application or a price, by finding its evaluation and replaying it step by step. You see when the decision was made, which version of the rule made it, and why, which is what auditors and regulators mean by decision explainability.
- See how often each rule runs, and how often it ends in an error, over the last days, months or year.
- Turn real cases into tests, so a decision that once mattered is checked again every time the rule changes.
- Keep a dependable history. A rule version that has ever been live can no longer be deleted on its own, so every recorded decision always points to the exact rule that made it.
Audit is a separate library that your application adds next to the Rule Repository. If your application does not use it, the parts of the repository described in this section stay empty. For the developer's side, see Setting Up Audit.
What Audit Uses
- The Live Evaluations grid: the list of every recorded evaluation, with filters for the rule, the source, the outcome, the person and the time. See Evaluations.
- The Evaluation dialog: one evaluation in full, replayed condition by condition. See Reviewing an Evaluation.
- The Save Test dialog, opened from an evaluation with Save as Test.... See Evaluations as Tests.
- The Stats tab of the Source Object, Source Version, Rule and Rule Version dialogs, which counts the evaluations and charts them over time. See Production Statistics.
What Is Recorded
For each evaluation of a live rule, Audit records:
- The versions that ran: the rule version, the source version, and the versions of any other rules the rule used.
- What the rule decided: whether it ran or ended in an error and, when it ran, its result (true or false), plus any values it set.
- The values the rule read. By default, only the values the rule actually looked at are kept, not the whole record your application passed in: a value the rule never reached, for example in a branch it did not take, is not recorded. Your application can choose to record every field instead, and it can leave out values that must never be stored, such as personal identifiers.
- Who and what it was for: the person, AI agent or service on whose behalf your application evaluated the rule, and the correlation ID, a reference your application supplies to tie the evaluation to a business case, such as an order or an application number.
- When it ran and how long it took, and the evaluation settings your application used.
Tests you run in the repository are never recorded as evaluations; only your application's real evaluations are.
Who Can See It
Seeing evaluations needs its own permission, because evaluations hold real production data. Saving an evaluation as a test needs another, because the test keeps a copy of that data after the evaluation is gone. Without the first permission, the Live Evaluations grid and the evaluation counts are hidden from you. See Permissions.