> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Queued to sent: the four-owner map over the status pages

> A read-first map of the outbound-message status pages — which of the four page-cluster entries owns each slice of the pending → queued → sending → sent arc, which side of the sweep cancelled and expired rows land on, and the five pointers a paragraph-level reader follows through the chain.

# Queued to sent: the four-owner map

You already know the six states an out-of-band queued message moves through. What you usually do not know is where each state's full story lives — because five different pages each own one slice of the arc, and nothing tells you which one to open for the question you actually have. This page is that map. Resolve your question here, then jump straight to the page that owns the answer, without reading five pages to find one rule.

Four of the neighbours are the status cluster: the [delivery lifecycle](/concepts/delivery-lifecycle), the [message-status map](/concepts/message-status-map), the [message-status transition rules (DAG)](/concepts/message-status-dag), and the [message route trace](/concepts/message-route-trace). The fifth, [send-at scheduled sends](/concepts/send-at-scheduled-sends), owns the `scheduled` hold that parks a row before the arc starts. The map below keeps them in traversal order — the order you consume them when you read top-down from "what does the status mean" to "where did my row actually go."

## The per-bucket story — which side of the sweep each state lives on

Every outbound row falls into one of two buckets, and the bucket decides who advances it and who can never touch it:

| Bucket                  | States                                         | Who advances it                                                                                                                                                                                                                                                                                   |
| ----------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **The forward arc**     | `pending → queued → sending → sent`            | The send pipeline — `pending → queued` at API acceptance, `queued → sending` at dequeue, `sending → sent` when the provider acknowledges on the wire. From `sent` onward only a delivery receipt (DLR, for `delivered`/`read`) or the no-DLR scheduler (`submitted_no_receipt`) can move the row. |
| **The outcome classes** | `cancelled`, `expired`, `deleted`, `test_sent` | Terminal states the send pipeline never passes through. `cancelled` is your own call against a still-unsent row; `expired` is the validity-window lapse or a late DLR; `deleted` is the operator redaction; `test_sent` resolves sandbox sends before any provider dispatch.                      |

The distinction matters because the forward arc and the outcome classes sit on opposite sides of the sweep: the platform's schedulers sweep *forward* rows for work (due `scheduled` rows to promote, stale `sent` rows to close) and sweep *outcome* rows for nothing — a `cancelled` or `expired` row is invisible to every drain, which is exactly what "terminal" means. A `scheduled` row holds the forward arc at `queued`'s doorstep: it is pre-arc, cancellable, and it joins `queued` only when its fire time arrives.

## The page-chain traversal — five pointers in reading order

A paragraph-level reader following an end-to-end question (for example, "cancellable until fire time, then which merge rule governs the DLR race?") walks this chain:

1. [Delivery lifecycle](/concepts/delivery-lifecycle) — read first. It owns what each status *means* and which actor advances it. The cancellation reader stops here: `cancelled` is defined on this page, and the forward arc's per-transition table names the send pipeline, the DLR pipeline, and the no-DLR scheduler by name.
2. [Message-status map](/concepts/message-status-map) — read second. It owns the row-per-status owner index: the primary and secondary owning page for every status value, so you stop here whenever a webhook payload shows a status you cannot place.
3. [Message-status transition rules (DAG)](/concepts/message-status-dag) — read third. It owns the legal-transition graph: precedence weight, merge contract, and floors — the rules you apply when reconciling webhook events into your own datastore.
4. [Send-at scheduled sends](/concepts/send-at-scheduled-sends) — the `scheduled` branch off the chain. It owns the pre-arc hold: the three exits (promote at fire time, cancel, expire) and how quiet hours and send windows interact with the drain at fire time.
5. [Message route trace](/concepts/message-route-trace) — read last, when one specific row needs explaining. It owns the per-message ordered timeline (`GET /api/v1/messages/:id/trace`) assembled on read from the persisted message row and webhook-delivery log.

A reader who only cares about *cancelling* a scheduled row stops at step 4. A reader reconciling events stops at step 3. Both are done before the trace page — the chain's pointers are scoped so you stop the moment the owning page is reached, not when the chain runs out.

## The index-sweep vs sentinel distinction — one paragraph to bundle `sent` and `no_dlr_channel`

The write-side insert that first stamps a row as `sent` also stamps the channel flag `no_dlr_channel` on the same row — and that pairing is the whole story on Meta DM channels (Instagram, Messenger), where the provider never emits delivery receipts. Without one bundling paragraph, a reader meets `sent` on the delivery-lifecycle page as a wire-intermediate state and assumes a receipt is coming; one row over, on channels flagged `no_dlr_channel: true`, the same `sent` row is the best answer the carrier will ever give, and the no-DLR scheduler closes it as `submitted_no_receipt` after a short per-channel grace window instead of the long SMPP one. Treat the pair (`sent`, `no_dlr_channel`) as one predicate: a `sent` row on a no-DLR channel is a *sentinel* — an accepted submission awaiting nothing — while a `sent` row on an SMPP-backed channel (SMS, MMS, voice, fax, RCS) is an *index-sweep* candidate whose grace window the scheduler is genuinely sweeping. Grouping your `submitted_no_receipt` rate by `no_dlr_channel` is what tells apart "the route never reports receipts" from "Meta channels resolved at a five-minute grace" — the two sentences your reconciliation query needs.

## The sibling anchors — what each one reads and what leaves

Each anchor below names the slice its page owns, in one scope sentence, so the map is a pointer and never a retry:

* **[Delivery lifecycle](/concepts/delivery-lifecycle)** — reads the state meanings and the advancing actors (send pipeline, DLR pipeline, no-DLR scheduler, operator); leaves the legal-graph merge rules and the per-event vocabulary to the DAG and trace pages.
* **[Message-status map](/concepts/message-status-map)** — reads the row-per-status owner index and the transition table as a consumer uses it; leaves the per-channel caveats and SMPP receipt encoders to the delivery-lifecycle and send-side-DLR pages.
* **[Message-status transition rules (DAG)](/concepts/message-status-dag)** — reads the legal-transition graph, precedence weight, and the merge contract verbatim; leaves definitions of the statuses themselves to the lifecycle page.
* **[Send-at scheduled sends](/concepts/send-at-scheduled-sends)** — reads the pre-arc `scheduled` hold and its three exits (promote, cancel, expire), plus quiet-hours and timezone interaction at fire time; leaves the post-acceptance arc to the lifecycle page.
* **[Message route trace](/concepts/message-route-trace)** — reads the per-message ordered timeline assembled on read from the persisted message row and webhook-delivery log (`GET /api/v1/messages/:id/trace`); leaves the flat state machine to every page above, and is the diagnostic you open only when one row needs its history reconstructed.

Resolve the question here, open the one anchor, and close the map — that is the whole contract this page makes with the five it points at.