# Approval in an AI workflow needs a versioned evidence record > Source: > Published: 2026-11-09 18:42:26+00:00 A reviewer approves a sales message on Monday. On Wednesday, someone corrects the case study behind it: the result applied to a pilot, not the whole customer business. The message is still queued for Friday. This example is fictional, but it exposes a concrete engineering requirement. An approval needs to identify the content and evidence that the reviewer saw. At [MachGTM](https://machgtm.com/), the published note on [what happens when approved outreach facts change](https://machgtm.com/blog/approved-outreach-facts-change) describes a source review dated 5 November 2026. It found a fingerprint over selected step, contact and company-knowledge inputs. The sending paths compare those stored inputs again and mark changed actions stale. The note also records an important limit: whether rewritten text gets another human review depends on the configured policy. Detecting a change and requiring a new approval are separate decisions. For a new system, I would want the approval record to retain: These are proposed design fields, not a description of Mach's database schema. Their purpose is to let another person reconstruct what was approved after the current records have changed. A single boolean on the latest draft cannot explain whether a reviewer saw the latest evidence. An immutable reference to the reviewed revision can. Before dispatch, compare the inputs that matter to the approved action. If a material dependency changed, pause that action and show which sentence or recipient decision is affected. The next step should follow an explicit policy: rewrite, ask for review, remove the unsupported claim, or cancel. Automatically generating a replacement is insufficient when the changed claim requires a person's judgment. Keep this check close to the actual send. A check at scheduling time leaves a gap in which the evidence can change. A production design also needs to consider concurrent edits and duplicate dispatch; a fingerprint comparison alone does not resolve either problem. A buyer can reply while every stored fact remains unchanged. A message can be accurate and still interrupt a conversation that another teammate is handling. Keep reply, stop-contact and meeting checks separate from evidence freshness. A fresh draft must still be eligible to send. Those checks depend on receiving and matching the relevant events. Use test records to exercise four cases: change a cited fact, remove a selected source, change an unrelated note, and record a buyer reply. Inspect the resulting action and its review state in each case. Record the policy settings alongside the result. A passing stale-input check does not prove that a person reviewed the replacement or that the original evidence was true. The related note on [human approval for AI sales actions](https://machgtm.com/blog/human-approval-ai-sales-actions) covers where I would put the decision boundary. Start by making one approval reconstructable, then trace what can invalidate it before execution. *Adapted with AI from the linked MachGTM notes. Implementation observations refer to the dated source review, not a new live test. Proposed design fields and the opening scenario are illustrative.*