Bring your semantic models into Mosaic, without giving up portability

Quick Answer

• With Strategy's July 17, 2026 release, Apache Ossie YAML import and export is available out of the box in Mosaic Studio, following a preview in Strategy One in June 2026.

• Mosaic can import and export the common semantic structures that platforms share, including supported datasets, attributes, metrics, and relationships. It's a practical interchange workflow, not a complete backup of every Mosaic capability.

• Apache Ossie helps the definitions move. Mosaic connects those definitions to enterprise data, applies governance, executes the logic, and makes the resulting business context available across analytics and AI.

At nearly every customer conversation, one question comes up sooner or later:

If we build our business logic in Mosaic, are we going to be locked in?

It is a fair question. Companies spend years defining revenue, customer, occupancy, risk, and thousands of other business concepts. Nobody wants to rebuild that work because the warehouse changes or a new analytics or AI tool arrives.

My answer is simple: you should not have to choose between strong governance and the freedom to move your models.

That is why Strategy has been active in the open semantic standards community, first through the Open Semantic Interchange initiative and now through Apache Ossie (Incubating). The goal has stayed the same. Business definitions should be able to move across the data, analytics, and AI ecosystem without forcing customers to start over every time the stack changes.

And now this is not a roadmap slide. It is in the product. With Strategy's July 17, 2026 release, Apache Ossie YAML import and export is available out of the box in Mosaic Studio, following the preview we introduced in June.

Open standards sound great in a press release. They only matter when customers can actually use them in their daily work.

Every vendor can say it is open. Here is the practical test: can customers bring their semantic work in, and can they take the portable parts back out?

Apache Ossie gives the industry a shared YAML format for datasets, fields, dimensions, metrics, expressions, and relationships. It is readable by people and structured for tools, so teams can inspect what is moving instead of treating the model as an opaque object.

Strategy, Snowflake, Databricks, Collibra, Qlik, Salesforce, dbt Labs, and others are participating. But participation is not the proof of open standards. Shipping working import and export is.

Moving a YAML file is useful, but it is not the same as running a governed semantic layer inside an enterprise.

A file can carry definitions. It cannot connect them to physical sources, apply enterprise security, optimize queries, or keep thousands of users and agents working from the same approved meaning.

That is where Mosaic fits. It connects portable definitions to the customer's real data environment, then gives teams a place to refine the model, govern access, execute the logic, and serve consistent business context across analytics and AI. I sometimes describe Mosaic as the connective tissue. The common meaning can move, the differences stay visible, and the customer remains in control.

Most enterprises are not starting from a blank page. They already have years of business logic spread across warehouses, BI platforms, transformation projects, data products, and custom applications. The problem is that the logic is often fragmented or tied to the system where it was created.

With Apache Ossie YAML import, supported semantic work can become the starting point for a Mosaic Model.

Mosaic can reconstruct supported datasets and tables, attributes, fact metrics, semantic metrics, and common relationships instead of asking the team to rebuild every object manually.

Importing a semantic model is not just uploading a text file and hoping for the best. In Mosaic, import is where the logical definitions actually meet the physical database. Mosaic maps each source in the YAML file to a real Strategy data source and namespace. If it finds a match, it can populate that connection automatically. If it does not, the team can create a new source and choose or create the right namespace. For freeform SQL sources, the team can inspect and edit the SQL before moving forward.

The YAML describes the logic. Source mapping connects it to where the data actually lives.

Here is an operational reality check: a model can look completely valid in YAML and still hit a wall when it meets the live warehouse. That is why import and publication are distinct steps. Import reconstructs the model from the file. Publication resolves physical data types and validates key references against the connected database.

That second check catches differences between what the YAML describes and what the source actually contains. A column may have a different physical type, or a metric may reference a field that was not included in the imported dataset. I would rather catch that before the model reaches a dashboard, application, or AI agent.

For expressions, the current import uses the ANSI_SQL representation in the Apache Ossie file. If a metric uses custom logic that Mosaic cannot parse safely, Mosaic does not invent a replacement. It flags the issue, skips the affected object when necessary, and continues reconstructing the parts of the model it can use.

That is the behavior I want from an enterprise interoperability workflow.

Do not hide the problem. Do not throw away an otherwise valuable model. Tell the team what moved, what failed, and what needs attention.

Openness has to work in both directions. Customers should also be able to export the supported parts of a Mosaic Model into Apache Ossie YAML for another workflow or another platform that implements the standard.

Mosaic exports supported datasets, fields, metrics, expressions, and relationships into readable YAML. Teams can inspect the model, compare versions, review changes, and include semantic assets in Git-based and other engineering workflows.

Let me be clear about what that file is. It is a portable representation of the common semantic model, not a complete clone of the Mosaic runtime. It can support model conversion, automated validation, catalog workflows, and more reusable data products because the business context can travel with the data.

No open format can magically bridge every proprietary difference between platforms. Enterprise models contain custom functions, complex attribute logic, hierarchy behavior, security policies, execution settings, and database-specific features.

We would rather be transparent than pretend translation is always one-to-one.

The common structures move well. More specialized behavior needs review. Complex attribute form expressions may need to be modeled differently. Many-to-many relationships are not recreated through the current import. Composite joins are reduced during export. Metric dimensionality, hierarchy metadata, VLDB settings, conditional behavior, formatting, additional attribute forms, security filters, and object permissions are not fully represented in an Apache Ossie round trip today.

Take a real edge case: multi-table metrics. If your orders and returns tables both contain a field called amount, the current import can resolve both references to the same bare field name. In the worst case, SUM(orders.amount) - SUM(returns.amount) can collapse to SUM(amount) - SUM(amount), leaving you with zero. That is a metric your team needs to review and correct before publishing.

This is why portability has to include visibility and validation, not just a successful upload. Mosaic creates the objects it can, logs the ones it cannot, and lets the team review the result before publishing.

One unsupported calculation should not invalidate an otherwise useful model, but a successful import is not proof that every behavior is identical. Customers should be able to see what moved, what needs review, and what remains specific to the original platform.

The need for interoperability becomes more urgent as AI agents consume enterprise data.

A semantic layer gives an agent important structure. It defines tables, attributes, metrics, calculations, and relationships. An ontology adds more business context. It describes the entities and the verbs that connect them. A customer places an order. A hotel guest occupies a room. A policyholder files a claim.

Context also changes with the person asking the question. In hospitality, a housekeeper and a front desk clerk might both ask, "What is my occupancy today?" The words are identical, but the useful answer may be very different. One person may need rooms to service. The other may need arrivals, departures, and historical occupancy. The agent needs more than a table name. It needs to understand how the business operates and who it is helping.

The current Apache Ossie exchange focuses on the core structures of the semantic model. It does not claim that one YAML file carries every ontology, persona, governance rule, or execution behavior. It provides a practical foundation for moving the structures platforms already share while the standard continues to evolve.

That matters because definitions drift when teams recreate them separately in every AI tool. Revenue becomes one calculation in a warehouse assistant, another in a BI copilot, and a third in a custom agent. Each answer may be technically valid and still be wrong for the business context.

Ambiguity also creates more queries, retries, compute, and human review. Apache Ossie helps the definitions travel. Mosaic connects them to governed data, executes the approved logic, and gives analytics tools and AI agents a consistent place to retrieve business meaning.

For years, customers have heard vendors talk about openness while the most valuable part of the analytics environment, the business meaning, remained locked inside proprietary models.

Apache Ossie changes that conversation. It gives the industry a shared language for semantic exchange. Mosaic makes that language useful inside the enterprise by connecting it to data, governance, query execution, analytics, and AI.

Here is the bottom line. Teams can bring supported semantic work into Mosaic without starting from zero, take the portable parts back out when another tool needs them, and see where platform-specific behavior requires review.

At the end of the day, your business rules should not be trapped in any single tool, including ours. They should become more valuable as the technology stack changes and safer for AI agents to use.

Open standards move the definitions. Mosaic turns them into working business context. That is openness made operational.