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 spec/osl/rfcs/NNNN-slug.md in the platform repository (template: 0001-template.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. (Superseded by RFC 0005 — the RETRIEVE relation source.)
• 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. (Accepted; implemented slice, unreleased.)
• RFC 0004 / RFC 0005 — projection operators and OSL-SQL, the single query surface. (Accepted; reference-engine rollout implemented, unreleased.)

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.