What does it mean that a hand-off is not a sent message?What does it mean that a hand-off is not a sent message?

A hand-off is the output of a delivery step that deliberately does not deliver. When the human seat approves a card, the authorisation is issued and then the transport is asked to deliver. In version 0 the transport refuses, and what the organiser receives is the message itself: the exact text that was approved, the exact audience it was meant for, and the refusal that stopped it.

The transport is one of four seams between a control plane and the world it operates in — credential, clock, store, transport. The control plane owns none of them, and the transport is the only one that may touch a person. Refusing to send is therefore a design decision about who owns the part that reaches a human being, not a missing feature that a later release will quietly fill in.

The refusal is recorded, not swallowed. The authorisation is left intact, the refusal code goes into the log, and the near-miss stays visible in the trail. A channel draft — a promotion, a recap — comes back the same way, with a note that it carries no individual recipient and should be posted by the organiser. Nothing that leaves this system should be describable as sent.

Two consequences follow, and both matter more than the feature. First, the wording on this site: you will not find "sent" here, because nothing is. Second, the path forward. If a future seam really does send, that code has to be written deliberately rather than inherited, and the rules it runs under — the member's stop, the quiet hours, the per-member cap, the disclosure line, the answerability requirement — are already in place and already tested. The delivery step is the last one to be switched on, not the first.

This is also why we describe the effect on members as unmeasured. We have not asked a member whether a hand-off was better or worse than what it replaced, so we do not claim it made anyone feel more valued, more engaged, or more attended to.