Observability & Lineage
One dependency graph covers every source, model, document, and automation — total visibility into every use of your data.
Switchboard keeps one dependency graph of your entire workspace. Every source, every resource it delivers, every model — down to each computed property — and every consumer of them is a node on it. Open Models → Graph to see it.
The edges are not self-reported. They are read from the artifacts themselves: which resources a model selects from, which models another model builds on, which models each explore block, expression, and filter in a document reads, and which documents an automation delivers. If something uses your data, it is on the graph.
Both directions
Because the graph is complete, it answers lineage questions in both directions.
Upstream: where did this number come from? Any figure on a dashboard traces back through the explore that rendered it, the model it read, the models that one was built from, and the resource and source that fed them.
Downstream: who uses this? Pick any model and every consumer is already known — each document with a block or filter that reads it, each automation that delivers one of those documents, and every model built on top of it.
What that makes possible
Impact analysis before a change. Because dependencies are recorded, the downstream effect of a change can be listed before you apply it. When Operator proposes a model change, the affected documents are part of what you review.
Correct builds, targeted rebuilds. Build runs walk the same graph, so models always build in dependency order — and you can rebuild one model together with everything it depends on, or everything that depends on it.
Cleanup with confidence. A model with no downstream edges is provably unused. Retiring data stops being guesswork about who might still be reading it.
Access that follows the data. Visibility rules apply on the graph like everywhere else: what you see of it is what your permissions allow.
Visibility that doesn't erode
Vibe coding has changed how dashboards get built. People build them in Claude artifacts, in Replit, in an app hosted on Supabase — and the moment they do, visibility into the use of data is lost. The dashboard works, but nothing records which data it reads, and no impact analysis will ever warn you before a change breaks it.
With Switchboard you can do all of that today over MCP — and because every query resolves through your models, a vibe-coded dashboard reads the same definitions as every document, with the same permissions, instead of a one-off extract.
Next, vibe-coded dashboards will live inside Switchboard itself and simply become part of this graph — nodes with lineage, like any document. Build however you want; visibility stays fully maintained.