Processus RFC

Les changements à la spec OSL passent par un processus RFC léger, façon paper. La spec est un contrat ; les changements gagnent leur place.

1. Ouvrez une RFC dans platform/spec/osl/rfcs/OSL-RFC-XXXX-slug.md.

2. Couvrez le problème, les alternatives envisagées, l’impact, le plan d’adoption et le rollback. Pré-enregistrez à quoi ressemble le succès.

3. Obtenez la validation des mainteneurs plus au moins un adoptant downstream.

4. Merge → statut Accepted → implémentation → statut Implemented.

Additif par défaut

La philosophie d’extension a la forme de Kubernetes : OSL étend MetricFlow de la même manière que les CRDs étendent l’API core de K8s — additif, versionné, sans jamais casser ce qui fonctionne déjà. MetricFlow pur reste sacré et exportable.

Exemples déjà dans l’arbre

• RFC 0002 — le prédicat semantic_match : comment une seule query traverse Iceberg + Lance. (Implemented)
• RFC 0003 — relations et résolution : le graphe structuré, N-N via bridges, joins honnêtes structuré↔non structuré, traversée multi-hop, résolution rapide et le domain-map unifié. (Implemented)

Conformité, pas lock-in

La spec comme les JSON Schemas sont en Apache-2.0. Les facettes OpenLineage custom (osl.semanticResolution, lance.retrieval, osl.policyDecisions, osl.redactions) sont proposées upstream à l’écosystème OpenLineage.