## Asset Header - **Asset ID:** ARQ-XX-DOIX-CorpBrainOS-Supabase-v01 - **Version:** v01 - **Status:** Draft - **Owner:** Victor Heredia - **IntellBank:** IB-XX-Maestro - **Tipo:** ARQ — Architecture - **Propósito:** Corp Brain OS — Arquitectura Supabase - **Última actualización:** 2026-04-11 --- asset_id: DOC-CorpBrainOS-Arquitectura-Supabase-v01 tipo: Documento Técnico de Arquitectura version: v1.0 proyecto: DOIX — EmpowerLabs Piloto 0 owner: Victor Heredia / EmpowerLabs sherpa: Jacob fecha: 2026-03-31 estado: Borrador activo tags: [BrainOS, Supabase, IntelliBank, DOIX, SherpaX, arquitectura, seguridad] --- # Corp Brain OS — Arquitectura Supabase ## Diseño de infraestructura para DOIX en EmpowerLabs (Piloto 0) --- ## PRINCIPIO FUNDACIONAL > **El IntelliBank no se distribuye. Se ensambla.** El error de diseño más común en sistemas de IA organizacional es tratar el conocimiento como archivos que se copian y distribuyen. En la arquitectura Corp Brain OS, el IntelliBank es una base de datos particionada. Cada persona no "tiene" un kit estático — cada vez que abre una sesión, el sistema ensambla en tiempo real el contexto que le corresponde según su rol, área y nivel de acceso. **Consecuencia directa:** Nadie puede llevarse el IntelliBank. Nadie puede acceder a lo que no le corresponde. Si alguien sale de la organización, su acceso desaparece instantáneamente. Esto no es solo seguridad técnica — es la materialización arquitectónica del Principio 1 de DOIX: *el contexto es infraestructura, no privilegio*. --- ## VISIÓN GENERAL DEL SISTEMA ``` ┌─────────────────────────────────────────────────────────────┐ │ CORP BRAIN OS │ │ (1 proyecto Supabase) │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ CAPA DE ALMACENAMIENTO │ │ │ │ (IntelliBank Particionado) │ │ │ │ │ │ │ │ corp_shared ──────── acceso universal (lectura) │ │ │ │ area_ops ─────────── solo Operaciones │ │ │ │ area_rh ──────────── solo RH + CEO │ │ │ │ area_finanzas ─────── solo Finanzas + CEO │ │ │ │ area_comercial ────── solo Comercial + CEO │ │ │ │ area_tech ─────────── solo Tech + CEO │ │ │ └──────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ CAPA DE CONTROL DE ACCESO │ │ │ │ (RBAC + RLS) │ │ │ │ │ │ │ │ CEO ──────────────── ALL schemas R/W │ │ │ │ Director de Área ──── corp_shared R + área propia │ │ │ │ Miembro de Área ───── corp_shared R + área propia R │ │ │ │ SherpaX Agent ─────── contexto ensamblado only │ │ │ └──────────────────────────────────────────────────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ KIT ASSEMBLER │ │ │ │ (el mecanismo central de seguridad) │ │ │ │ │ │ │ │ f(usuario, rol, área, proyecto) → │ │ │ │ → contexto efímero para la sesión │ │ │ │ → no se almacena, expira al cerrar sesión │ │ │ └──────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ ``` --- ## CAPA 1: ESTRUCTURA DE DATOS EN SUPABASE ### Schemas (uno por área + compartido) | Schema | Propósito | Quién puede acceder | |--------|-----------|---------------------| | `corp_shared` | Cultura, valores, procesos transversales, playbooks corporativos, memoria organizacional | TODOS (lectura). Admins (escritura). | | `area_ops` | Protocolos de operación, proveedores, procesos internos | Director Ops + equipo Ops + CEO | | `area_rh` | Perfiles de colaboradores, políticas de personal, datos de compensación | Director RH + CEO únicamente | | `area_finanzas` | P&L, presupuestos, flujo de caja, proyecciones | Director Finanzas + CEO únicamente | | `area_comercial` | Pipeline, clientes, propuestas, estrategia comercial | Equipo comercial + CEO | | `area_tech` | Arquitectura, documentación técnica, deuda técnica | Equipo tech + CEO | ### Tabla estándar en cada schema Cada schema tiene la misma estructura de tabla base — esto permite queries uniformes desde el Kit Assembler: ```sql -- Tabla: intellibank_entries (replicada en cada schema) CREATE TABLE {schema}.intellibank_entries ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), tipo TEXT, -- 'playbook' | 'protocolo' | 'criterio' | 'memoria' | 'contexto_rol' titulo TEXT NOT NULL, contenido TEXT NOT NULL, autor_id UUID REFERENCES auth.users(id), area TEXT, -- redundante para queries cross-schema por CEO version TEXT DEFAULT 'v1.0', tags TEXT[], activo BOOLEAN DEFAULT true, fecha_creacion TIMESTAMPTZ DEFAULT now(), fecha_update TIMESTAMPTZ DEFAULT now() ); -- Row Level Security habilitado en todas las tablas ALTER TABLE {schema}.intellibank_entries ENABLE ROW LEVEL SECURITY; ``` ### Tabla de perfiles de usuarios ```sql -- En schema: corp_shared CREATE TABLE corp_shared.user_profiles ( user_id UUID REFERENCES auth.users(id) PRIMARY KEY, nombre TEXT NOT NULL, rol TEXT, -- 'ceo' | 'director' | 'member' | 'externo' area TEXT, -- 'ops' | 'rh' | 'finanzas' | 'comercial' | 'tech' nivel_acceso INTEGER, -- 1-5, controla granularidad del kit activo BOOLEAN DEFAULT true, sherpax_config JSONB -- configuración personalizada de su SherpaX ); ``` --- ## CAPA 2: CONTROL DE ACCESO (RBAC + Row Level Security) ### Matriz de permisos | Rol | corp_shared | área propia | otras áreas | área_rh | área_finanzas | |-----|-------------|-------------|-------------|---------|---------------| | CEO | R/W completo | R/W completo | R/W completo | R/W | R/W | | Director de Área | Lectura | R/W completo | ✗ | ✗ | ✗ | | Miembro de Área | Lectura | Lectura | ✗ | ✗ | ✗ | | Externo / Cliente | Solo subset de corp_shared | ✗ | ✗ | ✗ | ✗ | ### Políticas RLS (Row Level Security) Supabase ejecuta estas políticas en cada query — el acceso se verifica a nivel de fila, no solo de tabla: ```sql -- Política para corp_shared: todos los usuarios activos pueden leer CREATE POLICY "corp_shared_read" ON corp_shared.intellibank_entries FOR SELECT USING ( EXISTS ( SELECT 1 FROM corp_shared.user_profiles WHERE user_id = auth.uid() AND activo = true ) ); -- Política para área restringida (ej: área_rh): solo director RH o CEO CREATE POLICY "area_rh_read" ON area_rh.intellibank_entries FOR SELECT USING ( EXISTS ( SELECT 1 FROM corp_shared.user_profiles WHERE user_id = auth.uid() AND activo = true AND (area = 'rh' OR rol = 'ceo') ) ); -- Escritura: solo directores y CEO pueden agregar al IntelliBank CREATE POLICY "intellibank_write" ON {schema}.intellibank_entries FOR INSERT USING ( EXISTS ( SELECT 1 FROM corp_shared.user_profiles WHERE user_id = auth.uid() AND rol IN ('ceo', 'director') AND (area = '{area}' OR rol = 'ceo') ) ); ``` --- ## CAPA 3: KIT ASSEMBLER — El mecanismo central Este es el componente más importante de la arquitectura. El Kit Assembler reemplaza la distribución de archivos estáticos (el problema de seguridad del modelo actual). ### Lógica de ensamblaje ```javascript async function assembleContextKit(userId) { const user = await getUserProfile(userId); let kit = { identity: {}, // quién es el usuario en la org shared: [], // IntelliBank corporativo area: [], // IntelliBank del área role: [], // instrucciones específicas del rol projects: [] // contexto de proyectos activos }; // 1. SIEMPRE incluir — contexto corporativo compartido kit.shared = await query(` SELECT titulo, contenido, tipo FROM corp_shared.intellibank_entries WHERE activo = true ORDER BY tipo, fecha_update DESC LIMIT 50 `); // 2. Contexto de área (RLS hace el control de acceso automáticamente) kit.area = await query(` SELECT titulo, contenido, tipo FROM area_${user.area}.intellibank_entries WHERE activo = true ORDER BY tipo, fecha_update DESC `); // 3. Perfil del rol (instrucciones de comportamiento del SherpaX) kit.role = await query(` SELECT * FROM corp_shared.sherpax_configs WHERE area = '${user.area}' AND rol = '${user.rol}' `); // 4. Proyectos activos del usuario kit.projects = await query(` SELECT * FROM corp_shared.proyectos_activos WHERE '${userId}' = ANY(participantes) AND estado = 'activo' `); // 5. Ensamblar como string de contexto para Claude return formatAsClaudeContext(kit); // → este string va al CLAUDE.md efímero de la sesión // → NUNCA se guarda en disco // → expira cuando la sesión termina } ``` ### Por qué esto es más seguro que el modelo actual | Modelo actual (archivos) | Corp Brain OS (dinámico) | |--------------------------|--------------------------| | CLAUDE.md estático en disco | Contexto ensamblado en RAM, efímero | | Si alguien accede al disco, tiene todo | No hay "todo" en ningún lugar | | Actualizar = editar archivos manualmente | Actualizar = entry en DB, aplica a todos en tiempo real | | Si un colaborador sale, hay que ir a buscar sus archivos | Desactivar user_id = acceso cortado inmediatamente | | No hay audit trail de qué vio quién | Supabase logs cada query con timestamp + user_id | --- ## CAPA 4: PROTOCOLO DE SINCRONIZACIÓN ### Flujo de actualización del IntelliBank ``` COLABORADOR detecta nuevo aprendizaje en sesión │ ▼ Propone IntelliBank Update (IBU) → Tipo: playbook / protocolo / criterio / memoria → Área: la suya → Contenido: el aprendizaje │ ▼ Director de Área revisa y aprueba → Si aprueba: entry se activa en DB (visible para todos del área en próxima sesión) → Si rechaza: se devuelve con feedback │ ▼ Si es conocimiento transversal → Director propone a CEO para corp_shared │ ▼ Supabase Realtime notifica a sesiones activas → "IntelliBank actualizado. Reinicia sesión para incorporar." ``` ### Cadencia de actualización recomendada | Frecuencia | Tipo de actualización | |------------|----------------------| | Post-sesión (inmediato) | Decisiones de proyecto, nuevos criterios, errores documentados | | Semanal | Review de IntelliBank del área — ¿qué aprendimos esta semana? | | Mensual | Revisión de corp_shared — ¿qué nuevo conocimiento es transversal? | | Trimestral | Auditoría completa — ¿qué entries ya no son relevantes? (activo = false) | --- ## CAPA 5: SEGURIDAD EN PROFUNDIDAD ### Para el Corp Brain OS en Supabase | Amenaza | Mecanismo de mitigación | |---------|-------------------------| | Empleado accede a datos de otro área | RLS a nivel de fila — imposible desde la aplicación | | Empleado descarga el IntelliBank completo | No existe "IntelliBank completo" — es particionado y se ensambla efímeramente | | Empleado sale y sigue usando su SherpaX | Desactivar user_id corta acceso en tiempo real | | Acceso no autorizado a Supabase | Service Role Key nunca expuesta al cliente; Row Level Security en todas las tablas | | Alguien roba el token de sesión | Tokens con TTL corto + refresh tokens; sesiones con expiración | | Filtración de datos sensibles (RH, Finanzas) | Schemas separados + políticas RLS estrictas + audit log automático | ### Para la arquitectura actual (SherpaX en Cowork / Claude) Esta pregunta la hacen los prospectos: *¿Qué pasa con mis datos cuando hablo con el SherpaX de EmpowerLabs?* **Respuesta estructurada para prospecto:** **¿Dónde vive el IntelliBank?** En archivos `.md` en la computadora del usuario (CLAUDE.md, carpeta `/skills`). No en servidores de EmpowerLabs. El cliente controla sus propios archivos. **¿Qué ve Anthropic?** El contenido de las conversaciones pasa por la API de Anthropic bajo su política de privacidad. Con planes Team o Enterprise: **Anthropic no entrena sus modelos con el contenido de las conversaciones**. Con el plan personal (claude.ai): revisar política vigente. **¿EmpowerLabs tiene acceso a las conversaciones?** No. EmpowerLabs configura el IntelliBank (los archivos de contexto), pero las conversaciones son entre el usuario y Claude directamente. EmpowerLabs no tiene acceso a transcripts a menos que el cliente los comparta explícitamente. **¿Qué tan sensible puede ser el IntelliBank?** Recomendación: el IntelliBank debe contener **modelos mentales, criterios, procesos y frameworks** — no datos raw sensibles (contraseñas, datos de clientes nominales, información financiera específica). El IntelliBank es una capa de inteligencia, no una base de datos operativa. **Hoja de ruta de seguridad:** - Fase 1 (ahora): Arquitectura de archivos locales — datos en computadora del cliente - Fase 2 (Corp Brain OS): Supabase del cliente — datos en infraestructura propia del cliente, cero dependencia de EmpowerLabs - Fase 3 (Enterprise): On-premise o VPC dedicado — total soberanía de datos --- ## IMPLEMENTACIÓN — RUTA CRÍTICA PARA EMPOWERLABS PILOTO 0 ### Fase 0 — Arquitectura con archivos (hoy) El sistema actual funciona pero con IntelliBank personal por persona. No hay particionado real. **Equipo EmpowerLabs actual:** ``` Victor → CLAUDE.md completo (CEO, acceso total) Anahí → CLAUDE.md de EmpowerTeams X (su área) [próximos] → CLAUDE.md por área cuando escale ``` ### Fase 1 — Supabase MVP (próximos 60-90 días) Pasos en orden: 1. **Crear proyecto Supabase** para EmpowerLabs Corp Brain OS 2. **Migrar el IntelliBank actual de Victor** a `corp_shared` como v1.0 base 3. **Crear schema `area_empowerteams`** para Anahí con su IntelliBank específico 4. **Construir Kit Assembler básico** (función Edge de Supabase que genera el CLAUDE.md dinámico) 5. **Integrar con Cowork**: al abrir sesión, se llama al assembler y se genera el contexto de la sesión 6. **Activar audit log**: quién abrió sesión, qué área de IntelliBank usó, cuándo ### Fase 2 — Scale a equipo completo Una vez validado con Victor + Anahí: - Crear schemas por área para cada colaborador nuevo - Activar el flujo de IntelliBank Updates (propuesta → aprobación → publicación) - Dashboard de madurez DOIX: ¿cuántas entries por área? ¿frecuencia de actualización? --- ## MÉTRICAS DEL CORP BRAIN OS Una organización puede medir la madurez de su Brain OS con estas métricas: | Métrica | Qué indica | |---------|------------| | # entries en `corp_shared` | Madurez del conocimiento corporativo transversal | | # entries por área | Profundidad del IntelliBank de cada área | | Frecuencia de actualizaciones | Velocidad de aprendizaje organizacional | | % colaboradores con SherpaX activo | Penetración de DOIX en el equipo | | Tiempo promedio de onboarding | Reducción vs. modelo sin DOIX | | Decisiones documentadas en IntelliBank | Acumulación de criterio ejecutivo | --- ## NOTAS DE JACOB Este documento responde la arquitectura técnica. Pero hay una dimensión más importante: **El Corp Brain OS no es un proyecto de IT — es un proyecto de diseño organizacional.** Las decisiones más críticas no son técnicas: - ¿Qué va en `corp_shared`? → Esto define la identidad y cultura codificada de la organización - ¿Quién puede escribir en el IntelliBank? → Esto define cómo aprende la organización - ¿Qué tan granular es el particionado? → Esto define el balance entre colaboración y privacidad La tecnología (Supabase + RLS + Kit Assembler) es el vehículo. El diseño de qué conocimiento vive dónde y quién puede accederlo es la arquitectura real. **EmpowerLabs como Piloto 0 tiene una ventaja enorme:** Victor entiende ambas dimensiones. La mayoría de las organizaciones van a necesitar un consultor que entienda el diseño organizacional tanto como la tecnología. Eso es el DOIX Practitioner. --- *Documento generado: Jacob — IA Lab Thinking Room, Sesión 002* *Versión 1.0 — Borrador activo* *Actualizar cuando se avance en implementación de Fase 1*