Knowledge Base & Definitions of Record
The Knowledge Base holds durable, agreed meaning and curated know-how — what a good analyst carries in their head that should outlive any one conversation. Anything executable elsewhere, generated, or ephemeral is referenced, not copied.
The litmus test
Three questions before anything lands in the Knowledge Base.
-
1
Agreed, or just true-for-now?
Agreed meaning belongs in the KB. A fact the warehouse computes lives in the Semantic Layer, referenced.
-
2
Will someone ask this again?
Reusable knowledge belongs in the KB. A one-off scope for today's analysis stays on the conversation or Canvas.
-
3
Does it live authoritatively elsewhere?
dbt models, DAGs, repo docs, tickets — reference the source of truth rather than copying it.
What belongs where
Copies rot — the whole drift story exists because of that. When something lives authoritatively elsewhere, the KB points at the source instead of duplicating it.
In the KB (a Page)
Durable, agreed meaning and curated how-to-analyze knowledge.
-
Definitions of Record
definition_of_record -
Skills & reference docs
reference_doc / skill -
Ambient context & decision logs
note - Source-of-authority pointers
Reference out
Lives authoritatively elsewhere — the KB binds to it, never copies it.
- dbt models / Semantic Layer — bound via a meta stamp
- Full project specs / repo docs (Git)
- External tickets (GitHub / Jira)
- BI dashboards (tracked as backlinks)
Neither (ephemeral)
Generated or one-off — it never becomes a Page.
- Chat transcripts
- Sandbox / scratch experiments
- Today's specific analysis scope
- Raw query corpus (curation material only)
Where decisions go
A decision ("explored A/B/C, chose C, here's why") is distilled into the KB, while the exploration stays on the conversation, linked. A metric-level decision lives in that Definition of Record's own version history — the commit reason, the Agree/Challenge, the variant tree. A cross-cutting decision becomes a note decision-log, linked from the Definitions it governs.