Dock for data analytics is the workspace where an agent's SQL drafts, dashboard suggestions, and metric definitions live as reviewable rows, each tied to a Snowflake query ID or a dbt model name, each carrying the analyst who signed off. Analytics work fails when the interpretive layer (which query won, why this metric excludes returns, who approved the rename) disappears into Slack threads. Dock is the persistent record of that interpretation.
The architecture
Snowflake, dbt Cloud, Looker, Hex, and Mode stay the system of record for the raw analytics data: warehouse rows, compiled models, published dashboards, notebook outputs. Dock is the system of record for what the agent interprets from that data: the prioritized query list, the chosen metric definition, the reviewer's sign-off, and the audit log. Each Dock row carries a pointer back to the platform record (snowflake_query_id, dbt_model_name), agent identity, decision, reviewer, and timestamp. The agent re-fetches warehouse data via fresh API reads when it needs current state. Dock holds the persistent interpretive layer that survives across sessions. Warehouses optimize for compute and dashboards for display; neither stores the reasoning behind a metric choice. See Cloud 2.0 for engineering and Cloud 2.0 for product for the broader pattern.
One Dock surface: the metric review table
| metric_name | dbt_model | agent_draft_sql | rationale | reviewer | status | snowflake_query_id |
|---|---|---|---|---|---|---|
| weekly_active_accounts | fct_account_activity | SELECT COUNT(DISTINCT account_id) WHERE event_ts >= DATEADD(day,-7,CURRENT_DATE) |
Excludes internal test accounts via is_internal=false. Aligns to product team's WAU spec from 2026 Q1. |
sarah.l | approved | 01b2c3d4 |
| paid_arr_net | fct_subscription_revenue | SELECT SUM(mrr_usd*12) WHERE plan_tier IN ('pro','team') AND status='active' |
Net of mid-cycle downgrades. Excludes trials and paused subs. | govind.k | pending | 01b2c3e9 |
| support_csat_30d | mart_support_satisfaction | SELECT AVG(score) WHERE submitted_at >= DATEADD(day,-30,CURRENT_DATE) AND score IS NOT NULL |
5-point scale; null responses excluded, not zero-filled. | mei.r | approved | 01b2c3f7 |
A worked workflow
A product manager asks the analytics agent for weekly active accounts. The agent re-reads the fct_account_activity schema from dbt Cloud, drafts SQL, runs an explain plan against Snowflake, and writes a new row to the metric review table with the draft query, the rationale (internal-account filter, day-boundary timezone), and a pointer to the Snowflake query ID. Sarah, a senior analyst, opens the row, runs the query, clarifies the test-account filter, and marks status approved. Only then does the agent publish to Looker. Overwriting an existing metric definition runs through a dangerous-ops contract consent gate so the analyst confirms in-context before the change ships.
Why it matters
Data quality is now the dominant complaint in analytics: 57% of practitioners cited poor data quality as their top issue in the 2024 dbt Labs State of Analytics Engineering report, up from 41% in 2022 (dbt Labs). The fix is not more pipelines. It is a durable record of which definition is canonical and who agreed to it.
Analyst time is the other lever. A Fivetran survey found 90% of data professionals report work slowdowns from unreliable data sources, and analysts spend less than half their day on actual analysis (Fivetran). When the agent drafts and the analyst reviews, the slow work shifts from typing SQL to confirming intent, which is the work only the human can do.
The cost of letting interpretation drift is measurable. Gartner pegs the average annual cost of poor data quality at $12.9 million per organization (Gartner). Most of that cost is decisions made on metrics nobody can defend. A persistent review surface, with agent identity on every draft and an audit log on every approval, is the cheapest defence available.
Start a Dock workspace for your analytics team.
FAQ
Does Dock replace dbt or Looker? No. dbt compiles models; Looker serves dashboards. Dock holds the agent's draft, the rationale, and the reviewer's decision, with pointers (dbt_model_name, snowflake_query_id) back to those systems.
What stops the agent from publishing a bad metric? The consent gate on the publish step. Status must be approved and the reviewer must be a named analyst. Drafts sit in pending until a human signs off.
How does Dock handle metric versioning? Each row is immutable on approval; edits create a new row with a supersedes pointer. Looker links to the row ID, so dashboards trace back to a sanctioned review.
Can the agent reuse approved definitions? Yes. The agent reads the metric review table on session start, treats approved rows as authoritative, and surfaces conflicts when a new ask contradicts an existing definition. See Dock for research for the same pattern applied to literature reviews.