RFC process

Changes to the OSL spec go through a lightweight, paper-style RFC process. The spec is a contract; changes earn their way in.

1. Open an RFC at platform/spec/osl/rfcs/OSL-RFC-XXXX-slug.md.

2. Cover the problem, alternatives considered, impact, adoption plan and rollback. Pre-register what success looks like.

3. Get sign-off from the maintainers plus at least one downstream adopter.

4. Merge → status Accepted → implementation → status Implemented.

Additive by default

The extension philosophy is Kubernetes-shaped: OSL extends MetricFlow the way CRDs extend the core K8s API — additive, versioned, never breaking what already works. Pure MetricFlow stays sacred and exportable.

Examples already in the tree

• RFC 0002 — the semantic_match predicate: how a single query crosses Iceberg + Lance. (Implemented)
• RFC 0003 — relationships & resolution: the structured graph, N-N via bridges, honest structured↔unstructured joins, multi-hop traversal, fast resolution and the unified domain-map. (Implemented)

Conformance, not lock-in

Both the spec and the JSON Schemas are Apache-2.0. The custom OpenLineage facets (osl.semanticResolution, lance.retrieval, osl.policyDecisions, osl.redactions) are proposed upstream to the OpenLineage ecosystem.