The Decision Outcome Framework: How to Operationalise a Data Strategy

Most organisations have a data strategy. Few have a way to operationalise it.

I have spent more than a decade building data and analytics products that drive outcomes across a range of industries and data domains. One thing remains consistent. The clear GAP between what people say and what people do.

There is usually a strategy. There might be a target operating model. There might even be a roadmap. Most of it lives in PowerPoint. Almost none of it is connected to how the day-to-day operating process actually generates the data that feeds the dashboards that inform the decisions.

Does this look familiar: someone forwards a spreadsheet, someone else asks for a report, a third person is told to make it look good before Friday.

The strategy lives in one place. The work lives in another. The two never meet.

The Decision Outcome Framework is my attempt to close that gap. It is an operationalised framework that has evolved from years of practice, building data products that drive outcomes and not just outputs, learning the hard way what worked and what did not, and refining the method until it stopped failing in the same places. The component steps came together gradually. The framework is the synthesis. The values it is shaped to enforce are set out in the Data Guiding Principles.

This piece sets the framework out in full. It also sets out why generative AI has, for the first time, made it genuinely operationalisable, which is what I am building through the Meridian platform. The framework is the thinking. The platform is the implementation. They are not the same thing, and they should not be treated as such.

What problem does the Decision Outcome Framework solve?

There are three failure modes I see repeatedly in data teams. They look different on the surface. They are the same problem underneath.

The first is the dashboard that answers the wrong question. Someone asks for “a view of utilisation,” a developer builds a view of utilisation, and six months later nobody is using it because it was never the right question to begin with. The strategic intent was buried under a literal request, and nobody had the structure to surface it.

The second is the dashboard built on data nobody trusts. The developer ships it, the audience uses it for a week, someone challenges a number, the trust collapses, and the dashboard is quietly retired. Nothing was wrong with the visualisation. The data underneath was never explicitly governed, and the moment it was tested, it failed.

The third is the dashboard that becomes “the truth” because nobody can prove otherwise. A number lands in a slide deck, gets quoted in a board meeting, and now it is canon. There is no lineage, no rule, no certification. It is just a number that becomes implicitly trusted.

Every one of these is a governance failure. Not a technology failure. Not a capability failure. The tools to prevent each of them already exist. What does not exist, in most organisations, is a structured way to make governance the default behaviour rather than the exceptional one.

The Decision Outcome Framework is that structure.

Stated as the inverse, there are three concrete ways to improve a dashboard under this framework. Each is the deliberate antidote to one of the failure modes above.

1. Anchor it to a clearly defined business question. Make sure the dashboard answers the decision someone is actually trying to make, not the data that happened to be available. This is the antidote to dashboards that answer the wrong question.
2. Build it on explicitly governed data. The data underneath needs a dictionary, business rules, and a named process owner standing behind it. This is the antidote to dashboards built on data nobody trusts the moment it is challenged.
3. Certify it against the original question and a design standard. Issue an explicit verdict: certified, conditional, or not certified. This is the antidote to numbers that become “the truth” only because nobody can prove otherwise.

Dashboards improve when governance is the default rather than the exception. The five steps that follow turn that default into a working method.

What are the five steps of the Decision Outcome Framework?

The framework has five iterative steps. Each one produces an explicit output. Each one feeds the next. The steps are not a checklist. They are a working method that a team uses to take a business question from “we should look into this” to “this dashboard is certified to ship.”

Step 1: Curate the Question

Start with the right question, not the nearest dataset.

Most data work begins in the wrong place. Someone has data, someone wants a dashboard, work begins. The question that should drive everything is taken as read, when in reality it is usually vague, contested, or simply absent.

Step 1 is the deliberate act of refusing to start until the question is properly defined. What decision needs to be made? Who is making it? What does success look like? What is the cost of getting it wrong? What does the audience need to see to act?

The output of Step 1 is the Scoped Brief. The pattern is borrowed from Human Centred Design, specifically LUMA’s Project Concept Poster, which I have adapted with a few small adjustments to capture the problem statement, the audience, the success criteria, the risks, and the critical data elements required to answer the question in a structured, repeatable way. It is an artefact of Human Centred Design because the entire point is to define a human-centred solution to a problem humans have today.

It is also the contract for everything that follows. If a dashboard built three months later does not address what was agreed in the brief, that is a failure that can be pointed at directly.

In the Meridian product, the Scoped Brief is produced through a structured form called the Business Case Canvas. The Canvas is the activity. The Scoped Brief is the artefact it produces.

This step is also where prioritisation happens. Not every request should move forward. The brief allows the team to score requests on strategic value versus effort, and to focus on the work that matters rather than the work that is loudest.

A note that runs through the whole framework: data products are outputs, but they exist to support outcomes. The outcome is what matters. The dashboard is not the point. The decision the dashboard enables is the point. Every step from here is in service of that.

Output: Validated business question, success criteria, critical data elements, risk register, prioritisation score.

See how this works in the Meridian product: Business Case Canvas →

Step 2: Conform the Data

Standardise the data so everyone is speaking the same language.

Once the question is clearly articulated, identifying the Critical Data Elements needed to answer it is actually fairly easy. What is not easy is getting clarity on what the definitions of those elements actually are, how they live through the operating processes, and how the technology systems that manage them line up. That is assuming those systems even exist.

This step specifies exactly what data is needed, in what form, and how the fields relate to each other. It is not a database design exercise. It is a definitional one. And it has to be led by the business.

This is where I want to introduce a principle that runs through the rest of the framework.

“

Data is a shadow of process.

”

If the data is bad, the process is usually broken. The implication, which most organisations resist for as long as they can, is that the process owner has to own the data. Not the data team. Not IT. The person responsible for the operating process that generates the data is the only person who can credibly own the definitions, the quality, and the accountability.

This is often where data teams struggle. Without strong process owners, the data is just shadow with no substance. The data team can write all the dictionaries it likes. None of it will hold up under pressure if there is no business or process owner standing behind the definitions and the data they generate. The honest answer, particularly in large disparate organisations with varied levels of data and digital literacy, is that you cannot brute-force this. You partner where you can win, deliver an outcome, and use that as evidence for why the rest of the organisation should follow.

In any organisation of meaningful size, the same word means different things in different systems. “Property” in the lease database is not “Property” in the facilities system. “Utilisation” in HR is not “Utilisation” in Real Estate. Conforming the data means agreeing, explicitly, what each field is, where it comes from, what its valid values look like, and how it connects to the other fields in the model.

The output is a data dictionary aligned to a Core Meta Model. The Core Meta Model is a model of the core metadata an organisation needs to support the acquisition of the data of today for the decisions of tomorrow. Technically, this is the semantic layer: the conformed structure that BI practitioners query against to build dashboards, and the same structure that LLMs increasingly query against to deliver decision support. Without it, every downstream piece of work, human or machine, has to relitigate definitions in the background. With it, the team has a shared semantic foundation to build on.

Output: Data dictionary and semantic relationship model, aligned to the Core Meta Model.

Step 3: Clean the Data

Govern the data through explicit business rules, not implicit trust.

Step 3 is where most teams hand-wave. Data quality is treated as something the data team or IT handles, or something that gets checked at the end. Both are wrong.

Cleaning the data, in the framework, means defining the explicit business rules that govern each Critical Data Element through the operating process. What are the acceptable thresholds of quality? What are the valid value ranges? Who owns this field? Who is accountable when it breaks? What is the remediation path?

This is the contract handshake between the people who produce the data through their processes and the people who consume it. It is governance written down. Without it, every dashboard is built on a foundation of implicit trust, which is to say, no trust at all.

There is a critical point about how those rules should be implemented. Most organisations build them as reactive checks: data lands in a warehouse, a quality engine inspects it, broken records are flagged after the fact. That is necessary, but it is the weakest possible version. The stronger version is to push the rules upstream to the point of capture, into the day-to-day operating technology itself, so that the data is right when it is created rather than corrected after it has already caused harm. That is a proactive data quality posture, and it should be a first-class input into the technology roadmap.

This requires the data team and the digital team to be joined at the hip. They almost never are. More often, the data team is filing technology requests on behalf of business owners who have not prioritised the technology change required to fix the data problems they themselves are complaining about. That structural tension cannot be solved by the data team alone. It is an organisational design problem, addressed in the next section.

The output of Step 3 is a business rule set with named owners, measurable quality thresholds, and remediation accountability. This is documented and exportable. The team takes the rule set and implements it in their own data quality engine and, where appropriate, in their operational technology. The framework defines the rules. The team enforces them.

Output: Business rule set, ownership map, data quality thresholds, remediation accountability.

Step 4: Connect End-to-End

Bring the data together into a coherent, shippable whole.

Step 4 is where the work of Steps 2 and 3 becomes a complete, traceable data foundation. The conformed model, the business rules, the ownership, the quality thresholds, all of it has to fit together into something a dashboard can actually be built on.

This is where the data narrative becomes coherent across the full lifecycle of the business process. The thread that runs from Step 1’s question to the final visualisation has to be unbroken. If the data narrative fragments halfway through, the dashboard at the end will fragment too.

The anchor of Step 4 is the entity identifier: the property ID, customer ID, or order ID that connects every step in the underlying process. That remains true regardless of industry. What I have come to see more clearly over time is that the broader output of Step 4 is the deployable data product itself: a defined, governed, addressable artefact that downstream consumers can rely on. Whether the data product is structured as a formal contract, a manifest, or a curated table, the principle is the same. The data has been brought together into something the team can ship.

Output: Connected data product with end-to-end lineage, ready to support a certified insight.

Step 5: Certify the Insight

Score, certify, and ship. Or send it back.

Step 5 is the moment of judgement. A dashboard has been built on the foundations laid by Steps 1 to 4. Before it ships, it is assessed against two questions.

Does it meet the design standard? A dashboard that buries the answer in clutter, ignores accessibility, or violates the visual conventions of its audience is not ready to ship, regardless of how good the data underneath is.

Does it answer the question from Step 1? A dashboard that looks beautiful but does not actually address what was agreed in the Scoped Brief is also not ready to ship. The Step 1 to Step 5 linkage is the most important loop in the framework. It is the thing that prevents the dashboard from drifting away from its original intent during development.

The output is a certification verdict: certified, conditional, or not certified. Certified dashboards ship with a visible mark. Explicit trust made tangible. Not-certified dashboards come back with detailed remediation guidance. There is no ambiguity, no soft “looks good to me,” no implicit approval.

In time, the Step 5 certification will extend to a third assessment: whether the data product underneath the dashboard genuinely conforms to the contracts defined in Steps 2, 3, and 4. That is the full Score, Certify, Ship promise. It is the direction the framework is heading.

Output: Certification verdict (Certified / Conditional / Not Certified), with remediation guidance.

See how this works in the Meridian product: Dashboard Certification →

What Holds It Together: Iteration, Contract, and Accountability

Three things make the framework work in practice.

The first is iteration. The five steps are not a waterfall. Real data work loops. A weakness exposed in Step 3 sends the team back to refine Step 2. A failed certification in Step 5 sends the team back to revisit Step 1. The framework is designed to be revisited, not completed once. Each cycle sharpens the foundation for the next.

The second is contract. Governance in this framework is not a policy document filed somewhere nobody reads. It is embedded in the artefacts each step produces. The Scoped Brief is a contract between the developer and the business. The data dictionary is a contract between the producers and consumers of data. The business rules are contracts of accountability. The certification verdict is a contract of quality. Each step’s output is a binding artefact, not a suggestion.

The third is accountability. This is the part most data strategies leave out, and it is the reason most data strategies fail.

“

A contract without consequence is a wish.

”

Accountability comes from organisational design. The objectives of Business Owners and Process Owners have to be chained to the data outcomes their processes produce. Most organisations try to do this with data handshake agreements between data teams. That is the wrong handshake. It happens between the wrong people. The handshake that matters is between the Business Owner who wants the dashboard and the Process Owner whose data feeds it. And it has to have something at stake. Fee at risk. Bonus at risk. A KPI that actually shows up in a performance conversation.

Without that accountability, “good data” remains the domain of data stewards and data managers, sitting on the technology side of the organisation, away from the business processes they nominally govern. That arrangement does not work. It has not worked anywhere I have seen it tried. Governance only shapes the work when the people who run the work have something to lose if the data is not governed.

When governance is contract with consequence, it actually shapes the work.

Why This Is Operationalisable Now

The framework is not new in spirit. The components have existed in various forms in good data teams for years. What is new is that, for the first time, the framework is genuinely operationalisable.

Generative AI has changed the economics of two of the hardest steps. Step 1 used to require a senior consultant or a very experienced BI developer to interrogate a vague request and turn it into a sharp question. That work can now be supported by an AI that asks the right follow-up questions in real time, surfaces unstated assumptions, and challenges weak framing without getting tired or political. Step 5 used to require a human reviewer with deep design knowledge to score a dashboard against a standard. That work can now be done objectively, consistently, and at scale by an AI that has been trained to apply the rubric.

That is what made Meridian possible. The framework is what I would have wanted ten years ago. The platform is what I can finally build today.

What Meridian Implements Today

Meridian is the platform that operationalises the Decision Outcome Framework. It is the structured mentoring layer that sits alongside a BI team, guides them through the framework, and produces the artefacts each step demands. Score. Certify. Ship.

Today, Meridian implements Step 1 and Step 5 in full. It guides a BI developer through curating the question, with AI-powered critical challenge to surface weak or vague framing. It then accepts a completed dashboard and certifies it against both the design standard and the original Step 1 Scoped Brief, producing a verdict and detailed remediation guidance.

Steps 2, 3, and 4 are the published roadmap. The reasoning is deliberate. The two highest-leverage points in the framework are the bookends: the moment a question is defined, and the moment a dashboard is judged ready to ship. Get those two right and most of the failure modes I described earlier are prevented. The middle steps are essential, but they are also where every team’s existing tooling and governance maturity differs most. Meridian will extend into them iteratively, and the framework will not change as it does.

The framework is the asset. The platform is the implementation. They are not the same, and they do not have to be one-to-one on day one.

Frequently Asked Questions

Mark Cunningham is the founder of Insights². He has spent more than a decade building data and analytics products. He writes at insights-2.com about how to make the meaningful measurable.