3.1 · Draft the ontology + a first metric
Prompt
You’ll see: generated
.tql and the exact, inspectable SQL. Run it to get the answer.3.2 · Make it reusable, not one-off
The rule of thumb: if two users could ask the same business question with different filters, groupings, time windows, or output columns, the surface should expose those choices as typed parameters — not hard-code one answer. A rigid one-off query answers today’s question; a parameterized surface answers the next hundred.Prompt
You’ll see: the same metric, but now callers pick metrics/dimensions/filters from approved options instead of triggering a rewrite — one governed surface serving many questions. Joins live once, in a reusable module.
Why this matters —This is also the durable answer to “how do I stop Ana rediscovering our join paths”: model joins as reusable fragments once, governed, and every later question routes through them. Reusable parameters are what make Module 5’s “update without rebuilding” cheap.
3.3 · Save it to the ontology
Prompt
You’ll see: the ontology files written to the repo — the basis for everything that follows.
3.4 · Make it findable — for the next chat
Discoverability is part of the deliverable, not cleanup. A future thread won’t know your filenames — it will search. Optimize for that:Prompt
You’ll see: a small README whose prose repeats the likely search terms on purpose — exact-match search is often the fastest retrieval path for a future agent.
✅ Checkpoint
- You read the rendered SQL before executing it
- Every metric got a stable alias
- The docs and .tql surfaces are saved to the ontology repo
- Your surface exposes typed parameters (metrics / dimensions / filters / window) — not one hard-coded answer
- A routing README exists, with the search terms a future chat would use