How to evaluate a decision

Write down the question, the possible answers, and what happens after each answer. Ask reviewers to explain the standard and resolve ambiguous examples. If people disagree about the intended result, model agreement alone will not settle the underlying policy.

Choose representative examples, including difficult cases. Keep examples used to evaluate a candidate separate from those used to train or optimize it.

For a yes-or-no decision, accuracy counts overall agreement with a reference label. Precision asks how many of the model’s yes answers should really have been yes. Recall asks how many actual yes cases the model found.

For ticket escalation, higher recall means catching more tickets that need escalation. Higher precision means fewer unnecessary escalations. These measures can move in different directions. Choose the trade-off deliberately, compare results with a simple baseline, and measure how much work still reaches people.

A model’s confidence is a number to test. Calibration asks whether groups of comparable predictions are correct about as often as their confidence suggests.

Before using a confidence threshold, measure the errors among the items it would handle automatically. Keep checking as the model, question, or incoming work changes. A stable answer or a precise-looking probability is not evidence of correctness.

When decisions affect people, accuracy and calibration do not establish fairness. Define tests for the actual input, population, threshold, and resulting action. Inspect relevant outcome differences as well as individual model answers.

A component can pass a paired test while the final selection outcome worsens. Treat a passed component test as evidence about that test, not a guarantee about the whole system.

Evaluate proposed changes on held-out representative corrections before approving them. Keep a random audit sample as review decreases so the team can check the whole workflow, including decisions that would otherwise pass without a human look.