Six months after a decision, a regulator asks how your model arrived at it. What must you have logged at the time?

Reconstruction after the fact does not work

The instinct is to say you would re-run the model on the customer's data. Consider what that involves six months later. The feature pipeline has been refactored twice. A window definition changed from thirty days to twenty-eight. A reference table used for a lookup has been updated, and it has no history. The customer's own record has changed — their address, their transaction count, their risk band. The model has been retrained four times. Re-running produces a number, and you have no way of knowing whether it is the number that was served.

Worse, you may not be able to tell that you have got it wrong. The recomputed score will look plausible. If it differs from the logged decision you have created a discrepancy you must now explain to a regulator, and if it happens to match you have proved nothing, because you cannot demonstrate the path was the same.

So the answer to "what do you need" is: everything, recorded synchronously at decision time, by the service that made the decision. Auditability is a write-time property. It cannot be added later, which is why this question is a good filter — it separates people who have been through an audit from people who have read about lineage.

The prediction record

For every decision that carries regulatory weight, the serving path emits one immutable record. Its fields are not negotiable.

A decision identifier that is also returned to the caller and stored on whatever downstream artefact the decision produced, so the customer's declined application can be joined back to the prediction that declined it. Without this join the rest of the log is unusable in an audit, because you cannot find the right row.

The model version, as a registry identifier rather than a filename. A path like model_v3_final.pkl names nothing. A registry version resolves to an immutable artefact with lineage attached: the training dataset snapshot, the code commit, the resolved configuration, the evaluation report that was accepted at promotion, and who approved it. That indirection is what lets one short field in a high-volume log answer a long question.

The feature vector as served, with values. Not the feature names, not the query that would produce them — the actual numbers and categories the model consumed, exactly as they crossed the boundary into the model, after every transformation. This is the single most important field and the one most often missing, because it is the largest.

The identifier of the code that computed those features. If features come from a feature store, the feature-set version and the retrieval timestamp. If they are computed in the request path, the commit or image digest of the service. This matters because a value alone does not tell you what it meant: 0.34 for avg_txn_ratio is uninterpretable unless you can recover the definition in force that day.

The raw score and the decision, separately, along with the threshold or policy applied. A model outputs a probability; a business rule turns it into a refusal. If you log only the refusal, you cannot show whether a later change in outcomes came from the model or from someone moving the cut-off. And if a human overrode the model, that override, its author and its stated reason belong in the same record — an audit of an automated decision that turns out to have been made by a person is a different conversation, and you want to be the one who says so.

{
  "decision_id": "d-7f3a91c4",
  "occurred_at": "2026-01-14T09:22:41.118Z",
  "model": "credit-risk/17",            // registry version, resolves to lineage
  "feature_set": "applicant-core/9",    // definitions in force that day
  "features": { "income_band": 3, "avg_txn_ratio": 0.34, "tenure_days": 812 },
  "score": 0.7413,
  "threshold": 0.70,                    // moving this changes outcomes, not the model
  "decision": "refer",
  "override": null
}

The structure to notice is the two levels of indirection. The high-volume record carries two short version strings; the expensive detail — training data, code, evaluation, approvals — sits once in the registry, referenced by many millions of predictions.

flowchart LR
  A[Decision record<br/>d-7f3a91c4] --> B[Model version<br/>credit-risk/17]
  A --> C[Feature values<br/>as served]
  A --> D[Feature set version<br/>applicant-core/9]
  B --> E[Training snapshot<br/>+ code commit]
  B --> F[Evaluation report<br/>+ approver]
  D --> G[Transformation code<br/>commit]

The interesting property is that only the two leftmost boxes are written per request; everything to the right is written once per model or feature-set version and reached by reference.

Volume, retention and the cost objection

Logging every feature vector at high request rates is genuinely expensive, and pretending otherwise weakens the answer. Say what you would do about it. Write the records to cheap append-only object storage in a columnar format partitioned by date, not to your transactional database. Set retention from the regulatory requirement rather than from engineering taste, because the retention period is usually the longest-lived constraint in the whole design and it is often measured in years. Consider a two-tier scheme where a compact record is kept for the full retention window and verbose diagnostics expire sooner. And apply the same discipline to the log that you would to any other regulated store: immutability, access control, and evidence that it has not been edited.

Where sampling is tempting, be careful. Sampling is defensible for monitoring and indefensible for audit, because the regulator will ask about one specific decision and there is no answer that begins "we kept one in ten".

Replaying the decision and explaining it are different asks

The last distinction worth making unprompted is between two questions a regulator may pose. The first is what happened: which model, which inputs, which threshold, which outcome. The record above answers that completely, and it is what most audits actually want.

The second is why: which inputs drove the output, and would a slightly different applicant have been treated differently. That requires the artefact to be loadable and runnable on the logged vector, which means the model binary, its runtime and its preprocessing must still be executable — a container image digest, not just a serialised weights file. It may also require an attribution method to have been run and stored at the time, because a post-hoc attribution computed today against a rebuilt environment is a new claim rather than evidence. If explainability is a requirement in your domain, the explanation is part of the prediction record, not something you generate when asked.

Everything you will need in the audit has to be written by the service at the moment of the decision. By the time anyone asks, the pipeline, the reference data and the customer's own record have all moved, and recomputation produces a number you cannot defend.