What Is Warehouse-Native Decisioning?

In short: Warehouse-native decisioning runs the decision logic (priors, posteriors, uncertainty, and the choice of next action) directly inside the data warehouse using SQL, rather than exporting data to a separate model service. Composable decisioning keeps learning, deciding, and activation in one place, so every decision is reproducible and never stale.

Most "decisioning systems" still work like this:

export the data, train a model somewhere else, deploy a black box, score later, hope reality hasn't changed in the meantime.

Every arrow in that chain is a place where causality leaks: a sync that fails, a model that goes stale, a feature store that drifts, a training set that describes a world that has already moved. You can't run a tight causal loop across five systems that update on five different clocks.

The fix is to put the decision where the data already is.

Decisions that live in the warehouse

We don't compromise on 1:1 personalization; we run contextual Bayesian bandits, but the entire thing runs on SQL, agnostic to dialect. No separate model service. No conventional feature store. No offline training loop. No bespoke IAM permissions for InfoSec to worry about. Why that matters:

Decisions live where the data lives. Every state, priors, posteriors, uncertainty, sits in tables. Every decision is reproducible with a query. No stale models, no sync failures, no "trust me, it's trained."

High-dimensional, zero matrix inversion. Hundreds of features, no giant covariance matrices, no inversions, no GPU jobs, linear-time SQL solving the problem analytically. (We won't spoil the full method here.)

It changes what experimentation even means. An A/B test asks, "did B beat A on average?" A decisioning system asks, "what should this customer see now to maximize learning and reward?" The shift from measuring correlation to acting on causation belongs inside the tools teams already understand and use, no extra product, no pipelines, no black boxes.

Causality requires one place for learning, deciding, and acting

There's a deeper reason this architecture matters, and it's about journeys.

For decades the marketing workflow has been: define an audience, design a journey, orchestrate touchpoints across channels, measure and iterate. Journeys are not just execution plans, they are how marketers express cause and effect. If a customer does X, do Y. If context changes, branch. If an intervention fails, adapt. A journey is a causal language.

Most AI decisioning sits outside that language, a standalone dashboard or autonomous "brain" bolted on beside the journey. That separation is exactly where causal power dies. When learning happens off to the side, the model isn't changing because a real customer just experienced a real journey. It's changing on a batch schedule, in a different system, against a snapshot of the past.

Composable decisioning means something specific here: no off-prem training, no data movement, real-time learning in place. Every individual moving through a journey updates the model as it happens. No batch jobs, no retraining cycles, no handoffs. Even a fully autonomous system loses its causal edge if learning is decoupled from execution; composability collapses that boundary.

For omnichannel orchestration, this is the whole ballgame: the same engine that decides the next touch is the one learning from the last one, in the warehouse, in real time, not a separate brain trying to catch up to a journey it can only watch from the outside.

This orchestration layer has a name: the Marketing Harness. The Decision OS decides what to do; the Harness is where those decisions run, the context, memory, guardrails, and feedback loop that turn a decision into reliable execution across channels, with role-based agents operating on an always-on loop. Composable, warehouse-native decisioning is what lets the Harness learn in place instead of bolting a model onto the side of the journey. We go deep on it in Part 7.

Causation doesn't emerge from autonomy alone. It emerges when learning, decisioning, and execution happen in the same place, at the same time.

Next in the series: Part 6: Decisioning-Centric vs. Model-Centric AI. Two ways to combine foundation models and reinforcement learning, and why enterprise growth lives on the side most people aren't building for.

FAQ

What is warehouse-native decisioning? It runs decision logic (priors, posteriors, uncertainty, and the next-action choice) directly inside the data warehouse in SQL, instead of exporting data to a separate model service. Decisions live where the data lives, so they're reproducible and never stale.

What is composable decisioning? Composable decisioning learns in place: no off-premise model training, no data movement, and real-time updates as each customer moves through a journey. Learning, decisioning, and execution happen in one system rather than a bolted-on "brain."

Why run decisioning in SQL instead of a separate model service? It removes the fragile export-train-deploy-sync pipeline where causality leaks, avoids matrix inversions and GPU jobs at high dimensionality, and keeps every decision auditable as a query, with no separate IAM surface for InfoSec to manage.

Series: From Correlation to Causation · Part 4 · Part 5