Analytics Design & Architecture in the AI Era•Part 2 of 10

Designing for the Machine Reader: Why Your Data Model Needs a New Audience

January 8, 2026

Opening Scene

Imagine a beautiful old library. Every book is shelved by a librarian who knows the place by heart. There’s a card catalog, but honestly, half the regulars don’t even use it — they just ask the librarian, who knows that “the gardening section” really means three different shelves, that the travel books are filed by continent except for one weird exception from 1987, and that “ask for the blue folder” means something only if you already know what you’re asking about.

This works beautifully — as long as everyone walking in is a human who can ask a follow-up question.

Now a new kind of patron walks in: a tireless robot assistant that can read every card in the catalog in seconds, but can’t tag along after the librarian, can’t pick up on a raised eyebrow, and definitely can’t intuit that “the blue folder” means anything at all. If the catalog isn’t actually accurate and complete, the robot won’t politely ask — it will confidently hand someone the wrong book and move on like nothing happened.

That’s exactly what’s happening inside data teams right now. Your data model is the library. Your dashboards and reports are the literate, infer-everything human regulars. And AI is the new patron who only has the catalog to go on — nothing else.

In Plain English

A data model is just the way your data is organized and labeled — like how a library organizes books by subject, author, or call number. For years, that organization only had to be “good enough” for human analysts, who could fill gaps with memory, guesswork, and asking around.

AI systems can’t fill those gaps the same way. They read what’s written down — table names, column descriptions, business definitions — and take it at face value. If your “catalog” has gaps, contradictions, or tribal knowledge baked in, an AI won’t notice something’s off. It will just give a confident, wrong answer.

The Old Way

In the traditional setup, the data model was designed almost entirely around one kind of reader: a human analyst who would eventually sit down and explore it.

  • The librarian is the analyst — someone who has built up months or years of memorized context about what each table and column really means, beyond what’s documented.
  • The card catalog is your data dictionary or schema documentation — often incomplete, sometimes outdated, but tolerable because the librarian is there to bridge the gaps.
  • The shelving system is your schema design — star schemas, naming conventions, table relationships — built more for query performance and human intuition than for airtight clarity.
  • Word of mouth (“ask Dave, he knows what that field actually means”) is the unofficial documentation layer every team secretly runs on.

This worked because the gap between “what’s written down” and “what’s actually true” was patched, every single day, by humans who knew better. Nobody questioned how much weight that informal patching was carrying — until something showed up that couldn’t do the patching itself.

What’s Changing (and Why AI Is the Reason)

1. The new patron can’t ask the librarian a follow-up question — not really. An AI agent generating a query or a summary works from what’s actually documented: table names, column descriptions, defined business metrics. It doesn’t know that “ask Dave” is a step in the process, because that step was never written down anywhere it could read.

2. Confident wrong answers replace “I don’t know.” A human analyst who hits a confusing, undocumented field usually pauses and asks someone. An AI model, by contrast, will often produce a fluent, well-formatted, wrong answer rather than visibly struggle. The library’s catalog gaps used to cause occasional confusion; now they cause confidently delivered misinformation.

3. Scale changes what “good enough” means. One librarian patching gaps for a steady trickle of regulars is manageable. A tireless robot patron reading the entire catalog cover to cover, instantly, and being asked questions by hundreds of people through it, multiplies the cost of every gap, contradiction, and stale entry by a huge factor.

This is why metadata — descriptions, definitions, lineage, business context — is graduating from “nice documentation” to load-bearing infrastructure. It’s not a courtesy for new hires anymore. It’s the only thing standing between your AI system and a wrong answer delivered with total confidence.

The Metaphor, Fully Extended

The Library (Metaphor) The Architecture (Technical)
The library itself Your data warehouse / lakehouse
Books on shelves Tables and columns
The shelving system Schema design (how tables and fields are structured and related)
The card catalog Your data dictionary / documentation layer
The experienced librarian The human analyst, who fills gaps with memory and context
“Ask Dave, he knows” Tribal knowledge — undocumented business logic living in people’s heads
A new tireless robot patron An AI agent or LLM querying your data
A catalog card with a vague or missing description An undocumented or ambiguously named column
The robot confidently handing over the wrong book An AI model producing a fluent, confident, but incorrect answer
Rewriting the catalog so anyone — human or robot — can use it without help Building a semantic layer: a precise, well-defined, machine-readable translation of your data model

For Beginners: What to Actually Do

  • Start treating column and table descriptions as real work, not paperwork. If you’re naming a field or writing a description, write it as if the next reader has zero context and can’t ask you anything — because increasingly, that’s literally true.
  • Notice your own “ask Dave” moments. Every time you find yourself asking a coworker what a field really means, that’s a gap in the catalog. Writing the answer down, even briefly, is one of the highest-leverage things a junior analyst can do right now.
  • Get curious about the semantic layer, even if you don’t own it. Tools like metric stores or semantic layers (dbt’s semantic layer, Cube, LookML, etc.) are becoming the new “catalog that actually works.” Understanding how they’re built will matter more over time than knowing one specific BI tool.

For Practitioners and Leaders: The Deeper Layer

  • A semantic layer is not optional infrastructure anymore — it’s the contract between your data and every consumer of it, human or AI. Investing in precise, centrally-defined metrics and entities pays off far beyond AI use cases, but AI is what makes the cost of skipping it visible and painful fast.
  • Documentation needs to move from “descriptive” to “prescriptive.” A column comment that describes what a field currently contains is less useful than a definition that states what it’s supposed to mean — including edge cases, exceptions, and known data quality issues. AI systems benefit enormously from explicit caveats that a human would have absorbed through experience.
  • Treat documentation debt as a real, trackable liability. Just as you’d track technical debt in code, consider tracking “semantic debt” — undocumented metrics, ambiguous fields, conflicting definitions across teams — as something with a real cost, now measurable in AI errors rather than just analyst confusion.
  • Don’t outsource this entirely to AI either. It’s tempting to have an AI model generate documentation automatically. It can help draft it, but the actual business meaning — what a metric should mean, what counts as an edge case — still requires human judgment and sign-off. The catalog needs a human editor, even if a robot helps write the first draft.

Quick Recap

  • Data models were historically designed for human readers who could fill gaps through memory and conversation — AI readers can’t do that.
  • When documentation is missing or ambiguous, AI doesn’t ask for help — it answers anyway, confidently and often incorrectly.
  • This makes metadata and semantic layers core infrastructure, not optional polish.
  • Good documentation should be prescriptive (what something should mean, including exceptions) rather than just descriptive.
  • Fixing “tribal knowledge” gaps benefits human analysts as much as AI systems — this is overdue work, not new busywork.

Where This Fits in the Series

Article 1 introduced the shift from a one-way data stack to a connected fabric where AI is a new kind of traveler through your architecture. This article zoomed into the “street signs” of that fabric — the data model and metadata that both humans and AI rely on to navigate. Next, in Article 3, we’ll follow the data itself through the pipeline and look at how the cleaning and transformation step is evolving — from ETL into something more like ETA: Extract, Transform, Augment.