As of November 2026: eMondrian Community 2026.11.10.1, modules 0.0.0.104, Apache Ossie spec 0.3.0.dev0 (a draft).

A semantic model is where your metrics live: what "revenue" means, how orders join customers, which total is a ratio and not a sum. The first question a team asks before putting one into a new tool is: how do we get it out again?

Apache Ossie (incubating, formerly Open Semantic Interchange) is an open answer to that: one YAML or JSON file with datasets, fields, relationships and metrics, which Snowflake, Databricks, dbt and other tools have converters for. eMondrian can now write its cubes in that format and build cubes from it.

We didn't write a converter. An AI agent does the translation, and the server checks the result, metric by metric, against the cube.

Why an agent, and why a check

Translating a model isn't mechanical. A caption column, a SQL view, a ratio measure, a time hierarchy: each needs a decision about what Ossie can express and what it can't. An agent makes those decisions well, and when the spec changes (it's a draft), only its guide changes.

But an agent can also be quietly wrong. The classic mistake is a ratio: sum of the ratios instead of ratio of the sums. The file looks fine and every number built on it is off.

So the server checks, with a tool the agent can't talk its way around. validate_ossie takes the document and the catalog and checks four things:

  1. Schema — the file against Ossie's JSON Schema.
  2. Names — keys, relationships and metrics name fields that exist; no metric names another.
  3. Source — every dataset, field and metric against the database, without reading a row.
  4. Parity — each metric's total, in SQL the server builds from the document, against the matching measure's total from the cube.

The server never runs SQL the agent wrote. A metric either matches, or the answer says MISMATCH with both totals.

Export: one prompt

With the agent connected to eMondrian over MCP:

"Read the Ossie guide, then write the cube of catalog OnTime as an Apache Ossie model. Validate it with validate_ossie and fix every error and mismatch. Give me the YAML."

The agent reads get_ossie_guide, writes one document per cube — tables and views become datasets, attributes become fields, keys become relationships, measures become metrics — and runs the check. On the OnTime cube (US flights in ClickHouse) all 13 of 13 metrics matched; on the FoodMart Sales cube, 8 of 8.

You can try the export side on the public demo without installing anything: connect your agent to https://demo.emondrian.com/emondrian/mcp (no sign-in) and use the prompt above. There, the OnTime model — 182 million US flights — validates with all 13 metrics matching, Flights 182,315,946 on both sides, in about two and a half seconds. The demo is read-only, so building a new cube (the import below) needs your own install.

A short excerpt of what comes out:

version: 0.3.0.dev0 name: shop_sales datasets: - name: sales source: FACT fields: - {name: store_id, expression: {sql: STORE_ID}} - {name: amount, expression: {sql: AMOUNT}, datatype: Decimal} metrics: - name: amount_total expression: {sql: SUM(amount)} custom_extensions: - {vendor_name: emondrian, data: '{"cube": "Sales", "measure": "Amount"}'} - name: store source: STORE primary_key: [store_id] fields: - {name: store_id, expression: {sql: STORE_ID}} - {name: city, expression: {sql: CITY}} relationships: - {name: sales_store, from: sales, to: store, from_columns: [store_id], to_columns: [store_id]}

And the check's last line: sales.amount_total -> [Sales].[Measures].[Amount]: match, ossie 100.00, emondrian 100.0.

Import: from another tool's model to Power BI and Excel

The other direction is the interesting one. A model written by another tool's converter can become an eMondrian cube, and then Power BI (live, over DAX), Excel PivotTables and AI agents all read the same definitions.

"Read the Ossie guide, then build a cube in catalog Shop from the Ossie model share:models/shop.yaml. Rebuild sensible hierarchies, validate it with validate_ossie, and save the schema when every metric matches."

The agent turns datasets into views, the "to" side of each relationship into a dimension, metrics into measures, and proposes hierarchies (Ossie has none). We tried it on a model from the Cube converter: two cubes built, 6 of 6 metrics matched.

One snag you'll hit today: every converter in apache/ossie-converters still writes spec 0.2, and 0.3.0.dev0 rejects it. The check says so, and the guide tells the agent how to bring the document up to date.

What a model leaves out

Ossie is deliberately small. It has no hierarchies, no roles and no row restrictions. That has two consequences you should know before you hand a file on:

  • An exported model has no access rules. Whoever loads it into another tool gets the whole model. validate_ossie ends every answer with that warning, and the agent is told to repeat it.
  • Some measures don't travel. Year-to-date, prior period, anything that depends on the current cell, and sums or ratios of distinct counts have no Ossie form. They're kept in an emondrian extension, which other tools ignore, or left out with a warning.

Parity compares totals, not totals per dimension, and it only runs where agents may read the catalog's real data: on a catalog that shows agents only synthetic data, only the structure checks run.

Try it

  • Your own data: git clone https://github.com/eMondrian/emondrian-community and ./setup.sh, connect an agent to the MCP server and use the prompts above. The tools are part of the MCP module; the free 30-day evaluation key at emondrian.com/license is enough, so you can always export your models.
  • The details: Apache Ossie models in the docs.

Do you exchange semantic models between tools today, or rebuild them by hand? Leave a comment.

eMondrian: Demo · GitHub · Docs

Sources: