Telmai Joins the Apache Ossie Ecosystem to Bring Observed Context to Semantic Models
Apache Ossie gives metrics, keys and relationships one open, vendor-neutral format, but a definition can’t tell you whether the data behind it is healthy. Telmai has joined the Ossie ecosystem to close that gap. See the early demo and where data quality fits.
Semantic models declare what data should mean, but the same metric is often defined differently across your data stack. Apache Ossie (incubating) consolidates those definitions into one open, vendor-neutral specification that every tool can read and exchange. What a definition cannot confirm is whether the data behind it is fit for use right now.
Telmai, the data quality and observability platform, today announced it has joined the Apache Ossie ecosystem to pair those definitions with observed context measured from the data itself. Below, we explain where data quality fits alongside Ossie and show an early demo of Telmai turning Ossie models into data quality monitors.
What is Apache Ossie?
Apache Ossie (incubating), formerly the Open Semantic Interchange, is an open specification for semantic models. Snowflake started it with Databricks, Salesforce, dbt and more than 50 other companies, and it is now an incubating project at the Apache Software Foundation.
An Ossie model is a YAML or JSON file that describes:
- Datasets and the physical tables behind them, including primary keys
- Fields and what each one means
- Metrics written as expressions, such as SUM(orders.amount) for revenue
- Relationships that define how datasets join
- AI context that tells agents how to use a metric correctly
Converters translate between Ossie and each tool’s native format, so a model defined once can be read by a catalog, a semantic layer, a BI tool or an AI agent. The spec also reserves a custom_extensions field where vendors can attach their own data to any part of the model.
What Semantic Models Mean for Data Observability
An Ossie model already encodes much of what a data observability platform needs to know. Each element implies a check, so coverage can follow the model instead of a hand-picked list of tables.
| Ossie element | Implied check | Why it matters |
|---|---|---|
| Dataset source | Freshness, volume, schema and completeness on the table it names | Confirms the table behind the model actually loaded and kept its shape |
| Primary key | Uniqueness and no nulls | Duplicate keys fan out joins and double-count metrics |
| Relationship | Referential integrity, with no orphaned foreign keys | Orphans drop or misattribute rows in any joined metric |
| Metric | A statistical range on the metric value | Catches a broken number before a dashboard or agent uses it |
What makes this practical is that it runs automatically. When a data quality platform generates checks from the Ossie model and re-reads the model on a schedule, monitoring stays in sync with the semantic definitions in the catalog. A new metric or a changed key produces matching monitors to review on the next sync, and datasets whose tables have gone missing are flagged.
Metrics also set priority. A table that feeds a metric scores higher than one that doesn’t, so monitoring starts there. That score has to be explainable. As Max Lukichev, Telmai co-founder and CTO, writes in his latest paper, “each score should carry the evidence behind it,” so teams can see why a table ranked where it did.
Because the definitions decide what gets measured, observed context builds itself instead of becoming a separate setup that drifts from the metadata. And because Ossie is an open format, the same approach works with any catalog or semantic layer that exports it.
The demo below shows Telmai applying this mapping to a real Ossie model.
What We Built
In this early demo, Telmai reads an Ossie model exported from a Snowflake semantic view and turns it into data quality monitors inside Telmai’s Microsoft Fabric workload.
- Read the model – Telmai parses the Ossie YAML for its datasets, keys, relationships and metrics.
- Map it to the data – Each dataset is matched to the table it names, here a mirrored Snowflake database in Fabric. Datasets with no matching table are flagged.
- Suggest monitors – Telmai proposes the checks from the table above, one bundle per table, for the team to review and approve. Metric monitors flag values outside a range of three standard deviations from their history.
- Stay in sync – Telmai re-reads the model every few hours and suggests an update when a metric or key definition changes.
The integration is one-way today. Telmai reads Ossie models but does not yet write anything back to them.
Why This Matters for Data Teams
Generating monitors from the model saves setup time, but the bigger payoff comes after setup.
- Faster triage – When a metric moves, teams can check every table behind it before escalating, and tell a business change from a broken pipeline.
- Coverage that keeps pace with the model – New metrics, changed definitions and dropped or renamed tables are all picked up on the next sync, so monitoring stays aligned with the semantic layer without manual upkeep.
- Monitoring tied to definitions, not tools – Checks follow the semantic model, so the same coverage applies wherever that model is used, not just in one vendor’s semantic layer.
- A coverage standard a central team can verify – Every table behind a metric is expected to carry the same checks, so a central data team can measure coverage against the model instead of auditing each team’s setup one by one.
What Comes Next
Reading Ossie models is the first step. Next, Telmai wants to help bring observed context, meaning what was measured from the data itself, into the semantic model.
A semantic model says what the data should mean. It does not say whether the data behind a metric loaded today, kept its shape, or still matches its definition. Today that knowledge sits in separate tools, and a person or an agent has to go and look for it. When it travels with the model, any tool that reads a metric definition can also tell whether the data behind it can be trusted right now.
For this to work across the data stack, observed context needs a common shape that every catalog, semantic layer, BI tool and agent can read, whichever vendor did the measuring. We plan to shape it with the Ossie community and the vendors building on the standard, and we’ll share more demos as the work moves forward.
Get Involved
Apache Ossie is still early, and how data quality fits in the standard is an open question. Whether you run data pipelines or build a BI tool, a query engine or an AI agent that needs business context, there is a way to take part.
- See it on your stack – If your team already maintains semantic models, book a walkthrough of how Telmai would read them and the monitors it would suggest.
- Shape the data quality format – If you build a catalog, semantic layer or BI tool on Ossie, work with us on a shared structure for data quality expectations and status.
- Follow and contribute to the standard – Ossie is moving to Apache Software Foundation infrastructure as part of incubation. Follow updates on the project website, join the dev@ossie.apache.org mailing list, collaborate on GitHub, and join the Ossie Slack workspace.
Semantic interoperability is too big for any one vendor to solve alone, and so is trust in the data behind it.
Want to stay ahead on best practices and product insights? Subscribe to our newsletter for expert guidance on building reliable, AI-ready data pipelines
- On this page
See what’s possible with Telmai
Request a demo to see the full power of Telmai’s data observability tool for yourself.
