Slotting Architecture · 20 min read

Pick-Path Optimization & Space Utilization for Warehouse Slotting

A committed slot assignment is a hypothesis, not a saving. The moment a picker walks the floor, that hypothesis is tested against physics the assignment layer never modeled: the actual walking distance between two bins, the cube a carton wastes in an over-sized location, the queue that forms when three waves converge on the same aisle, and the sequence in which tasks are released to labour. Get any of those wrong and a mathematically perfect A/B/C placement still produces long routes, honeycombed racking, and congested peak waves. This document is the reference architecture for the layer that closes that gap — the system that converts static slot assignments into measured, floor-level labour reduction.

It sits downstream of three systems and depends on all of them. It consumes committed placements from the Location Assignment & ABC Classification Algorithms pillar, inherits its facility topology and zone map from Core Slotting Architecture & Velocity Taxonomies, and is fed live pick telemetry through the Velocity Data Ingestion & WMS Sync Pipelines layer. Where the Pick-Path Modeling Frameworks guide defines the theory of routing over an aisle graph, this system is the operational layer that runs it against a real wave under a real congestion load and pushes an executable sequence to the WMS.

The engineering thesis is that four costs must cooperate or none of them pay off: travel distance, space and cube utilization, wave sequencing, and congestion. Optimize travel alone and you overfill golden aisles until they gridlock. Optimize cube alone and you scatter fast-movers into the deepest reserve. Every section below grounds that thesis in a concrete data structure, cost function, or threshold you can adapt directly.

Architecture Overview

The optimization layer is a per-wave control loop, not a one-time plan. Committed slot assignments enter from the assignment engine; a travel-cost model converts the facility into a weighted aisle graph; a space and cube utilization scorer flags locations that waste or overflow their capacity; a wave and batch sequencer groups order lines into labour-balanced releases; a congestion and zone router re-times and re-paths those releases to keep aisles below their density ceiling; and the resulting sequence executes on the floor. Every completed pick emits telemetry that re-enters the loop, correcting the travel-cost weights and re-scoring utilization for the next wave. Reading the flow left to right exposes the failure surfaces: a stale distance matrix upstream inflates every route downstream, and an un-modeled congestion multiplier turns a “shortest” path into the slowest one during peak.

Pick-path and space optimization per-wave control loop A serpentine control loop of six stages. Row one, left to right: committed slot assignments enter as input, feed a travel-cost model that builds a weighted aisle graph, which feeds a space and cube utilization scorer. The flow drops down into row two and runs right to left: a wave and batch sequencer groups order lines into labour-balanced releases, a congestion and zone router re-times and re-paths those releases below an aisle density ceiling, and floor execution dispatches the sequence to pickers. A coral dashed feedback arc returns pick telemetry from floor execution up to the slot assignments and travel-cost model, closing the loop. The loop runs once per wave. Per-wave optimization pass scored slots pick telemetry Slot assignments committed · IN Travel-cost model travel_cost() Cube utilization scoring score_utilization() Wave & batch sequencing build_wave_plan() Congestion & zone routing route_with_congestion() Floor execution picker travel
The optimization layer as a per-wave loop: committed slots become a weighted travel-cost graph, cube scoring flags wasted and overflowing locations, the sequencer balances labour across waves, and the congestion router keeps aisles below their density ceiling before the sequence executes — pick telemetry then re-tunes the model for the next wave.

The remainder of this document walks each stage: the canonical data model, the four algorithmic components (each with a dedicated deep-dive guide), a runnable end-to-end pass, the operational parameters that tune it, and the failure modes that break it on the floor.

Canonical Data Model

Every stage of the loop reads and writes the same typed records, so the model is defined once and shared. A Location carries both its logical address (aisle, bay, level) and its physical coordinates, because travel cost is computed on coordinates while zone routing and slotting reason about the address. A PickTask binds a SKU and quantity to a location within an order. A Route is an ordered walk with a computed distance and time. A WavePlan groups tasks into routes under a labour budget. A UtilizationScore captures how well a location’s cube is used. Keeping these definitions identical to the upstream assignment contract is what prevents silent drift between the layer that places a SKU and the layer that routes to it.

from __future__ import annotations

from dataclasses import dataclass, field


@dataclass(frozen=True)
class Location:
    """A pick face addressed both logically and physically."""
    location_id: str
    aisle: str
    bay: int
    level: int
    x: float                 # metres along the facility long axis
    y: float                 # metres across the facility short axis
    zone: str = "GEN"
    cube_capacity_m3: float = 1.5


@dataclass
class PickTask:
    task_id: str
    order_id: str
    sku_id: str
    location: Location
    qty: int
    unit_cube_m3: float = 0.01


@dataclass
class Route:
    route_id: str
    tasks: list[PickTask]
    total_distance_m: float = 0.0
    total_time_s: float = 0.0


@dataclass
class WavePlan:
    wave_id: str
    routes: list[Route] = field(default_factory=list)
    labour_minutes: float = 0.0


@dataclass
class UtilizationScore:
    location_id: str
    cube_used_m3: float
    cube_capacity_m3: float
    fill_ratio: float        # cube_used / cube_capacity, clipped to [0, 1]
    honeycomb_loss: float    # fraction of capacity stranded by partial pallets
    score: float             # composite 0-1, higher is better utilization

These records are deliberately cheap to serialize and deterministic to compare, so a wave plan can be computed in shadow mode against a historical extract and diffed against what actually happened on the floor. Two design choices in the model earn their keep repeatedly. First, Location is frozen and carries both address and coordinates, so it can be used as a dictionary key in the distance cache while still exposing the zone and aisle fields the congestion router reasons about — you never join two representations of the same bin. Second, UtilizationScore separates the raw fill_ratio from the derived composite score, so a downstream consumer can read the honest occupancy number or the policy-weighted judgement without one contaminating the other. Keeping the derived and the observed side by side is what lets you audit a placement decision months later against the telemetry that justified it.

How the Four Costs Trade Off

The reason this layer exists as one system, rather than four independent optimizers, is that the costs are coupled — reduce one naively and you inflate another. A worked example makes the coupling concrete. Suppose you consolidate the ten fastest SKUs into a single golden aisle to minimize travel. Measured on the distance matrix alone, average route length drops sharply and the plan looks like a win. But cube utilization in that aisle now spikes past the overflow threshold, so replenishment cannot keep the faces stocked; and every wave routes through the same aisle, so at peak the congestion multiplier on those segments climbs from 1.0 toward 1.6, adding back most of the travel time you thought you saved. The travel-only optimum is a congestion and replenishment pessimum.

The system resolves this by scoring each candidate placement and each candidate wave on all four axes at once and optimizing the sum, not any single term. Travel cost sets the baseline route time. The utilization score adds a penalty when a placement wastes cube or pushes a location past its fill ceiling. The congestion multiplier inflates route time in proportion to the density a wave imposes. The wave sequencer spends those costs against a labour budget, spreading load so no single aisle-time cell saturates. A placement that is 5% longer on raw travel but keeps three aisles below their density ceiling and cube in its target band routinely beats the travel-only optimum on total picker-hours — which is the only number the warehouse pays for.

This is why the layer is a loop and not a ranking. Each cost is a soft constraint on the others, and the equilibrium shifts with volume: the travel-dominant layout that is optimal at 60% of peak throughput becomes congestion-dominant at 95%. Re-scoring per wave, against live telemetry, is what keeps the four costs in balance as the floor’s operating point moves through the day.

Travel-Distance & Pick-Path Cost Modeling

Distance in a warehouse is not the straight line between two coordinates — a picker cannot walk through racking. The travel-cost model represents the facility as an aisle graph and computes distance as the shortest walk over that graph, then converts metres into a labour-time cost that includes walk speed, per-turn penalties, and a congestion multiplier that rises with aisle density. Getting the metric right is the difference between a route that looks short on paper and one that is short on the clock: rectilinear aisle-graph distance routinely differs from naive euclidean distance by 30–60% in a cross-aisle layout. The Travel-Distance & Pick-Path Cost Modeling guide builds this component in full — traversal, return, and midpoint routing heuristics; the networkx aisle graph; and the calibration of walk speed and turn penalties against timestamped pick telemetry. Every other stage in this architecture consumes its output: the sequencer needs route times to balance labour, and the congestion router needs the base distances it inflates. Treat the distance matrix as the single source of truth for “how far”, precomputed and cached rather than recomputed per route.

Space & Cube Utilization Scoring

Travel optimization and space optimization pull against each other, and scoring is how you referee them. A cube utilization score measures how much of a location’s rated volume its assigned SKU actually occupies, net of honeycombing — the stranded capacity left when a partial pallet blocks a full one. A fast-mover crammed into an over-sized reserve bay wastes cube; a slow bulk SKU parked in a shallow golden-zone face wastes travel. The Space & Cube Utilization Scoring guide defines the scoring schema and the Python implementation: fill ratio, honeycomb loss, level-height fit, and a composite that the assignment layer can read as a placement penalty. The score is not just a report — it is a feedback signal. A location scoring below its target fill for several cycles is a candidate for re-slotting or consolidation, and one scoring above its overflow threshold is a receiving-jam risk. Feeding those scores back to the Location Assignment & ABC Classification Algorithms layer is what lets placement and utilization converge instead of fighting each cycle.

Congestion Modeling & Zone Routing

A shortest path computed in isolation is a fiction during peak. When ten pickers share four aisles, the binding constraint is not distance but density — the queue that forms when two carts meet in a one-way aisle, or the wait at a congested pick face. Congestion modeling estimates the pick density each candidate route imposes on each aisle-time cell, and zone routing re-paths or re-times waves so no cell exceeds its density ceiling. The Congestion Modeling & Zone Routing guide implements the density estimator and the routing policy: converting the base distances from the travel-cost model into congestion-adjusted times, detecting hotspots from historical pick density, and enforcing one-way aisle direction and zone boundaries. The key discipline is that congestion is a multiplier on the travel-cost model, never a replacement for it — you compute the base route first, then inflate its cost by the density it creates. Skip this stage and your “optimal” plan sends every wave down the same golden aisle at the same minute, converting a modeled saving into a real traffic jam.

Wave & Batch Pick Sequencing

Sequencing decides which order lines are released together and in what order, and it is where travel, cube, and congestion costs are finally spent. Batch too aggressively and you cut travel per line but overload a zone; sequence poorly and labour arrives in bursts the floor cannot absorb. The wave and batch sequencer groups tasks into routes under a labour budget, balances those routes so no picker finishes twenty minutes before the next, and orders the releases so downstream congestion stays bounded. The Wave & Batch Pick Sequencing guide builds the sequencer: batching heuristics that weigh travel savings against zone load, labour-balancing across parallel pickers, and the release cadence that keeps the packing line fed without starving or flooding it. This is the stage that turns the other three costs into a schedule — it reads route times from the travel-cost model, respects the density ceiling from the congestion router, and consults utilization scores so a wave never over-picks a location past its fill. It is the last transformation before the sequence is pushed to the WMS.

Production Implementation: End-to-End Wave Optimization

The components compose into a single deterministic pass: load locations, build a travel-cost function over the aisle graph, score two candidate waves, and commit the lower-cost plan. The orchestrator below is intentionally self-contained and runnable — it builds a small aisle graph, defines a rectilinear-plus-turn-penalty cost function, sequences two candidate batchings of the same order lines, and selects the cheaper one under structured logging so a bad candidate never silently ships.

The pattern generalizes directly to production. In a live system, load_locations reads the committed slot assignments rather than a hard-coded grid; travel_cost is replaced by a lookup into the precomputed distance matrix; and pick_cheaper_wave evaluates not two but hundreds of candidate batchings generated by the sequencer, each already filtered against the congestion ceiling and utilization scores. What stays constant is the shape: candidates in, a single scalar cost per candidate, the minimum committed, and every decision logged with the margin by which it won. That margin is the audit trail — a wave that wins by two seconds over its runner-up is telling you the plan is barely differentiated and the layout, not the sequencer, is the constraint worth attacking next.

from __future__ import annotations

import logging
from dataclasses import dataclass, field

logging.basicConfig(level=logging.INFO, format="%(levelname)s %(name)s: %(message)s")
logger = logging.getLogger("pickpath.wave")


@dataclass(frozen=True)
class Loc:
    location_id: str
    x: float
    y: float
    aisle: str


def load_locations() -> dict[str, Loc]:
    """Stand-in loader; in production this reads the committed slot assignments."""
    grid = [
        Loc("A-01", 0.0, 2.0, "A"), Loc("A-05", 0.0, 10.0, "A"),
        Loc("B-02", 6.0, 4.0, "B"), Loc("B-06", 6.0, 12.0, "B"),
        Loc("DOCK", 0.0, 0.0, "DOCK"),
    ]
    logger.info("Loaded %d locations", len(grid))
    return {loc.location_id: loc for loc in grid}


def travel_cost(a: Loc, b: Loc, walk_mps: float = 1.2,
                turn_penalty_s: float = 4.0) -> float:
    """Rectilinear aisle distance in seconds, with a penalty per aisle change."""
    distance_m = abs(a.x - b.x) + abs(a.y - b.y)   # cannot walk through racking
    turns = 1 if a.aisle != b.aisle else 0
    return distance_m / walk_mps + turns * turn_penalty_s


def route_time(order: list[Loc]) -> float:
    """Total seconds to walk an ordered route, dock to dock."""
    return sum(travel_cost(order[i], order[i + 1]) for i in range(len(order) - 1))


def score_wave(batches: list[list[str]], locs: dict[str, Loc]) -> float:
    """Sum route time across every batch in a candidate wave plan."""
    dock = locs["DOCK"]
    total = 0.0
    for batch in batches:
        route = [dock] + [locs[l] for l in batch] + [dock]
        total += route_time(route)
    logger.info("Candidate wave: %d batches, %.1fs total", len(batches), total)
    return total


def pick_cheaper_wave(candidates: dict[str, list[list[str]]],
                      locs: dict[str, Loc]) -> str:
    """Score each candidate batching and commit the lowest-cost plan."""
    scored = {name: score_wave(batches, locs) for name, batches in candidates.items()}
    winner = min(scored, key=scored.get)
    logger.info("Committing wave '%s' at %.1fs (saved %.1fs)",
                winner, scored[winner], max(scored.values()) - scored[winner])
    return winner


if __name__ == "__main__":
    locations = load_locations()
    # Same four lines, two different batchings.
    candidate_waves = {
        "by_order":  [["A-01", "B-06"], ["A-05", "B-02"]],   # naive, crosses aisles
        "by_aisle":  [["A-01", "A-05"], ["B-02", "B-06"]],   # aisle-consolidated
    }
    pick_cheaper_wave(candidate_waves, locations)

Run in shadow mode first: compute wave plans against a historical extract and compare modeled route time to the timestamps the picks actually recorded. Only after the modeled and observed times agree within tolerance should the plan drive live task release behind a circuit breaker.

Telemetry & the Feedback Loop

A wave plan is a prediction, and a prediction that is never checked against reality drifts. The feedback arc in the architecture diagram is what keeps this layer honest: every confirmed pick emits a telemetry record — location, timestamp, picker, and the task it completed — and those records are the ground truth against which the model recalibrates. Three quantities are recovered from the stream and fed back.

First, observed inter-pick time. Regressing the seconds between consecutive picks against the modeled aisle-graph distance recovers the real walk_speed_mps and turn_penalty_s for the current shift, cart mix, and staffing level. This is the single most important calibration in the system, because those two parameters scale every route time; a model calibrated against last quarter’s staffing silently misprices every plan. Wire the telemetry through the Velocity Data Ingestion & WMS Sync Pipelines layer so the regression runs on fresh, validated events rather than a stale nightly export.

Second, realized congestion. Clustering completed picks into aisle-time cells reveals where density actually built up, which is rarely exactly where the model predicted. Those observed hotspots re-fit the congestion multiplier so the next wave routes around the real bottlenecks, not the modeled ones.

Third, utilization drift. Comparing picked quantities against location capacity over several cycles surfaces faces that are chronically under- or over-filled — the candidates the system hands back to the Location Assignment & ABC Classification Algorithms layer for re-slotting, and the same signal the Core Slotting Architecture & Velocity Taxonomies map uses to keep zone definitions current.

The discipline is to treat the gap between modeled and observed as an alarm, not noise. When a wave’s realized picker-hours diverge from the plan beyond tolerance, the circuit breaker halts automated release and the divergence becomes the next calibration target — a closed loop that tightens rather than a plan that decays.

Operational Parameters

Every lever lives in one externalized profile so a facility can be re-tuned without touching code. Ship it as YAML for planners and load it into the identical Python dict the engine consumes.

# pickpath_params.yaml — one profile per facility
travel:
  walk_speed_mps: 1.2          # loaded-cart walk speed; calibrate from pick timestamps
  turn_penalty_s: 4.0          # added seconds per aisle change / 180-degree turn
  metric: "aisle_graph"        # aisle_graph | rectilinear | euclidean
utilization:
  target_fill: 0.80            # desired cube fill; below this = consolidation candidate
  overflow_fill: 0.92          # above this = receiving-jam risk
  honeycomb_weight: 0.30       # penalty weight on stranded partial-pallet capacity
congestion:
  aisle_density_ceiling: 3     # max concurrent pickers per aisle segment
  congestion_multiplier: 1.6   # travel-time multiplier applied at the ceiling
wave:
  labour_budget_min: 20.0      # target minutes of work per picker per wave
  max_batch_lines: 24          # cap on order lines per batch
  balance_tolerance: 0.15      # max allowed spread across parallel routes
PICKPATH_PARAMS = {
    "travel": {"walk_speed_mps": 1.2, "turn_penalty_s": 4.0, "metric": "aisle_graph"},
    "utilization": {"target_fill": 0.80, "overflow_fill": 0.92, "honeycomb_weight": 0.30},
    "congestion": {"aisle_density_ceiling": 3, "congestion_multiplier": 1.6},
    "wave": {"labour_budget_min": 20.0, "max_batch_lines": 24, "balance_tolerance": 0.15},
}

The two parameters that most change floor behaviour are walk_speed_mps (mis-calibrate it and every route time is wrong by the same factor, silently) and aisle_density_ceiling (lower it and waves spread out, raising travel but cutting queueing). Treat both as facility-specific and re-fit them whenever the labour model or layout changes.

Parameter sensitivity is not uniform, and grouping the levers by what they control keeps tuning tractable. The travel block is a physics calibration — it should track how fast people and carts actually move, and it changes only when equipment or staffing does. The utilization block is a space policy — target_fill and overflow_fill bracket the band you want most faces to sit in, and they move with your replenishment cadence and surge strategy, not with demand. The congestion block is a throughput governor that bites only near peak, so tune it against your busiest hour, not your average one. The wave block is a labour contract with the floor: labour_budget_min and balance_tolerance decide how evenly work lands, and setting them too tight manufactures idle time while setting them too loose lets one picker carry a wave. Change one block at a time and re-measure, because a simultaneous edit to travel and congestion makes it impossible to attribute the resulting swing in picker-hours to either.

Failure Modes & Remediation

  • Stale or naive distance matrix. A matrix built on euclidean distance, or one not rebuilt after a rack move, understates travel and produces routes that cross racking the picker cannot walk through. Rebuild the aisle graph on any layout change and validate a sample of modeled distances against a measuring wheel before trusting it.
  • Un-modeled congestion at peak. A plan that ignores density sends every wave down the same golden aisle at the same minute, converting a modeled saving into a real jam. Apply the congestion_multiplier above the aisle_density_ceiling and stagger release times, not just paths.
  • Cube overflow into receiving jams. Sequencing that over-picks a location past overflow_fill blocks replenishment and strands partial pallets. Read live UtilizationScore state, not a nightly snapshot, and cap batch draw per location.
  • Labour imbalance across parallel routes. Batches that violate balance_tolerance leave one picker idle while another runs long, erasing the throughput gain. Enforce the balance check in the sequencer and re-split any route outside tolerance.
  • Walk-speed drift. A walk_speed_mps set once and never recalibrated diverges from reality as cart loads and staffing change, biasing every route time. Re-fit it from pick timestamps each time labour or equipment changes.
  • Feedback starvation. If pick telemetry does not re-enter the loop, the model optimizes against last quarter’s floor. Wire completed picks back through the ingestion pipeline so travel weights and utilization scores track the live facility.

Deployment Checklist

  1. Freeze the canonical Location / PickTask / Route / WavePlan / UtilizationScore schemas against the assignment contract and assert field names and types match the upstream feed at startup.
  2. Build and cache the aisle graph; validate a random sample of modeled distances against physical measurement before enabling.
  3. Load pickpath_params.yaml, validate ranges (0 < target_fill < overflow_fill < 1, walk_speed_mps in a plausible 0.8–1.6 band), and fail closed on out-of-range values.
  4. Calibrate walk_speed_mps and turn_penalty_s against timestamped pick telemetry, not vendor defaults.
  5. Run the wave optimizer in shadow mode over a 30-day extract; reconcile modeled route time against observed pick timestamps within tolerance.
  6. Promote to advisory mode: surface wave plans to supervisors, tracking override rate as a trust signal.
  7. Enable live task release behind a circuit breaker that halts if modeled and observed times diverge beyond tolerance or if any aisle exceeds its density ceiling.
  8. Stand up dashboards for lines-per-hour, average route length, cube fill distribution, and peak aisle density; alert at 3σ deviations.

Measure success against operational baselines, not model accuracy: target a 15–25% reduction in average route length within 60 days, a 10–18% lines-per-hour uplift from labour-balanced waves, cube fill held in the target_fill–overflow_fill band across 85% of active faces, and zero aisle-time cells sustained above the density ceiling during peak.