Decision intelligence platform: the architecture, in 2026

"Decision intelligence platform" has become the noun the retail tech market reaches for when "BI" and "forecasting" no longer fit. The category is real — and so is the confusion around it. Buyers shortlist four vendors who all use the phrase. Twelve months later, two of them turn out to be dashboard tools and a third a forecasting engine with workflow on top.

The category is best defined by its architecture, not its marketing. A decision intelligence platform has a specific shape inside: four layers, each with its own contract. Pull any layer out and what remains is one of the older categories — a reporting tool, a prediction engine, a workflow product.

This article opens the box. It defines the category in a sentence, walks through the four layers, names the two confusions, traces the decision lifecycle, and surfaces what actually breaks in production. It complements our decision platform vs forecasting platform vs BI comparison and our what is a decision layer in retail definition. For where this tier sits in the wider stack, see retail data stack vs decision stack. Those name the boundaries; this one shows the inside.

The category, in one sentence

A decision intelligence platform is a system that turns operational data and forecasts into orchestrated, executable decisions across the retail chain. It then feeds the outcome back into the model so the next cycle is better.

That sentence carries five load-bearing words. Operational — the platform consumes the real state of the chain, not a sample. Orchestrated — decisions are sequenced and reconciled with each other.

Executable — the output reaches the systems that move money, stock, and price. Across the chain — allocation, replenishment, markdown and transfers live in the same engine, so they cannot contradict each other. Feeds back — the platform measures what its decisions produced and adjusts.

Drop any of the five and you get something else. Without operational, a planning tool. Without orchestrated, a recommendation engine.

Without executable, a smarter dashboard. Without across the chain, a point solution. Without feeds back, a frozen rule engine that decays the day after go-live. The category is the conjunction, not the bullet list.

The four layers

Inside a decision intelligence platform sit four layers. They are not optional sub-modules — each one solves a problem the next assumes is already solved.

Data layer

The data layer harmonises the operational state of the chain. It ingests from the systems that hold ground truth. ERP for master data and stock, WMS for warehouse state, POS for sales, CRM for customer, sometimes a separate price master, often an e-commerce order book. It reconciles them into a single SKU/store/day view the rest of the platform can rely on without re-asking.

The pattern matters more than the storage technology. Modern stacks usually land on a lakehouse or warehouse with a semantic layer on top. The same definition of "stock on hand" or "sell-through" is then used by every downstream component. The contract of this layer is legibility: every other layer should be able to ask "what is true?" and get one answer.

What disqualifies a system from carrying this layer is not the absence of a data lake — it is the absence of reconciliation. A platform that reads three disagreeing stock numbers from three systems and exposes all three is not a data layer. It is a passthrough.

Intelligence layer

The intelligence layer turns harmonised data into the model outputs decisions depend on. Demand forecasts at the SKU/store level, stockout and overstock probabilities, sell-through projections, price elasticities, return likelihoods, sometimes a markdown-risk score or a transfer-yield estimate. It is the home of the models — classical statistical forecasting, gradient-boosted trees, deep learning where it earns its place, and rule-derived signals where the model has nothing to add.

Its output is not a prediction document. It is a decision-ready signal. A quantity, a probability, an interval, attached to the SKU/store/day grid the data layer defined, with enough metadata for the next layer to weigh it against alternatives. The contract is predictive accuracy with provenance. Every signal must know how it was produced, on which data, with which confidence — otherwise the orchestration layer cannot reason about it.

This layer is where most retail vendors stop. They produce signals and hand them to a human, or to a workflow tool, with no further coordination. That stopping point is precisely what defines them as forecasting platforms rather than decision intelligence platforms.

Orchestration layer

The orchestration layer is where decisions are actually made. It takes the signals from the intelligence layer and the business rules from the chain — margin floors, supplier MOQs, commercial calendars, brand handling, category arbitration. It reads the current operational state. Then it commits to a specific action on a specific object.

The output unit is not a chart and not a list. It is a verdict: replenish 18 units of this SKU to that store on Tuesday — and the reasoning that justifies it. Critically, this layer sequences related decisions.

Allocation cannot decide a quantity that replenishment will then ignore. A markdown cannot fire on a SKU another team is replenishing in parallel. The orchestration layer holds the global view that prevents self-cancelling decisions. This is what makes it structurally distinct from a workflow runner that fires actions one at a time.

The contract is committed, coherent, explainable arbitration. Anything weaker — "here are five options ranked by score" — is a recommendation engine. We make this case in depth in how retail data becomes useless without a decision layer.

Execution and feedback layer

The execution and feedback layer lands the decision in the systems that move the world. It writes orders into the ERP, transfer instructions into the WMS, price changes into the pricing system, store tasks into the ops app the floor uses. Without re-entry. Within commercial cadence — hours, not days.

Then it measures. Did the markdown clear the stock at the expected depth? Did the transfer balance the network or just move the problem? Did the replenishment land in time to catch the demand spike the forecast predicted?

Those outcomes flow back into the data layer as new ground truth, and into the intelligence layer as labels the model can learn from. That closing loop is what separates a learning decision system from a static one. Without it, the platform freezes in the state it shipped, blind to its own results.

The contract is write-back and measurement. A platform that can write decisions but cannot observe what they produced is half a decision intelligence platform.

Two boundary conditions people get wrong

The category gets mislabelled in two specific ways. Both are easy to spot once the architecture above is on the table.

It is not a BI tool with extra views. BI is the visualisation of the past — its unit of work is a chart a human reads. A decision intelligence platform's unit of work is an action a system commits to.

Adding more dashboards, drill-downs or "AI-powered insights" to a BI tool does not move it across the boundary. The boundary is the deliverable, not the polish on the deliverable. We unpack this in decision intelligence vs business intelligence. A reporting layer is structurally below the intelligence and orchestration layers, not a substitute for them.

It is not a forecast platform with an export button. A forecasting engine produces a number. A decision intelligence platform produces an action under constraints.

A 92%-accurate forecast still does not say whether to mark down, transfer, replenish or hold. The leap from prediction to decision is precisely where most ML-led retail projects stall. We argue this at length in from forecasting to decision: why ML isn't enough. Wrapping CSV export and a Jira webhook around a forecast does not produce the orchestration layer. The orchestration is the new component, not the integration.

A useful test: pick a SKU/store and ask the platform "what should we do here, why, and can you make it happen?" If the answer is a chart, the platform is BI. If the answer is a number, it is forecasting. If the answer is an action with reasoning that arrives in the WMS without anyone re-keying it, the architecture is genuinely in place.

The decision lifecycle

The four layers describe what the platform is. The decision lifecycle describes how a single decision moves through it.

It starts with a signal. The intelligence layer fires — a stockout-risk score crosses a threshold, a slow-mover gets flagged, a transfer opportunity opens because two stores diverged faster than the forecast expected. The signal lands in the orchestration layer with its metadata: which SKU, which store, what confidence, what time horizon.

The orchestration layer then runs option generation. For this signal, what are the candidate actions? Mark down, transfer, replenish, return, do nothing, sometimes a combination. Each option is scored on expected outcome, cost, and risk — using the intelligence layer's outputs for the predictive parts and the chain's rules for the constraints.

Then the constraint check. Each candidate is filtered through margin floors, supplier MOQs, commercial calendar locks, brand-specific handling, logistics capacity. A candidate that survives is feasible; one that doesn't is dropped with a reason that can be inspected. This step is what makes the difference between a recommendation an ops team will execute and one they will silently ignore.

The surviving candidates are arbitrated, and the decision is committed: a specific action on a specific object at a specific time, with the reasoning attached. If the decision exceeds an automation threshold — by value, by risk, by exception — it routes to a human for approval before execution. Either way, it does not stop at the screen.

It then executes. The decision is written into the downstream system as a real instruction — a transfer order, a price change, a replenishment quantity, a store task. The execution layer logs the write and waits for the world to respond.

The world responds, and the platform measures. Did the transfer happen, on time, at the planned cost? Did the markdown clear the stock at the predicted depth?

Did the replenishment arrive before the stockout? These outcomes flow back as feedback. The intelligence layer uses them to recalibrate its models. The orchestration layer uses them to adjust its arbitration weights. The next cycle is measurably better than the last — or the platform can name exactly why it is not.

What is hard in production

The architecture above is the easy part to draw. The hard part is making it survive contact with a real retail chain. Four things teams routinely underestimate.

State coherence across decisions. Allocation, replenishment, markdown and transfers all read from and write to the same operational state. If allocation commits a transfer at 10:14 and replenishment runs at 10:16 against a snapshot taken at 10:12, the two decisions can disagree without either being wrong on its own.

A real orchestration layer holds a consistent view of operational state across decisions. Otherwise it produces correct-looking outputs that contradict each other in execution. This is closer to a database transaction problem than a modelling one, and it is rarely on the slide deck.

Override governance. A human will need to inspect and correct decisions — that is non-negotiable. The platform has to make that possible without breaking the loop. Every override must be visible, attributable and labelled.

The model can then distinguish "this decision was wrong" from "this decision was right but commercial overrode it for a reason the system does not yet know". Without override governance, overrides poison the feedback signal and the model degrades. With it, overrides become the most valuable training labels in the dataset.

The decision latency vs decision quality trade-off. A perfect decision computed in twelve hours is, for a replenishment cycle that ships at 06:00, a wrong decision. A fast decision computed on stale inputs is a different kind of wrong decision.

The platform has to expose this trade-off explicitly. Which decisions tolerate latency, which do not, what the cost of waiting is, what the cost of acting on incomplete signal is. Teams that treat latency as a single number to optimise will optimise the wrong number.

Data quality fallback patterns. Operational data is incomplete. POS feeds drop, WMS receipts lag, master data goes stale during seasonal launches.

A decision intelligence platform that can only decide when all inputs are clean is a platform that stops deciding precisely when the chain needs it most. The architecture has to degrade gracefully. Name the uncertainty in the signal, narrow the option space, route to a human earlier, or defer the lowest-stakes decisions. Never silently produce confident decisions on bad data. This is mostly a discipline of the intelligence and orchestration layers, and it is what separates a platform you can run unattended from one you cannot.

Solya, in context

Solya is built as a decision intelligence platform by design, not by add-on. The intelligence layer and orchestration layer are first-class components of the product, not modules layered on top of a BI tool or a forecasting engine. The architecture above is the shape of what we ship — the four layers, the lifecycle, and the production patterns that hold it together at scale. We position the platform inside the broader retail stack in our retail decision platform buyer's guide.

The question to ask of any platform that uses the phrase

Forget the brochure. Ask the four-layer question. Can the platform name its four layers, and show you a decision that traveled all of them end to end, feedback closing the loop?

If the answer stalls at "intelligence" — we predict, then you decide — the platform is forecasting. If it stalls at "orchestration" — we recommend, then your ops team enacts — it is a recommendation engine. If it stalls at "execution" — we send a notification — it is a workflow tool. A decision intelligence platform is the one that completes the loop.

For the integration and security questions IT directors face during platform selection, see our IT Director FAQ.

---

Want to see the architecture against your stack?

At Solya, we offer retail data and operations leaders a personalized 30-minute diagnostic. We map your current stack against the four-layer architecture above, name precisely which layer is missing or under-built, and identify the decisions losing the most margin to that gap. You'll walk away with:

• A four-layer map of your current architecture and where each layer stops
• The specific decision types that fall through the seams between layers today
• The first high-ROI loop to close end to end under a real decision intelligence platform