Skip to content
RiverCore
Solid Joins Snowflake's Open Semantic Interchange Push
Open Semantic Interchangesemantic layerenterprise AIvendor-neutral semantic layer for AI agentsportable semantic definitions across data tools

Solid Joins Snowflake's Open Semantic Interchange Push

26 Jul 20267 min readJames O'Brien

Every large company I've worked with has a version of the same argument on repeat: what exactly counts as an "active customer"? Finance has one definition, the growth team has another, and the ML platform quietly invented a third when nobody was looking. Semantic layers were supposed to be the referee. So far they've mostly been another player on the pitch.

That's the backdrop against which Solid has just signed up to the Open Semantic Interchange, the Snowflake-led effort to make semantic definitions portable across tools. Think of it as trying to build a common rail gauge for data meaning, after two decades of every vendor laying their own track.

What Happened

Solid announced it's joining the Open Semantic Interchange (OSI), an open source initiative led by Snowflake that aims to create a universal, vendor-neutral specification for semantic models. The press release went out via PR Newswire on July 13, 2026, and, as Yahoo Finance Singapore carried it, the pitch is that OSI will provide consistent metrics and definitions across dashboards, notebooks, and machine learning models.

The ecosystem around OSI already spans BI, data governance, data engineering, AI, financial services, and manufacturing. Snowflake, styling itself "the AI Data Cloud company," is positioning the spec as the connective tissue that lets semantic metadata move between platforms without being re-modelled by hand each time.

Solid's angle is the AI-agent side of the equation. The company describes itself as the AI-native context layer for enterprise AI, one that automatically creates, evaluates, and maintains semantic context for AI agents rather than being built for dashboards and manual modeling. It continuously benchmarks accuracy, detects data changes, and works across any data warehouse or AI platform.

Yoni Leitersdorf, Solid's CEO and Co-Founder, framed the move as a bet on portability: "Our participation ensures that semantic context can automatically move smoothly across AI agents, data warehouses, BI tools, and analytics platforms, enabling organizations to build reliable AI systems on top of a shared, interoperable understanding of their business, without vendor lock-in."

Josh Klahr, Director of Analytics Product Management at Snowflake, called OSI "the critical step in building that bedrock" for a common foundation across data and AI. The word "bedrock" is doing a lot of heavy lifting there, but the intent is clear: one spec, many tools.

Technical Anatomy

Strip away the press release language and OSI is trying to solve a boring but expensive problem. A semantic layer is the file where you write down what "revenue," "monthly active user," or "gross margin" actually means in SQL, dimensions, filters and joins. Every BI tool has one. dbt has one. Cubes, LookML, MicroStrategy, Power BI, they all have one. None of them talk to each other. If you want to move from tool A to tool B, someone spends a quarter re-writing definitions and arguing about edge cases.

OSI's proposition is a vendor-neutral file format and metadata specification that any of these tools can read and write. In practice that means a shared way to describe entities, measures, dimensions, joins, filters, hierarchies, and, importantly for the AI crowd, the natural-language descriptions and business rules an LLM needs to reason about them. If you've ever tried wiring an agent to query your warehouse and watched it hallucinate a metric because it had no idea what "churned" means at your company, you know the guts of the problem.

Where Solid fits in is the maintenance layer. Traditional semantic layers, of the sort you'd hand-craft in dbt or LookML, assume a human sits down, models the business, and updates the file when things drift. That works for a stable dashboard. It falls over the moment you have agents making autonomous decisions on top of schemas that mutate weekly. Solid's pitch is that it automatically creates and re-evaluates that context, benchmarks accuracy, and flags when data changes have quietly broken the meaning.

Marry the two ideas and the architecture is: OSI defines the wire format for semantics, Snowflake (per the Snowflake docs) provides the compute and governance substrate, and Solid handles the freshness and correctness problem on the agent side. That's the theory. The boring bit is whether the spec is expressive enough to capture the messy joins and window functions that make up real business logic, or whether it settles for a lowest-common-denominator that everyone tolerates and nobody actually uses.

Who Gets Burned

The obvious loser here, if OSI gets traction, is the closed semantic layer as a moat. Vendors who've spent years locking customers into proprietary modeling languages are going to feel the pressure the same way proprietary SQL dialects did once ANSI standards showed up. If your BI tool's main defensibility is that migrating away means re-writing five thousand metric definitions, an interchange format is bad news.

Snowflake, obviously, wins if this works. A shared semantic layer that lives above the warehouse makes the warehouse itself the stable anchor while tools above it commoditise. That's the same play Databricks has been running with Delta and Unity Catalog. Expect Databricks to either join OSI, fork it, or ship something suspiciously similar within a few quarters. My take: they'll join, grudgingly, and then argue about governance seats.

For the AI-native analytics vendors, and there are dozens now, this is a Rorschach test. If your product depends on being the single source of semantic truth, an open interchange erodes your position. If your product is genuinely better at the hard bits (context freshness, agent alignment, evaluation), you get a bigger addressable market because you can plug into anything. Solid is clearly betting on the second reading.

Enterprise data teams, meanwhile, get a 90-day headache. Every CTO who's approved three overlapping semantic layer projects is about to get an email from an architect asking whether they should pause, migrate, or wait for OSI to mature. Anyone who's lived through a metrics-layer migration knows there's no cheap answer. The right move is usually to slow down, not speed up, when a standard is forming.

Playbook for Data Teams

If you're running analytics infrastructure this week, a few concrete moves. First, audit where your metric definitions actually live. Not where they're supposed to live, where they are. In most shops it's a mix of dbt models, one BI tool's proprietary layer, a wiki page from 2023, and a Slack thread. You can't adopt any interchange format until you know what you're interchanging.

Second, treat the OSI spec as a design constraint even before you formally adopt it. When you're writing new metric definitions, ask whether they'd survive a translation to a vendor-neutral format. Deeply nested tool-specific logic is a liability now. Boring, portable SQL and clear dimensional modeling are assets.

Third, if you're building AI agents against your warehouse, separate the "what does this metric mean" layer from the "how do I query it" layer today, even if you're doing it manually. That's the interface OSI is standardising, and getting your codebase into that shape now means the migration later is a mapping exercise, not a rewrite.

Fourth, don't rip anything out. Standards take longer than press releases suggest. Watch for real reference implementations, conformance tests, and whether Databricks and the major BI vendors ship read/write support. Until then, OSI is a promising direction, not a production dependency. For high-throughput analytical workloads that sit outside the semantic conversation, engines like ClickHouse remain their own decision, unaffected either way.

Key Takeaways

  • Solid has joined the Snowflake-led Open Semantic Interchange, an open source initiative building a vendor-neutral spec for semantic models across BI, data engineering, and AI tools.
  • The real target is AI agents that need consistent business context to reason reliably about enterprise data, not just dashboard consistency.
  • Solid's differentiator is automated, continuously benchmarked semantic context maintenance, versus legacy hand-modeled semantic layers.
  • Closed semantic layers lose defensibility if OSI gets traction; warehouses and genuinely differentiated context tooling gain use.
  • Data teams should audit where metric definitions actually live and start writing new ones in a shape that would survive translation to a neutral format, without ripping out working systems yet.

Back to the rail gauge. The reason standardised track eventually won wasn't that any one railway loved the compromise. It was that the cost of every junction having a translator got worse than the cost of agreeing. Enterprise data is finally at that junction. OSI might not be the gauge everyone ends up running on, but the argument has started, and that on its own changes what smart data teams should be building this quarter.

Frequently Asked Questions

Q: What is the Open Semantic Interchange?

OSI is an open source initiative led by Snowflake that creates a universal, vendor-neutral specification for semantic models, so metric and dimension definitions can move consistently across BI tools, notebooks, data warehouses, and machine learning platforms.

Q: How is Solid different from a traditional semantic layer?

Solid describes itself as an AI-native context layer that automatically creates, evaluates, and maintains semantic context for AI agents, continuously benchmarking accuracy and detecting data changes. Legacy semantic layers are built for dashboards and manual modeling, which struggles when agents act on rapidly changing schemas.

Q: Should data teams adopt OSI right now?

Not as a production dependency yet. The sensible move is to audit where your metric definitions live, write new ones in a portable shape, and watch for reference implementations and support from other major vendors before committing to a migration.

JO
James O'Brien
RiverCore Analyst · Dublin, Ireland
SHARE
// RELATED ARTICLES
HomeSolutionsWorkAboutContact
News06
Dublin, Ireland · EUGMT+1
LinkedIn
🇬🇧EN▾