Semantic View in MIP, Part 1: Defining Business Semantics in the Data Engine

In the introduction to this series, we looked at a common problem: business definitions already exist, but every analytical consumer may have to rebuild them.

Revenue can be defined in a BI model, an ETL pipeline, a dashboard, or an ad hoc query. Add an AI agent, and the same definition may need to be reconstructed yet again.

If we want the executable parts of these definitions to live on the query path, the next question is practical: What must be defined in the data engine before a query is generated?

In MirrorShip Intelligence Platform (MIP), Semantic View provides a structured way to define, in the data engine, the contract that governs how AI agents interpret business operating data.

It describes the tables within a business domain, the relationships between them, the dimensions users can analyze, the metrics they can request, and the rules that must hold across every query.

The goal is not to encode every possible question in advance. It is to consolidate semantic information explicitly in advance, so that an AI agent, BI tool, application, or SQL user can assemble queries within the correct boundaries—reducing AI hallucinations caused by inferred relationships, calculations, or business rules.

Start with a business domain

A physical schema describes how data is stored.

It can show that an orders table contains o_custkey, o_totalprice, and o_orderdate. It may also show that a customer table contains c_custkey and c_name.

The schema alone, however, may not answer the questions that matter to an analytical consumer:

• Does o_totalprice represent revenue?
• Which customer key defines the relationship?
• Which order states should be included?
• Which date determines the reporting period?
• What does the business mean by “customer”?
• Which attributes can be grouped with a metric without changing its intended grain?

These are not merely naming questions. They describe how the business expects its data to be interpreted and queried.

A Semantic View consolidates this information around a defined analytical domain. For an order-analysis domain, the definition might include:

• Orders and customers as logical tables
• The key relationship between those tables
• Customer name and order date as dimensions
• Total revenue as a metric
• Business rules that must apply to every query
• Synonyms and descriptions that connect business language with the model

The result is a more structured analytical surface than the full physical schema.

From Physical Schema to a Defined Business Domain

Define the semantic structure

Consider a simplified order-analysis domain containing two physical tables:

• salesdb.orders
• salesdb.customer

The orders table is the analytical root. Each order refers to a customer through a customer key.

A Semantic View can organize this domain into tables, relationships, dimensions, metrics, and business-language metadata:

CREATE SEMANTIC VIEW salesdb.ordermetrics
TABLES
  orders AS salesdb.orders
    PRIMARY KEY oorderkey
    WITH SYNONYMS ('sales', 'purchases')
    COMMENT 'All customer orders',

  customer AS salesdb.customer
    PRIMARY KEY ccustkey
    WITH SYNONYMS ('client', 'buyer', 'account')
    COMMENT 'Customer master data'

RELATIONSHIPS
  ordtocust AS
    orders (ocustkey) REFERENCES customer

DIMENSIONS
  orders.orderdate AS oorderdate
    WITH SYNONYMS ('order date', 'purchase date', 'sale date')
    COMMENT 'Date the order was placed',

  customer.custname AS cname
    WITH SYNONYMS ('customer', 'client name', 'buyer name')
    COMMENT 'Full name of the customer',

  orders.orderstatus AS oorderstatus
    WITH SYNONYMS ('status', 'order state')
    COMMENT 'Order lifecycle status code'
    SAMPLE_VALUES ('F', 'O', 'P')

METRICS
  orders.totalprice AS SUM(ototalprice)
    WITH SYNONYMS ('revenue', 'sales', 'total sales', 'order value')
    COMMENT 'Total monetary value of all orders',

  customer.custcount AS COUNT(ccustkey)
    WITH SYNONYMS ('number of customers', 'customer count')
    COMMENT 'Count of customers'

COMMENT 'Order metrics with customer information'

AI_SQL_GENERATION
  'Focus on aggregated order metrics. Use the defined relationships,
   dimensions, and metrics when generating SQL.';

This definition contains the principal components of an executable semantic contract:

• TABLES identifies the physical data sources and assigns logical names.
• RELATIONSHIPS defines how those logical tables connect.
• DIMENSIONS defines attributes available for grouping and filtering.
• METRICS defines reviewed aggregate calculations.
• Comments, synonyms, and sample values connect technical elements with business language.
• AI_SQL_GENERATION provides domain-specific guidance for AI-assisted SQL generation.

Semantic View does not store another copy of the data. When queried, it is transparently inlined into the surrounding SQL as a derived subquery, using the topology defined in its RELATIONSHIPS clause.

Relationships carry meaning

A join is not merely a technical operation.

The selected join path affects which rows are combined, whether records are duplicated, and which grain the final result represents. A syntactically valid join can still produce a misleading metric.

Relationships therefore belong in the semantic contract.

In the example, the following declaration connects each order to its customer:

ordtocust AS
  orders (ocustkey) REFERENCES customer

Because the referenced customer table declares a single primary key, the referenced column can be resolved from the model. A query consumer does not need to reconstruct the relationship whenever it requests revenue by customer.

Semantic View also validates the overall relationship topology. Its tables and relationships must form a single connected snowflake with one root—typically the fact table—and every other table must be reachable from that root.

This moves an important structural check to definition time.

If unrelated roots are placed in the same model, no valid relationship path may exist between every metric and dimension. Rejecting that topology when the Semantic View is created helps prevent a later query from producing a cross product or an incorrect aggregation

Dimensions and metrics

Physical columns are necessary for execution, but analytical consumers typically work with dimensions and metrics.

A dimension answers questions such as:

• By which customer?
• In which region?
• During which year?
• For which product category?

A metric answers questions such as:

• How much revenue?
• How many orders?
• What was the average order value?
• What was the closing balance?

In the example, orderdate maps the physical order date into a defined analytical dimension:

orders.orderdate AS oorderdate

Likewise, totalprice is not simply a renamed field. It defines an aggregate calculation:

orders.totalprice AS SUM(ototalprice)

Once these elements have been defined, query consumers can request a reviewed business concept rather than repeatedly reconstructing its transformation and aggregation logic from raw columns.

The definition still requires deliberate metric design. The data team must determine whether revenue is gross or net, whether refunds are deducted, which transaction states qualify, and which date establishes the reporting period.

Semantic View makes those decisions explicit and reusable in the data-engine query path.

Keep mandatory rules in-path

Some business conditions should not depend on whether a query author remembers to add them.

Examples include:

• Excluding test records
• Removing soft-deleted rows
• Limiting analysis to finalized transactions
• Applying tenant or business-unit scope
• Excluding invalid operational states

A view-level FILTER defines a condition that applies to every query against the Semantic View. If a query supplies its own WHERE condition, the view-level filter is combined with it using AND.

A view-level filter differs from a rule written only in documentation or a prompt.

Documentation can tell an AI agent to exclude invalid data, and a prompt can remind it to add the condition. The generated query may still omit or reinterpret that instruction.

When the condition is defined in the Semantic View, it becomes part of the query-expansion path.

This does not mean that every governance requirement should be implemented as a Semantic View filter. Access control, data quality, and broader policy enforcement remain separate responsibilities.

A global filter has a narrower role: preserving the row-level business conditions that belong to a particular analytical domain.

Add business vocabulary

A technically valid semantic model must also connect with the language people use.

A user may say “sales,” “revenue,” “order value,” or “bookings” while referring to related—but not necessarily identical—concepts. The user may ask for “clients” even though the physical table is named customer.

Semantic View supports several forms of metadata for mapping business language to technical definitions:

• COMMENT explains what an element represents in business terms.
• WITH SYNONYMS records alternative expressions, abbreviations, and domain terminology.
• SAMPLE_VALUES provides representative values for facts, dimensions, or metrics.
• View-level AI instructions provide domain rules and disambiguation guidance.

Consider an order-status column that stores codes such as F, O, and P.

A user is unlikely to ask: How many orders have status F?

The user is more likely to ask: How many fulfilled orders did we receive?

The corresponding dimension can provide both a business description and representative stored values:

orders.orderstatus AS oorderstatus
  WITH SYNONYMS ('status', 'order state')
  COMMENT 'Order lifecycle status code'
  SAMPLE_VALUES ('F', 'O', 'P')

Comments and synonyms help identify the relevant semantic element. Sample values help the AI understand the literal format stored in the data—for example, that a filter may need the code F rather than the word fulfilled.

Sample values are metadata hints. They neither filter the underlying data nor restrict the values that a query can return.

What Semantic View Defines Before Query Time

Define more, infer less

AI still has an important role in this workflow.

It interprets the user’s language, identifies the analytical intent, and selects the relevant dimensions, metrics, and query-specific filters.

But it should not need to invent information that the data team can define and review in advance.

Semantic Definition vs Query Time

The more semantic information the system consolidates before query time, the less structural business logic an AI agent must infer while generating SQL.

The objective is not to eliminate probabilistic reasoning. It is to apply that reasoning to the user’s intent and natural-language variation—not to relationships, metric formulas, or business rules that can be defined and reviewed beforehand.

A contract in the engine

Semantic View can be understood as an information contract between AI agents and business operating data.

The contract states:

• Which physical data belongs to the domain
• How the data is related
• Which analytical concepts are available
• How important metrics are calculated
• Which row-level rules must always apply
• Which business terms refer to those concepts

Different analytical consumers can work from the same defined surface.

An AI agent can select metrics and dimensions. A BI workflow can query the model through a table-like interface. A SQL user can inspect or extend the resulting query. An application can build against a more stable analytical contract than a collection of raw tables.

Semantic View does not eliminate every semantic model elsewhere in the data stack. External systems can continue to support authoring, collaboration, governance, and version control.

Its role in MIP is specific: to consolidate an executable semantic representation in the data-engine query path.

That is the first step—define business meaning before requiring every analytical consumer to reconstruct it.

In Part 2, we will follow this contract into execution: How does a semantic request become SQL, and how can a data team inspect what will actually run?

Next: Semantic View in MIP, Part 2: From Semantic Intent to Executable SQL