Dashboards should be data.
The modern data stack has world-class tools for loading and transforming data. The visualization layer is still a GUI product. DVT changes that.
"Dashboards should be declarative data that AI agents and humans co-author — stored in a database, updated via API, where every visual property is a named, customizable parameter — not a design constraint imposed by the tool."
The gap in the modern data stack
dlt (Data Load Tool) extracts and loads raw data into your warehouse. dbt transforms and models it into analytics-ready tables. What comes next — visualization — has remained a solved-but-messy layer.
Existing BI tools are built for point-and-click authoring. They're opaque, priced by seat, designed for human GUIs rather than programmatic access, and fundamentally incompatible with the code-native, AI-assisted workflows that analytics engineers already use everywhere else.
DVT completes the trio. The right analogy is Figma or Notion, not dbt: dashboard specs are live data in the cloud, updated instantly via API or MCP — not files committed to a repo every time a chart color changes. The spec format is open and version-controlled (like dbt's model definition). Individual dashboards are mutable records (like a Figma file).
The complete modern data stack
Who DVT is for
Analytics engineers & data scientists
Already using dbt and dlt. Think in SQL. Use git. Care about reproducibility. Want to build dashboards programmatically — not click-and-drag. Comfortable with JSON specs. Would rather author a dashboard via API or let Claude write the spec than wrestle with a GUI.
"I want programmatic control over my dashboards — and the option to put them in git when it makes sense."
Data analysts who use AI heavily
May not write much code, but work in environments where Claude or another agent drafts analytical artifacts. For this user, DVT's AI-native authoring means describing what they want — and an agent builds it, with every detail editable through a structured editor backed by the same open spec.
"I asked Claude to build me a revenue dashboard and it just worked."
Platform & BI teams
Need to standardize dashboards, enforce brand guidelines, manage permissions at scale, and audit what data is being shown to whom. The DAD model — dashboards as versioned, API-managed data — gives them auditability and control that legacy GUI tools cannot.
"We need every dashboard to be reviewable before it reaches production."
Why now
Three forces converge in 2025–2026 to make this tractable for a small team.
LLMs can write dashboard specs
A well-structured JSON schema plus a good MCP server means Claude can author, edit, and audit dashboards as first-class operations — not just describe what they should look like. AI agents become first-class dashboard authors.
The dbt/dlt community is large and underserved
Analytics engineers have great tooling for the data layer and poor tooling for the visualization layer. They're the community most primed to adopt a code-native visualization tool — and they're already asking for it.
Apache ECharts 6 solved the rendering problem
A token-based theme system, dynamic switching, and deep per-element config APIs make a truly flexible spec-driven renderer feasible without building chart primitives from scratch. The hard part is done.
The semantic layer you already have
The modern data stack is being told it needs another abstraction: a semantic layer between the warehouse and every downstream tool. DVT's answer is different.
The promise
Define your business metrics once — ARR, churn, pipeline — in a central governed schema. Every tool queries them consistently. No more competing definitions. No more "which churn rate is the real one?"
The problem: this requires another grammar to learn, another service to run, and organizational buy-in that rarely materializes. Definitions still drift. The governance problem doesn't go away — it just moves.
DVT's answer
When Claude authors a DVT dashboard, metric definitions come with it — embedded in the spec, stored in the database, queryable over the same REST API. You don't define your metrics before building dashboards. The definitions emerge from the dashboards themselves.
Ask DVT's search API. It returns the dashboard Claude built — with the business context it wrote, the data source it used, and how often the team views it. No separate metadata catalog. No manual documentation step.
Query all panels that reference churn-related metrics. DVT surfaces every definition in use, who created each one (human or AI agent), and which version the team actually looks at. Usage frequency becomes a proxy for canonical truth.
Every panel in a DVT spec records its data source, metric reference, and the description Claude wrote for it. Full lineage is in the spec. No separate lineage tool required.
DVT doesn't replace a semantic layer at the warehouse layer — if you need ad-hoc metric queries against raw tables, MetricFlow or Cube still do that well. But for visualization-layer governance — where is this metric shown, how is it defined in context, who built it, who uses it — DVT's catalog is already there.
The long game
DVT's long-term moat is the spec format becoming an industry standard — the thing every AI agent emits when building dashboards, the thing that travels between tools, the thing that analytics engineers put in their repos.
This is the dbt playbook: the spec and CLI became the standard, and that standard — plus hosted Cloud, brand, and community — became the moat. The code of the engine is not the moat. The spec is.
See the spec →Follow the build
DVT is in founding research. Leave your email and we'll reach out when there's something to see — no newsletters, no noise.