Skip to main content

Metrics that aren't emitted

TL;DR

Why Context Engineering Studio holds some metrics back from a deployed engine, where those metrics are still available, and what happens when CES repairs a metric automatically to meet an engine requirement.

Connect

Your semantic model can hold more metrics than a target engine can accept. When that happens, Context Engineering Studio (CES) leaves the metric out of what it sends to that engine and tells you which ones and why.

On the Overview tab, the derived metrics count carries a not emitted badge showing how many were held back. The agent lists them under Not emitted (with reasons) when the build finishes.

Nothing is deleted. A metric that isn't emitted stays in the canonical model in Atlan.

Why metrics aren't emitted​

The usual reason is a filtered metric: a metric whose definition includes a condition, such as pipeline value counted only for deals in the negotiation stage.

Some engines can't represent a conditional filter on a metric. Sending one as a plain aggregate drops the condition and returns the wrong number, so CES leaves the metric out instead.

These metrics remain in the canonical model and are emitted to engines that support filtered metrics natively.

Automatic repairs​

Some mismatches CES can fix on its own, and it reports each one.

The usual case is a metric defined as a bare column reference where the engine requires an aggregate. Snowflake Cortex Analyst is one such engine. CES wraps the reference in SUM(...) and reports the change. This changes how the metric is written for that engine, not what it measures.

Repaired metrics appear alongside the ones CES held back, so you can see every change before you deploy.

note

CES validates against the target engine where it can. When live validation isn't available for your connection, the report covers what CES found on its own, and the engine may flag more once the model is live. Open the deployed model in the engine to check.

What to do about it​

Read the reasons the agent gives before you deploy. For each metric that wasn't emitted, you have three options:

  • Accept it. The metric stays in the canonical model and reaches engines that can represent it. Business users on the deployed engine won't see it.
  • Redefine it. Rewrite the metric without the conditional filter. Exposing the filter column as a dimension lets users apply the filter themselves.
  • Deploy to an engine that supports it. Check the Portability options for a target that handles filtered metrics natively.

See also​