| Input | Lands as |
|---|
| Business documentation (SOPs, policies, glossaries) | `notes/*.md` + term definitions |
| Metrics documentation | governed `.tql` query surfaces + notes |
| Database + data dictionaries | schema backings + relations + table docs |
| Process-flow diagrams | entities + relationships + workflow notes |
| Call transcripts / unstructured text | terminology, intents, entities → glossary + entities |
| Golden datasets | golden-query test fixtures (accuracy) |
| Validation sets | eval cases that verify answers |
| Governed / access-controlled documents | fail-closed access rules + governed notes |
## How you know it's right
* Every query renders **inspectable SQL** — you can read exactly what ran.
* **Golden-query tests** pin a known-correct value and alert on drift.
* Flexibility ↔ accuracy is a per-metric dial: exact where it must be, flexible where exploration matters.
### The expert shortcut — seed from what you already know
Discovery (Modules 2–5) is for when the knowledge doesn't exist yet. If your team **already has** the join logic, ERDs, dbt models, or canonical SQL — don't make Ana rediscover it. Feed it in as a corpus and let her formalize it:
```text Prompt theme={null}
Here are assets that already encode how our data joins and what our metrics mean: [attach or paste: ERD, canonical SQL queries, dbt models, join documentation]. Seed the ontology from these directly - sources, join paths, and metric definitions - instead of rediscovering them by exploration. Show me everything you extracted as a reviewable change, and flag anything ambiguous or conflicting rather than guessing.
```