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. 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 anautonomy 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.
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).
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 | Agent | — | Edit content and line items |
submit-deliverable-for-review | Agent | Needs review | Creates a review item in the operator’s Inbox |
mark-deliverable-shipped | Agent | Shipped | Pre-approved types only |
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 | Operator / Agent | — | Correct directly, or the agent revises on the operator’s instructions |
approve-deliverable | Operator | Approved | Sign off — content freezes |
reject-deliverable | Operator | Pending | Send back for rework; comments optional |
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 | Agent | Shipped | The agent delivers the result, then marks it shipped |
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’sbilledAt 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.