RUBIX · TESIS CRÍTICA — qué cae cuando el producto deja de ser un motor de consultas

0 · ⭐⭐⭐ El desplazamiento, en una frase

La federación de datos es la condición de entrada — la tiene Trino, la tiene Starburst, la tiene Databricks, y competir ahí es competir en milisegundos contra gente con más ingenieros. La federación de metadatos enriquecidos —ontología, linaje, semántica, procedencia— es lo que un agente necesita y lo que nadie sirve bien todavía.

⇒ El espejo deja de ser una fase de la entrega (FD·2) y pasa a ser el núcleo. Todo lo demás —FD·3, FD·5— son consumidores suyos.

1 · Los claims revisados · cuatro caen, dos se refuerzan

③ ⛔ «El DESCRIBE del motor basta» — no para una ontología

C·5 se apuntó una victoria real: pedirle el esquema al motor devolvió los tipos ya en Spark SQL y eliminó un mapa de tipos PG→Spark hecho a mano. Sigue siendo cierto para ejecutar.

Pero una ontología no se construye con tipos físicos. varchar(36) no dice que eso sea un UUID que referencia otra entidad; int no dice que sea una clave primaria; y el comentario de la columna —que suele ser la única semántica que el cliente escribió— no aparece por ninguna parte. DESCRIBE no da claves, ni foráneas, ni constraints, ni comentarios.

⇒ El espejo necesita una segunda lectura del origen, distinta de la de ejecución (information_schema.table_constraints, key_column_usage, pg_description). Y eso refuerza I1 por un camino inesperado: el espejo no puede ser un subproducto del camino de ejecución, porque necesita cosas que ese camino no pide.

④ ⛔⛔ «El catálogo es el SoT» — deja de ser verdad en cuanto hay federación

ontology-projection asienta un CQRS: catálogo = source of truth, grafo = proyección. Para datos nativos es correcto. Para datos federados es falso: el SoT es el sistema del cliente, y nuestro catálogo ya es una proyección de él.

La cadena real tiene dos saltos, no uno:

   ORIGEN (SoT real)  ──▶  ESPEJO (proyección 1)  ──▶  ONTOLOGÍA / GRAFO (proyección 2)
      del cliente            nuestro catálogo            lo que ve el agente

Cada salto añade latencia y un modo de fallo propio, y los modos se componen: una tabla retirada en el origen puede seguir viva en el espejo y además haber generado aserciones en el grafo que ya nadie va a revisar. Un CQRS de un salto no prepara para eso.

⇒ ontology-projection necesita revisión: su premisa vale para el plano nativo y hay que acotarla explícitamente, o mentirá justo donde Rubix compite.

⑥ ⚠️ «El agente nunca ve las tablas» × RUBIX·I1 — la tensión de verdad

agentic-data-cloud dice que el agente consume conocimiento, no tablas. I1 dice que la autoridad de datos es siempre el origen en vivo.

Puestas juntas, chocan: si el agente ve el grafo y no las tablas, entonces para el agente la autoridad de facto ES la proyección. Y no se puede resolver «recalculando en vivo»: un embedding no se recalcula en cada pregunta, y un grafo de conocimiento sin materializar no es un grafo, es una consulta.

⇒ La salida honesta no es elegir: es separar los planos y decir la verdad de cada uno.

2 · Los invariantes, refinados

RUBIX·I1 (acotado) — la autoridad de datos, en el plano de EJECUCIÓN

Se mantiene entero, y ahora con su alcance escrito: plano de ejecución. Es lo que hace que un espejo rancio no pueda dar un resultado incorrecto — la propiedad que a Trino le costó #10512.

RUBIX·I2 🆕 — procedencia y edad en TODO derivado semántico

Y no se inventa el vocabulario: es literalmente para lo que existe PROV-O (Recomendación W3C), con prov:wasDerivedFrom y prov:hadPrimarySource — los mismos términos que DCAT v2/v3 importa para describir procedencia de datasets. Un sistema que alimenta agentes y no sabe decir de dónde salió una afirmación no es auditable, y en datos ajenos eso es descalificatorio.

RUBIX·I3 🆕 — reanclaje: el grafo es el ÍNDICE, el origen es la verdad

Esto resuelve la tensión ⑥ sin negar ninguna de las dos partes. El agente navega por el grafo —ahí la proyección es la autoridad, y se dice— pero cuando la respuesta necesita valores, el agente no los recita del grafo: vuelve al origen. El grafo responde «dónde mirar y qué significa»; el origen responde «cuánto».

⭐ Y da un criterio de producto tajante: una respuesta con cifras que no se pueda reanclar es un bug, no una respuesta rápida.

RUBIX·I4 🆕 — el plano semántico tiene PUERTA, o no está gobernado

Ver §4: hoy no existe, y es el agujero más grande del norte.

3 · Los estándares correctos, por plano

Rubix toca tres planos, y cada uno tiene su estándar. Mezclarlos es como se acaba inventando un formato propio para cada cosa.

⭐⭐⭐ OSI es la pieza que faltaba, y llega en el momento exacto

Open Semantic Interchange es una especificación vendor-neutral para intercambiar metadatos semánticos —datasets, métricas, dimensiones, relaciones, contextos— entre plataformas de analítica, BI y aplicaciones agénticas. Es YAML declarativo, la v1 está publicada bajo Apache 2, la respaldan 60+ organizaciones, y desde junio de 2026 está donada a la Apache Software Foundation, incubando como Apache Ossie.

Tres razones por las que esto decide el approach:

1. Es el formato de intercambio que hoy no tenemos. Nuestra ontología, si se publica en un formato propio, es un silo con otro nombre — exactamente lo que la federación viene a deshacer.
2. Está pensado para agentes, no sólo para BI. Es el vocabulario en el que un agente espera recibir «qué significa esta columna» sin que se lo expliquemos nosotros.
3. ⭐ Es la primera vez que competir en semántica no exige inventar el lenguaje. Y para un producto que quiere liderar, adoptar el estándar temprano es más barato que convertirse a él después de haber vendido un formato propio.

⇒ La ontología de Rubix debería poder EXPORTARSE e IMPORTARSE en OSI, y esa capacidad es un requisito de la entrega, no un extra. Lo interesante del caso Rubix es que OSI aplicado sobre datos FEDERADOS es territorio sin ocupar: el ecosistema OSI hoy describe semántica de datos que ya están dentro de la plataforma.

4 · ⛔⛔⛔ El agujero: el plano semántico NO TIENE PUERTA

Todo el sustrato de gobierno construido —decidePrivilege, el plan, el ledger, los securables, la cara— cuelga de runQuery. Es decir: gobierna SQL.

Un agente que consulta el grafo no pasa por ahí. Ni por el plan, ni por el ledger, ni por decidePrivilege. Hoy eso es inocuo porque el grafo casi no se usa; el día que Rubix venda GraphRAG sobre datos de clientes, significa que la mitad del producto está fuera del punto de aplicación — que es exactamente lo que el veto del 08-16 impidió para el motor, repetido en otro plano y sin que nadie lo haya vetado.

Y es peor que en SQL, por dos motivos propios de lo semántico:

• la fuga es por INFERENCIA, no por lectura: un embedding entrenado sobre una columna que el usuario no puede leer filtra su contenido aunque nunca se devuelva una fila;
• el recorrido es el ataque: catalogo-origen-del-grafo ya lo anotó — «hay que gobernar el TRAVERSING». Saber que dos entidades están conectadas ya es información.

⇒ I4 no es una fase más: es el prerrequisito de vender el plano semántico. Y hay una pieza esperando: OpenFGA está desplegado y HUÉRFANO desde el cutover — lo usaba Lakekeeper, y Gravitino no lo soporta. Su sitio natural no era nunca el catálogo de tablas: es el backend de relaciones del plano semántico, que es donde un modelo ReBAC (grafo de permisos sobre un grafo de datos) encaja de forma nativa.

5 · Qué cambia en la hoja de ruta

⚠️ Y una revisión pendiente que no es de esta entrega: ontology-projection afirma que el catálogo es el SoT. Hay que acotarlo al plano nativo antes de que alguien lo aplique a lo federado y construya encima.

6 · 📎 Fuentes