Solutions / Logistics and inventory

One order, one shipment, one truth.

Orders move through warehouses, carriers and returns systems that each keep their own status. States that should be impossible show up quietly when two systems disagree. Invarly checks that they don’t.

FulfilmentWarehousingDeliveryReturns

Why logistics breaks quietly

A single order can have a status in your store, your warehouse system, a carrier’s API and a returns tool. Integrations retry, carriers send late updates, and warehouse staff correct things by hand.

The result is rarely an error. It is an order that is both cancelled and shipped, or stock that is reserved twice. Someone finds it when a customer calls.

Five places it breaks

Orders dispatched twice

A carrier booking times out and is retried, creating two shipments and two labels.

ruleshipments_per_order <= 1 unless order.split

Reservations above stock

Two channels reserve the same units because reservations are checked against a stale count.

ruleinventory.reserved <= inventory.on_hand

Delivered without proof

A status update marks a shipment delivered without a scan or signature.

ruleshipment.delivered ⇒ proof_id != null

Impossible status changes

An order moves from cancelled back to processing after a late webhook.

rulestatus transition in allowed_transitions

Returns never restocked

A return is received but the inventory update fails silently.

rulereturn.received ⇒ stock adjusted within 24h

A walkthrough

Composite example, combined from common fulfilment bugs.

A team adds retries to carrier booking to handle timeouts. When the carrier is slow, some bookings succeed twice.

postgres.ops · shipmentslive
ordercarrierlabelsmax
88256DPD11
88258GLS11
88260DPD21
88263DHL21
88264DPD11
88265UPS11
88267UPS21
88270DHL21
88273GLS21
one-shipment-per-order≠ open
rule shipments_per_order <= 1
orders shipped twice
5
limit
≠ incident opened, 5 records
after deploy e4b712f “retry carrier booking”
ai investigation
  • all 6 orders have two labels from the same carrier within 30 s
  • traced to e4b712f “retry carrier booking” shipping/book.go:64
  • extra labels to cancel 6

Labels can be cancelled before pickup, instead of after two parcels arrive at one door.

The starter rule pack

The rules most teams in this space start with. Each one is a query against your own tables, adjusted to your schema during setup.

rule protects runs
one-shipment-per-order Duplicate dispatch 5 min
reserved-within-stock Overbooking 1 min
delivered-has-proof Delivery disputes 15 min
valid-status-transitions Impossible states 5 min
returns-restocked Lost inventory 1 hour
no-ship-after-cancel Cancelled orders shipped 5 min

How it fits your stack

The agent reads the order and inventory tables your systems already write to. Carrier data can be checked as soon as it lands in your database.

Operations teams get alerts in the channel they already use, with the list of affected orders ready to act on.

Common questions

Our warehouse system is a vendor product.

If its data syncs into a database you control, rules can run on it.

Can rules check status transitions?

Yes. A rule can compare each status change with the transitions you allow.

How fast are alerts?

Rules can run every minute. Most logistics rules run every one to fifteen minutes.

Next industry
Health and regulated data
Read →

Catch the second label before pickup.

We’re onboarding a few logistics teams first. Tell us where your orders change hands.

Join waitlist