Grounding copilots on governed metrics

A copilot that dumps table schemas into the prompt and asks the model to write SQL is not grounded. It is improvising. Grounding means the answer path can only touch certified metrics, so governance travels with the number instead of living as a hope in the system prompt.

datahashi gives copilots a narrow MCP surface: list what they may ask, describe a metric, run a structured semantic query. Humans in the console and agents on MCP use the same request shape. Neither path accepts client SQL.

What grounding is not

Grounding is not stuffing more DDL into context. Schema dumps invite the model to invent joins, skip refund filters, and read rows a policy was meant to hide. A longer “be careful” instruction does not close those gaps.

Grounding is also not a post-filter that reviews SQL the agent already wrote. By then the damage may already be in the warehouse plan. Governance has to be the request shape.

The certified path

Publish a YAML semantic model as an immutable artifact: entities, relationships, measures, metrics, and access rules validated together, then frozen as a version. Downstream copilots pin that version so mid-flight edits cannot silently change answers.

Grant the copilot a role that exposes named metrics and the dimensions they need, not raw measures. Bind the same row-level rules you already use for humans.

Connect the copilot over MCP. The tools are fixed:

• list_catalog - names and short descriptions the credential can see
• describe_metric - definition, unit, grain expectations, and allowed dimensions
• run_semantic_query - metrics, dimensions, filters, order, limit

None of those tools accept or return SQL. There is no warehouse escape hatch on the agent path.

How a turn should look

User: “What was average order value by region last quarter?”

The copilot calls list_catalog, finds the metric and dimension, optionally calls describe_metric, then calls run_semantic_query with the structured request. datahashi compiles fan-out-safe SQL inside your warehouse. The copilot sees rows and labels - not the SQL text, not a path around row-level rules.

If the user asks for something outside the model, the tools have nothing to offer. The copilot should refuse rather than improvise. A correct “I don’t have that certified metric” beats a plausible invention.

Inherit governance, do not re-implement it

Field grants, row-level rules, and cost ceilings apply on the server for every call. Metering records what the principal scanned. The thin semantic layer stays thin: transforms live in the warehouse; the model names certified metrics and decides who may ask.

REST, console, and MCP share the same Semantic Query object. That is how you prove grounding before you trust chat: run the identical request in the console and from the copilot against one pinned published version. Same metric names, same dimensions, same number.

Ship the bar, not the demo

Wire instructions that say: answer quantitative questions only through the six MCP tools; refuse when the catalog has no match. The instruction layer is hygiene. The hard guarantee is the tool schema - the copilot cannot widen a governed credential by asking nicely.

Rollups have shipped, but they do not promise a p99 latency SLO. No formal benchmark exists yet. Design the UX around certified answers and clear refusals, not unpromised speed.

Ground the copilot on the catalog. Let natural-language answers inherit governance instead of table dumps.