Delivery and acceptance
How a Service Order moves from intake to earned, delivered in parts, with each line confirmed, revised, or disputed on its own.
Delivery turns a placed Order into the result its Outcome Contract promises, one line at a time. Acceptance earns each line once the Customer confirms it or lets its window close.
Two fields track an Order
A Service Order carries two fields. fulfillment says where the work stands; payment says where the money stands. Each line also carries its own verdict, so one Order can hold an accepted line beside a line in revision.
Read as text
- fulfillment: intake to working
- fulfillment: working to delivered
- fulfillment: delivered to accepted
- fulfillment: delivered to revising
- fulfillment: revising to delivered
- fulfillment: revising to disputed
- fulfillment: disputed to remedy
- payment: authorized to captured, line by line
The work runs as Deliver an outcome, a Workflow that starts when the Order is placed. Take the Startup that copyedits book manuscripts, with an 82,000-word book quoted as three lines, one per part.
Intake and the clock
Intake checks the inputs against the brief on the accepted Quote, as Quotes and intake explains. Order.start moves the Order to working and sets dueAt.
The deadline counts only the Startup's time. While the Order waits on the Customer, it shows pending with reason awaitingInput, and dueAt moves later by the time spent waiting. While it waits on the Startup's own Workers, the clock runs.
The status reads the same on the Portal, through the API, and to the Customer's own Agent. Every delay is charged to whoever holds the next move.
Working, then checked
Each step is an Action run by a Function. Code checks spelling against the style sheet, a model flags inconsistent names and dates, and an Agent edits each chapter.
Before anything leaves the Startup, deliver runs every Evaluator the contract names. A person grades a 5% sample. A failing verdict sends the work back for another pass, inside the deadline and at no cost to the Customer.
When a step needs a person and none is free, it waits as awaitingWorker and moves to the next qualified Worker. A failed step retries as a new Action linked to the first, so nothing runs twice against the Customer.
Deliver in parts
Deliver takes the lines it hands over. Each delivered line arrives with its Evidence, frozen at the moment of delivery, and opens its own acceptance window.
await $.Order.deliver({
order: 'order_1',
lines: ['line_1'],
work: { manuscript: 'file_part_1', report: 'file_report_1' },
})The author reads part one while part two is in work. The Customer never judges three weeks of work in one sitting. The Startup never waits three weeks to earn.
Confirm, revise, or dispute each line
Inside a line's window, the Customer gives one of three verdicts. Each verdict is a Verb that acts only on the lines it names.
| Verb | The Customer says | What follows |
|---|---|---|
| confirm | The line meets the contract | The line is accepted, and Bill on confirmation captures and bills it |
| revise | Close, with these edits | The line is revising, its window pauses, and one of the contract's revisions is used |
| dispute | The line misses the contract | The line is disputed, a Dispute opens, and Start the remedy holds its fee |
The author confirms parts one and two, and sends part three back once.
await $.Order.confirm({ order: 'order_1', lines: ['line_1', 'line_2'] })
await $.Order.revise({ order: 'order_1', lines: ['line_3'], changes: 'Keep British spelling in dialogue.' })A revision past the contract's allowance becomes a dispute, and the remedy starts. Silence counts as acceptance: when a line's window closes with no verdict, confirm runs on its own. A redelivered line opens a new window, and a confirmation binds to the exact work the Customer saw.
Earned line by line
Payment is authorized when the Customer accepts the Quote, and captured line by line on the Event the contract earns names. For a Service that is Order.confirmed, so revenue never counts before the Customer has had the chance to object.
The Order closes once every line is confirmed or refunded. A missed dueAt is a miss too. Its remedy, such as a credit on the next Order, runs without the Customer asking.
One operation on every Interface
Deliver is one operation, Order.deliver, with one input on every Interface. The delivering Agent calls it over MCP; a script calls it through the SDK or CLI.
Deliver the latest order.
curl -X POST https: //api.sb/ patentpad.com/ orders/ order_1/ deliver \
-H "Authorization: Bearer $STARTUP_BUILDER_API_KEY" \
-H "Content-Type: application/ json" \
-d '{"work": {}}'
import { $ } from 'startup-builder'
const order = await $.Order.deliver({ order: 'order_1', work: {} })
npx startup-builder do Order.deliver --json '{"order": "order_1", "work": {}}'
{
"name": "do",
"arguments": {
"code": "return await $.Order.deliver({ order: 'order_1', work: {} })"
}
}
Next
- Outcome contracts: the terms every line is checked against.
- Disputes: when a remedy does not settle a disputed line.
- Support and retention: what follows an accepted Order.