When a compliance auditor asks why model version 3.4 is in production instead of version 3.3, they're not asking a rhetorical question. They need a specific, documented answer with timestamps and actor attribution. If your answer involves opening four browser tabs and a Confluence search, you don't have an audit trail — you have the raw materials for one, scattered across systems that weren't designed to be queried together.
This is the difference between an audit trail and audit-compatible data. Most ML platforms produce the latter. Enterprise compliance needs the former.
What a proper ML audit trail contains
An audit trail for a production model version should contain every governance decision that affected that version's existence and status. Not logs. Not metrics. Decisions — the human and automated choices that moved the model through its lifecycle.
For a single model version, a complete audit trail includes: the retrain trigger event (what signal fired, when, with what measured values), the retrain proposal creation (who submitted it, which policy version governed it), each approval action (who approved or rejected, in what role, at what timestamp, with what context they were shown), the quality gate evaluation results (which gates passed, which failed, with the evaluation dataset version recorded), the promotion decision (who executed it, what the rollback point was set to), and any post-promotion events (drift alerts acknowledged, performance reviews, rollback if executed).
Each event in this chain should be structured, immutable, and queryable. Structured means machine-readable with defined fields, not a log line that requires regex to parse. Immutable means the record cannot be modified after creation — this is essential for audit integrity. Queryable means you can retrieve all events for model fraud-classifier between dates X and Y, or all retrain approvals made by role compliance-owner, without a full table scan.
Model lineage vs. audit trail: adjacent concepts, different structures
Audit trails and model lineage address different questions and have different data structures. Understanding the distinction prevents building one and assuming you have both.
Model lineage is the directed acyclic graph of artifact ancestry: which training run produced model version 3.4, what was the input dataset hash, which feature pipeline version was used, what hyperparameters were passed, and what is the ancestor chain back to the original model version. Lineage is primarily an engineering concern — it answers "how was this model built."
Audit trail is the sequence of decisions that affected the model's operational status: who approved it, under what policy, when it was promoted, whether it was ever rolled back and by whom. Audit trail is primarily a governance concern — it answers "why is this model in production."
Both are necessary. A compliance auditor conducting a review of a credit-decisioning model needs both: the lineage to verify that the model was trained on data within the consented time window using the approved feature set, and the audit trail to verify that the promotion went through the required approval chain.
The four things auditors actually ask for
Drawing on patterns from internal audit reviews of ML systems, there are four recurring evidence requests:
Point-in-time model state: "What model was serving predictions on date X?" This requires the audit trail to record promotion and rollback timestamps with enough fidelity to answer a point-in-time query. A record that says "version 3.4 was promoted at some point in Q3" doesn't answer the question. A record with UTC timestamps and an explicit "serving start" and "serving end" event does.
Decision authorization: "Who approved the retrain that produced version 3.4, and in what role?" The approval event needs to record the actor's identity, their role at the time of approval, and a reference to the policy version that defined the approval requirement. If the ML Lead who approved a retrain had their role changed three months later, the audit record should still show that they held the ML Lead role at the time of approval.
Policy compliance: "Was the retrain policy in effect at the time complied with?" This requires the audit record to store a snapshot of the policy version — not just a reference to the policy ID, which could have been updated since. The policy version that governed a decision should be immutably attached to that decision's audit record.
Exception documentation: "Were there any deviations from standard policy, and how were they handled?" Exceptions — emergency retrains under time pressure, temporary policy overrides, approvals by non-standard role holders — should be recorded as explicitly as normal events. An audit trail with no exceptions looks suspicious; exceptions are normal in operational contexts and should be documented as such, with the reasoning captured.
Connecting lineage to audit: the model version as a join key
The practical way to connect lineage and audit trail systems is the model version identifier as a shared primary key. The lineage system records that version fraud-classifier:3.4.1 was produced by training run run-2024-1102-a with dataset hash sha256:9f2c.... The audit trail records that version fraud-classifier:3.4.1 was approved by the ML Lead in a governance event at 2024-11-04T14:22:18Z.
A compliance export can then join on the model version identifier to produce a unified artifact: for version 3.4.1, here is its full provenance (lineage) and here is the complete chain of decisions that authorized its production status (audit trail). This is the answer to "why is version 3.4 in production" — lineage plus audit trail, joined at the version identifier.
The audit export problem
Structured, immutable, queryable audit data only becomes usable for compliance review when it can be exported in a format that non-engineering reviewers can read and verify. CSV export keyed by model and date range is the minimum viable audit evidence format. JSON is more flexible but requires tooling to read. PDF report generation from structured audit data reduces the barrier for external reviewers but introduces a rendering layer that can omit or distort data.
The safest approach is to export structured data (CSV or JSONL) and provide an optional rendered view, with the structured data as the authoritative source. An auditor who wants to verify the rendered report should be able to cross-reference it against the raw export without unexplained discrepancies.
The audit export capability also defines the scope of what "audit-ready" means in practice. If you can produce a clean, complete export of all governance events for a model over a given period, with no gaps and no unexplained entries, in under an hour — that is audit-ready. If producing that export requires two days of engineering work and involves manual correction of inconsistent records, you are not audit-ready, regardless of what your policy documentation says.