Sustrato · 04 — la arquitectura entera, de una pieza

1 · Qué estamos construyendo, en un párrafo

De ahí salen las tres decisiones que ordenan todo lo demás:

1. La cintura estrecha es el CATÁLOGO, no un motor. El estándar no es «rápido», es «gobernado y ontologicamente PROYECTABLE».
2. El cómputo es PLURAL y desechable. Los motores entran y salen por un registro; ninguno es la arquitectura. ⭐ Confirmado por la referencia: es exactamente lo que hace Foundry (Polars por defecto, Spark «sólo cuando el dato excede un nodo»).
3. La gobernanza emana del catálogo y el grafo la heredará por relación.

2 · El mapa, de arriba abajo

   ┌──────────────────────── SUPERFICIES ────────────────────────┐
   │  SQL Editor · dashboards · pipelines · notebooks · ontología │
   └───────────────────────────┬─────────────────────────────────┘
                               │
                    ⭐ JUNCTION — LA PUERTA (lib/compute)
                  loadItemForConsumption  ·  runQuery
                    (nuestro Furnace — ver §7·bis)
                               │
              ┌────────────────┴────────────────┐
              │                                 │
     REGISTRY DE MOTORES              LA CARA  /api/iceberg
     spark · duckdb · karma           (Iceberg REST gobernado)
     mlrunner · pg                              │
              │                                 │
              └────────────────┬────────────────┘
                               │
        ┌──────────────────────┴───────────────────────┐
        │  CINTURA ESTRECHA:  Iceberg + Lakekeeper     │
        └──────────────────────┬───────────────────────┘
                               │
                     Cloudflare R2 (Parquet)

Y en paralelo, el plano de control: PostgreSQL (Index) + OpenFGA + Keycloak.

⇒ El recorrido completo, salto a salto, está en mapa-computo.md §1.

3 · La cintura estrecha — Iceberg + Lakekeeper

Un único punto por el que pasa todo lo que es dato. No es un motor: es un formato (Apache Iceberg) y un catálogo (Lakekeeper, Iceberg REST).

Por qué esto y no un motor: un motor que aplica política sólo la aplica a sí mismo. Con la política en el catálogo vale para Spark, DuckDB, PyIceberg y lo que venga — lo que la industria llama catalog-centric.

⚠️ Y lo que Iceberg NO da: seguridad de fila y columna. Lakekeeper+OpenFGA llega hasta tabla.

4 · Las dos puertas

4·1 · Junction — la puerta del PRODUCTO

lib/compute/junction.ts. Una puerta, dos entradas (loadItemForConsumption para identidad lógica, runQuery para SQL de usuario). Resuelve catálogo lógico → binding físico → valida la tenencia TABLA POR TABLA → construye el GovernanceContext → elige motor → despacha.

⭐ La elección de motor es política de la puerta, en una función con nombre: elegirMotorDeLectura(esWrite) → hoy spark siempre, o lanza.

⛔ Sin try { spark } catch { duckdb }, y sin degradación declarada. La lección de §12·9: un fallback silencioso no causa el fallo, impide leerlo.

⭐ W4 le añadió un tercer camino: CREATE TABLE sale sin writeTarget (su destino no existe todavía) y sin plan de tablas (no tiene FROM).

4·2 · La cara — la puerta de los MOTORES

app/api/iceberg/v1/[...path]. Un Iceberg REST catalog gobernado. Hace siete cosas que un catálogo normal no (las dos últimas son de hoy):

1. Autoriza por inquilino y niega si la tabla contradice el prefijo declarado.
2. Acuña la credencial acotada a esa tabla.
3. Filtra los listados a lo que es del inquilino.
4. Resuelve nombres lógicos — diets ↔ ds_<uuid>, en las dos direcciones.
5. Firma el commit — carbon.operation-id + carbon.principal en el summary.
6. ⭐ Firma con el ID DEL LEDGER — busca la operación en vuelo y usa su id, que es lo que hace la escritura reconciliable (W3·c).
7. ⭐ MATERIALIZA las tablas nuevas — al recibir createTable da de alta el dataset en Index con el esquema del body y reenvía como ds_<uuid> (W4·2).

⭐ Las cuatro últimas comparten un porqué: son cosas que el motor no puede hacer y que, hechas aquí, valen para todos los motores a la vez. Cada vez que aparece algo así, la respuesta ha sido la misma: baja al catálogo.

⚠️ Y una que aprendió hoy: «no está» ≠ «no puedes». unknown-table devuelve 404 NoSuchTableException, no 403 — sin eso, un CREATE TABLE moría invisible en el loadTable previo.

5 · Gobernanza — quién puede qué

⚠️ DOS caminos, DOS aplicadores

Los principals

⭐ TABLE_CREATE entró en el editor con W4, y el porqué es el mismo que lo negaba: D2 lo prohibía porque «abriría un segundo camino de creación que se saltaría el registro». Con la cara materializando, no hay segundo camino: hay uno que empieza en Index. El privilegio dejó de ser la política y pasó a ser el conducto.

⛔ TABLE_DROP sigue fuera, y no es simetría: crear de más deja una tabla que sobra —contable y borrable—; soltar de menos no deja nada.

⚠️ El límite de la gobernanza de USUARIO, medido hoy

grants por principal_kind:   360 × service      usuarios con grants: 0

principal_grants sólo está poblado para servicios. ⇒ La autorización efectiva de un usuario es la pertenencia al workspace, que es lo que la puerta aplica para leer, escribir y crear. El modelo soporta kind:'user'; la capa no existe. Es el Horizonte 2, no una fase de W. Se dice en vez de fingir una granularidad que no hay.

Censo del plano de control

datasets 109 · schemas 14 · catalogs 9 · workspaces 8 · principal_grants 360
dataset_transactions where status='open'  →  0

6 · Almacenamiento y credenciales

Cloudflare R2, bucket lakehouse. El perímetro es explícito — quién toca R2: warehouse-writer RW · duck-server RO · Lakekeeper (el 4º sitio que se olvida y rompe toda escritura) · ml-runner ninguno.

⭐ Vending, no llaves estáticas: STS 900 s, acotado, con control negativo (leer su prefijo PERMITE · leer otro inquilino DENIEGA · escribir otro DENIEGA).

7 · Cómputo — plural, y detrás de la cintura

⭐ available es un eje separado de sql/read: un motor no desplegado no puede mentir sobre sí mismo.

Spark, y por qué hace falta un puente

Spark Connect no tiene cliente Node. La pieza que lo une es el puente: HTTP entra, gRPC sale. Y el número que manda sobre su diseño:

primera query 5.832 ms  ·  p50 en caliente 125 ms  ·  47×

Por eso es un servicio con estado cuyo trabajo real es sostener sesiones calientes (una por inquilino, LRU 8, inactividad 30 min). ⚠️ Y de ahí el límite: no escala en horizontal sin afinidad de sesión. Hoy, 1 réplica.

7·bis · ⭐⭐⭐ EL CAMBIO DE PARADIGMA — dónde estamos frente a Furnace y Rubix

Junction es el Furnace de Carbon, y la equivalencia es correcta en la intención y falsa en el mecanismo:

⭐⭐ Y eso explica de golpe los seis fallos de dialecto de esta semana —WITH … CREATE TABLE, el destino cualificado dos veces, el CTE capturando un DELETE, el ^ que no veía el prólogo, las 2 divergencias silenciosas, INSERT … SELECT fuera—: no eran independientes, eran el mismo, seis veces.

⇒ No falta un parser: hay uno malo, en diez sitios. Y el repo ya sabe la respuesta — catalog-sql/grammar.ts (M3) llevó la gramática de catálogo a datos «sustituyendo la cadena de 10 regex». El camino de datos sigue en regex. La dirección no hay que inventarla: hay que terminarla.

Y el sustrato frente a Rubix («K8s endurecido, HA, nodos que no viven más de 48 h, cada carga aislada, cada interacción autenticada y registrada»):

los CUATRO pods —driver, 2 executors y el puente— EN EL MISMO NODO
   4 vCPU · 16 GB · europe-west1-b · sin política de ciclo

⇒ No tenemos una malla: tenemos un nodo con cuatro pods. Sirve el editor entero, y está bien para donde estamos — pero conviene no confundirse al planificar.

8 · Dónde corre cada cosa

⛔ El techo real es la cuota: CPUS_ALL_REGIONS = 12, y la subida fue denegada (cuenta de trial), igual que Spot (PREEMPTIBLE_CPUS = 0).

⭐ Apagar y encender el cómputo es MODO DE OPERACIÓN NORMAL

«Spark no sirve» es casi siempre «Spark está apagado». Se comprueba PRIMERO:

kubectl -n spark get pods                 # vacío = apagado, no averiado
kubectl -n spark patch sparkconnectserver carbon-connect --type=merge \
  -p '{"spec":{"clusterOperation":{"stopped":false}}}'
kubectl -n spark scale deploy/spark-bridge --replicas=1

Medido: Spark + 2 executors listos en ~30 s; el puente en ~2 min.

9 · Lo que está PROBADO — con su gate

Los del 03 siguen vigentes (Spark arranca · lee por la cara · la autorización vive en el catálogo · vending acotado · latencia del puente · 8/8 de aislamiento · catálogo por sesión · dialecto derivado 16/25 · B8 la sesión sobrevive a su token · W0 · W1 · W2). Lo añadido hoy:

⚠️ Y lo que estos gates siguen sin cubrir

• Ninguna suite ejecuta runQuery en modo LECTURA de extremo a extremo. Sigue abierto desde el 03.
• El corpus de ESCRITURA nunca se midió. Es el hueco más caro (§10).
• La ruta HTTP del editor (/api/sql-editor/execute) no se puede medir desde un script: va detrás de Clerk, que responde 404 —no 401— a quien no tiene sesión.

10 · Lo que está abierto

Bloqueantes de producto

Deuda de sustrato

11 · ⭐ Las prioridades — por DAÑO, no por vistosidad

P0 · lo que YA cobra intereses
     1. corpus de ESCRITURA + ANSI   ← corrompe el dato sin que nadie mire.
                                       Y BLOQUEA la pluralidad de motores
     2. rowsAffected honesto         ← horas de trabajo, se ve cada día
     3. mantenimiento Iceberg (B7)   ← llega con el TIEMPO, no con la escala

P1 · el cambio de punto de vista
     4. consolidar el parseo del camino de DATOS  (terminar lo que M3 empezó)
     5. elegir motor por TAMAÑO      ← depende de P0·1

P2 · producto que aún no existe
     6. EXTERNAL_LINKS · time travel en SQL · vistas materializadas · Iceberg v3

P3 · sustrato  ⛔ TODO bajo el techo de CPUS_ALL_REGIONS = 12 (subida DENEGADA)
     7. malla real · un solo sitio de ejecución · rotar el secreto simétrico

⚠️ Y lo que NO está en ninguna prioridad, a propósito: «expandir Spark a toda la plataforma». La investigación dice lo contrario — Foundry pone Polars/DuckDB por defecto y Spark «sólo cuando el dato excede un nodo». Lo que se expande es la malla (P3) y la puerta (P1): que es lo que Rubix y Furnace son, cada uno en su capa.

Los horizontes, más allá

• Horizonte 2 · la gobernanza efectiva — encender OpenFGA y decidir fila/columna. Y la capa de usuario, que hoy no existe.
• Horizonte 3 · la proyección ontológica — CQRS a nivel de datos: el catálogo es el SoT de escritura, el grafo un read-model proyectado. La cuña frente a Stardog es que nuestro catálogo es NATIVO: ellos importan metadata, nosotros heredamos.
• Horizonte 4 · los agentes — el agente NUNCA ve las tablas. Consume el grafo proyectado. Ése es el producto: Agentic Data Cloud.

12 · Las reglas que la práctica dejó

Las 17 del 03 siguen vigentes. Lo que añadió esta jornada:

18. ⭐⭐⭐ Cada cambio de motor deja atrás piezas que asumían el anterior — y no las caza ni el compilador ni los tests. Se repitió tres veces el mismo día: el literal engine:'duckdb' del ledger, el alias 'lake' de la cualificación, y el ancla ^ que no veía el prólogo. ⇒ Al cambiar de motor, buscar los literales del viejo (grep 'duckdb', grep "'lake'") es parte del cambio, no una limpieza.
19. ⭐⭐⭐ Un gate que mide con «lo que le venía bien» no mide el sistema. Todos los gates de escritura pasaban el nombre pelado (ds.name); un usuario escribe UPDATE main.default.diets. La regresión llegó a producción por esa diferencia. Es §12·2 llevada al extremo: la sonda tiene que usar el vocabulario del usuario, no el que le resulta cómodo.
20. ⭐⭐ Un censo que ve una parte no cuenta de menos: cuenta MAL. Dos veces: listNamespaces sin ?parent= devuelve sólo el primer nivel (23 de 144 tablas, y declaró fantasma una tabla viva), y medir por la cara subcuenta porque filtra al inquilino a propósito. Para censar: al catálogo directo y recorrer el árbol.
21. ⭐⭐ Antes de construir un mecanismo, buscar si el repo ya lo tiene. La idempotencia del DML no se construyó: ya existía (lib/sdk/idempotency.ts, el contrato de Stripe completo). Montar el segundo habría sido dos sitios donde decidir lo mismo.
22. ⭐⭐ Un aborted sin su prueba al lado es lo que la regla prohíbe; con la prueba, es reconciliación. Las 12 transacciones que ratify no podía cerrar se cerraron demostrando algo más fuerte que lo que se buscaba: «la tabla no publicó un solo snapshot en toda la ventana». ⇒ Cuando la pregunta no tiene respuesta, buscar otra pregunta que sí la tenga — y escribir la evidencia en el propio asiento.
23. ⭐ La idempotencia sólo funciona si la clave la pone quien sabe que dos peticiones son la misma operación, y ése es el cliente. Una clave nueva por ejecución —el primer intento— no deduplica nada. Y sólo se cachea el éxito: cachear un fallo vuelve permanente un error transitorio.
24. ⭐ Una migración se auto-verifica, y con su negativo. DROP CONSTRAINT IF EXISTS sobre un nombre que no casa no falla y no hace nada. Se comprueba el estado: que lo nuevo pasa y que lo inválido sigue rechazado.
25. ⭐⭐⭐ El fallo estructural de esta semana fue tratar el SQL como TEXTO. Seis bugs distintos, una sola causa. ⇒ Cuando varios fallos comparten forma, no son varios fallos.

13 · Los documentos que importan

Los gates que se corren, y contra qué

npx dotenv -e .env.local -- npx tsx scripts/governance/w3-b-gate-puerta-escribe.ts   # ¿escribe el camino del producto?
npx dotenv -e .env.local -- npx tsx scripts/governance/w3-c-gate-atribucion.ts       # ¿es reconciliable?
npx dotenv -e .env.local -- npx tsx scripts/governance/w3-d-gate-idempotencia.ts     # ¿deduplica un reintento?
npx dotenv -e .env.local -- npx tsx scripts/governance/w4-gate-create-table.ts       # ¿se puede crear una tabla?
npx dotenv -e .env.local -- npx tsx scripts/governance/w4-0-gate-no-esta.ts          # 200 / 404 / 403
npx dotenv -e .env.local -- npx tsx scripts/governance/w5-0-reconocimiento.ts        # la cola del ledger
npx dotenv -e .env.local -- npx tsx scripts/governance/w5-c-censo-deriva.ts          # Index ↔ físico
npx dotenv -e .env.local -- npx tsx scripts/governance/s5-0-principals-gate.ts       # la forma de cada principal
npx tsx scripts/bridge/b6-gate-motor.ts <origen>                                     # ¿qué motor sirve?