In this article
The question
I regard approval as a decision about a particular draft, for a particular recipient, using particular facts. If those facts change while the message waits, I want a deliberate decision about what happens next.
My work in regulated AI at Leucine gives me a reference point. A claim had to trace back to a source record before it could be used. I bring that standard to Mach: keep the support for a claim, the condition attached to it and what remains unknown. That support needs to survive after someone approves the words.
A contact can change jobs. A customer result can turn out to cover one project instead of a company-wide rollout. The approval may still be recorded, while the meaning of the draft has changed.
Approval belongs to the facts that were reviewed
The following example is fictional. A seller approves a message to a head of operations on Monday. It includes a customer result and is scheduled for Friday.
On Wednesday, a colleague corrects the case study. The result applied to a pilot, and the approved sentence leaves that limit out.
I would want the Friday decision to include that correction. The reviewer should see the old sentence, the source and the narrower claim now supported. Asking a sender to remember every correction made while messages wait puts a hidden job on the team.
This is why I want research to retain the exact support for a claim. In an r/CRM discussion[1], u/Unusual_Sweet5410 described AI notes turning “maybe in Q4 if security approves it” into “planning a Q4 rollout.” The example concerns a sales note, not an approved outbound message. But removing the condition changes a possible plan into something that sounds committed.
u/marthaforester1[2] described a different working practice: “I’d keep the transcript and not push the whole summary into CRM.” The commenter checks prices, timelines and next steps personally. That is one person's practice, without proof that transcripts catch every error.
My read is that the source and its conditions need to travel with the claim. A polished sentence that loses them is harder to review, even if someone approved an earlier version.
What I want a changed draft to show
A notice saying “draft is stale” leaves the reviewer searching for the reason. I want the change to be visible enough to decide whether to rewrite, remove the claim or stop the action.
| What changed? | What I would check | Decision needed |
|---|---|---|
| A case-study scope was corrected | The original result and its revised limit | Rewrite or remove the proof. |
| The contact changed roles | The current role and why this person was chosen | Keep the recipient or research another person. |
| A selected source disappeared | Which sentence depended on it and what evidence remains | Find support or leave the claim out. |
| An unrelated internal note was corrected | Whether it affects the words or recipient | Avoid restarting review without a reason. |
This is the review experience I want, rather than a claim that Mach already presents every comparison in this table. A material buyer-facing claim deserves more attention than a spelling correction to an unrelated note. I want the policy to explain that difference.
Google's production-ML guidance[3] asks how a team will notice changes in upstream inputs. For a sales message, I would add a question: does the change alter what we are entitled to tell this buyer?
What Mach checks today
Mach's playbook source provides part of this check. When it writes a message, it records a fingerprint calculated from selected inputs: the drawn step, the person's recorded name, title and company, and selected Brain records associated with the words. The task and connected-send paths calculate it again before proceeding.
A difference marks the action stale so the step can be planned and written again. Hiding or removing a selected Brain record can also change the fingerprint.
That gives the changed information a consequence. The remaining approval decision depends on the configured review policy. Fresh wording can proceed without another routine human review under some settings.
For a consequential change, my bar is that the team knows who must reconsider it. I would test that setting explicitly. A freshness check alone does not establish that another person will inspect the revised claim.
The check also compares stored information. It cannot discover a job change that never reached the person's record, or prove that the original source was correct. Research still has to find and assess the evidence.
A reply can change the action while the facts stay true
Imagine the buyer replies to a colleague on Thursday. The case study may remain accurate. The scheduled introduction may now interrupt an existing conversation.
I want those decisions kept separate. One concerns whether the words remain supported. The other concerns whether the team should take this action at all. A contact-stop request belongs in the latter decision; changing the copy cannot resolve it.
The playbook engine has separate checks for recorded replies, meetings, contact stops and company activity. Their usefulness still depends on the relevant information being received and matched. I would not infer a complete view of the relationship from an unchanged fingerprint.
Test the next decision
Before using this policy with buyers, I would rehearse 2 cases on test records. First, change a stored fact used in an approved draft and inspect both the action and its review state. Then record a reply for a test person and inspect the next action.
Keep the settings beside the result. A successful fact-change check cannot establish that the reply check works, or that every original source is current.
For the wider permission decision, see when an AI sales action should ask a person. I want a saved approval to remain understandable when someone opens it later: these were the words, these were the facts, and this is why the next action is still appropriate.
How this post was made, 5 November 2026: AI assisted research and drafting from author-provided principles and experience. Public quotation records were checked, and draft fingerprints, freshness checks and review settings were inspected in the source snapshot for Mach's deployed build. No live send workflow was tested. The Monday-to-Friday example is fictional.
What change would make you withdraw approval from a message already waiting to go?
Common questions
Should every small change require approval again?
Start with changes that affect the recipient, the claims or the decision to contact. Review irrelevant alerts too, because they can make consequential changes easier to miss.
Does a fingerprint prove that the claims are true?
It compares selected inputs. A source can already be wrong, and a relevant fact can be absent. Open the original evidence when the claim matters.
Does Mach automatically recheck the original website?
The inspected fingerprint compares stored step, person and selected Brain information. It is not evidence of an automatic fresh crawl of every original source.
Does a stale message always need a new human approval?
The inspected path marks it stale and allows fresh words to be produced. Review afterward follows the configured policy. Test that policy before relying on it.
What if a selected source has been deleted?
A missing or hidden selected Brain record can change the fingerprint. The reviewer should identify what support was lost before using the claim again.
Can a buyer reply leave the facts unchanged?
Yes. The words may remain accurate while the introduction has become inappropriate. The relationship needs its own check and an owner for the next step.
Where does this fit with a dry run?
A dry run previews a path using information available then. Later changes still need checks; see why an approved playbook checks each person.
Sources and further reading
- AI sales notes and conditional commitmentsReddit, r/CRMBack to text
- u/marthaforester1 on checking the transcriptReddit, r/CRMBack to text
- Production ML systems: Questions to askGoogle for DevelopersBack to text
