Keeping an audit trail for a machine-drafted document
The record of which source each fact was checked against, by whom and when, is what answers a cross-examination in a sentence instead of a week of reconstruction.
An audit trail for an AI planning document is the record that lets you show, two years later, which published source each factual statement was checked against and who checked it. It is not a compliance ritual. It is the difference between answering a cross-examination at an inquiry in a sentence and spending a week reconstructing where a policy number came from, with the client watching.
Consultants who already keep this discipline for consultant-written reports need to extend it in one specific direction: recording which content was drafted and which was authored, and how each drafted fact was verified.
Why a trail matters later
Four situations where it is asked for, in rough order of likelihood.
A client asks where a figure came from. Usually benign, usually months later, usually about a policy reference or a floorspace number, and usually at a point when the person who wrote it has left.
A case officer or a statutory consultee challenges a factual statement during determination. Here the trail saves time rather than reputation, because a dated source reference resolves the point in one email.
An appeal reaches a hearing or an inquiry. Evidence given in a proof is tested, and an inspector who finds that a cited policy had been superseded at the date of the statement will discount more than the one paragraph.
A complaint or a claim. A professional institute's conduct process, or a negligence claim, turns on what a reasonably competent practitioner would have done. Having verified each fact against a named source on a named date is close to the whole defence.
What to record at drafting stage
Capture it while the work happens. Reconstruction after the fact is unreliable and reads as reconstruction.
- The brief and the instructions received, including anything the client asserted as fact.
- The inputs used to produce the draft: the site address, the constraint data and its date, the uploaded documents, the answers given in the guided flow.
- Which sections were machine-drafted and which were written by a named person.
- Every flag the draft inserted where a site fact was missing, and how each was resolved: verified, assumed with a basis, or removed.
- The version of the draft at each stage, with a date and the name of whoever changed it.
PlanScope marks missing site-specific facts with a placeholder flag rather than inventing them, which makes that fourth item straightforward: the flags are the list of open items, and the trail records what happened to each. Reports should be reviewed before submission, and PlanScope does not guarantee planning approval.
Keep the record in a single place per project rather than scattered across email. A one page register, updated as the work proceeds, outperforms a thorough system nobody fills in.
Sources used and their dates
This is the part most practices do badly, and the reason is that the sources themselves move.
The National Planning Policy Framework has been reissued more than once in recent years, with paragraph numbers renumbered and then replaced by policy codes. A citation that was correct when written can be unrecognisable to a reader holding the current edition. So record the edition and its publication date alongside every reference, and never copy a paragraph number from an earlier document without re-checking it.
Planning Practice Guidance is worse, because gov.uk pages are revised without version numbers. The page shows a last updated date, and that date is the only version marker available. Record it, and archive a copy.
What to capture for each source:
- The title, the publisher and the edition or publication date.
- The specific policy, paragraph, regulation or section relied on.
- The date you accessed it.
- A saved copy as it stood on that date, printed to a dated file rather than a bookmark.
That last point is the one that pays off. A link is not evidence, because the page behind it changes. But a dated file is.
Who verified which fact
A verification table, held with the project file and not submitted, with one row per material factual statement.
Record the statement, the source it was checked against, the status, the person who checked it and the date. Three statuses cover everything: verified against a published source, assumed with the basis stated, or supplied by the client. The third category needs the client's own email or document behind it, because a fact the client asserted and you repeated is a shared exposure rather than yours alone.
Keep it proportionate. A householder statement needs a dozen rows. A major application proof of evidence might need a hundred. The test is whether each statement a decision could turn on has a source and a name against it, and the broader question of which statements those are is the subject of what AI drafts get right and wrong in planning reports.
Review and sign-off records
Record the scope of a review as carefully as its outcome, because a review of the planning balance is not a review of the factual content and a later reader will assume otherwise.
For each review: the version reviewed, who reviewed it, what the review covered, what it excluded, the comments made, what changed as a result, and the date of sign-off. Where a reviewer signs a document, the declaration they signed and the version it attached to both need keeping, since a document revised after sign-off is not the signed document.
PlanScope's review request flow records statuses of sent, accepted, in review, changes requested, signed off and rejected, with an expiry, and those transitions give you a dated sequence for the review itself. The reviewers in the professional directory can take a draft and provide that sign-off. For specialist technical reports, qualified professional input may be required, and where a licensed or competent professional is legally required the record should name them and their competence basis.
The failure mode is a document that changes after the reviewer saw it, which is why version control when report sections are regenerated and sign-off records have to be kept together rather than separately.
Storage and retention
Set the retention period from the limitation position rather than from habit.
Contract and tort claims generally run to six years, with the latent damage provisions extending that for some claims and a long stop at fifteen years. Many practices therefore retain project files for fifteen years, which is also roughly how long a planning permission and its conditions can remain live in practical terms.
Practical requirements for storage: files in a format that will still open, source copies as dated PDFs rather than links, a naming convention that encodes project, document and version, no reliance on an individual's mailbox, and a record that survives a change of software. Exported PDFs of the register and the verification table, saved at each milestone, are more durable than a live document in a system you may not have in a decade.
One caution on content. Where a client's documents are confidential, check the current policies on the site you are using before uploading them, and keep anything sensitive out of third-party systems unless you have checked the position.
Producing the trail if challenged
Assemble it as a chronological bundle, not as a pile of files.
What a bundle needs. A short chronology of the instruction, the drafting, the verification and the sign-off. The version of the document actually submitted, with its date. The verification table, the review and sign-off records, and the dated source copies relied on, in the order they are cited.
Then a one page covering note setting out who authored what and what was verified when. An inspector, an insurer or a conduct panel reading that note should be able to see the shape of the work without opening the appendices.
Where the trail has gaps, say so plainly rather than filling them. A note recording that a particular fact was taken from a client email that no longer exists is a weaker position than a verified source, and it is a far stronger position than a reconstruction that turns out to be wrong. Explaining that distinction to a client or a committee has its own technique, covered in explaining an AI-assisted draft to a client or a committee.
Under appeal deadline pressure the trail is the first thing dropped and the first thing missed, which is why drafting to an appeal deadline without cutting corners treats the verification table as part of the document rather than as an optional extra.
This is general guidance, not legal advice; take advice on your own retention obligations and professional indemnity requirements before relying on it.
Frequently asked questions
What should an audit trail for a planning document contain?
The brief and instructions, the inputs used to produce the draft, which sections were drafted and which authored by a named person, every flag for a missing site fact and how it was resolved, a verification table of material statements, the review and sign-off records, and dated copies of every source relied on.
Why record the date a guidance page was accessed?
Because Planning Practice Guidance is revised on gov.uk without version numbers, so the last updated date shown on the page is the only version marker available. A link is not evidence, since the page behind it changes. Save a dated copy of the page as it stood when you relied on it.
How should policy citations be recorded?
With the edition and publication date alongside the policy, paragraph or code relied on. The National Planning Policy Framework has been reissued more than once, with paragraph numbers renumbered and later replaced by policy codes, so a reference that was right when written can be unrecognisable to a reader holding the current edition.
How long should project records be kept?
Set the period from the limitation position rather than habit. Contract and tort claims generally run to six years, with latent damage provisions extending that for some claims and a long stop at fifteen years. Many practices retain project files for fifteen years, in formats that will still open and without relying on an individual mailbox.
What should a review record state?
The version reviewed, who reviewed it, what the review covered and what it excluded, the comments made, what changed as a result, and the sign-off date. Scope matters as much as outcome, because a review of the planning balance is not a review of factual content and a later reader will assume otherwise.
Sources and further reading
This article is general guidance about the planning system in England and, where stated, the rest of the UK. It is not legal or professional advice. Check your local planning authority’s validation requirements and take professional advice for your specific site.