Decision lineage in AI: how models, rules, policy and people make one outcome

The model said review. The claim was denied.

An insurer's AI application reviews a $78,000 reimbursement claim with complete documentation for a covered event. The model returns a structured fraud-risk proposal: score 0.82, recommendation "refer to specialist". It's advisory. It doesn't say deny.

A coverage check confirms the policy is active, the service is covered and the documents are present. The policy service returns "review required", with an obligation: no denial before a specialist decides. A specialist reviews the case and chooses "open investigation". They haven't approved payment, and they haven't denied the claim. The intended state is investigation pending.

The downstream integration accepts only one boolean field, approved. Anything other than "approve payment" maps to false. The claims platform reads false as denied, changes the claim and sends a denial notice.

Every component did its job. The application kept the outputs of each decision. It lost what each output was allowed to mean.

Is an AI outcome one decision?

Rarely. A consequential AI outcome usually combines several judgments, each with a different job: an observation, a model proposal, a validation, a policy decision, a routing choice, a human judgment, an authorization to act and a confirmation of what happened.

The role isn't set by the technology. A rule can be advisory. A model output can be binding in a low-stakes path if the workflow gives it that role and the controls are met. A person can recommend, approve, deny, adjudicate or override. The application has to declare the role rather than infer authority from whoever produced the output.

Decision lineage, defined

It's narrower than full execution lineage, which also covers context, identity, waits, retries and external effects. And it's richer than a list of model calls and approvals. Context records show what information was available. Decision lineage shows how the application's judgments used it, and which one made the outcome binding.

What should a decision record contain?

Each judgment needs its own record: what it was about, who or what produced it, the evidence and versions it used, its result and status, its role, when it stops being valid, and its links to earlier and later decisions.

In practice that means:

• a stable decision ID and type, and the producer (model, rule, policy service, person or runtime check);
• the workflow version, run, step and contract it belongs to;
• the exact proposal evaluated, with a digest;
• the evidence used, assumptions made and anything excluded;
• the result, alternatives considered, any uncertainty and the threshold applied;
• its role, scope, validity conditions and expiry;
• its status: accepted, rejected, escalated, superseded or committed;
• links to the decisions before and after it.

It doesn't need to copy every document or model payload. References, digests and versions pointing to the systems that own them are enough.

Declare what each decision may do

Declaring roles stops a common leak: a proposal passes through several systems and is gradually treated as a fact, then a permission, then an action, though no step ever earned those changes.

Proposals shouldn't become facts by accident

Give each judgment an explicit status and govern every change of status. A typical path runs proposed, then validated, then permitted by policy, then authorized, then committed. Along the way it may be rejected, escalated for review, superseded, expired or flagged for revalidation. Not every case follows the same path; some run in parallel, some are denied straight away, some low-risk proposals skip review.

What matters is that each status change is explicit, attributable and versioned. Valid JSON doesn't make a model output authorized. Opening an investigation isn't approval to deny. A policy "permit" isn't proof the action happened.

Link decisions with meaning, not timestamps

A link between two decisions should say how one became evidence, a constraint, a trigger or the authorization for the next. For example: the model's fraud_risk field mapped to the policy fact specialist_review_score under mapping version 7; a coverage result blocking auto-denial even with a high risk score; a policy obligation creating a review task rather than a notification; a reviewer authorizing "open investigation" but not "deny claim"; a current-state check invalidating an approval after the amount changed.

Without explicit links, investigators infer meaning from timestamps, field names and which service called which. That shows order. It can't prove one decision was allowed to constrain or authorize another. In the opening case, a link stating "reviewer authorized: open investigation" would have made the boolean mapping visibly wrong.

Keep disagreement and overrides visible

Real applications disagree with themselves: two models differ, a proposal breaks a rule, policy requires review despite high confidence, a person rejects a recommendation, a later check invalidates an earlier decision. Record all of it.

When a later decision replaces an earlier one, record that it did, for which proposal and scope. When someone overrides, record it as a new decision with their authority, reason, evidence, policy basis, conditions and expiry, and keep the original. A person can override only when policy grants that authority and separation-of-duty rules are met. Otherwise it's another proposal, or an unauthorized deviation.

Confidence routes. Authority decides.

A confidence score can route a case. It can't decide whether a consequential action is allowed. Record what the score represented, which threshold and version turned it into a route, what that route was, and which policy governed the threshold. (See confidence escalation.)

Human involvement needs the same precision. Reviewing evidence, confirming a fact, challenging a result, approving a proposal, adjudicating a conflict, authorizing an exception and opening an investigation are different decisions. Record which one happened, what the reviewer saw, their authority and exactly what it allowed.

Decisions expire

A decision can be right when made and wrong to rely on later. During a long wait, the amount or evidence changes, a reviewer loses authority, the record is edited, the policy or threshold is updated. Give each consequential decision validity conditions: the proposal digest, record version, authority, policy version, scope and expiry. Before resuming or acting, recheck them, or record why the earlier decision expired and needs a new one.

Follow the decisions through to the effect

A decision chain that stops at the model recommendation, the policy result, the approval or the API request is incomplete. Continue through the final authorization to act, the stable operation ID, each attempt, and the confirmation from the system of record. Then you can show which decisions were accepted, which were rejected or replaced, what authorized the action, and whether what happened matched what was authorized.

Make this testable before go-live. For each consequential path, list the decisions, roles, links and checks that must exist, and flag any path where a model proposal connects straight to an action, several outcomes collapse into one boolean, or an override has no declared authority.

Common anti-patterns

Ten rules for decision lineage

1. Treat proposals, checks, policy decisions, routing, human judgments and confirmations as different things.
2. Declare each decision's role; don't infer it from the technology.
3. Bind each decision to the exact proposal, evidence and versions it used.
4. Link decisions with meaning: mapping, threshold, obligation, authorization.
5. Keep rejected, escalated, expired and replaced decisions.
6. Record overrides as new, authorized decisions that keep the original.
7. Record exactly what a reviewer decided and what it allowed.
8. Recheck decisions after material changes before acting.
9. Follow the chain to the confirmed effect.
10. Never claim the record shows the model's private reasoning.

The result: one accountable outcome

AI outcomes get attributed to one model, one rule or one reviewer. In practice they come from a network of judgments spread across the application. Decision lineage gives that network a precise form: which proposals existed, what role each decision played, what evidence and constraints applied, how disagreement was handled, which decision became binding, and whether the effect matched.

That doesn't diminish models, rules, policy or people. It gives each a defined place, and stops any one of them from quietly borrowing another's authority.