---
title: "Dock for data analytics: metric definition workflow with attributed semantic owner"
excerpt: "Dock holds the agent's drafted metric definition, the lineage and usage evidence it read, and the semantic owner who approved it. dbt Cloud, Looker, and Snowflake remain the source of truth for code, dashboards, and warehouse state."
author: mei
category: Use Cases
date: "2026-05-30"
---

Metric definitions drift when no one owns the semantics. An agent can draft a definition by reading lineage and usage, but a human semantic owner still signs off. Dock holds the draft, the evidence, and the approval. dbt Cloud holds the YAML, Looker holds the explore, Snowflake holds query history. The Dock row carries the interpretation.

dbt Cloud, Looker, and Snowflake stay the system of record for the raw data. Dock is the system of record for what the AGENT INTERPRETS. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.

## The Dock surface: Metric Definition Drafts

| metric_key | dbt_model_ref | looker_explore | usage_30d | agent_draft_summary | semantic_owner | status | decided_at |
|---|---|---|---|---|---|---|---|
| revenue_net | dbt://models/marts/revenue.sql@a91f | explore://finance/orders | 412 queries / 38 users | Exclude refunds posted after period close; align with finance month-end cutoff | hannah@ | approved | 2026-05-28 14:02 |
| active_account | dbt://models/marts/accounts.sql@c70b | explore://growth/accounts | 1,108 queries / 92 users | Switch from last_login_at to last_workspace_event_at; matches PM definition since Q1 | derek@ | changes_requested | 2026-05-29 09:41 |
| pipeline_coverage | dbt://models/marts/pipeline.sql@4d12 | explore://sales/pipeline | 247 queries / 21 users | Weight stage probability by 30-day historical conversion, not static stage factor | priya@ | approved | 2026-05-30 08:15 |

Every row points back to a dbt model commit, a Looker explore, and a Snowflake query-history window. Status changes write to the row history, not to a Slack thread.

## The workflow

The agent runs nightly. For each metric it pulls 30-day query volume from Snowflake `QUERY_HISTORY`, walks lineage via dbt Cloud's discovery API, and reads Looker's content validator for explores that reference the metric. On drift signals (upstream column rename, dashboard mismatch, stale `description`) it drafts a definition update in the row, cites the queries and dashboards, and assigns the semantic owner from the metric catalog.

The owner reviews in Dock. Approve flips status to `approved` and the agent opens a dbt PR, links the row in the PR body, and tags the owner as reviewer. Changes-requested holds the row open with the note; the agent re-drafts and re-fetches platform state. The dbt PR merge is the system-of-record event. The Dock row is the interpretation event.

## Why this matters

Metric definitions belong in code. dbt's Semantic Layer is built on that premise: metrics defined once in the modeling layer, not scattered across BI tools ([dbt Labs](https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl)). Cube makes the same argument for headless BI: metrics should live in code and be deduplicated upstack ([Cube](https://cube.dev/blog/headless-bi)). Neither answers who drafted the change and on what evidence. That is the Dock row: agent identity, queries read, dashboards cross-checked, owner who approved, timestamp. See [agent identity](/blog/agent-identity) on attributed authorship and [agent audit and compliance](/blog/agent-audit-and-compliance) for definition disputes.

The pattern repeats across every Dock-for-X cluster. The platform stays canonical. Dock holds the interpretation. See [Dock for data analytics](/blog/dock-for-data-analytics) for the pillar, [cloud 2.0 for engineering](/blog/cloud-2-0-for-engineering) for the architecture, and [Dock for marketing](/blog/dock-for-marketing) for the split applied to campaigns. Agents draft. Humans decide. The decision is attributed.

Start your metric drafting workflow at [agent identity setup](/blog/agent-identity).

## FAQ

**Where does the metric definition live?**
In dbt Cloud. The YAML is system of record. The Dock row holds the draft, the evidence the agent used, and the owner's decision. The merged PR is what production reads.

**What stops the agent shipping a bad definition?**
The approval gate on the Dock row. The agent cannot open the dbt PR until status is `approved`. Changes-requested sends it back for redrafting.

**Why not have the agent open the PR directly?**
Reviewers need evidence, not just the diff. The row carries 30-day usage, lineage walk, and dashboards cross-checked. Reviewer reads the row, then approves the PR.

**Can two agents draft the same metric?**
Yes. The row history shows both attempts with their agent identities. The owner picks one or asks for a merged draft. Attribution stays per-agent.