Retail data stack vs decision stack

Draw the retail technology stack on a whiteboard and almost everyone draws the same thing. Sources at the bottom — POS, ERP, WMS, e-commerce. An ingestion layer above them, a warehouse or lakehouse in the middle, a transformation layer. And BI on top, where the diagram stops. It looks complete because every box is filled and every arrow connects.

It is not complete. It is missing the tier where decisions actually happen.

The modern data stack solved a real problem — getting clean, reconciled, queryable data into one place. That problem is largely solved now. What it never claimed to solve, and what most retail stack diagrams quietly omit, is the conversion of that data into action on the floor. This article separates the two tiers: the data stack that describes, and the decision stack that decides. They are not the same architecture, and one cannot be reached by extending the other.

Two stacks people draw as one

The confusion is structural, not careless. The data stack and the decision stack share the same inputs and live next to each other on the diagram, so they get drawn as a single column. But they answer different questions and emit different units of work.

The data stack answers what is true and what happened. Its unit of output is a row, a metric, a chart. The decision stack answers what should we do about it, and make it happen. Its unit of output is a committed action on a specific object — replenish this SKU, transfer that one, mark down a third.

Treat them as one tier and a retailer ends up with a beautifully instrumented warehouse and an hourly sell-through dashboard. Meanwhile a buyer still re-keys transfer orders into the ERP by hand. The data is composable. The decision is not even on the diagram.

The retail data stack: built to describe

The data stack has a well-understood shape, and it earns its place. Ingestion pulls from the operational systems — extract-load tools landing POS, ERP, WMS and e-commerce feeds into one place. Storage holds it in a warehouse or lakehouse. Transformation models it — the semantic layer where "stock on hand" and "sell-through" get one canonical definition. BI reads from that, and renders it for a human.

Every layer here is genuinely composable. You can swap the ingestion tool, change the warehouse, re-platform BI, and the contract between layers holds. This is the great achievement of the last decade of data engineering, and retail benefits from it as much as any sector.

But notice what the top layer does. BI is descriptive by construction — it answers questions a human asks, and stops at the screen. It will show that margin on women's footwear fell three points last month. It will not decide which of 50,000 SKUs to act on, in what order, under which constraints.

The data stack terminates in a chart on purpose. That was always the job.

The decision stack: built to decide

The decision stack sits above the data stack and consumes it. It does not replace the warehouse or the BI layer — it reads from them, then does the thing they were never built to do. It has its own layers, and they map to a different contract: not legibility, but executed action.

A signal layer turns the data stack's reconciled metrics into decision-ready inputs — demand forecasts, stockout probabilities, overstock risk. An arbitration layer weighs the competing options for each object: replenish versus transfer versus markdown versus hold, under margin floors, supplier minimums and the commercial calendar. An execution layer writes the chosen action back into the ERP, WMS or pricing system — no re-entry. And a feedback layer measures what the action produced and feeds it back.

The unit of output is the tell. The data stack's deliverable is a chart someone reads; the decision stack's deliverable is an allocation or a replenishment order that lands in the WMS without a human re-typing it. We open the inside of this tier in the decision intelligence platform architecture. The point here is narrower: it is a separate tier, not a feature of BI.

Where the data stack stops

The seam between the two stacks is where retail margin quietly leaks. The data stack hands you a perfect description of the problem and then stops, exactly one step before the action. Everything past that point is manual.

A dashboard surfaces that a SKU is overstocked in Lyon and short in Bordeaux. Someone has to notice it, decide a transfer is the right move over a markdown, check the margin holds, and key the order into the WMS. Multiply by tens of thousands of SKU/store pairs every week and the arithmetic breaks. No analyst team asks the right question on every line, every week — so most lines get no decision at all.

This is the gap a decision stack closes, and it is invisible on the standard diagram because the diagram simply ends at BI. We made the broader version of this case in why BI tools don't make decisions and how retail data becomes useless without a decision layer. The architectural reading is the same: the stack is drawn one layer short.

What "composable" really demands

Composability is the right instinct — but it has been applied to only half the stack. The industry got rigorous about composing the data tier and never extended the discipline upward. A truly composable retail architecture treats the decision stack as a first-class tier with its own swappable contract, not as a module bolted onto BI.

That has a concrete design consequence. The decision tier should plug onto whatever data stack you already run — read your warehouse, consume your existing forecasts, respect your semantic layer — without forcing a re-platform. If adding decisioning means rebuilding your data stack, it was never composable. The contract at the seam is what matters: clean, reconciled inputs in; committed, explainable actions out.

This is also why "add an AI feature to the BI tool" is the wrong shape. It folds a decision-tier job back into the description tier and loses the contract. The arbitration, the constraint enforcement, the write-back — those belong to a tier the data stack was deliberately built not to contain.

The Solya angle

This is exactly where Solya sits — not another box inside your data stack, but the decision tier on top of it. Solya reads the reconciled data and forecasts your stack already produces. It runs multi-option arbitration under your business rules at the SKU/store level, then propagates the validated decisions into your ERP, WMS and pricing systems through the orchestration layer. The intelligence layer carries the signals; the application layer is where ops teams steer and override.

It is built to be composable in the way the rest of your stack already is. It plugs onto what you own rather than replacing it — the data layer harmonises, the decision tier decides. You can see the tier doing real work in our continuous replenishment and AI agents on markdown and transfers use cases. The data stack you already built keeps its job. Solya adds the one above it.

The question to ask of your own stack

Draw your stack on the whiteboard and look at the top box. If it is BI — a chart, a metric, a screen — ask where the decision happens. If the honest answer is "in a weekly meeting" or "a buyer notices it and re-keys it," your stack stops at description. The decision tier is being staffed by people doing a system's job.

That gap is not a tooling gap inside the data stack. It is a missing tier above it. The retailers pulling ahead are not the ones with the sharpest warehouse or the most dashboards — they are the ones who stopped drawing the stack one layer short.

---

Is your stack drawn one layer short?

At Solya, we offer retail data and operations leaders a personalized 30-minute diagnostic to map your current stack and pinpoint exactly where description stops and decisioning should begin. You'll walk away with:

• A layer-by-layer map of your stack, with the decision tier marked where it's missing
• The specific decisions falling into the seam between BI and your operational systems today
• The first high-ROI loop to close end to end on top of the data stack you already own