You're on Timbr: Keep the Tables Under Every SQL Ontology Mapping True, So Agents Answer Right

Your team wrote the business down in SQL. Concepts like customer, order and subscription are created with CREATE CONCEPT, linked by relationships and inheritance, and given measures your analysts trust. Mappings bind each concept to live tables with a plain SELECT ... AS <property>, and Timbr queries those tables where they sit, in Databricks, Snowflake, BigQuery, Postgres and the rest, without copying the data. Analysts query concepts in SQL, BI tools connect over JDBC and ODBC, apps use the REST API, and data agents read the same ontology through the Timbr MCP server, steered since July by the Knowledge Base for Data Agents. Timbr holds the meaning in SQL. Data Workers keeps it true: Data Context Wizard brings the ontology and its mappings in as context with provenance, watches the tables and pipelines under every mapping, catches a source change before a measure drifts, and proposes the fix with approvals and a receipt.

A mapping reads the source as it is right now. When an application team changes a column, the mapping keeps reading the old shape. That seam, between the systems engineers change every day and the ontology your semantic team maintains, is what this guide covers.

Key takeaways

• •Timbr keeps its job. Concepts, mappings, measures, the Knowledge Base, Ask Timbr and Ontology Readiness stay as they are.
• •The ontology becomes governed context. Data Context Wizard reads concepts and mappings from Timbr's system tables and joins them to lineage, quality, usage and owners.
• •Source changes are caught before the answer. Schema and value changes under a mapping are traced to the measures they feed, including ones that raise no error.
• •Writes stay gated. Approved fixes land in your mapping DDL repo or the pipeline upstream, with a blast radius, an approver and a rollback path.
• •Start with a pilot. One ontology domain, read-only; then one fix class, on the ladder from L0 manual to L4 autonomous.

Timbr holds the meaning in SQL. Data Workers keeps the tables under it true.

Timbr calls itself "the governed enterprise context layer for AI", built on "SQL-native ontologies". Its docs describe an ontology-based semantic layer and a virtual knowledge graph that "models data as business concepts, relationships, hierarchies, measures, mappings, and rules, while querying live data in existing systems." The modeling is SQL DDL, the mapping is a SELECT, and the system tables expose all of it to SQL: SYS_CONCEPT_MAPPINGS lists "all the table mappings to concepts" and SYS_LINEAGE lists the ontology's data dependencies. That makes a Timbr ontology unusually easy for an agent to read.

Outside the ontology sits everything that decides whether an answer is right: application databases, CDC streams, orchestrators and the people who change them. Data Workers covers that side. Here is one morning, as an illustration, not a customer case.

Nothing raised an error. The migration was valid, Debezium replicated it faithfully, the Dagster run succeeded and the amount column still existed, so VALIDATE MAPPINGS passed. Timbr did what it was asked: sum the column the mapping names. Revenue would simply have come out low. Data Workers caught the cause two systems upstream before finance asked, with the ontology owner's approval on the fix.

Why doesn't Timbr just do this itself?

Because Timbr made a deliberate choice: model the meaning, leave the data where it lives. Its homepage says: "Don't move, ingest or sync data, just map it at source," and "Timbr doesn't store any." That is the right design for a semantic layer that spans a lakehouse, a warehouse and operational databases at once. The systems under the mappings belong to application teams, to Debezium and Kafka, to Dagster and to the lakehouse, and changing them is a different product with a different liability.

Timbr handles change on its own side with care. Ontology Readiness, added in September, turns "the ontology still works" into scheduled test suites, and its docs name the risk exactly: "A change to a source table, a mapping or a relationship can silently break the queries that users and agents depend on." VALIDATE MAPPINGS checks every mapping against the live source schema, so a dropped or renamed column fails the next run. Those are the right tools for the ontology's owner, and they check the conditions someone wrote down. A column that still exists but stopped receiving values passes them.

Data Workers is the product on the other side of that line. It knows what an upstream change will touch in the ontology, routes it to the owner, applies the fix reversibly through the repositories you already run, verifies the result against the source and keeps the record.

Every tool owns a slice. Data Workers covers the whole lifecycle

Timbr owns one slice outright: a SQL ontology over live data, and the governed answers built on it. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and builds on the ontology you already run.

How Timbr and Data Workers work together

Engineers and agents stay where they are: Claude Code or VS Code for mapping DDL and pipeline code, Ask Timbr for business questions, Power BI or Tableau over JDBC. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, its blast radius, approver and rollback. Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, and the Autonomous Data-Conductor runs each fix end to end under per-domain guardrails.

What Context Wizard does with your Timbr ontology. It reads concepts, properties, relationships and measures, and for each mapping the source tables, columns and expressions it selects, straight from SYS_CONCEPT_MAPPINGS, SYS_MAPPINGS and SYS_LINEAGE. It records them as context with provenance (source, last change, who changed it, owner) and joins them to source lineage, so the order_value property traces through map_orders to the Delta table, through the Dagster asset and the Debezium connector to the Postgres column it started as. Every agent gets that view through tools like explain_table and trace_cross_platform_lineage. When Timbr's total_revenue disagrees with the dbt Semantic Layer's revenue metric, the conflict goes to a named owner.

Setup over MCP and the Timbr API today. Data Workers connects to Timbr over its MCP server and its SQL interface today, with a token for a read-only Timbr role; Timbr's system tables can be queried from any Timbr endpoint. The Timbr MCP server speaks Streamable HTTP at /timbr/api/mcp/ and exposes four read-only tools: query_data, ask_question, generate_sql and identify_concept. It accepts a Timbr token in the x-api-key header or OAuth 2.0, and the x-ontology or x-agent header picks the ontology or Timbr agent. Data Workers' agents are MCP servers from the open-source repository: clone it and add start-agent.sh entries to your client config, as the client setup docs show.

// Example: .mcp.json for Claude Code
{
  "mcpServers": {
    "timbr": {
      "type": "http",
      "url": "https://<your-timbr-server>/timbr/api/mcp/",
      "headers": {
        "x-api-key": "<read-only Timbr token, from your secret store>",
        "x-ontology": "sales"
      }
    },
    "dw-context-catalog": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-context-catalog"]
    },
    "dw-schema": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-schema"]
    },
    "dw-quality": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-quality"]
    }
  }
}

List the tools with your client's own command (/mcp in Claude Code). An engineer can then ask "what feeds total revenue in the sales ontology, and is it healthy today?" and get the concepts from identify_concept, the lineage from trace_cross_platform_lineage, the null-rate baseline on the Delta table from monitor_metrics and the source's schema versions from Schema Registry, in one answer. Before an application migration merges, blast_radius_analysis names the concepts, measures and data agents it reaches.

Where writes go. Fixes land where your team already reviews change: a diff to the mapping DDL in version control, or to the Dagster asset upstream. Your deploy job runs the approved statement, so the ontology keeps one path for change. For the morning above:

-- Example: proposed change to the mapping DDL, applied by your deploy job after approval
CREATE OR REPLACE MAPPING `map_orders` INTO (`order`) AS
SELECT `order_id` AS `order_id`,
       COALESCE(`amount_cents` / 100.0, `amount`) AS `order_value`
FROM sales.silver_orders;

-- Example: new Ontology Readiness test proposed with the fix
ALTER TESTSUITE prod_gate ADD TEST order_value_not_null
OPTIONS (assertion = 'empty')
AS SELECT order_id FROM timbr.`order` WHERE order_value IS NULL;

One request, L0 to L4. The autonomy ladder is set per domain.

• •L0 manual. Your engineer traces a wrong measure by hand.
• •L1 observe. Data Workers watches every column the mappings read, flags schema and value changes and explains the cause with lineage and owners.
• •L2 propose. Data Workers drafts the mapping or pipeline diff with its blast radius and a readiness test; the ontology owner approves in Spellbook.
• •L3 act reversibly. For proven classes, such as rerunning a late Dagster asset, Data Workers applies the change, re-checks the measure against its baseline and can roll it back.
• •L4 autonomous. For a scoped class like late feeds in one domain, Data Workers fixes, verifies and posts the receipt.

The safety model is in is it safe to let AI agents change production data; where data and credentials live is in where does our data go.

The same pattern holds for every source of meaning: see the hub, bring your own context, and the guides for Stardog, AtScale and RelationalAI. For background, read ontology for enterprise data explained and semantic layer vs knowledge graph for LLM grounding.

What changes for your team

Semantic teams spend much of the week explaining why a measure moved or chasing a renamed column. With Data Workers next to Timbr, those jobs run on autopilot at the level you set.

• •Incidents. A source change that would make a measure undercount or a concept come back empty is caught, traced and fixed before a business user asks.
• •Data quality. Every column a mapping reads gets value and null checks at the source and a load-lag baseline, so readiness suites stay focused on the rules of the ontology.
• •Cloud spend. Cleanups of tables and extracts left behind by retired mappings are proposed to the owner after a dependency check.
• •Access. A request for a sensitive concept arrives as a time-boxed grant proposal for its owner, with the policy behind it.
• •Audits. Every change to a mapping, a feed or a measure carries an approver, a diff, the verification and a rollback path.
• •Migrations. When the lakehouse or warehouse under the ontology moves, tables move in parity-checked waves and the mappings follow with approvals.

Keep Timbr, or consolidate?

Keep Timbr if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

For most teams the ontology, mappings, measures, Knowledge Base and Ask Timbr stay in Timbr. What teams consolidate is the tooling around it: a separate data-quality tool for the tables under the mappings, reconciliation scripts for key measures, a spreadsheet mapping concepts to source columns. Data Workers runs those jobs with one context, one approval flow and one audit trail. If you are weighing building this layer yourself, read build it ourselves with Claude Code and MCP servers: the connection is the easy part; the cross-system context, approvals and rollback are where the work is.

The case for your CFO

The outcome: the ontology the company invested in gives numbers people can act on. Every revenue figure and agent answer built on Timbr rests on the tables under the mappings, and Data Workers keeps them right every day.

The risk story is plain. Agents read Timbr with a read-only role. Every change Data Workers proposes shows its blast radius, goes to a named approver, lands through your own repositories and deploy jobs, is re-checked against its baselines and leaves a receipt: who approved it, what it touched and how to undo it. Autonomy is set per domain from L0 manual to L4 autonomous. There is zero migration.

Why now: Timbr's Knowledge Base and MCP server put the ontology in front of data agents, so a quiet break under a mapping reaches everyone who asks, at agent speed. The first win is one ontology domain watched read-only, so the next upstream change is caught before the answer. What stays the same: your ontology, your mappings, your Timbr deployment, your source permissions and your review process. The pilot path is on the pricing page, and the pilot is credited in full against the first year. For the numbers, see the ROI of agentic data operations.

The sentence to repeat upstairs: "Timbr gives our agents one meaning of the business in SQL; Data Workers keeps the data under that meaning right, and fixes it with an approval and a receipt."

Getting started

Start with a pilot. Pick one ontology domain that agents or a BI report rely on, such as sales, connect Data Workers read-only next to Timbr, and let it watch the tables under the mappings before enabling the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.

FAQ

Does Data Workers write to our Timbr ontology? No. Agents read Timbr with a read-only role. Approved fixes land as diffs to your mapping DDL or upstream pipeline, and your deploy job applies them after the owner approves in Spellbook.

How does Data Workers know which source columns a concept reads? Timbr publishes its structure as system tables. Context Wizard reads SYS_CONCEPT_MAPPINGS, SYS_MAPPINGS and SYS_LINEAGE and joins each mapping's tables and columns to source lineage, so trace_cross_platform_lineage follows a property back to the source field.

We already run Ontology Readiness suites. What does this add? Readiness suites check the ontology against the conditions you wrote, on demand or on a schedule. Data Workers works upstream and continuously: it catches the source change first, including value changes no test describes, and proposes a new readiness test with the fix.

Does this replace Ask Timbr or the Knowledge Base? No. They stay where people and agents ask questions and reuse approved SQL. Data Workers keeps the tables and definitions under them correct.

What happens when Timbr and our dbt Semantic Layer define a metric differently? Context Wizard routes the conflict to a named owner. Agents see both candidates and their sources until the owner decides, and the decision is recorded.

Which sources does this cover? Whatever Timbr maps: relational databases, cloud warehouses, data lakes, NoSQL systems and APIs. Data Workers follows each mapping back to what fills the table, whether a CDC feed, a Dagster or Airflow job, or a dbt model.

Sources

• •Timbr, homepage, https://timbr.ai/ (checked Oct 2, 2026)
• •Timbr, llms.txt (product description and naming), https://docs.timbr.ai/llms.txt (checked Oct 2, 2026)
• •Timbr, Introduction to Timbr, https://docs.timbr.ai/doc/docs/getting-started/intro-timbr/ (checked Oct 2, 2026)
• •Timbr, Concepts DDL, https://docs.timbr.ai/doc/docs/sql/sql-ddl/ (checked Oct 2, 2026)
• •Timbr, Mappings, https://docs.timbr.ai/doc/docs/sql/mappings (checked Oct 2, 2026)
• •Timbr, Ontology system tables (SYS_MAPPINGS, SYS_CONCEPT_MAPPINGS, SYS_LINEAGE), https://docs.timbr.ai/doc/docs/getting-started/systables/ (checked Oct 2, 2026)
• •Timbr, Ontology unit tests (Ontology Readiness), https://docs.timbr.ai/doc/docs/sql/ontology-readiness (checked Oct 2, 2026)
• •Timbr, Knowledge Bases, https://docs.timbr.ai/doc/docs/sql/knowledge-bases (checked Oct 2, 2026)
• •Timbr, MCP server, https://docs.timbr.ai/doc/docs/integration/mcp/ (checked Oct 2, 2026)
• •Timbr, REST API, https://docs.timbr.ai/doc/docs/api/ (checked Oct 2, 2026)
• •Timbr, Changelog (2.66.0 Sep 11, 2.67.0 Sep 22, 2.68.0 Oct 1, 2026), https://docs.timbr.ai/doc/docs/general/changelog/ (checked Oct 2, 2026)
• •Timbr, Announcing: Knowledge Base for Data Agents (Jul 9, 2026), https://timbr.ai/news/announcing-knowledge-base-for-data-agents/ (checked Oct 2, 2026)
• •Timbr, Data Virtualization, https://timbr.ai/timbr-core/data-virtualization/ (checked Oct 2, 2026)
• •Timbr, Access Control and Governance, https://timbr.ai/timbr-core/access-control-and-governance/ (checked Oct 2, 2026)
• •Data Workers, Client setup (open-source docs), https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)
• •Data Workers open-source repository, agent tools and start-agent.sh, https://github.com/DataWorkersProject/dataworkers-claw-community (checked Oct 2, 2026)