JSJidoSeal

A defensible audit trail for AI-edited documentation

What to record when Claude Code, GitHub Copilot, Cursor or a local model edits your controlled documents, which ISO 9001 clauses that record evidences, and where git alone falls short. Last reviewed 23 September 2026.

The short answer

An audit trail is defensible when you can show five things about any version of a controlled document:

  1. What changed: the diff.
  2. Who or what made the change: the person accountable, and the AI tool if one was involved.
  3. Who approved it: which person reviewed and approved the change, and when.
  4. That nothing has been altered since: the record is intact.
  5. How to go back: the previous version can be restored.

In a git-based documentation set, those five things come from six pieces:

  • protected history;
  • a commit trailer that names the AI tool;
  • a human approval on every merge into the controlled branch;
  • frontmatter provenance that keeps "who wrote it" apart from "who confirmed it";
  • for tools that edit files in bulk, their own append-only log;
  • a written retention rule.

The ISO 9001 clauses this record evidences

ISO 9001's document-control clauses don't mention AI, but they already cover everything an AI edit can disturb. Clause numbers and wording below are from ISO 9001:2015. For ISO 9001:2026, published comparisons report that clause 7.5 is unchanged apart from wording, and the Harmonized Structure the new edition adopts keeps the shared parts of this text.

Clause What it asks What it means for AI edits
7.5.2 c) "review and approval for suitability and adequacy", when creating and updating A person approves each AI-assisted change before it becomes the controlled version.
7.5.3.1 b) "adequately protected (e.g. from loss of confidentiality, improper use, or loss of integrity)" No tool can silently alter controlled content or its history.
7.5.3.2 c) "control of changes (e.g. version control)" Every change is a recorded, attributable version.
7.5.3.2 d) "retention and disposition" You decide how long approvals, logs and snapshots are kept.
7.5.3.2, records "Documented information retained as evidence of conformity shall be protected from unintended alterations." Approval records and logs live somewhere an agent can't rewrite them.

None of these clauses prescribes a mechanism; the pieces below are one reasonable way to meet them. For how the same clauses map onto frontmatter keys in general, see ISO 9001 clause 7.5.2 as markdown frontmatter.

1. History that can't be quietly rewritten

Git records every change, but anyone with push rights can rewrite history on a branch that isn't protected. So protect the branch that holds controlled documents: no force-pushes, no deletion, and changes only through reviewed merges.

  • Stronger evidence of authorship. If you need proof of who made a commit, sign commits or release tags.
  • Keep agents off the protected branch. An agent can propose a change; a person merges it.

2. Name the tool in the commit

Open-source projects have settled on a commit trailer for this.

  • The Linux kernel. Its guidance for AI coding assistants says "AI agents MUST NOT add Signed-off-by tags. Only humans can legally certify the Developer Certificate of Origin (DCO)", and that contributions "should include an Assisted-by tag".
  • Fedora. The AI-assisted contributions policy its Council approved in October 2025 keeps the contributor as the author, fully accountable for what they submit. It says contributors MUST disclose AI use when a significant part of a contribution is taken from a tool without changes, and it recommends an Assisted-by: commit trailer for contributions tracked in git.

The same convention works in a documentation repository:

Clarify torque values for M8 fasteners in QP-08-14

Updated table 2 to match the supplier's revised datasheet.

Assisted-by: <tool name> <model and version>

The kernel's own format is Assisted-by: LLM [TOOL1] [TOOL2], where the bracketed items are optional analysis tools. In a documentation repository, also record the model and its version: the same tool name can mean different models over time.

Whatever your tool does by default, check two things. The commit should identify the person accountable for the change, and it should name the tool.

3. A human approval on every merge

Require at least one approving review from someone other than the author before a change reaches the controlled branch. In a very small team that may not be possible. If so, say so in your procedure; don't pretend otherwise.

Two gaps in the git-only approach need closing.

  • Review records aren't in git. Pull-request approvals and comments live on the forge (GitHub, GitLab), not in the repository, so cloning the repository doesn't take them with it. OpenRegulatory flags exactly this in its guide to running a QMS on GitHub. Archive the approvals, or copy them into the file (next section).
  • An approval is not always an electronic signature. In regulated sectors, rules such as the FDA's 21 CFR Part 11 may require more than a pull-request approval. OpenRegulatory is unsure GitHub alone meets them. Check your sector's rules.

4. Provenance in the file: keep "wrote" apart from "confirmed"

The Open Knowledge Format, an open specification published by Google Cloud, keeps authorship and confirmation apart on purpose.

  • Two fields, two facts (§5.2). generated records how the current content was produced. verified records who confirmed it, "because who wrote a concept need not be who confirmed it."
  • Actors (§7). <producer>/<version> identifies an agent or tool, human:<id> a person, and process:<id> an automated process. Producers MUST use human: for content a person wrote or confirmed.
  • Trust tiers (§5.3). Consumers derive a tier from verified: unverified, machine-confirmed, or human-reviewed.
---
title: Torque values for M8 fasteners
owner: Manufacturing Engineering Lead
status: stable
generated: { by: <tool>/<model-version>, at: 2026-09-22T14:10:00Z }
verified:
  - { by: human:j.alvarez, at: 2026-09-23T09:05:00Z }
---

A page an agent wrote, with no human: entry under verified, can never pass as human-reviewed. Anyone, and any tool, can see that from the file. For what this provenance evidences in a knowledge base, see What ISO 30401 asks of a knowledge base.

5. Keep accountability fields human-only

Some fields are claims about people: owner, approved_by, a verified entry with a human: actor, and reviewed_at. An AI tool should never fill these in on its own. A tool that writes reviewed_at: today has manufactured evidence of a review that didn't happen. Let agents draft content and propose metadata, and let people sign. For setting and recording a review cycle you can keep, see Does ISO 9001 require periodic document review?

6. When a tool edits many files, it needs its own log

A single run of a bulk edit can touch hundreds of files: adding frontmatter across a vault, regenerating summaries, fixing links. One big commit hides the detail. A bulk-edit tool you can defend:

  • asks before writing, and records that consent;
  • snapshots each file before changing it, so any single file can be restored;
  • refuses to write to a file that changed after it was read;
  • appends one log line per file: which file, what was added, the hash before and after, who authorized the run, and when;
  • chains each log line to the previous one by hash, so a deleted or edited line is detectable (ideally across runs too, so that a whole missing run shows up);
  • keeps that log outside anything the tool itself rewrites.

JidoSeal's free Self-Check is a bulk editor of this kind, so here is what it does and doesn't do. Before it fixes frontmatter in your browser, it lists every file and every value it is about to write, marking which values you typed and which it suggested, and you can untick any file. It writes nothing until you confirm, refuses to write if the files changed after that list was drawn up, touches only the frontmatter block, and never fills in an owner or a review date without your say-so. You can undo from the page for as long as the tab stays open. It keeps no log and no snapshots of its own, so keep the folder in git and let your commits be the record, with the tool named in the trailer. Fixes are written into your files in Chrome or Edge; other browsers show them as a preview. Pick a folder, scan it: the scan and the fixes are free, and your files never leave your machine.

7. Decide what you keep, and for how long

Clause 7.5.3.2 d) asks for retention and disposition, so write down how long you keep approvals, tool logs and snapshots. Snapshots are bulky and can expire. Approvals and logs are small, and they're your evidence, so keep them longest.

What won't hold up

  • AI edits committed under a person's name, with no mention of the tool.
  • Approvals that exist only in a chat thread.
  • Review dates stamped by a script.
  • Force-pushed history on the controlled branch.
  • Logs the agent itself can edit.

Checklist

  • Controlled branch protected: no force-pushes, reviewed merges only
  • Commit trailer names the AI tool and model version
  • Human approval by someone other than the author, archived outside the forge
  • Frontmatter keeps generated apart from verified; human: only for people
  • Owner, approval and review fields written by people only
  • Bulk-edit tools: consent, per-file snapshots, a freshness check, and a hash-chained per-file log (or, if the tool keeps none, a git commit per run that names it)
  • Written retention rule for approvals, logs and snapshots
  • Sector e-signature rules checked (for example 21 CFR Part 11)

Sources