What "AI-native" actually means for planning software

Most planning platforms now claim to "have AI" somewhere in the product — a chat panel bolted onto the side, a forecast button that calls out to a model, a summary widget that paraphrases a report. That's a real feature, but it isn't the same thing as AI-native software, and the difference isn't cosmetic. It changes how the assistance actually gets used.

Two different architectures, not two different features

A system with AI added on treats the model as an external service. You open a chat panel, ask a question in natural language, read the answer, and then go and re-enter whatever that answer implies back into the real planning model — the cube, the driver tree, the version you're actually forecasting against. The assistant sits beside the system of record. It can suggest; it can't act inside the model without a person doing the translation by hand.

In Cubix, AI uses model structure and business context to formulate requests for governed tools. Deterministic tools enforce permissions and perform data operations; the AI has no direct engine access. Proposed changes are validated and staged for an authorised person to review before they are applied.

Why this matters more in a multi-dimensional model

The gap is easy to miss in a flat spreadsheet, where "the model" and "the data" are roughly the same thing. It's much harder to miss in an OLAP planning model, where a single driver change can cascade across dimensions — cost centre, product, time, scenario — and needs to recalculate consistently across all of them.

The assistance layer needs model metadata to understand dimensions and relationships. The engine remains responsible for calculation, while governed tools connect a request to permitted operations. Authorised result previews can include cell values, so AI-provider selection and data handling must be considered as part of deployment design.

What changes, in practice

A few things look different once AI is designed in rather than added on:

• Model building — describing a driver relationship in plain language can produce an actual dimensional structure, not just an explanation of one.
• Variance analysis — the system can trace why a number moved back through the cube's dimensions, not just flag that it moved.
• Recalculation — the engine supports incremental recalculation when model inputs change. Performance depends on model structure and workload.
• Review — every AI-suggested change is a change to the model, so it goes through the same version control and approval path as a human-entered one. Nothing skips the audit trail because an assistant made the edit.

Human-in-the-loop is a design decision, not a limitation

None of this means the system acts unsupervised. AI-assisted suggestions — a proposed driver, a flagged anomaly, a drafted scenario — are exactly that: proposed. A person reviews and approves before anything becomes the plan of record. For finance teams operating under audit and governance requirements, that review step isn't friction to be engineered away; it's the reason the acceleration is trustworthy enough to rely on.

Why we built Cubix this way

Cubix combines a Rust engine, vectorised in-memory computation and incremental recalculation with governed AI assistance. Deployment choices include Australian hosting and client-managed environments. Administrators can disable AI, and any configured provider's processing location and data handling need to match the organisation's requirements.

The practical questions are whether assistance can produce a reviewable proposal, whether tools enforce the user's permissions, and whether people can inspect and approve the resulting changes. These controls make assistance useful without giving an AI provider direct control of the planning engine.

If you'd like to see how this works against a real planning model, get in touch or read more about Cubix.