Inside Sema: The Architecture Behind a Trustworthy Answer

It takes an afternoon to wire an LLM to a database. It takes a lot longer to make the answers trustworthy. The distance between those two things is Sema's architecture — six layers that each solve a hard problem, working as one pipeline from a plain-English question to a governed, signed answer.

The pipeline, end to end

Question → Semantic graph → Governed planner → Sandboxed SQL → Auto-viz → Signed evidence

Let's walk each layer and why it's hard.

1. Semantic knowledge graph

Not a wiki of definitions — a typed control plane. Entities (customer, order, facility), their attributes, verified joins with keys and cardinality, and first-class metrics with real formulas. Sema bootstraps this by introspecting your schema and profiling data, then drafts plain-English definitions for you to confirm. Confirm a join once and every future answer inherits it.

Why it's hard: inference has to be good enough to be useful and conservative enough to never assert a wrong relationship. This is also the reason Sema doesn't hallucinate on your data — the model plans against the graph, not raw tables.

2. Grounded planning + repair

The LLM's job isn't to "write SQL from a string." It's to plan against approved entities and metrics from the graph. Generation is constrained to what exists; the planner resolves the question to specific nodes, and if execution errors, a single safe repair-retry attempts a fix without ever relaxing scope or policy.

3. Policy & RBAC engine

Before a single row is read, the plan passes through governance: the requesting user's role resolves their entitlements, restricted columns are masked or refused, and row policies scope the result. Enforcing this at plan time — not after results return — is what keeps restricted data out of both the model's context and the user's screen. (More in governance that scales.)

4. Sandboxed execution

Approved SQL runs in an ephemeral, network-isolated runner, read-only, after static analysis. No shared privileged connection, no write path, no way for a generated statement to reach beyond its sandbox.

5. Auto-visualization

The result's shape decides the chart: a time series becomes a line, a breakdown becomes bars, a single figure becomes a stat, geographic data becomes a map. This is the difference between a chatbot that prints a table and a system that hands you the right view automatically.

6. Cryptographic evidence + audit

Finally, the question, SQL, lineage, and access context are bundled and signed with an Ed25519 key, and the whole interaction lands in an append-only audit log. The signature is the trust anchor — tampering is detectable, and the pack can be shared as an expiring read-only link.

Why the whole is greater than the parts

Layer	The hard problem it owns
Semantic graph	Encoding meaning + verified relationships
Grounded planner	Correct SQL, not plausible SQL
Policy engine	Enforcement before execution
Sandbox	Safe, isolated running
Auto-viz	The right chart for the answer
Evidence + audit	Provable, tamper-evident answers

Any one layer is months of specialised engineering. Stacked together, they're the reason an answer from Sema is something you can put in front of an auditor — and the reason "just add an LLM to your database" never gets you there. If you want the product-level view of what this unlocks, read beyond chat-with-your-data.