Message Acceptance Is Not Recipient Delivery

Compare email, SMS and push evidence without inventing a shared delivered state. Define recipient-level coverage, unknown outcomes and bounded follow-up actions.

Decide what a notification result lets you claim

A workflow sends a maintenance notice and receives successful API responses. Its dashboard marks the recipients informed. An AI assistant repeats that conclusion to the operator. The application has converted acceptance of a request into a statement about people receiving information, without collecting evidence that supports the statement.

Consider a fictional service platform announcing maintenance revision M9 to four designated contacts. One contact uses email, two use SMS and one uses an app notification. The platform records four accepted requests. Its product owner wants to know whether the contacts received the current notice before the maintenance window. The acceptance count answers an earlier question: whether the application obtained a successful submission response for each attempted send.

This article proposes a cross-channel evidence contract. The contacts, notice and observations are synthetic. They are not an Ampity delivery result or a live test of a messaging provider. The goal is to prevent an integration adapter, dashboard or AI summary from claiming more than its available evidence. Emergency communications require their own approved procedures; the design here is not a substitute for them.

Keep the channel's meaning beside its status

Names such as sent and delivered depend on the channel and provider. A common UI label can conceal that one observation concerns a mail server, another concerns a carrier receipt and another concerns an app instance. Keep the provider's status and the application's interpretation as separate fields. Changing vendors should require reviewing that interpretation, rather than mapping familiar words by appearance.

Amazon SES event definitions describe a delivery event as delivery to the recipient's mail server. They identify the recipients the event applies to and the remote SMTP response. They also distinguish the SES-assigned message identifier from some identifiers in original headers. Our inference is that this event can support a mail-server acceptance label, but cannot establish that the named human read or acknowledged the notice.

Twilio's Message resource defines sent as acceptance by the nearest upstream carrier. Delivered means Twilio received delivery confirmation from the upstream carrier and, where available, the handset. Read status is documented for RCS and WhatsApp when receipts are enabled. Treat those as provider-defined observations; do not invent an SMS read receipt or turn delivery confirmation into a maintenance acknowledgement.

For M9, choose labels the operator can understand: submission accepted, mail-server delivery observed, carrier delivery observed, app receipt observed and explicit notice acknowledgement. A channel may provide only some of these. Unavailable evidence must remain unavailable, not be filled in by a model estimating that a person probably saw the message. Keep the narrower technical status visible when a decision depends on it.

Capture the initial response and later evidence separately

Record the initial submission outcome, provider reference and attempted destination as soon as the response arrives. Then associate later events with that attempt. A system that relies entirely on callbacks can miss the first state or lose the correlation needed to interpret a later one. An event receiver being online does not establish that every required provider event has been configured or retained.

Twilio's status-callback guide says no callback is sent for the initial status of a newly created Message resource. The initial value comes from the creation response. Depending on the creation path, it can be queued, accepted or scheduled. This provider-specific behavior explains why a callback-only ledger cannot be assumed to describe the whole submission lifecycle.

Our proposed record has a logical notice-recipient identity and a separate transport-attempt identity. It retains channel, provider account, provider message reference, endpoint revision, content revision and observation time. A callback for the email endpoint used yesterday must not establish reachability of a replacement endpoint saved today. A callback for M8 must not settle the intended communication of M9.

Authenticate the incoming event through the provider's supported verification mechanism before using it. Correlate it to the known account and attempt, then preserve duplicates or conflicting observations according to an explicit adapter contract. Do not create recipients from unknown callbacks or let receipt time alone override a more informative observation. Keep raw evidence accessible only to the authorized support role, with addresses and bodies minimized in aggregate dashboards.

Separate recipient evidence from aggregate trends

A high delivery percentage can help diagnose a channel while saying nothing definitive about a particular maintenance contact. The dashboard should identify whether a number describes logical recipients, transport attempts, app instances or a sampled provider dataset. It should also show the reporting window and any known evidence exclusions, instead of presenting every percentage beside the same green badge.

Firebase's delivery documentation distinguishes sends, app receipt, notification display and opens. Its FCM Data API reports aggregated Android transport information, has incomplete coverage and excludes devices with certain data-collection preferences. It describes delayed reporting and rounded or omitted metrics. Individual-message export is a different evidence path. Our inference is that an aggregate percentage cannot prove delivery to the particular app instance assigned to the fourth M9 contact.

Define the intended business denominator independently. In the fictional example, there are four designated contacts, even if only three attempted sends appear in a provider report. An accidentally omitted contact stays in the unresolved group. A contact using two channels still represents one logical communication obligation under this declared rule, with two attempts rather than two people.

Endpoint evidence has another limit: a contact can have multiple devices or share an endpoint. Decide which endpoint observations satisfy the product's declared criterion, if any, and keep that criterion next to the count. A successful app-instance receipt does not automatically establish receipt by every person associated with the account. If explicit acknowledgement is required, collect a separate, appropriately authenticated action tied to M9.

Use a cross-channel evidence worksheet

The worksheet proposes what an operator may say from each observation. It assumes authenticated, correlated evidence for the exact attempt and current notice. The observations are fixtures, not actual provider traffic. A production adapter needs its own verified event configuration and correlation tests before adopting these labels.

| Observation | Supported statement | What remains unresolved | | --- | --- | --- | | Successful email submission, no later correlated event | The provider accepted this submission. | Mail-server delivery and human acknowledgement are unestablished. | | SES delivery event for this message and recipient | Mail-server delivery was observed for this recipient. | The human's reading and acknowledgement are unestablished. | | Twilio SMS status sent for this attempt | An upstream carrier accepted the message. | Recipient delivery and human acknowledgement are unestablished. | | Twilio SMS status delivered for this attempt | Provider-defined delivery confirmation was observed. | Human reading and maintenance acknowledgement are unestablished. | | High aggregate FCM delivery percentage, no individual receipt | The provider reports aggregate delivery outcomes for its covered population. | Delivery to this particular app instance and contact is unestablished. |

Build the adapter's test expectations from these meanings before looking at its output. Include one accepted submission, one correlated channel-delivery observation and one observation for the wrong notice revision. The last event may remain valid historical evidence while providing no coverage for M9. Retaining history and settling the current obligation are different decisions.

For an AI-generated operator summary, specify prohibited assertions as well as required details. A summary may report that two carrier deliveries were observed and two contacts remain unresolved. It must not replace that record with “everyone was notified.” Require traceable references to the sanitized evidence records, and test whether missing evidence stays missing when the prompt asks for a reassuring executive update.

Choose bounded follow-up instead of automatic resending

No new observation is not proof that the first send failed. The callback route may be delayed or broken, or the provider may have accepted the request before a timeout obscured the response. Preserve an unknown outcome until an authoritative observation or an explicitly bounded operational decision resolves it. Sending another copy can increase confusion without supplying evidence about the first.

Before follow-up, check that M9 remains current, the selected channel is still permitted and the destination belongs to the intended contact. A failed email does not grant permission to use every phone number in an account. Switching channels changes the data-disclosure and permission question as well as the transport. An AI agent should not choose a new recipient or wider audience merely to close an unresolved count.

Assign an owner, decision deadline and permitted action to each unresolved case. The owner may reconcile the original attempt, request corrected contact information or use an approved manual route. Task creation records assigned work; it does not establish that someone performed the contact. Likewise, a resend API response is another accepted attempt, not completion of the original obligation.

For communications needing explicit confirmation, retain an acknowledgement tied to the notice revision and an authorized actor. An open, click or available channel read indication does not perform that business operation. If the notice changes, determine whether a new acknowledgement is required and present the current text. Avoid silently treating confirmation of an older notice as agreement to changed maintenance details.

Test the evidence contract before enabling AI summaries

Start with one notification type and define its evidence labels, recipient denominator and acceptable follow-up. Have the provider-integration owner explain which events are configured and the product owner explain what each event permits the application to claim. Keep unsupported evidence states explicit instead of making the UI look complete by assuming every channel has them.

Use a non-sending fixture to test submission responses, duplicated events, missing events and events for another account, recipient or revision. Add a contact omitted before submission and a contact whose endpoint changes after submission. Verify both the evidence projection and the visible operator summary. Include a deliberately broken adapter that maps every successful API response to recipient delivered; the observer should reject its inflated claims.

The test's limitation is that it establishes application evidence handling, not carrier reachability, human attention or live callback reliability. Any live channel test needs agreed recipients, permitted sends and resulting-state readback. A restricted operator can bring one completed evidence worksheet and unresolved cases to a backend systems review or DevOps and SRE review.

For revision-specific coverage, use the sports notification evidence guide. For a workflow that turns observations into actions, use the feasibility and authority review. Reading these resources does not require an email address. If you want us to contact you, you can choose to share a sanitized example rather than customer message bodies or private contact lists.