Ask most teams to explain, six months after the fact, exactly what went into a specific report and who signed off on it, and the honest answer is usually “let me check” followed by a search through email and shared drives. The deliverable exists. The story of how it got there does not.

01. Why this becomes a problem later, not now

At the moment a piece of work is issued, everyone involved remembers how it happened — who reviewed it, what source data it drew on, why a particular judgement call was made. That context evaporates within weeks, and it evaporates faster than anyone expects, because nobody was writing it down at the time; it just lived in people’s memory. The gap only becomes visible when someone actually needs the answer: a client query, a compliance review, a dispute about what was agreed.

02. What an audit trail actually records

Not a general sense that the process was followed — specific, checkable facts:

  • What was used: the source material and evidence a piece of work drew on, attributed to the item it supports rather than floating loose in a folder.
  • Who approved it: a named, accountable role, not an email that might have been a yes.
  • When: a timestamp tied to a specific action, not an estimate.
  • On which version: because work gets revised, and “the report” is not one static thing across its lifecycle — it is a sequence of versions, and the trail needs to say which one actually went out.

03. Why this matters more, not less, once AI is involved

Once a workflow includes AI-assisted drafting, reviewed and approved by a person before anything ships, the audit trail is what proves that sequence actually happened for a specific piece of work — not just that the workflow is designed to work that way in general. It is the difference between a policy and evidence that the policy was followed, for this deliverable, on this date. The commitments themselves are set out in what we actually do with your data.

04. Where this lives in what we build

Traceability is one of the four control mechanisms built into every connected delivery system, alongside access, testing, and reporting — not bolted on afterwards because a reviewer asked for it. An audit trail runs from source material through approval to issued output, and it is what lets a quality or compliance reviewer answer a specific question about a specific piece of work without having to ask the person who happened to work on it and hope they remember.

05. What it actually gets used for

Rarely for the reason people initially build it. Most audit trails exist because a compliance reviewer required one, and then get used, months later, for something entirely different: settling a disagreement about what was agreed, confirming a figure that is now being questioned, or simply answering “why does this say what it says” when the person who wrote it has moved to a different project. That is the actual test of whether a trail was built properly — not whether it exists, but whether it answers the question when someone finally needs it to.

See the full set of governance commitments this sits alongside — access, review, testing and exit: how the work is controlled →