RFC-Prozess

Änderungen an der OSL-Spec durchlaufen einen leichtgewichtigen RFC-Prozess im Paper-Stil. Die Spec ist ein Vertrag; Änderungen verdienen sich ihren Weg hinein.

1. Eröffne eine RFC unter platform/spec/osl/rfcs/OSL-RFC-XXXX-slug.md.

2. Decke das Problem, die erwogenen Alternativen, die Auswirkungen, den Adoptionsplan und das Rollback ab. Registriere vorab, wie Erfolg aussieht.

3. Hol dir die Freigabe der Maintainer plus mindestens eines Downstream-Adopters.

4. Merge → Status Accepted → Implementierung → Status Implemented.

Standardmäßig additiv

Die Erweiterungsphilosophie hat die Form von Kubernetes: OSL erweitert MetricFlow so, wie CRDs die Core-K8s-API erweitern — additiv, versioniert, ohne jemals zu brechen, was bereits funktioniert. Reines MetricFlow bleibt heilig und exportierbar.

Beispiele, die bereits im Baum sind

• RFC 0002 — das semantic_match-Prädikat: wie eine einzige Query Iceberg + Lance überquert. (Implemented)
• RFC 0003 — Relationen & Resolution: der strukturierte Graph, N-N über Brücken, ehrliche strukturiert↔unstrukturiert Joins, Multi-Hop-Traversierung, schnelle Resolution und die vereinheitlichte domain-map. (Implemented)

Konformität, kein Lock-in

Sowohl die Spec als auch die JSON Schemas sind Apache-2.0. Die benutzerdefinierten OpenLineage-Facetten (osl.semanticResolution, lance.retrieval, osl.policyDecisions, osl.redactions) werden upstream dem OpenLineage-Ökosystem vorgeschlagen.