Solid tritt Snowflakes Open Semantic Interchange bei

Jedes große Unternehmen, mit dem ich gearbeitet habe, führt dieselbe Diskussion immer wieder: Was genau gilt als „aktiver Kunde"? Finance hat eine Definition, das Growth-Team hat eine andere, und die ML-Plattform hat still und leise eine dritte erfunden, als niemand hingeschaut hat. Semantic Layer sollten als Schiedsrichter fungieren. Bisher waren sie meistens nur ein weiterer Mitspieler auf dem Platz.

Vor diesem Hintergrund hat Solid gerade den Open Semantic Interchange unterzeichnet – die von Snowflake angeführte Initiative, um semantische Definitionen über verschiedene Tools hinweg portabel zu machen. Man kann sich das vorstellen wie den Versuch, nach zwei Jahrzehnten, in denen jeder Anbieter seine eigenen Gleise verlegt hat, eine gemeinsame Spurweite für Datenbedeutung zu schaffen.

Was passiert ist

Solid hat bekannt gegeben, dass das Unternehmen dem Open Semantic Interchange (OSI) beitritt – einer von Snowflake geleiteten Open-Source-Initiative, die eine universelle, herstellerneutrale Spezifikation für semantische Modelle schaffen soll. Die Pressemitteilung wurde am 13. Juli 2026 über PR Newswire veröffentlicht, und wie Yahoo Finance Singapore berichtete, soll OSI konsistente Metriken und Definitionen über Dashboards, Notebooks und Machine-Learning-Modelle hinweg bieten.

Das Ökosystem rund um OSI erstreckt sich bereits auf BI, Data Governance, Data Engineering, KI, Finanzdienstleistungen und Fertigung. Snowflake, das sich selbst als „the AI Data Cloud company" bezeichnet, positioniert die Spezifikation als Bindegewebe, das semantische Metadaten zwischen Plattformen transportiert, ohne jedes Mal manuell neu modelliert werden zu müssen.

Solids Ansatz konzentriert sich auf die KI-Agenten-Seite der Gleichung. Das Unternehmen beschreibt sich selbst als den KI-nativen Kontext-Layer für Enterprise-KI, der automatisch semantischen Kontext für KI-Agenten erstellt, bewertet und pflegt – anstatt für Dashboards und manuelle Modellierung entwickelt zu sein. Er benchmarkt kontinuierlich die Genauigkeit, erkennt Datenänderungen und funktioniert über jedes Data Warehouse oder jede KI-Plattform hinweg.

Yoni Leitersdorf, CEO und Mitgründer von Solid, bezeichnete den Schritt als eine Wette auf Portabilität: „Unsere Beteiligung stellt sicher, dass semantischer Kontext automatisch reibungslos zwischen KI-Agenten, Data Warehouses, BI-Tools und Analyseplattformen übertragen werden kann – und ermöglicht es Unternehmen, zuverlässige KI-Systeme auf Basis eines gemeinsamen, interoperablen Verständnisses ihres Geschäfts zu entwickeln, ohne Vendor Lock-in."

Josh Klahr, Director of Analytics Product Management bei Snowflake, nannte OSI „den entscheidenden Schritt beim Aufbau dieses Fundaments" für eine gemeinsame Basis über Daten und KI hinweg. Das Wort „Fundament" trägt hier viel Gewicht, aber die Absicht ist klar: eine Spezifikation, viele Tools.

Technische Grundlagen

Hinter der Pressemitteilungssprache verbirgt sich ein unspektakuläres, aber teures Problem. Ein Semantic Layer ist die Datei, in der man aufschreibt, was „Umsatz", „monatlich aktiver Nutzer" oder „Bruttomarge" tatsächlich in SQL, Dimensionen, Filtern und Joins bedeutet. Jedes BI-Tool hat einen. dbt hat einen. Cubes, LookML, MicroStrategy, Power BI – sie alle haben einen. Keiner davon kommuniziert mit den anderen. Wer von Tool A zu Tool B wechseln möchte, verbringt ein Quartal damit, Definitionen neu zu schreiben und über Sonderfälle zu streiten.

OSIs Vorschlag ist ein herstellerneutrales Dateiformat und eine Metadatenspezifikation, die alle diese Tools lesen und schreiben können. In der Praxis bedeutet das eine gemeinsame Methode zur Beschreibung von Entitäten, Kennzahlen, Dimensionen, Joins, Filtern, Hierarchien und – wichtig für die KI-Community – den natürlichsprachlichen Beschreibungen und Geschäftsregeln, die ein LLM benötigt, um über sie zu schlussfolgern. Wer schon einmal versucht hat, einen Agenten mit dem eigenen Warehouse zu verbinden, und dabei zugesehen hat, wie er eine Metrik halluziniert, weil er keine Ahnung hatte, was „abgesprungen" im eigenen Unternehmen bedeutet, kennt das Kernproblem.

Solids Rolle ist die Wartungsschicht. Herkömmliche Semantic Layer – wie man sie in dbt oder LookML von Hand erstellt – setzen voraus, dass ein Mensch das Geschäft modelliert und die Datei aktualisiert, wenn Dinge sich verschieben. Das funktioniert für ein stabiles Dashboard. Es scheitert in dem Moment, wenn Agenten autonome Entscheidungen auf Basis von Schemas treffen, die sich wöchentlich verändern. Solids Ansatz ist, diesen Kontext automatisch zu erstellen und neu zu bewerten, die Genauigkeit zu benchmarken und zu erkennen, wenn Datenänderungen die Bedeutung still und leise gebrochen haben.

Verbindet man beide Ideen, ergibt sich folgende Architektur: OSI definiert das Drahtformat für Semantik, Snowflake (gemäß der Snowflake-Dokumentation) stellt das Rechen- und Governance-Substrat bereit, und Solid übernimmt die Aktualitäts- und Korrektheitsproblematik auf der Agenten-Seite. Das ist die Theorie. Der langweilige Teil ist, ob die Spezifikation ausdrucksstark genug ist, um die komplexen Joins und Window Functions zu erfassen, aus denen echte Geschäftslogik besteht – oder ob sie sich mit einem kleinsten gemeinsamen Nenner begnügt, den jeder toleriert, aber niemand wirklich nutzt.

Wer verliert

Der offensichtliche Verlierer, wenn OSI an Fahrt gewinnt, ist der geschlossene Semantic Layer als Wettbewerbsvorteil. Anbieter, die jahrelang Kunden in proprietäre Modellierungssprachen eingesperrt haben, werden denselben Druck spüren wie proprietäre SQL-Dialekte, als ANSI-Standards aufkamen. Wenn das Hauptverteidigungsargument eines BI-Tools darin besteht, dass ein Wechsel das Neuschreiben von fünftausend Metrikdefinitionen bedeutet, ist ein Austauschformat eine schlechte Nachricht.

Snowflake gewinnt offensichtlich, wenn das funktioniert. Ein gemeinsamer Semantic Layer, der oberhalb des Warehouses liegt, macht das Warehouse selbst zum stabilen Anker, während die Tools darüber zu Commodities werden. Das ist dasselbe Spiel, das Databricks mit Delta und Unity Catalog betreibt. Man kann davon ausgehen, dass Databricks entweder OSI beitritt, es forkt oder in wenigen Quartalen etwas auffallend Ähnliches liefert. Meine Einschätzung: Sie werden beitreten, widerwillig, und dann über Governance-Sitze streiten.

Für die KI-nativen Analyse-Anbieter – und es gibt mittlerweile Dutzende – ist das ein Rorschach-Test. Wenn das Produkt davon abhängt, die einzige semantische Wahrheitsquelle zu sein, untergräbt ein offener Austauschstandard die eigene Position. Wenn das Produkt bei den wirklich schwierigen Aufgaben genuinen Mehrwert bietet (Kontext-Aktualität, Agenten-Ausrichtung, Evaluierung), erschließt sich ein größerer adressierbarer Markt, weil man sich in alles einklinken kann. Solid setzt eindeutig auf die zweite Lesart.

Enterprise-Datenteams haben derweil 90 Tage Kopfschmerzen vor sich. Jeder CTO, der drei überlappende Semantic-Layer-Projekte genehmigt hat, wird bald eine E-Mail von einem Architekten bekommen, der fragt, ob man pausieren, migrieren oder auf die Reifung von OSI warten soll. Wer eine Metrics-Layer-Migration miterlebt hat, weiß, dass es keine günstige Antwort gibt. Der richtige Schritt ist meistens, langsamer zu werden, nicht schneller, wenn sich ein Standard herausbildet.

Handlungsempfehlungen für Datenteams

Wer diese Woche Analyse-Infrastruktur betreibt, sollte einige konkrete Schritte unternehmen. Erstens: Prüfen, wo die Metrikdefinitionen tatsächlich gespeichert sind. Nicht wo sie sein sollen, sondern wo sie sind. In den meisten Unternehmen ist es eine Mischung aus dbt-Modellen, der proprietären Schicht eines BI-Tools, einer Wiki-Seite von 2023 und einem Slack-Thread. Kein Austauschformat lässt sich übernehmen, bevor man weiß, was man austauscht.

Zweitens: Die OSI-Spezifikation als Designbeschränkung behandeln, noch bevor man sie formal übernimmt. Wenn neue Metrikdefinitionen geschrieben werden, sollte man prüfen, ob sie eine Übersetzung in ein herstellerneutrales Format überstehen würden. Tief verschachtelte, tool-spezifische Logik ist jetzt eine Haftung. Schlichtes, portables SQL und klares dimensionales Modellieren sind Vermögenswerte.

Drittens: Wer KI-Agenten gegen das eigene Warehouse baut, sollte die Schicht „Was bedeutet diese Metrik" von der Schicht „Wie frage ich sie ab" heute trennen – auch wenn das zunächst manuell geschieht. Das ist die Schnittstelle, die OSI standardisiert, und wer die Codebasis jetzt in diese Form bringt, macht die spätere Migration zu einer Mapping-Übung statt zu einem Neuschreiben.

Viertens: Nichts herausreißen. Standards brauchen länger als Pressemitteilungen vermuten lassen. Man sollte auf echte Referenzimplementierungen, Konformitätstests und die Frage achten, ob Databricks und die großen BI-Anbieter Lese-/Schreibunterstützung liefern. Bis dahin ist OSI eine vielversprechende Richtung, keine Produktionsabhängigkeit. Für hochdurchsatzfähige Analyse-Workloads, die außerhalb der semantischen Diskussion liegen, bleiben Engines wie ClickHouse eine eigenständige Entscheidung, die in beide Richtungen unberührt bleibt.

Wichtigste Erkenntnisse

• Solid ist dem von Snowflake geführten Open Semantic Interchange beigetreten – einer Open-Source-Initiative, die eine herstellerneutrale Spezifikation für semantische Modelle über BI, Data Engineering und KI-Tools hinweg entwickelt.
• Das eigentliche Ziel sind KI-Agenten, die konsistenten Geschäftskontext benötigen, um zuverlässig über Unternehmensdaten nachzudenken – nicht nur Dashboard-Konsistenz.
• Solids Alleinstellungsmerkmal ist die automatisierte, kontinuierlich benchmarkte Pflege von semantischem Kontext im Gegensatz zu manuell modellierten, veralteten Semantic Layern.
• Geschlossene Semantic Layer verlieren ihren Wettbewerbsvorteil, wenn OSI Fahrt gewinnt; Warehouses und genuinen differenzierten Kontext-Tools gewinnen an Bedeutung.
• Datenteams sollten prüfen, wo Metrikdefinitionen tatsächlich gespeichert sind, und neue in einer Form schreiben, die eine Übersetzung in ein neutrales Format überstehen würde – ohne funktionierende Systeme bereits zu entfernen.

Zurück zur Spurweite. Der Grund, warum sich standardisierte Gleise letztlich durchgesetzt haben, war nicht, dass irgendeine Eisenbahngesellschaft den Kompromiss liebte. Es war, dass die Kosten dafür, an jeder Weiche einen Übersetzer zu haben, höher wurden als die Kosten einer Einigung. Enterprise-Daten befinden sich endlich an dieser Weiche. OSI ist möglicherweise nicht die Spurweite, auf der am Ende alle fahren, aber die Diskussion hat begonnen – und das allein verändert, was clevere Datenteams in diesem Quartal aufbauen sollten.