Proces RFC

Zmiany w specyfikacji OSL przechodzą przez lekki, w stylu artykułu naukowego proces RFC. Specyfikacja to kontrakt; zmiany muszą sobie zasłużyć na wejście.

1. Otwórz RFC w platform/spec/osl/rfcs/OSL-RFC-XXXX-slug.md.

2. Opisz problem, rozważone alternatywy, wpływ, plan adopcji i rollback. Prerejestruj, jak wygląda sukces.

3. Uzyskaj akceptację od maintainerów plus co najmniej jednego downstream-adoptera.

4. Zmerguj → status Accepted → implementacja → status Implemented.

Domyślnie addytywnie

Filozofia rozszerzania ma kształt Kubernetesa: OSL rozszerza MetricFlow tak, jak CRD-y rozszerzają rdzenne API K8s — addytywnie, wersjonowanie, nigdy nie łamiąc tego, co już działa. Czysty MetricFlow pozostaje święty i eksportowalny.

Przykłady już w drzewie

• RFC 0002 — predykat semantic_match: jak pojedyncze zapytanie przekracza Iceberg + Lance. (Implemented)
• RFC 0003 — relacje i rozwiązywanie: graf ustrukturyzowany, N-N przez mosty, uczciwe joiny ustrukturyzowany↔nieustrukturyzowany, trawersacja multi-hop, szybkie rozwiązywanie i ujednolicona domain-mapa. (Implemented)

Conformance, nie lock-in

Zarówno specyfikacja, jak i JSON Schemy są Apache-2.0. Custom fasety OpenLineage (osl.semanticResolution, lance.retrieval, osl.policyDecisions, osl.redactions) są proponowane upstream do ekosystemu OpenLineage.