Codd AI
AI & Analytics

Why Runtime Context Is the Wrong Foundation for Enterprise AI Analytics

Why Runtime Context Is the Wrong Foundation for Enterprise AI Analytics

Over the past two years, enterprise analytics has entered a new phase. Dashboards are no longer the center of innovation. The industry's attention has rapidly shifted toward:

  • conversational analytics,
  • natural language query (NLQ),
  • AI copilots,
  • text-to-SQL interfaces,
  • and AI-powered business intelligence.

The promise is compelling. Business users can now ask questions in plain English and receive instant answers, charts, summaries, and insights without needing SQL expertise or waiting on analysts.

On the surface, it feels like the analytics industry has finally solved the accessibility problem.

But beneath the excitement, a deeper architectural issue is emerging.

Most AI analytics systems still do not truly understand the business. They rely heavily on prompts to provide the right context to correctly understand and interpret the questions and responses.

The problem is not that large language models cannot generate answers. The problem is that most conversational analytics systems attempt to assemble business context dynamically at runtime, after the question is already asked.

That may work for demos and isolated use cases. But what do we do in a business where dozens of users independently ask questions and, through their prompts, provide slightly differing context?

Right now there is a rush from vendors to add copilots and conversational style interfaces, but the future of conversational analytics will be determined by which platforms establish the most trusted and governed contextual foundation before users ever ask a question.

In last week's blog I explored why so many AI projects stall and the need for comprehensive context (database, business rules and logic, and more). In this blog I will dig a little deeper into the differences between context-through-prompts at runtime and a true governed contextual semantic layer.

Current Copilots Solved Language, But Not Context

The current generation of copilots on AI analytics platforms has largely focused on improving interaction and user experience.

Users can:

  • type questions in natural language,
  • generate SQL automatically,
  • summarize dashboards,
  • create visualizations,
  • and interact conversationally with data.

This is an important advancement. But much of the market has confused language fluency with business fluency.

A system may understand the sentence:

"What was customer churn last quarter?"

while still failing to understand:

  • how the organization defines churn,
  • which customers should be excluded,
  • whether term contracts count,
  • which business unit owns the metric,
  • or which source system is considered authoritative.

In enterprise analytics, these distinctions matter enormously, and in traditional BI tools they live in the minds of analysts and are translated into dashboards and reports upon user request.

And this is where many copilots and AI analytics systems begin to struggle. Because the workaround is to provide that missing context at runtime, or as referred to earlier, context-through-prompts.

The Runtime Context Problem

Most conversational analytics systems today operate using what could be called a runtime context model.

The workflow generally looks something like this:

  1. User asks a question
  2. System retrieves technical metadata
  3. Optional semantic definitions or metric descriptions are loaded
  4. Prompts are augmented with contextual text
  5. The LLM generates an answer

At first glance, this appears reasonable. But this architecture creates a hidden scalability problem.

Why? Because business meaning is being reconstructed dynamically for every interaction.

Instead of establishing a governed and reusable understanding of the business upfront, the system attempts to infer or assemble meaning during runtime.

This often leads to:

  • inconsistent interpretations,
  • semantic drift,
  • duplicated business logic,
  • repeated metric engineering,
  • and growing governance complexity.

Many modern platforms partially address this by allowing users to define business metrics or semantic descriptions. Platforms such as:

  • Databricks Genie with Metrics Views,
  • Snowflake Semantic Views,
  • Tableau Pulse metrics,
  • and dbt metric layers

all move in this direction. But in many cases, the business understanding is still created manually on a metric-by-metric basis.

The result is significant operational overhead. Organizations repeatedly define:

  • the same business concepts,
  • the same relationships,
  • the same filters,
  • and the same logic

across hundreds or thousands of metric definitions. Much of this is encoded manually in YAML files, semantic descriptions, or prompt augmentations.

The industry is effectively governing metrics individually rather than governing the business concepts that generate the metrics.

That distinction matters. Because metrics are outputs. Business understanding is the foundation.

Why Query-Time Context Does Not Scale

The limitations of runtime context become increasingly visible as organizations attempt to scale conversational analytics beyond small pilots. Several problems emerge quickly.

Repeated Semantic Engineering

Every metric becomes its own semantic project. Teams repeatedly encode:

  • filters,
  • business rules,
  • definitions,
  • exclusions,
  • and context

for each individual metric. This creates enormous duplication. A concept like "active customer" may be recreated dozens or hundreds of times across the analytics environment.

Semantic Drift

Over time, definitions inevitably diverge. One team updates a metric logic definition. Another forgets to update a related metric elsewhere.

Eventually:

  • dashboards disagree,
  • copilots return conflicting answers,
  • and trust begins eroding.

Governance Complexity Explodes

When governance occurs at the metric layer, the number of governed objects becomes unmanageable. Every metric requires:

  • validation,
  • certification,
  • lineage,
  • ownership,
  • documentation,
  • and maintenance.

As organizations scale AI analytics initiatives, this quickly becomes operationally expensive.

Runtime Ambiguity Remains

Even with semantic descriptions attached to metrics, the AI system is often still resolving meaning dynamically during execution. That means interpretation can still vary depending on:

  • prompt wording,
  • retrieved context,
  • or runtime retrieval quality.

In enterprise analytics, that variability is dangerous. Executives do not want "mostly correct" financial metrics. They want governed consistency.

The Governed Context Alternative

This is where a fundamentally different architectural philosophy is emerging.

Instead of constructing business understanding dynamically during query execution, a governed contextual semantic layer establishes certified business meaning before runtime. It defines the comprehensive business and technical context as a core foundation before queries are run.

This is the approach taken by platforms like Codd AI.

The idea is straightforward but powerful. Rather than starting with metrics, the process starts with business understanding itself.

The workflow looks more like this:

  1. AI generates an analytical ontology or conceptual model
  2. Business concepts and relationships are identified
  3. Human analysts or stewards review and certify the ontology
  4. The physical data model is generated
  5. Technical and business metadata are unified
  6. Human validation occurs again
  7. The platform auto-generates an initial set of business metrics
  8. Metrics are reviewed and certified before exposure to decision makers

This changes the role of the semantic layer entirely. The semantic layer is no longer just:

  • a collection of metric definitions,
  • technical metadata,
  • or dashboard modeling artifacts.

It becomes a governed contextual foundation for enterprise AI reasoning. That is a much more strategic capability.

Why Ontology Matters More Than Metrics

One of the biggest misconceptions in the current AI analytics market is the belief that metrics are the primary governance object.

They are not. Metrics are outputs. Ontologies define meaning.

A governed ontology establishes:

  • concepts,
  • relationships,
  • hierarchies,
  • business vocabulary,
  • semantic dependencies,
  • and contextual understanding.

Once those concepts are certified, metrics can be generated automatically in a much more consistent and accurate manner. This dramatically reduces:

  • duplicated logic,
  • repeated YAML engineering,
  • semantic inconsistencies,
  • and governance overhead.

More importantly, it gives AI systems a reusable understanding of how the business operates.

A metric is only as trustworthy as the business ontology beneath it.

Without a governed ontology, conversational analytics systems are effectively improvising business interpretation at runtime. That may work occasionally for exploratory analytics. It is not an ideal foundation for trusted enterprise decision intelligence.

Human-in-the-Loop Is Not a Weakness, It Is the Trust Layer

One of the more dangerous narratives emerging in AI is the idea that automation alone creates intelligence. In enterprise analytics, that assumption is flawed.

Trust does not come from removing humans from the loop. Trust comes from certifying what AI learns before it reaches decision makers.

This is one of the most important differences in the governed contextual semantic layer approach.

AI accelerates:

  • ontology generation,
  • semantic modeling,
  • metadata enrichment,
  • relationship discovery,
  • and metric creation.

But humans still certify:

  • business meaning,
  • conceptual accuracy,
  • governance alignment,
  • and analytical trustworthiness.

This creates a scalable trust architecture. The objective is not to eliminate governance. The objective is to operationalize governance more efficiently through AI-assisted semantic engineering.

That is a fundamentally more enterprise-ready approach than relying purely on prompt engineering or runtime retrieval.

The Future of Conversational Analytics

The analytics market is now entering an important transition period.

The first wave of conversational analytics focused heavily on:

  • interfaces,
  • copilots,
  • prompt experiences,
  • and text-to-SQL generation.

The next phase will focus on something much more important: governed business understanding.

The market is gradually splitting into two architectural approaches.

Approach One: Runtime Context AI

  • Prompt-driven
  • Query-time semantic injection
  • Metric-level governance
  • Dynamic interpretation
  • High manual semantic engineering overhead

Approach Two: Governed Contextual Intelligence

  • Certified ontologies
  • Governed semantic foundations
  • Reusable business understanding
  • AI-assisted semantic generation
  • Human-certified context
  • Consistent analytical reasoning

The second approach is ultimately far more scalable for enterprise environments. Because enterprise trust cannot depend on reconstructing business meaning differently for every query.

The Real Future of AI Analytics

The future of AI analytics will not be won by the platforms with the best chatbot demos. It will be won by the platforms that establish the strongest contextual foundation for business understanding.

AI analytics does not become trustworthy at query time. Trust is established long before the first question is ever asked.

And that may ultimately become the defining difference between experimental AI copilots and truly business-fluent enterprise AI systems.

About Codd AI

Codd AI is a leading provider of AI analytical platforms. Unlike many other approaches in the market, Codd AI has been designed from the ground up for the world of generative AI to solve exactly the problems explored in this blog. It uses AI to automate and speed up semantic modeling and metrics creation (with human review), and then delivers that contextual semantic understanding to AI agents and analytical users, whether in chatbots, BI tools, embedded agentic flows, or your Slack and Teams interface.

If you are interested in learning more about us, visit us at www.codd.ai or schedule a quick conversation with our founders.