Approval in an AI workflow needs a versioned evidence record

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, the published note on what happens when 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.

Make the reviewed version reconstructable

For a new system, I would want the approval record to retain:

• The recipient and exact draft revision.
• References to the evidence revisions used by its claims.
• The reviewer, decision time and review-policy version.
• Any conditions attached to the approval.

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.

Recheck at the action boundary

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.

Relationship state needs a separate check

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.

Test the transitions, including the review policy

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 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.