[ ontology ]

Ontology:
Your Tribal Knowledge,
as Code

Ana unearths the definitions, context, playbooks, and permissions buried across your systems, then assembles them into a self-maintaining semantic layer, fully reviewable and yours as a Git repo.

ontologies in production at

scale

[ what an ontology is ]

A model of your business. Yours to keep.

What an active customer is. How you measure revenue. Which system holds which fact, and who may see it. An ontology is your company's rules, written as code a machine can execute — and kept in a repository on your account. That makes it an asset you own rather than a platform you rent.

[ problem ]

Getting AI-Ready Data Still Runs Like an Assembly Line

Today, you centralize onto a single data platform. Model the dataset. Build a semantic layer over the metrics. Wire it to your agent. Then run the whole line again for the next dataset, and the next.

CENTRALIZE

MODEL

SEMANTIC LAYER

WIRE TO AGENT

7 WEEKS

DATASET 1

3 WEEKS 1.5 WEEKS 1.5 WEEKS 1 WEEK

CENTRALIZE

MODEL

SEMANTIC LAYER

WIRE TO AGENT

7 WEEKS

DATASET 2

3 WEEKS 1.5 WEEKS 1.5 WEEKS 1 WEEK

CENTRALIZE

MODEL

SEMANTIC LAYER

WIRE TO AGENT

7 WEEKS

DATASET 3

3 WEEKS 1.5 WEEKS 1.5 WEEKS 1 WEEK

21 weeks, nothing reused.

[ 01 how it builds ]

Our Ontology Builds Itself

Ana doesn't need you to begin with a migration or centralization effort. It starts across the systems you already run: cloud data platforms, on-prem systems, APIs, BI tools, operational applications.

It reads the schemas, relationships, queries, underlying data, and business logic spread across them, and reconciles all of it into a shared model of your business. Decades of institutional knowledge, captured without moving a single dataset.

[ ontology ]

schema

field def

query log

payload APIbusiness logic Salesforce

join key

schema

field def

query logAPI payload Salesforce

business logic Postgres

join key

See the connectors →

The Ontology Learns With You

Every question teaches Ana more about how your business actually uses its data: which definitions matter, how teams interpret them differently, where the context is still missing.

Ana turns what it learns into proposed patches to the ontology. Every patch is reviewable, version-controlled, and synced bi-directionally with Git.

@Ana update revenue to subtract returns going forward

Ana

Refine revenue definition · finance ontology 2 files +5 -1

Updates revenue to subtract returns. Three analyses this week ran into this gap, so making it explicit in the definition.

revenue.md metrics +4 -1

README.md metrics +1 -0

12 ## Revenue

14 revenue = gross_bookings

14 revenue = gross_bookings - returns

15 # excludes Q3 returns wave (see retention.md)

Requires 2 approvals Deny Approve

[ 02 what's inside ]

Everything Is a File

Everything in the ontology is a file in a tree — the metric definition, the methodology, the comp spreadsheet, the query itself. Files are what every agent already knows how to inspect, edit, diff, and test.

The query file is TQL: your SQL, with the meaning attached. The query stays the query you would have written; the file adds the documentation that explains it and the permissions that guard it. Definitions any agent can read are not lock-in.

revenue_by_region.tql

---

description: Total revenue per region.

---

params {

-- Region code. "US", "EU" or "APAC".

region: String

-- Earliest order date to include.

start_date: Date

}

SELECT region, SUM(order_amount) AS revenue

FROM orders

WHERE region = ${region} AND order_date >= ${start_date}

GROUP BY region

ENGLISH + SQL = TQL

/ two languages, one file/ fig. 01

Learn about TQL →

[ 03 what runs on top ]

Everything Built on the Ontology Lives in It

Beyond semantic models and supporting context, the ontology stores everything built on top of them: playbooks, dashboards, data apps, agents — each a file beside the definitions and permissions it depends on, not state stranded in a tool that owns it.

So nothing stays in a silo. An agent inherits the metric a dashboard already proved; a data app inherits the permissions a playbook already established. Anything Ana builds comes from what came before it.

/ the ontology as one surface/ fig. 02

Actions Run on the Same Model as Answers

An ontology that only describes your business is a reference. Ana works from it through permissioned actions: writing to your data warehouse, collecting input and holding state in data apps, taking the steps a workflow needs by hitting your APIs. Those actions are defined in the ontology and live there, beside the definitions they depend on and the permissions that bound them.

So the model that decides what a number means is the model that decides what may be done about it. Nothing acts on a definition it isn't allowed to read.

[ sovereignty ]

Every change is a commit. The repo is yours.

The ontology is text under version control. Ana proposes, your team reviews, the change merges — and every merge syncs both ways with a Git remote on your own account. Everyone else's ontology lives inside their platform, readable only through them. Yours is plain files, readable by anything.

the history