Summary: Every AI platform claims audit trails. Most mean logs: a record that things happened. Regulated work needs a record of why the outcome followed: which policy version fired, on what data, extracted from which page, reviewed by whom. We call that artifact the why-trail. This post defines it, contrasts it with ordinary logging, and explains why it has to be generated with the decision rather than assembled after an exam notice arrives.
”The AI decided” is not an answer
When an examiner, an auditor, or opposing counsel asks about a decision, the questions are always the same four:
- Which rule was in effect at the moment of the decision, and which version of it?
- What data did the rule evaluate, exactly?
- Where did that data come from: which document, which page, which field?
- Which human reviewed or overrode it, and when?
An execution log answers none of these. It tells you the model was invoked at 14:32 and returned in 2.1 seconds. Between the invocation and the outcome sits everything a regulator actually cares about.
Anatomy of a why-trail
A why-trail is the complete causal record of one decision:
- Policy version, and profile. Not just “credit policy v12” but the exact profile that governed this case’s jurisdiction, counterparty, and product.
- Data values evaluated. The numbers and facts the rules actually ran against.
- Evidence pointers. Each value linked to its source: document, page, character offset. Click from the decision to the pixel it came from. This is the property that turns extraction from trust-me into show-me, and it is built into MightyBot’s document pipeline.
- Evaluation results and timestamps. Which rules passed, failed, or flagged, and when.
- Human actions. Review, approval, override, escalation, with the reviewer and the context they saw.
- The final determination, connected to all of the above.
The defining property is provenance by construction: the trail is emitted as the workflow executes, because the execution itself is deterministic enough to record. Reconstruction after the fact is where audit projects go to die: analysts rebuilding evidence from logs, screenshots, and memory, weeks after the exam letter.
Why architecture decides whether you can have one
A why-trail is cheap for a deterministic system and nearly impossible for an improvising one.
A compiled execution plan runs the same steps on the same inputs every time; recording why is a side effect of running. A reasoning-loop agent that improvises its path per case has no stable structure to record: two identical cases can take different routes to different intermediate conclusions, and the log of what it did cannot be replayed into why it decided.
This is also why bolting audit on afterward fails. If extraction did not carry evidence pointers at runtime, no amount of post-processing can attach true provenance; the source of a number that was never linked to a page is a guess.
The reruns test
One question separates real why-trails from marketing: can you rerun the decision under the original rules? When policy has changed since the decision, a real system replays against the policy snapshot that was in effect, and backtests proposed rule changes against history the same way. If the platform can only evaluate under current configuration, its audit story is a screenshot, not a trail.
That test, plus the four examiner questions above, will sort any vendor list quickly. For the full compliance architecture around why-trails, including review gates and exportable decision records, see the compliance infrastructure page; for how this plays in a live regulated deployment, the Built case shows the why-trail carrying production lending volume.
