Composite semantic layers are emerging because one enterprise meaning layer is rarely enough

Introduction

On July 10, 2026, the Open Semantic Interchange project publicly announced its new name: Apache Ossie (Incubating).

The project had entered the Apache Incubator in June. By the time of the July announcement, the question around semantic infrastructure had already begun to change.

Snowflake could create native semantic views from Ossie YAML and export existing semantic views back into the open format. dbt was adding Ossie support alongside its own native semantic models. The Apache project was maintaining converters between semantic systems rather than asking enterprises to replace those systems with one universal layer.

Large data estates already contain several places where business meaning is encoded.

Metrics may be governed in dbt. A warehouse may expose its own semantic objects. BI platforms carry long-lived models, calculated fields and access conventions. Domain systems hold taxonomies and entity definitions that can be richer than a metric layer. AI applications increasingly need parts of all of them.

A composite semantic layer for enterprise AI is beginning to look less like one replacement platform and more like an architecture for making those sources of meaning portable, compatible and explicit about what each one owns.

At a glance

• Enterprise semantics are increasingly spread across modelling tools, warehouses, BI platforms, catalogs and domain-specific systems rather than concentrated in one layer.
• Apache Ossie is emerging as an interchange format for metrics, dimensions and relationships so semantic definitions can move between systems without requiring direct point-to-point integration between every pair of tools.
• Current Snowflake and dbt implementations show a composite pattern: an enterprise can maintain semantics in one system while materialising or consuming them through another platform’s native semantic objects.
• Interoperability does not make every semantic system equivalent. Native features, governance rules and richer modelling constructs can survive outside the common interchange format, so enterprises still need explicit semantic ownership and translation controls.

The problem has shifted from defining semantics to moving them

The first generation of semantic-layer architecture largely assumed that the organisation needed a central place to define metrics and business terminology.

That problem still exists.

But mature enterprises already have several places where business meaning is encoded.

A finance metric may be governed in dbt’s Semantic Layer. A Snowflake team may have semantic views designed for Cortex Analyst and Cortex Agents. A long-established BI environment may contain its own trusted models. A customer platform can carry entity relationships that do not originate in the analytical stack at all.

For an agent working across those systems, the challenge is no longer simply whether semantic context exists.

The harder problem is whether the meaning defined in one system can be reused by another without being manually recreated and gradually changed.

Apache Ossie is designed around that exchange problem.

The Apache project describes Ossie as a vendor-neutral semantic model format for business metrics, dimensions, relationships and related metadata. Its converter architecture is built so systems can translate to and from a shared representation rather than requiring every semantic platform to integrate directly with every other one.

The semantic model itself can now become something that moves between platforms.

A semantic system of record and a consumption layer can be different things

One of the clearest examples appeared in dbt’s February 2026 guidance for Snowflake Intelligence.

dbt described a deliberately two-layer arrangement.

The dbt Semantic Layer can remain the place where semantic definitions are developed, reviewed, tested and maintained. Snowflake Semantic Views can provide the Snowflake-native representation consumed by Cortex Analyst and Snowflake Intelligence, as described in dbt Labs’ guidance.

Those roles can remain separate.

One system owns the lifecycle and governance of the definition. Another provides the native representation needed by the platform consuming it.

That becomes useful when the same governed annual_recurring_revenue definition needs to appear in Snowflake, an AI agent connected through dbt MCP, a BI environment and another analytical platform.

Manually recreating the logic in every destination produces several definitions that merely share an origin.

A portable semantic representation makes it possible to retain an authoritative definition while generating native forms for different consumers.

Snowflake is now round-tripping an open semantic format

Snowflake’s current implementation makes that pattern tangible.

Its Preview SYSTEM$CREATE_SEMANTIC_VIEW_FROM_OSSIE_YAML procedure accepts an Apache Ossie semantic model and creates a Snowflake Semantic View from it. Snowflake can also export an existing Semantic View back into Ossie YAML.

A native semantic object can therefore participate in an interchange workflow instead of becoming the permanent endpoint of the meaning encoded inside it.

Snowflake maps Ossie datasets, fields, relationships and metrics into its own semantic-view structures. It also preserves ai_context, version information and vendor extensions in extension metadata where those constructs do not map directly into the native representation.

The older OSI-named procedure is now deprecated in favour of the Ossie-named version.

Snowflake can keep a native semantic implementation while participating in a shared interchange model around it.

dbt is supporting native and open semantics side by side

dbt is moving toward a similar arrangement from the modelling side.

Current dbt v1.12 documentation says projects can include Apache Ossie semantic documents in an osi/ directory and parse them alongside native dbt semantic models. dbt also emits an osi_document.json artifact representing the project’s Semantic Layer.

The Apache Ossie project also maintains a dbt converter in both directions between dbt’s MetricFlow Semantic Interface and Ossie.

dbt can continue to use MetricFlow.

Snowflake can continue to use Semantic Views.

Other platforms can preserve their own native representations while exchanging a common portion of their semantic model through Ossie.

The composite layer emerges from those coordinated systems rather than from one runtime replacing all of them.

Interchange avoids an explosion of point-to-point mappings

The Apache Ossie converter architecture shows why a shared semantic format becomes useful as the number of systems grows.

Without one, every semantic platform potentially needs a translator for every other platform.

The Ossie project describes that as an N*(N-1) point-to-point problem.

With Ossie acting as the common interchange hub, each participant can instead maintain an importer and exporter against the shared representation, reducing the converter relationship to 2*N, according to the Apache Ossie converter architecture.

That becomes increasingly relevant as semantics spread beyond BI.

An enterprise may have a metric layer, warehouse semantics, an ontology-oriented domain model and agent-facing context.

A common representation gives those systems a place to exchange the portion of meaning they can represent consistently without requiring a bespoke mapping between every pair.

Portability does not mean semantic equivalence

The difficult part begins when a model crosses the boundary.

Current converter implementations already show that translation can be lossy.

The Apache Ossie dbt converter documents cases where dbt constructs do not have direct equivalents in the Ossie representation. Conversion metrics and private metrics can be dropped; some entity constructs do not survive intact; cumulative metric structures can lose detail during translation.

Snowflake handles other mismatches through extensions.

Its Ossie import/export implementation can preserve metadata that has no direct common-format equivalent inside custom extension fields, including AI context and vendor-specific information.

A successful conversion can therefore produce a valid target model while still representing less than the source.

Production teams need visibility into what crossed the boundary, what remained native and what was lost or approximated.

The common layer should carry what actually travels

Apache Ossie’s portable model focuses on concepts such as datasets, fields, metrics and relationships.

Snowflake’s current implementation can also preserve ai_context and custom extensions around that core.

The useful boundary is the part of the model that several systems can understand consistently.

Platform-specific execution behaviour can remain native.

The definition of net_revenue, for example, may travel across systems while a Snowflake-specific capability, dbt-specific metric construct or BI-tool display behaviour remains in its original environment.

This avoids turning interoperability into an attempt to flatten every platform into the same capability set.

A composite architecture can keep a stable cross-platform semantic core while retaining richer native behaviour around it.

Composite semantics need an authority map

Once several semantic systems coexist, the enterprise needs to know which one is authoritative for each kind of meaning.

Suppose an AI application can reach:

• a dbt model containing governed financial metrics;
• Snowflake Semantic Views containing warehouse-native relationships;
• a customer-domain ontology defining account hierarchies;
• a BI model with presentation-specific calculated fields.

All four may be useful.

Problems arise when more than one claims authority over the same concept.

If customer has one hierarchy in the customer domain and another inside a sales dashboard, machine readability alone cannot resolve the disagreement.

Semantic provenance therefore has to survive composition.

A translated metric should retain an identifiable source. A native materialisation should reveal which upstream definition produced it. Vendor-specific extensions should remain distinguishable from portable semantic content.

Where definitions conflict, ownership has to resolve the conflict before another translation spreads it further.

Versioning now matters across semantic boundaries

Portable semantics also create a version-coordination problem.

A metric can change in the system of record while a downstream native representation still reflects the previous version.

A converter can change its mapping behaviour.

Apache Ossie itself can evolve its specification.

Snowflake currently documents Ossie 0.1.1 as a supported specification version in its import procedure. dbt v1.12 supports Ossie 0.1.0 and 0.1.1.

Once meaning moves between semantic systems, compatibility becomes part of the semantic supply chain.

Teams need to know which specification was used, which converter produced the target representation, whether unsupported constructs were lost, which native extensions survived and when the downstream representation was last regenerated.

Otherwise, an open interchange format can still distribute an outdated or degraded definition very efficiently.

Apache incubation makes semantics an ecosystem problem

The project’s move into the Apache Incubator in June 2026 changes the governance context around the standard.

The July 10 public announcement introduced the Apache Ossie name, while Apache Incubator records show the project entering incubation in June.

The September 2026 Incubator report said the project was still working toward its first formal Apache release while continuing the migration of infrastructure and governance into the ASF process.

The contributor base also extends across several parts of the data ecosystem. Apache’s current project documentation lists participants spanning semantic-layer vendors, data platforms, catalogs, governance tools and analytics products.

That diversity matters because the semantic problem is broadening beyond metrics alone.

Catalog context, entity relationships, ontology concepts and analytical semantics increasingly meet inside the same agentic workloads.

A composite semantic architecture needs translation controls

Once enterprise meaning can move among several systems, the operating questions become concrete:

Semantic boundary	Control question
System of record	Where is this business definition actually owned and approved?
Interchange	Which part of the semantic model is represented in the shared format?
Translation	Which converter and version produced the downstream representation?
Native extension	Which meaning exists only inside the target platform?
Loss handling	Were unsupported constructs dropped, approximated or preserved as extensions?
Synchronisation	How quickly does a changed authoritative definition reach downstream semantic surfaces?
Conflict	What happens when two semantic systems define the same business concept differently?

Agents can already consume machine-readable business meaning. Composite architecture adds another problem: several systems may now participate in producing, translating and serving that meaning.

The reliability question moves into the boundaries between them.

One enterprise layer may become several coordinated layers

The instinct to build one enterprise semantic layer is understandable.

A single model promises one definition of customer, one definition of revenue and one place to govern business logic.

Large estates often arrive with BI models, modelling frameworks, warehouse-native semantics, domain vocabularies and application-specific representations already in production.

AI agents increase the pressure to reuse those assets because one task can cross several of them.

Apache Ossie is an early sign that the industry’s response may be to make semantics interoperable rather than force every existing model into one replacement runtime.

That still leaves difficult operating work: deciding authority, tracking translation loss, coordinating versions and preserving provenance as definitions move.

A composite semantic architecture succeeds only if the enterprise can share meaning across systems without becoming uncertain about where that meaning came from or what survived the journey.

FAQs

What is a composite semantic layer?

A composite semantic layer is an architecture in which multiple semantic systems participate in defining, exchanging or consuming enterprise meaning. One system may own governed definitions, another may provide a platform-native semantic model, and an open interchange format can carry shared metrics, dimensions and relationships between them.

How is a composite semantic layer different from one universal semantic layer?

A universal layer attempts to centralise meaning in one semantic system. A composite architecture accepts that several semantic systems may continue to exist and focuses on ownership, interoperability, translation and consistency across them.

What is Apache Ossie?

Apache Ossie (Incubating), formerly Open Semantic Interchange, is an open semantic interchange specification intended to let BI, AI and analytical systems exchange constructs such as datasets, metrics, dimensions and relationships through a vendor-neutral representation.

Does Apache Ossie replace dbt Semantic Layer or Snowflake Semantic Views?

No. Current implementations show dbt and Snowflake retaining their native semantic capabilities while adding Ossie-based interchange. The common format acts as a translation boundary between semantic systems rather than replacing their native runtimes.

Can semantic models be moved between platforms without losing information?

Not always. Current converter documentation already identifies constructs that do not map perfectly between semantic systems. Composite architectures therefore need visibility into translation loss, native extensions, converter versions and the authoritative source behind each downstream representation.

Interoperability changes what “one semantic layer” means

Enterprise AI still needs consistent business meaning.

The emerging architecture separates consistency from the assumption that every consumer must run against one proprietary semantic system.

A definition can have an authoritative home, move through an open interchange representation and appear inside several native semantic environments.

That creates more coordination work than a single central layer would require, but it also matches the semantic estate many large organisations already possess.

The harder engineering problem is now maintaining ownership, fidelity and traceability while meaning moves between those systems.