Sending with provider evidence, end to end

The flow, stage by stage#

1. Trigger — the engine decides a reply is due, or a person approves or writes one.
2. User or external event — an approval in Needs You, a person's own send, or an autonomous decision inside the gates.
3. Authentication and workspace resolution — the send runs inside the owning workspace; the mailbox, its credentials and its rules are all read there.
4. Ingest — the draft, its recipients and the thread it belongs to are assembled into one outbound message.
5. Canonical record — the intent to send exists as a record before the attempt, so a failure has somewhere to be written.
6. Classification and reasoning — already done: by this stage the wording is fixed, whether written by Connect or edited by a person.
7. Knowledge, memory and rules — consulted while drafting, not at the boundary. What the boundary reads is policy, not prose.
8. Autonomy and approval — the last gate: the mode for that mailbox and channel, the compliance check for that recipient, and the daily allowance.
9. Action through a provider — one attempt, through the one send boundary that both the engine and a person use.
10. Result — sent on acknowledgement, failed if the provider refused it, uncertain if the answer never arrived.
11. Relationship, timeline and memory — an acknowledged message joins the thread and the person's cross-channel timeline.
12. Audit, usage and Needs You — the outcome is recorded, the allowance is decremented, and anything unresolved is put in front of a person.

The four states#

*Failed* and *uncertain* are not degrees of the same thing. A failure is knowledge: nothing was handed over, so another attempt cannot duplicate anything. Uncertainty is the absence of knowledge: the message may be in the recipient's inbox already, and a second attempt would be a second message.

Why nothing is re-sent on a maybe#

An automatic retry needs a rule, and every rule has a failure case. Retry on uncertainty and a dropped acknowledgement becomes a duplicate reply to a customer — the same answer twice, sometimes with different wording, which reads as a machine talking to itself. Never retry and a genuinely lost message becomes silence nobody notices.

Connect refuses to pick for you and shows the state instead. A person can look at the mailbox's own sent items, or at whether the customer has replied, and settle in seconds a question no rule can settle at all. That is the same principle the product applies elsewhere: uncertainty is an answer, and presenting it honestly beats a confident guess.

What the gates refuse before an attempt#

Autonomy

ask_before_send holds every outbound message for a person; draft_only writes and stops without even asking; off disables the channel.

Compliance

Suppression, unsubscribe, complaints and do-not-contact are checked in one place before any outreach. A refusal here is recorded as a decision, with its origin.

The daily allowance

When it is spent, the send is held rather than dropped, and the refusal is shown with its cause.

A mailbox that cannot send

A mailbox connected for reading has no send path. This shows as a failure with a reason rather than as a silent nothing.

Every one of those produces a record. A refusal is a decision, and the decision log holds refusals for the same reason it holds actions: the question asked afterwards is usually *why did nothing happen*, and that question needs an answer as much as *who sent this* does.

Resolving an uncertain send#

1. Open the mailbox at the provider and look at what actually left it.

   Result The provider's own sent record is the authority. This is a thirty-second check that no automatic rule can perform on your behalf.

2. If the message is there, mark the matter closed and do nothing else.

   Result The customer has it. The uncertainty was about the acknowledgement, not about the message.

3. If it is not there, send once, from the same thread.

   Result The reply leaves from the mailbox the thread is bound to, so the conversation stays in one place for the recipient.

4. If uncertain sends recur on one mailbox, treat it as a health question.

   Result Repeated uncertainty is a connection or provider problem rather than a message problem, and reconnecting the mailbox is the usual repair.

Questions#

Related#

• Proof that a message was sent
• Sending email
• The send result is uncertain
• The reply would not send
• Why 'sent' must require provider evidence