Dashboards as data
Dashboards as data is the architecture in which a dashboard is a structured document stored as a database record and managed through an API, so the same document always renders the same output.
It is the storage side of dashboards as code. Dashboards as code says a dashboard should be a readable, versioned document. Dashboards as data says where that document lives and how software reaches it: as a record any authorized program can read and write, not a file that has to pass through a build step before anything changes.
How it works in dvt
dvt is built on this pattern. A dvt dashboard spec is stored as a record, and the REST API and the MCP server both read and write it directly. Update a spec through either one and the dashboard is live immediately, with the change recorded as a new revision. Rendering is deterministic: the same spec and the same data produce the same pixels every time, so a reviewer looking at a spec knows exactly what viewers will see.
Treating dashboards as data is also what lets agents edit them directly. An agent doesn’t have to drive an editor or produce a file for someone to upload. It reads the current spec as JSON, edits the part that needs to change, and writes it back through the same API every other client uses. Because a spec is plain JSON, teams that want a copy in git can keep one; the database record stays the source the renderer reads.