This proof-of-concept demonstrates a simple but non-negotiable reality of logistics and operations:
Inventory is not a single number.
It is a distributed state that lives across multiple containers, with movement constraints and policy constraints that determine whether the system is stable or collapsing.
This POC visualizes that idea with a dockyard-style routing problem: items arrive, you store them, you move them, and you discover very quickly that “we have capacity somewhere” is not the same thing as “we can handle the flow.”
What you’re looking at
Bins (storage containers)
Each box on the left is a separate storage bin with its own:
- Capacity (max items it can hold)
- Current contents (what is actually inside right now)
- Eligibility rules (what types it accepts)
In the POC there are specialized bins:
- Warehouse A / General B: general storage
- Cold Storage: accepts Food
- HazMat: accepts HazMat
- Overflow Yard: accepts anything, but represents a failure mode
- Inbound: the arrival queue
- Out / Processed: the sink (delivered throughput)
Items (discrete units)
Inventory is modeled as individual units, not a single pooled value. You can see items directly in bins:
- General = square icons
- Food = rounded icons
- HazMat = triangle icons
Because items are discrete, you can watch the system “pile up” in specific places, which is the whole point: where the pile exists matters.
Links (transport capacity)
The lines/arrows between containers represent rate-limited transport links. Each link has a maximum throughput (items per second).
This is the second key lesson:
Even if a destination bin has free space, you can still fail if you can’t move items into it fast enough.
The animation on the arrows is tied to actual movement, not the slider value:
- If items are really moving, you see strong motion.
- If the link is idle, motion drops off.
- If the link is strained (demand exists but movement is partial), the link shifts toward “warning.”
- If demand exists and nothing moves, it becomes “blocked.”
Core mechanics (what’s being simulated)
1) Arrivals (Inbound spawn rate)
Items enter the system through Inbound. The Inbound spawn rate controls how much pressure is injected into the system.
Increase it and you’re simulating:
- higher customer demand
- higher production output
- higher shipments arriving at a dock
Lower it and the whole system relaxes.
2) Routing decision capacity (Dispatch capacity)
Even if trucks and conveyors exist, there is usually an additional constraint: handling and decision bandwidth.
The dispatcher controls how quickly items can be pulled from Inbound and placed into the storage network. This models:
- labor limits (how many pallets per minute can be processed)
- scanning / receiving bottlenecks
- decision latency / workflow constraints
So you can get failure in two different ways:
- Transport bottleneck (links too slow)
- Handling bottleneck (dispatch too slow)
3) Priority policy (where the system tries to put items first)
The bin priority order is the policy layer: when Inbound is routed, the system tries bins top-to-bottom (Overflow is intended as last resort).
This creates a real operational phenomenon:
- The “wrong” priority order can cause the system to look like it’s working (low rejects) while it is actually degrading (overflow creeping up).
- The “right” priority order can protect critical resources (Cold, HazMat) at the expense of general storage, depending on what you decide matters.
4) Overflow rules (what happens when the ideal destination is full)
Overflow is not a normal path in a healthy system. It is what happens under stress.
When a destination bin is full, the overflow rule decides the behavior:
- Spill → Overflow: hides the problem by dumping into Overflow Yard
- Reject: hard failure (lost inventory / lost orders)
- Auto-reroute: policy-driven attempt to place the item elsewhere
This is the third key lesson:
A system can be “stable” only because it is silently using overflow as a crutch.
Metrics (how to interpret “success” vs “failure”)
The metrics are deliberately blunt:
- Delivered: throughput into Out / Processed (what the system successfully pushes through)
- Rejected: items that could not be placed anywhere (hard loss)
- Overflowed: items that were forced into Overflow Yard (soft loss / accumulating failure)
A common real-world failure mode is:
- Rejected stays low (looks good)
- Delivered stays decent (looks good)
- Overflow slowly climbs (system is rotting from inside)
This POC makes that visible because Overflow is drawn as “bad” storage by design.
How to run the POC (recommended demonstrations)
Demo A: “Capacity exists but the system still fails”
- Set Outbound link rates low (slow drain).
- Set Inbound spawn rate moderate/high.
- Watch bins fill, then watch Overflow activate.
Result: you will see that the system fails even though some bins may still have room—because the system can’t move or place items fast enough in the right places.
Demo B: “Policy changes outcomes”
- Keep the same inbound/outbound rates.
- Change priority order:
- prioritize Cold first vs last
- prioritize HazMat first vs last
- Watch which bins fill and where overflow pressure appears.
Result: the same physical system produces different outcomes based purely on routing policy.
Demo C: “Overflow hides the truth”
- Turn full bins to Spill → Overflow.
- Compare with Reject or Auto-reroute.
Result: Spill makes “Rejected” look artificially good, but the Overflow yard becomes a growing liability. This demonstrates why many real businesses drift into fragility: they measure the wrong things.
The point (in one sentence)
This POC proves that inventory management is not “counting units”—it is controlling flows across constrained containers with explicit policies for what happens when reality exceeds capacity.