OSL-Spezifikation

Die OSL-Spezifikation ist der normative Vertrag (RFC 2119). Sie definiert jede Primitive, jedes Feld und jeden Fehlercode. Die Seite Konzepte lehrt das Modell; die Spec bindet es. Apache-2.0

In Bearbeitung

Die aktuelle normative Spec ist v1.2-draft (zuletzt überarbeitet 2026-06-04). Der vollständige Text wird für die Veröffentlichung unter spec.opendome.eu vorbereitet; die autoritative Quelle ist heute platform/spec/osl/v1/SPEC.md im Repository.

Versionshistorie

apiVersion: osl.opendome.eu/v1 deckt die gesamte v1.x-Linie ab. Minor-Versionen sind additiv und lese-kompatibel; Breaking Changes warten auf v2.

v1.0Basis

Das Fundament: MetricFlow-Superset (strukturierte Ebene) + UnstructuredFacet (unstrukturierte Ebene) + die JointEntity-Brücke sowie die vier Konformitätsstufen.

RFC 0002 · semantic_match · Accepted

v1.1Design

Das Beziehungs- & Auflösungsmodell: strukturiert↔strukturiert über gemeinsame Entities, N-N über Brücken, ehrliche strukturiert↔unstrukturiert-Joins auf autoritativen Schlüsseln, Multi-Hop und schnelle Auflösung.

RFC 0003 · Relationships & resolution

v1.22026-06Aktuell · Entwurf

Operationalisiert RFC 0003: L2-Traversierung, gesteuertes Content-Sampling (ACL + serverseitige Redaktion) und die vereinheitlichte Domain-Map (alles ist eine Entity; Brücken kollabieren zu Kanten). Die Konformitätsstufen Lance + Governance werden erweitert.

RFC 0003 · Implemented

v1.32026-07Nächste

Die einzige Query-Oberfläche (OSL-SQL): /osl/query wird zum einzigen Konsum-Endpoint und faltet Retrieval, Joins und Traversierung in einen semantischen SQL-Dialekt — plus Projektionsoperatoren. RFC 0002 wird von der RETRIEVE-Relationsquelle abgelöst.

RFC 0005 · OSL-SQL · DraftRFC 0004 · Projection operators · Draft

v2Zukünftig

Reserviert für Breaking Changes und Arbeit explizit außerhalb der v1.x-Grenze (z. B. content↔content-Inferenz / -Reasoning).

Die neun Primitiven

SemanticModel, Metric, SavedQuery, TimeSpine, UnstructuredFacet, JointEntity, Lexicon, DataContract, PolicyBinding. Jede trägt apiVersion: osl.opendome.eu/v1 und ein kind. Die JSON Schemas werden veröffentlicht — eines pro Primitive plus ein Master-Manifest-Schema.

RFCs

Substanzielle Änderungen durchlaufen den RFC-Prozess.

#	Titel	Status
0002	semantic_match / MATCHES-Prädikat	Abgelöst
0003	Beziehungen, Auflösung & Abfragbarkeit	Implementiert
0004	Projektionsoperatoren (Encoder + optionaler Decoder)	Entwurf
0005	OSL-SQL — die einzige Query-Oberfläche	Entwurf

Designprinzipien (verbindlich)

Wenn ein Vorschlag eines dieser Prinzipien verletzt, wird er abgelehnt:

1. Der MetricFlow-Pass-through ist heilig. Jedes gültige dbt-sl-Projekt ist gültiges OSL.
2. Lance ist gleichberechtigt, kein Add-on — eigene Primitiven, Schema, Fehler, Lineage.
3. Der Kunde deklariert, die Engine führt aus. Die Spec sagt, was existiert, nie wie es läuft.
4. Jede Entscheidung ist auditierbar — Query, Retrieval, PDP-Entscheidung emittieren alle OpenLineage.
5. Versionierung ist ein Vertrag. …/v1 bricht dein YAML für die gesamte v1-Linie nicht; Breaking Changes warten auf v2.

Versionierungsgarantie

apiVersion: osl.opendome.eu/v1 ist ein Versprechen, dein YAML über die gesamte v1-Linie nicht zu brechen. Endpoints dürfen innerhalb von v1.x optionale Felder hinzufügen; Clients müssen unbekannte Felder ignorieren. Alles, was in v1.x deprecated wird, bleibt mindestens zwei aufeinanderfolgende Minor-Versionen lang funktionsfähig; das Entfernen erfordert v2, das für dieses Fenster parallel zu v1 bereitgestellt wird.

Verwandt

• Konformitätsstufen — Core, Lance, Lineage, Governance.
• RFC-Prozess — wie man eine Änderung vorschlägt.