LLM failure modes, calculations, non-determinism, hallucination and the audit trail

An expense-audit agent applies the policy well, but every now and then it adds up a report’s totals wrong and flags the wrong person. At another company, a lender plans to answer auditors by regenerating the explanations for its credit pre-screenings at temperature zero, “so they come out the same”. Both designs treat the model as something it isn’t.

What an LLM is not

An LLM is not a calculator, a database or a deterministic system. Each known failure mode has its control, and that control is almost never one more instruction in the prompt:

Failure mode	What it looks like	Control
Arithmetic and exact calculations	totals, conversions or dates calculated wrong	a calculation tool or code, and validating the result outside the model
Non-determinism	the same input gives different outputs, even at temperature zero	store what was produced; never reconstruct by regenerating
Hallucination	invented data, quotes or policies, stated confidently	grounding in documents, verifiable citations, permission to say “I don’t know”
Knowledge cutoff	outdated information presented as current	retrieve from current sources with their date
Drift in long contexts	rules followed less in long conversations	controls outside the model (layered guardrails lesson)
Poorly calibrated confidence	sounds just as sure when right as when wrong	combine stated confidence with verifiable signals: validations, matching sources, business rules

The division of labor is the central idea: the model does what it does well (interpreting, applying judgment, writing) and delegates what has to be exact. In the expense agent, the policy stays with the model and a tool calculates the totals, with a check in code before anyone is flagged.

The audit trail

If a regulator or a customer asks “why was this decided?”, the answer can’t depend on running the model again. Besides the output possibly varying, between the decision and the audit the prompt, the model and the external data all change. The audit trail stores, for each decision:

• the inputs as they were used, including retrieved documents and third-party data consulted;
• the prompt version, model ID and parameters;
• the tool calls and their results;
• the full output and what the reviewer did next, if there was one;
• date and time, with an identifier that ties everything together.

That record is designed as one more requirement: retention under the applicable regulation, restricted access and handling of the personal data it contains. Pinning the prompt and the model forever doesn’t replace it; it only freezes the system without guaranteeing that regeneration will match.

The usual traps

• Lowering the temperature to zero so “the sums always come out the same”: it makes the same mistake more consistently.
• Asking the model to reason through each sum step by step or moving to a larger one: fewer mistakes, but still not exact.
• Planning the audit around regenerating outputs, even at temperature zero or with top_k set to one.
• Storing only the explanation text, without the inputs that produced it.
• Using the model’s stated confidence as the only gate for deciding without review.

On the exam

If the scenario shows calculation errors while the rest of the judgment works, look for the option that delegates the calculation to a tool or code and validates outside the model. If someone wants to reconstruct past decisions by regenerating them, the answer is to persist inputs, versions and output as the record. Rule out any option that tries to make the model exact or deterministic through parameters.