Plotly says semantic layers can be files—but definitions and execution are different controls

Plotly is making a deliberately contrarian case for data teams building agentic Dash applications: many do not need to buy and operate a separate semantic-layer product. Its November 3 guide recommends starting with either tested Python functions inside the app or plain-text definitions in a shared repository, then importing metrics from an existing platform only where another system already owns them.

The advice is useful, but teams should preserve one distinction that the “semantic layer” label can blur: a definition is context; an executable metric is a control.

When a Python function really can be the layer

Plotly’s strongest pattern is also its narrowest. Put a metric such as ARR in one Python function, add a regression test for a known result, and have the dashboard, REST endpoint and MCP tool call that same function. In that design, the function does not merely describe the metric. It computes it, and every supported interface reuses the same implementation.

That can be a good fit when one team owns the application and the number. The repository provides version history, pull requests provide a review path, and the test catches a changed result before deployment. The important operational rule is that callers invoke the function rather than independently regenerate its SQL.

Markdown solves a different problem

Plotly’s second option puts column notes, known data problems, business terms and formulas in Markdown files, with Google’s Open Knowledge Format offered as a preferred convention. This gives coding and analytics agents material they can read, search and cite. It is also portable and easy for domain experts to review.

But Markdown does not itself enforce a join path, row-level policy or aggregation rule. If an agent reads a formula and then writes fresh SQL, correctness again depends on translation. A documentation check can catch a missing column description; it cannot prove that a generated query implemented the definition correctly.

Teams adopting this route should label answers by execution path. A number returned by a tested metric function can be called governed. A number assembled from governed components should expose its formula. An ad hoc query generated from prose should remain exploratory and show the SQL.

A practical rollout

Start with five disputed or high-impact metrics, not the entire warehouse. For each one, name an owner, record units and exclusions, and decide whether the source of truth is executable code or explanatory text. Add a golden-result test for executable metrics. Give MCP clients a narrow tool that calls the tested function instead of a generic SQL tool wherever possible.

If several applications, teams or BI systems must consume the same metric, the coordination value of a dedicated semantic platform rises. Plotly’s guide itself describes calling or importing definitions from dbt, Snowflake, Databricks, Power BI, Looker and Cube when those systems already own the metric.

The useful takeaway is not that semantic-layer products are obsolete. It is that teams should buy only the control they need. A small app can make one tested function authoritative. A shared Markdown repository can make hidden business knowledge visible. Neither should be presented as deterministic governance unless the execution path actually makes it so.