An auditable review answers four questions a year later.

What was checked? What was found? Who decided, and on what basis? And can any of it be reproduced? Almost every audit enquiry reduces to those four, and most QA processes can answer only the second.

The gap is usually the first and the last. Teams remember the findings and forget the rule set, so a report cannot be re-derived. Or they remember the decision and forget what it covered, so a signature looks broader than it was.

Designing for audit is mostly a matter of recording four small things at the moment they are true, rather than reconstructing them later from memory and screenshots.

A complete set is small: the version of the rule set, the findings with severities, the score, the scope statement, the decision and the signatory if there was one.

Keeping the raw draft forever is a privacy liability. Keeping nothing is an audit failure. The resolution is to decide what the record has to prove and store only that.

In most cases the claim being evidenced is that a gate ran and what it found. Findings plus an excerpt plus a date prove that. The raw file is only needed if someone will later dispute the findings themselves, which is rare and can be handled case by case.

For human reviews, the scope description and the reviewer's change notes carry the evidence. A signed statement that a specialist read the pricing claims is auditable without retaining the client's whole document.

A deterministic rule set turns an audit question into an experiment. Given the same text and the same rule version, the reviewer can re-derive the findings themselves, which removes the need to trust your logs.

Model-judged reviews cannot offer that. The same input may produce a different verdict, so the only evidence is a stored output and a promise about how it was generated. That is weaker in a way no amount of reporting fixes.

This is the practical argument for keeping the mechanical layer deterministic even if a model is used elsewhere in the pipeline. You want at least one part of the process that behaves like a calculator.

An application log records that a check happened. A report records what it said. Auditors ask the second question, and engineering teams often answer the first.

So keep the report with the deliverable, not only in a dashboard. The pull request, the CMS entry, the delivery folder. A report that lives only in a vendor console disappears when the subscription does.

The same logic favours portable formats. A PDF or a pasted block travels. A link to somebody's dashboard is a dependency disguised as evidence.

Pick three completed pieces of work at random and try to answer the four questions from the records alone, without asking anyone. Whatever you cannot answer is the gap, and it is usually the scope or the rule version.

Then fix the smallest thing that closes it. In practice that is a report attached to the delivery and two extra fields on the approval: what was reviewed, and against which rule set.

Write the policy last. A policy written before the records exist tends to describe a process nobody ran, which is the single most damaging thing to hand an auditor.

Once people know the record is read, the shape of the process changes. Overrides get written down instead of assumed, scope conversations happen before the file moves, and reviewers stop signing things they did not read.

None of that requires a heavier process. It requires four fields and the habit of keeping the report with the work.

That is also what makes an AI review defensible in a way that a satisfaction survey about AI tools never will be.