In most of the decisioning systems we have looked at, the audit trail was added late. The engine was chosen for speed or price, went live, and logging got bolted on afterwards, shaped by whatever the last internal audit happened to ask about. It is treated as a compliance cost, which is why it is usually thin.
Our view is that this is the wrong way round. The record of one decision, what went in, what rule or model was in force, what came out and why, is the single most useful artefact a decision system produces. It is also, as it happens, what four different regulators are now asking for, each in their own words.
What a decision has to carry with it
Six things, and they have to be captured at the moment the decision is made, not reconstructed later. The inputs used, meaning which pieces of personal information, from where. The policy and model version in force at that moment. The reasons, in language a customer or a case worker would recognise rather than a feature-importance chart. The outcome. Who or what decided, and if a person was involved, why it was referred to them. And a timestamp.
Line those six up against the regulation we have written about over the last month and the overlap is almost total. CPS 230 wants evidence within 24 hours of a tolerance breach, which means the timestamp, the outcome and the accountable owner have to exist before the clock starts. Australia’s automated decision-making disclosure, from 10 December, wants the kinds of personal information the program used, and because the disclosure has to stay true as models change, that is really a per-decision question. MAS wants a decision explained to the customer, with the version that produced it. New Zealand’s Privacy Act gives a customer the right to see what you held and to correct it, which is only meaningful if the correction reaches the next decision.
In a nutshell: it is one artefact. Firms that build it once, properly, answer all four. Firms that build four different compliance extracts on top of a thin log will be reconciling them for years.
The benefit nobody prices in
The part that gets missed when the record is treated as a cost is what it does for the business on a normal Tuesday.
Because every decision is stamped with the policy version that made it, policy can change without a release cycle and without losing history. Risk tightens the hardship threshold on 1 March, the change goes live as configuration, and the question “what was true on 12 February” still has an exact answer.
That same stamp is how you catch a system that keeps running but decides badly. Compare outcomes across versions, or across a month, and the drift is visible in the record long before a complaint surfaces it. It is what we described in the CPS 230 piece as the quieter failure mode, the one no availability alert catches, and the decision record is the only place it shows up early.
It is also, increasingly, what procurement asks for. A hosted decision engine is likely a material service provider under CPS 230, and the due diligence question is not “do you keep logs” but “can we get the record out, in a form we can query, if we leave”. A vendor that can answer that quickly was built with the record in mind. One that changes the subject was not.
The cheapest moment to design the record is before the first decision runs. Retrofitting it is the reconstruction exercise we keep describing, done under an inspection deadline. That is the one design choice we made first in CxOS: the record travels with the decision, from the day the first one is made.