Especificación OSL

La especificación OSL es el contrato normativo (RFC 2119). Define cada primitiva, cada campo y cada código de error. La página de Conceptos enseña el modelo; la spec lo vincula.

Apache-2.0

En redacción

La spec normativa actual es v1.2-draft (última revisión 2026-06-04). El texto completo se está preparando para su publicación en spec.opendome.eu; la fuente autoritativa hoy es platform/spec/osl/v1/SPEC.md en el repositorio.

Historial de versiones

apiVersion: osl.opendome.eu/v1 cubre toda la línea v1.x. Las versiones menores son aditivas y compatibles en lectura; los cambios incompatibles esperan a v2.

v1.0Base

La base: superset de MetricFlow (plano estructurado) + UnstructuredFacet (plano no estructurado) + el puente JointEntity, y los cuatro niveles de conformidad.

RFC 0002 · semantic_match · Accepted

v1.1Diseño

El modelo de relaciones y resolución: estructurado↔estructurado vía entidades compartidas, N-N vía bridges, joins honestos estructurado↔no estructurado sobre claves autoritativas, multi-salto y resolución rápida.

RFC 0003 · Relationships & resolution

v1.22026-06Actual · borrador

Operacionaliza RFC 0003: travesía L2, muestreo de contenido gobernado (ACL + redacción server-side) y el domain-map unificado (todo es una Entity; los bridges colapsan a aristas). Los niveles de conformidad Lance + Governance se amplían.

RFC 0003 · Implemented

v1.32026-07Siguiente

La superficie única de consultas (OSL-SQL): /osl/query pasa a ser el único endpoint de consumo, plegando retrieval, joins y travesía en un solo dialecto de SQL semántico — más los operadores de proyección. RFC 0002 queda reemplazada por la fuente de relación RETRIEVE.

RFC 0005 · OSL-SQL · DraftRFC 0004 · Projection operators · Draft

v2Futuro

Reservada para cambios incompatibles y trabajo explícitamente fuera del límite v1.x (p. ej. inferencia / razonamiento contenido↔contenido).

Las nueve primitivas

SemanticModel, Metric, SavedQuery, TimeSpine, UnstructuredFacet, JointEntity, Lexicon, DataContract, PolicyBinding. Cada una lleva apiVersion: osl.opendome.eu/v1 y un kind. Los JSON Schemas se publican uno por primitiva más un schema maestro de manifest.

RFCs

Los cambios sustantivos pasan por el proceso RFC.

#	Título	Estado
0002	Predicado semantic_match / MATCHES	Reemplazada
0003	Relaciones, resolución y consultabilidad	Implementada
0004	Operadores de proyección (encoder + decoder opcional)	Borrador
0005	OSL-SQL — la superficie única de consultas	Borrador

Principios de diseño (vinculantes)

Si una propuesta rompe uno de estos, se rechaza:

1. El pass-through de MetricFlow es sagrado. Cualquier proyecto dbt-sl válido es OSL válido.
2. Lance es de primera clase, no un add-on — sus propias primitivas, schema, errores, lineage.
3. El cliente declara, el motor ejecuta. La spec dice qué existe, nunca cómo corre.
4. Cada decisión es auditable — query, retrieval, decisión del PDP, todas emiten OpenLineage.
5. El versionado es un contrato. …/v1 no romperá tu YAML en toda la línea v1; los cambios incompatibles esperan a v2.

Garantía de versionado

apiVersion: osl.opendome.eu/v1 es una promesa de no romper tu YAML en toda la línea v1. Los endpoints pueden añadir campos opcionales dentro de v1.x; los clientes deben ignorar los campos no reconocidos. Cualquier cosa deprecada en v1.x sigue funcionando durante al menos dos versiones menores consecutivas; su eliminación requiere v2, servida junto a v1 durante esa ventana.

Relacionado

• Niveles de conformidad — Core, Lance, Lineage, Governance.
• Proceso RFC — cómo proponer un cambio.