A shared document with forty resolved comments feels reviewed. Everyone who mattered had a look, every concern was answered, every thread was closed. Then something goes wrong with the decision the document supported, and someone asks a simple question: who approved this, and what exactly did they approve?
Often nobody can say. The comment history shows activity, not a decision. The version that went out may not be the version most people commented on. The person who closed the last thread may not have had the authority to approve anything.
This was tolerable when drafts were slow and few. It stops being tolerable when an AI assistant produces drafts in minutes and revises them on request, because the number of versions multiplies and each one can change in places nobody is looking. CloudNala's position: a comment thread and an approval are two different things, and a serious AI-assisted workflow records them separately, against specific versions.
Silverleaf Brokers is fictional, and its systems and figures are illustrative. By now its advisers produce client review packs with an AI assistant and review them as HTML, with claims labelled by type, as described in Part 2. The question in this part came from its compliance officer: if a client disputes advice next year, can Silverleaf show which version of the pack the senior adviser approved, and that the client received that version?
Two state machines, not one
The confusion starts because most collaboration tools give comments and documents one combined history. It is clearer to treat them as two separate lifecycles.
A comment moves from raised, to answered, to resolved. Resolution means the person who raised it is satisfied, or the point was overtaken. It says nothing about whether the artifact as a whole is fit to use.
An artifact version moves from draft, to in review, to approved, and later to superseded. The move to approved is made by a named person with the authority to make it, for one specific version, and is recorded with the date and any conditions.
The link between the two is a rule, not an automation: an approver should not approve a version while material comments on it are unresolved. But the reverse never holds. Closing every comment does not approve anything. Several tools make it far too easy to read a fully resolved thread as a green light.
Pin feedback to the version it was made on
The second failure is quieter. A reviewer comments on version 3. The agent produces version 4. The comment, still visible and still marked as resolved, now appears beside content it never applied to.
At Silverleaf the near miss looked like this. The senior adviser reviewed a pack, checked the excess assumption of R5,000 and resolved her comment with "looks right". The adviser then asked the assistant to update the motor section. The assistant regenerated the pack and, drawing on a newer schedule, changed the excess to R2,500 in two places. The resolved comment still sat next to the excess figure saying "looks right". Anyone glancing at the history would conclude the new figure had been checked. It had not.
The fix is a rule the tooling has to support:
- every comment and every approval records the version identifier and the element it applies to;
- when a later version changes that element, the comment or approval is reopened, not inherited;
- unchanged elements may carry their earlier review forward, and the record shows that they did.
This is ordinary practice in code review, where repositories are commonly set to dismiss an approval once new commits change the reviewed code. AI-generated documents need the same behaviour, and it is one of the main reasons to keep a structured source (Markdown or data) behind the rendered HTML: you can only tell what changed between versions if the source makes it computable.
The minimum review record
For anything that supports a material decision, the review record should hold, at minimum:
| Field | Why it matters |
|---|---|
| Artifact and version identifier | Proves which content was approved |
| Source inputs and their versions | Shows what the AI worked from, including prompt and instruction versions |
| Reviewers and their comments, per version | Shows what was challenged and how it was answered |
| Open questions at approval time | Shows what was knowingly unresolved |
| Approver, role and authority | Shows the decision was made by someone entitled to make it |
| Decision and conditions | Approved, rejected, approved with conditions |
| Date and time | Places the decision in sequence with later changes |
| Distribution record | Shows which version left the organisation, and to whom |
The last row is the one most often missing. Silverleaf's compliance officer cared less about who commented than about whether the pack the client received matched the pack that was approved. A version identifier printed on the exported PDF, and stored with the approval, closes that gap cheaply.
None of this needs heavy software. A disciplined folder structure, version-stamped exports and a short approval log will do for a small team. What does not work is relying on the collaboration tool's activity feed as the record. Activity feeds are written for collaboration, not for evidence.
Who may approve what
Review records expose a question many organisations have never answered explicitly: who is allowed to approve an AI-assisted artifact, and does that change because AI was involved?
Our view is that AI involvement should not change who is accountable, but it should change what the approver checks. The senior adviser at Silverleaf was always accountable for advice leaving the firm. With an assistant in the loop, her approval now explicitly covers that the claim labels are present, that verified facts carry current sources, and that the open questions are closed. The human in the loop must show their work makes the same argument for AI-assisted decisions more generally: a signature with no visible reasoning is not oversight.
Two patterns to avoid:
- Rubber-stamp approval. The approver clicks approve on a long artifact within seconds of receiving it. Some tools record time-in-review; a pattern of very short reviews is worth noticing.
- Approval by the author. The person who prompted the assistant approves its output. For low-risk material this is fine. For anything that reaches a client, a regulator or a board, the approver should be someone other than the author.
Keep it proportionate
Not every artifact needs this. An internal brainstorm, a first-cut outline or a meeting summary can live happily in a comment thread. The trigger for a formal review record is consequence: client advice, a proposal with pricing, an architecture decision, an audit finding, anything that commits the organisation.
A useful test: if this artifact were challenged in a year, would you need to prove what it said and who stood behind it? If yes, keep the record. If no, keep the conversation.
Next: Part 4, What an AI audit should actually examine. All parts are on the series page. For how this connects to specification governance, see Govern decisions and evidence, not document volume.
How CloudNala can help
We help teams set up proportionate review records for AI-assisted work: separating comments from approvals, pinning feedback to versions, defining who may approve which kinds of artifact, and making sure what was approved is what was sent. We design this around the tools you already use rather than adding a new platform.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an AI Assurance Review or write to us at consult@cloudnala.co.za