Library · Data Practice OS

Outcome feedback loops

Reference guide · Published · Source reviewed 2026-11-06

Short answer. A decision is not finished when it is made. Decide in advance what outcome tells you whether it was right, capture it, link it to the Decision record, and route it to three places: the evaluation set, the owner of the rule, and the Decision inventory. This is the top layer of the From data to decisions - the decision stack, and the one most often missing.

Status. Proposed practice. Not an agreed decision. It extends the "after go-live" practice in Evaluating AI systems from model quality to decision quality.

Choose the outcome signal first

For each decision type, name the signal before go-live. Good signals are observable, arrive within a known time, and are linkable to the decision.

Decision	Outcome signal	Arrives
Defect priority	Repair date vs target response; same defect re-reported within six months; claims or crashes at the site	Weeks to months
Licence renewal recommendation	Officer accepted or overrode; later appeal or reversal; complaint	Days to months
Heavy-vehicle permit route	Permit amended after issue; incident on route; infrastructure damage report	Months
Customer enquiry routing	Re-routed; resolved at first contact; complaint	Days

Also record the counterfactual you can see: for overrides, what the officer did instead. An override with a reason code is the most valuable signal you will get, because it is a human expert telling you the system was wrong and why.

If you cannot name a signal, write that down in the inventory. It means the decision cannot yet be evaluated, and AI support for it should stay at read or recommend.

Link outcomes to decisions

Give every decision a decision id at the moment it is made, and carry it into the work order, letter, case or permit it produces. Outcomes arrive in those systems, not in the AI service.
Land outcome events into the platform and join them to decision records by id. Where no id was carried, link by subject and time window, and record the method and its uncertainty.
Keep outcomes append-only on the record. An appeal outcome is added; the original decision is not edited (Decision records and provenance).

Three destinations

1. Evaluation sets

Outcomes turn production into test cases.

Add overridden and reversed decisions to the evaluation set, with the correct answer as the officer or appeal decided it (Evaluating AI systems, LLM evaluation).
Sample accepted decisions too, or the set drifts towards hard cases only.
Re-run the evaluation before each model, prompt or rule change. A change that would have reversed past correct decisions does not ship.
Track experiments and results in the tooling the AI handbook recommends, for example MLflow.

2. Rule review

Outcomes show where the rules, not the model, are wrong.

A cluster of overrides on one decision-table row is evidence for the rule owner, not a model bug.
Route it to the owner as a proposed rule change, with the cases attached. The owner decides; the data does not change the rule by itself (Rule authority).
Review cadence per decision type, set in the inventory: for example, the defect matrix annually and after any cluster of recurrences.

3. The decision inventory

Roll outcomes up per decision type: volume, override rate, reversal rate, time to decide, outcome quality. These become the decision outcome measures reported in the roadmap (Roadmap and maturity). They decide whether AI support moves up (recommend → approve with review) or down.

Guard against bad loops

Self-confirmation. If the system's own ranking decides which defects get inspected, outcomes for low-ranked defects are never observed. Keep a small random or rule-based sample outside the ranking.
Override fatigue. If officers accept 99% of recommendations in seconds, the acceptance signal is weak. Measure review time and sample for quality checks (Human in the loop).
Lagging outcomes. Some outcomes take a year. Use early proxies (re-report within 30 days), and label them as proxies.
Fairness. Break outcome measures down by region and customer group where lawful and appropriate, so a decision that works on average does not fail one group.

Not when

Decisions with no consequence worth measuring. Do not build a feedback pipeline for a report.
Do not let outcome data retrain or change rules automatically for decisions about people. Outcomes inform the owner; the owner changes the rule.
Do not start here. Without decision records there is nothing to link outcomes to. Build Decision records and provenance first.