If the Lineage of a Decision Ends at an LLM, an Auditor Cannot Accept It

Every automated decision has a lineage. Where it terminates decides whether the decision can be defended, and across most enterprise AI architectures it terminates somewhere that is not a reason.

Kognitos Nov 14, 2026

Four wireframe chains running left to right, the top three fraying into loose strands where they cross a dashed line while the bottom chain terminates in a solid lime anchor block

TL;DR

Every automated decision has a lineage: a chain of why, running back from the action to whatever ultimately authorized it. Where that chain terminates determines whether the decision can be defended. Across most enterprise AI architectures the chain ends at a prompt, a confidence score, or a screen recording. None of those is a reason, and an auditor cannot accept any of them.

Key Takeaways: Trace a decision backwards and the chain stops somewhere. For a Copilot build it stops at a prompt. For an LLM agent it stops at a confidence score. For RPA it stops at a click log. Each is a record of behavior rather than authority. A chain that terminates in an approved, versioned rule is the only one that answers the question asked.

The question behind every audit question

Auditors ask many things, but most of them reduce to one.

Why did this happen?

Not what happened. The what is usually visible, in the ledger, the system of record, the log. The question is why this particular action was taken on this particular transaction, and whether the thing that decided it was permitted to decide it.

Answering requires following a chain backwards. The payment went out because the invoice was approved. The invoice was approved because it matched the purchase order within tolerance. The tolerance is two percent because a policy says so. The policy was approved by the controller in March.

That chain is the lineage of the decision. Every link is a step from the action toward the authority behind it, and the chain is only as good as where it stops.

Where the chain stops

Here is the test, and it is unusually clean for something this consequential. Take one automated decision from last quarter and trace it backwards until you cannot go further. The terminal point tells you what you have.

It stops at a prompt. Common where the automation was built on a general-purpose assistant. The chain runs: the action happened because the model produced this output, because this prompt was given. Follow it one more step and there is nothing. Why did that prompt produce that output on that input? Nobody can say, and the same prompt against a different model version may not produce it again.
It stops at a confidence score. Common with LLM agents. The chain runs: the action happened because the agent decided, and the agent was 94 percent confident. A confidence score is a statement about the model’s internal state. It is not a reason. “The system was fairly sure” does not answer why a particular rule applied to a particular transaction, and the number carries no information about whether the decision was correct.
It stops at a screen recording. Common with RPA. The chain runs: the action happened because the bot clicked these fields in this order. That is an accurate and complete account of behavior that explains nothing about intent. It tells you what was done, never why that was the right thing to do.
It stops at vendor configuration. Common with ERP-embedded AI. The chain runs: the action happened because the feature is configured this way. The logic beneath the configuration belongs to the vendor, and you cannot inspect it, test it, or explain it to someone who asks.

Four architectures. Four terminal points. Not one of them is a reason.

Why “the model decided” fails as evidence

It is worth being specific about why an auditor rejects this, because it is not conservatism.

It is not reproducible. Testing operating effectiveness assumes a control behaves consistently. If the same inputs can produce a different output, there is no control to test, only a history of outcomes. A sample proves nothing about the population, because the population has no fixed behavior.
It is not attributable. Controls have owners. An owner accepts responsibility for a control operating as designed. Nobody can own a decision they cannot explain, which means that in practice the control has no owner even where a name appears on the matrix.
Design cannot be evaluated. PCAOB AS 2201 requires that a control’s design be assessed, not only its operation. Design means what the control is meant to do. Where the deciding component is a model, there is no design in the sense the standard means, only observed behavior.
It cannot be reconstructed. COSO’s 2026 guidance on internal control over generative AI expects reasoning to be reconstructable rather than outputs merely recorded. A prompt and a response are not a reconstruction.

So the rejection is not about AI. It is that a decision nobody can explain was never a control in the first place, and automating it did not make it one.

The chain that works

A lineage that survives the question terminates in a rule that a person approved.

The action was taken because a rule required it. That rule is written in language the control owner reads. The version in force at the time is identifiable. The person who approved that version is identifiable. And running the same inputs against that version today produces the same action.

Notice what has been removed. There is no step at which the explanation becomes “the system determined.” Every link is either a fact about the transaction or a rule a human approved.

This is not an argument against using models. Models are extremely good at the step they belong in: reading the invoice, interpreting the policy document, extracting the date of loss from a narrative, understanding an instruction written in plain English. Those are perception and language tasks, and the alternative to a model doing them is a person doing them more slowly.

The argument is about which step the model occupies. Reading is a model problem. Deciding is a rules problem. Where an architecture lets the model do both, the lineage terminates at the model, and the chain breaks exactly where the auditor starts pulling.

What this looks like in practice

For any decision, the record should contain:

The exact input the system received
Where a model was used to interpret that input, its determination and the threshold it had to clear
The rule that fired, and the version of that rule in force at the time
The action taken in the system of record
Who reviewed it, if anyone, and when
A reproduction of the same decision on any later date

The last item is the one that converts a log into a control. A record tells you what happened once. A reproduction demonstrates what the system does, which is what operating effectiveness means and what a walkthrough is actually testing.

Kognitos is built around this separation. A language model drafts the procedure and a person approves it. A symbolic executor runs that approved procedure, and every write comes from a versioned rule rather than from the model. Every run is recorded in plain English with the inputs, the rules applied and the actions taken, and any decision can be replayed. Big Four audit firms have accepted these logs as primary SOX 404 evidence.

For related material, see our guides on deterministic AI, agent observability, hallucination-free AI, SOX compliance software, and what your SOX auditor will ask about AI automation. To trace a decision end to end in a working system, book a demo or try the platform.

Run the test

Take one automated decision from last quarter. Not a representative one, a specific one, with a transaction number.

Ask why it happened. Then ask why again, of each answer, until you cannot go further.

Write down where the chain stopped.

If it stopped at a rule someone approved, you have a control. If it stopped at a prompt, a confidence score, a click log or a vendor setting, you have an automated process that has not yet been made into a control, and the gap will be found by someone else on their schedule rather than yours.

Frequently Asked Questions

Decision lineage is the chain of reasons connecting an automated action back to whatever authorized it: the action, the rule that required it, the version of that rule in force, and the person who approved it. Where the chain terminates determines whether the decision can be explained and defended.

For four reasons. It is not reproducible, so operating effectiveness cannot be tested. It is not attributable, because nobody can own a decision they cannot explain. Control design cannot be evaluated as PCAOB AS 2201 requires, since there is observed behavior rather than design. And it cannot be reconstructed, which COSO’s 2026 guidance on generative AI expects.

No. A confidence score describes the model’s internal state, not the reason for an action. It does not identify which rule applied to a transaction, carries no information about whether the decision was correct, and cannot be used to demonstrate that a control operated as designed.

No. It means the model should occupy the step it is good at. Reading documents, interpreting language and extracting meaning are model tasks. Deciding what action to take is a rules task. Where the architecture keeps those separate, the model improves the process without the lineage terminating at it.

The exact input received, the model’s determination and threshold where a model interpreted the input, the rule and rule version that fired, the action taken in the system of record, the reviewer and timestamp where applicable, and the ability to reproduce the same decision on a later date.

Take one specific automated decision from last quarter and ask why it happened, then ask why of each answer until you can go no further. Record where the chain stopped. A chain ending in an approved, versioned rule is a control. A chain ending at a prompt, a confidence score, a click log or a vendor configuration is not.