Delivery truth

A destination is published only when the platform confirms it on read-back — with one labelled exception: Telegram has no read-back, so a Telegram destination is published on Telegram's own send response (evidence_kind = send_response), and a lost Telegram response stays uncertain until a workspace owner or admin forces a retry or marks it resolved. Otherwise it is one of: pending, deferred (rate limit), in_progress, published_limited (on the platform but not publicly visible — e.g. self-only before a platform audit, creator-only on trial access; never counted as live), awaiting_human_finish (inbox routes; not done until the read-back confirms the human finished), failed (provably nothing published; retryable), uncertain (a request may have landed), blocked (the platform needs an in-app action), held_same_asset, cancelled.

• Receipts are an append-only checkpoint log per destination; a restart resumes the stage, not the post.
• Uncertain is never retried automatically. A resolution probe (read-back search) runs on a backoff; it either finds the post live or unlocks a normal retry. A forced retry requires an explicit acknowledgement that a duplicate is possible.
• Automatic retries apply only to provable pre-send failures, bounded to three attempts with backoff.
• Flags record degradations on the receipt (disclosure not settable on a route, playlist add failed, first comment failed, link not shortened, thread part failed) and surface in the attention feed.
• Handoff packs give the human finishing an inbox-route post the caption and every toggle to set, phone-sized.
• Engagement (views, likes, comments, shares) is the platform's number, pulled after publish and never part of delivery truth — see engagement coverage for what each platform exposes.
• Notifications: failures, uncertain outcomes, handoffs, parked posts and approvals can email you or call a signed webhook, so a closed assistant conversation never silences a failed post.