¿Qué es OpenDome?

OpenDome es una plataforma de datos open-core para equipos que necesitan poner sus datos estructurados y no estructurados detrás de una única interfaz gobernada y consultable — sin cederlos a un tercero.

Corres una celda: un namespace de Kubernetes por tenant, autocontenido, que aloja tu lakehouse (Iceberg + Lance), tus pipelines y el motor de consumo. Todo lo que lee datos pasa por una sola superficie — la OpenDome Semantic Layer (OSL).

La regla: OSL es la única capa de consumo

Los datos estructurados, los no estructurados, las métricas, las entidades y el lenguaje natural se consumen exclusivamente a través de OSL. Trino, Lance y dbt son motores internos: nunca exponen un endpoint público. Ningún consumidor habla con Trino directamente.

Por qué importa

Si un consumidor puede llegar al dato sin pasar por OSL, es un bug de arquitectura — se salta el punto de aplicación de políticas y la cadena de auditoría. Una sola puerta significa un solo sitio donde gobernar, un solo sitio donde auditar, un solo sitio donde evolucionar el modelo.

Dos planos, una spec

OSL describe un modelo semántico que abarca dos sustratos físicos con un solo lenguaje declarativo en YAML:

Plano estructurado

Tablas Iceberg vía Trino. Entidades, métricas, dimensiones, contratos de datos. Aquí OSL es un superset de dbt MetricFlow — cualquier proyecto MetricFlow válido es OSL válido.

Plano no estructurado

Colecciones Lance vía LanceDB. Chunk schema, embeddings, retrieval híbrido (vector + BM25 + filtros de metadata), ACL row-level. Es la extensión OSL-only.

El puente entre ambos es la JointEntity: un objeto lógico (Customer, Policy, Order) cuya clave primaria viene de un modelo estructurado y que expone atributos de ambos planos. Una llamada, una decisión de política, una traza de auditoría. Ver Conceptos para el modelo completo.

Qué obtienes de fábrica (OSS)

La distribución Apache-2.0 es todo lo necesario para correr y consumir una celda en tu propia infraestructura:

• El data plane de la celda — charts de Helm para un tenant autocontenido y standalone.
• El motor OSL (tenant-semantic-api) sirviendo los 13 endpoints /osl/*.
• Conectores (taps Singer/Meltano: Postgres, MySQL, Salesforce, custom).
• El embedder y el retrieval sobre Lance.
• Evaluación de políticas (SQL allowlist, row filters, projection) — fail-closed.
• La especificación OSL, los JSON Schemas y un ejemplo trabajado.

OSS vs EnterpriseQué es Apache-2.0 hoy y qué añade el tier gestionado/Enterprise — la consola, el control-plane, los packs verticales y compliance.

Para quién es esto

• Adopters (el equipo de datos del cliente) — modela tu dominio en OSL, conecta fuentes, sirve métricas y retrieval gobernados. Empieza por Conceptos y luego el Quickstart.
• Agent authors — construye agentes contra las tools MCP y la REST de OSL. Ver la referencia de la API.
• Spec implementers — construye un motor OSL-conforme. Ver Spec y gobernanza.

Siguiente paso

Quickstart (autohospedado)Levanta una celda en kind/Kubernetes sin control-plane, emite un token y haz tu primera llamada gobernada.