Request a demoDemo

Modules

One core. Demand today. The rest on the same engine.

A module here is a versioned package of metadata you activate, diff and upgrade, not a release you wait for. Demand planning is what you can use today. Everything else below is next on the same engine, built with the first customer who needs it.

Available today

Demand planning

The platform’s first application: a planner’s day on one surface that shows its work.

Available today

A planner’s day, on one surface

  • The worklist. What needs a look, worst first, with the reason beside each series.
  • The verdict. Keep, correct, mask, declare an event, adjust or approve: one gesture, stored as data every engine reads.
  • The explanation. Right-click any number and ask what built it, and see when a driver was judged and refused.
  • The policy. Every engine behaviour a switch with a dial, set once at the level you choose, inherited below it.
  • The contest. Every series gets its own model contest each cycle; the winner is named on the grid with the margin.
The demand module, end to end
The Demand Workbench’s three panes: the exception worklist on the left, the history-and-forecast grid in the centre, and the actions rail on the right.The Demand Workbench’s three panes: the exception worklist on the left, the history-and-forecast grid in the centre, and the actions rail on the right.
The Demand Workbench’s three panes: the exception worklist on the left, the history-and-forecast grid in the centre, and the actions rail on the right.The Demand Workbench’s three panes: the exception worklist on the left, the history-and-forecast grid in the centre, and the actions rail on the right.
Demand WorkbenchWhat needs a look, the history and forecast behind it, and the moves you can make: one surface.Real screens on a demo world; the brands are fictional.

Next on the engine

What the engine already carries, and how each module arrives

The engine has no module-specific code in it, so a new module is configuration, not a rebuild. Each of these is built with the first customer who needs it, and this page calls a module available only once it is.

  • Next on the engine

    Inventory

    Sites, lanes and the demand variability a safety-stock policy needs; service levels and multi-echelon rules as policies the engine reads, switchable at the level you choose.

    Built with the first customer who needs it, as configuration on this engine, in weeks.

  • Next on the engine

    Supply

    Make, buy and transfer as sourcing relationships in the model; time fences and effective demand as policies; the same governed runs and scope records every job carries.

    Built with the first customer who needs it, as configuration on this engine, in weeks.

  • Next on the engine

    Manufacturing

    Bill of material and routing as relationships in the model, not tables bolted on. A 10,000-edge bill of material explodes in 26 ms on the single-node setup, multi-level, with quantity-per, scrap and effectivity.

    The engine already carries the hard part. The module is built with our first manufacturing customer.

  • Next on the engine

    S&OP

    Consensus at the level the business meets, scenarios that branch without copying the plan, immutable published cycles, and one accuracy definition for every hand: the platform pieces the process needs.

    Built with the first customer who needs it, as configuration on this engine, in weeks.

  • Next on the engine

    The full retail suite

    Merchandise financial planning, assortment, allocation, replenishment, pricing and markdown. Merchandise hierarchies, a retail calendar, and per-measure spreading that respects locks and ties the totals are in the engine by design, and a merchandise-planning face already sits over the demand build.

    Designed into the model. It ships with our first retail customer.

Why the second module costs the platform nothing

The engine came first. The modules are configuration.

Dimensions, grains, measures, rules, pages, policies and model bindings are metadata, so a planning module is a versioned package you activate, diff and upgrade, not a release you wait for.

Industry behaviour enters only as package content: policy rows, formulas, sets, bindings, never as an engine fork. If a package ever needs a behaviour the engine lacks, that becomes a named platform task first. Packages upgrade by a field-level three-way diff, so your customisations survive an upgrade with conflicts named rather than overwritten.

Demand ships today on exactly the same core that will carry inventory, supply and S&OP. If building the second module required touching the core, the platform would not be finished.

Open by design, on the platform page

59

metadata packages make up the demand module: content, not engine code

8

swappable contracts the platform is built on

0

lines of module code to build a whole application from an empty install, through the product’s own doors

See the demand module on your data

Bring your history and your hierarchies. We load them, run the contest, and walk the planner’s day with you on your own numbers.

Request a demo

a working demo on your data · no commitment