You're on TopBraid EDG (now TQ Data Foundation): Make Every System Compute What Your Experts Approved

Your governance team works in asset collections. Ontologies hold the classes, properties and SHACL shapes that describe the business. Taxonomies hold SKOS concept schemes for products, regions and risk types. Glossaries hold business terms with definitions, stewards and links to the data elements that implement them. Reference datasets hold the governed code lists every system is supposed to share. Changes happen in a working copy, go through a review and approval workflow, and publish with a time-stamped record of who changed what. Since version 9.1, TopQuadrant calls the product TQ Data Foundation (formerly TopBraid EDG), "the Context Governance Platform", and it serves that governed meaning to agents over GraphQL, SPARQL and an MCP server. TQ Data Foundation holds the authoritative meaning. Data Workers makes the data match it: Data Context Wizard brings your definitions in as context with provenance, checks them against what the warehouse, dbt and your dashboards actually compute, raises contradictions to the owners named in Data Foundation, and lets agents act on the approved definition with approvals and a receipt.

An approved term says one thing; the dbt model, the warehouse filter and the dashboard measure were written last year. That seam between governed meaning and running data is the job this guide covers.

Key takeaways

• •TQ Data Foundation keeps its job. Ontologies, taxonomies, glossaries, reference data, workflows and the change log stay where they are. Data Workers works next to them from day one.
• •Your definitions become governed context for every agent. Context Wizard reads approved terms and code lists, records the collection, version and approver with each one, and joins them to lineage, quality and usage.
• •Meaning is checked against the data. Data Workers compares each approved definition with what the warehouse, dbt models and dashboards compute, and routes every contradiction to a named owner.
• •Fixes land where your engineers review change. A model that drifts from the approved term gets a dbt diff for the owner to merge, with its blast radius, an approver and a rollback path.
• •Start with a pilot. One glossary domain and its reference data, read-only, then one fix class, on the ladder from L0 manual to L4 autonomous.

TQ Data Foundation is the source of meaning. Data Workers is the platform that makes every system match it.

TQ Data Foundation is built for the hardest part of semantic governance: getting experts to agree. Its documentation describes "virtual work-in-progress copies of asset collections" that "enable controlled publishing, review and approval workflow", an audit trail where "every change is logged and time stamped", and SHACL constraints with suggested fixes. TopQuadrant's own line is "AI proposes. Your experts confirm." More than 200 connectors harvest metadata from Snowflake, Databricks Unity Catalog, BigQuery, Oracle and others, and publish reference data to Kafka.

Outside Data Foundation sit the systems that turn a definition into a number: the warehouse, the dbt models, the pipelines and the dashboards. Data Workers covers that side with one context, one approval flow and one audit trail, measured against the definitions your experts approved.

Here is a day with Data Workers next to TQ Data Foundation. This is an illustration, not a customer case.

Without that check, finance would have approved a definition no number in the company used. TQ Data Foundation did exactly what it is for: the experts agreed, and the change is recorded. The fix was in dbt, a system Data Foundation doesn't run, and it went through an owner's approval first.

Why doesn't TQ Data Foundation just do this itself?

Because TopQuadrant built the product that decides what things mean, and that job depends on staying the neutral, authoritative record for every system around it. Its MCP server is designed for exactly that: assistants can list asset collections, run read-only SPARQL queries, read the selected asset and its constraint violations, and suggest fixes that an editor applies from the Problems and Suggestions display. Users see only the collections they can already open in Data Foundation. TopQuadrant also watches your systems for drift and new context, flags what changed and proposes updates for your experts to confirm, which keeps the governed definitions current. That is the right design for the place your experts sign off on meaning.

Rewriting a dbt model, changing a warehouse filter or rerunning a pipeline is a different product with a different liability. It needs to know what a change touches across every system, who owns each piece, how to roll it back and how to prove the result. Those systems belong to other vendors and to your data team, and a governance platform that also edited them would blur the line between deciding meaning and implementing it. Data Workers is the product on the other side of that line.

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

TQ Data Foundation owns one slice of the data lifecycle and owns it outright: governing ontologies, vocabularies and reference data, with the workflows and roles that make them authoritative. 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 governed meaning you already have.

How TQ Data Foundation and Data Workers work together

Your people stay where they are: Claude, Codex or VS Code for questions and code, the Data Foundation editor for modelling and approvals. Spellbook Data Catalog (in preview) is where the data team looks: each contradiction, proposed change, blast radius, approver and rollback. Between them run four layers: Data Context Wizard keeps one governed context graph, the Data-Agents Swarm does the work with more than 20 specialist agents, the Autonomous Data-Conductor runs each fix end to end (detect, diagnose, fix, review, verify, remember), and per-domain guardrails hold approvals, receipts and rollback.

What Context Wizard does with your definitions. It reads the approved terms, concept schemes and code lists you point it at, and records each one with provenance: the asset collection, the version, the approver and when it was observed. It joins each term to the tables and columns that implement it, using Data Foundation's mappings and warehouse lineage, so a glossary term traces to fct_active_customers and on to its dashboards. It serves one governed view to every agent through tools like explain_table, resolve_metric and trace_cross_platform_lineage. An agent cannot promote a definition to authoritative on its own; that takes a named person, which matches how your experts already work in Data Foundation.

Setup over MCP today. TQ Data Foundation connects over its MCP server, or over its GraphQL and SPARQL endpoints, today, in your team's client beside Data Workers. The MCP server is remote, reached over HTTPS with OAuth 2.1; TopQuadrant Support enables it per environment (its docs mark it experimental), and users sign in through SSO with the collection rights they already have. Data Workers' agents come from the open-source repository: clone it and add start-agent.sh entries to your client config, as the client setup docs show. In Claude Code, add the Data Foundation server with claude mcp add --transport http data-foundation <your-MCP-server-URL>, or put both in one file.

// Example: .mcp.json for Claude Code
{
  "mcpServers": {
    "data-foundation": {
      "type": "http",
      "url": "https://mcp.<your-data-foundation-host>/mcp"
    },
    "dw-context-catalog": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-context-catalog"]
    },
    "dw-quality": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-quality"]
    },
    "dw-schema": {
      "command": "/path/to/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-schema"]
    }
  }
}

List the tools with your client's own command (/mcp in Claude Code). An analytics engineer can then ask "does fct_active_customers match the approved Active Customer term?" and get the term from Data Foundation through a read-only SPARQL query, the model's lineage from trace_cross_platform_lineage, its latest run_quality_check and get_quality_score results, and any recent column changes from the dbt manifest diff, in one answer.

Where writes go. Data Foundation stays read-only from the agent's side, as its MCP server is built. Approved fixes land where the definition is implemented: a dbt diff, a pipeline change or a warehouse rule, reviewed where your engineers already review change. Definition changes stay in Data Foundation's workflow, decided by your stewards.

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

• •L0 manual. Connected, not acting. Your steward compares definitions and models by hand.
• •L1 observe. Data Workers reads approved terms and code lists, compares them with what the warehouse and dbt compute, and reports every contradiction with lineage and owners. Nothing changes.
• •L2 propose. Data Workers drafts the dbt diff or pipeline change with its blast radius. The owner approves in Spellbook before anything runs.
• •L3 act reversibly. For proven change classes, such as adding a new code from a published reference dataset to a warehouse mapping table, Data Workers applies the change, verifies it and can roll it back.
• •L4 autonomous. For a scoped, trusted class like keeping one mapping table in step with one governed code list, Data Workers fixes and verifies on its own and posts the receipt for review.

For the safety model behind each step, read is it safe to let AI agents change production data, and for where data and credentials live, read 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 and Ontotext GraphDB. For the catalog layer, see Collibra, Alation, DataHub and OpenMetadata with Spellbook. For background, see ontology for enterprise data explained, our business glossary guide and exposing a business glossary over an MCP server.

What changes for your team

Governance teams spend real time after a definition is approved: chasing which models implement it and explaining why the dashboard still shows the old number. With Data Workers next to TQ Data Foundation, those jobs run on autopilot at the level you set.

• •Incidents. A model or dashboard that still computes last quarter's definition is caught, traced and fixed with a receipt.
• •Data quality. Every governed code list gets a check that warehouse values stay inside it, so a missing code shows up the same day.
• •Cloud spend. Cleanups of tables and extracts built for retired definitions are proposed to the owner after a dependency check.
• •Access. A request for data a term marks as sensitive arrives as a time-boxed grant proposal for its owner.
• •Audits. Each fix links the approved term and version, the approver, the diff and the rollback path.
• •Migrations. When the warehouse moves, every mapping from a term to a table moves with it in parity-checked waves.

Stewards and ontologists get their week back for modelling new domains and settling the disagreements only people can settle.

Keep TQ Data Foundation, or consolidate?

Keep TQ Data Foundation 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 ontologies, SKOS taxonomies, reference data and approval workflows belong in Data Foundation, and its open standards keep that work portable. What teams consolidate is the tooling around it: a separate tool that checks codes in the warehouse, scripts that diff a glossary export against dbt YAML, a spreadsheet that maps terms to dashboards. Data Workers runs those jobs with one context, one approval flow and one audit trail. If you are weighing building this layer yourself on the Data Foundation MCP server, read build it ourselves with Claude Code and MCP servers: reading definitions is the easy part; cross-system context, approvals and rollback are the work.

The case for your CFO

The outcome: the definitions the company paid experts to agree on are the ones every report, dashboard and agent uses. Revenue, active customers and regulatory codes stop drifting between what was approved and what was computed.

The risk story is plain. Your team's assistant reads Data Foundation through its MCP server with read-only SPARQL and each person's own access rights; Data Workers' agents never call it. Every change Data Workers proposes shows its blast radius, goes to a named approver, lands through your existing dbt and pipeline review, is verified and leaves a receipt: the term it implements, who approved it, what it touched and how to undo it. Autonomy is set per domain from L0 manual to L4 autonomous and can be dialled back at any time. Zero migration.

Why now: agents answer business questions from whatever the systems compute. If the approved definition never reached the model, every agent repeats the wrong number with confidence. The first win is one glossary domain with its reference data, read-only, and a contradiction report against the warehouse and dbt. What stays the same: your ontologies, workflows, stewards, Data Foundation licence and review process. Start with a pilot; the 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: "Our experts decide what the numbers mean in TopQuadrant; Data Workers makes sure every system computes them that way, and fixes it with an approval and a receipt."

Getting started

Start with a pilot. Pick one glossary domain that feeds reports people rely on, such as customer or revenue terms with their reference data, connect the Data Foundation MCP server read-only next to Data Workers, and let Data Workers report contradictions for a few weeks 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

Is TopBraid EDG the same product as TQ Data Foundation? Yes. TopQuadrant's documentation moved from "TopBraid EDG 9.0" to "TQ Data Foundation 9.1", and the EDG name survives in places like EDG Studio and the /edg path. This guide applies to both names.

Does Data Workers write to our Data Foundation collections? No. Your team's assistant reads through the Data Foundation MCP server, which runs read-only SPARQL with each user's existing rights. Definition changes stay in Data Foundation's workflow; Data Workers' fixes land in dbt and your pipelines.

What happens when the warehouse and the approved term disagree? Context Wizard records both, shows agents the approved term with its source and version, and routes the contradiction to the term's steward and the model's owner. If the model is wrong, Data Workers proposes the fix; if the term needs to change, that decision goes back to Data Foundation's workflow.

Can Data Workers use our SKOS taxonomies and reference datasets, not only glossary terms? Yes. Concept schemes and code lists come in through the same MCP server or the SPARQL and GraphQL endpoints. Reference data is often the fastest win: a code missing from a warehouse mapping table is easy to detect and safe to fix.

Our MCP server isn't enabled yet. Can we still start? Yes. Data Foundation also exposes GraphQL and SPARQL endpoints with the same access rights, and Data Workers connects over those today. Enabling the MCP server is a request to TopQuadrant Support for your environment.

Does this replace our data catalog? Data Foundation can govern catalog assets too. Spellbook Data Catalog is where your team reviews, approves, rolls back and audits what Data Workers does, alongside Data Foundation as the place where meaning is decided.

Sources

• •TopQuadrant, homepage ("The Context Governance Platform"), https://www.topquadrant.com/ (checked Oct 2, 2026)
• •TopQuadrant, TQ Data Foundation product page, https://www.topquadrant.com/tq-data-foundation (checked Oct 2, 2026)
• •TopQuadrant, Authoritative Context, https://www.topquadrant.com/authoritative-context (checked Oct 2, 2026)
• •TopQuadrant, Connectors and APIs, https://www.topquadrant.com/connectors (checked Oct 2, 2026)
• •TopQuadrant, TQ Data Foundation documentation (updated Jun 29, 2026), https://docs.topquadrant.com/latest/ (checked Oct 2, 2026)
• •TopQuadrant, Introduction to TQ Data Foundation, https://docs.topquadrant.com/latest/introduction/index.html (checked Oct 2, 2026)
• •TopQuadrant, TQ Data Foundation Integration Points, https://docs.topquadrant.com/latest/edg_integration_points/index.html (checked Oct 2, 2026)
• •TopQuadrant, MCP Server (updated Sep 9, 2026), https://docs.topquadrant.com/latest/mcp_server/index.html (checked Oct 2, 2026)
• •TopQuadrant, TopBraid EDG 9.0 documentation, https://docs.topquadrant.com/9.0/ (checked Oct 2, 2026)
• •TopQuadrant, TQ Data Foundation 9.1 documentation, https://docs.topquadrant.com/9.1/ (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)