⭐ Ontology Projection — el catálogo escribe, el grafo lee

1 · Index no compite con Lakekeeper ni con OpenFGA: los unifica

La lectura equivocada —y estaba en el reconocimiento de F4— es tratarlo como un reparto de territorio: «si OpenFGA guarda los permisos, ¿qué le queda a Index?». Esa pregunta da por hecho que el valor está en poseer las piezas.

No lo está. El valor está en que sean UNA.

⇒ T1 del documento anterior queda disuelta, no resuelta. La pregunta «¿quién es la SSOT de permisos?» estaba mal planteada:

Un almacén no es una autoridad. principal_grants no desaparece: pasa a ser la intención declarada, y OpenFGA su forma ejecutable — la misma relación que ya existe entre «qué íbamos a hacer» y el commit de Iceberg en el ledger.

2 · 🔴 Se retira «Pod»

Por qué era poco preciso: «Pod» nombraba un objeto («el objeto de negocio gobernado e hidratado») y con eso escondía la pregunta que importa — de dónde sale y qué garantiza. Un nombre de objeto invita a construir una tabla de objetos; y en cuanto hay una tabla de Pods, hay una copia que alguien tiene que sincronizar.

Lo que lo sustituye no es otro nombre: es un mecanismo.

3 · El modelo: CQRS a nivel de datos

   ┌──────────── PLANO DE CONTROL · Write / Governance Model ──────────────┐
   │                                                                       │
   │   EL CATÁLOGO — Source of Truth                                       │
   │     · los datos, crudos y curados        (R2 · Parquet · Iceberg)     │
   │     · el linaje FÍSICO                    (snapshots, commits)        │
   │     · las políticas de seguridad y acceso (OpenFGA)                   │
   │     · la coordenada, el tier, la calidad  (Index)                     │
   │                                                                       │
   └───────────────────────────────┬───────────────────────────────────────┘
                                   │
                       PROYECCIÓN ONTOLÓGICA
                    (derivación, no importación)
                                   │
                                   ▼
   ┌──────────── PLANO DE LECTURA · Context Read-Model ────────────────────┐
   │                                                                       │
   │   EL GRAFO (Memgraph / capa semántica)                                │
   │     · relaciones semánticas y ontologías                              │
   │     · ⭐ PUNTEROS GOBERNADOS — no copias del dato                      │
   │     · optimizado para TRAVERSING de LLMs/agentes y navegación humana  │
   │                                                                       │
   └───────────────────────────────────────────────────────────────────────┘

Las tres reglas que definen el patrón:

4 · Proyección ontológica ≠ ETL de metadatos

Es la diferencia con Stardog, y ahora tiene nombre técnico:

5 · ⭐ El punto que lo hace difícil, y donde OpenFGA se gana el sitio

Un read-model tiene que estar filtrado, o revela lo que oculta.

Si un agente atraviesa el grafo y llega a un nodo que no puede leer, aunque el resolve del puntero lo deniegue, ya ha aprendido que ese nodo existe — su nombre, su tipo, sus relaciones. En un grafo de conocimiento la topología ES información: saber que «Cliente» se relaciona con «Incidencia_Legal» dice algo aunque no se lean las filas.

⇒ No basta con gobernar el resolve. Hay que gobernar el TRAVERSING.

Y ahí es donde el sustrato deja de ser una preferencia:

• las aristas del grafo semántico y las tuplas de OpenFGA son la misma clase de objeto;
• la herencia bottom-up de OpenFGA —«only items in the direct path are presented to users»— es literalmente «enséñame sólo el trozo de grafo que me toca»;
• ⇒ filtrar el grafo por permisos es un list-objects de OpenFGA, no un post-filtro que haya que programar y mantener.

6 · Lo que esto cambia en el trabajo

7 · Las tres tensiones honestas del patrón

⚠️ C1 · CQRS trae consistencia eventual — y hay que decir cuánta

El read-model va por detrás. La pregunta no es si eso pasa, sino cuánto y qué se rompe: un agente puede ver una relación que ya no existe, o no ver una que acaba de nacer.

Mitigación estructural, y es lo que hace R2 imprescindible: como el grafo guarda punteros y no dato, el peor caso es «te enseño un puntero que ya no resuelve» — molesto y recuperable. Nunca es «te doy dato obsoleto», que sería inaceptable.

⚠️ Pero sí puede ser «te enseño una relación que ya no deberías ver» si la proyección de permisos va por detrás. ⇒ los permisos NO se proyectan: se consultan en vivo contra OpenFGA. El grafo proyecta estructura, no autorización.

⚠️ C2 · La proyección necesita un disparador, y hoy NO lo tenemos

¿Cómo se entera el grafo de que el catálogo cambió? Lakekeeper emite CloudEvents… pero ya está medido (index-n0-n2-approach.md §4.1): los únicos sinks son NATS y Kafka, no corremos ninguno, y LOG_CLOUDEVENTS sólo escribe líneas de log.

⇒ La proyección arranca por PULL, exactamente como se decidió para N·2b. Push cuando la latencia lo pida, y con datos.

⚠️ C3 · Memgraph es un servicio más

Con OpenFGA ya son dos servicios nuevos. Y conviene ser explícito sobre el orden: OpenFGA sirve para algo hoy (F4, Trino); Memgraph no sirve para nada hasta que haya proyección. ⇒ OpenFGA ahora, Memgraph cuando el read-model tenga qué leer.

Cruza con: catalogo-como-origen-del-grafo.md (por qué OpenFGA) · agentic-data-cloud.md (la tesis de producto, cuyo primitivo esto corrige) · warehouse-index.md (qué es Index) · index-frontier.md (el patrón control/datos/hechos, del que esto es la continuación natural).