Inventory Optimization

Multi-echelon inventory planning with BOM expansion, supply forecast, and data-center inventory balancing

Previewproblem type inventorymanifest 1.1

Objectives#

What the solver optimizes. Enabled objectives are weighed together.

Objective	What it means	Direction	On by default	Weight
Maximize Replenishment Fitness `maximize_replenishment_fitness`	Favor plans with better overall evolutionary fitness		Yes	1.0
Minimize Rack Build Days `minimize_rack_build_days`	Prefer plans that reduce final rack build latency	minimize	Yes	0.5

The setup values you send with a problem. The console renders them as form fields.

Input	Name	Type	Required	Default	Description
`horizon`	Planning Horizon	integer	Yes	7	Number of days to optimize across the inventory plan

Input	Name	Type	Required	Default	Description
`pop_size`	Population Size	integer	Yes	50	Evolutionary search population size
`generations`	Generations	integer	Yes	100	Number of generations for the EvoCogniSolve search

Input	Name	Type	Required	Default	Description
`n_products`	SKU Types	integer	No	480	Number of SKU/product types used when generating demo inventory data
`n_locations`	Data Centers	integer	No	8	Number of locations used when generating demo inventory data
`n_periods`	Forecast Periods	integer	No	35	Number of planning periods for generated forecast and inventory snapshots
`n_suppliers`	Suppliers	integer	No	72	Number of suppliers used in generated BOM and forecast data
`n_rack_types`	Rack Types	integer	No	8	Number of rack types in generated BOM data
`n_sub_assembly_types`	Sub-assembly Types	integer	No	48	Number of sub-assembly types in generated BOM data
`supplier_sku_overlap_ratio`	Supplier SKU Overlap	number	No	0.3	Target ratio of shared SKU coverage across supplier catalogs in generated demo data
`bom_fungibility_ratio`	BOM Multi-source Ratio	number	No	0.4	Target ratio of BOM lines that can be sourced from multiple suppliers in generated demo data

Input	Name	Type	Required	Default	Description
`rules_text`	Policy Rules	string	No		Rule DSL for SKU fungibility, shortage priority, and other inventory policies

A hard constraint must hold or the problem is infeasible; a soft one adds a penalty when broken.

Constraint	What it requires	Kind	On by default
BOM Feasibility `bom_feasibility`	Cumulative racks built cannot consume more part-units than cumulative arrived supply affords (aggregate over the BOM's rack -> sub-assembly -> SKU -> supplier quantities). The defining rule of the rack-build problem: you cannot assemble what has not arrived.	hard	Yes
Location Capacity `location_capacity`	Respect location-level capacity and inventory tensor bounds	hard	Yes
Supplier Lead Time `supplier_lead_time`	Respect supplier lead-time / replenishment latency assumptions	hard	Yes
Stockout Risk Penalty `stockout_risk`	Penalize plans that over-expose the network to stockout risk	soft	Yes