Who this is for
Data and platform engineers, analytics engineers who live in a terminal, and anyone wiring TextQL into CI or automation. You should be comfortable with a shell; Python helps but the CLI does the heavy lifting.What you’ll be able to do
- Install and authenticate the CLI, and read
refinery infobefore assuming any capability exists. - Query any connector into a named remote sandbox and analyze there — without pulling data to your laptop.
- Run governed .tql query surfaces with typed parameters — the same approved queries the product runs.
- Author new .tql files using the deployment’s own writing-tql skill as the authoritative grammar.
- Install ontology files programmatically and run the execute-before-save loop that catches bugs before users see them.
- Script a before/after evaluation that proves what your ontology changed.
Install & authenticate
One binary, device-flow or API-key auth, and refinery info as your compass.
Query into sandboxes
Connectors → named Python kernels; aggregate in place, never locally.
Run governed queries
The ontology mount, ANA.md, and executing approved .tql with parameters.
Author .tql correctly
The deployment’s own writing-tql skill is the grammar — use it, don’t guess.
Ontology as code
Install files via RPC, with the review discipline that makes it safe.
Prove the lift
Baseline → install → re-run: the before/after that sells the ontology.
Before you start
You need a TextQL workspace with at least one database connector and permission to use the CLI (an admin or data-team role). Modules 3–5 write to the ontology — run them in a workspace where that’s welcome (a sandbox org, or your team’s with a heads-up).🤖 Prefer to have Ana coach this workshop? — Paste the runner from
ana-runner-full.md into a new Ana thread — you run the CLI commands in your terminal; Ana explains output and coaches module by module.