The two views of auditing: the individual decision and policy behavior

Why an explained decision isn't enough

Individual traceability answers a specific question: why was this person rejected. It is essential to answer a complaint and to support a one-off review, but it has a blind spot: a policy can have every one of its decisions perfectly documented and still be wrong.

The typical case: each decision is well justified, and yet the rejection rate went from 40% to 80% after a change. No individual trace is wrong. The problem only exists in the aggregate.

• The individual view answers a specific complaint.
• The aggregate view shows whether the policy does what is expected.
• An auditor asks for both; so does a regulator.

Individual view: reconstructing a decision

This is the chain of evidence for one case: what data came in, which sources were queried, which rules were evaluated, which version of the policy was live at that moment, and with what reasons it was resolved. With that chain, any decision is explained with evidence rather than someone's recollection.

• Input received and external sources queried.
• Rules applied and the exact policy version.
• Outcome and its associated reasons (reason codes).

Aggregate view: how the policy behaves

This is the picture of the whole: how many transactions the policy processed, what share it approved and rejected, and how rejection reasons are distributed. It doesn't replace the individual trace — it answers a different question.

Its value lies in comparison. An approval rate in isolation says nothing; the same rate before and after publishing a new version says a great deal.

• Transaction volume per policy.
• Approval and rejection rates.
• Distribution of rejection reasons and their relative weight.

What the aggregate view catches that the individual one cannot

When a single criterion concentrates most rejections, it may be correct — a regulatory validation that genuinely applies to many people — or a calibration error turning away good customers. Telling one from the other is only possible by looking at the aggregate.

Bias is the most delicate case. If a reason disproportionately hits one segment, decision by decision every case looks correct: the pattern only appears when you group them. Governing bias starts with measuring it.

• Calibration errors after a policy change.
• Data sources down: a new reason appearing all at once.
• Bias concentrated in one segment.
• Real differences between variants in a champion/challenger test.

What to watch, and how often

The aggregate view only works if it is watched on a cadence. The most expensive deviations aren't the most severe ones: they're the ones that run for weeks with nobody looking at the whole.

• After publishing each version: the day's approval rate.
• Weekly, in steady state: reason concentration and newly appearing reasons.
• During a champion/challenger test: compare rates across variants.
• At every risk committee: distribution by segment.

How this looks in uFlow

Each policy has its own dashboard: total transactions, how many were approved and rejected with their rates, and the top rejection reasons with the number of occurrences of each. All inside the platform, without exporting data or processing it elsewhere.

It is configured once per policy, indicating which variable holds the approval status, which value represents an approved case and which variable stores the rejection reason: the panel adapts to your naming, not the other way around.

One limit worth being clear about: the panel covers the current day's transactions, excluding the last hour. It is an early-detection tool — seeing today whether a policy has drifted — and it does not replace historical analysis or exploratory cuts, which stay in your analytics team's own tools.