Fulfillment intelligence: a warehouse that explains itself

Intelligence begins with not lying

Most fulfillment intelligence is a forecast drawn over a balance nobody has audited. The forecast inherits every error in the balance and adds its own. DockingWare builds the layer in the other order. First a ledger where every balance is derived from movements and no code path can change stock without writing a row. Then a system that reports its own condition without rounding up. Then reports that read from both. Forecasting sits on top of that, and it is not shipped yet. This page says so.

What the system already knows about itself

Every place in the code that can change a stock bucket is listed in a registry with its movement type and its test. The build refuses a new one that is not on the list. A ledger replay against the snapshot is a test that fails first. Reconciliation runs on a schedule and names every discrepancy by product, bucket and size.

The health endpoint reports the database, the cache, the migrations, the storage and the background workers, and it degrades when something is wrong instead of returning a cheerful two hundred. Named alerts fire when a connected store goes silent and clear when it speaks again. Errors are shown where the operator is looking, with the field painted and the reason under it, not in a toast that vanishes.

What the system already knows about the work

Every allocation writes why it chose what it chose. Every order status change writes what triggered it. The allocation aging report lists which orders have held stock the longest, by bucket and by customer, against each customer’s own limit, and the system notifies on breach without ever releasing on its own. A component product explains how much of it is held by open kit orders and for which ones, read from the allocation table rather than inferred by subtraction. Channel demand is shown on the product when there is something to say.

These are not predictions. They are facts the warehouse already has and most systems throw away.

What is coming, labelled

Forecasting, ABC-XYZ classification, dead-inventory detection and an assistant that answers questions over the ledger are on the roadmap. They are registered in the application’s own capability register as missing, and they will stay off this page as features until they ship with the same rule as everything else: a test that failed first and a release note that names the version.

The executive overview exists today and is partial. It will grow as the pages above give it more that is true to show.

Who this is for

Operators and owners who want the reports to be as trustworthy as the ledger, and who would rather have five numbers they can defend than fifty they cannot. Teams evaluating forecasting tools who want to know what the forecast will be standing on.

What you can verify

Every capability described as shipped is enforced in code with a test that failed before it passed, and the changelog names its release. Every capability described as coming is listed as missing in the application’s capability register, which is versioned with the code.