Context Is the New Schema

In the early days of business intelligence, organizations struggled with fragmented data, inconsistent reporting, and decisions that moved more slowly than the problems they were meant to solve. The breakthrough came with dimensional modeling. Ralph Kimball gave us a structured way to transform raw operational data into something meaningful and query-friendly. It was not just a technical advance, but a trust advance. Analysts could finally explain where a number came from.

Today, AI faces a similar inflection point. The challenge is no longer about building powerful models, but about making them reliable, interpretable, and enterprise-ready. That is where context engineering enters.

What Dimensional Modeling Actually Solved

Before dimensional modeling, data warehouses were technically functional but practically opaque. Database schemas and entity-relationship diagrams captured reality, but were not designed for human consumption. A business analyst asking "how did sales perform in Q3 across regions?" would face a maze of joins, null values, and inconsistent granularity.

Dimensional modeling reoriented the design question. Instead of asking "How do we store data accurately?" it asked, "How do we make data usable for decisions?" The star schema was the answer, where facts were at the center and dimensions at the edges. This led to queries that ran fast and read like plain English. Not only did it help improve performance, but it also elevated stakeholders' confidence while viewing the report. When a number appeared in a report, they could trace it to a dimension and a fact. The traceability, governance, and structure led to increased trust, as a result of which the adoption of dimensional modeling accelerated.

The AI Problem Looks Familiar

Large language models operate on context. Everything a model knows in a given interaction, such as the conversation history, retrieved documents, system instructions, memory summaries, and tool outputs, lives inside a context window. But that window is finite. What goes into it, how it is structured, and in what order it appears determine what the model produces. Most enterprise AI deployments treat context as an afterthought. Prompts are written ad hoc, retrieved chunks are dumped in without prioritization, and system instructions accumulate over time like unreviewed backlog tickets. The result is a model that is technically capable but operationally unreliable. This is exactly where BI was before dimensional modeling. The engine worked, but the design around it did not.

Context Engineering as a Discipline

Context engineering is the deliberate design of what enters a model's context window, in what form, at what point, and why. It is more than prompt engineering and retrieval augmented generation. It is the end-to-end discipline of structuring information flow so that the model receives what it needs, at the right level of detail, without noise and without gaps.

Think of it through the dimensional modeling parallel. A fact table in a star schema contains only what is needed for measurement, with no redundancy and ambiguity. Dimension tables provide the context that makes those facts interpretable. The grain is explicit, and relationships are clean. A well-designed context window works the same way. The core task is the fact. Supporting documents are the dimensions. Memory and history provide the time dimension. Tool outputs provide the event dimension. When you design context this way, the model does not have to work to disambiguate. It can focus computational capacity on reasoning rather than reconstruction.

Four Parallels

The first parallel is granularity management. In dimensional modeling, defining the grain of a fact table is the most consequential design decision. In context engineering, deciding the granularity of retrieved chunks has the same consequence. If the grain is too coarse, the model receives irrelevant noise. And if it is too fine, it loses semantic coherence. Getting this right should be a design choice.

The second parallel is the separation of concerns. Dimensional models separate facts from dimensions because they serve different purposes. Context engineering benefits from the same logic. System instructions define behavior. Retrieved content provides knowledge. Conversation history provides the state. Tool results provide fresh data. Mixing these without structure produces the AI equivalent of a normalized warehouse, which is technically correct, but operationally painful.

The third parallel is reproducibility. A dimensional model produces the same result for the same query every time. That is what makes reporting trustworthy. Context engineering must achieve the same guarantee. If two users ask the same question and receive different answers because different content was retrieved or differently ordered, enterprise adoption fails.

The fourth parallel is governance through structure. You cannot audit what you cannot trace. Dimensional models made lineage possible. Context engineering must do the same. Which documents were retrieved? What was truncated? What instructions were active? Enterprises that cannot answer these questions will struggle to deploy AI in regulated or high-stakes environments.

The organizations that succeeded with BI did not win because they had better databases. They won because they invested in the layer between raw data and business decisions. They hired data modelers. They built naming conventions and governance councils, and treated structure as infrastructure. 

Enterprise AI teams are at the same crossroads. The teams investing in context engineering, building retrieval pipelines with explicit chunking strategies, designing context windows as structured artifacts, tracking what enters each interaction and why, are building the equivalent of a well-governed data warehouse. The teams skipping this step are building the equivalent of a reporting system where every analyst writes their own SQL against a production database. It works for some time and might not scale for enterprise-level adoption plays

The Emerging Toolkit

Just as dimensional modeling spawned tooling such as dbt for transformation, Kimball's bus architecture for integration, and slowly changing dimensions for historical accuracy, context engineering is building its own ecosystem. Frameworks like LlamaIndex and LangChain provide scaffolding for retrieval and context assembly. Observability platforms like LangSmith give visibility into what entered the context window and how the model used it. Prompt management tools like PromptLayer bring version control and lineage to instruction design. These tools are maturing fast, but the discipline around them is still forming. 

Nevertheless, the organizations that define their own context engineering standards now, such as their own grain definitions, own retrieval governance, and own context window schemas, will be in a similar position to the data teams that adopted Kimball's methodology early.  They will have a structural advantage that compounds over time.

Trust Is the End Goal

Dimensional modeling was not just about schemas or star tables; it was about making data trustworthy enough to run a business on. When an executive trusted a dashboard, it was because a data engineer had made certain design decisions that ensured the numbers were correct and trustworthy. Context engineering carries the same responsibility for AI. When an enterprise deploys an AI agent, trust does not come from the AI agent alone. It comes from the discipline applied to everything the AI agent is given to work with.

We are in the early phases of context engineering as a formalized discipline. The frameworks and standards are emerging. The teams that treat context as a design problem rather than a configuration problem will build AI systems that are not just powerful, but reliable. And in the enterprise, trust is the only currency that matters.