Order lines, not buckets
Plan at the atomic decision level — every order, every supply event. Not aggregated weekly cells.
The third architectural move is the one most planning systems flinch from. Plan at the atomic decision level — every Order Line, every Supply Event — not at aggregated time-series buckets per SKU-location-week. Aggregation hides exactly the information that decisions need.
Consider a single weekly demand bucket at MIC: SKU-A-2891 at Loc-Houston, Week 24, 1,200 units. The bucket says nothing about composition. The actual composition is three distinct objects: Customer-Alpha's 600-unit SLA-bound order (28% contract margin, must ship from Houston, no substitutions accepted), Customer-Bravo's 400-unit spot order (35% margin, accepts the SKU-A-2891-R substitute, ±3 days flexibility, indifferent to source DC), and 200 units of forecast residual. When supply gets tight, the bucket view has no way to allocate; the order-line view allocates Customer-Alpha first by contract, shifts Customer-Bravo's flexible portion to Week 25 at the customer's accepted slip tolerance, substitutes 200 of the residual. The decision is only possible when the atoms are preserved.
The cost of this commitment is real. The MILP at a typical $1B industrial — 3,000 SKUs, four DCs, 200 active customers — runs across roughly 144,000 active Order Lines and 60,000 active Supply Events. Scoping discipline becomes essential (the change-interpretation layer narrows each solve to the affected dependency graph rather than the full network). The engineering work to make this tractable on commodity compute was substantial. It earns what it costs.
What it earns: margin awareness at the line at the moment of commit, per-decision EVA computation, per-decision Resilience Score, customer-specific allocation under scarcity, the pegging-driven cost cascade that flows realized cost-to-serve back to the demand line that triggered it, per-customer substitution eligibility, customer-and-channel cost-to-serve, per-commit decision provenance. None of these are reachable from a bucket-based architecture no matter how much capability is layered on top.
VYAN uses distributions, not values. VYAN plans at the order-line / supply-event grain, not in aggregated buckets. The rest of this book is built on these two commitments.