The platform is done: what that means in plain words

“Done” is a word software companies use loosely, so it is worth saying what we mean by it. PlanSieve is built as a planning engine first and a demand-planning product second: the data model, the math, the interface, the connectors and the storage engine all sit behind contracts, and a planning module is a package of configuration that runs on top of them. For a platform built that way, “done” has a precise meaning. It means the engine has no module-specific code in it, and the proof is that a whole application can be built on it without writing any.

On 29 July the platform core passed the last of its acceptance gates. A gate is a test on the real stack that passes or does not; no phase was written down as closed until it did.

What the final gate proved

The last phase was the acceptance gate for the whole platform. It had four parts.

Conformance, and the storage swap. The platform has eight contracts: the control store, the fact store, the compute plug-in, the connector, the event bus, the cache, the job runner, the feature store. And every adapter behind them has to answer the same conformance matrix. The sharpest test is the storage swap: one configuration value switches the fact store from the embedded columnar engine to the scale-out column store, with zero changes to any caller, and both engines return identical totals at both scales. The embedded engine wins small aggregates; the scale-out engine’s curve is flatter. The claim is not that one is faster. The claim is the right engine per tier, same answers.

The half-second budget, under load. An edit must be visible to the person who made it in under 500 milliseconds, and its downstream effects must follow. On the scale-out setup we held 25 edits a second plus 10 reads a second for 60 seconds, twice, with zero failures; editors saw a median of 10 ms and a 95th percentile of 193 to 212 ms. That is inside that budget, measured in our lab against our own test data, not a customer benchmark, and not a cloud cluster.

The door-walk. Starting from an empty install, a whole planning application was built through the product’s own doors: dimensions, hierarchies, measure groups, rules, pages, policies, with zero module code, and then walked by hand. Everything a person can do on a screen, a program can do through a documented door; the screen is just one client of it.

Security, tenancy and lineage. The gate went looking for holes, and it found real ones: an audit façade, identifier handling across nine identifier types, a scenario read leak, a clone bypass, and fixed each before “done” was said. The access envelope was measured at enterprise shape: 1,000 users, 1,000 roles and 10,000 grants resolve and compile in a median of 143 ms and a 95th percentile of 167 ms cold, flat, with no cliff.

Why performance is part of “done”

Speed here is a budget that fails the build. 54 of the 439 backend test files assert a timing bound: a pivot page, a cell edit reaching its downstream measures, a full cascade, each with a millisecond ceiling. A regression is a red build the same afternoon, not a slide in a quarterly review.

What it changes for a buyer

The demand module ships on that core as 59 packs of metadata: dimensions, grains, measures, rules, pages, policies and model bindings, not as engine code. Finishing the platform first means the second module cannot require touching the core, because the first one already proved the core has nothing module-specific in it.

It sets the honest limit of what we say. Demand planning is the module available today. Inventory, supply, manufacturing and sales-and-operations planning are carried by the data model by design, and we will not list them as available until they are. What we can say is that when they arrive, they arrive the way demand did: as configuration you activate, diff and upgrade, on a platform that was done before any of them.