Go back to Market Research
o9 Solutions supplies enterprise planning software for manufacturers, retailers, and distributors. Its Digital Brain platform combines demand forecasting, supply and production planning, inventory policies, commercial planning, and integrated business planning. Customers use its data models, solvers, configurable workflows, and extensions to generate plans, compare scenarios, and coordinate decisions across business functions. (1, 2, 3)
Overall supply chain score: 4.1/10.
| Dimension | Score |
|---|---|
| Supply chain depth | 3.8/10 |
| Decision and optimization substance | 4.4/10 |
| Product and architecture integrity | 4.6/10 |
| Technical transparency | 3.8/10 |
| Vendor seriousness | 3.8/10 |
o9’s governing approach combines a common enterprise model with forecasts, inventory policies, configurable allocation rules, and scenario selection. Its retail application produces purchase and transfer orders; its enterprise workflows help people reconcile and commit plans. The central weakness is how those policies and priorities translate into economic choices under uncertainty. Channel profitability can influence allocation without measuring the expected return on the next unit of stock. Financial scenarios and inventory-cost calculations have documented roles, but the joint calculation of purchases, production, prices, and risk remains largely unspecified. Its LP/MIP architecture must also accommodate revisions when operations expose missing costs, dependencies, or constraints. (2, 3, 4, 41)
The same gap affects the autonomy proposition. o9’s examples emphasize explaining deviations, capturing planner knowledge, and improving rules and workflows. (3, 9, 10) Its technology history includes a 2019 promise of a “self-driving” supply chain without measured coverage of unattended decisions. Maintaining the models, integrations, and configurations adds a further cost that the headline productivity figures do not capture. (25, 29, 51)
o9 Solutions versus Lokad
o9 organizes planning around a shared enterprise model and configurable applications. Customers can also develop algorithms: its coffee-retailer case describes an internal data science team running its own Python code on the platform. Lokad organizes the implementation around a business-specific calculation that values and selects operational decisions under uncertainty. Both approaches require engineering; the difference concerns what that engineering is intended to produce. (28, 31, 36)
Consider a retailer allocating its last units between stores. o9 documents replenishment driven by forecasts and stock policies, with allocation priorities that can include channel profitability. Lokad’s approach is to calculate the expected monetary consequences of competing allocations, including uncertain sales and the value of alternative uses of stock. The economic distinction concerns how the next unit is valued: a store’s priority or average profitability can differ substantially from the return on sending that particular unit there. The allocation example below makes the distinction explicit. (35, 36, 41)
Lokad’s stated approach makes specialists responsible for improving reusable decision logic. Its holimization perspective treats the objective, data interpretation, and available decisions as hypotheses to revise when operations expose mistakes. (35, 50) o9 provides customer models, Python extensions, and version-controlled configuration. (29, 31) The practical comparison concerns how each system converts a harmful recommendation into corrected logic that works across subsequent cases, and what that improvement costs in engineering and recurring intervention.
A common model does not specify the economic calculation
o9’s Digital IBP page describes synchronized operational and financial plans, scenario evaluation, and executive decisions within the platform. Revenue, margin, cash, and working capital appear in the model. Its supply-planning page identifies heuristics, linear programming, mixed-integer programming, and external solvers. These are different parts of the problem: financial visibility describes consequences; a solver chooses actions only after someone specifies an objective and constraints. (2, 3)
The inventory documentation goes further. It describes network rebalancing, postponement, shelf-life restrictions, and a calculation balancing holding costs, delivery penalties, and expediting costs. (4) The remaining economic question is broader: how does changing a price alter demand and production, and how should that alter purchases competing for the same cash? The public material does not provide a formulation or worked example joining those choices.
The retail allocation documentation identifies more of the decision process. Forecasts, stock policies, and safety-stock targets determine replenishment needs. Configurable rules distribute inventory using store priority, channel profitability, launch timing, and promotional importance. The application then generates purchase and stock-transfer orders. Additional calculations address capacity constraints and 90-day, 21-day, and daily horizons. (41)
The economically decisive step is the allocation rule. Consider an illustrative end-of-season choice: one unit remains at a warehouse, acquisition cost is already sunk, transfer costs are equal, and an unsold unit has no residual value. The probabilities below concern selling this additional unit after accounting for each store’s existing stock.
| Destination | Net proceeds if the additional unit sells | Probability of sale | Expected proceeds |
|---|---|---|---|
| Store A | €20 | 10% | €2.00 |
| Store B | €8 | 90% | €7.20 |
Sending the unit to B yields €5.20 more in expected proceeds. A ranking based only on proceeds per sale selects A. Real allocations must also account for substitutes, future deliveries, markdowns, and effects on other purchases. Each changes the incremental value of the unit. A priority system needs to incorporate those consequences to make the economic choice reliably.
o9 also describes constraint-aware optimization and service/cost trade-offs on the allocation page. It does not explain how these calculations interact with the configured priorities when they favor different destinations. (41) If a business priority takes precedence, that priority determines the allocation’s opportunity cost. If an optimizer can override it, the objective and override conditions determine the result. The distinction matters to customers maintaining these rules: adding another exception can change which orders lose access to shared stock.
o9’s collaborative-demand product explicitly aligns functions around one reconciled forecast and automates parts of consensus formation. Its replenishment guidance recommends service targets and ABC classification. (5, 6) Agreement on a forecast cannot eliminate the range of possible demand, and a service target does not tell a manufacturer whether another use of its capital is more profitable. These conventions remain central beneath the newer AI vocabulary.
Uncertainty, digital twins, and causal claims
Risk-adjusted replenishment requires a probabilistic projection of demand and future receipt dates, including their dependencies. The stock needed before a delivery depends on both how much customers buy and how long replenishment takes. A demand distribution combined with a fixed average lead time can miss the exposure created by long delays. A late common component can also disrupt several finished products simultaneously. The decision calculation needs to value these possible outcomes and their probabilities; optimization cannot recover uncertainty omitted from its inputs.
o9’s MEIO documentation says it models demand and supply variability when calculating stocks. It does not describe their joint distributions, conditioning on current information, or how those projections enter order selection. (4) Separate demand-risk and supplier-risk indicators leave the calculation of demand before receipt unresolved. A collection of internally consistent what-if scenarios likewise supplies no probability model until the possible futures and their likelihoods are established. These are prerequisites for evaluating shortages, expediting, and excess inventory economically.
The July 2026 knowledge-graph demonstration provides a concrete example. A planner records that a supplier regularly delivers late in the fourth quarter. The system checks the observation against history, contrasts a 26-day ERP lead time with approximately 46 days in that quarter, and proposes changes to rules and affected orders. (10) The featured workflow starts with a person noticing a pattern already present in the data. Seasonal lead-time estimation should run systematically; remembering suppliers’ seasonal behavior is expensive recurring work. Replacing one lead-time parameter also leaves the variability around it unresolved.
o9 made a more ambitious predictive claim in October 2022. Its Supply Sensing launch promised warnings about commodity availability and prices up to twelve months before effects reached a tier-one supplier, with event probabilities and suggested mitigation. The announcement gives no calibration results, false-alarm rate, or test of whether acting on the alerts improved returns. (8) Those measurements determine whether an early warning is worth paying for.
The current neuro-symbolic description adds causal agents and post-game analysis: it proposes attributing deviations to demand, supply, policies, and execution. (9) Attribution requires more than a consistent record of plans and outcomes. A stockout changes observed sales; a planner’s intervention changes the outcome used to judge the original recommendation. A digital twin predicting the effect of alternative actions is a high-dimensional conditional forecast. Its errors and causal assumptions need validation before the resulting explanations can safely update the decision rules.
Forecast accuracy at the wrong scale
o9’s production-planning article promotes weekly aggregate accuracy above 95%, then connects that figure to steadier production, lower safety stocks, and fewer emergency changeovers. (14) This is a red flag: weekly totals can be accurate while the product mix and daily timing needed for production remain wrong. The article supplies no error formula, forecast origin, or matched evaluation supporting that connection.
Its ZAMP account makes the resolution problem visible. The headline reports 92% accuracy, while the detailed results separately report 70% at store level. The project includes daily SKU forecasts for restaurants, but the article does not define the metric, horizon, or aggregation behind the two percentages. (13) The headline cannot be read as 92% accuracy for each restaurant’s daily ingredient requirements.
M5 illustrates how large this effect can be. Recalculating its fifty published leading point submissions over the final 28-day test period using 100 × (1 − WAPE) gives 22.1–25.1% at SKU/store/day level, versus 95.8–98.2% after pooling products and stores by day. The forecasts are unchanged; aggregation cancels errors. This diagnostic uses unit-volume absolute error, while M5’s official ranking used WRMSSE. (15)
o9’s demand-sensing description combines external signals, frequent updates, hierarchical forecasting, and daily or intraday outputs. (7) “Sensing” supplies no additional computational meaning. The relevant test is whether those signals improve decisions against a forecast using the same information cutoff and refresh frequency. A better estimate received after production is committed cannot repair that production decision. Validation must reach the product, location, and decision deadline, then measure the resulting margins, waste, and capital costs.
Planning the least predictable items
o9’s October 2025 training description classifies item-location combinations with a coefficient of variation above 0.7 as having low forecastability. Its recommended responses include cleaning data, applying tailored rules to selected items, moving up the product hierarchy or grouping items, and obtaining shared forecasts from customers and distributors. (42) This reveals how its planning doctrine handles difficult demand: seek a more stable representation and supplement the forecast with rules and collaboration.
Aggregation leaves an allocation problem underneath. A stable forecast for a product family does not determine which size, color, or location will need the stock. Distributing that total back to individual items requires assumptions about their proportions and dependencies. A rule that repeatedly assigns too much to one item and too little to another can preserve an excellent family-level forecast while creating excess stock and shortages simultaneously. The economic test concerns those decisions after disaggregation.
The collaboration and tailored-rule recommendations also carry a labor cost. Someone must identify the special cases, maintain their treatment, collect external judgments, and reconcile disagreements as the assortment changes. These tasks concentrate on the demand that is hardest to forecast. Automation figures restricted to stable items can therefore leave the most expensive work untouched. The training description supplies no workload measurement for this proposed treatment of low-forecastability items. (42)
o9’s Forecast Value Add training evaluates whether changes in the forecasting process improve forecast quality, then frames this as measuring the value of forecasting effort. (43) Forecast-error improvement cannot by itself price that effort or its inventory consequences. An adjustment may reduce error without changing an order because a minimum quantity binds; another may arrive after procurement is committed. Both can improve the forecasting metric without improving the decision. Evaluating the intervention economically requires its effect on purchases, shortages, waste, and labor cost.
LP/MIP: the cost of simplifying the problem
Reliance on LP/MIP is an architectural red flag when the advertised goal is to optimize the supply chain as a system. The computational difficulty starts before uncertainty is represented. Minimum orders and production setup charges create discrete, nonconvex choices that a pure LP must simplify. Smoothing these discontinuities can change which purchases or production runs appear profitable. Integer variables retain such choices by adding combinatorial search, which can become prohibitively expensive as products, locations, and periods interact. (37)
Expanding this model across possible futures compounds the computational burden. The extensive-form approach adds scenario-dependent decisions and constraints, with links preventing today’s purchase from depending on information revealed only later. (38) Each possible history brings its own subsequent stock, production, and allocation choices. Representing uncertainty this way increases the size and coupling of an already difficult model. Mathematical encodability supplies no evidence of practical supply-chain capability.
Branching over successive decision stages makes the expansion particularly severe. An illustrative tree with three outcomes at each of twelve branching steps has 531,441 terminal paths. Each path carries a history of outcomes and decisions; the number grows before adding more products or locations. Research on multistage inventory models explicitly identifies this exponential growth as a reason to seek simpler approximations. (46) The operational test is whether the model preserves consequential uncertainty and nonconvex choices while fitting the available memory and decision deadline. A small scenario demonstration does not establish that result at enterprise scale.
The July 2026 cuOpt announcement reports a supply-chain LP with roughly 30 million variables and 15.7 million constraints. It gives 661.7 seconds for a commercial CPU solver and 57.4 seconds for cuOpt on an NVIDIA B200, with objective values differing by approximately 0.008%. (11)
The technical article identifies the CPU baseline as eight cores and 32 GB of RAM, gives the cuOpt version, and discusses earlier H100 constraint violations. The demonstrated result is LP; GPU acceleration for mixed-integer and nonlinear problems remains further work. The model, CPU solver identity/settings, and infrastructure-cost comparison are absent. (12) The timings demonstrate acceleration of this model; the near-matching objective values do not measure its fidelity to operating economics.
For MIP, weak continuous relaxations produce loose bounds and can leave branch-and-bound and cutting-plane methods with substantial search work. (39) Scenario expansion adds to this burden. o9’s benchmark discloses no scenario structure, joint demand/lead-time model, or economic validation against unseen outcomes. (12) Its large LP earns no credit toward the tractability of a stochastic MIP retaining the same network scope and realistic discrete choices.
The deeper issue is what happens when operational results expose a faulty formulation. An optimality gap measures progress toward the optimum of the encoded problem; it cannot reveal an omitted shortage cost or a misinterpreted lead-time field. Even testing decisions against that same objective can preserve its blind spots. The holimization perspective treats the formulation itself as something to investigate and revise. (50) A solver architecture becomes an obstacle when incorporating a newly discovered economic interaction requires prohibitive re-engineering, destroys tractability, or forces the interaction back out. The relevant capability is the process for improving the decision logic, including what the system optimizes.
Reducing scenarios or shortening the horizon can make a model finish by discarding futures that drive shortage, obsolescence, or expediting costs. Dividing it into independent product or site problems can remove competition for cash, components, and capacity. Scenario reduction therefore needs economic tests on unseen outcomes, and decomposition needs explicit coordination of shared resources. The published benchmark does not explain what interactions or decision scope were retained to obtain its runtime. (11) Repeatedly solving point-forecast plans supplies no evidence that these uncertainty costs enter the calculation.
The press release also extrapolates from this eleven-minute CPU solve to workloads previously requiring overnight computation becoming available in under a minute. (11) Data preparation, model generation, and downstream processing are not measured. Neither the broader speed claim nor the economic value of the computed plan follows from the reported solver timings.
NVIDIA’s technology and o9’s contribution
NVIDIA released cuOpt under Apache 2.0 and documents solver substitution in existing modeling tools with minimal changes, plus a command-line interface for benchmarking standard model files. (40) The solver is available to other vendors on the same terms. Adopting it supplies no exclusive algorithmic advantage to o9.
o9’s account describes integration, benchmarking, and parameter tuning. It identifies no o9-authored solver change or improvement over unmodified cuOpt. (12) The announcement gives the platform a halo from NVIDIA’s solver and hardware, while leaving o9’s own numerical contribution unspecified. Distinctive supply-chain engineering would show an improved formulation, algorithm, or complete decision process, with measured gains after computation and operating costs. The published solver timing establishes none of those results.
Agents and the productivity of planning
o9’s 2024 composite agents were trained on planning experts’ task sequences and used for forecasting analyses and post-game explanations. Its 2026 neuro-symbolic account describes an LLM interpreting a question, a numerical and rules-based middle layer conducting analyses, and an LLM returning a brief. The advertised 10–80–10 division has no defined unit of work or measured allocation of runtime, cost, or error. (20, 9)
The principal operating question is how much work disappears. An agent can generate an explanation faster while leaving a planner responsible for the same decision. Repeatedly diagnosing exceptions and changing parameters is a weak destination for automation when a better calculation could handle subsequent cases without intervention.
o9 reports some reductions in customer work. ZAMP’s restaurant managers spent 30% less time placing orders. Hormel reported 52% fewer people manually overriding deployment recommendations and 35% fewer production overrides after introducing functional champions. (13, 32) These figures concern particular tasks and behaviors. They do not give total staffing, support effort, or labor per product and location at comparable decision quality.
The coffee-retailer case starts with approximately six hours a day spent on ordering, inventory, and forecasting, then describes automation with minimal manual input. It lists hours saved as an affected KPI without reporting the remaining workload. (31) The cost comparison needs customer, vendor, and implementation-partner labor, including maintenance, testing, and recovery. It should also show how that total grows with the business. Faster operation than a former manual process is an inadequate benchmark for the productivity now available from executable decision software.
Technology history: recurring breakthroughs, incomplete follow-through
For a decade, o9 has presented successive technologies as breakthroughs in enterprise decision-making. Its technical history gives substance to the persistent theme: a shared business model supporting faster coordination.
Patent US12051026B2, granted in July 2024 and claiming priority from September 2014, describes a dependency engine that identifies calculations affected by a data change and recomputes them in the required order. It connects hierarchical and nonhierarchical measures across planning models and supports saved scenarios. Goal-based scenarios work backward from desired outcomes, with maximization/minimization guidance and priorities. (44)
This design addresses a concrete engineering problem: keeping related calculations consistent without rerunning everything after each change. For example, a revised input cost can propagate into product costs and projected margins wherever the model links them.
The 2026 neuro-symbolic account adds LLMs, knowledge extraction, and causal analysis around the EKG. (9) The predictive value of newly inferred relationships depends on their validation. Dependency propagation executes the relationships supplied to it; it cannot establish that they predict the effect of an intervention. A price change, for example, can update revenue consistently while relying on a wrong demand response. Without validation of that response, faster scenario generation can accelerate a bad pricing decision.
| Period and technology | Dated evidence | Consequence for the current claim |
|---|---|---|
| Cloud decision management, 2016 | The August announcement described the mPower platform for sales, supply chain, product, and P&L processes. (16) | Cross-functional planning and financial alignment were already the proposition; their presence is not a new AI capability. |
| Augmented intelligence, 2017 | The February launch promoted AI and delivery of value in 30–60 days for an initial core process. (17) | The release provides no cost baseline against which to measure later productivity promises. |
| Self-driving supply chain, 2019 | The May release advertised digital assistants and automated recommendations to improve profits. (51) | The autonomy claim came without measured unattended decision coverage or remaining human workload. |
| Machine learning and digital twins, 2021–2022 | October 2021 brought Google’s Vertex AI Forecast integration; October 2022 added predictive Supply Sensing. (19, 8) | External algorithms and longer-range alerts were announced, but their incremental economic outcomes remain unquantified in these accounts. |
| Generative AI beta programs, 2023 | The August announcement described early-stage R&D and customer beta programs. (52) | New LLM capabilities were entering customer trials; their operating benefits remained prospective. |
| Generative AI and composite agents, 2024 | The July announcement organized agents around sequences followed by planning experts. (20) | Automating an expert’s task sequence leaves its decision logic and recurring workload to be assessed. |
| Customer adoption of ML, 2025 | Mankind Pharma reported operational gains while its October case still listed ML forecasting and MEIO as future steps. (22, 45) | The deployment record supports improvements from the implemented planning system; it cannot attribute those gains to methods still on the roadmap. |
| APEX and neuro-symbolic AI, 2026 | The March announcement combined LLMs with the existing EKG. The technical account calls the symbolic core an investment spanning fifteen years. (21, 9) | The new interface and orchestration require their own measured contribution beyond the pre-existing engine. |
| GPU optimization, July 2026 | An LP benchmark used NVIDIA’s publicly available cuOpt solver and B200 hardware. (11, 40) | Integration earns no automatic credit for upstream innovation; o9-specific numerical improvements and net planning gains remain unestablished. |
The May 2019 release connected the EKG and AI/ML to a “self-driving” supply chain and profit-maximizing recommendations. Its supporting features included language processing, tagged emails, sensor connections, Hadoop storage, and customer R/Python algorithms. It reported no measured autonomy coverage, fallback workload, or economic results. (51) A search can surface a shortage while leaving its economic resolution and execution to a planner. The leap from these features to a self-driving supply chain is an overselling red flag.
In August 2023, o9 explicitly described generative AI in management decision-making as early-stage work and announced customer beta programs. (52) Its March 2026 APEX release reported that multiple AI pilots had entered production during 2025. (21) The releases leave the scope and delivery of the 2019 autonomy promise unexplained: which decisions ran unattended, where people remained necessary, and what economic gains survived the cost of operating the system. New LLM capabilities cannot retrospectively substantiate that earlier promise. Repeated breakthrough claims without this accounting weaken the credibility of the current autonomy proposition.
Software bill of materials and operating cost
o9’s planning environment combines proprietary in-memory storage, distributed data processing, customer configuration, and external numerical tools. Its architecture articles, training material, and engineering recruitment describe several distinct layers.
| Layer | Documented components and role | Evidence |
|---|---|---|
| Planning model | Proprietary in-memory GraphCube, exchanging data with the customer’s data lake; patent disclosure describes dependency-driven recalculation and linked scenarios | March 2024 storage explanation and graph-model patent. (23, 44) |
| Distributed data processing | Delta Lake and Apache Spark; Integration 3.0 uses datastores, datanodes, and transformation pipelines | March 2024 architecture article and current integration workshop. (24, 26) |
| Implementation data engineering | SQL Server, MySQL, Delta Lake, Spark, T-SQL, and PySpark in integration assignments | o9’s Associate Architect advertisement, requisition JR102899. (25) |
| Customer models and extensions | IBPL rules and queries, model/report/layout designers, and customer Python algorithms | Technical workshop and coffee-retailer case. (28, 31) |
| Third-party application execution, patent design | Managed container registries, orchestration APIs, and shared storage isolated by tenant, application, and execution | July 2026 container-execution patent. (48) |
| Numerical optimization | Heuristics, LP/MIP solvers, external engines, and the demonstrated cuOpt/B200 combination | Supply-planning page and July 2026 benchmark. (2, 11) |
| Snowflake connection | A customer-data integration path with planning inputs and outputs exchanged between systems | May 2026 Connected Application announcement. (30) |
The storage article explicitly describes bringing relevant data into GraphCube while retaining the customer’s lake as the authoritative source. (23) That architecture incurs synchronization, memory, and recovery costs. Spark transformations and Delta Lake add another execution and storage layer. The job advertisement assigns engineers responsibility for batch pipelines, validation, deployment defects, and ongoing integration support. (25)
A shared logical model does not make these physical costs disappear. The platform must move and transform data, maintain compatible definitions, and recover when a step fails. The public architecture does not quantify these costs for a representative planning workload. The scalability article reports a thirtyfold increase in data intersections at an unnamed retailer without the accompanying hardware, processing, or operating-cost figures. (24)
The platform’s claim of unlimited scaling is especially poorly supported by this record. Its own training covers performance tuning and memory management to prevent tenant crashes. (1, 29) These are practical operating limits that buyers must budget for. The useful measurement is the cost of producing and maintaining decisions at the required scale, rather than the amount of data the platform can accommodate.
Changing what the system optimizes
o9’s technical workshop teaches model construction, IBPL queries, data rules, and dashboards. Its EKG workshop teaches metadata-driven integration using a low-code interface over PySpark and Spark SQL. (28, 27) These activities create executable dependencies. Someone must understand and test them when products, constraints, data, or business rules change.
o9’s demand-planning article criticizes older systems for making users depend on IT vendors or consultants to change models. (18) Its Config 2.0 provides Git, collaborative workflows, conflict resolution, and hotfixes; the learning paths include testing strategy, release responsibilities, recovery, and performance tuning. (29) These controls help developers maintain customer logic. They also expose the continuing specialist workload concealed by a simple “configurable platform” description.
Hormel’s deployment account describes functional champions participating in design, testing, training, management communication, and support after go-live. (32) These responsibilities belong in total cost of ownership alongside subscription fees, infrastructure, vendor services, and routine planning. Reduced overrides may save labor, but the effort needed to maintain that reduction must be counted too.
The most consequential maintenance changes the problem being solved. A recurring bad allocation may reveal that the objective omits a cost, that an ERP field means something different from what the model assumes, or that a useful action is missing from the calculation. These discoveries require revisions to the calculation and its interpretation of the business. Holimization makes that work explicit: diagnose the failure, revise the formulation, replay or shadow-test the decisions, and deploy the correction under controlled conditions. (50)
o9’s supplier demonstration proposes revised lead-time assumptions, alternative suppliers, and changes to planning rules after a planner identifies seasonal delays. (10) Consider a further diagnostic step: if a recurring shortage stems from how the ERP records receipt dates, raising a lead-time parameter can conceal the data-interpretation error. If several products depend on the same delayed shipment, adjusting their buffers individually can leave their shared exposure unmodeled. The correction must reach the relevant data semantics and dependencies, then be evaluated against the operating consequences that exposed the defect.
o9’s authoring and release tools support model changes. The reviewed demonstration does not follow a change to the objective or decision structure through testing, deployment, and subsequent economic results. Nor does it quantify the engineering effort involved. That effort belongs in ownership cost: data remapping, reformulation, regression testing, deployment delays, and any manual work retained because the revised model is too expensive to run. Fast execution of the original formulation says little about the cost of making it economically adequate.
Accountability for economic results
Mankind Pharma’s FY2024–25 annual report describes a specific operational change: moving from country-level forecasts to planning at carrying-and-forwarding-agent locations across more than 1,200 SKUs. It attributes a fall in loss-of-sale probability from 3–4% to below 0.5%, alongside lower inventory days, to this shift using o9. The same report describes concurrent warehouse, procurement, and logistics programs. (45) Finer geographical planning can expose shortages that a country total conceals, while connecting demand, supply, and logistics can make replenishment respond to those shortages sooner.
o9’s October 2025 account separately reports 20% lower inventory and 80% fewer service losses, more than 400 platform users, and a year and a half of implementation work. It presents machine-learning forecasting and multi-echelon inventory optimization as subsequent steps. (22) These results support the value of the planning changes already deployed. They cannot establish the contribution of ML and MEIO still described as future work. The two sources do not provide a common definition of service loss.
The relevant comparison is the return on this implemented operating model. Finer planning, shared data, process changes, and concurrent logistics improvements offer several routes to better service. Identifying their contributions requires the timing and scope of each change, with implementation and recurring costs included. Four hundred users indicate adoption; their number does not measure hours saved or the effort required to sustain the gains. Hormel’s functional champions likewise perform continuing design, testing, training, and support work. (32) Those obligations must be costed before attributing net returns to the software.
o9’s APEX announcement promises repeated improvements in growth, margins, and cash flow, then supports its execution narrative with deployment counts and adoption. (21) A go-live measures delivery of software. The commercial test requires returns after the costs of maintaining and operating it, against a defined baseline and period.
The post-game framework proposes tracing decisions and explaining deviations. (9) That could support accountability if it distinguishes a poor recommendation from a customer override, an execution failure, and an outcome that was unfavorable but plausible under the original uncertainty. The public account does not explain how those diagnoses translate into vendor responsibility or remedies for a project that misses its economic case. Without that boundary, demands for better data, processes, and adoption can remain open-ended while the product’s promised returns remain untested.
Practitioner Python and production security
The coffee-retailer case describes a customer’s data science team running its own Python algorithms on o9 for store-level forecasting and replenishment. (31) This creates a security requirement alongside the computational one. Practitioner-written code operating on production data must be treated as potentially faulty or compromised, including its imported packages and any AI-generated additions. A legitimate user’s access rights do not make every program they run trustworthy.
o9 describes several relevant controls. Its security page lists identity features and ISO/SOC frameworks. Its April 2026 Responsible AI article goes further: agents have explicit identities, scoped tool permissions checked before execution, audit trails, and stop mechanisms. (34, 47) A July 2026 patent describes third-party container images passing vulnerability scans before admission to internal registries, authorized deployment, resource configurations, and storage-path isolation between tenants, applications, and executions. (48) These disclosures address agent governance and a container-deployment design; they do not identify the enforced runtime policy for the customer Python execution described in the case study.
The distinction matters after code starts running. A compromised package can attempt to send the data it legitimately reads to an external destination. Read-only database access does not prevent that disclosure. A faulty script can exhaust resources or produce corrupted planning outputs without exploiting a known vulnerability. Image scanning cannot establish that a program’s behavior is safe for the data and authority it receives. The execution environment must enforce restrictions that the program cannot remove.
The published material leaves those restrictions insufficiently specified: whether arbitrary code’s outbound connections are denied by default, which credentials it can access, how its writes are constrained, and who can approve changes to those permissions. The patent describes configurable security contexts and networking, but does not give the effective policy for practitioner workloads. (48) Container packaging alone does not resolve this. Kubernetes’ own guidance recommends stronger sandboxing for untrusted code because ordinary containers share the host kernel. (49)
Customer Python is therefore a material security red flag until its containment in production is demonstrated. The required boundary covers data access, network traffic, secrets, resource consumption, and promotion of code and dependencies into production. Leaving practitioners to establish that boundary would transfer security engineering to people whose job is supply-chain analysis.
Technical access and portability
The Guide portal advertises UI APIs for accessing GraphCube data and configuration documentation for tenants. Following its API and wiki links leads to authorization pages. (33) Training outlines expose the subjects taught, but they do not provide a publicly reproducible implementation of the suite’s numerical decisions.
Customer Python algorithms and Git-managed configuration give customers control over parts of their solution. The public material does not explain how a complete decision model, including proprietary rules and solver orchestration, could be exported and executed independently of o9. (29, 31) This limits the portability of the engineering investment.
Supply chain score
Supply chain depth: 3.8/10
| Sub-score | /10 | Basis |
|---|---|---|
| Economic framing | 5 | Financial scenarios, inventory costs, and profitability-based priorities are explicit; incremental joint valuation remains unexplained. |
| Decision end-state | 5 | Purchase and transfer orders are produced; broader workflows retain human arbitration. |
| Conceptual sharpness on supply chain | 4 | Cross-functional relationships are modeled, but shared data is repeatedly conflated with optimized decisions. |
| Freedom from obsolete doctrinal centerpieces | 3 | Consensus forecasts, service targets, and ABC classes remain central. |
| Robustness against KPI theater | 2 | Aggregate accuracy and task-level automation figures support broader claims without matching measurements. |
Arithmetic average: (5 + 5 + 4 + 3 + 2) / 5 = 3.8.
Economic framing — 5/10. The allocation analysis identifies profitability-based priorities alongside inventory costs and financial scenarios. The published process does not establish how priorities compare the expected contribution of the next unit or how the calculations coordinate procurement, production, and commercial choices.
Decision end-state — 5/10. The retail application explicitly generates purchase and stock-transfer orders. The broader enterprise workflow still depends on people comparing scenarios and committing consequential choices. (3, 41)
Conceptual sharpness on supply chain — 4/10. o9 addresses relationships across functions and horizons. Its central graph proposition does not specify how scarce resources are allocated when feasible plans conflict economically.
Freedom from obsolete doctrinal centerpieces — 3/10. A reconciled forecast and segmented service targets organize the documented process. The forecastability guidance adds aggregation, tailored rules, and collaboration for difficult items, leaving their allocation economics and recurring workload unresolved. (5, 6)
Robustness against KPI theater — 2/10. The accuracy analysis finds weekly aggregate figures attached to detailed production benefits and a ZAMP headline substantially above the separately reported store figure. Missing definitions and economic comparisons prevent those percentages from substantiating the promised decision quality.
Decision and optimization substance: 4.4/10
| Sub-score | /10 | Basis |
|---|---|---|
| Probabilistic modeling depth | 4 | Stochastic inventory and disruption probabilities are claimed; their joint representation and validation are not exposed. |
| Distinctive optimization or ML substance | 4 | External solvers and customer algorithms are documented; LP timings do not validate the economic model. |
| Real-world constraint handling | 6 | Capacity, supplier tiers, perishability, postponement, and network rebalancing are described. |
| Decision automation and labor productivity | 4 | Task savings and fewer overrides are reported; total labor and its scaling remain unknown. |
| Resilience under real operational complexity | 4 | Model-editing tools exist; correcting faulty formulations while preserving economic interactions remains insufficiently demonstrated. |
Arithmetic average: (4 + 4 + 6 + 4 + 4) / 5 = 4.4.
Probabilistic modeling depth — 4/10. MEIO claims demand and supply variability, but the uncertainty analysis finds no disclosed joint projection of demand and future receipt dates feeding order selection. The low-forecastability guidance describes rules and aggregation without tracing the remaining uncertainty into allocations. The probabilities, their calibration, and their effect on decisions remain unspecified.
Distinctive optimization or ML substance — 4/10. o9 integrates numerical solvers and supports customer algorithms. The cuOpt disclosure establishes no o9-specific numerical improvement, and its LP benchmark leaves the economic formulation and approximations unvalidated. Model size and close solver objectives provide no evidence of superior decisions under uncertainty.
Real-world constraint handling — 6/10. Inventory rebalancing, shelf life, supplier capacity, and postponement address concrete operating constraints. The joint treatment of these constraints with pricing and competing uses of capital remains unclear. (2, 4)
Decision automation and labor productivity — 4/10. The customer reports identify reduced ordering effort and fewer overrides. They do not measure the full operating team, support costs, or additional work eliminated by agents beyond earlier automation.
Resilience under real operational complexity — 4/10. o9 supports model editing and reusable rules, but the improvement workflow does not demonstrate a faulty objective, data interpretation, or decision structure being revised and validated through subsequent operating results. LP performance cannot establish that capability. Solver restrictions also put newly identified economic interactions at risk of being simplified away when the formulation changes.
Product and architecture integrity: 4.6/10
| Sub-score | /10 | Basis |
|---|---|---|
| Architectural coherence | 5 | A common model connects applications; multiple execution layers and their economic semantics remain incompletely described. |
| System-boundary clarity | 6 | Data lakes, planning storage, external solvers, and downstream outputs have identifiable roles. |
| Security seriousness | 4 | Agent permissions and a container-security design are documented; enforced containment of customer Python remains unexplained. |
| Software parsimony and ownership cost | 3 | Infrastructure, configuration, and revisions to the decision model require sustained engineering; total costs are unquantified. |
| Compatibility with programmatic and agent-assisted operations | 5 | Python extensions, IBPL, and Git-managed configuration support development; full model reproducibility remains unclear. |
Arithmetic average: (5 + 6 + 4 + 3 + 5) / 5 = 4.6.
Architectural coherence — 5/10. The graph-model disclosure explains dependency-driven recomputation and linked scenarios. The software inventory reveals distinct storage, transformation, and computation layers; their integration still requires consistent definitions, maintained rules, and coordinated economic calculations.
System-boundary clarity — 6/10. The storage explanation identifies the customer’s authoritative data source and the planning copy. The Snowflake announcement describes inputs and returned outputs. These give concrete boundaries for integration responsibilities. (23, 30)
Security seriousness — 4/10. The practitioner-code assessment finds scoped agent permissions and a patent describing image scanning, authorized deployment, and isolated storage paths. The public record does not connect these controls to an enforced policy for customer Python’s network access, credentials, writes, and permission changes. Extensibility with production-data access needs that containment to limit damage from mistakes and compromised dependencies.
Software parsimony and ownership cost — 3/10. The maintenance workload includes model development, integration testing, tuning, and support. Revising objectives, data interpretations, and available decisions also incurs engineering and deployment costs. The customer accounts do not quantify that effort or relate it to durable improvements in returns and labor productivity.
Compatibility with programmatic and agent-assisted operations — 5/10. Customer Python code, rule queries, and version-controlled configuration can support durable improvements. The public documentation does not show reproducible execution and testing of the complete economic model across these layers. (28, 29, 31)
Technical transparency: 3.8/10
| Sub-score | /10 | Basis |
|---|---|---|
| Public technical documentation | 5 | A graph-model patent, architecture articles, training outlines, and a solver benchmark expose mechanisms; current implementation guides require authorization. |
| Inspectability without vendor mediation | 4 | Customers can develop models and extensions; underlying formulations remain largely undisclosed publicly. |
| Portability and lock-in visibility | 2 | Export and independent execution of a complete decision model are unexplained. |
| Implementation-method transparency | 5 | Training, engineering duties, and customer accounts identify substantial implementation and maintenance work. |
| Evidence density behind technical claims | 3 | Solver timing has specifics; causal, predictive, and autonomous claims have much weaker validation. |
Arithmetic average: (5 + 4 + 2 + 5 + 3) / 5 = 3.8.
Public technical documentation — 5/10. The patent analysis supplies concrete mechanisms for dependency evaluation and scenario generation, alongside the public architecture and LP material. The access check still finds restricted current implementation guides; the historical design does not provide a reproducible description of today’s complete decision engine.
Inspectability without vendor mediation — 4/10. Customer algorithms and configurable models are inspectable within their development scope. The reviewed sources do not expose the full objective, uncertainty treatment, and execution path behind suite-wide optimization.
Portability and lock-in visibility — 2/10. Git can preserve configuration history without making proprietary runtime behavior portable. The public documentation leaves the cost and feasibility of moving the complete customer solution to another platform unknown.
Implementation-method transparency — 5/10. Workshops, the engineering advertisement, and customer deployment accounts identify modeling, testing, integration, and continuing organizational responsibilities. Their staffing requirements and ongoing costs are not quantified. (25, 28, 32)
Evidence density behind technical claims — 3/10. The numerical benchmark has concrete parameters. Disruption prediction, causal attribution, and the broader agent productivity proposition lack comparable validation of outcomes.
Vendor seriousness: 3.8/10
| Sub-score | /10 | Basis |
|---|---|---|
| Technical seriousness of public communication | 4 | Specific solver disclosures coexist with unlimited-scale language and unsupported extrapolations. |
| Technology roadmap integrity | 3 | The 2019 autonomy promise remains unevaluated as later releases introduce LLM betas and report AI pilots entering production. |
| Conceptual sharpness | 4 | The enterprise model is a consistent theme, but planner coordination remains central to the proposed operating model. |
| Economic accountability | 3 | Customer results and responsibilities are described; net-return criteria and remedies for failure remain undefined publicly. |
| Defensibility in an agentic-software world | 5 | Domain models and integrations require work to reproduce; interfaces and externally supplied solvers offer less differentiation. |
Arithmetic average: (4 + 3 + 4 + 3 + 5) / 5 = 3.8.
Technical seriousness of public communication — 4/10. The LP account identifies limitations and earlier numerical problems. The wider communication overextends this result into overnight planning and promotes unlimited scale without an operating-cost benchmark.
Technology roadmap integrity — 3/10. The dated history documents an expansive autonomy claim in 2019, followed by generative AI beta programs in 2023 and a later report of AI pilots entering production in 2025. The launches do not account for delivery of the earlier promise. Mankind’s deployment also separates reported gains from ML and MEIO still planned for later. This weak follow-through undermines the credibility of successive breakthrough claims.
Conceptual sharpness — 4/10. A common enterprise model is a coherent engineering direction. Consensus forecasts, expert task sequences, and parameter corrections retain a large role, leaving the progression toward economically autonomous decisions incomplete.
Economic accountability — 3/10. The Mankind analysis combines customer-reported service gains with documented implementation effort and subsequent capability plans. The results do not isolate the software’s contribution or establish returns after ongoing costs. Public commitments still leave organizational obligations and remedies for a missed business case undefined.
Defensibility in an agentic-software world — 5/10. Domain models, customer integrations, and the planning runtime constitute accumulated engineering. External solvers and conversational interfaces are easier to obtain elsewhere. The durable advantage must come from better decisions and lower total operating effort, which remain insufficiently measured.
Overall score: 4.1/10
(3.8 + 4.4 + 4.6 + 3.8 + 3.8) / 5 = 4.08, rounded to 4.1/10.
o9 offers an extensive environment for constructing and coordinating enterprise plans. Its public evidence is much weaker on the joint economic calculation, validated uncertainty, and total labor required to operate it. The central investment risk is paying for a sophisticated planning organization without obtaining a correspondingly productive system for making decisions.
Source dossier
Sources accessed November 3, 2026. External citations link to verified timestamped archive copies.
o9 Solutions: Digital Brain platform. Undated. Functional scope, shared enterprise model, and scaling claims.
o9 Solutions: Supply chain planning. Undated. Solver families, capacity modeling, operational outputs, and automation.
o9 Solutions: Digital IBP. Undated. Financial scenarios, plan synchronization, and executive decision workflows.
[4] Multi-echelon inventory optimization
o9 Solutions: Multi-echelon inventory optimization. Undated. Inventory costs, postponement, network rebalancing, shelf life, and stochastic-modeling claims.
[5] Collaborative demand planning
o9 Solutions: Collaborative demand planning. Undated. Consensus forecasting, automatic reconciliation, and common demand baselines.
[6] Replenishment planning doctrine
o9 Solutions: Replenishment planning doctrine. Undated. Service-level targets, safety stocks, and ABC classification.
o9 Solutions: Demand sensing. Undated. External signals, forecast frequency, hierarchy, and granular outputs.
o9 Solutions: Supply sensing launch. 2022-10-03. Predictive disruption alerts, event probabilities, and proposed mitigation.
o9 Solutions: Neuro-symbolic AI. 2026-02-11. Agent architecture, the 10–80–10 claim, decision context, and causal analysis.
[10] Digitized knowledge demonstration
o9 Solutions: Digitized knowledge demonstration. 2026-07-10. Planner-supplied supplier knowledge, lead-time validation, and rule changes.
[11] GPU optimization announcement
o9 Solutions: GPU optimization announcement. 2026-07-23. Reported LP speedup and the extrapolation to overnight planning.
[12] GPU benchmark methods and results
o9 Solutions: GPU benchmark methods and results. 2026-07-24 (updated 2026-07-29). Workload dimensions, hardware, solver timings, numerical quality, and development scope.
[13] Retail customer reports and demonstrations
o9 Solutions: Retail customer reports and demonstrations. 2025-09-15 (updated 2026-03-12). ZAMP’s accuracy and ordering-effort figures; customer results and separate demonstrations.
[14] Production planning accuracy claim
o9 Solutions: Production planning accuracy claim. 2026-10-19. Weekly aggregate accuracy above 95% and the claimed production benefits.
[15] M5 data and point-forecast submissions
M5 competition organizers: M5 data and point-forecast submissions. 2020–2022. The diagnostic recalculation uses the published top 50 point submissions on evaluation days d_1942–d_1969, including all 30,490 product/store series and zero-sales observations. WAPE divides total absolute error by actual unit volume. Aggregation sums the original forecasts without refitting; the official M5 ranking used WRMSSE.
[16] Cloud decision management in 2016
o9 Solutions: Cloud decision management in 2016. 2016-08-09. The mPower cloud platform and its cross-functional planning proposition.
[17] Augmented Intelligence announcement
o9 Solutions: Augmented Intelligence announcement. 2017-02-24. Augmented Intelligence positioning and an initial core-process delivery target.
[18] Future of demand planning
o9 Solutions: Future of demand planning. 2017-05-18. Sales adoption, collaborative demand management, and model flexibility.
[19] Vertex AI Forecast integration
o9 Solutions: Vertex AI Forecast integration. 2021-10-12. Integration of Google’s forecasting algorithms and external demand signals.
o9 Solutions: Composite agents. 2024-07-01. Atomic and composite agents following expert planning task sequences.
o9 Solutions: APEX announcement. 2026-03-26. Operating-model and economic promises, deployment counts, and AI rollout.
[22] Mankind Pharma planning deployment
o9 Solutions: Mankind Pharma planning deployment. 2025-10-15. Implementation effort, users, reported results, and subsequent ML and MEIO plans.
[23] How to Use Your Data Lake for Storage
o9 Solutions: How to Use Your Data Lake for Storage. 2024-03-15. GraphCube storage, customer data lakes, and data exchange.
[24] Navigating Large Volume Challenges
o9 Solutions: Navigating Large Volume Challenges. 2024-03-15. Delta Lake, Spark, common data models, and anonymous scale examples.
[25] Associate Architect, JR102899
o9 Solutions, employer listing on Built In: Associate Architect, JR102899. Undated. Employer-authored advertisement on Built In, requisition JR102899. Integration technology and duties spanning pipelines, testing, deployment, and maintenance.
o9 Solutions: Integration 3.0 workshop. Undated. Integration 3.0 pipelines, datastores, datanodes, and Delta Lake.
o9 Solutions: EKG integration workshop. Undated. Metadata-driven ETL and the EKG Configurator over PySpark and Spark SQL.
[28] Platform technical workshop
o9 Solutions: Platform technical workshop. Undated. IBPL, model construction, rules, reports, and layout configuration.
[29] Configuration and performance learning paths
o9 Solutions: Configuration and performance learning paths. Undated. Config 2.0 with Git, testing and release responsibilities, recovery, and performance tuning.
[30] Snowflake connected application
o9 Solutions: Snowflake connected application. 2026-05-05. Connected Application integration, data inputs, and planning outputs.
[31] Coffee retailer deployment and customer algorithms
o9 Solutions: Coffee retailer deployment and customer algorithms. Undated. Customer Python algorithms, planning automation, and the initial store workload.
[32] WHOOP and Hormel deployment lessons
o9 Solutions: WHOOP and Hormel deployment lessons. 2026-09-28 (updated 2026-10-08). Hormel’s functional champions and reported reductions in overrides; WHOOP’s planning ambitions.
o9 Solutions: Documentation portal. Undated. Portal descriptions of UI APIs and tenant configuration guides; access checked through the linked authorization paths.
o9 Solutions: Security. Undated. Access controls, encryption, monitoring, assurance frameworks, and vulnerability disclosure.
[35] Joannes Vermorel: Introduction to Supply Chain, full text
Joannes Vermorel: Introduction to Supply Chain, full text. September 2025. Especially economics, decisions, and the engineering of productive software.
[36] Joannes Vermorel: Supply Chain Needs Programmable Systems, Not Configurable Products
Joannes Vermorel: Supply Chain Needs Programmable Systems, Not Configurable Products. January 5, 2026. Lokad’s approach to business-specific executable decision logic and its maintenance.
[37] Mixed integer optimization
MOSEK Modeling Cookbook: Mixed integer optimization. Undated. Fixed setup costs, minimum-quantity choices, nonconvex formulations, and computational difficulty.
[38] Solving the Extensive Form
mpi-sppy: Solving the Extensive Form. Undated. Scenario probabilities and linked decisions in stochastic models passed to general-purpose solvers.
[39] How do I distinguish a weak MIP formulation?
Gurobi: How do I distinguish a weak MIP formulation?. Updated April 16, 2026. Relaxation strength, bounds, search effort, and observed runtime behavior.
[40] Accelerate Decision Optimization Using Open Source NVIDIA cuOpt
NVIDIA: Accelerate Decision Optimization Using Open Source NVIDIA cuOpt. June 11, 2025. Open-source licensing, solver substitution, and a standard interface for LP/MIP benchmarks.
[41] Allocation and replenishment process
o9 Solutions: Allocation and replenishment. Undated. Stock policies, allocation priorities, executable orders, constrained planning, and planning horizons.
[42] Low-forecastability planning
o9 Solutions: Managing Low Forecastability. October 10, 2025. Published training description: CoV threshold, aggregation, tailored rules, and collaboration.
o9 Solutions: Forecast Value Add Explained. May 26, 2025. Published training description: evaluating changes to forecast quality.
[44] Computational unified graph hierarchy model
o9 Solutions: US12051026B2. Granted July 30, 2024; priority September 22, 2014. Dependency evaluation, incremental recomputation, linked planning models, and goal-based scenarios.
[45] Mankind Pharma annual report
Mankind Pharma: Annual Report 2024–25. Printed pages 48–49. Distribution-point planning with o9, reported service and inventory gains, and concurrent operational programs.
[46] Bounds and Approximations for Multistage Stochastic Programs
Francesca Maggioni and Georg Ch. Pflug: Bounds and Approximations for Multistage Stochastic Programs. 2015 preprint; published in SIAM Journal on Optimization, 2016. Scenario-tree growth, approximations, and an inventory application.
[47] Responsible AI and agent permissions
o9 Solutions: o9’s Approach to Responsible AI. April 30, 2026; updated May 6, 2026. Agent identities, tool permissions, policy checks, audit trails, and stop mechanisms.
[48] Containerized application deployment and execution framework
o9 Solutions: US12694127B1. Granted July 28, 2026. Image scanning and promotion, authorized deployment, resource configuration, and storage isolation for third-party applications.
[49] Container isolation and untrusted code
Kubernetes: Multi-tenancy, sandboxing containers. Shared-kernel isolation limits and stronger sandboxing for untrusted code.
[50] Joannes Vermorel: Holimization: Why Optimization Is Not Enough
Joannes Vermorel: Holimization: Why Optimization Is Not Enough. December 12, 2025. Revising objectives, constraints, data semantics, and available decisions through operational feedback, instrumentation, and controlled experiments.
[51] Self-driving supply chain announcement
o9 Solutions: Self-driving supply chain announcement. 2019-05-08. Digital assistants, autonomy claims, and the supporting technology list. Archived June 1, 2019.
[52] Generative AI beta announcement
o9 Solutions: Generative AI beta announcement. 2023-08-17. Early-stage generative AI research, proposed uses, and customer beta programs.