From Tables to Decisions: Why Dashboards Don’t Change What Teams Do

This is an idea paper: a pattern I keep seeing across data teams, a proposal for what’s missing, and a sketch of what closing that gap could look like. It’s a direction to explore, not a finished result — I’d welcome pushback from anyone building decision support on top of a warehouse.

The Problem: Data Platforms Stop One Layer Too Early

Ask almost any data team what they’ve built and you’ll hear the same shape of answer: a warehouse, a transformation layer, a semantic model, a dashboard on top. The pipeline runs, the numbers are trustworthy, the chart renders. By every technical measure, the platform works.

And yet the number one complaint from the business side is some version of “we have all this data and nobody uses it to decide anything.” A dashboard gets built, it gets a few weeks of attention, and then a meeting reverts to whoever argues most convincingly.

The reason, I think, is structural rather than cultural. A dashboard answers what happened. A decision requires what should we do about it — and that requires a threshold, an owner, a set of options, and a next action. None of that lives in the semantic layer. It lives, if anywhere, in someone’s head, or in a Slack thread that nobody can query.

The Idea: A Decision Layer, Modeled Like Data Is

What if decisions were first-class objects in the platform, the same way metrics and dimensions already are? The proposal is a thin layer — call it a decision layer — that sits on top of the existing semantic model and captures, for a defined set of recurring decisions:

• The trigger metric — the specific query or threshold that should prompt a decision, expressed in the same terms as the metrics layer already uses.
• The owner — who is accountable for acting when the trigger fires, not just who receives the alert.
• The option set — the two or three responses that are actually on the table, written down in advance rather than improvised in the moment.
• The resolution record — what was chosen, and what happened to the metric afterward.

None of this replaces the dashboard. It sits beside it, and it’s deliberately small: not a workflow engine, not a BPM tool, just a structured record of the decisions a business actually repeats — pricing changes, inventory reorders, campaign go/no-go calls, escalation thresholds.

DecisionLog: Closing the Loop Back to the Data

The part I find most interesting is the feedback loop. Call the system that would run this DecisionLog:

1. Trigger watch — evaluate each registered trigger against the semantic layer on a schedule and open a decision record when one fires.
2. Nudge, don’t alert — route the open decision to its named owner with the pre-written option set attached, instead of a generic anomaly notification.
3. Capture the resolution — require a one-line record of what was chosen before the record can close.
4. Replay against outcomes — join resolved decisions back to the metric a week or a month later, so the log itself becomes a dataset: which options tend to work, and for which triggers.

That last step is the payoff. Today, the outcome of a business decision is almost never joined back to the data that prompted it. If it were, a team could eventually query “what do we usually do when this metric crosses this line, and does it work?” — the same way they already query “what did revenue do last quarter.”

Hypotheses Worth Testing

The idea rests on a few assumptions that would need real usage to validate:

• Decisions are repeatable enough to model. If most consequential calls are genuinely novel each time, a fixed decision layer has little to attach to.
• Naming an owner changes behavior. An alert with an accountable name attached should get acted on more often than an anonymous dashboard threshold — but that needs to be measured, not assumed.
• Pre-written options reduce delay. Deciding among three known responses should be faster than reasoning from scratch under time pressure.
• The resolution log compounds in value. A handful of logged decisions won’t show much. The bet is that dozens of them, joined back to outcomes, start to reveal which responses actually move the metric.

Open Questions

• Scope creep. It would be easy for a decision layer to grow into a full workflow or ticketing system. Keeping it to a record-and-join tool, not a task tracker, seems important to its usefulness.
• Who defines the trigger. Getting the threshold and the option set right up front takes real domain judgment — probably a joint exercise between the data team and the decision owner, not something a data team can define alone.
• Staleness. Business conditions change; a trigger or option set written six months ago may no longer fit. The layer would need its own review cadence, not just a one-time setup.
• Measuring the counterfactual. Joining a decision to an outcome is easy. Knowing what would have happened under the option not chosen is much harder, and probably out of scope for a first version.

Why This Matters Beyond the Math

From a product seat, the recurring pattern is that data teams get measured on pipeline reliability and dashboard adoption, while the business gets measured on decisions and outcomes. Those are different scoreboards, and a lot of the frustration on both sides comes from optimizing for one while being judged on the other. A decision layer is an attempt to put both sides on the same scoreboard — where a resolved, outcome-linked decision counts as the unit of value, not a viewed chart.

If you’ve tried to build something like this — a metrics layer with accountability attached — I’d genuinely like to compare notes.