--- asset_id: DC-XX-SOMA-Canon-v01 tipo: DC — Documento Canónico layer: Universal · fuente de verdad del concepto SOMA version: v01 status: Canónico — no modificar sin VoBo de Victor Heredia owner: Victor Heredia sherpa_owner: Jay fecha: 2026-06-06 intellibank: IB-XX-Maestro / IPI-XX-IP-Infraestructura / IPI-XX-SOMA proposito: > Definición canónica y definitiva de SOMA — qué es, cómo está arquitecturado, cómo se distingue de MetaPlaybook, y cómo se extiende por dominio o engagement. Es el documento de referencia al que todos los demás SOMA y MetaPlaybook apuntan. Cuando haya duda sobre qué es SOMA y qué no es, este documento resuelve. referencias_desde: - SOMA-XX-Core-v01.md - SOMA-XX-Method-v01.md - SOMA-XX-SX-v01.md - ARQ-EL-BrainX-SOMA-v01.md - MePB-XX-BrainSX-v01.md --- # DC-XX-SOMA-Canon-v01 ## SOMA — Definición Canónica y Arquitectura Refinada > *"Un sistema que no distingue entre su infraestructura y su metodología > confunde lo que es con lo que hace. SOMA define lo que es. > MetaPlaybook define lo que hace."* > — Victor Heredia, 2026-06-06 --- ## 1. DEFINICIÓN CANÓNICA **SOMA** — Sistema Operativo Metodológico y Arquitectónico — es la **capa de infraestructura cognitiva** de cualquier Brain[X] y de la organización que lo adopta. Define la arquitectura del sistema: sus componentes, sus capas, sus reglas estructurales, su gobernanza, y la configuración de cómo el contexto se ensambla en cada sesión de trabajo (Harnesses). SOMA no define cómo opera el sistema. Eso es responsabilidad de los MetaPlaybooks. SOMA define **sobre qué opera**. La distinción es análoga a la de un sistema operativo: ``` SOMA = el sistema operativo (kernel + filesystem + drivers) MetaPlaybook = las aplicaciones que corren sobre el OS Actualizar una aplicación no requiere reinstalar el OS. Actualizar el Sales MetaPlaybook no requiere modificar SOMA. ``` --- ## 2. POR QUÉ SOMA EXISTE Antes de SOMA, cada nuevo engagement, cliente o dominio requería reconstruir el mismo contexto desde cero: qué es BMF, qué es DOIX, cómo se nombran los activos, qué puede hacer el Sherpa, cuál es el XDoc de este proyecto. Ese costo de reconstrucción es exactamente el tipo de costo oculto que el modelo existe para eliminar. SOMA lo elimina siendo el bootstrap que cualquier Sherpa carga una vez y que lo hace operativo desde el primer prompt. Adicionalmente, sin SOMA como capa separada, los aprendizajes metodológicos (que deben actualizarse frecuentemente) se mezclaban con las reglas estructurales (que deben ser estables), produciendo un sistema que se desestabiliza cada vez que alguien aprende algo nuevo. SOMA resuelve esto al separar formalmente las capas con sus propios ciclos de vida. --- ## 3. ARQUITECTURA REFINADA — LAS CUATRO CAPAS ``` SOMA (Sistema Operativo · capa de arquitectura e infraestructura) │ ├── SOMA-Core │ → Arquitectura universal: BMF, DOIX, SherpaX, WORX OS, IntelliBanks │ → Inmutable entre dominios y engagements │ → Cambia solo cuando la arquitectura central del ecosistema evoluciona │ → Prefijo: SOMA-XX-Core-vNN.md │ ├── SOMA-Method │ → Reglas estructurales: naming convention, XDoc schema, │ gobernanza L0-L3, ciclo de vida de activos, registry │ → Universal — aplica a todo el modelo sin importar el dominio │ → Cambia con versiones de WORX o decisiones de arquitectura │ → Prefijo: SOMA-XX-Method-vNN.md │ ├── SOMA-Harnesses │ → Configuración de ensamblaje de contexto por room o sesión │ → Define: qué cargar, en qué orden, qué MetaPlaybooks activar, │ qué IBs referenciar, qué Brain Codes incluir, qué nivel de gobernanza │ → Uno por tipo de room · específico por dominio y entidad │ → Cambia cuando se crea un nuevo tipo de room o dominio │ → Prefijo: HNS-[IB]-[X]-[TipoRoom]-vNN.md │ └── SOMA-[X] → Extensión de SOMA por dominio o por engagement → SOMA-[Dominio]: arquitectura del Brain[X] (SX, MX, PX, TX) → SOMA-[Engagement]: contexto específico del cliente → Hereda de Core + Method y agrega lo específico del dominio/cliente → Prefijo: SOMA-[XX|IB]-[X]-vNN.md ``` --- ## 4. METAPLAYBOOK — LA CAPA QUE OPERA SOBRE SOMA MetaPlaybook es la capa de **metodología** que opera sobre la infraestructura que SOMA provee. Define cómo el sistema ejecuta en un dominio específico: los workflows, los criterios de decisión, los scripts de operación, las métricas de salud, y los anti-patterns del dominio. ``` MetaPlaybooks (capa de metodología · opera sobre SOMA) │ ├── MetaPlaybook de dominio │ → Define cómo opera un Brain[X] completo │ → MePB-XX-BrainSX-v01.md (ventas — opera sobre LoopSX) │ → MePB-XX-BrainMX-v01.md (expertise — opera sobre LoopMX) │ → MePB-XX-BrainPX-v01.md (publicaciones — opera sobre LoopPX) │ → MePB-XX-BrainTX-v01.md (transformación — opera sobre LoopTX) │ ├── MetaPlaybook de engagement [cliente] │ → Adapta el MetaPlaybook de dominio al proceso específico del cliente │ → Hereda del dominio y agrega o ajusta sin tocar SOMA │ → MePB-[IB]-SX-[Cliente]-vNN.md │ └── MetaPlaybook procedural → Procedimiento específico de cualquier capa o proceso → MePB-XX-BrainCode-Anatomy-v02.md → MePB-XX-MasterBrainCodeDistiller-v02.md ``` **La regla fundamental de separación:** > Si cambiar la metodología requiere cambiar SOMA, la arquitectura está mal diseñada. Un BrainSX correctamente construido puede adoptar un proceso de ventas completamente diferente (nuevo MetaPlaybook-SX) sin reconfigurar SOMA-SX. --- ## 5. LA DISTINCIÓN EN UNA TABLA | Dimensión | SOMA | MetaPlaybook | |---|---|---| | **Pregunta que responde** | ¿Cómo está construido el sistema? | ¿Cómo opera el sistema? | | **Nivel** | Arquitectura + infraestructura | Metodología + procedimiento | | **Frecuencia de cambio** | Baja / Muy baja | Media / Alta | | **Quién lo cambia** | Victor · arquitecto senior | Equipo operativo + Victor ratifica | | **Condición de cambio** | Decisión arquitectónica | Aprendizaje operativo | | **Contiene** | Capas, componentes, harnesses, naming rules, gobernanza | Workflows, criterios, scripts, métricas, anti-patterns | | **Riesgo de cambio incorrecto** | Alto — puede romper interoperabilidad | Bajo — afecta solo el dominio | | **Analogía OS** | Kernel + filesystem + drivers | Aplicación instalada | --- ## 6. EL GRADIENTE DE CHANGEABILITY No todas las capas del sistema cambian con la misma frecuencia ni el mismo impacto. El gradiente va de lo más estable (mayor impacto si cambia) a lo más fluido (menor impacto, mayor frecuencia de actualización): ``` MÁS ESTABLE ←────────────────────────────────────────────→ MÁS FLUIDO SOMA-Core SOMA-Method SOMA-Harnesses MetaPlaybook MiniPlaybook │ │ │ │ │ Años Meses-Años Semanas-Meses Días-Semanas Horas-Días Arquitectura Reglas Configuración Metodología Micro-proceso central estructurales de sesión operativa │ │ │ │ │ Victor solo Victor+Senior Jay+Victor Jay+Equipo Sherpa IMPACTO de cambio incorrecto: ████████████░░░░░░░░░░░░░░░░░░░░░░░ ``` **Implicación práctica:** cuando alguien dice "esto debería funcionar diferente", la primera pregunta no es cómo cambiarlo — es en qué capa del gradiente vive. Eso determina quién puede cambiarlo, con qué ratificación, y qué impacto tiene. --- ## 7. LA CADENA DE HERENCIA Toda instancia de SOMA hereda de las capas universales. La cadena de herencia es obligatoria — no se puede tener un SOMA-[X] sin haber cargado SOMA-Core y SOMA-Method. ``` SOMA-XX-Core (arquitectura universal — siempre primero) └── SOMA-XX-Method (reglas universales — siempre segundo) └── SOMA-[X] (extensión por dominio) └── SOMA-[Engagement] (extensión por cliente) └── Harness (ensamblaje de sesión) └── MetaPlaybook-[X] (metodología) └── MetaPlaybook-[X]-[Cliente] (adaptación) ``` La cadena de herencia garantiza que cualquier Sherpa, en cualquier room, tiene acceso al mismo núcleo arquitectónico. La inteligencia del sistema es consistente aunque el dominio y el cliente sean diferentes. --- ## 8. INVARIANTES DE SOMA Las invariantes son las reglas que SOMA nunca viola, independientemente del dominio, el cliente o la versión. Modificar cualquiera de estas reglas requiere una revisión de arquitectura formal con Victor. **I1 — SOMA no contiene procedimientos.** Los procedimientos (cómo hacer algo) viven en MetaPlaybooks. SOMA contiene definiciones (qué es algo) y reglas estructurales (cómo se nombra, cómo se versiona). **I2 — SOMA-Core y SOMA-Method son universales.** No existen versiones de SOMA-Core o SOMA-Method por cliente o dominio. Son únicos y transversales. Cualquier diferenciación por cliente o dominio va en SOMA-[X]. **I3 — Un Harness nunca contiene metodología.** El Harness define qué cargar y en qué orden — no cómo operar una vez que el contexto está cargado. La metodología siempre está en el MetaPlaybook. **I4 — Cada SOMA-[X] hereda sin contradicción.** Un SOMA-[X] puede extender SOMA-Core y SOMA-Method pero nunca puede contradecirlos. Si la extensión requiere contradecir una regla universal, la regla universal debe revisarse — no ignorarse. **I5 — Cambios en SOMA-Core y SOMA-Method requieren VoBo de Victor.** Son documentos de arquitectura central. Su actualización tiene consecuencias en todos los dominios y engagements que los referencian. --- ## 9. PROTOCOLO DE EXTENSIÓN — CÓMO CREAR UN SOMA-[X] NUEVO Cuando un dominio nuevo o un engagement nuevo requiere su SOMA-[X]: ``` PASO 1 · Verificar que no existe ya → Buscar en IB-XX-Maestro/IPI-XX-IP-Infraestructura/IPI-XX-SOMA/ → Si existe → extender la versión existente (SOMA-[X]-vNN+1) → Si no existe → crear desde cero siguiendo el template PASO 2 · Definir el alcance → ¿Es un SOMA de dominio (SOMA-SX, SOMA-MX) o de engagement (SOMA-PO, SOMA-EL)? → Dominio: universal — aplica a todos los clientes del dominio → Engagement: específico — aplica solo a ese cliente o proyecto PASO 3 · Construir el contenido mínimo obligatorio → Declarar herencia (hereda_de: SOMA-XX-Core + SOMA-XX-Method) → Vocabulario del dominio o engagement (términos propios, estados, métricas) → Gobernanza específica (qué puede hacer el Sherpa en este contexto, L0-L3) → Componentes propios (si es dominio: qué elementos constituyen el Brain[X]) → Naming convention específica (si el dominio tiene prefijos propios) → Referencias a Harnesses disponibles PASO 4 · Crear el Harness correspondiente → Sin Harness, el SOMA-[X] existe pero no tiene mecanismo de carga → El Harness es la conexión práctica entre SOMA y la sesión de trabajo PASO 5 · Ratificar con Victor antes de usar en producción → Un SOMA-[X] sin VoBo de Victor no es canónico — es un draft de trabajo ``` **Naming convention:** ``` Dominio universal: SOMA-XX-[X]-vNN.md → SOMA-XX-SX-v01.md Engagement cliente: SOMA-[IB]-[Codename]-vNN.md → SOMA-PO-Posta-v01.md Harness: HNS-[IB]-[X]-[Room]-vNN.md → HNS-EL-SX-SalesPipeline-v01.md ``` --- ## 10. MAPA DE ACTIVOS SOMA AL 2026-06-06 Estado del ecosistema SOMA en el momento de crear este documento: | Activo | Tipo | Estado | Ruta | |---|---|---|---| | `SOMA-XX-Core-v01` | SOMA-Core | ✅ Activo | IPI-XX-SOMA/ | | `SOMA-XX-Method-v01` | SOMA-Method | ✅ Activo | IPI-XX-SOMA/ | | `SOMA-XX-SX-v01` | SOMA-[X] Dominio | ✅ Activo | IPI-XX-SOMA/ | | `HNS-EL-SX-SalesPipeline-v01` | SOMA-Harness | ✅ Activo | PB-LoopX/ | | `DC-XX-SOMA-Canon-v01` | Canónico | ✅ Este documento | IPI-XX-SOMA/ | | `SOMA-PO-Posta-v01` | SOMA-[Engagement] | ⬜ Pendiente | IB-PO-Posta/ | | `SOMA-EL-EmpowerLabs-v01` | SOMA-[Engagement] | ⬜ Pendiente | IB-EL-EmpowerLabs/ | | `SOMA-XX-MX-v01` | SOMA-[X] Dominio | ⬜ Pendiente | IPI-XX-SOMA/ | | `SOMA-XX-PX-v01` | SOMA-[X] Dominio | ⬜ Pendiente | IPI-XX-SOMA/ | | `SOMA-XX-TX-v01` | SOMA-[X] Dominio | ⬜ Pendiente | IPI-XX-SOMA/ | | `MePB-XX-BrainSX-v01` | MetaPlaybook dominio | ✅ Activo | FM-XX-Formulas/ | | `ARQ-EL-BrainX-SOMA-v01` | Arquitectura | ✅ Activo | PB-BMF/ | --- ## 11. GLOSARIO CANÓNICO DE SOMA | Término | Definición canónica | |---|---| | **SOMA** | Sistema Operativo Metodológico y Arquitectónico. Capa de infraestructura cognitiva. Define cómo está construido el sistema. | | **SOMA-Core** | Arquitectura universal del ecosistema BMF. Inmutable entre dominios y engagements. Fuente de verdad de la arquitectura. | | **SOMA-Method** | Reglas estructurales universales. Naming convention, XDoc schema, gobernanza L0-L3. Sincronizado con versiones de WORX. | | **SOMA-Harness** | Configuración de ensamblaje de contexto para un room o sesión específica. La conexión práctica entre SOMA y el trabajo. | | **SOMA-[X]** | Extensión de SOMA por dominio (Brain[X]) o por engagement (cliente). Hereda de Core + Method. | | **MetaPlaybook** | Capa de metodología que opera sobre SOMA. Define cómo opera el sistema en un dominio. Actualizable sin tocar SOMA. | | **MetaPlaybook de dominio** | MetaPlaybook que define la operación de un Brain[X] completo (BrainSX, BrainPX, etc.). | | **MetaPlaybook de engagement** | Adaptación del MetaPlaybook de dominio al proceso específico de un cliente. Hereda del dominio. | | **Gradiente de changeability** | La escala de frecuencia y facilidad de cambio por capa: Core < Method < Harness < MetaPlaybook < MiniPlaybook. | | **Invariante de SOMA** | Regla que SOMA nunca viola. Modificarla requiere revisión de arquitectura con Victor. | | **Cadena de herencia** | SOMA-Core → SOMA-Method → SOMA-[X] → Harness → MetaPlaybook. El orden es obligatorio. | | **Bootstrap** | El proceso de cargar el stack de SOMA completo al inicio de una sesión para hacer operativo al Sherpa. | | **LoopX** | Nombre genérico de la metodología orbital. Framework base del que se derivan todos los loops de dominio (LoopSX, LoopMX, LoopPX, LoopTX). | | **Loop[X]** | Instancia de LoopX en un dominio específico. LoopSX = ventas, LoopMX = expertise, LoopPX = publicaciones. | | **BrainX** | Plataforma de motores de especialización. Brain[X] = instancia por dominio. | | **XDoc[X]** | Documento atómico de trabajo del dominio. XDocSX, XDocMX, XDocPX. Estructura de 7 secciones. | --- ## CHANGELOG | Fecha | Versión | Cambio | |---|---|---| | 2026-06-06 | v01 | Documento creado. Canonización completa de SOMA: definición, propósito, arquitectura de 4 capas (Core/Method/Harnesses/[X]), separación formal de MetaPlaybook, tabla de distinción, gradiente de changeability, cadena de herencia, 5 invariantes, protocolo de extensión, mapa de activos al 2026-06-06, glosario canónico de 16 términos. Surge del análisis de arquitectura BrainX × SOMA del 2026-06-06. | --- *DC-XX-SOMA-Canon-v01 · IB-XX-Maestro/IPI-XX-IP-Infraestructura/IPI-XX-SOMA/* *Generado por Jay · EmpowerLabs Brain OS · 2026-06-06* *Documento canónico — fuente de verdad del concepto SOMA* *Modificaciones requieren VoBo de Victor Heredia y actualización del CHANGELOG* *Cuando haya conflicto entre este documento y cualquier otro → este documento prevalece*