Orders

An order is the authoritative record of a single transaction between a buyer and a seller, from request through reconciliation. That record has exactly three parts, all immutable or append-only: the create request as you sent it, the platform's own create-time facts (the minted order_id, the resolved buyer_entity, the terms frozen from the presented agreement), and the order's event log. Everything you read, the snapshot, the seller's view, the queue rows, is the platform's projection of those three, never a separately maintained copy. See The state machine for its lifecycle.

Partial acceptance

Results report per unit: accepted | rejected | countered, and the numbers carry the count. A seller taking 6 of your 10 leaves the line accepted with units: 10 and num_accepted: 6: there is no separate partial status at either level, because every consumer handles a full and a partial acceptance identically except for the count, which it reads from num_accepted in both cases. An order with a mixed unit set completes like any other, never a stall; your agent decides whether to re-shop the remainder.

Day resolution

Every line result carries an authoritative allocation: an array of {date, units} entries whose units sum to num_accepted. Day resolution follows from the period you booked at. A line whose period is a single day has a single-entry allocation by construction: that is what daylocking is. A line booking a week or a month leaves the distribution to the seller, who spreads the line's units across air dates within the product's weekday pattern, one allocation entry per date: ten weekly units may land as 4 + 3 + 3 across three dates, and the allocation says exactly which. The placement_receipt artifact carries the locked result per unit. Read the allocation from the result; never infer air dates from the request.

Rules for consumers

Switch your logic on status, on artifact.name, on error.error_code, and on typed fields such as cancellation.late_notice. substatus is an informational step marker: it will change, it is never the only carrier of a fact, and control flow must never pattern-match it. Artifacts carry the domain payloads: parsed_io and validation_result on the document path, plan_proposal on proposals, placement_receipt on every placed order, and delivery_post when delivery results land in the declared currency.