Orders

An order is the authoritative record of a single transaction between a buyer and a seller, from request through reconciliation. See The state machine for its lifecycle.

Partial acceptance

Results report per unit: accepted | rejected | partial | countered, with num_requested and num_accepted. An order-level partial is a completed order with a mixed unit set, 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 grain you booked at. A line that books a slot has a single-entry allocation by construction: that is what daylocking is. A line that books a package and week leaves the distribution to the seller, who spreads the line's units across air dates within the package'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 (plus substatus, artifact.name, error.error_code). Step markers are informational and will change; never pattern-match them in control flow. 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.