Order orchestration: the queue decides, and writes down why

From the channel to the floor without a spreadsheet in between

An order arrives from a connected store. Somebody has to decide whether it can be filled today, from which stock, on which part of the floor, and when to tell the store it shipped. In most warehouses that somebody is a person with two screens open. Here it is the fulfillment queue.

The queue takes each channel order through ingest, allocation, destination, pick, pack, ship and confirmation, and it stops only where it should: when stock is short, when a listing maps to nothing, when a carrier does not answer, when an allocation has been held past its limit. Those orders are the exceptions. They are the queue’s whole screen. Everything else moved on its own.

Every decision is a row

Orchestration that cannot explain itself is a black box with a status column. DockingWare writes a decision log for every allocation and a transition log for every status change. Which lots were considered, which bucket was drawn, why this order went to the station and that one to the walk floor, what triggered the move from allocated to picking. When an order looks wrong, the reason is already written, with a time on it.

Allocation itself is piece exact. Demand in pieces reserves pieces; a case is broken only when no conversion exists, and that fallback is logged as a decision, not buried in a quantity. The last units of a product can be held back from the channels for wholesale (a channel reserve per product), and publish and allocate read the same availability so the store is never promised what the floor cannot pick.

Three destinations, one law

An order can be dispatched to the walk floor, to a packing station, or to a pick-to-tote split where one operator picks into totes that a bench then packs. The tote is a real object with a lifecycle: bound to an order, carried, released, rebound, with named refusals when a tote is already in use or missing. The three destinations share the same inventory primitives and the same ledger, so a shipment closes the same way whichever path it took.

The channel is watched, not trusted

Connected stores go quiet, rotate secrets, and send cancellations for orders already on a truck. Orchestration treats the channel as a source to verify. Webhook signatures are checked and repaired automatically. A silence detector names a store that stopped talking and clears the alert when it speaks again. A periodic reconciliation pulls what the webhooks missed. An inbound cancellation writes a ledger witness and is refused, by name, if the order already shipped.

What it will not do for you

It will not release a stuck allocation. It records how long each order has held its stock, applies a limit per customer, lists breaches oldest first and notifies. Releasing stock someone else may be about to pick is a human call, and when a human makes it the reason is written on the ledger row with their name.

The assemble cascade (fill a listing from the direct SKU, else from the kit that builds it) exists and is off for every tenant until a pre-flight passes. A feature that can change what gets shipped is enabled on purpose, per tenant, or not at all.

Who this is for

Brands and 3PLs running several stores into one floor who are tired of the order queue being a person. Teams that have been burned by an allocation nobody can explain and want the next one to come with its reasons attached.

What you can verify

Every behaviour on this page is enforced in code with a test that failed first. The changelog names the release each one shipped in.