FAQ
Why can't I just connect Claude to my database and ask?
You can, but Claude doesn't know what your data means. It doesn't know that rev_net is the revenue Finance uses, which table is canonical, or how two tables are meant to join. So it guesses, and a wrong answer is worse than no answer. The missing piece is context — what every table and metric actually means. Shanc builds that and keeps it current, so Claude reasons over facts instead of guessing.
Why can't I just build this myself?
You can build a context layer — plenty of teams do. Building it isn't the hard part; keeping it alive is. The layer is accurate the day you finish it and starts drifting the next time a developer ships a schema change. Maintaining it by hand becomes a standing job: someone tracks every commit, updates definitions, re-checks joins. That's the cost Shanc removes. It reads your git history and query logs and updates the layer on its own, so you get what you'd build yourself, without the person whose whole job is keeping it from going stale.
Why not just use an LLM?
An LLM is only as good as the context it's given, and on its own it has none of yours. Ask it about your data and it fills the gaps with plausible guesses — the more fluent it sounds, the easier those guesses are to miss. More prompting doesn't fix it; it produces more confident wrong answers. Shanc gives the model a factual layer to reason over, so it works from your real definitions instead of inventing them. Same model, roughly twice the accuracy on analytical tasks.
Why not just write a skill?
A skill is a set of instructions you write for an agent. It's static, it isn't grounded in your actual schema, and it goes out of date the moment your data changes — so the agent follows the instruction confidently and still returns the wrong number. Shanc isn't instructions about your data, it's a structured layer built from your data: real tables, real definitions, real query logs, validated before anything runs and updated as the data moves.
Why not another tool on the market?
Most tools here either replace your stack or still need a person to maintain them. BI platforms ask you to move your analytics into their interface. Warehouse-native layers get curated by hand. The ones that auto-generate a layer mostly build it once and leave you to keep it current. Shanc sits under the stack you already have, maintains the layer itself from your commits and query logs, and serves it to whatever agent you already use over MCP. Nothing to migrate, nobody assigned to keep it alive.
How is this different from Omni?
Omni is a BI platform — you move your analytics into it, and its context layer is built and curated by your team inside its interface. Shanc is the layer underneath. It doesn't replace your BI tool or ask anyone to switch tools; it auto-maintains the definitions from your commits and query logs, then serves them to whatever AI you already use. Omni owns the interface; Shanc owns the context and plugs into yours.
Isn't this just a semantic layer?
A semantic layer is part of it — metric definitions, join paths, terminology. Shanc keeps that current automatically instead of by hand, and adds what a semantic layer alone doesn't: query-log patterns, the corrections analysts make while exploring, and validation before a query runs. The difference that matters to your buyer is maintenance — a semantic layer is something you keep up to date; Shanc keeps itself up to date.
What's the innovation?
Context layers aren't new. Context layers that maintain themselves are. Normally the definitions are hand-written and go stale on the next schema change. Shanc reads your git history and query logs and updates the layer automatically, so it reflects your data as it is today, not as it was six months ago. And what your analysts work out while exploring gets written back in, so the layer sharpens with use instead of decaying.
Who is Shanc for?
Data and analytics teams that want their AI to answer reliably, and the analysts, PMs and business people asking the questions. The ones who feel the pain first are usually data engineers — the people who'd otherwise keep documentation alive by hand — and heads of data who want one trusted set of definitions across the company.
How does Shanc handle governance?
Everything resolves against one shared layer, so dashboards, reports and AI all use the same definitions and "revenue" means the same thing everywhere. Before a query runs, Shanc validates the SQL against that layer, so answers stay grounded and safe to act on. What analysts discover in exploration stays marked unverified until you approve it, so nothing is silently promoted to fact.
Which warehouses and agents does Shanc support?
Warehouses: Snowflake, Databricks, Redshift and BigQuery. Agents: anything that speaks MCP — Claude, Codex and others. Shanc reads from your git (GitHub or GitLab), your query logs and your docs, and doesn't ask you to change any of them.
Does my data leave my environment?
No. Shanc runs locally on your machine, and no data leaves your environment. Connecting your full stack unlocks continuous sync, team-level layers and multiplayer mode when you're ready. In connected mode, only structural metadata and aggregate statistics leave — schemas, column types, query patterns — never row-level data.
Is Shanc SOC 2 compliant?
SOC 2 Type I in progress, expected Q4 2026. Type II to follow. Shanc holds read-only access to your warehouse, never requests write scope, and can run entirely locally with no egress at all.
Does Shanc replace dbt, my warehouse or my BI tool?
No. Shanc sits alongside your stack and reads from it — git history, warehouse query logs, your knowledge base, any docs you point it at. You keep everything you already use; Shanc gives your AI the context it's missing.
What does Shanc need to get started?
Your sources: git history, data warehouse query logs and any documentation you want included. Connect them and you have a working layer in minutes.
How do I try it?
Run it free locally to see it on your own machine, or book a demo to connect your full data stack.