Introducing datahashi

We’re building datahashi for a sharp job:

Same metric for humans and AI agents — without hallucinated SQL.

Most “semantic layer” tools are a query builder bolted onto a warehouse. datahashi is the other shape: the model is the product, and every path to your data — BI, apps, and MCP agents — goes through it.

The failure mode we care about

Teams already ship copilots and MCP tools against Snowflake or BigQuery. The agent invents a join, returns a confidently-wrong number, and the dashboard next door quietly disagrees. Metric fights between finance, product, and ops aren’t new — agents just make them faster and harder to catch.

datahashi puts one governed model in the middle so dashboard X and agent Y ask by the same metric names and get the same answer.

What it is

You author a semantic model — entities, dimensions, measures, and metrics — as YAML files. When it’s ready you publish it. Publishing produces an immutable artifact: the model plus its policy bundle, versioned and frozen. Nothing reads from your warehouse except through a published artifact.

Two ways to ask (same request shape):

• The console / REST — a logged-in member or app runs a Semantic Query. The control plane attaches the principal server-side.
• MCP — an agent connects with a credential the control plane issued. Three tools: list_catalog, describe_metric, run_semantic_query. None of them accepts or returns SQL.

Why no SQL from the client

A client names a metric and some dimensions. There is no syntax in which to ask for anything else — no arbitrary joins, no SELECT *, no way to step around a row-level policy. Governance isn’t a filter that runs after the query; it’s the only thing there is.

datahashi compiles fan-out-safe SQL and runs it in your warehouse. The layer stays thin. Pre-computed rollups for a sub-second hot path are on the roadmap; we won’t lead with latency theater until they ship. Every query is metered against the caller.

Where it runs

Two processes, deliberately. hashi-api is browser-reachable and holds the key that seals warehouse credentials. hashi-engine holds the live warehouse connections and generates SQL. They meet at exactly two places — a published artifact and a warehouse DSN — both over a service-token route the browser cannot reach.

Start with the docs to publish your first model — then prove it: same metric in the playground and from an agent.