Request a demoDemo

How it works

Configuration, not a rebuild

An implementation here is what you bring, modelled in the product’s own designers, loaded through governed connectors, governed by policies you set once at the level you choose, run as governed jobs, and reviewed on screens that explain themselves. It is designed so a new planning problem is configuration, not a rebuild.

The path

Six steps, and the second one is where most of the work goes

Each step is a door in the product, not a document in a project plan. What follows is the shape of the path, stated as the design intent the platform was built to.

  1. What you bring

    Your history: sales, shipments, orders, at whatever grain you keep it. Your hierarchies: product, location, customer, channel, and any axis you actually plan on. Your vocabulary: the level names, the calendar, the units. And the drivers you believe in: price, promotions, events, weather.

    Files, database extracts, object storage, REST or streams: the connector plane takes each through the same governed, walled pipeline, and rejects are counted rather than swallowed.

    21M

    cells of a demo tenant’s history landed through the governed connector pipeline, 0 rejects

    a demo tenant; measured in our lab

  2. Model it in the Designer

    Dimensions, levels, hierarchies and grains are authored on the Designer’s canvas. They are data, not schema, so there is no item table to bend your business into and no migration when an axis is added later. Hierarchies can be alternate, ragged, shared and effective-dated.

    Each measure declares how it aggregates, over which hierarchy, and how it spreads back down: by recent sales, by assortment, evenly, or by a rule you write. And locks are respected when it does. The whole model is versioned as it is built.

    The Designer Studio: a product dimension’s hierarchy path, its attributes and its derived members, built from the interface.The Designer Studio: a product dimension’s hierarchy path, its attributes and its derived members, built from the interface.
    The Designer Studio: a product dimension’s hierarchy path, its attributes and its derived members, built from the interface.The Designer Studio: a product dimension’s hierarchy path, its attributes and its derived members, built from the interface.
    Designer StudioA dimension’s hierarchy path, its attributes and its derived members, built from the interface.Real screens on a demo world; the brands are fictional.
    A measure’s aggregation and spreading rules: aggregation up, aggregation over time, the hierarchy it rolls along and the disaggregation basis.A measure’s aggregation and spreading rules: aggregation up, aggregation over time, the hierarchy it rolls along and the disaggregation basis.
    Designer StudioAggregation up, aggregation over time, the hierarchy and the disaggregation basis, per measure.

  3. Load

    History and master data land through the connector plane in bulk, never a row at a time, into the fact store your tier calls for: embedded columnar on a laptop, a scale-out column store in production, behind one contract; a cloud-warehouse adapter is designed behind the same contract. The model, the screens and the math do not change when the store does.

    Integration runs both ways at the platform level: inbound connectors, and governed outbound 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.

  4. Set policies at the level you choose

    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, shipped with defaults that work. Pin a policy 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.

    A package brings the industry’s defaults; you change only what your business does differently. Turning a setting off doesn’t hide it: the engine measurably skips it.

    The Policy Studio: a policy family’s named setups, each option typed and described, riding a default until it is set.The Policy Studio: a policy family’s named setups, each option typed and described, riding a default until it is set.
    The Policy Studio: a policy family’s named setups, each option typed and described, riding a default until it is set.The Policy Studio: a policy family’s named setups, each option typed and described, riding a default until it is set.
    Policy StudioA family’s named setups, each option typed, described and riding a default until set.

  5. Run

    Cleansing, the model contest, the driver verdicts and the publish are governed jobs: each run carries its own scope record: what it ran on, with which parameters, what it wrote. And each step runs inside a measured budget that fails the build if it slips.

    A run is repeatable because its inputs are named, and a published cycle is frozen as an immutable snapshot the next cycle’s accuracy is measured against.

    Jobs and runs: a governed run with its scope record, timings and outcome, listed with the runs before it.Jobs and runs: a governed run with its scope record, timings and outcome, listed with the runs before it.
    Jobs and runs: a governed run with its scope record, timings and outcome, listed with the runs before it.Jobs and runs: a governed run with its scope record, timings and outcome, listed with the runs before it.
    Jobs & runsEvery governed run carries its own scope record: what it ran on and what it wrote.

  6. Review

    The planner’s day begins: the worklist ranks what needs a look, a verdict is one gesture stored as data, and every number can be asked why. Accuracy, bias and forecast value added are graded automatically at whatever level the planner pivots to, including when a human change made the plan worse.

    Nothing here is a special screen. Every page in the review is rendered from the same metadata the Designer wrote in step two.

    A planner’s day, on one surface
    The cell’s own right-click menu over a forecast: copy, copy with headers, what built this number, and explain this cell.The cell’s own right-click menu over a forecast: copy, copy with headers, what built this number, and explain this cell.
    What built this number?Every forecast carries its own questions: what built this number, and an explanation of the cell.

The configurability ladder

If it changes the business, it’s a screen.

Measures, formulas, rules, pages, filters, policies, action buttons and model bindings are all authored in the product and versioned like everything else. When you outgrow the forms there is a plug-in contract, and behind that a governed SQL console: read-only by default, audited always.

  1. Formulas and named sets

    a planner or an analyst

    A measure defined from other measures; a saved selection, "top 100 by revenue in the North region, excluding discontinued", that every grid, run, policy and access rule can reuse.

  2. Rules

    an analyst or an administrator

    A live rule with a target, an expression and the slice it edits, bounded or open in time, switched on and off from the interface, versioned like everything else.

  3. Procedures and action buttons

    an administrator

    A governed sequence of steps behind a button with a typed parameter form, so a routine becomes one click with its inputs validated.

  4. Plug-ins

    your data scientists and engineers

    A model, a solver, a feature or a custom step registered through one contract: sandboxed, resource-limited, permissioned and lineaged, competing on the same footing as the built-ins.

  5. The governed SQL workspace

    an administrator, when the forms run out

    Read-only by default, audited always, walled by the same permissions as every other door. The last rung is a statement that there is nothing to hide.

Along the way

Nothing changes without a record.

Configuration is versioned and diffable, plan edits carry who, when, what-from and what-to, and a published cycle is an immutable snapshot you can compare against.

Versioned configuration

Every dimension, measure, rule, page and policy carries a version; change sets roll back as a unit when something in them fails.

Auditable edits

A plan edit records the actor, the source, the old value and the new one, through the same door whether a person or a program made it.

Upgrades as a diff

A package upgrade arrives as a field-level three-way diff against your customisations, with conflicts named rather than overwritten.

Walk the path on your data

Bring a slice of your history and your hierarchies. We model them in the Designer, load them, and show the engine working on them: the same six steps, your numbers.

Request a demo

a working demo on your data · no commitment