A framework tells you what to do. Principles tell you why. The Data Guiding Principles set out the values that sit underneath the Decision Outcome Framework: the beliefs about data, process, and accountability that the framework is shaped to enforce.
They are short. They are opinionated. They are the result of more than a decade of building data products inside organisations where the same failure modes kept appearing in different costumes. Each principle exists because its absence has a predictable, expensive consequence.
The framework principle: design out, ship in.
Data sovereignty, sensitivity, and access controls are getting more rigorous. Building data products inside a client environment is increasingly complex, and that complexity is not going away. The temptation is to fight the constraint from inside it. To negotiate access, to spin up sandboxes, to argue with security. That work rarely pays back.
Design the product outside. Ship it in.
This is not just a technical pattern. It is a delivery philosophy. The thinking, the modelling, the engineering, the iteration all happen in an environment built for them. The deployment happens into the environment built to govern them. The two are kept distinct on purpose. This principle sits across everything that follows.
What are the six guiding principles for a data and analytics team?
Each principle below is paired with the step of the Decision Outcome Framework it most directly informs. The principles came first. The framework is what they look like when applied.
If you can’t curate the question, it’s not important.
Clarity comes before cleverness.
Everything starts with clarity. Data fluency begins when we understand what decision we are enabling, who it is for, and how success will be measured. If you cannot articulate the question, it is impossible to visualise the answer.
So before anything else, ask: what decision does this data need to support? Not “what should the dashboard look like?” That comes later. The question comes first. Always.
Not all data is created equal.
Identify the data that runs the business and protect it.
Some data runs the business. Some data is noise. Knowing the difference is what separates a data team from a reporting team.
We identify and protect Critical Data Elements, the data that matters most to our business processes. Standardising definitions ensures that when two people use the same word, they mean the same thing. That sounds obvious. It rarely is.
Data is the shadow of process. Stop running from your shadow.
Fix the process, the data follows.
Every data quality issue has an upstream cause. Fixing the process fixes the data. Trying to fix it in the dashboard is like mopping the floor while the tap is still running.
The data team’s job is to ensure data flows cleanly. The business owner’s job is to ensure it is correct at source. Process mapping and its effectiveness sit with process owners and business owners. We provide the inputs. They own the outcome.
Top tip: Stop trying to fix data in a dashboard. Fix it in your process. The dashboard will follow.
The data team creates connections, not copies.
Integration is leverage. Duplication erodes trust.
The value of a data team is not in rebuilding what already exists in your source systems. It is in bringing data together in a way that no single system can do alone.
We connect disparate systems and sources into a single governed model that tells the full story. We integrate across platforms, ensuring consistency, interoperability, and shared trust across the data ecosystem. Copying a report from a source system is not integration. It is duplication. And duplication erodes trust.
Dashboards are easy. Data is hard.
The value sits beneath the visual.
You cannot throw data at a dashboard and expect insight to appear. The real value sits in the lineage, the logic, and the trust beneath the visual. Data fluency means understanding what drives the numbers, not just how they look.
Here is something worth saying plainly. The data team does not need dashboards. Dashboards exist to enable better decisions within the business. The data team’s role is to design, connect, and deliver the product. Driving adoption is on the process owner. If dashboards are not delivering value, the process owner needs to take accountability. That is not a criticism. It is a clear division of responsibility.
Insights only create value when they are used to drive action.
Words mean stuff.
Definitions are infrastructure for the AI era.
In the era of AI, this has never been more true. Large language models are exactly that. Models. Built on language. And language is words.
The precision of your data definitions directly affects the quality of any AI output derived from them. Conforming definitions may feel like the least exciting part of data work. It is not. It is foundational. Garbage in, garbage out has always been true. AI just amplifies the consequences, faster, and at scale.
This is why Step 2 exists. This is why the Core Meta Model — the shared semantic layer that conforms every definition the organisation runs on — matters. Get the words right and everything downstream gets easier.
From principles to practice
Principles on a wall do nothing. Principles wired into a method change behaviour. The Decision Outcome Framework is how these principles become a working method that a team uses week after week. The principles explain why the framework refuses to start without a curated question, why it insists the process owner owns the data, why it certifies dashboards rather than approves them.
The platform that operationalises the framework is Meridian. The principles are the asset. The framework is the method. The platform is the implementation. Three layers, one direction of travel.
Frequently Asked Questions
What does "design out, ship in" mean?
Design out, ship in is the principle that data products should be designed and built outside the client environment, then deployed into it. Data sovereignty, sensitivity, and access controls are tightening, and trying to do all the design and build work inside a constrained client environment slows everything down. The pattern separates where the thinking and engineering happens from where the product runs. It is a delivery philosophy as much as a technical pattern, and it sits across every other principle.
Why does the data team not own the data?
Because data is a shadow of process. The process owner is the only person who can credibly own the definitions, the quality, and the accountability of the data their process generates. The data team's job is to design, connect, and deliver the data product. The process owner's job is to make sure the data is correct at source. If the process is broken or unowned, no amount of cleaning downstream will produce trustworthy data.
What is a Critical Data Element?
A Critical Data Element is a piece of data that materially supports a business process or decision. Not all data is created equal. Some data runs the business, some data is noise. Identifying CDEs, standardising their definitions, and protecting them is what separates a data team from a reporting team. The CDE list is the working subset of the data estate that genuinely needs governance, ownership, and quality thresholds applied.
Why do words matter so much in the era of AI?
Large language models are exactly that, models built on language. The precision of your data definitions directly affects the quality of any AI output derived from them. Garbage in, garbage out has always been true. AI just amplifies the consequences faster and at scale. Conforming definitions through a shared semantic layer — what we call the Core Meta Model — is the foundational work that makes downstream AI useful rather than confidently wrong.
How do these principles relate to the Decision Outcome Framework?
The Data Guiding Principles are the values. The Decision Outcome Framework is the operating method. Each principle maps directly to a step of the framework: curate the question, conform the data, clean the data, connect the data, curate the insight. The principles explain why the framework is shaped the way it is. The framework explains how to apply the principles in practice.
Why should I stop trying to fix data in the dashboard?
Because every data quality issue has an upstream cause. Fixing a number in the dashboard is mopping the floor while the tap is still running. The fix is temporary, the root cause is untouched, and the same issue surfaces again in the next report. Push the fix upstream into the operating process or the technology that captures the data, and the problem stops recurring.
What is the difference between connecting data and copying it?
Copying data duplicates a source-system report into another tool. Connecting data brings disparate systems together into a single governed model that tells a story no individual system can tell alone. Duplication erodes trust because you immediately have two versions of the truth that drift over time. Connection creates leverage because the whole becomes more than the sum of its parts.
See how we operationalise these principles.
The principles set the values. The Decision Outcome Framework is the five-step method that puts them to work — from the question to the certified insight.
Read the Decision Outcome FrameworkMark 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.