You're on Stardog: Keep the Tables Under Every Virtual Graph True, So Voicebox Answers Right
Already on Stardog? Data Workers brings your model and virtual graph mappings in as governed context, watches the tables under them and fixes breaks with approvals.
Your team modeled the business once, in OWL and RDFS, and mapped it onto the systems where the data already lives. Most of the data never moves: virtual graphs rewrite SPARQL into native SQL against Snowflake, Databricks SQL, BigQuery, Oracle or SAP HANA, run it in place and translate the rows back into the graph. Analysts use SPARQL and GraphQL, BI tools use the BI Server, and since Voicebox 1.0.0 reached general availability on Aug 28, 2026, business users ask questions in plain language. The Stardog Cloud MCP Server brings Voicebox into Claude Code and Cursor. Stardog holds the meaning. Data Workers keeps it true: Data Context Wizard brings the Stardog model and its mappings in as context with provenance, watches the tables and pipelines under every mapping, catches a break before Voicebox answers from it, and proposes the fix with approvals and a receipt.
A virtual graph reads the warehouse as it is right now. When a dbt refactor renames a column or changes a status code, the mapping still points at the old shape. That seam, between the warehouse your data team changes every day and the model your ontology team maintains, is the job this guide covers.
Key takeaways
- •Stardog keeps its job. The model, virtual graphs, SPARQL, the BI Server and Voicebox stay as they are; Data Workers works next to them from day one.
- •The model and the mappings become governed context. Data Context Wizard reads the classes and the warehouse columns each mapping reads, and joins them to lineage, quality, usage and a named owner.
- •Changes under a mapping are caught before the question. Schema changes, value changes and stale tables are traced to the classes they feed and fixed before Voicebox answers from them.
- •Writes stay gated. Approved fixes land in dbt or the mapping repository your team already deploys from, with a blast radius, an approver and a rollback path.
- •Start with a pilot. One virtual graph, read-only; then one fix class in one domain, on the ladder from L0 manual to L4 autonomous.
Stardog holds the meaning. Data Workers keeps it true.
Stardog is a superb place to unify meaning. It describes itself as a "knowledge-graph-powered semantic AI platform" that "unifies enterprise data where it lives." Virtual graphs rewrite "(parts of) SPARQL queries against Stardog into native query syntaxes like SQL" and translate the results back. Mappings are written in SMS, SMS2 or R2RML, or drawn in Designer. SHACL constraints check the graph, and Voicebox turns a question into SPARQL, runs it across the federated sources and summarizes the result.
Outside the graph sits everything that decides whether an answer is right: the source systems, Fivetran, the dbt models that shape the warehouse tables and the people who change them. Data Workers covers that side with one context, one approval flow and one audit trail. Here is one afternoon. It is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 13:40 | dbt | An analytics engineer merges a refactor of dim_account that replaces the status codes A, I and P with the words active, inactive and prospect; the accepted_values test is updated in the same pull request |
| 14:10 | Snowflake | The scheduled dbt job rebuilds dim_account; every test passes |
| 14:14 | Data Workers | It detects that every value in status_cd changed against yesterday's profile, and that 41 downstream readers use the column |
| 14:16 | Stardog | The knowledge engineer's assistant reads the accounts virtual graph mapping over the Stardog Cloud MCP Server and hands it to Data Workers: the :ActiveCustomer class is built from rows where status_cd = 'A', so the class would now return no members |
| 14:20 | Spellbook | Data Workers opens an incident with the cause, the mapping, the two Voicebox apps and the one BI Server dashboard that read the class, and the ontology owner named |
| 14:35 | Stardog | Data Workers proposes the change to the mapping in the team's mapping repository, with the diff and a SPARQL check that counts members per class before and after |
| 15:05 | Spellbook | The ontology owner reviews the diff and the impact, and approves |
| 15:12 | Stardog | The team's deploy job republishes the mapping to the Stardog endpoint |
| 15:15 | Stardog | The knowledge engineer's assistant runs the SPARQL check: :ActiveCustomer is back in line with yesterday's count, and Data Workers writes the receipt |
| 16:30 | Voicebox | A sales operations lead asks how many active customers are in EMEA; the answer is right |
Nothing in the graph raised an error. The mapping was valid, the SQL ran, the dbt tests passed, and the virtual graph returned exactly what the new data said: no account had the code A any more. Stardog did exactly what it was asked to do. The cause sat in dbt, and Data Workers caught it before the 16:30 question, with the ontology owner's approval on the fix.
| Job | What Stardog does | What Data Workers does |
|---|---|---|
| The model | Holds classes, properties and rules in OWL and RDFS, built in Designer | Reads the model as context and joins it to warehouse lineage, quality, usage and owners |
| The mappings | Maps sources into the graph with SMS, SMS2 or R2RML and queries them in place | Records which tables and columns each mapping reads, and traces them back through dbt and ingestion |
| The questions | Answers SPARQL, GraphQL, SQL through the BI Server, and natural language through Voicebox | Makes sure the tables and definitions behind those answers are correct and current |
| The break | Queries the source as it is; flags errors by marking a source or virtual graph Unavailable | Detects schema and value changes under a mapping before anyone asks, including the ones that raise no error |
| The fix | Runs the mapping your team publishes | Proposes the mapping or dbt change with its blast radius, routes it to a named owner and lands it in your repository |
| The proof | Serves the graph after the change | Verifies class counts with SPARQL after the change and writes a receipt with the cause, diff, approver and rollback |
| The meaning | Holds one model of the business | Keeps definitions consistent across the graph, the semantic layer and the catalog, with conflicts routed to an owner |
Why doesn't Stardog just do this itself?
Because Stardog made a deliberate choice: leave the data where it lives and query it in place. That is the right design for a graph that spans Snowflake, Oracle and MongoDB at once. The systems under the mappings belong to other vendors and to your data team, and changing dbt models, Fivetran connectors and warehouse tables is a different product with a different liability.
Stardog handles change on its own side with care. When source metadata changes after a data source has saved it, its docs say, "those changes will not be visible to the loaded Virtual Graphs. This phenomenon is known as schema drift." The data-source refresh-metadata command reloads the metadata, and a data source or virtual graph that errors is marked Unavailable, "like an offline mode", until an administrator brings it back. Those are the right tools for the graph's administrator. A change in values, like the status codes above, raises no error at all.
Data Workers is the product on the other side of that line. It knows what an upstream change will touch in the graph, routes it to the owner, applies the fix reversibly through the repositories you already run, verifies the result and keeps the record.
Every tool owns a slice. Data Workers covers the whole lifecycle
Stardog owns one slice of the data lifecycle outright: unifying meaning across sources, and the SPARQL analytics and Voicebox 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 knowledge graph you already run.
| Stage | Data Workers | Stardog | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 9.5 | Stardog's home stage: an OWL and RDFS model of the business, built in Designer, mapped onto many sources and served through SPARQL, GraphQL and Voicebox. Data Workers brings that model in as context with provenance, next to lineage, quality and usage. |
| Analytics & Insights | 8 | 8.5 | Stardog's other home stage: Voicebox turns questions into SPARQL over federated sources, and the BI Server gives Tableau and Power BI a SQL view of the model. Data Workers' Insights agent answers through governed metric definitions. |
| Data Quality | 8 | 5 | SHACL constraints with VALIDATE queries and guard mode keep the graph's own data in shape. Data Workers checks the warehouse tables under the mappings and repairs breaks at the source. |
| Observability & Incidents | 8.5 | 3 | Stardog marks a data source or virtual graph Unavailable when it errors. Data Workers detects the upstream change, traces it across systems, fixes it and verifies the graph after the change. |
| Pipelines & Ingestion | 8.5 | 5 | Virtual graphs query Snowflake, Databricks, BigQuery and many more in place, with no copy. Data Workers builds, reruns and backfills the pipelines that fill those tables, with approvals. |
| Schema & Migration | 8 | 3 | Stardog names schema drift and refreshes saved metadata on command. Data Workers takes upstream schema changes from pull request review of dbt and migration diffs, catches value changes through the metric baselines the team records, and assesses their impact on every mapping. |
| Governance & Access | 8.5 | 6.5 | Strong over its own graph: roles, named graph security and virtual graph security. Data Workers proposes and applies grants across your data platforms by policy. |
| Security & Privacy | 8 | 6 | Strong for its own estate: property-based protection, Kerberos, LDAP and OAuth 2.0 JWT. Data Workers flags sensitive column names in pull request review and proposes masking for the owner. |
| Cost / FinOps | 8 | 2 | Stardog runs its own server or Cloud plan. Data Workers traces credits in the warehouse under the graph to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 3 | Voicebox uses the language model you configure. Data Workers keeps the data under your models healthy and connects to MLflow and W&B. |
How Stardog and Data Workers work together
Your engineers and agents stay where they are: Claude Code or Cursor for SPARQL, mappings and dbt, Voicebox for business questions, Tableau or Power BI over the BI Server. Spellbook Data Catalog (in preview) is where the data team looks: each proposed change, its blast radius, its approver and its rollback. 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, and per-domain guardrails hold approvals, receipts and rollback.
What Context Wizard does with your Stardog model. It reads the classes and properties of the model and, for each virtual graph, the tables, columns and filters its mapping reads, and records them as context with provenance: where each fact came from, when and who owns it. It joins that to warehouse lineage, so :ActiveCustomer traces back through the mapping to dim_account.status_cd, through dbt and Fivetran to the CRM field it started as, and serves one governed view to every agent through tools like explain_table and trace_cross_platform_lineage. When the graph's idea of an active customer disagrees with the dbt Semantic Layer's, the conflict goes to a named owner.
Setup over MCP and the Stardog API today. Stardog connects over its HTTP API or the Stardog Cloud MCP Server (v0.2.3, Jul 29, 2026) today, and Data Workers runs next to that server in the same client, where your team's assistant reads with a read-only role. That server exposes three tools, voicebox_settings, voicebox_ask and voicebox_generate_query; they read settings, ask Voicebox and generate SPARQL, and none writes to the graph. It takes a Voicebox app token, and Stardog enables Voicebox API access per organization on request. 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 (Cursor uses the same mcpServers shape)
{
"mcpServers": {
"stardog-cloud-mcp": {
"command": "uv",
"args": [
"--directory", "/path/to/stardog-cloud-mcp",
"run", "stardog-cloud-mcp",
"--token", "<Voicebox app token, from your secret store>",
"--client_id", "<Voicebox app id>"
]
},
"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 in your client with its own command (for example /mcp in Claude Code). An engineer can then ask "what feeds the ActiveCustomer class, and is it healthy today?" and get the SPARQL from voicebox_generate_query, the lineage from trace_cross_platform_lineage, the latest run_quality_check results on dim_account, its load lag against the monitor_metrics baseline, and the model's change history from the dbt manifest, in one answer. Before a dbt change merges, blast_radius_analysis names the classes and virtual graphs it reaches.
Where writes go. Fixes land where your team already reviews change: a dbt diff for the owner to merge, or the mapping files your team exports from Designer and keeps in version control. Your deploy job publishes the mapping to Stardog after the owner approves, so the graph keeps one path for change.
One request, L0 to L4. The autonomy ladder is set per domain.
- •L0 manual. Data Workers is connected but not acting; your engineer traces a wrong answer by hand.
- •L1 observe. Data Workers watches every table and column the mappings read, flags schema and value changes before anyone asks, and explains the cause with lineage and owners.
- •L2 propose. Data Workers drafts the dbt diff or the mapping change with its blast radius; the ontology owner approves in Spellbook.
- •L3 act reversibly. For proven change classes, such as rerunning a late dbt job that feeds a virtual graph, Data Workers applies the change, verifies the tables under the virtual graph and can roll it back.
- •L4 autonomous. For a scoped, trusted class like late feeds under one virtual graph, Data Workers fixes and verifies on its own 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 Ontotext GraphDB, Neo4j and Palantir Ontology. For grounding tradeoffs, read semantic layer vs knowledge graph for LLM grounding and what is a context graph.
What changes for your team
Knowledge graph teams spend much of the week on work that isn't modeling: explaining why a class came back empty or chasing a renamed column. With Data Workers next to Stardog, those jobs run on autopilot at the level you set.
- •Incidents. A dbt or source change that would empty or distort a class is caught, traced and fixed before a business user asks.
- •Data quality. Every column a mapping reads gets value and null checks in the warehouse and a load-lag baseline, so SHACL shapes stay focused on the rules of the model.
- •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 named graph 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 definition carries an approver, a diff, the verification and a rollback path.
- •Migrations. When the warehouse under the virtual graphs moves, the tables move in parity-checked waves and the mappings follow with approvals.
The ontology team gets its week back for modeling, new domains and Voicebox.
Keep Stardog, or consolidate?
Keep Stardog 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 model, the virtual graphs, the SHACL shapes and Voicebox stay in Stardog. What teams consolidate is the tooling around it: a separate data-quality tool for the tables under the mappings, a class-count script, a spreadsheet that maps classes to 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 knowledge graph the company invested in gives answers people can act on. Customer counts, regulatory reports and Voicebox answers rest on the warehouse tables under the virtual graphs, and Data Workers keeps those tables and their mappings right every day.
The risk story is plain. Your team's assistant reads Stardog through the Stardog Cloud MCP Server with a read-only role; Data Workers' agents never call it. Every change Data Workers proposes shows its blast radius, goes to a named approver, lands through the repositories and deploy jobs your team already runs, is verified on the tables under the mappings (class counts confirmed with SPARQL by your team's assistant) 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 and can be dialled back at any time. There is zero migration.
Why now: Voicebox is generally available and reaches agents over MCP, so a quiet break under a mapping now reaches everyone who asks, in plain language. The first win is one virtual graph with the tables under it watched, read-only, so the next upstream change is caught before the answer. What stays the same: your model, your mappings, your Stardog plan, your warehouse 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: "Stardog gives us one meaning across our data; 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 virtual graph that Voicebox users or a BI dashboard already rely on, such as the customer graph, connect Data Workers read-only to the tables under the mappings, next to the Stardog Cloud MCP Server in your team's client, 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 Stardog database? Not directly. Your team's assistant reads Stardog through the Stardog Cloud MCP Server with a read-only role. Approved fixes land in dbt or your mapping repository, and your deploy job publishes them after the ontology owner approves in Spellbook.
How does Data Workers know which warehouse columns a virtual graph reads? Context Wizard reads each mapping, in SMS, SMS2 or R2RML or exported from Designer, records the tables, columns and filters it uses, and joins them to warehouse lineage, so trace_cross_platform_lineage follows a class back to the dbt model and source field.
Stardog already handles schema drift. What does this add? Stardog's refresh-metadata command and Unavailable status handle drift inside the graph. Data Workers works upstream: it catches a schema change in pull request review of the dbt or migration diff and a value change that raises no error through the metric baselines the team records, names the classes affected and carries the fix with an approval.
Does this replace Voicebox or our SHACL constraints? No. Voicebox stays where business users ask questions, and SHACL shapes keep the graph's own rules. Data Workers keeps the tables and definitions under them correct and current.
What happens when the graph and the semantic layer disagree on a definition? 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.
Sources
- •Stardog, homepage, https://www.stardog.com/ (checked Oct 2, 2026)
- •Stardog, documentation home, https://docs.stardog.com/ (checked Oct 2, 2026)
- •Stardog, platform release notes (12.1.4, Sep 3, 2026), https://docs.stardog.com/release-notes/stardog-platform (checked Oct 2, 2026)
- •Stardog, Virtual Graphs, https://docs.stardog.com/virtual-graphs/ (checked Oct 2, 2026)
- •Stardog, Data sources: schema drift, refresh-metadata and availability, https://docs.stardog.com/virtual-graphs/data-sources/ (checked Oct 2, 2026)
- •Stardog, Supported data sources, https://docs.stardog.com/virtual-graphs/data-sources/supported-data-sources (checked Oct 2, 2026)
- •Stardog, Designer, https://docs.stardog.com/stardog-applications/designer/ (checked Oct 2, 2026)
- •Stardog, BI tools and SQL queries, https://docs.stardog.com/query-stardog/bi-tools-and-sql-queries (checked Oct 2, 2026)
- •Stardog, Data quality constraints, https://docs.stardog.com/data-quality-constraints (checked Oct 2, 2026)
- •Stardog, Security, https://docs.stardog.com/operating-stardog/security/ (checked Oct 2, 2026)
- •Stardog, Voicebox, https://docs.stardog.com/voicebox/ (checked Oct 2, 2026)
- •Stardog, Voicebox developer guide (API access, Stardog Cloud MCP Server), https://docs.stardog.com/voicebox/voicebox-dev-guide/ (checked Oct 2, 2026)
- •Stardog, Voicebox release notes (1.0.0 GA Aug 28, 2026; 1.1.1 Sep 28, 2026), https://docs.stardog.com/release-notes/stardog-voicebox (checked Oct 2, 2026)
- •Stardog, Stardog Cloud MCP Server (v0.2.3, Jul 29, 2026; tools voicebox_settings, voicebox_ask, voicebox_generate_query), https://github.com/stardog-union/stardog-cloud-mcp and https://github.com/stardog-union/stardog-cloud-mcp/releases (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)