Dashboards as code, implemented as a versioned JSON spec

Dashboards as code means a dashboard is a versioned, schema-validated document, not a pile of saved clicks in a vendor’s database: every query, every axis label, every color is a named property you can read, diff, review, and roll back, the same way you treat a dbt model or an application’s source. dvt is built around this definition directly: every dvt dashboard is a JSON spec, and that spec is the only thing the renderer reads.

Why dashboards as code matters

In most BI tools, a dashboard is opaque GUI state that only the vendor’s rendering engine can interpret. Nothing can read it, so nothing can review it, diff it, or explain why it changed last Tuesday. Dashboards quietly drift: a filter nobody remembers setting, a metric that no longer matches its title, a data source swapped out during a migration and never checked again. The two things dvt actually promises come directly from closing that gap: faster iteration, and always knowing what’s published.

The same gap is why AI-generated dashboards became a problem instead of a shortcut. The static HTML trap describes what happens when an AI produces a one-off page instead of a document: it looks finished, then it can’t be updated, reproduced, or connected to live data, and it piles up in a downloads folder next to five other one-off attempts at the same chart.

How dvt implements dashboards as code

A dvt spec is a JSON document validated against a schema: it holds the queries that run against your warehouse at view time, the visual encoding for every panel, the layout, and any filters or interactions. Every property is named, and every property is a parameter, not a hidden default. Here’s a complete panel, the same one an agent or a person would write:

{ "id": "revenue-by-month", "title": "Revenue by month", "type": "chart:bar",
  "data": { "rows": [{ "month": "Jan", "revenue": 120 }, { "month": "Feb", "revenue": 150 },
                     { "month": "Mar", "revenue": 178 }, { "month": "Apr", "revenue": 168 }] },
  "spec": { "series": [{ "type": "bar", "barMaxWidth": 48 }] } }

The renderer reads this document and nothing else; it never drives from recorded GUI clicks or reverse-engineered state. Update the JSON and the render changes; there is no other path to changing what ships.

Review and rollback, the payoff

Because the spec is a document, a change to it is a diff: the History pane shows exactly which query, axis, or color moved, with a before-and-after thumbnail for each version. Roll back to any prior version and child elements keep their identity, so later edits stay correct. Every version records whether a human, an agent, or the system made it. A reviewer can leave a comment pinned to a specific panel and let an AI agent resolve it, the same review loop teams already use for code, now applied to the dashboard itself.

That reviewability is also what makes AI authorship trustworthy rather than a black box. An agent posting a spec through dvt’s MCP server produces the same validated document a human produces by hand: schema-checked before it saves, previewable before it applies, and diffable afterward. The full mechanics of dashboards as code go deeper into what the spec contains and what version control buys you once the authoring is done.

Getting hands-on

The fastest way to see the format is to open it directly: the spec reference documents the full schema, and the live builder renders whatever JSON you type. If you want the format running against your own warehouse, with an agent authoring against it, early access sets that up directly with our team.

Try the format yourself in the free Builder. No signup required. Ready to run it on your own warehouse? Get early access.