# Corp-Brain-OS — Planteamiento del Problema y Arquitectura Inicial ## DOIX-CorpBrainOS-ProblemStatement-v01 --- **Asset ID:** DOIX-CorpBrainOS-ProblemStatement-v01 **Tipo:** Documento de análisis — Problem Statement + Arquitectura conceptual **Versión:** v01 **Estado:** Draft — Documento de trabajo para Room Estafeta / HIOrgs Enterprise **Owner:** Victor Heredia / EmpowerLabs **Fecha:** 2026-04-09 **Layer:** Transversal (L0–L3) **Room de origen:** Room Estafeta / HIOrgs Enterprise **Dependencias:** SHA-ConceptoBrainOS-v01, MePB-DOIX-v01, BMF-FactoryOS-Concepto-v01, MePB-INTELLIBANK-DomainMetaFactory-v01, SHA-Corp-Especificacionesfuncionales-Tecnológicas-v01, SHA-Corp-ComparativoM365-v01 --- ## 1. La situación actual — Lo que ya funciona EmpowerLabs tiene operativo un sistema de inteligencia personal para ejecutivos que funciona en tres capas: **Capa 1 — Memoria (BrainOS).** Una base de datos PostgreSQL + pgvector que almacena pensamiento, decisiones e insights de cada ejecutivo como embeddings vectoriales. La comunicación es vía MCP (Model Context Protocol). Cada ejecutivo tiene un schema aislado. La infraestructura corre en AWS EC2 con autenticación por API key. **Capa 2 — Identidad y conocimiento (SherpaX Package).** Un conjunto de archivos que se instala en el workspace del ejecutivo: CLAUDE.md (inicialización del Sherpa), MetaPlaybooks (framework operativo), BrainOS-seed (contexto inicial), Skills (capacidades preinstaladas). Es el ADN cognitivo de cada Sherpa. **Capa 3 — Experiencia (Cowork).** La interfaz de trabajo. El ejecutivo abre Claude Cowork, su Sherpa lo saluda por nombre, consulta el BrainOS vía MCP, y la sesión arranca con contexto completo. El cliente no configura nada. Este sistema — equivalente funcional a lo que Open Brain (OB1) propone como "personal knowledge system that any AI can read from and write to" — ya está validado y en producción. La arquitectura individual funciona. La replicación para nuevos ejecutivos toma menos de 45 minutos. **Además, existe una alternativa aún más simple ya validada:** la conexión de un SherpaX a través de Cowork con un Vault local en Obsidian (o cualquier carpeta de contenidos), sin necesidad de infraestructura cloud. Esta solución funciona perfectamente para el caso individual y replica las capacidades que antes requerían Supabase. --- ## 2. El salto que falta — De BrainOS individual a Corp-Brain-OS ### 2.1 El gap fundamental Cuando 6 ejecutivos de una organización operan cada uno con su SherpaX + BrainOS, el resultado es 6 islas de inteligencia individual. Cada ejecutivo tiene un Sherpa que lo conoce profundamente. Pero ningún Sherpa sabe lo que está pasando en la organización como sistema. No existe hoy una capa que: - Recopile la actividad y la dinámica de la red distribuida de inteligencia - Integre lo que está ocurriendo en los diferentes workflows, factorías y meta factorías (BMF) - Conecte los agentes operando en distintos nodos - Genere una visión organizacional emergente sin requerir reportes adicionales **El BrainOS es la memoria de un ejecutivo. Lo que falta es la memoria de la organización.** ### 2.2 Por qué no es simplemente "juntar los BrainOS" La solución no es agregar los BrainOS individuales en una base de datos común. Hay razones de arquitectura, privacidad y funcionalidad: **Privacidad.** Lo que un ejecutivo piensa, duda o explora con su Sherpa es información íntima. Un Corp-Brain-OS que acceda a todo lo que cada SherpaX captura violaría la confianza que hace funcionar al sistema. El BrainOS personal es intransferible por diseño (ver SHA-ConceptoBrainOS-v01: "Es quién eres"). **Granularidad incorrecta.** Los pensamientos individuales capturados en sesiones de trabajo no son la unidad correcta para inteligencia organizacional. La organización necesita saber "qué proyectos tienen momentum", no "qué pensó el Director Financiero a las 3pm del martes". **Arquitectura errónea.** Juntar datos crudos de 6 schemas en uno produce ruido, no inteligencia. La inteligencia organizacional requiere un nivel diferente de procesamiento: síntesis, detección de patrones, identificación de señales débiles, cruce de contextos entre áreas. ### 2.3 El problema como pregunta de diseño > **¿Cómo se construye una memoria organizacional viva que emerge del trabajo cotidiano de una red distribuida de SherpaX + agentes + factorías, sin violar la privacidad individual, sin requerir reportes manuales, y que sea accionable tanto por humanos como por agentes?** --- ## 3. Los cinco retos técnicos y de diseño ### Reto 1 — La frontera entre lo personal y lo organizacional Cada interacción humano-SherpaX genera dos tipos de contenido: (a) lo que es personal del ejecutivo (sus dudas, reflexiones, estilo de pensamiento) y (b) lo que es relevante para la organización (decisiones tomadas, estados de proyecto, compromisos, señales de riesgo). Hoy no existe un mecanismo para separar estos dos flujos de manera automática y confiable. **El reto:** Definir qué información fluye del BrainOS individual al Corp-Brain-OS, bajo qué condiciones, con qué nivel de abstracción, y quién lo autoriza. **Decisión de diseño (2026-04-09):** Se operará con un **Publication Protocol de dos carriles:** - **Carril automático:** Categorías predefinidas que fluyen al Corp-Brain-OS sin aprobación individual. Incluyen: decisiones formalizadas, compromisos declarados, estados de proyecto, outputs de factorías. Estas categorías se definen durante la implementación y se codifican en el SherpaX Package de cada ejecutivo. - **Carril propuesto:** Para información que no cae en las categorías automáticas, el SherpaX detecta relevancia organizacional y propone publicar una versión abstraída al Corp-Brain-OS. El ejecutivo aprueba o rechaza. El contenido publicado es siempre una abstracción — nunca el pensamiento crudo. ### Reto 2 — Activos cognitivos en repositorios heterogéneos En una implementación enterprise genérica, los activos cognitivos no vivirán en un solo lugar. Pueden estar en: - **Obsidian / Vault local** (como hoy en EmpowerLabs) - **GenniuxGit** (repositorio versionado propio de EmpowerLabs) - **SharePoint / OneDrive** (si la empresa opera con Microsoft 365) - **Google Drive / Workspace** (alternativa cloud) - **Git corporativo** (GitHub Enterprise, GitLab, Azure DevOps) - **Sistemas enterprise** (Confluence, Notion, ServiceNow) El Corp-Brain-OS necesita funcionar independientemente de dónde vivan los activos. Esto implica una capa de abstracción que pueda leer de múltiples fuentes y escribir resultados de inteligencia en el formato que la organización consuma. **El reto:** Diseñar una capa de conectores que haga al Corp-Brain-OS agnóstico al backend de almacenamiento, manteniendo la capacidad de búsqueda semántica y recuperación contextual. **Decisión de diseño (2026-04-09):** El Vault local es siempre la capa de interfaz del Corp-Brain-OS — independientemente de qué backend use el cliente. Si el cliente opera con Microsoft 365, el Vault local se sincroniza con SharePoint; el Corp-Brain-OS lee exclusivamente del Vault. Esto significa que solo necesitamos un conector: al Vault. La sincronización Vault ↔ SharePoint/OneDrive/Google Drive es un problema de infraestructura del cliente (o de su implementador), no del Corp-Brain-OS. Esta decisión simplifica radicalmente la arquitectura: un solo punto de lectura, múltiples backends posibles. ### Reto 3 — La telemetría de una red distribuida En la arquitectura BMF, la actividad productiva no ocurre en un solo lugar. Ocurre en: - **SherpaX individuales** (sesiones ejecutivo-Sherpa) - **Factory OS de cada factoría** (estado de proyectos, gates, telemetría) - **Agentes autónomos** (M-Sherpas ejecutando misiones recurrentes) - **EmpowerTeams X** (equipos humano-IA en proyectos críticos) - **Rooms especializados** (nodos cognitivos con propósito específico) Hoy, la visión consolidada de lo que está pasando en toda esta red vive exclusivamente en la cabeza de Victor. El Corp-Brain-OS debe capturar esa actividad distribuida, sintetizarla, y hacerla disponible sin que cada nodo tenga que "reportar" conscientemente. **El reto:** Definir qué señales emite cada componente de la red, cómo se capturan sin fricción, y cómo se sintetizan en una visión organizacional coherente. **Decisión de diseño (2026-04-09):** Los Factory OS de cada factoría fluyen automáticamente al Corp-Brain-OS como telemetría estructurada — son el piso del Activity Pulse Layer. El APL se extiende más allá de los Factory OS con protocolos de publicación adicionales: outputs de Rooms, cierres de sprint de EmpowerTeams, resultados de M-Sherpas, y las publicaciones del carril automático de cada SherpaX. Factory OS = telemetría base automática. Protocolos adicionales = extensión configurable por organización. ### Reto 4 — De la recopilación a la inteligencia accionable Recopilar datos de actividad es la parte fácil. El valor real está en convertir esa recopilación en inteligencia que cambie decisiones. El Corp-Brain-OS no es un dashboard — es un sistema que detecta: - **Patrones emergentes:** "Tres directivos diferentes mencionaron problemas con el proveedor X esta semana." - **Desalineaciones:** "El equipo tech está priorizando migración de sistemas, pero el CEO habló de crecimiento de mercado." - **Señales débiles:** "La factoría de Publishing lleva dos semanas sin mover ningún proyecto más allá de E4." - **Oportunidades de conexión:** "Lo que el Director Comercial descubrió en su sesión de hoy es exactamente lo que el Director de Producto necesita para su decisión pendiente." **El reto:** Diseñar los algoritmos de síntesis, detección de patrones y generación de alertas que convierten datos crudos de actividad en inteligencia organizacional accionable. ### Reto 5 — Escalabilidad sin complejidad de implementación La solución debe ser implementable en una empresa donde los ejecutivos usen Cowork (o la interfaz que sea) sin saber que existe un Corp-Brain-OS detrás. La complejidad del sistema no puede trasladarse al usuario. Y el modelo debe ser replicable: lo que funcione para Estafeta (6 directivos tech) debe funcionar para cualquier equipo enterprise de 5 a 50 personas. **El reto:** Mantener la simplicidad de la experiencia individual de SherpaX mientras se agrega una capa organizacional invisible pero funcional. **Nota de diseño:** La decisión de que el Vault local sea siempre la interfaz (Reto 2) y de que los Factory OS fluyan automáticamente (Reto 3) contribuyen directamente a este reto: el ejecutivo sigue trabajando con su SherpaX + Vault como siempre, sin saber que hay una capa organizacional operando debajo. --- ## 4. Los componentes conceptuales del Corp-Brain-OS Basado en el análisis de la arquitectura BMF existente (Factory OS, IntelliBank, DOIX, BrainOS), el Corp-Brain-OS se construiría sobre cuatro componentes: ### 4.1 Organizational IntelliBank (O-IB) El IntelliBank organizacional (ya definido conceptualmente en MePB-INTELLIBANK-DomainMetaFactory-v01) es el repositorio gobernado de activos cognitivos de la organización. A diferencia del IntelliBank personal, tiene un steward y múltiples contributors. **Lo que existe hoy:** La definición conceptual, la taxonomía de activos cognitivos (6 capas del Cognitive Asset Stack), y el sistema de badge ⬡. **Lo que falta para enterprise:** Un mecanismo para que los activos fluyan desde los SherpaX individuales y las factorías al O-IB sin fricción. La capa de conectores a repositorios heterogéneos (SharePoint, Git, etc.). El sistema de permisos y gobernanza multi-nivel. ### 4.2 Activity Pulse Layer (APL) Una capa de telemetría ligera que captura señales de actividad desde todos los nodos de la red sin requerir acción consciente del usuario. La analogía del Factory OS aplica: así como el Factory OS captura estado, gates y telemetría de una factoría individual, el APL hace lo mismo a nivel organizacional. **Señales que captura:** | Fuente | Señal | Ejemplo | |--------|-------|---------| | SherpaX individuales | Temas activos, decisiones formalizadas, compromisos declarados | "El CTO formalizó la decisión de migrar a Kubernetes" | | Factory OS de factorías | Estado de proyectos, bottlenecks, gates pendientes | "La factoría de Publishing tiene 3 proyectos bloqueados en E4B" | | M-Sherpas | Resultados de misiones recurrentes, anomalías detectadas | "El M-Sherpa de monitoreo de competencia detectó un nuevo competidor" | | EmpowerTeams X | Progreso de proyectos críticos, decisiones de equipo | "El EmpowerTeam de producto completó el sprint sin dependencias externas" | | Rooms | Outputs generados, Transfer Packs actualizados | "El Thinking Room generó un nuevo MetaPlaybook que afecta a 3 factorías" | **Principio de privacidad:** El APL no captura contenido de conversaciones. Captura metadatos de actividad y outputs formalizados. El ejecutivo controla qué se "publica" al nivel organizacional. ### 4.3 Synthesis Engine (SE) El motor que convierte señales de actividad en inteligencia organizacional. Opera en tres modos: **Modo pasivo — Detección de patrones.** Analiza las señales del APL y detecta correlaciones, tendencias, anomalías y señales débiles sin que nadie lo pida. **Modo activo — Respuesta a consultas.** Cuando un ejecutivo (o su SherpaX) pregunta "¿qué está pasando con el proyecto X?", el SE busca en todas las fuentes relevantes y genera una respuesta consolidada. **Modo proactivo — Alertas y recomendaciones.** Cuando el SE detecta algo que requiere atención (desalineación, oportunidad de conexión, riesgo emergente), genera una alerta dirigida a quien debe verla. ### 4.4 Governance Bridge (GB) La capa que conecta el Corp-Brain-OS con los protocolos de gobernanza existentes del BMF: naming convention, registry de activos, protocolos de escalación DOIX, permisos por rol. **Por qué es necesario:** Sin governance, el Corp-Brain-OS se convierte en un lago de datos sin estructura. Con el Governance Bridge, cada pieza de inteligencia organizacional está gobernada con las mismas reglas que ya aplican al ecosistema BMF (INV-01 a INV-07). ### 4.5 Org-Sherpa — El agente del Corp-Brain-OS **Decisión de diseño (2026-04-09):** El Corp-Brain-OS tendrá su propio agente: el **Org-Sherpa**. No es un SherpaX personal — es un agente cuya "persona" es la organización. Su CLAUDE.md se configura con acceso exclusivo al Corp-Vault y al APL (no a los BrainOS individuales). **Qué puede hacer el Org-Sherpa:** - Responder preguntas transversales: "¿Qué está pasando esta semana en la organización?" - Generar reportes de estado consolidados sin que nadie los redacte manualmente - Alertar sobre desalineaciones, bottlenecks cruzados, o señales débiles detectadas por el Synthesis Engine - Servir como interlocutor del CEO con la inteligencia organizacional — el CEO pregunta al Org-Sherpa en lugar de convocar una junta de status **Qué NO puede hacer el Org-Sherpa:** - Acceder a los BrainOS individuales de los ejecutivos - Leer conversaciones privadas entre un ejecutivo y su SherpaX - Tomar decisiones operativas — solo informa, conecta y alerta **Implementación técnica:** El Org-Sherpa es un SherpaX más en la infraestructura existente. No requiere tecnología nueva. Es un Cowork session con su propio CLAUDE.md apuntando al Corp-Vault como workspace. Puede correr como instancia permanente del CEO o como agente consultable por cualquier ejecutivo con permisos. ### 4.6 Modelo de permisos — Tres niveles de acceso **Decisión de diseño (2026-04-09):** El Corp-Brain-OS opera con capas de acceso por rol. No todos ven todo. | Nivel | Rol | Acceso al Corp-Brain-OS | |-------|-----|------------------------| | **L3 — Estratégico** | CEO / Fundador | Vista completa: todos los nodos, todas las alertas, Org-Sherpa con contexto total. Ve patrones entre áreas, desalineaciones estratégicas, y tiene acceso a la telemetría de todas las factorías. | | **L2 — Directivo** | Directores / VPs | Vista de su área + cruces relevantes con otras áreas. Recibe alertas que afectan a su dominio. Ve el estado de proyectos de sus factorías y las dependencias con otras áreas. No ve la telemetría de áreas ajenas salvo cuando hay cruce directo. | | **L1 — Operativo** | Gerentes / Operadores | Vista de sus proyectos activos. Acceso al O-IB para consultar MetaPlaybooks y protocolos. No recibe alertas estratégicas. Ve el estado de los proyectos donde participa directamente. | **Implementación en Vault-based (Opción A):** Estructura de carpetas con permisos de lectura diferenciados. La zona `/corp-brain/strategic/` solo es accesible para L3. La zona `/corp-brain/areas/[area]/` es accesible para L2 de esa área + L3. La zona `/corp-brain/shared/` es accesible para todos. --- ## 5. Las dos opciones de implementación técnica ### Opción A — Corp-Brain-OS basado en Vault (Obsidian/Carpeta local) **Cómo funciona:** El Corp-Brain-OS es un Vault compartido (o una carpeta de red / repositorio Git) que funciona como el "Obsidian organizacional". Cada SherpaX tiene acceso de lectura al Corp-Vault y acceso de escritura a una zona específica donde publica outputs formalizados. **Ventajas:** - Cero infraestructura cloud adicional — funciona con lo que ya existe - Compatible con el modelo de Vault + Cowork ya validado - El Git corporativo (GenniuxGit) puede ser el backend - Implementación inmediata — no hay que construir nada nuevo **Limitaciones:** - Sin búsqueda semántica nativa (solo búsqueda por texto/tags) - Sin telemetría automática (el APL tendría que ser manual o semi-manual) - La síntesis depende de que un agente lea y procese archivos, no de un motor de búsqueda vectorial - Escalabilidad limitada conforme crece el volumen de activos **Mejor para:** Piloto 0 en EmpowerLabs, equipos de 5-15 personas, empresas que prefieren soberanía total de datos. ### Opción B — Corp-Brain-OS basado en infraestructura vectorial (BrainOS escalado) **Cómo funciona:** El Corp-Brain-OS tiene su propia instancia de BrainOS (PostgreSQL + pgvector) a nivel organizacional. Los SherpaX individuales publican al Corp-BrainOS vía MCP. El Synthesis Engine opera sobre la base vectorial con búsqueda semántica nativa. **Ventajas:** - Búsqueda semántica real a nivel organizacional - Detección de patrones automática (embeddings similares = temas convergentes) - Telemetría pasiva integrada - Escalable a organizaciones grandes **Limitaciones:** - Requiere infraestructura adicional (instancia EC2, base de datos dedicada) - Mayor complejidad de implementación inicial - Requiere definir protocolos de publicación individual → organizacional - Costo operativo mensual adicional **Mejor para:** Implementaciones enterprise (6+ directivos), empresas con equipo IT propio, casos donde la búsqueda semántica organizacional es crítica. ### Opción C — Híbrida (Vault como interfaz + BrainOS como motor) **Cómo funciona:** Los activos viven en un Vault/repositorio accesible para humanos (Obsidian, SharePoint, GenniuxGit). El Corp-BrainOS lee esos activos, los indexa vectorialmente, y opera como motor de síntesis por debajo. Los humanos trabajan con archivos; el Corp-Brain-OS trabaja con embeddings. **Ventajas:** - Mejor de ambos mundos: interfaz humana familiar + capacidad semántica IA - Los archivos son portables y legibles sin dependencia del sistema - El motor vectorial se puede agregar o quitar sin perder los activos **Limitaciones:** - Requiere un proceso de sincronización Vault ↔ Base vectorial - Mayor complejidad de mantenimiento --- ## 6. Propuesta de secuencia — Cómo avanzar ### Fase 0 — Piloto 0 en EmpowerLabs (semanas 1) **Objetivo:** Validar el Corp-Brain-OS con el equipo propio antes de cualquier implementación externa. **Implementación:** Opción A (Vault-based). Crear un Corp-Vault en GenniuxGit o en una carpeta compartida. Definir la estructura de carpetas para el O-IB, el APL (como log .md), y las zonas de publicación por SherpaX. **Entregable:** Corp-Brain-OS mínimo operativo con al menos 3 SherpaX del equipo EmpowerLabs publicando outputs al nivel organizacional. ### Fase 1 — Validación del modelo y documentación (semana 2) **Objetivo:** Convertir lo aprendido en el Piloto 0 en una metodología documentada y transferible. **Entregable:** Metodología de implementación Corp-Brain-OS (EL-DOIX-Impl-CorpBrainOS-v01.md) lista para presentar a clientes enterprise. ### Fase 2 — Escalamiento a infraestructura vectorial (semana 3) **Objetivo:** Agregar la capa de BrainOS organizacional (Opción C híbrida) para habilitar búsqueda semántica y detección de patrones automática. **Entregable:** Corp-Brain-OS completo con Vault como interfaz + motor vectorial como backend. ### Fase 3 — Paquetización para enterprise (semana 4) **Objetivo:** Empaquetar el Corp-Brain-OS como producto implementable para clientes como Estafeta. **Entregable:** Kit de implementación enterprise que incluye: guía de instalación, plantillas de Corp-Vault, conectores a M365/SharePoint, protocolos de onboarding organizacional. --- ## 7. Registro de decisiones de diseño Las siguientes decisiones fueron tomadas por Victor Heredia el 2026-04-09 y están integradas en el cuerpo del documento: | # | Pregunta | Decisión | Integrada en | |---|----------|----------|-------------| | D1 | ¿Qué fluye de BrainOS individual al Corp-Brain-OS? | Publication Protocol de dos carriles: categorías automáticas predefinidas + SherpaX propone / ejecutivo aprueba lo no categorizado | Reto 1, §3 | | D2 | ¿El Corp-Brain-OS tiene su propio agente? | Sí — Org-Sherpa como agente dedicado con acceso exclusivo al Corp-Vault y APL | §4.5 (nuevo) | | D3 | ¿Cómo se integra el Factory OS? | Factory OS fluye automáticamente al APL como telemetría base + protocolos adicionales configurables | Reto 3, §3 | | D4 | ¿Modelo de permisos? | Tres niveles: L3 Estratégico (CEO), L2 Directivo (por área), L1 Operativo (por proyecto) | §4.6 (nuevo) | | D5 | ¿Integración con M365/SharePoint? | Vault local como interfaz única; sincronización Vault ↔ SharePoint es problema de infra del cliente | Reto 2, §3 | | D6 | ¿Rol de Alain en el stack técnico? | No opera infraestructura. EmpowerLabs mantiene control completo del stack | Nota — no requiere cambio en arquitectura | | D7 | ¿Pricing del Corp-Brain-OS? | Se trabaja en Room separado de consultoría | Fuera de scope de este documento | ### Preguntas que permanecen abiertas 1. **¿Qué categorías específicas componen el carril automático del Publication Protocol?** Se necesita definir la lista concreta: ¿decisiones formalizadas, compromisos, estados de proyecto, cambios de prioridad? ¿Algo más? → Resolver en Fase 0 (Piloto 0). 2. **¿Cómo se configura el Org-Sherpa para el Piloto 0?** Definir el CLAUDE.md del Org-Sherpa, su workspace, y los protocolos de consulta. → Siguiente entregable práctico. 3. **¿Cómo se implementa la estructura de permisos en el Corp-Vault?** Definir la taxonomía de carpetas por nivel de acceso y los mecanismos de control (Git permissions, Obsidian folders, SharePoint permissions). → Resolver en diseño de implementación. 4. **¿Qué métricas definen el éxito del Piloto 0?** ¿Cómo sabemos que el Corp-Brain-OS funciona antes de llevarlo a un cliente? → Definir antes de iniciar Fase 0. --- ## 8. Diagrama de arquitectura conceptual ``` ┌─────────────────────────────────────────────────────────────────────────┐ │ CORP-BRAIN-OS │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ SYNTHESIS ENGINE │ │ │ │ Detección de patrones · Alertas · Respuesta a consultas │ │ │ └────────────────────────────┬─────────────────────────────────────┘ │ │ │ │ │ ┌────────────────────────────┴─────────────────────────────────────┐ │ │ │ ORGANIZATIONAL INTELLIBANK (O-IB) │ │ │ │ Activos cognitivos compartidos · MetaPlaybooks · Decisiones │ │ │ │ Badge ⬡ · Versionado · Taxonomía completa │ │ │ └────────────────────────────┬─────────────────────────────────────┘ │ │ │ │ │ ┌────────────────────────────┴─────────────────────────────────────┐ │ │ │ ACTIVITY PULSE LAYER (APL) │ │ │ │ Telemetría distribuida · Señales de actividad · Logs de gates │ │ │ └─────┬──────────┬──────────┬──────────┬──────────┬───────────────┘ │ │ │ │ │ │ │ │ │ ┌─────┴───┐ ┌────┴────┐ ┌──┴───┐ ┌────┴────┐ ┌──┴──────┐ │ │ │SherpaX │ │SherpaX │ │Fact. │ │M-Sherpa │ │Empower │ │ │ │Exec #1 │ │Exec #2 │ │OS │ │Missions │ │Teams X │ │ │ │+BrainOS │ │+BrainOS │ │ │ │ │ │ │ │ │ └─────────┘ └─────────┘ └──────┘ └─────────┘ └─────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ GOVERNANCE BRIDGE │ │ │ │ BMF Naming · Registry · Permisos · Protocolos de escalación │ │ │ └──────────────────────────────────────────────────────────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────────────────┐ │ │ │ CONNECTOR LAYER (backends de almacenamiento) │ │ │ │ Obsidian/Vault │ GenniuxGit │ SharePoint │ Google Drive │ Git │ │ │ └──────────────────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────────────────┘ ``` --- ## 9. Conexión con el TP del Room Estafeta / HIOrgs Enterprise Este documento responde directamente al objetivo 5.2 del Transfer Pack (EL-TP-Estafeta-HIOrgs-v01): "Metodología de implementación HIOrgs." El Corp-Brain-OS es la implementación técnica del componente "Organizational Brain" descrito en el MePB-DOIX-v01, que integra IntelliBank + SherpaX + EmpowerTeams X. En la nomenclatura DOIX, el Corp-Brain-OS es la materialización de la Fase 4 del protocolo de implementación: "Corp Brain OS completo (ciclo continuo)." La restricción del TP aplica: **no se vende antes de tener el paquete listo. EmpowerLabs primero.** --- --- ## 10. Respuestas para Alex — Preguntas sobre el Corp-Brain-OS *Sección generada a partir de las preguntas de Alex registradas el 2026-04-09.* ### ¿Qué es exactamente el Corp-Brain-OS? El Corp-Brain-OS es la **memoria viva de la organización**. Así como el BrainOS es la memoria de un ejecutivo individual, el Corp-Brain-OS es la memoria de la empresa como sistema. No es una base de datos. No es un dashboard. Es un sistema compuesto por cuatro componentes que trabajan juntos: 1. **Organizational IntelliBank (O-IB):** El repositorio gobernado donde viven los activos cognitivos compartidos de la organización — MetaPlaybooks, decisiones estratégicas, protocolos, lecciones aprendidas. Cada activo tiene identidad (Asset ID), versión, dueño, y estado. Es la inteligencia institucional que sobrevive a la rotación de personas. 2. **Activity Pulse Layer (APL):** La capa de telemetría que captura qué está pasando en toda la red — estados de proyectos, compromisos declarados por los ejecutivos, outputs de factorías, resultados de misiones de agentes. Funciona automáticamente: los Factory OS de cada factoría alimentan al APL sin intervención humana, y los SherpaX individuales publican al APL a través de categorías predefinidas. 3. **Synthesis Engine (SE):** El motor que convierte las señales del APL en inteligencia accionable. No es un reporte — es un sistema que detecta patrones ("tres directivos mencionaron el mismo problema esta semana"), desalineaciones ("el CEO habla de crecimiento pero el equipo tech prioriza migración"), y oportunidades de conexión ("lo que descubrió el Director Comercial es lo que necesita el Director de Producto"). 4. **Governance Bridge (GB):** La capa que conecta todo con las reglas de gobernanza del ecosistema BMF — naming, registry, permisos, protocolos de escalación. Sin esto, el Corp-Brain-OS sería un lago de datos sin estructura. **En una frase:** El Corp-Brain-OS es el sistema que hace que la organización sepa lo que sabe — sin que nadie tenga que escribir un reporte. ### ¿Cuál es la naturaleza de la información que almacena? El Corp-Brain-OS **NO almacena** conversaciones privadas entre ejecutivos y sus SherpaX. No almacena pensamientos, dudas, ni reflexiones personales. Esas son del BrainOS individual y son intransferibles. **Lo que SÍ almacena:** | Tipo de información | Origen | Ejemplo | |---|---|---| | **Decisiones formalizadas** | SherpaX individuales (carril automático) | "El CTO formalizó la decisión de migrar a Kubernetes en Q3" | | **Compromisos declarados** | SherpaX individuales (carril automático) | "El Director Comercial se comprometió a cerrar 3 pilotos antes del 30 de abril" | | **Estados de proyecto** | Factory OS de cada factoría (automático) | "La factoría de Publishing tiene 2 libros en E7 y 1 bloqueado en E4B" | | **Outputs de factorías** | Factory OS + Rooms (automático) | "El Thinking Room generó un nuevo MetaPlaybook que afecta a 3 factorías" | | **Alertas y patrones** | Synthesis Engine (generado) | "Señal débil: el proveedor X fue mencionado negativamente por 3 directivos esta semana" | | **Activos cognitivos compartidos** | Organizational IntelliBank (curado) | MetaPlaybooks de la organización, protocolos, estándares de calidad — con badge ⬡ | | **Telemetría operativa** | Factory OS (automático) | Tiempos por fase, bottlenecks recurrentes, tasa de aprobación en gates | **La regla simple:** Si un ejecutivo lo formalizó como decisión o compromiso, entra al Corp-Brain-OS. Si es una reflexión personal o una duda, se queda en su BrainOS privado. ### ¿Qué capacidades tiene? El Corp-Brain-OS tiene tres capacidades principales: **Capacidad 1 — Responder preguntas transversales.** El CEO (o cualquier ejecutivo con permisos) puede preguntar al Org-Sherpa: "¿Qué está pasando esta semana en la organización?" y recibir una respuesta consolidada que cruza información de todos los nodos — sin que nadie haya escrito un reporte. Esto funciona porque el APL ya capturó las señales y el Synthesis Engine las procesó. **Capacidad 2 — Detectar patrones y señales débiles automáticamente.** Sin que nadie lo pida, el Corp-Brain-OS puede detectar: convergencias ("tres áreas están trabajando en temas similares sin saberlo"), desalineaciones ("la estrategia dice X pero la ejecución va hacia Y"), y riesgos ("un proyecto lleva dos semanas sin movimiento y tiene una dependencia con otro que avanza rápido"). **Capacidad 3 — Conectar información entre áreas.** Lo que un directivo descubre en su sesión de trabajo puede ser exactamente lo que otro directivo necesita para una decisión pendiente. El Corp-Brain-OS identifica esas conexiones y las surfacea — funciona como el "puente de contexto" que hoy solo existe en la cabeza de Victor. **Capacidad bonus — Onboarding acelerado.** Cuando un nuevo directivo se incorpora, su SherpaX puede acceder al Organizational IntelliBank y arrancar con el contexto completo de la organización: protocolos, decisiones recientes, proyectos activos, estándares de calidad. El nuevo directivo no empieza de cero — empieza desde la inteligencia acumulada. ### ¿Cómo se implementa técnicamente? En su versión más simple (Piloto 0), el Corp-Brain-OS es un **Vault compartido** — una carpeta de archivos estructurada que cada SherpaX puede leer y donde publica sus outputs formalizados. El Org-Sherpa es un Cowork session cuyo workspace es ese Corp-Vault. No requiere infraestructura nueva. Son archivos .md + un CLAUDE.md bien configurado. En su versión escalada, se agrega una capa de base de datos vectorial (PostgreSQL + pgvector, la misma tecnología del BrainOS individual) que permite búsqueda semántica a nivel organizacional y detección automática de patrones. La clave es que **empezamos con archivos y validamos el modelo antes de agregar complejidad técnica.** --- *Asset ID: DOIX-CorpBrainOS-ProblemStatement-v01 | Versión: v01 | Estado: Draft — Decisiones de diseño integradas* *Room: Estafeta / HIOrgs Enterprise | Owner: Victor Heredia / EmpowerLabs* *Colaboradores: Victor Heredia (decisiones), Alex (preguntas), Jacob (generación)* *Generado: 2026-04-09 | Actualizado: 2026-04-09*