RootCause.ai
Automated data ontology

A governed semantic layer over every system you already run.

RootCause connects your sources and resolves the same entities across them on three keys: entity, time and location. The result is an ontology your team and your agents query in plain language. It starts from the sources. No glossary, no catalog, no modeling project.

See inside the ontology
By handauthoring effort
The knowledge lives in the author.Every mapping is rewritten for the next question.
revenue_by_customer.sql25 / 25 lines
WITH crm_customers AS (
  SELECT account_key, company_name, region_code, phone
  FROM crm.accounts
  WHERE is_deleted = false
), billing_customers AS (
  SELECT customer_id, account_name, arr_usd, billed_at
  FROM billing.subscriptions
  WHERE is_test_account = false
), resolved AS (
  SELECT
    COALESCE(c.account_key, b.customer_id) AS customer_id,
    COALESCE(c.company_name, b.account_name) AS customer,
    COALESCE(g.region_name, 'Unassigned') AS region,
    DATE_TRUNC('month', b.billed_at) AS month,
    SUM(b.arr_usd) AS revenue
  FROM crm_customers c
  JOIN billing_customers b
    ON lower(trim(c.account_key)) = lower(trim(b.customer_id))
  LEFT JOIN geo.region_map g
    ON c.region_code = g.raw_code
  WHERE b.billed_at >= '2026-01-01'
    AND b.billed_at <  '2026-07-01'
  GROUP BY 1, 2, 3, 4
)
SELECT * FROM resolved ORDER BY revenue DESC;▊
Lines25
Joins2
Mappings7

Written again by the next person, with different assumptions.

RootCause ontology3 / 3 selected
The knowledge lives in the ontology.Resolved once, reused by every question after it.
EntityCustomersresolved across 4 sources
LocationUnited Statesregion rolled up
TimeJan to Jun 2026monthly grain
entity.customer · time.month · location.region
metric: revenue.finance.v3
Resolved result set with each column typed by the ontology
customerStringentitymonthDateTimetimeregionCategorylocationrevenueNumber · USD
Acme Corp2026-06West1,842,000
Northstar Freight2026-06East1,207,400
Atlas Manufacturing2026-06Midwest918,250
Beacon Health2026-06South744,900
4 of 1,284 rowsEvery row traces back to the source rows it came from.

The mappings are stored, so the next question starts where this one finished.

Why this exists

The meaning of your data lives in people's heads.

Most companies can already reach their data. The gap is that the data does not carry its own meaning.

Revenue means one thing in finance and another in sales ops. The same customer exists four times under four keys. Every analysis starts with joins and mappings the last analyst also wrote, differently.

A smarter agent does not close that gap. If nothing records which customer table is canonical, what counts as revenue, or how two IDs point at the same company, there is no information to reason from. A human analyst hits the same wall and gets past it by carrying undocumented context in their head.

RootCause writes that context down and keeps it current. People and agents inherit the same definitions, the same identity resolution and the same rules for every question they ask.

Better reasoning cannot recover information the data never contained. The ontology supplies it.

Cold start

Start with the connection strings.

Point RootCause at what is actually there. A production database, two SaaS APIs, the legacy instance nobody wants to touch, and a folder of exports.

It reads structure and values, proposes relationships, tests them against the data, and then asks about the handful of cases the data cannot settle. Four stages, and the only thing you supply at the start is access.

Cold start, four stagesStarting material: read-only credentials
  1. 01

    Connect what is already there

    Point RootCause at the systems you run today. It reads structure, keys and values, including the database nobody wants to touch and the folder of exports.

    CRMSaaS
    acct_key
    company_name
    phone
    BillingDatabase
    customer_id
    arr_usd
    zip_code
    Support deskSaaS
    case_org
    opened_at
    domain
    WarehouseWarehouse
    dim_customer
    fct_orders
    Regional exportsFiles
    client_name
    week_ending
    region
    Logistics APIExternal
    shipment_ref
    site_lat
    site_lon

    No glossary, no catalog and no dbt project. The sources are the input.

  2. 02

    Propose relationships, then test them against the data

    Column names suggest a join. Data decides whether it holds. Every candidate is checked for overlap, cardinality and referential integrity before it enters the ontology.

    crm.accounts.acct_key → billing.subscriptions.customer_idHeld up
    98.4% key overlap1:N cardinalityno orphan rows
    support.cases.case_org → crm.accounts.company_nameHeld up
    96.1% name matchN:1 cardinalitydomain agrees
    exports.client_name → crm.accounts.company_nameDropped
    41.2% key overlapN:N cardinalityfails on reruns
    billing.subscriptions.zip_code → geo.postal_codes.codeHeld up
    99.8% key overlapN:1 cardinalityrange holds

    412 candidates proposed. 397 held up. 12 were dropped. 3 could not be settled by the data.

  3. 03

    Three questions the data cannot answer

    These are the cases where two readings are equally consistent with every row. RootCause stops and asks instead of picking one and moving on.

    Review queue
    • Acme Holdings vs Acme Corp
    • Fiscal week FY26-W01
    • Region code EMEA West

    397 relationships resolved without anyone being asked.

    Needs a human answer1 of 3

    Acme Holdings vs Acme Corp

    Both share a billing address and a domain, and neither shares a key. One customer or two?

    Same customerKeep separateParent and child

    Answered once, versioned, and applied to every query, model and agent after it.

  4. 04

    A governed ontology your team and your agents query

    Entities, their relationships and the entity, time and location keys that join them. Access rules apply before a query runs, for people and for agents alike.

    Customer
    Site
    Order
    Shipment
    RevenueNumber
    RegionCategory

    • Customer

      • causesOrder
      • causesShipment

    • Site

      • causesShipment

    • Order

      • causesRevenue
      • causesRegion

    • Shipment

      • causesRegion

    • Ends atRevenueRegion

    Relationship tested against your dataEntity in the ontology

    Every answer traces back to the source rows and the relationship that produced it.

Entity · time · location

Three keys make every source joinable.

Federated query engines already send one question to several systems. The difficulty comes after that, when the systems disagree about who a customer is, what a week is and where a site is. Those three keys are what a cross-source answer depends on.

RootCause resolves them once, from the data, without hand-written mappings. Every query, model and agent afterwards reuses the same resolution.

01 · Entity

One customer, however each system spells it.

RootCause normalizes identifiers and then corroborates them with the evidence already attached to the record: domain, phone, billing address and account metadata. Matches that clear the bar are merged. The rest go to review.

CRMAC-4471key
Billing4471key
Supportacme-corp.comdomain
ExportsAcme Corp. (US)fuzzy name
Logistics12 Mill St, Bostonaddress
customer.acme_corp5 records, 1 entity
Five methods agreed. Anything they disagree on goes to review.
02 · Time

Hourly, daily and monthly meet at the grain you asked for.

Event timestamps, daily snapshots, fiscal periods and irregular exports are aligned with timezone and calendar context. The alignment is stored on the ontology, so the next question inherits it.

orders · hourly
billing · daily
support · monthly
requested · weekly
W21W22W23W24W25W26
timezone and fiscal calendar applied before the roll-up
03 · Location

Coordinates roll up to postal code, city, region and country.

Points, postal codes, sites, cities, regions and countries resolve onto one hierarchy. Data captured at different spatial grains joins at whichever level the question is asked.

37.7749, -122.4194coordinates
94108postal code
San Franciscocity
Californiaregion
United Statescountry
ask at country level and every coordinate beneath it rolls up
Once those keys exist

Show me everything I have on customers in the United States between January and June.

Shared definitions

One definition of revenue, owned and versioned.

Metric definitions live in the ontology with an owner, a description and a change history. RootCause learns the aliases and shorthand your team already uses and maps them onto the canonical concept.

Defined once, versioned

Each metric carries an owner, a description and a change history. Every consumer reads the same definition and returns the same number.

Your team's vocabulary

Aliases and internal shorthand map to canonical concepts automatically. The ontology answers to the words your team already uses.

Governed before the query runs

Row and column permissions travel with the definition and are applied at query time, for people and for agents alike.
Verified relationships

Every relationship is tested against your data before it ships.

A model reading a schema will tell you order.cust_id joins to customer.id. Usually it is right. When it is wrong it is wrong quietly, and the first symptom is a number in a board deck that nobody can reproduce.

RootCause checks each candidate against actual rows before it enters the ontology. Key overlap, cardinality, referential integrity, distributional consistency. Candidates that fail are dropped or flagged at build time instead of shipping as suggestions for a human to certify later.

How proposed-only relationship discovery compares to relationships RootCause has tested
Generated and proposedRootCause
Relationship discoveryInferred from names and metadataInferred, then tested against rows
Failure modeQuiet, surfaces in a wrong answerSurfaced at build time, flagged or dropped
Human effortCertify every suggestionAnswer the exceptions only
Starting requirementExisting glossary or catalogRead-only access to the sources
Under the hood

The ontology records what each column means.

Before anyone queries it, RootCause runs a battery of analysis over every column and series to recover the business logic already latent in the data. Expected categories and their aliases. Numeric ranges and monotonic properties. Seasonality and periodicity on time series. Structural constraints between fields.

That inferred layer is what lets an agent know that a negative value in one column is an error and in another is a refund.

Supporting page

Adaptive Metadata Layer

See what is inferred from every column and series before anyone queries it.

Sources

Read your data where it already sits.

Databases, warehouses, object storage, SaaS applications and flat files all feed the same ontology. RootCause connects with read-only credentials scoped to what you nominate.

Databases

Transactional row stores and read replicas, read with credentials scoped to the tables you nominate.

Warehouses and lakehouses

Modeled tables and raw landing zones alike. An existing dbt project is welcome and never required.

Object storage

Columnar and delimited files in buckets, including the partitioned exports nothing else reads.

SaaS applications

CRM, support, billing and marketing systems, pulled through their own APIs with their own field semantics.

Files and exports

Spreadsheets and extracts that carry real business logic and live on somebody's drive.

Sources are read where they already sit. Nothing has to be centralized first and nothing has to be migrated for the ontology to work.

Next on the ladder

Foundational Ontologies

Join external context to the same entity, time and location keys.

Then query it

RootCause MCP

Give agents governed access to the ontology and the models built on it.

Not sure where you are on the curve? Take the readiness assessment.

Automated data ontology

See it built on your own sources.

Bring one messy source and one you care about. We will build the ontology on the call.