You're on Open Semantic Interchange, Now Apache Ossie: What the Standard Settles and What Runs on Top of It
Open Semantic Interchange is now Apache Ossie (incubating). What the standard settles for data leaders, what it leaves to the operating layer, and where Data Workers fits.
If you signed your team up for Open Semantic Interchange, you bought into a simple promise: write once, query anywhere. Define "revenue" or "active customer" in one vendor-neutral YAML document, with its datasets, relationships, metrics and AI context, and let every BI tool, query engine and agent read the same meaning. In July 2026 the project was accepted into the Apache Incubator as Apache Ossie (incubating), and the community says the spec and mission did not change. By July the coalition had grown from 17 launch partners to more than 50 organizations, and the ecosystem page listed 67 on October 2, 2026, including Snowflake, Databricks, dbt Labs, Salesforce, Microsoft, Cube and AtScale. Apache Ossie is the common language for meaning. Data Workers is the operating layer that keeps definitions true and acts on drift.
A data leader evaluating or contributing to Ossie has a fair question: once the language is agreed, who keeps the definitions true over time, reconciles what each engine actually serves, and fixes things when the data underneath changes? A standard decides the format by open vote. The operating layer decides, every day, whether the numbers still match the definition, and routes the answer to a named owner.
Key takeaways
- •Ossie settles the language. One vendor-neutral format for semantic models, datasets, fields, metrics and relationships, with converters in a hub-and-spoke design so N platforms need 2N converters instead of N times N minus one.
- •The operating layer is a separate job. Keeping every engine's copy true, checking the data under each expression, and acting on drift with approvals and rollback all happen after the standard has done its work.
- •Data Workers is that layer. Data Context Wizard imports Ossie definitions through the Ossie project's own dbt converter, reads every engine, joins definitions to lineage, quality and usage, and gives every definition a named owner.
- •Adopting Ossie and adding Data Workers are independent decisions. Keep standardizing on the spec at your pace; Data Workers works with Ossie models, native semantic layers, or both.
- •Owners decide, with receipts. Agents propose; people approve in Spellbook; every change is verified across engines and recorded.
Apache Ossie is the common language. Data Workers is the operating layer that keeps definitions true and acts on drift.
A shared definition has a property leaders often underrate: when the data under it changes, every engine moves together. That is consistency working as intended, and it is also why someone has to watch the data. Here is a Thursday at a company that standardized active_accounts in Ossie and runs it in both Snowflake and Databricks. This is an illustration, not a customer case.
| Time | System | What happens |
|---|---|---|
| 07:30 | Salesforce | A RevOps admin renames the Account status value Active to Active - Paying as part of a pricing change |
| 08:00 | Fivetran | The morning sync lands the new value in the Snowflake and Databricks raw tables |
| 08:10 | Ossie model | The shared definition of active_accounts filters on status = 'Active'; both engines, built from the same model, apply it faithfully |
| 08:12 | Databricks | Data Workers flags active_accounts in the metric view down 31% day over day, far outside its normal range |
| 08:15 | Snowflake | The semantic view shows the same drop. Lineage traces both to the Salesforce field through the dbt staging model; blast radius: a Genie Agent, a CoWork answer path, the board KPI dashboard and two retention models |
| 08:20 | dbt | Data Workers proposes two options to the owner: map the new value in the dbt staging model so the definition stays as approved, or change the Ossie filter. It recommends the staging mapping, with a row-level preview |
| 09:05 | Spellbook | The RevOps analytics owner approves the staging mapping; the shared definition is untouched |
| 09:40 | dbt | The build runs. Data Workers verifies that both engines report Wednesday's count plus 14 genuine new accounts, and records the receipt |
| 10:00 | Genie | A VP asks Genie how many active accounts the company has. The number is right in both platforms |
Ossie did its job perfectly here: both engines meant the same thing, so they agreed with each other all morning. The definition was never wrong. The data under it changed, and the fix belonged in the pipeline, approved by the person who owns the metric. That is the operating layer's work.
| Job | What Apache Ossie does | What Data Workers does |
|---|---|---|
| The language | Defines a vendor-neutral format for semantic models, datasets, fields, metrics and relationships | Imports Ossie models as governed definitions, with provenance |
| Portability | Converters move a model between Snowflake, Databricks, dbt, Cube, Salesforce and others | Reads what each engine actually built and compares it with the source |
| Agreement | Spec changes are discussed and voted on in the open, under the ASF | Each definition has a named owner who approves changes for your company |
| The data | Expressions point at tables and columns | Watches those tables for schema changes, freshness and quality, and traces breaks to every engine |
| Drift | Out of scope for a format, by design | Detects it, proposes a fix with blast radius, verifies across engines |
| The record | The spec's version history | A receipt per change: who approved, what changed, how to undo it |
Why doesn't Ossie just do this itself?
Because a standard's strength is what it leaves out. Ossie's job is to give dozens of vendors one format they can all read and write, decided through an open discussion-and-vote process with committership earned by contribution. To stay vendor-neutral it has to stay a specification: no runtime, no access to anyone's warehouse, no opinion about which of your teams owns revenue, and no liability for a change made inside a member's product. The roadmap shows the community building carefully in that direction, with working groups on metric semantics, catalog integration and ontology, and future items such as a reference query engine with conformance tests and governance metadata like certified definitions. Those make the format richer. They are still the format.
Keeping definitions true across a live estate is a different product. It needs connections to every engine, the lineage from each metric back to its sources, data-quality and freshness signals, an approval flow tied to named owners, rollback, and evidence for auditors. It also needs someone accountable for changes in systems the standard's members run. That is the product Data Workers is, and it builds on Ossie rather than competing with it.
There is a practical reason too. Ossie is moving: Snowflake's import procedure accepts version 0.1.1 today (the spec dates 0.1.1 to December 2025, and the repository tags it osi-0.1.1-rc1), while the 0.2.0 draft on main changes the document shape to one flat model per file, the shape the repository's converters use. A healthy standard evolves. The operating layer is what lets your company adopt it at the pace that suits you, because it checks what each engine actually serves, whatever version produced it.
Every tool owns a slice. Data Workers covers the whole lifecycle
Apache Ossie owns one slice of the data lifecycle, and it owns it well: a vendor-neutral standard for semantic definitions. Each point tool adds another console, another contract and another handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail, and treats Ossie as a first-class source of meaning.
| Stage | Data Workers | Apache Ossie | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 7.5 | The spec covers semantic models, datasets, fields, metrics and relationships, and its Ontology and Catalog working groups extend it toward business concepts and discovery. Data Workers joins every definition to lineage, quality, usage and a named owner. |
| Analytics & Insights | 8 | 8.5 | A home stage: write once, query anywhere. Snowflake, Databricks, dbt, Cube, Salesforce and others import or export Ossie, so BI tools and agents can share one metric. Data Workers answers from the approved definition, with lineage behind the number. |
| Data Quality | 8 | 1.5 | Data quality sits outside a semantic standard's scope by design; the spec declares keys. Data Workers checks the data each definition reads and turns breaks into tests. |
| Observability & Incidents | 8.5 | 1 | A standard has no runtime, so monitoring belongs to the engines that run it. Data Workers detects breaks in the tables a definition reads and traces them to every engine and agent. |
| Pipelines & Ingestion | 8.5 | 2 | The standard moves definitions, not data. Data Workers builds, reruns and backfills the pipelines under the tables every engine reads, with approvals. |
| Schema & Migration | 8 | 8.5 | A second home stage: hub-and-spoke converters move a semantic model between platforms without a rewrite, which makes a semantic-layer change of vendor a conversion. Data Workers plans warehouse migrations in approved, parity-checked waves. |
| Governance & Access | 8.5 | 3 | The project is governed openly under the ASF; governance metadata for definitions is on the community roadmap. Data Workers puts a named owner and an approval history on every definition today. |
| Security & Privacy | 8 | 2 | An Apache 2.0 specification; security is enforced by each engine that runs a model. Data Workers leaves a receipt on every change it proposes or makes. |
| Cost / FinOps | 8 | 1 | Cost belongs to the engines that execute each metric. Data Workers traces Snowflake credits to the dbt model behind them and drafts the fix for its owner. |
| MLOps & Models | 7.5 | 2.5 | ai_context and the AI-native roadmap give language models instructions and verified queries. Data Workers keeps the data under your own models healthy and connects to MLflow and W&B. |
How Apache Ossie and Data Workers work together
The standard sits at the bottom of the picture, next to the engines that implement it. Your Ossie models live in git, and each vendor's converter or import procedure creates the native objects: Snowflake semantic views, Databricks metric views, dbt MetricFlow and others on the ecosystem page. People and agents stay on top, in Genie, CoWork, Claude, ChatGPT or a BI tool. Spellbook Data Catalog (in preview) is where owners look and decide. In the middle, Data Context Wizard holds the Ossie definitions with lineage, quality and usage, the Data-Agents Swarm does the checking and fixing, the Autonomous Data-Conductor runs each fix end to end, and per-domain guardrails hold approvals, receipts and rollback.
How the definitions get in. Data Context Wizard imports semantic definitions as MetricFlow, and the Ossie project maintains a bidirectional dbt converter, apache-ossie-dbt. Convert each Ossie model with ossie-dbt ossie-to-msi, and Context Wizard imports the resulting MetricFlow semantic_manifest.json. Each engine's copy comes in from your team's export or assistant today (Snowflake can return any semantic view as Ossie YAML, Databricks metric views are YAML in Unity Catalog, dbt serves the Semantic Layer API) and compares every copy with the source. The step-by-step version for teams already running Ossie YAML is in you're on OSI semantics.
How people and agents reach it. Data Workers agents are MCP servers. Connect them to the client your team uses with the documented client setup path: clone the repository and add one start-agent.sh entry per agent.
Example (.cursor/mcp.json; paths are placeholders):
{
"mcpServers": {
"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"]
}
}
}Then ask: "Where is active_accounts defined, who owns it, and does every engine agree?" resolve_metric returns the approved definition, or every candidate with its source when they disagree. get_authoritative_source shows which definition the owner approved, and mark_authoritative records a new decision. trace_cross_platform_lineage and blast_radius_analysis show what reads the metric, pull-request review catches changes to the columns it depends on, and run_quality_check and get_quality_score cover the data under it.
One request, L0 to L4. The request: "Keep active_accounts right in every engine." The autonomy ladder is set per domain.
- •L0 manual. An analyst notices the drop on the dashboard and opens a ticket; an engineer traces it by hand across two warehouses.
- •L1 observe. Data Workers reports the drop in both engines, the Salesforce field behind it and the assets that read the metric. Nothing changes.
- •L2 propose. Data Workers drafts the staging mapping with a preview and routes it to the metric's owner in Spellbook. Nothing runs until the owner approves.
- •L3 act reversibly. For change classes with a proven record, such as rebuilding the affected models after an approved mapping, Data Workers runs the change, verifies both engines and can roll back.
- •L4 autonomous. For a scoped domain like status-value mappings, Data Workers fixes and verifies overnight and posts the receipt. Changes to the shared Ossie definition always go to its owner.
For the full safety model, read is it safe to let AI agents change production data; for where data and credentials live, read where does our data go. For specific engines, see Snowflake semantic views over MCP into Data Context Wizard, Data Workers with Cube, AtScale, MetricFlow and OSI, you're on Snowflake semantic views and you're on Cube. The section hub, bring your own context, covers every source of meaning Data Context Wizard plugs in.
What changes for your team
Standardizing on Ossie changes how your team writes definitions. Data Workers changes what happens after: the definitions stay true without a person checking each engine.
- •Incidents. A source change that moves a shared metric in every engine is traced to its cause, fixed upstream with the owner's approval and verified everywhere.
- •Data quality. Each standard metric gets checks on the tables it reads, in every engine that runs it.
- •Cloud spend. Snowflake credits are traced to the query and dbt model behind them, and each fix goes to its owner drafted.
- •Access. Access to a newly shared metric arrives as a scoped grant proposal for each engine's owner.
- •Audits. Every standard definition has a named owner, an approval history and receipts across engines, ready for finance and audit questions.
- •Migrations. Moving a metric set between engines runs in waves, with values compared before cutover.
For architects contributing to the spec, the split is useful: the working groups can keep the standard focused on meaning and portability, and the operating concerns live in a layer built for them.
Keep Ossie, or consolidate?
Keep Ossie if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
For a standard, keeping it is the point: Ossie is how your definitions stay portable and yours, and it costs nothing to keep. What teams consolidate is everything they built around it to make it operational: scripts comparing engines, a separate monitor on the same tables, a wiki page listing metric owners, and the manual review before every board meeting. If you are weighing whether to build that operating layer in-house on top of the converters and your assistants, read build it ourselves with Claude Code and MCP servers first.
The case for your CFO
The outcome: the company is standardizing its business definitions on an open, vendor-neutral format so every tool and agent uses the same meaning, and the definitions stay ours. Data Workers makes that investment pay off every day: the numbers in every engine keep matching the approved definition, and each definition has an owner who signs off on changes.
The risk story is plain. A standard makes definitions consistent; consistency also means one upstream change moves every engine at once. Data Workers watches for that, with autonomy set per domain on the ladder from L0 manual to L4 autonomous. Each change goes to a named approver, is applied reversibly, verified across engines and recorded in a receipt with who approved it, what it touched and how to undo it. Agents never approve their own work. Zero migration: Ossie, the converters and every platform stay where they are.
Why now: Ossie has an ASF home, broad vendor support and agents in every platform reading definitions directly, so the cost of a wrong shared number is rising. The first win is the ten board metrics: put them in Ossie or import the ones you have, assign owners, and reconcile every engine in the first weeks. What stays the same: your repos, your platforms, their permissions and your review process. For the numbers, see the ROI of agentic data operations. Start with a pilot (pricing); the pilot is credited in full against the first year.
The sentence to repeat upstairs: "Ossie gives us one portable definition for every metric; Data Workers makes sure every engine still matches it, with an owner's approval on every change."
Getting started
Start with a pilot. Take the Ossie models behind your board metrics (or export them from the engine where they live today, using that engine's Ossie export), convert and import them into Data Context Wizard, and connect it to the engines those models feed. In the first weeks you get every definition with an owner, every engine compared, and a watch on the data under each metric. Then turn on proposals in one domain. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
What is Apache Ossie, and how does it relate to OSI? Apache Ossie (incubating) is the new name of Open Semantic Interchange. The project was accepted into the Apache Incubator in July 2026 and renamed to avoid confusion with other projects that share the OSI acronym. The community says the spec and the YAML format did not change, so existing OSI files keep working.
Should we adopt Ossie now or wait for 0.2.0? Snowflake's import accepts 0.1.1 today, and 0.2.0 is a draft that moves to one flat model per document. Many teams start with the metrics that matter most and convert as the spec matures. Data Workers checks what each engine actually serves, so it supports you on either version and during the move between them.
Does Ossie replace our semantic layer? No, and it isn't meant to. Ossie is the interchange format; Snowflake semantic views, Databricks metric views, dbt MetricFlow, Cube and others keep serving queries. Ossie lets them share definitions, and Data Workers keeps those shared definitions true in each one.
How does Data Workers import Ossie definitions? Through the Ossie project's own dbt converter: ossie-dbt ossie-to-msi produces a MetricFlow semantic_manifest.json, and Data Context Wizard imports that manifest. Anything the conversion simplifies can be recorded as a governed definition with its owner. The step-by-step setup, including converter install and CI placement, is in you're on OSI semantics.
Who decides which definition is right? Your named owner, never an agent. When engines disagree, or when a definition and the data conflict, Data Workers routes the case to the owner in Spellbook with every candidate, its source and the blast radius, and records the decision.
Can we contribute to Ossie and still use Data Workers? Yes. Contributing to the standard and running an operating layer on top of it are complementary. The spec focuses on meaning and portability; Data Workers runs the daily work of keeping every engine and every number aligned with it.
Does Ossie cover ontologies and AI context? The spec includes ai_context for language models, and an Ontology working group is extending it toward business concepts above the physical model. Data Context Wizard holds those concepts alongside lineage, quality and usage, so agents get meaning and evidence in one governed view.
Sources
- •Apache Ossie (incubating), homepage (definition, YAML standard, Apache 2.0, news dates), https://ossie.apache.org/ (checked Oct 2, 2026)
- •Apache Ossie, "Apache Ossie (Incubating): The New Name for Open Semantic Interchange" (July 10, 2026; rename, ASF governance, community, working groups), https://ossie.apache.org/updates/ossie-enters-apache-incubator/ (checked Oct 2, 2026)
- •Apache Ossie, Ecosystem (participating organizations and implementations), https://ossie.apache.org/ecosystem/ (checked Oct 2, 2026)
- •apache/ossie on GitHub (README, core-spec 0.2.0.dev0 draft, tag osi-0.1.1-rc1, converters), https://github.com/apache/ossie (checked Oct 2, 2026)
- •apache/ossie, ROADMAP.md (working groups, query engine, governance items), https://github.com/apache/ossie/blob/main/ROADMAP.md (checked Oct 2, 2026)
- •apache/ossie, converters README (hub and spoke, document format), https://github.com/apache/ossie/blob/main/converters/README.md (checked Oct 2, 2026)
- •apache/ossie, core-spec/spec.md (0.2.0.dev0 draft; version history 0.1.1, 2025-12-11), https://github.com/apache/ossie/blob/main/core-spec/spec.md (checked Oct 2, 2026)
- •Snowflake, SYSTEM$READ_OSSIE_YAML_FROM_SEMANTIC_VIEW, https://docs.snowflake.com/en/sql-reference/functions/system_read_ossie_yaml_from_semantic_view (checked Oct 2, 2026)
- •apache/ossie, converters/dbt README (ossie-to-msi), https://github.com/apache/ossie/blob/main/converters/dbt/README.md (checked Oct 2, 2026)
- •Snowflake, SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML (Preview, currently supported version 0.1.1), https://docs.snowflake.com/en/sql-reference/stored-procedures/system_create_semantic_view_from_ossie_yaml (checked Oct 2, 2026)
- •Data Workers open-source repository (dw-context-catalog, dw-schema and dw-quality tool registrations) and client setup guide, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 2, 2026)