--- asset_id: TP-XX-BMF-SOMA-v01 type: TP — Transfer Pack version: v01 status: Activo — concepto en diseño owner: Victor Heredia sherpa_owner: Jay fecha: 2026-06-03 intellbank: IB-EL-EmpowerLabs proyecto: PB-BMF-BigMetaFactory proposito: > Brief para desarrollar el concepto SOMA dentro del ecosistema BMF. SOMA = Sistema Operativo Metodológico y Arquitectónico. Cargar este TP al abrir cualquier sesión de trabajo sobre SOMA. --- # TP · SOMA ## Sistema Operativo Metodológico y Arquitectónico ### Un concepto de BigMetaFactory — EmpowerLabs --- > *SOMA es el paquete de contexto que hace operativo un WORX OS desde cero. Es lo que hoy se reconstruye manualmente en cada nuevo engagement. Formalizar SOMA como un activo de la BigMetaFactory elimina ese costo.* --- ## El problema que resuelve Cada vez que arranca un nuevo engagement (nuevo cliente, nuevo proyecto, nueva instancia de Sherpa), alguien tiene que explicar: - Qué es BMF y cómo se estructura - Qué es DOIX y cómo funciona - Qué es SherpaX y qué puede y no puede hacer - Cuáles son las disciplinas WORX - Cómo se nombran los activos - Qué es un XDoc y cuál es su estructura Sin SOMA, eso se reconstruye cada vez — en el contexto de la sesión, en el TP Raíz de cada cliente, en el prompt de cada room. La información diverge. Se desactualiza. El Sherpa de un engagement nuevo sabe menos que el de uno maduro, aunque estén sobre la misma arquitectura. **SOMA resuelve esto:** es el bootstrap que cualquier Sherpa puede cargar para conocer la arquitectura completa y las reglas operativas — sin que nadie tenga que re-explicarlas. --- ## Qué es SOMA **SOMA** es un paquete de contexto estructurado, actualizable y reutilizable que define: 1. La **arquitectura cognitiva** del ecosistema (BMF, DOIX, SherpaX, WORX OS) 2. El **modelo operativo** para implementarlo (WORX — Método, Infraestructura, Interfaz) 3. Las **disciplinas fundamentales** de trabajo (naming, XDoc, dependencias, ciclo de activos) 4. Las **reglas de gobernanza** del sistema (qué puede hacer un Sherpa, qué no) SOMA no es un manual ni una presentación. Es un paquete funcional — se carga como contexto y el Sherpa puede operar con él de inmediato. --- ## Posición de SOMA dentro de BMF SOMA vive en la capa de **BigMetaFactory** — es un producto de la fábrica, no un activo de un proyecto o cliente. La BMF lo genera, lo mantiene y lo distribuye. ``` WORX OS ├── Core Prime │ ├── Info Brain │ └── Behavior Brain │ ├── BigMetaFactory ← SOMA vive aquí │ ├── SOMA-Core (arquitectura: BMF, DOIX, SherpaX) │ ├── SOMA-Method (metodología: WORX, disciplinas, naming) │ └── SOMA-[Engagement] (extensión por cliente o proyecto) │ └── SherpaX └── [Instancias activas] ``` --- ## Arquitectura modular de SOMA SOMA no es un documento único — es un sistema modular de tres capas: ### SOMA-Core **Qué contiene:** la arquitectura base del ecosistema — inmutable entre engagements - Definición de BMF (Big Meta Factory): qué es, sus 6 capas, cómo opera - Definición de DOIX: el modelo de organización inteligente - Definición de SherpaX: qué es una entidad vs. una herramienta, cómo funciona - Definición de WORX OS: las 3 capas (Core Prime → BMF → SherpaX) - Definición de IntelliBank: qué es un banco de inteligencia vs. repositorio **Frecuencia de actualización:** baja — solo cuando la arquitectura central evoluciona **Responsable:** Victor Heredia ### SOMA-Method **Qué contiene:** las reglas operativas del modelo WORX — actualizable con cada iteración - Los 3 pilares WORX (Método, Infraestructura, Interfaz) con detalle operativo - Naming convention BMF completa (todos los prefijos, reglas, ejemplos) - Estructura canónica del XDoc (7 secciones con descripción operativa) - Disciplinas fundamentales (D01-D06 del MasterPlaybook WORX) - Anti-patterns principales (AP01-AP07) - Ciclo de vida de activos cognitivos **Frecuencia de actualización:** media — sincronizado con versiones del MasterPlaybook WORX **Fuente de verdad:** `WOI-EL-WORX-MasterPlaybook-v01.md` ### SOMA-[Engagement] **Qué contiene:** extensión específica del engagement — única por cliente o proyecto - Contexto del cliente (codename, sector, equipo, dolor map) - Naming convention específica del cliente (ej. prefijos TI Posta) - Stack técnico acordado - Reglas de gobernanza específicas - Activos clave del engagement con rutas **Frecuencia de actualización:** alta — crece con el engagement **Ejemplo:** `SOMA-PO-Posta-v01.md` (el SOMA-Engagement de Posta) --- ## SOMA como Sistema Operativo La analogía es precisa: SOMA funciona como el sistema operativo de un WORX OS. | Componente OS | Equivalente SOMA | |---|---| | Kernel | SOMA-Core (arquitectura base) | | Sistema de archivos + APIs | SOMA-Method (reglas operativas) | | Perfil de usuario + apps instaladas | SOMA-Engagement (contexto específico) | Un Sherpa sin SOMA es como un OS sin instalar — el hardware existe pero no puede hacer nada útil. Un Sherpa con SOMA completo opera desde el primer prompt con conocimiento arquitectónico completo. --- ## Diferencia entre SOMA y TP Raíz | | TP Raíz | SOMA | |---|---|---| | **Alcance** | Un engagement específico | Universal + extensión por engagement | | **Contenido** | Contexto del cliente | Arquitectura + metodología + contexto | | **Actualización** | Con cada hito del proyecto | Con cada evolución de la metodología | | **Reutilización** | No — es único por cliente | Sí — SOMA-Core y SOMA-Method son compartidos | | **Responsable** | Jay + equipo de engagement | BigMetaFactory / Victor | El TP Raíz referencia al SOMA-Engagement correspondiente. El SOMA-Engagement referencia al SOMA-Core y SOMA-Method. --- ## Activos a generar | Activo | Descripción | Prioridad | |---|---|---| | `SOMA-EL-Core-v01.md` | Primer SOMA-Core: arquitectura BMF, DOIX, SherpaX, WORX OS | 🔴 Alta | | `SOMA-EL-Method-v01.md` | Primer SOMA-Method: WORX completo, naming, XDoc, disciplinas | 🔴 Alta | | `SOMA-PO-Posta-v01.md` | SOMA-Engagement de Posta — primero en producción | 🟡 Antes del Día 1 | | `WOI-EL-BMF-SOMA-Design-v01.md` | Documento de diseño detallado del sistema SOMA | 🟡 Media | | Prefijo `SOMA-` en naming convention BMF | Oficializar el prefijo en el Registry y naming guide | 🟡 Media | --- ## Preguntas de diseño abiertas Estas preguntas deben resolverse antes de generar los activos: 1. **¿SOMA-Core y SOMA-Method son TPs o un nuevo tipo de activo?** El TP está frozen por definición — pero el SOMA-Method necesita actualizarse. ¿Un WOI que "gradúa" a versiones? ¿Un tipo nuevo? 2. **¿Cómo se carga SOMA en un room?** ¿Como archivo de contexto en la configuración del proyecto? ¿Como primer mensaje del sistema? ¿Como documento dentro del IB del cliente? 3. **¿El SOMA-Engagement reemplaza al TP Raíz o lo complementa?** Propuesta: el SOMA-Engagement ES el TP Raíz extendido con las capas Core y Method incluidas por referencia — no por copia. 4. **¿Qué tan granular debe ser SOMA-Core?** Riesgo de sobre-documentar la arquitectura antes de que esté completamente estabilizada. --- ## Principio editorial de SOMA > *SOMA debe poder cargarse en un solo contexto de sesión y hacer operativo a cualquier Sherpa. Si un SOMA requiere múltiples sesiones para ser leído antes de poder operar — es demasiado largo. La prueba: un Sherpa nuevo + SOMA completo = operativo en el primer prompt.* --- *TP generado por Jay · EmpowerLabs Brain OS · 2026-06-03* *Proyecto: PB-BMF-BigMetaFactory · IntelliBank: IB-EL-EmpowerLabs*