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

# Deliverable Lifecycle

Every deliverable carries a status — **Pending**, **Needs review**, **Approved**, **Shipped**, or **Voided** — that tells you exactly where it is on its way to you. This page explains each status: what it means, how a deliverable gets there, and what can happen next.

```mermaid theme={null}
stateDiagram-v2
    direction LR
    [*] --> Pending: created
    [*] --> NeedsReview: created ready for review
    [*] --> Shipped: created (pre-approved work)
    Pending --> NeedsReview: submit for review
    NeedsReview --> Pending: reject
    NeedsReview --> Approved: approve
    Approved --> Shipped: mark shipped
    Pending --> Shipped: mark shipped (pre-approved work)
    Shipped --> [*]

    NeedsReview: Needs review
```

## How deliverables are created

Deliverables are created when tasks are executed:

* **Automatically, when a task starts.** Deliverable types marked *automatic* for a task are created by Membrane the moment the task launches, in **Pending** — before any work happens, so the work can't finish without its record. The deliverable's id is passed into the task, and the agent updates that record rather than creating its own.
* **By the agent, as the work produces results** — [`create-deliverable`](/reference/workspace-elements/deliverables/create-deliverable). The agent creates the deliverable directly in the status that fits: **Pending** if the work is still underway, **Needs review** if it's ready for sign-off, or straight to **Shipped** for pre-approved work that's already delivered.

## Needs approval vs. pre-approved

Each deliverable type on the job has an `autonomy` setting, one of:

* **Needs approval** — the operator signs off every deliverable of this type before it ships. For high-stakes output: a report going to the CFO, a closed month.
* **Pre-approved** — agreed once, at job setup; deliverables ship as soon as the work is done. For routine, high-frequency output: customer requests, daily digests.

Pre-approved work can still be submitted for review when the agent wants a human check.

## The statuses

### Pending

The deliverable exists, but hasn't been delivered or handed over for review. The agent updates its content and line items as the work progresses ([`update-deliverable`](/reference/workspace-elements/deliverables/update-deliverable)).

**Gets here by:** being auto-created at task launch, being created by the agent mid-work, or being rejected in review and returned for rework.

| Command                                                                                                     | Who      | Moves to     | Notes                                         |
| ----------------------------------------------------------------------------------------------------------- | -------- | ------------ | --------------------------------------------- |
| [`update-deliverable`](/reference/workspace-elements/deliverables/update-deliverable)                       | Agent    | —            | Edit content and line items                   |
| [`submit-deliverable-for-review`](/reference/workspace-elements/deliverables/submit-deliverable-for-review) | Agent    | Needs review | Creates a review item in the operator's Inbox |
| [`mark-deliverable-shipped`](/reference/workspace-elements/deliverables/mark-deliverable-shipped)           | Agent    | Shipped      | Pre-approved types only                       |
| [`void-deliverable`](/reference/workspace-elements/deliverables/void-deliverable)                           | Operator | Voided       | Kill work that should never ship              |

### Needs review

Waiting for the operator's decision. Submitting created an item in the operator's Inbox, and the Inbox is where the review happens: approve or reject on the spot, with the deliverable's content, task, and price in front of you. The operator can correct the content directly, or ask the agent to revise it — both can edit here.

**Gets here by:** the agent submitting it from Pending, or creating it ready for review in the first place.

| Command                                                                                 | Who              | Moves to | Notes                                                                 |
| --------------------------------------------------------------------------------------- | ---------------- | -------- | --------------------------------------------------------------------- |
| [`update-deliverable`](/reference/workspace-elements/deliverables/update-deliverable)   | Operator / Agent | —        | Correct directly, or the agent revises on the operator's instructions |
| [`approve-deliverable`](/reference/workspace-elements/deliverables/approve-deliverable) | Operator         | Approved | Sign off — content freezes                                            |
| [`reject-deliverable`](/reference/workspace-elements/deliverables/reject-deliverable)   | Operator         | Pending  | Send back for rework; comments optional                               |
| [`void-deliverable`](/reference/workspace-elements/deliverables/void-deliverable)       | Operator         | Voided   |                                                                       |

### Approved

The operator signed off. Content and line items are frozen — what was approved is exactly what ships — and the producing task is resumed with the approval so it can deliver the result.

**Gets here by:** the operator approving it in review.

| Command                                                                                           | Who      | Moves to | Notes                                                   |
| ------------------------------------------------------------------------------------------------- | -------- | -------- | ------------------------------------------------------- |
| [`mark-deliverable-shipped`](/reference/workspace-elements/deliverables/mark-deliverable-shipped) | Agent    | Shipped  | The agent delivers the result, then marks it shipped    |
| [`void-deliverable`](/reference/workspace-elements/deliverables/void-deliverable)                 | Operator | Voided   | Approval can still be withdrawn before delivery happens |

### Shipped

Delivered. Delivering is the agent's work — only it knows the steps that put this deliverable where it goes (write the sheet, send the email, publish the connector) — and marking the deliverable shipped is its confirmation that those steps completed. From here the deliverable is final: the record of what went out, when, and at what price. Its price is added to the current monthly statement; when that statement is billed at the end of the month, the deliverable's `billedAt` is stamped.

**Gets here by:** the agent marking it shipped — from Approved, from Pending for pre-approved work, or at creation when pre-approved work is already delivered.

No commands apply.

### Voided

Will never ship — rejected for good, duplicate, or out of scope. Never billed.

**Gets here by:** the operator voiding it from Pending, Needs review, or Approved, with a reason.

No commands apply.

## Nothing gets stuck

Every active status has one party responsible for moving it on — the agent in Pending and Approved, the operator in Needs review. When that party stalls (a task dies with a pending deliverable, an approval never ships), Membrane raises it in the operator's Inbox.