| Layer | File | Answers | Owned by |
|---|---|---|---|
| Semantics | semantics/**/*.yaml | ”How do I query this safely?”: tables, types, grains, joins, measures | auto-maintained |
| Knowledge | knowledge/**/*.md | ”What does this mean to the business?”: definitions, caveats, policies | auto-maintained |
| Contracts | contracts/**/*.yaml | ”Which definition is canonical, and what must the answer obey?“ | human-owned |
The split rule
- Changes how the SQL runs → semantics.
- A human needs it to trust the answer → knowledge.
- Governs which definition is authoritative or what an answer must satisfy → contracts.
Why three surfaces, not one
Each layer has a different owner and a different update cadence:- Semantics is machine-derived from your live schema (tables, columns, grains, joins) and safe to auto-refresh on every
canonic ingest: it describes physical reality, so it should track physical reality. - Knowledge carries business prose that’s also auto-drafted from evidence (dbt descriptions, Notion pages, BI usage), but is meant to be refined by a human over time: it’s read-heavy context, not enforcement.
- Contracts decide what’s authoritative and mandatory. This is deliberately human-owned: which of two conflicting “revenue” definitions wins, and which guardrails are non-negotiable, are governance decisions canonic surfaces but never makes for you.
human_curated or board_approved fact in any layer is never silently overwritten by new evidence; at most, a conflict is flagged for review.
Semantics
Tables, grains, joins, and measures: what the compiler queries against.
Knowledge
Business meaning, caveats, and policies: searchable and graph-linked.
Contracts
Canonical bindings and guardrails: what the compiler must obey.