An automated decision you cannot explain is a liability, not an efficiency.

Logging is not auditability

Logs are written for engineers debugging a system now. Audit trails are read by other people — a customer disputing an outcome, a compliance reviewer, a regulator sampling a file — often years later, and they answer a different question. Not "what went wrong" but "what did you decide, and on what basis".

The gap shows up in retention, in structure and in completeness. Logs are sampled, rotated, and shaped around the code that emitted them. If the log line does not record which version of the policy was in force, no amount of retention makes it an audit trail.

What has to be recorded

To reproduce a decision rather than describe it, five things have to be kept together, with the decision itself.

The inputs

Exactly what was submitted, not a summary. A field that was absent must be distinguishable from a field that was empty.

The policy version

Which version of the logic was in force. Without this, everything else is unmoored — the same inputs produce a different answer under a policy that has since changed.

What came back from outside

The bureau response, the device signal, the sanctions hit. These change independently of you, and cannot be re-fetched to reconstruct a past decision.

The path taken

Which branches ran and which did not. "Declined" is an outcome; "declined at the affordability rule after the bureau pull returned a thin file" is an explanation.

The output

The verdict and any reasons attached to it, in the form the calling system received them.

If any one of the five is missing, you can describe the decision but not reproduce it — and describing it is what gets disputed.

Why versioning is the hard part

Most teams get inputs and outputs right and lose on the version. The reason is structural: when policy lives in application code, its version is the deploy, and the deploy is not recorded with the decision. Answering "what logic was live at 14:20 on the third of March" becomes an archaeology exercise across a deploy log and a git history.

This is the strongest practical argument for keeping decision logic as a separate versioned artifact. Not elegance — the ability to answer that question in one lookup instead of an afternoon.

Human decisions need the same treatment

Any real policy refers some cases to a person. Those are the decisions most likely to be disputed later, and the ones most often recorded worst — the automated part leaves a clean record and the human part leaves a status change and a timestamp.

The referral needs the same five elements: what the reviewer saw, what they decided, when, and under which policy the case was referred to them in the first place. A case that arrives carrying its signals and its reason is not only faster to review — it is the only version of the event that can be audited afterwards.

How this works in ArboRule

Each decision is recorded with its flow version, its input, its output, its duration and the node-by-node trace of the path taken, retrievable by decision id or filtered by flow, environment and grouping id through the history API. Referrals keep the same record: a Manual Review node pauses the run until a person answers, and a Create Case node opens a case carrying the evidence that produced it.

The point is not the storage. It is that the audit trail is produced by the run itself rather than assembled afterwards by a separate system that has to be kept in step with the logic — because a trail that depends on remembering to write it is a trail with holes exactly where the unusual decisions are.

Questions