What an AI-Drafted Customer Message Must Show Before It Is Sent

By Jared Mastroianni
Chief Operating Officer, modSTORAGE
CEO and Co-Founder, Facily.ai

Method and evidence boundary: This is an authored customer-message control method, not legal, privacy, accessibility, advertising, collections, emergency, safety, or communications advice. Every customer, facility, employee, vendor, message, account, transaction, amount, date, channel, source, and outcome in the examples is fictional. Qualified owners must define applicable law, policy, consent, recipient scope, content, accessibility, channel, timing, retention, review, and escalation requirements before any real message is sent.

An AI draft is not a customer message.

It is proposed language generated from an input context. Before it becomes communication, an operator must be able to show which claims it contains, where those claims came from, when they were true, who had authority to release them, what the recipient may reasonably do because of them, and what happens if the message is wrong.

That proof should travel with the draft.

Without it, human review becomes a writing critique. The reviewer checks whether the message sounds professional while the important questions remain hidden: Is the facility actually closed? Is the amount current? Is this the right customer? Is the offered action available? Is the deadline approved? Is the channel permitted? Is a correction possible?

The release gate must inspect the message as an operating action, not a paragraph.

Begin with a message identity

Every proposed message needs a stable identity before review.

Record:

• message_id and version;
• message class and approved purpose;
• facility and legal-entity scope where applicable;
• recipient population definition;
• customer or account identifiers in a protected system, not the public review copy;
• requested channel;
• requested send window and time zone;
• consequence tier;
• drafting actor and AI-system contribution;
• current owner and next action.

Version the message whenever a claim, recipient rule, date, amount, action, link, template, source, or consequence changes. Grammar-only edits may follow a lighter rule if the qualified owner approves one, but they still need a traceable disposition.

“Final draft” is not a useful state. Use candidate, source_incomplete, review_ready, returned, approved_for_queue, queued, provider_accepted, delivery_reported, delivery_failed, recipient_response_received, corrected, withdrawn, or another approved vocabulary.

The ten-part release packet

The reviewer should see ten blocks beside the message.

1. Audience and recipient rule

Define who is intended to receive the message and who must not.

The rule might reference:

• a specific facility;
• an approved account state;
• a lease or transaction relationship;
• a service request;
• a preference or consent state;
• language or accessibility needs;
• a time-bounded event;
• explicit exclusions and suppression lists.

Do not paste a raw customer list into an AI prompt or review packet merely because the system can accept it. Use the minimum protected identifiers necessary for the approved workflow.

The population query needs a version, source, cutoff time, owner, and row count. A saved list can become stale between review and send. If the population is rebuilt, the message release must decide whether the prior approval still applies.

2. Purpose and allowed action

State what the message is intended to accomplish.

Examples include:

• confirm receipt of a request;
• announce approved office-hour changes;
• request missing information;
• provide an approved service update;
• explain a bounded transaction state;
• route the recipient to an approved support channel.

Also state what the message may not do. A service update may not create a payment promise. A receipt confirmation may not claim completion. A general reminder may not become an account-specific determination. A safety-related draft may not be released without the authority and source rules defined for that consequence.

3. Claim ledger

Break the draft into claims rather than reviewing it as one block.

For each sentence or material phrase, record:

• claim ID;
• exact text span;
• claim type: identity, status, amount, date, time, feature, obligation, availability, instruction, link, contact, or another approved class;
• source record and field;
• source owner;
• observed and effective times;
• freshness horizon;
• transformation from source to wording;
• limitation or uncertainty;
• release disposition.

The ledger may reveal that one sentence contains four separate claims. “Your refund has been completed and should arrive within three days” contains at least a transaction identity, completion state, future receipt implication, and time estimate. One provider response may support only one of them.

The current FTC advertising and marketing guidance states at a high level that advertising claims must be truthful, non-deceptive, non-unfair, and evidence-based, and notes that specialized rules may apply. That is general federal business guidance, not a determination that a particular facility message is advertising or lawful. The bounded operating lesson is straightforward: do not release claims that outrun their evidence.

4. Source and freshness packet

The release packet should show the exact sources used to build the message.

For each source, include:

• system and record identity;
• source version;
• field names;
• source authority;
• observed time;
• effective time;
• current read state;
• freshness rule;
• conflict state;
• access or retrieval error;
• approved citation or internal locator.

Never treat a source read failure as confirmation of the last known value. Use unknown_source_unavailable or another explicit state. A cached fact may remain usable under an approved horizon for a low-consequence message, while a consequential account, facility, payment, or access statement may require a fresh authoritative read.

The pinned W3C PROV-O Recommendation defines general relationships among entities, activities, agents, generation, use, derivation, attribution, association, and delegation. Those concepts can link a message claim to a source and drafting activity. Provenance does not prove that the source is true, current, authorized, or sufficient. It makes the chain inspectable.

5. Authority and reviewer scope

The release packet must name who may approve this message class for this facility, entity, population, channel, and consequence.

Record:

• policy or procedure reference;
• message owner;
• source-owner approvals;
• content reviewer;
• privacy or legal review where required;
• operational authority;
• channel authority;
• segregation rule;
• approval expiry;
• exception authority.

Access to a composer or campaign tool is not publication authority. A facility manager may be authoritative for today’s office hours but not for a financial amount, lease interpretation, accessibility determination, emergency instruction, or marketing claim. Authority is claim-specific.

The NIST AI RMF 1.0 is a voluntary, non-sector-specific framework. It supports a governed, documented, role-aware approach across the AI lifecycle. NIST states that the framework is under revision. It does not approve a message or certify a review process.

The mutable NIST AI RMF Playbook includes voluntary suggestions for differentiating human-AI roles, documenting oversight, and tracking risk information. It is not a universal checklist. The practical lesson is to show the reviewer where AI contributed and where a qualified human decision is required.

6. Consequence and correction plan

Classify what could happen if the message is wrong, late, incomplete, inaccessible, sent to the wrong population, or acted upon literally.

A proposed tiering model might consider:

• informational inconvenience;
• customer effort or missed service;
• account or financial consequence;
• access or physical consequence;
• privacy exposure;
• deadline or rights consequence;
• safety or emergency consequence;
• irreversible or difficult-to-reverse action.

The method does not assign universal tiers. Qualified owners do.

For the chosen tier, define:

• required sources and reviewers;
• allowed channels;
• send-window limits;
• preview and test-send requirements;
• pause or cancel control;
• correction template;
• affected-population reconstruction;
• support and escalation owner;
• incident and retention record.

A correction plan should exist before release, not after a mistake.

7. Privacy and data minimization

Show which personal or account data enters the drafting, review, queue, provider, log, and archive stages.

For each field, record:

• purpose;
• minimum necessary representation;
• protected-system locator;
• whether AI can access it;
• masking or tokenization rule;
• channel exposure;
• retention and deletion rule;
• access owner;
• incident path.

The NIST Privacy Framework 1.0 is a voluntary enterprise risk-management tool and explicitly lacks the force of law. It recognizes that data processing can create consequences for individuals and organizations. It does not prescribe consent, retention, or message content. The bounded lesson is to manage the privacy consequence of the data flow, not only the text that reaches the customer.

Do not copy customer data into an evidence package intended for broad internal access. The review packet can show population logic, protected locators, counts, and masked examples without duplicating the recipient file.

8. Channel and delivery semantics

Each channel has different technical and operating states.

For email, text, portal, app, phone, printed mail, or another approved channel, distinguish:

• content approved;
• population approved;
• queued;
• accepted by a provider;
• delivery reported;
• delivery failed;
• opened or viewed when such data is approved and meaningful;
• recipient responded;
• recipient action completed;
• corrected or withdrawn.

Provider acceptance is not delivery. Delivery is not reading. Opening is not comprehension. A response is not acceptance of the message’s claim. A completed action needs its own authoritative record.

The channel packet should show sender identity, reply route, link destinations, expiration, unsubscribe or preference treatment where applicable, provider-specific limitations, and the owner of failures.

9. Accessibility and comprehension

The message and its action path should remain usable across supported channels.

Review:

• plain and specific subject or opening;
• clear facility identity;
• readable dates, times, currency, and time zone;
• descriptive link names;
• text alternatives for meaningful non-text content;
• logical heading and reading order;
• sufficient contrast in rendered templates;
• zoom and mobile layout;
• keyboard and screen-reader behavior for linked actions;
• language and translation ownership;
• a reachable help route.

The pinned WCAG 2.2 Recommendation contains testable criteria for accessible web content, including text alternatives, perceivable information, understandable operation, and compatible controls. A message may span non-web channels, and testing selected criteria is not a full conformance or legal-compliance claim. Use the standard where applicable and verify the complete recipient path.

10. Final disposition

The final reviewer should return a structured disposition:

• approved_for_exact_queue;
• approved_with_expiry;
• returned_for_source;
• returned_for_population;
• returned_for_wording;
• returned_for_accessibility;
• returned_for_authority;
• denied;
• withdrawn.

The record should name the approved message version, recipient-query version, channel, send window, reviewer, authority scope, reason, limitations, and expiry. Any change to those items may require a new review.

A fictional message review

Fictional Cedar Loop Storage prepares this AI draft:

The office will be closed Monday. Your gate access is unchanged. Call us at the number below if you need help.

The release packet separates three claims.

Claim 1: office closure
An approved special-hours record supports the office closure for the exact date and facility. State: source_current.

Claim 2: gate access unchanged
The gate schedule source was last verified before a recent system change and is outside its freshness horizon. State: unknown_source_stale. The sentence is held.

Claim 3: support phone
The number passed a technical connection test, but operational handling is not verified for the closure window. State: connected_handling_unverified. The reviewer must use an approved route or return the message.

The AI draft is not rejected because AI wrote it. It is returned because two material claims lack the evidence required for release.

No part of this fictional review proves a real facility schedule, access state, phone route, message, or customer outcome.

What AI may and may not do

AI may:

• draft language from an approved fact packet;
• extract candidate claims from its own draft;
• link candidate claims to supplied sources;
• flag missing dates, amounts, time zones, contacts, and limitations;
• compare a draft with an approved template;
• generate plain-language alternatives;
• propose accessibility and mobile checks;
• summarize reviewer changes;
• prepare a correction draft after a governed incident.

AI should not:

• select recipients;
• infer consent or channel eligibility;
• decide source authority;
• fill missing account, facility, or transaction facts;
• invent a deadline, amount, feature, status, or promise;
• approve its own message;
• send, schedule, or publish without the exact authorized gate;
• treat provider acceptance as delivery or customer action;
• decide that a message is legally compliant or accessible in every context.

The NIST Generative AI Profile, AI 600-1, is a voluntary cross-sector companion to AI RMF 1.0, published July 26, 2024; its page was updated April 8, 2026. It supports identifying and managing generative-AI risks across design, development, use, and evaluation. It does not prescribe this release packet or validate a particular AI system.

The operator exercise

Choose one recurring message class and sample ten recent drafts or sends using approved protected records.

For each item, answer:

1. Which exact message and recipient-query versions were used?
2. What claims did the message make?
3. Which source supported each claim, at what time?
4. Which claims were unknown, stale, conflicting, or transformed?
5. Who held authority for the source, message, population, and channel?
6. What could happen if the message was wrong?
7. Which personal data crossed each system boundary?
8. What accessibility and comprehension checks were performed?
9. What did the provider report, and what did it not prove?
10. Could the team pause, correct, and reconstruct the affected population?

Use the companion human-review template, review-packet template, and readiness suite to test ordinary, stale-source, wrong-facility, duplicate, inaccessible, high-consequence, provider-failure, correction, and AI-assisted cases. The release-chain diagram gives teams a compact visual for training and tabletop review.

The release question

Before a message leaves the facility’s control, the reviewer should be able to say:

I know what this message claims, where each claim came from, when it was true, who may release it, who should receive it, what the channel can prove, and how we will correct it if it is wrong.

If the packet cannot support that sentence, the draft is not ready to send—no matter how polished it sounds.

Sources

The companion source register records source owner, publication or version date, retrieval date, durable locator, claim supported, limitation, and provenance note.

• Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, NIST, published July 26, 2024; page updated April 8, 2026.
• Artificial Intelligence Risk Management Framework 1.0, NIST, January 26, 2023; current page checked August 22, 2026 and notes the framework is under revision.
• NIST AI RMF Playbook, NIST AI Resource Center, mutable companion checked August 22, 2026.
• NIST Privacy Framework 1.0, NIST, January 2020; current page checked August 22, 2026.
• Web Content Accessibility Guidelines 2.2, W3C Recommendation, December 12, 2024.
• Advertising and Marketing, Federal Trade Commission business guidance, current page checked August 22, 2026.
• PROV-O: The PROV Ontology, W3C Recommendation, April 30, 2013.