The questions a careful buyer asks

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 vintage 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. Any verdict takes at most two gestures, on one surface, with the evidence beside the action.

A planner’s day, on one surface

By letting the model say no. Every driver you switch on (weather, price, promotion, events) is backtested against the series it claims to explain, per series. 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. On one demo tenant, real weather was loaded, measured, and named on 0 of 2,310 series: a refusal we count as a result, not a gap. A tool that only ever agrees with itself is not evidence.

The engine chapter

Yes. Every engine behaviour (gap and zero handling, stockout censoring, outlier treatment, launch curves, phase-out fences) is a policy the engine reads: on or off, with typed options and defaults that work. You pin it at a category, a region, a channel or a single item; everything underneath inherits it; one item can differ, on the record with a reason. Turning a setting off does not hide it: the engine measurably skips it, and we test that byte for byte. A policy family the platform has never seen lands as a plain metadata write, no deployment.

Everything is a policy

Right-click any forecast and ask what built it: the base level, each driver’s push up or down, the model that won and the margin it won by, and what changed since the last cycle. The explanation is of the number you clicked, always, declared by the rule that authored it, never inferred. 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. The same permissions that wall the grid wall the explanation.

Nothing is a black box

The platform grades its own work. Accuracy, bias and forecast value added are computed every cycle at whatever level you pivot to, from one metric definition used identically on every screen, in code, and it forbids a ratio of aggregates. Cycles are frozen as immutable snapshots, so accuracy at every lag is measured against the promise that was actually made. When a manual adjustment made the forecast less accurate, the value-added measure shows it, by the same definition applied to every step of the plan.

How the platform grades its own work

No. Every product-location series gets its own contest each cycle: simple methods, classical statistics, intermittent-demand methods and machine learning compete on that 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 (P10 / P50 / P90) come from the model that won. Forecasting happens at more than one level by design.

A contest for every series

Each measure declares how it spreads: by recent sales, by assortment, evenly, proportionally, or by a rule you author. And every roll-up names the hierarchy it rolls along, so two measures in the same group can flow differently. Locked cells stay locked, the totals still tie, and the grid shows you exactly which cells a spread touched.

Your vocabulary is the model

Yes, because there is no item table to bend your business into. Dimensions, levels, hierarchies and granularity are data, not schema; a grain is any combination of dimension and level, with no limit on how many. Adding a channel, a demand stream, a supplier axis or a finer grain is a metadata change: no migration, no downtime. Hierarchies can be alternate, ragged, shared and effective-dated, so a re-categorisation last year does not quietly rewrite last year’s history.

Your vocabulary is the model

Both, on one core. The fact store is an adapter behind one contract: an embedded columnar store on a laptop, a scale-out column store in production, and a cloud-warehouse adapter designed behind the same contract, with a columnar interchange in between. Both storage engines return identical totals at both scales, and one configuration value is the whole switch. The model, the math and the screens do not change when you move; the configuration does. The cloud-warehouse adapter is designed and named in the architecture; two adapters are in the tree today.

The engine

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 an embedded store and on a billion-row fact table on the scale-out setup, in our lab with our own test data. The numbers, with what each one measures and its caveats, are on the measured-performance page, and so are the ones we missed.

Measured, not promised

In the database itself. Every tenant-bearing table carries a row-level policy, the runtime connects as the policy’s subject, and a connection that has not declared its tenant sees zero rows and cannot write. A forgotten call site fails safe. What a person may see narrows every grid, chart, run, export, scenario and explanation panel by one rule: effective data is what the grants allow, intersected with the scope in hand. Isolation tiers are configuration, not code: shared schema, schema per tenant, database per tenant.

Security & trust

Yes, through the same door ours use. Register a model or a solver and it competes exactly as the built-ins do: same inputs, same backtest, same accuracy definition, same lineage record of which version produced which number. It runs sandboxed, resource-limited and permissioned, because bring-your-own-code and governed have to be the same sentence. There is no ungoverned inline script step anywhere in the product.

Your model, our contest, one contract

It is versioned, so a release meets it as a diff. Every metadata entity carries a version and audit columns; changes land as change sets that roll back as a unit when something fails; published cycles are immutable snapshots distinct from working scenarios. A package upgrade arrives as a field-level three-way diff against your own customisations, with conflicts named rather than overwritten.

Nothing changes without a record

It is agent-ready by construction, and we say exactly that. Every capability is served by a documented door. Everything a person can do on a screen, a program can do through the door, and the model describes itself: policy catalogs, parameter schemas and level definitions are readable metadata. The whole planner application renders from that metadata through one route, so nothing is a bespoke screen invisible to a program. We do not ship agents that run your plan; we ship the platform such agents would need.

Built so software can read it

Through governed connectors, in both directions at the platform level. Inbound: files, database extracts, object storage, REST and streams, each through the same walled pipeline with rejects counted rather than swallowed. Outbound: governed publish pipelines walled by the same permissions as every other door. Integration tools you already own are spokes on the API-first surface, never required, never blocked.

How an implementation runs

Not yet, and we will not imply otherwise. What we can describe is the posture: tenant isolation enforced in the database, permissions that narrow every door including the explanation panel and the SQL console, audit and change sets on every edit, versioned configuration, plug-ins sandboxed and resource-limited, and self-hosted observability with no external egress. Vulnerability reports go to the security address on the security & trust page.

Security & trust: the posture in full

Where your deployment puts it. Facts live in the storage adapter you choose: embedded, or a scale-out column store today; a cloud-warehouse adapter is designed behind the same contract. And the control plane is a relational database you can host where your policy requires. Because storage is an adapter and not a dependency, residency is a deployment decision rather than a product constraint, and nothing in the platform phones home: observability is self-hosted with zero external egress.

Security & trust