Spec-Driven Data Modeling -Part 1 They Hypothesis
It’s time to rethink the approach to data modeling in the age of AI
The Hypothesis
Over the past several months, I’ve been exploring an idea inspired by the principles of Spec-Driven Development. The idea is surprisingly simple: if software can be built from an approved specification, why can’t enterprise data models?
That question eventually became what I call Spec-Driven Data Modeling.
At its core, Spec-Driven Data Modeling is my hypothesis that business understanding, not prompts, data models, or code should become the authoritative source of enterprise data modeling. Every downstream artifact, whether created by an architect or generated by AI, should be a faithful transformation of that understanding rather than another independent interpretation of the business.
This article is the first in a two-part series. In this article, I want to explain why I believe this idea deserves exploration. In Part 2, I’ll share the proof of concept I built to determine whether the hypothesis actually works.
I didn’t arrive at this idea because I was looking for a new modeling methodology. I arrived at it because of something I learned almost thirty years ago that has quietly shaped every project I’ve worked on since.
A Logical Data Model Was Never About the Database
Early in my career, my mentor Bill spent three days teaching me data modeling in the least glamorous place imaginable, a small break room with two vending machines (yes vending machines existed). We were working on a project to move information from AutoCAD drawings into a database, and I assumed he was going to teach me database design.
Instead, he started asking questions about the business.
As I described how the business worked, Bill translated those conversations into entities, attributes, and relationships. Occasionally he would stop, challenge an assumption, erase part of the model, and redraw it as our understanding improved. Somewhere during those three days I realized he wasn’t designing a database at all.
He was discovering business context.
When we finished, something remarkable happened. I realized I no longer needed my interview notes. The logical data model itself explained how my area of the business worked. It captured its language, concepts, relationships, and business rules in a way that anyone could understand.
That experience fundamentally changed how I viewed data modeling. To me, a logical data model was never a database design.
It was the blueprint of business concepts.
Over the next three decades I worked across operational systems, analytical platforms, governance initiatives, semantic layers, and, most recently, artificial intelligence. The technologies changed dramatically, but one observation never did. The projects that consistently succeeded weren’t necessarily the ones using the newest technology. They were the ones that invested the time to understand the business before they began implementing data solutions.
Unfortunately, I believe that’s the discipline we’ve gradually moved away from.
We Never Stopped Needing Business Understanding. We Just Moved It.
As I look back over the last thirty years, I don’t believe data modeling started to disappear because it became less valuable. In many ways, our industry has never been stronger. We’ve embraced Agile, cloud computing, modern data platforms, ELT solutions, and now artificial intelligence. Each of those advancements solved real problems and helped us deliver data solutions faster than ever before.
What changed wasn’t the need to understand the business.
What changed was when we chose to do it.
Somewhere along the way, we began treating business discovery as something that slowed projects down instead of recognizing it as the foundation that made projects successful. We convinced ourselves that we already knew what the business needed, or that we could figure it out as we built the data solution. As delivery cycles accelerated, conversations about business concepts, terminology, ownership, and business rules gradually gave way to conversations about implementing point solutions.
The irony is that we never eliminated the work.
We simply postponed it.
Instead of investing the time to establish a shared understanding before implementation, we rediscovered the business later through testing, production issues, governance initiatives, semantic layer projects, and endless conversations about why two reports produced different answers to the same question. The effort never disappeared; it simply became far more expensive because end to end solutions had already been built on top of assumptions that were never challenged.
I don’t believe this happened because data professionals stopped caring about good design. I think it happened because our industry became exceptionally good at building solution quickly and, over time, began assuming that understanding the business would naturally emerge during implementation.
Sometimes it did.
Often it didn’t.
The consequence wasn’t just inconsistent data structures or poorly named tables. It was something much more fundamental. Different applications began representing the same business differently because each team interpreted the business independently. Logical models, operational databases, analytical models, semantic layers, data pipelines, and documentation all became separate interpretations of the organization rather than faithful representations of a shared understanding.
For years, I accepted that as the reality of modern data solution development.
Then artificial intelligence arrived, and for the first time I realized the problem wasn’t just affecting architects anymore.
It was about to affect every artifact AI was asked to generate.
AI Didn’t Create the Problem. It Exposed It.
Like many people, my first reaction to generative AI was excitement. I began asking it to generate logical data models, physical schemas, SQL, documentation, and eventually complete data solutions. The results were often remarkable, and like everyone else, I found myself learning how to write better prompts to improve the quality of the output.
Get Keith Belanger’s stories in your inbox
Join Medium for free to get updates from this writer.
Then I noticed something that completely changed my perspective.
The quality of the architecture had very little to do with AI.
It had everything to do with the quality of the business understanding I provided.
If my understanding of the business was complete, AI produced impressive results. If it wasn’t, AI didn’t know that something important was missing. It simply generated the most likely interpretation based on the information it had been given. That isn’t a flaw in artificial intelligence. It’s exactly what these models are designed to do.
The problem was that I had been asking AI to compensate for business understanding that had never been established in the first place.
That realization led me to a much more interesting question.
Instead of asking how to write better prompts, should we be asking how to provide AI with a better understanding of the business before it generates anything at all?
The Question That Changed My Thinking
Around the same time I was coming to these conclusions, the company I work for, DataOps.live, now part of FICO, began adopting the principles of Spec-Driven Development. Listening to those discussions, I found myself fascinated by an idea that seemed almost obvious once it was stated.
Instead of allowing software to become the primary expression of the system, Spec-Driven Development places the specification at the center of the process. The specification becomes the authoritative description of what the software should do, while implementation becomes a faithful transformation of that specification.
As I listened, I couldn’t stop thinking about enterprise data modeling.
If that philosophy makes sense for software, why couldn’t it make sense for data?
The more I reflected on that question, the more I realized I had been accepting something for most of my career without ever challenging it. We have traditionally treated the logical data model as the first architectural artifact. Yet every logical model depends on work that has already been completed. Before the first entity is identified or the first relationship is drawn, someone has already interviewed business experts, reconciled terminology, clarified business rules, and developed an understanding of how the organization actually operates.
The logical data model doesn’t create that understanding.
It represents it.
That realization caused me to rethink where data architecture actually begins. Perhaps the logical model isn’t the first artifact at all. Perhaps the first artifact should be an approved Business Specification that captures the business vocabulary, concepts, business rules, events, ownership, and objectives before anyone attempts to design a database, write code, or generate a semantic model.
Once I began looking at architecture through that lens, everything else started to fall into place. Logical models, operational databases, analytical models, semantic layers, APIs, documentation, and even AI-generated artifacts no longer appeared to be independent architectural deliverables. They became successive transformations of the same business understanding, each optimized for a different purpose but all traceable back to a single authoritative source.
That observation eventually became what I now call Spec-Driven Data Modeling.
The Hypothesis
Every meaningful idea starts as a hypothesis.
Mine is straightforward.
Business understanding, not prompts, data models, or implementation should become the authoritative source of enterprise data model.
If that hypothesis is correct, then every downstream artifact should become a faithful transformation of an approved Business Specification rather than another independent interpretation of the business. Logical data models should be generated from that specification. Operational and analytical models should be generated from the logical model. Semantic layers, APIs, documentation, and increasingly AI-generated artifacts should all trace their lineage back to the same approved understanding of the business.
Artificial intelligence plays an important role in that vision, but not the one many people expect.
I don’t believe AI should invent business knowledge.
I believe it should faithfully transform business knowledge that has already been reviewed, challenged, and approved by the people who understand the business best.
That distinction is the foundation of the hypothesis.
Of course, every hypothesis sounds reasonable until someone attempts to prove it. Rather than debating the idea, I decided to build a complete proof of concept. I created a fictional company, developed a Business Specification, defined a transformation methodology, and challenged AI to generate every major architectural artifact while following one uncompromising rule:
If the business hasn’t said it, AI doesn’t get to invent it.
Whether that experiment validated the hypothesis is the subject of Part 2.
There I’ll walk through the proof of concept, the methodology that emerged, what surprised me, what didn’t work as expected, and why I believe this conversation is only beginning.
My goal isn’t to convince the industry that Spec-Driven Data Modeling is the future.
My goal is much simpler.
I want to start a conversation.
I believe AI gives us an opportunity to rethink where enterprise data architecture begins, and this is my contribution to that discussion. I’ve shared the hypothesis. In Part 2, I’ll share the proof of concept that tested it.
After that, I’d genuinely like to hear what the community thinks.
