A Lokad allocation recommendation is not inventory release

Define the object that an allocation can release

Lokad says its platform uses probabilistic forecasts and economic objectives to improve decisions, including allocation and dispatch. It also describes automated multi-echelon allocation calculations. Those are provider statements about modeled recommendations and workflow scope. They do not establish that stock was available, that a priority rule was approved, that a transfer or fulfillment order was released, or that the intended recipient received the units.

Create an allocation-decision record for a named item, lot or substitutable group; ownership status; source and destination location; channel, customer or work order; requested quantity; need date; inventory snapshot; protected and available quantities; demand class; service commitment; shelf-life or compatibility limit; transportation constraint; policy version; model run; recommended quantity; approver or automation authority; override; and expiration. Link the record to the released movement or order ID.

Preserve the inventory snapshot and objective weights

An allocation can look rational under one snapshot and become infeasible when quality holds, reservations, late receipts, substitutions, customer commitments, or location constraints change. Retain on-hand, available-to-promise, allocated, quarantined, in-transit, consigned, damaged, and expiring quantities at the decision cutoff. Preserve the demand and supply events included, their timestamps, and any later event that made the recommendation stale.

Economic optimization also depends on choices. Record the costs, penalties, margin assumptions, service targets, shortage priorities, transfer limits, capacity constraints, and scenario probabilities used in the run. If a planner changes a weight or applies a protected-customer rule, retain the before-and-after recommendation and the rationale. A label such as best decision is not reproducible evidence unless another reviewer can rebuild the ranking from governed inputs.

Keep recommendation, release, and fulfillment separate

Model output, planner acceptance, inventory reservation, transfer creation, warehouse release, pick confirmation, shipment, receipt, and customer fulfillment are different states. Give each state an actor, timestamp, quantity, location, system identifier, exception code, and reversal reference. A recommendation may expire before execution; a released transfer may short-pick; a shipped unit may miss the need date; and a later cancellation may return supply to a different priority queue.

Test the chain under shortage. Remove part of the available stock, place one lot on hold, add a higher-priority order after the model cutoff, split demand across two locations, and block the cheapest lane. Confirm whether the recommendation is recalculated, rejected, partially released, or routed for approval. Then inspect whether downstream systems preserve the original run and explain any difference between recommended, released, shipped, and received quantities.

Treat the homepage as capability evidence

A buyer demonstration should start with a disclosed inventory-and-demand snapshot and end with the operational transaction, not with a ranked allocation screen. Ask the provider to show one normal decision, one scarce-stock conflict, one manual override, one stale recommendation, one substitution, and one failed or partial movement. Review which controls belong to the model, the customer's policies, the ERP or order system, and warehouse execution.

Supply Chain Signal reviewed the registered Lokad page on September 7, 2026. It supports the provider's public descriptions of probabilistic forecasting, financially informed recommendations, allocation, dispatch, and automation. It does not establish any customer's input completeness, objective function, priority policy, recommendation accuracy, release authority, inventory availability, execution, service result, or financial outcome, and it supplies no dated post-cutoff change record.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Supply Chain Signal will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.