Skip to main content

​
2.1 · Connect the ontology repo to Ana

This is the key step. In TextQL, add a Git connector and point it at your fork of the starter repo (TextQLLabs/ontology-starter-kits/tree/main/insurance — no fork yet? Ask your TextQL contact; it takes minutes). Because the ontology is git-backed, Ana now has the entire model — every metric definition, every note, every classification rule — as a reference she reads on demand.
No second source of truth — You don’t copy anything into Ana. She reads the repo live; when the repo changes, Ana sees the change.
Git connector pointed at the starter repo

The ontology repo connected — Ana reads it as ground truth.

​
2.2 · Connect your data warehouse

Add the connector for the warehouse holding your policy-admin / claims / actuarial data (Redshift, BigQuery, Snowflake, Databricks, …). Read-only access is enough.
Use your governed, contracted warehouse — Insurance is state-regulated (NAIC model laws / state DOIs) and life/health claims carry medical PII. Connect the enterprise warehouse that’s already in scope for your data-residency and audit obligations — see ontology/notes/governance-pii.md.

​
2.3 · (Optional) Bring in your documents

Your real-world context — the actuarial reserving workbook, a rating manual, dbt models, the spreadsheet where someone defined “in force” — often lives in messy files. Upload them in chat, connect Google Drive, or connect SharePoint/OneDrive. Ana reads them alongside the ontology as corpus, not migration, and can fold what she learns into the model.

​
2.4 · Say hello

Prompt
You’ll see: Ana describe the model from the repo itself — proof the Git connector works and the ontology is being read as ground truth.

​
✅ Checkpoint

  • Ana described the starter’s entities and metrics from the connected repo
  • Your warehouse connector is attached, read-only, and in your contracted region
  • You know which of your documents you’ll bring in (or that you’re skipping this)