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. Six tools: list_catalog, describe_metric, run_semantic_query, drill_down, refine_semantic_query, and list_dimension_values. None of them accept or return 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; a Query Runner you control runs it in your warehouse. The layer stays thin. Rollups now answer repeated questions from Parquet on the engine, and they are still not a latency promise. Every query is metered against the caller.

Where it runs

Compile and execute are different processes, deliberately. hashi-api is browser-reachable and stores a runner URL plus a sealed runner key — never the warehouse password, on the path we recommend. hashi-engine compiles SQL and never opens a warehouse. A Query Runner you run next to the warehouse holds the DSN, the kill switch, and the audit log. They meet at a published artifact and a runner endpoint — both over a 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.