Decision Infrastructure

The Missing Map: Why Your Data Needs a Model Before It Needs a Dashboard

6 min read

Ask your leadership team to define "active client."

You will get three definitions. You will get three numbers. And you will get a quiet, polite argument that has been running underneath your organization for years without anyone naming it.

This is the definition problem. And almost nobody is working on it.

The Part Everyone Skips

Every organization I work with has the same hidden gap. They have data. They have dashboards. They have spreadsheets that get updated every Monday and reports that get sent every Friday. What they do not have is an agreed-upon map of what any of it means.

When organizations invest in data, they usually jump straight from raw data to dashboards. Pull the numbers. Build the chart. Ship it to leadership. Move on.

The step they skip is the one that actually decides whether any of it works. The step where you sit down, as a leadership team, and write out what the core things your organization tracks actually are. What counts as a client. What counts as a service. What counts as a success. How you measure each of them and where the number lives.

In the data world, this has a name. It is called a data model. The simplest useful version has two kinds of tables. Dimensions are the things you measure against, like clients, programs, staff, schools, locations, time. Facts are the events and outcomes you measure, like enrollments, donations, service hours, test scores, revenue. Every dashboard, every report, every AI agent your organization will ever build pulls from that same underlying model.

If the model is clean, everything downstream is clean. If the model is a mess, every dashboard disagrees with every other dashboard, and your team spends more time reconciling numbers than acting on them.

Most small and mid-sized organizations have never had anyone sit down and build one.

For a Long Time, This Was Survivable

For most of the last decade, the definition problem was a tax you could afford to pay.

Your best analyst held the context in her head. She knew "clients" meant one thing in the funding report and another in the program dashboard, and she translated between them on the fly. She knew which version of "revenue" the CFO wanted and which version the board wanted. She knew that the attendance numbers from one system had not been reconciled with the other since 2022, and she adjusted.

The knowledge lived in her. It worked, barely, because she was brilliant and because humans are good at holding contradictions.

That era is ending.

Why This Matters More Now Than It Did Five Years Ago

The AI agents being deployed into every industry right now do not hold contradictions. They read what is in front of them and they answer the question.

When the data underneath is ambiguous, they do not flag it. They do not ask a clarifying question. They do not translate. They produce a confident, articulate, completely wrong answer, and they produce it in under a second. At scale. To your board.

The whole promise of agentic AI is that it can query your data and give you an answer. But an agent querying a confused data landscape does not produce confused answers. It produces confident wrong ones. And those are worse than no answer at all, because they feel right.

A clean data model is what makes AI reliable. It is the thing that tells the agent, and every human who touches the system, exactly what a client is, exactly how you count one, and exactly where the number lives. Without it, you are not doing AI. You are doing expensive guessing at unprecedented speed.

What a Data Model Actually Delivers

When we build a data model for a client, three things come with it.

The first is the map. A single diagram that shows the core dimensions, the core facts, and how they connect. Leadership looks at this and sees the shape of their own organization, often for the first time. It is usually the moment in an engagement where someone says, "I did not realize that is how this fits together."

The second is the tables themselves. The actual schemas, with field names, data types, keys, and the grain of each table specified in plain language. This is what the technical build runs on. Pipelines load into it. Dashboards read from it. Agents query it.

The third is the dictionary. Every field, defined in business terms. What it means. How it is calculated. Who owns it. What counts and what does not. This is the piece most consultants either skip or half-do, and it is the piece that determines whether the model survives after we leave. A dictionary is what lets a new hire onboard in a week instead of a quarter. It is what lets an AI agent answer correctly instead of plausibly.

Together, those three pieces are what I have started calling a Decision Data Model. The decisions leadership needs to make determine the metrics. The metrics determine the facts. The facts determine the dimensions. And the dictionary makes the whole thing legible to humans and machines at the same time.

Where This Fits in the Work

This is not a separate engagement. It is the part of the Foundation Sprint that makes everything else real.

When we define KPIs, we are defining what the facts need to measure. When we define metrics, we are defining how those facts are calculated and at what grain. When we design the dashboard architecture, we are deciding which slices of the model the dashboard exposes. The data model is the artifact that ties those decisions together and hands them cleanly to the build phase.

It is also the artifact that makes the handoff to AI agents actually work. In Building Your Decision Engine, the agents we build query this model. They know the grain. They know the definitions. They know what counts. Because we wrote it down, and we wrote it down in a form they can read.

Without a model, the Foundation Sprint produces strategy. With one, it produces something your team and your AI can both use on day one.

The Honest Truth

The reason most organizations skip the model is that it is not exciting. Nobody gets a standing ovation for a dimension table. Nobody puts a data dictionary on a board slide.

But the organizations that spend the two weeks to get this right stop arguing about which numbers are real. Their dashboards agree with each other. Their reports reconcile. Their AI agents give answers they can trust. And when a new leader joins, or a new system gets added, or a new question gets asked, there is a map to work from instead of a scramble.

I have come to believe this is the single most leveraged two weeks a leadership team can spend right now. Not because the deliverable is exciting, but because it is the artifact that makes every downstream investment finally mean something.

The dashboard is what people see. The model is what makes the dashboard true.

If your organization is about to invest in dashboards, reporting, or AI agents and nobody has sat down to build the model first, stop. The model is the thing. Everything else is built on top of it.


Aaron Buchanan, MPP, is the founder of Forte AI Solutions. We build the decision infrastructure that makes dashboards and AI actually work for small businesses and nonprofits. Book a discovery call to find out what your data model should look like.

Frequently Asked Questions
What is a data model?

A data model is the agreed-upon structure of an organization's core information: the entities it tracks (clients, programs, staff, etc.), the events and outcomes it measures (enrollments, donations, service hours, revenue), and the definitions that make each of those unambiguous. Every dashboard, report, and AI agent pulls from this model.

Why do AI agents need a data model to work?

AI agents do not hold contradictions the way humans do. When the data underneath is ambiguous, they produce confident wrong answers instead of flagging the ambiguity. A clean data model gives the agent a canonical source of truth, which is what makes its outputs reliable.

What is a Decision Data Model?

Forte's Decision Data Model is a three-part deliverable: the map (a diagram of dimensions, facts, and their relationships), the tables (schemas with field names, types, keys, and grain), and the dictionary (every field defined in business terms, with ownership). Together, they are the canonical map of the organization.

When should we build a data model?

Before you invest in dashboards, reporting, or AI agents. The model is the foundation those investments sit on top of. Building dashboards before building the model is how organizations end up with three dashboards that disagree with each other.

Ready to build your decision infrastructure?