What dst is

dst is a governed data access layer: the thing your AI calls instead of opening a raw connection to the warehouse. Two kinds of caller, and both are AI: the AI your team already uses — Claude, ChatGPT, Copilot, Cursor, over MCP — and the AI you run, the agent inside your product, over MCP or REST. A caller asks a natural-language question; dst grounds it in a curated semantic model and business definitions, generates and guards SQL, executes it read-only against your warehouse — there is no write path for callers, by construction — and returns a cited answer with the SQL, a verification grade, and the cost attached. Every call leaves a trace: provenance for the caller, a native audit log for the platform engineer.

There is no query UI. People author the files, rule on reviews, and hold the keys their agents ask under — but they reach the data through an AI interface, not by querying dst themselves. Humans stay in the loop, not in the query path: the dashboard is a cockpit for governing and observing, never for querying. Both caller lanes go through the same pipeline, so the answer is identical whichever agent asks.

dst is not your data analyst. It is your data janitor: the layer that knows which table, which definition, which join, which aggregation — and serves exactly that, correctly. The caller reasons about the task; dst reasons about the answer. Neither does the other's job.

Its unit of governance is the answer path, not the context path. Tools that only govern context produce a better-informed agent with the same unchecked reach; dst sits between the question and the warehouse, so access, cost, scope, and correctness are enforceable in one place. Start with the answer path, then quickstart.