The last time we wrote about Ontology was in 2024. Since then, it has become one of the core primitives, alongside Sandcastles, that gives Ana capabilities no other data analyst agent can match. It is the layer that lets Ana reason about your business, not just query your warehouse.
Today we are shipping Ontology 3.0, one of the largest single updates to TextQL we have ever made. Four new capabilities come with it:
- Cost per query drives down over time. The more your team uses Ana, the cheaper each query becomes. The median query cost drops 7x or more as the Ontology accumulates knowledge.
- Unified context across structured and unstructured data. What used to be two separate systems (Ontology for semantic modeling, Context Library for documentation) now live in one place and can cross-reference each other.
- Self-learning with human approval. As users query your data estate, Ana proposes Ontology changes through pull requests. Your team reviews and merges them. The knowledge graph improves continuously without anyone losing oversight.
- Context that scales to your entire org. Ana's effective working context grew from 200K to over 5M tokens through better retrieval architecture, capturing more of your accumulated business knowledge per query.
These are made possible by two architectural bets: a git-backed file repository that the Ontology is built on, and .tql, the dialect it is stored in.
What This Means For You
The experience changes depending on whether it is Ana's first time seeing your data, or its hundredth.
The first time Ana sees a question about your data, Ana does the hard work: canvassing your entire data estate top-down, the warehouse for tables and join keys, the data catalog for column-level metadata, your BI tools and semantic layer for where business metrics actually live, and more.
From that sweep, Ana builds entity relationships, enriches metadata against your columns, and assembles a coherent picture of what your data means. The output is a persistent knowledge graph of your business that every future query builds on.
The next time someone asks a similar question, that underlying Ontology determines the shortest path to the answer, making every subsequent query cheaper and faster. If the analysis goes a different direction, or if the data has changed, Ana learns and updates the Ontology accordingly.
Beyond reliability and determinism, accumulated Ontology context drives the median query cost down by 7x or more over time.
The Ontology Repository
Backing the Ontology with a git repository, where everything lives as files in folders, is a radical shift from how context management and data modeling used to work in TextQL. It also makes the platform more enterprise-ready: every change is auditable, every version is recoverable, and governance follows the controls organizations already have in place.
Ontology and Context Library used to be separate systems: one for semantic modeling and structured querying, the other for unstructured prompts and documentation. The Ontology Repository brings them together, because structured and unstructured context are more useful when they can reference each other.
Why Files and Folders?
Files and directories turn out to be the most efficient and flexible substrate for AI exploration and composition. Frontier models are improving at file and terminal work faster than anything else, and by putting Ana's brain in that same substrate, every model upgrade lifts Ana directly.
In this navigation system, Ana can search it three ways: by keyword when there is a term to look for, by meaning when there is not, and by tracing how one piece connects to another. From any starting point, Ana follows references between files, so a question about churn pulls in how churn is defined, the events it depends on, the cohorts it filters against, and the definition of active underneath it all.
Beyond that, the Ontology can hold all types of unstructured content too: dashboards, notebooks, scripts, images, stylesheets, spreadsheets, and slide templates. The same repository that teaches Ana about your business gives Ana what it needs to produce pixel-perfect dashboards, reports, and decks that match your company's format.
Governance follows from this structure. Ana inherits the controls enterprises already use: fine-grained permissions through TextQL's built-in RBAC, SCIM, and SSO integration. Teams can control who can propose and accept changes to the Ontology, with a full audit trail of who changed what and when, perfect version control, regressions traceable to a specific commit, and rollbacks to any prior state.
.TQL: A Semantic Modeling Language Built for Agents
We're introducing .tql, a SQL-native semantic modeling language built for agents. It is the shared format where Ana uses your business metrics across every connected system, proposes updates for your team to review, and gets more efficient with each query.
Yes, we know. The world didn't need another semantic layer. We built one because it is the best one optimized for AI.
Locality of Behavior
A core design principle of .tql is locality of behavior: declarations stay close to the SQL they affect, so a unit's meaning is apparent from reading it and its imports. Humans can read it. AI runs faster and more accurately on it.
Ana reads the same file that produces the SQL. The metric formula, the join definition, the filter registry, and the access rule all sit in one place, so Ana reasons from intent rather than reverse-engineering behavior from compiler output. And when a question doesn't fit a clean semantic path, the trusted definitions still anchor a one-off SQL query.
Locality is what most semantic layers lack. They define entities, metrics, and joins inside the vendor's application, which works well within BI but breaks composability. Definitions live in a database rather than files, so they can't be searched across, referenced from documentation, or diffed between versions. As data stacks grow, the problem compounds: metrics in one tool, joins in another, filters in a BI layer, governance rules somewhere else.
The result is that a query requires a reader to mentally stitch together distant UI state, hidden application objects, injected prompts, and warehouse SQL. A .tql file consolidates that scattered context into one readable artifact:
Everything In One Format
Every piece of semantic information in .tql takes a common form: a declaration in a single language. Metrics, joins, filters, dimensions, and reusable functions all share the same syntax. Because the definitions are plain files, the entire semantic model lives in version control by default. There is no separate export step and nothing else to store.
The format is modular. Definitions can live in separate files, shared logic can be imported instead of copied, and business rules become small, reviewable modules that both humans and Ana can understand.
One format also collapses a tradeoff Ana used to face. There is no longer a choice between rigid semantic querying and freeform text-to-SQL. Ana can use .tql definitions when writing direct SQL, use direct SQL discoveries to propose better .tql models, and promote successful one-off analysis patterns into reusable, governed semantic definitions.
Designed for the Stack You Already Have
Every .tql file compiles to warehouse-native SQL. Nothing in your existing data stack needs to change, and generated SQL stays inspectable, debuggable, and compatible with the workflows you already have. Execution is governed throughout: parameters are typed, metrics and dimensions can be validated before execution, and filters compile to safe SQL fragments rather than ad hoc string concatenation.
.tql is also built for real-world warehouse complexity. Teams can start with simple table-backed objects and graduate to query-backed objects, custom SQL formulas, custom joins, and reusable helper functions. User roles, team, region, and other runtime context are available as values inside .tql models, so access-aware and personalization logic lives in versioned files rather than buried in prompts or application code.
Because .tql files are code, semantic modeling follows the same workflow as software development. Engineers work in branches, propose changes through pull requests, and merge when ready. Every change in Ana's behavior traces to a specific commit, with access control handled by the repository itself.
The context Ana builds about your business is also yours to take elsewhere. Because it lives in plain files, you can export it, use it in other tools, and build on top of it in Claude, Copilot, or Cursor.
What Customers Are Seeing
Early customers running on Ontology 3.0 have been measuring the difference. OpenGov compared the same queries against the previous Ontology: speed to first answer is up 3x.
Per-query effective context also grew from 200K to over 5M tokens. The model window stayed the same; better retrieval architecture has captured more of your accumulated business knowledge into each query.
ACU efficiency improved by a comparable order of magnitude. A medium-lived thread across multiple connectors, without Ontology context: 432 ACUs, 28 seconds. With context loaded: 82 ACUs, 15 seconds. Five times cheaper, nearly twice as fast, same model, same workload.
Ontology 3.0
Ontology 3.0
Ontology 3.0
Ontology 3.0
Ontology 3.0
Ontology 3.0
Source: TextQL internal benchmark. Same workload run against Ana before and after Ontology 3.0 rollout, across connectors. ACUs = Agentic Compute Units. Runtime = end-to-end time from query submission to verified answer.
Migration
For existing customers, the upgrade is straightforward.
An admin enables Ontology 3.0 under Settings > Features & Tools > Beta Features. Once enabled, all Markdown files and context previously stored in the library carry over into the new git-backed file system automatically. You won't need to recreate anything from scratch. Your existing context shows up as files in the new directory structure, and every new chat immediately runs on the new system: faster startup, richer context, full version history from day one.
For existing Ontology objects, there is a one-click migration button in the Ontology settings that converts them to .tql format. This is available today. It runs on the existing object definitions and outputs .tql files into the repository, so you can review and commit them before anything changes in production.
From there, you can reorganize into folders, provision team access via the Manage access tab, and start adding new file types like Python scripts or datasets. Permissions are opt-in: if you don't configure access, every user in your org continues to see all context, the same as before. There's no risk of accidentally locking anyone out.
