POD — Predict, Optimize, Decide

Demand requirements are expanded through bills of materials into purchased-item histories. Models produce integer probability laws; missing observations remain distinct from observed zeros. Lead-time models use completed receipts and right-censored open orders, conditioning remaining receipt time on an order’s age.

The demand shortlist includes empirical hurdle and TSB models, a profile-based recency KDE, a Patch Transformer and an item router. Model eligibility and short-history handling are explicit. Fitting and backtests respect chronological information cutoffs.

Demand comparisons use matched eligible SKU/week observations. The demand router ranks candidates using the mean of NLL and RPS ranks on earlier validation evidence, then absolute mean bias and score tie-breaks. The lead-time router selects the lowest mean causal validation RPS among eligible saved base models with sufficient support.

A router selects an existing base PMF; it does not imply a new ensemble accuracy gain. Model choice within router segments is automatic during explicitly requested training. Held-out evaluation and downstream decision cost remain separate checks.

Demand profiles use saved PCA coordinates, groups and hierarchical priors. Lead-time routes are organized by transport, geography and native supplier-history support, with supported parent pools or configured fallbacks for sparse contexts. Membership and routes are frozen at their information cutoff.

Configuration controls where each model may run. Disabled segments skip inference and scoring; every segment must retain suitable base-model coverage. Changed eligibility requires saving and retraining. Snapshot and cache identities prevent incompatible scientific inputs, recipes or coverage settings from silently reusing old fits.

Monte Carlo sampling produces demand and receipt outcomes. The objective is the sample mean of per-scenario cost-component totals, subject to a policy-defined feasibility test. Plans contain integer quantities by transport mode and a planning lead time. That planning value does not control the physical receipt time, which remains a forecast outcome.

Policies and optimizers are independently authored Rust modules. The generic optimizer combines grid and quantile initializations, an affine extension over integer simplices to obtain gradients for Adam, followed by integer-neighbour refinement. A selected custom optimizer can use a different search strategy; there is no implicit solver substitution.

Only training scenarios enter search. The chosen plan is checked for feasibility, repriced, and evaluated on separate holdout scenarios. Reports distinguish uncertainty in estimated cost, local decision stability and search termination. A heuristic result is not a certified global optimum.

The Python application is a modular monolith built by object composition. Source connectors and domain modules implement typed protocols for execution, queries and capabilities. A registry checks missing providers and cyclic dependencies before use; modules exchange typed references to versioned artifacts.

Economic policy–optimizer pairs execute in fresh WebAssembly instances with fuel, memory and time limits. Trusted local compilation is separate from execution. Python retains forecasting and orchestration; the sandbox exposes no filesystem, network or WASI access.

Configured worker jobs prepare models, forecasts, scenario valuations and reports without manual processing of individual items. Regular and historical jobs have separate queues but share bounded compute capacity. Data refresh, policy activation and historical-job submission remain explicit actions. The interface reads saved results.

The runtime view follows the actual linked source-preparation, model-training and calculation executions, including reused earlier work. It shows stage episodes, model/component calls, cache outcomes and sampled worker-tree memory. Inter-execution waiting is excluded from summed step time.

Stage time and inclusive nested work answer different questions: nested calls can overlap. Memory peaks cover saved samples and their recorded execution scope; absent samples cannot establish a historical peak. The administrative developer view reads existing records without starting computation.