Supply chain planning · demand first
Every forecast names what drove it. Every setting is a switch you own. Every number traces back to its inputs, on a platform that speaks your business’s vocabulary, not ours.
Complexity in Clarity out
a working demo on your data · no commitment
The data model, the algorithms, the connectors and the storage engine are all pluggable, so a new planning problem is configuration, not a rebuild.
Demand ships today on a core that is already built and acceptance-proven, and one configuration value switches its storage engine, with identical totals at both scales. The platform grades its own work, too: accuracy, bias and forecast value added are measured every cycle, including when a human change made the plan worse.
Measured in our lab, on our own test data, never a customer benchmark.What each number measures, and its caveats
The film
Every planning team knows these three. Here is what PlanSieve does about each.
Why PlanSieve
Each one is a mechanism, not an adjective, and each one is on screen.
Right-click any forecast and the answer is about that number: its base, each driver’s push, the model that won and by how much, and what moved since the last cycle.
Where the arithmetic is exact we draw the waterfall. Where it is a proportional share we say so in words instead of drawing one that would lie.
Nothing is a black box
Accuracy, bias and forecast value added are measured every cycle, at any level you look, by the one definition every screen shares.
When a hand-made change made the forecast worse, that is on the page as well, as a number, not a scolding. Authority earned with evidence is the only kind a planning system keeps.
How the platform grades its own work
Everything a planning module is, its measures, rules, pages, policies and model bindings, is metadata, so a module arrives as a package you switch on, not a release you wait for.
Demand is the first package on that core. Inventory, supply and S&OP are carried by the same data model, by design. None of them is listed as available until it is.
Open by design
The fact store is an adapter, not a dependency: embedded columnar on a laptop, a scale-out column store in production, and a cloud-warehouse adapter designed behind the same contract, with Apache Arrow as the interchange in between.
The model, the math and the screens do not change when you move. The configuration does. We measured a billion-row fact table on the scale-out setup; the numbers, with their caveats, are on the measured-performance page.
The engine, and what it was measured doing
The rest of the eighteen
No badge without a page. Every line here is substantiated in full on the platform page.
A planner’s day
Not a feature list. The morning worklist, the question about a driver, and the model that won.
Keep it, correct it, mask it, or name it as an event. Each is a single click with the evidence sitting beside it. The verdict is stored as data, not as a note, so the cleansing engine, the model contest and the next cycle all read it.
Every driver you switch on (weather, price, promotion, events) is backtested against the series it claims to explain. If it does not improve the forecast, it does not get a seat, and the page says so in plain words with the score beside it. A tool that only ever agrees with itself is not evidence. A refusal is.
Simple methods, classical statistics, intermittent-demand methods and machine learning all compete on each series’ own history, scored on the same accuracy definition used everywhere else. The winner is named on the grid, the scoreboard shows every challenger and the margin, and the ranges come from the model that won.
How it works
Three steps, and the second one is the engine.
Model your dimensions, levels and hierarchies in the Designer. They are data, not schema. Load history through the connector plane. Set policies once, at the level you choose.
A contest per series picks the model and names why. Spreading respects your locks and ties the totals. Every step runs inside a measured budget that fails the build if it slips.
Every number explains itself. The platform grades its own accuracy, bias and value added. A verdict is one gesture, and every engine downstream hears it.
Deeper proof
A verdict, keep, correct, mask, declare an event, adjust or approve, is not a note on the side. It lands as data on the history itself, through the same governed edit path every other number uses, with a reason and a date stamp. The cleansing engine, the model contest and the next cycle all read it, so judgement stops being an override the system fights and becomes an input the system uses.
Demand planning is the module available today. Inventory, supply, manufacturing and sales-and-operations planning are carried by the data model by design: the engine has no module-specific code in it, and a module is a versioned package of metadata you activate, diff and upgrade rather than a release you wait for. We do not list them as available until they are.
Every performance claim we make is an assertion inside our own test suite: a pivot page, an edit reaching its downstream measures, a full cascade, each with a millisecond ceiling that fails the build when it is crossed. We have measured the same product on a laptop-class embedded store and on a billion-row fact table on the scale-out setup; the numbers, with what each one measures and its caveats, are on the measured-performance page.
Bring your history, your hierarchies and your vocabulary. We show the platform working on them.
a working demo on your data · no commitment