Module 5 · Track A: Update Without Rebuilding

Prompt

Update the ontology: add a new variant of an existing metric and break a metric out by a new dimension. Then handle a schema change (a renamed column). Show me the diff before applying, and open the changes for review.

You’ll see: small, targeted edits and a clean diff — not a rebuild. The schema rename touches schema.tql once; everything downstream follows.

Close the loop

Now re-ask your Module 1 baseline question in a fresh session with the ontology attached. Compare: governed definition, consistent answer, exact audited SQL.

Prompt

[Your Module 1 baseline question, exactly as you asked it cold.] Note which definition you used and show the SQL.

You’ll see: the warm answer route through your governed definition — consistent, with the exact audited SQL — instead of an improvised one.

Make the ontology learn from usage — not just from events —Schema renames and new metrics are event-driven updates. The other half is usage-driven: a recurring playbook that mines real activity — repeated questions, manual SQL, failed ontology lookups, mid-thread corrections — and proposes small reviewable patches. Ana drafts; a named owner approves; the learning is routed back into the routing READMEs; unresolved gaps become work items, not buried chat history. Build it in the Automation workshop, and see Ontology Operations Module 4 for the full operating loop.

✅ Checkpoint

You saw the diff before it was applied, and the change went to review
A renamed column was handled by one edit in schema.tql
Your baseline question’s warm answer beat the cold one — and you can say why

Track A: Explore & Reconcile Track B: Build from Documents

​Close the loop

​✅ Checkpoint

Close the loop

✅ Checkpoint