Predictive Logistics Developer

Predictive Logistics Developer

When to Use

• Build demand forecasts at SKU, location, lane, or network-node granularity with logistics-aware features
• Design inventory positioning and safety stock model interfaces that feed planning and execution systems
• Predict ETA, lead time, and transit time distributions from operational and external signals
• Forecast capacity, congestion, and throughput for nodes, lanes, and facilities at integration level
• Integrate route and network flow predictions with TMS/WMS/OMS—not full VRP solver implementation
• Model cold chain, perishables, and shelf-life constraints in forecast and positioning logic
• Encode promotions, seasonality, and calendar effects for logistics demand and capacity
• Run backtests, monitor drift, and score models against fill rate, OTIF, WMAPE/MAPE, and service KPIs
• Define feature stores, inference contracts, and batch/real-time scoring pipelines for logistics ML

When NOT to Use

• Pure OR/MIP formulation and solver implementation without logistics prediction scope → operations-research-algorithm-developer
• Supply chain strategy, RFQ, supplier scorecards, or inventory policy governance without ML build → supply-chain-manager
• WMS workflows—waves, pick paths, RF scanning, slotting application logic → wms-developer
• Fleet telematics ingestion, map matching, or geospatial pipeline engineering → geospatial-telematics-developer
• Generic ML experimentation, causal inference, or MLOps without logistics domain framing → data-scientist
• EDI/X12 mapping, AS2, or partner document translation → edi-engineer
• Warehouse dimensional modeling or dbt mart design without prediction modeling → analytics-data-engineer

Related skills

Core Workflows

1. Scope and problem framing

Clarify horizon, granularity, decision consumer, and operational KPI contract.

See `references/predictive_logistics_scope.md`.

2. Demand forecasting and features

Build SKU/location/lane demand models with logistics calendars, promotions, and hierarchy reconciliation.

See `references/demand_forecasting_and_features.md`.

3. Inventory and network positioning

Connect forecasts to positioning, safety stock interfaces, and multi-echelon handoffs.

See `references/inventory_and_network_positioning.md`.

4. ETA, lead time, and capacity

Model transit times, node congestion, and capacity signals for planning and execution.

See `references/eta_leadtime_and_capacity.md`.

5. Evaluation and monitoring

Backtest against operational KPIs; track drift, bias, and forecast value.

See `references/model_evaluation_and_monitoring.md`.

6. Operations integration

Wire scores to OMS/TMS/WMS, planning cycles, and human-in-the-loop overrides.

See `references/integration_with_operations.md`.

Outputs

• Problem brief — granularity, horizon, consumers, KPI targets, and non-goals
• Feature catalog — definitions, freshness SLAs, leakage checks, and hierarchy keys
• Model card — training window, metrics (WMAPE/MAPE, bias), segments, and known failure modes
• Backtest report — rolling-origin results tied to fill rate, OTIF, or inventory service proxies
• Inference contract — schema, latency, batch cadence, fallback rules, and version pins
• Monitoring runbook — drift thresholds, retrain triggers, and escalation to planning ops

Principles

• Optimize for operational KPIs, not only statistical accuracy — tie WMAPE to service and inventory outcomes
• Respect logistics calendars — lead times, cutoffs, carrier schedules, and promotion lift are first-class features
• Prevent leakage — exclude post-decision signals; align train labels to information available at forecast origin
• Reconcile hierarchies — bottom-up vs top-down consistency for SKU × location × lane stacks
• Separate prediction from optimization — deliver distributions and interfaces; route MIP/VRP to OR peers
• Monitor in production — drift, bias by lane/node, and forecast value beat one-time offline accuracy
• Document override paths — planners and TMS rules may supersede scores; model serving must degrade safely

When to load references

Demand forecasting and features

Forecast design checklist

1. Define granularity — SKU, location, lane, customer segment; minimum volume for stable series 2. Set horizon and cadence — daily vs weekly; align to replenishment and transportation planning cycles 3. Choose target — units, cases, weight, cube; handle pack-size changes explicitly 4. Establish hierarchy — reconcile SKU → family → location → region (bottom-up, top-down, or MinT) 5. Document forecast origin — timestamp and information cutoff to prevent leakage

Feature families

Seasonality and promotions

• Fit multiple seasonalities when cadence mixes daily noise with weekly retail patterns
• Model promotional lift with explicit start/end; avoid training on post-promo returns as demand
• Separate stockout-censored periods—zero demand may be unobserved demand
• For lane demand, aggregate ship-to patterns and mode mix shifts

Hierarchy reconciliation

Model selection (logistics-aware)

Prefer global models across series when thousands of SKUs share calendars and promotions.

Outputs for downstream systems

• Point forecast + prediction interval (P50/P90) for safety stock interfaces
• Forecast version and as_of timestamp for audit
• Explainability slice by driver (promo, season, stockout flag) for planner trust

Anti-patterns

• Training on shipped quantity when ordered demand is the planning target during stockouts
• Using future inventory transfers known only after forecast origin
• Single MAPE target without volume weighting—WMAPE by lane/SKU volume
• Ignoring pack-size or UOM changes without restating history

ETA, lead time, and capacity

Lead time and ETA modeling

Problem variants

Modeling approach

1. Define event timestamps — order release, pickup, hub arrival, out-for-delivery, delivery 2. Align labels to information available at prediction time (no future scans) 3. Predict distribution—quantiles or survival time—for promise-date engines 4. Calibrate by lane and carrier; avoid global averages on heterogeneous networks

External and operational signals

Capacity and congestion

Build congestion indices from rolling dwell times, backlog depth, and scheduled vs actual appointments—not only static nameplate capacity.

Route and network flow (model-integration)

• Forecast origin-destination volumes and mode mix for planning horizons
• Provide uncertainty for robust planning inputs
• Do not implement VRP, time windows, or driver scheduling—hand to OR skill with forecasted OD matrix

Cold chain transit

• Add temperature compliance risk features (lane history, season, equipment type)
• Extend lead-time variance for refrigerated lanes with higher disruption rates
• Separate spoilage clock from transit clock for perishables

Evaluation specifics

Penalize late bias differently from early bias when customer promise dates asymmetric.

Production patterns

• Batch refresh for planning (daily/weekly lane tables)
• Near-real-time ETA updates for TMS dashboards with staleness bounds
• Fallback to historical lane median when feature pipeline fails
• Version carrier network changes explicitly in model registry

Integration with operations

Integration map

Inference contract template

Document for each score:

Batch vs real-time

Define idempotent writes and partition keys for backfills.

Human-in-the-loop

• Expose override reason codes in planning UI; log for model feedback
• Never silently overwrite planner buffers without audit
• Provide explainability snippets (top drivers) for low-trust segments

EDI and event alignment

• Use edi-engineer for 856/214/990 field semantics; consume status events as features only
• Normalize status timestamps to a single event timeline
• Handle late postings and duplicate events in feature pipelines

Failure modes and degradation

Security and data boundaries

• No PII in feature stores unless required—aggregate ship-to where possible
• Separate prod vs sandbox score tables; prevent test writes to planning prod

Release checklist

• [ ] Schema contract signed with WMS/TMS consumers
• [ ] Backtest attached for promotion window
• [ ] Monitoring dashboards and paging rules live
• [ ] Rollback version pinned in registry
• [ ] Runbook for fallback and manual override communicated to planning ops

Inventory and network positioning

Purpose

Connect demand and lead-time forecasts to inventory positioning inputs—where to hold stock, how much buffer, and how echelons interact—without owning supply chain policy sign-off.

Positioning problems

Safety stock interface design

Deliver to optimization engines:

• Demand distribution over risk period (not only point forecast)
• Lead-time distribution by lane/supplier (mean, variance, service level target)
• Forecast error covariance when systems support it; else segment-level scaling factors

Document:

• Service level target assumed (e.g., 95% cycle service vs fill rate)
• Review period and protection interval alignment
• Override hooks for planner buffers and commercial commitments

Multi-echelon considerations

Do not conflate forecast with allocation solver—pass inputs to OR or policy engines.

Cold chain and perishables

• Model remaining shelf life at receipt and FEFO constraints as features
• Forecast spoilage-adjusted demand—discard unsellable inventory from sellable forecast
• Tie markdown triggers to spoilage risk thresholds separately from base demand
• Include temperature excursion flags as exogenous shocks when telemetry exists

Network flow forecasting (integration level)

• Predict volume between nodes for S&OP and lane procurement
• Provide confidence bands for capacity planning—not detailed route sequences
• Hand off route optimization to operations-research-algorithm-developer with forecasted flows as parameters

Validation tied to inventory KPIs

Handoffs

• `supply-chain-manager`: Approve service levels, ABC/XYZ policies, and S&OP targets
• `operations-research-algorithm-developer`: Multi-echelon optimization with distributional inputs
• `wms-developer`: Consume positioning targets in replenishment workflows

Model evaluation and monitoring

Backtesting discipline

1. Rolling-origin evaluation — refit or refit-window policy documented; no single holdout on logistics seasonality 2. Match decision cadence — if planners run weekly, backtest weekly origins 3. Segment reporting — lane, node, ABC class, promo vs non-promo, cold chain vs ambient 4. Link statistical metrics to operational proxies — WMAPE segments vs simulated fill rate impact where possible

Core metrics

Report WMAPE and bias at minimum for executive and planning audiences.

Operational KPI linkage

Build a forecast value analysis table—did improved WMAPE reduce stockouts or inventory dollars?

Bias and fairness checks

• Geographic bias — systematically under-forecasting rural lanes
• New product bias — ramp under/over shoot
• Promo decay — post-promo negative bias
• Carrier change — regime shift undetected

Production monitoring

Define retrain triggers: sustained WMAPE degradation, major network redesign, new SKU class rules.

Model registry artifacts

• Training data window, feature schema version, hyperparameters
• Backtest report attachment and sign-off checklist
• Champion/challenger promotion criteria
• Rollback procedure when OTIF or fill rate regresses post-deploy

Champion/challenger workflow

1. Shadow score in production without driving decisions 2. Compare offline backtest and shadow operational KPIs 3. Promote with canary segment (e.g., one region or carrier tier) 4. Full cutover with monitoring escalation path

Predictive logistics scope

Purpose

Define predictive modeling for logistics networks—forecasting demand, transit and lead times, capacity stress, and inventory positioning inputs that drive planning and execution.

This skill covers ML feature design, training, evaluation, monitoring, and integration contracts—not supply chain strategy governance, WMS product features, pure optimization solvers, or telematics pipeline engineering.

Terminology

In scope

Out of scope

Problem taxonomy

Roles and RACI

Handoffs

• To `operations-research-algorithm-developer`: Provide forecast distributions and cost parameters; receive optimized plans—not embed solver logic in notebooks
• To `supply-chain-manager`: Translate model assumptions into policy and S&OP cadence; do not own supplier negotiations
• To `wms-developer`: Define inference APIs and event hooks; do not implement pick-path algorithms
• To `geospatial-telematics-developer`: Specify telematics features needed; do not own device ingestion
• To `edi-engineer`: Align shipment status fields used as features; do not own partner mappings