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). Cube makes the same argument for headless BI: metrics should live in code and be deduplicated upstack (Cube). 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 on attributed authorship and 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 for the pillar, cloud 2.0 for engineering for the architecture, and 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.
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.