There is a failure mode in credit decisioning that has nothing to do with model quality. The policy is sound, the thresholds are defensible, the outcomes are reasonable — and the review queue keeps growing, because the people staffing it cannot tell why anything landed there.

That is an explainability problem, and it shows up in operations long before it shows up in a regulatory conversation.

The queue is the diagnostic

Every automated decisioning system produces three populations: the ones it approves, the ones it declines, and the ones it hands to a person. The third one is where the design reveals itself.

A healthy referral queue has items that a reviewer can act on in a couple of minutes because the reason is legible: an identity element did not match, an attribute fell inside a band the policy deliberately routes to a human, a document is missing. The reviewer does something specific and the item leaves.

An unhealthy queue has items whose only annotation is a score and an outcome. The reviewer’s actual job becomes reconstructing the decision, which is slower than making it, and which produces inconsistent results because two reviewers reconstruct differently.

If your handle time is climbing and your reviewers disagree with each other, the first thing to look at is not training. It is whether the decision told them anything.

Reasons are outputs, not commentary

The fix is to treat the reason as part of the decision’s contract, produced by the same evaluation that produced the outcome — not derived afterward by a separate process reading the same inputs.

Derived-afterward explanations drift. The evaluation changes, the explanation code does not, and now the system is confidently reporting a reason that had no role in the outcome. This is worse than no reason at all, because people act on it.

Concretely, a decision should carry:

  • the outcome and the rule set version that produced it
  • the specific conditions that fired, in the order they were evaluated
  • for each, the input value and the threshold it was compared against
  • what a reviewer is expected to do next

That last one is skipped surprisingly often. “Identity mismatch: address” is a reason. “Identity mismatch: address — confirm current address and re-run” is an instruction, and only one of them clears a queue.

Version the rule set, and mean it

A decision made under primary_v3 needs to remain explainable after primary_v4 ships. That means the version is stamped on the decision and the prior definition remains retrievable — not just in a git history, but in a form the system can render next to the outcome.

This is what makes retrospective analysis possible at all. “Why did approvals move in April” is answerable if you can partition decisions by rule set version and see which conditions changed. It is guesswork if the only definition available is the current one.

It also settles disputes. When a decision is questioned six months later, the useful artifact is not an explanation of how the system works today. It is the policy as it stood on the day.

Separate the policy from the plumbing

The rules that encode credit strategy and the code that fetches attributes, handles retries, and dispatches events are different things with different change cadences and different owners.

When they are the same artifact, every threshold adjustment is an engineering release, which means thresholds get adjusted less often than the business wants and in larger, riskier batches. It also means the risk team reads their own policy through code, which is a bad medium for the conversation they need to have with each other.

Configurable rule evaluation exists to break that coupling — the policy becomes something the risk owner can read, review, and change on its own cadence, with the integration underneath it stable. That is the design intent behind decisioning in Revery Credit: make the policy the thing that is configured, and keep the mechanics out of it.

The test that matters

Here is a cheap and slightly uncomfortable exercise. Take twenty referred applications from last week. Hand them to someone in operations who did not build the policy. Ask them to write one sentence explaining each referral.

Count how many they can do in under two minutes without asking anyone.

Whatever that number is, it is roughly the ceiling on how well your queue can run — and improving it is almost always cheaper than improving the model.

The workflows, rule sets, and states described here are illustrative of how configurable decisioning is designed to work. Which attributes, thresholds, and adverse action requirements apply to your program is a matter for your risk, legal, and compliance teams.