🇪🇺 Capa de Gobernanza Europea — Módulo Dataspaces (Gaia-X / IDSA)

Visión + Roadmap del proyecto. Este es el documento raíz del módulo: la puerta de entrada. Empieza por el destino, no por EDC.

Ubicación en el stack: docs/dataspaces/ (documentación) ↔ services/edc-service/ (runtime del conector) ↔ lib/dataspaces/ (integración Node).

🌟 Norte (North Star)

Carbon deja de ser "un Foundry interno para mid-market" y se convierte en un nodo soberano de intercambio de datos.

Cada despliegue de Carbon pasa a ser un participante de primera clase de la economía del dato europea (Gaia-X / IDSA): capaz de publicar y consumir productos de datos gobernados a través de fronteras organizativas, directo desde su lakehouse, sin mover el dato y sin Palantir/Databricks.

Esto no es una feature más. Es un layer de gobernanza europea encima de la plataforma — un gran upgrade que convierte el foso (soberanía + AI Act) de atributo a red.

🎯 Por qué (el foso, recordatorio)

Carbon apunta al mid-market vertical europeo — industrial, agroalimentario, logística, sanitario — que necesita ontología + pipelines + gobernanza pero no puede pagar Palantir ni operar Databricks. Promesa: "un Foundry operable por un equipo de 3, a precio de mid-market, con cumplimiento europeo de serie."

El foso es soberanía del dato europea + AI Act: plataforma europea, on-prem / cloud soberano, con gobernanza y lineaje nativos. Gaia-X/IDSA son la infraestructura europea de soberanía → este módulo es la extensión natural del foso.

🔭 El destino, a tres altitudes

Altitud	Qué significa
Técnica	Un conector EDC self-hosted (control + data plane + IdentityHub), uno por despliegue, cuyo data plane lee/escribe el mismo R2 + Lakekeeper de la plataforma. Identidad llave en mano (DID/VC + Gaia-X Trust Framework). Tres capas de authz coherentes. Todo dentro de fronteras.
Usuario (equipo de 3)	Pestaña "Dataspaces" en el workspace: publicar datasets/objetos como productos de datos gobernados con políticas en lenguaje llano (quién, para qué, dónde, hasta cuándo); descubrir y consumir los de socios (catálogo → contrato → aterrizaje en el lakehouse o zero-copy); lineaje que cruza la frontera de la organización.
Estratégica	El foso se vuelve red: intercambiar dato con tu cadena de valor bajo soberanía europea, sin ceder el control, con cumplimiento demostrable (credenciales verificables + contratos ODRL = evidencia ante el AI Act).

🏭 Por qué es real, no teoría (verticales)

Industrial — automoción ya lo corre en producción con EDC (Catena-X / Tractus-X). Patrón probado que llevamos al mid-market.
Sanitario — el EHDS (European Health Data Space) es reglamento europeo que obliga a un espacio de datos sanitario alineado con Gaia-X. Estamos donde empuja la regulación.
Agroalimentario / logística — trazabilidad de cadena (finca→cooperativa→distribuidor; operador→operador) compartiendo estado bajo contrato, sin entregar la base de datos.

Efecto de red: el primer cliente de un vertical hace poco; con tres intercambiando, cada nuevo cliente vale más y salir cuesta más. Eso es lo que construimos.

🧱 Arquitectura de un vistazo

CARBON (repo Node)  ──Management API (REST JSON-LD)──▶  services/edc-service/
  UI: pestaña Dataspaces                                  Control Plane (Mgmt API + DSP)
  lib/dataspaces/edc-client.ts                            Data Plane (S3 → R2)
  lib/executors/services/edc.executor.ts                  IdentityHub (DID + VC)
  worker BullMQ  ──▶  lib/lakehouse (snapshot Iceberg)         │ DSP / DCP
        │                                                       ▼
  Datos (3 niveles): R2 (bytes) · Lakekeeper (catálogo    Otros participantes
  REST Iceberg / punteros) · Supabase (metadata app)      del dataspace

Tres capas de autorización (cada una en su frontera): Clerk/RLS (usuario↔workspace) · Lakekeeper/OpenFGA (participante↔tabla) · EDC ODRL+DID/VC (organización↔organización).

Detalle completo → edc-connector-research.md.

🗺️ Roadmap (working — este es el plan que seguimos)

Convención de commits del repo: Stage N — Fase M. Estado: ✅ hecho · ▶️ en curso · ⬜ pendiente.

Fase	Objetivo	Entrega clave	Estado
0 — Recopilación	Estándares, fit con Carbon, arquitectura, foso.	edc-connector-research.md	✅
1 — PoC local aislado	2 conectores EDC locales; ciclo catálogo→negociación→transferencia. Entender la Management API.	approach · hallazgos · arnés en `services/edc-service/poc/`	✅
2 — Data plane sobre R2	Data plane S3 validado: transfer S3→S3 (MinIO) y money shot contra R2 real ✅. (Recaptura v4 se hace en Fase 3.)	approach · hallazgos · launcher propio en `services/edc-service/`	✅
3 — Cliente + executor en Node	`edc-client.ts` + `edc.executor.ts` (nº88) + rutas `app/api/dataspaces/*` + `edc-sync-worker`. Carbon maneja el conector desde Node.	approach · iteración · hallazgos	✅
4 — Consumir → lakehouse	El worker aterriza el Parquet consumido como dataset Iceberg gobernado + legible (fuente Parquet server-side, hermana de `/sync`; reúso puro). Landing verificado en vivo; auto-chain con 1 edge (transfer R2→R2).	approach · hallazgos	🟢 núcleo ✓
5 — Publicar datasets como assets	Estrategia A (copia S3/R2) → Estrategia B (zero-copy vía Lakekeeper, DataSource Iceberg custom). Asset + Contract Def + ODRL. Carbon como provider.	DataSource Iceberg	⬜
6 — Identidad de dataspace	IdentityHub / DID + VC llave en mano; Gaia-X Trust Framework.	Identidad turnkey	⬜
7 — UI + governance	Pestaña "Dataspaces": catálogo, editor de políticas en lenguaje llano, panel de negociaciones/transferencias, lineaje inter-org.	Módulo de workspace	⬜
8 — Producción	Postgres + Vault dedicados, Federated Catalog, hardening, alta en un dataspace real.	Despliegue soberano	⬜

Regla de oro del roadmap: cada fase es un escalón hacia la red, no una feature suelta. El data plane sobre R2 (F2), el zero-copy vía Lakekeeper (F5) y la identidad Gaia-X llave en mano (F6) son las tres piezas que convierten "soberanía como promesa" en "soberanía como producto operable por 3 personas".

📍 Estado actual y siguiente acción

Fase 1 ✅ (2026-07-02): ciclo DSP completo entre 2 conectores con dato real transferido (hallazgos).
Fase 2 ✅ (2026-07-02): launcher propio (services/edc-service/) + data plane S3. Transfer S3→S3 (MinIO) y money shot contra R2 real — EDC escribió en el bucket del lakehouse bajo contrato, verificado y limpiado (hallazgos). Riesgo técnico #1 retirado. EDC 0.17.0.
- Hallazgo para Fase 4: el sink S3 de EDC ignora el prefijo del keyName (escribe el basename en la raíz); controlar la clave/prefijo de destino queda para Fase 4.
Fase 3 ✅ (2026-07-02): Carbon maneja el conector desde Node. Paso 0 (api-key + v4), Paso 1 (edc-client.ts v4), Iter 1 (executor edc nº88 + credencial partner), Iter 2 (migración dataspace_* RLS + rutas app/api/dataspaces/*), Iter 3 (edc-sync-worker), Iter 4 (E2E de cola BullMQ real — enqueue → COMPLETED autónomo). Verificado en vivo contra el conector + Supabase real. Deltas v4: @type obligatorio, JSON-LD limpio, TransferRequest+dataDestination. Pendiente menor: smoke HTTP-en-app (server Clerk). hallazgos.
Fase 4 🟢 núcleo (2026-07-03): el Parquet consumido se vuelve un dataset Iceberg gobernado y legible — verificado E2E en vivo (Parquet R2 → datasets+project_files → read-router devuelve las filas con identidad). Fuente Parquet server-side en ml-runner (hermana de /sync, reúsa run_lakehouse_ingest); Node reúsa writeIcebergNativeFromParquet + createDatasetArtifact. hallazgos.
- Pendiente: el transfer EDC con source en R2 no completó (provider leyendo R2 — edge); consume no autofija el destino R2 todavía.
Siguiente: rematar el auto-chain (transfer→land) + arrancar Fase 5 (publicar / zero-copy Lakekeeper).

🗂️ Mapa de documentos del módulo

Documento	Qué es
README.md (este)	Visión + roadmap. Puerta de entrada.
edc-connector-research.md	Investigación de fondo: estándares, anatomía EDC, modelo de datos, fit con Carbon, identidad, riesgos, fuentes.
fase-1-poc-approach.md	Runbook detallado de la Fase 1 (el cimiento).
fase-1-findings.md	Hallazgos de la Fase 1 (✅ ejecutada): versiones, superficie de API, sondas.
fase-2-approach.md	Approach de la Fase 2: data plane S3 → R2, launcher propio, recaptura v4.
fase-2-findings.md	Hallazgos de la Fase 2 (✅): transfer S3→S3 (MinIO) + money shot R2 real.
fase-3-approach.md	Approach de la Fase 3 (▶️): integración Node del conector, calzada a los patrones auditados del stack.
fase-3-findings.md	Hallazgos Fase 3: Paso 0 ✅ (api-key + v4), Paso 1 ✅ (client validado + deltas v4).
fase-3-iteration-roadmap.md	Roadmap de iteración del resto de Fase 3 (executor+credencial → estado+rutas → worker → E2E).
fase-4-approach.md	Approach Fase 4: aterrizar el Parquet consumido como dataset Iceberg gobernado. Audit del camino de landing incluido.
fase-4-findings.md	Hallazgos Fase 4 + health del stack: landing E2E ✓ (dataset legible), auto-chain con 1 edge, known issues.
`services/edc-service/`	Launcher propio (base + data plane S3) + compose con MinIO + `run-cycle-s3.sh`.
`services/edc-service/poc/`	Arnés de Fase 1: 2 conectores EDC en Docker + ciclo DSP HTTP.

Documento vivo. Es el charter del proyecto y el roadmap de trabajo — mantenerlo al día al cerrar cada fase.