A surveyor signs a Level 3 Building Survey. Eighteen months later a buyer disputes a finding, and the practice's professional indemnity insurer asks a plain question: which words in that report did a person write, and which did software draft? On most AI-assisted systems that question has no clean answer. The model's contribution and the human's edits have been merged into one field, overwritten on save, with no record of who decided what or when.
That is the gap an append-only decision ledger closes. In a surveying operations system we built for a UK residential practice, every AI suggestion and every human verdict on it is written once to a ledger that has no update and no delete path. The same records then generate the survey's AI disclosure automatically. This is not document management bolted on after the fact. It is the audit trail constructed as the AI runs.
Key takeaways
- An append-only ledger has no update and no delete path, so the record is immutable by construction rather than by anyone's good behaviour after the event.
- Each entry captures the model and version, the input, the output, a three-way accept/modify/reject decision, the named surveyor and a timestamp.
- The RICS-style AI disclosure is generated from the ledger, so the disclosure cannot drift from what actually happened on the job.
- The ledger lets a board answer whether AI was used, what it suggested, who decided and whether the record could have been altered — without taking anyone's word.
- It proves the decision history, not that the decision was correct; accountability still rests with the professional, but it becomes evidenced rather than assumed.
An audit trail is only worth what its mutability allows
The phrase "audit trail" is used loosely. Plenty of systems log AI activity to a table you can edit, truncate or quietly correct. A log you can change after the event is not evidence of what happened; it is a record of what someone last decided it should say.
The distinction that matters for governance is append-only: rows are inserted, never updated, never deleted. The schema itself enforces it — there are no update or delete mutations against the ledger table in the application at all. If a suggestion was wrong, you do not edit the row. You append a new decision that supersedes it, and both remain visible. The history is immutable by construction, the same principle behind stopping AI from changing what it should only read: you make the unwanted operation impossible in the data layer rather than promising staff will not do it.
Immutability is what turns a log into an audit trail. ISO/IEC 42001, the international AI management system standard published in 2023, expects an organisation to keep documented evidence of how AI systems operate and how decisions are controlled across the lifecycle. An append-only ledger is the most direct way to produce that evidence without relying on anyone's good behaviour after the fact.
A decision ledger records the decision, not just the output
A useful AI audit trail decision ledger captures more than what the model produced. It captures what a named person did about it. In the surveying build, each suggestion-and-decision record holds:
| Field | What it captures |
|---|---|
| Model | The model and version that produced the suggestion |
| Input | The notes, photos and section context the surveyor supplied |
| Output | The text the model returned |
| Decision | Accept, modify or reject |
| Decided by | The named surveyor |
| Timestamp | When the decision was recorded |
The three-way decision is the part that does the governance work. Accept means the surveyor took the suggestion as drafted. Modify means they changed it — and the ledger holds both the original suggestion and the fact that it was altered. Reject means the suggestion was discarded and a human wrote the content instead.
This matters because "AI-assisted" is too coarse a label to defend a regulated report. A reviewer needs to know whether a specific finding was the model's wording the surveyor approved, the model's wording the surveyor rewrote, or text the surveyor produced after rejecting the suggestion outright. The ledger answers per suggestion, with a name and a time against each.
Verification in this system is also explicit and sticky. Once a surveyor verifies AI-assisted content, that verification stands and cannot be silently cleared by a later process — it has to be a recorded human act to change a recorded human act. That is the same human-in-the-loop pattern we apply elsewhere, such as the confidence floors and reason codes that let deterministic code overrule the model on invoice posting. The model assists; a named person decides; the decision is the artefact.
The ledger generates the disclosure, so the disclosure cannot drift from the facts
RICS Home Survey reports carry an AI usage disclosure, commonly handled under the practice's K5-type obligations on transparency about the tools and methods behind professional work. The honest, fragile way to produce that disclosure is to have an administrator remember which jobs used AI and write a paragraph from memory. The defensible way is to compute it from the ledger.
In our build the disclosure text is generated from the actual decision records for that job. If the ledger shows AI suggestions were accepted or modified, the report states that AI assisted in its production and that the surveyor takes full responsibility for the content of this report. If the ledger holds no AI decisions for the job, the disclosure instead states that no AI technology was used. The wording is derived from evidence, not asserted alongside it, so it cannot quietly contradict what actually happened.
That is the property a regulator or insurer is really testing. A disclosure that is hand-written can be optimistic. A disclosure computed from an immutable ledger is only ever as strong or as cautious as the record beneath it — and the record is the same one you would produce on request. The lesson generalises well beyond surveying, which is why we treat what an RICS K5 disclosure teaches every regulated profession as a sector playbook rather than a niche detail. Solicitors, accountants and consultants all sign work where the same question applies: who is accountable for the words, and can you show it.
What this gives a board, in evidence rather than assurance
Boards governing AI they did not build are right to be wary of "we have an audit trail" as a claim. The append-only decision ledger is checkable. Specifically, it lets you answer four questions for any AI-assisted output without taking anyone's word for it:
- Was AI used here? The ledger either holds decision records for the job or it does not.
- What did the model actually suggest? The original output is preserved even where the human modified or rejected it.
- Who decided, and when? Every decision carries a named person and a timestamp.
- Could the record have been altered after the fact? No — there is no update or delete path, so the trail is what it was when written.
This is the kind of living evidence that belongs in an AI risk register that is more than a spreadsheet: not a policy stating that humans review AI output, but a queryable record proving they did, on which jobs, with what verdict.
A caveat worth stating plainly. An append-only ledger proves the decision history — what was suggested, what a named person decided, and that the record is unchanged. It does not, on its own, prove the decision was correct. That still rests on the professional's judgement and the firm's competence. The ledger makes accountability traceable; it does not replace it. Used well, that is exactly the point: the human stays responsible, and the system makes that responsibility evidenced rather than assumed.
It also sits within a broader control set on the same system — AI usage logging, prompt-injection sanitisation, least-privilege per-job access, short-lived signed URLs for files, and a who-accessed-what file-access log with a 90-day retention window. The ledger is the accountability spine; these are the access and integrity controls around it. None of this required a new AI statute to justify. The UK has no single AI Act; governance here is principles-based and regulator-led, and "appropriate transparency and explainability" plus "accountability and governance" are two of the UK's five pro-innovation AI principles. An append-only decision ledger is a concrete way to demonstrate both.
For organisations processing personal data through AI, the same record supports data-protection obligations. The ICO is the UK's lead regulator wherever AI touches personal data under the UK GDPR. New Articles 22A–22D, introduced by the Data (Use and Access) Act 2025 and in force from 5 February 2026, preserve a right to human review of significant automated decisions; the ICO's updated guidance on automated decision-making is still in draft, with a consultation that closed on 29 May 2026 and final guidance expected in summer 2026. Where AI assists but a named human decides and the decision is logged, you are not making a solely-automated decision in the first place — and the ledger is the evidence that the human was in the loop, not merely named in a policy.
You can see how this control fits the full system in our anonymised AI-assisted surveying case study, and how it connects to the rest of our engineered governance on the Trust page.
Last reviewed: 29 May 2026.
If you are deploying AI into regulated work and want the audit trail built in rather than reconstructed later, talk to us about how we engineer these controls into the systems we build.
