---
asset_id: ARQ-EL-BrainX-SOMA-v01
tipo: ARQ — Documento de Arquitectura
version: v01
status: Activo — marco canónico en construcción
owner: Victor Heredia
sherpa_owner: Jay
fecha: 2026-06-06
intellibank: IB-EL-EmpowerLabs / PB-EL-Project-Bank / PB-BMF-BigMetaFactory
proposito: >
  Documento canónico que establece la arquitectura formal de BrainX y el rol
  refinado de SOMA dentro de ella. Define la distinción entre SOMA (infraestructura)
  y MetaPlaybook (metodología), formaliza los Harnesses como componente propio,
  y establece la pila de 5 niveles que cualquier BrainX debe cumplir. Es la
  piedra angular para construir metafactorías replicables por dominio y adaptables
  por cliente.
relacionado_con:
  - SOMA-XX-Core-v01.md
  - SOMA-XX-Method-v01.md
  - TP-XX-BMF-SOMA-v01.md
  - XP-EL-LoopX-PilotoHiOrgHighTicket-v01.md
  - IB-WikiX/Wiki/SOMA.md
  - IB-WikiX/Wiki/BrainX-Loop.md
---

# ARQ-EL-BrainX-SOMA-v01
## Arquitectura BrainX × SOMA · Marco canónico de diseño

> *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. Cuando los dos están separados, la organización puede aprender
> sin romperse.*

---

## PRÓLOGO — Por qué este documento existe ahora

El 6 de junio de 2026, durante el diseño de BrainX Loop (LoopX), surgió una
pregunta de arquitectura que tenía respuesta obvia en superficie pero consecuencias
profundas: ¿SOMA y MetaPlaybook son el mismo concepto o dos capas distintas?

La respuesta es que son dos capas distintas con ciclos de vida, responsables y
tasas de cambio fundamentalmente diferentes. Mezclarlos produce un sistema que
se rompe cada vez que alguien quiere mejorar un procedimiento — porque para
mejorar el procedimiento tiene que tocar la arquitectura.

Este documento establece la distinción de manera formal, la conecta con la
arquitectura BrainX, y define el protocolo de composición que permite construir
motores de especialización replicables para cualquier dominio y adaptables a
cualquier cliente.

---

## 1. EL PROBLEMA QUE ESTA ARQUITECTURA RESUELVE

### 1.1 El problema sin resolver en SOMA v01

El `SOMA-XX-Method-v01.md` creado el 2026-06-03 resolvió correctamente el
problema del bootstrap de cualquier Sherpa: cargarlo hace operativo al agente
desde el primer prompt. Pero mezcla dos tipos de contenido que tienen ritmos
de cambio distintos:

- **Reglas de infraestructura** (naming convention, esquema de XDoc, niveles de
  gobernanza L0-L3): cambian poco porque definen las reglas del sistema operativo.
- **Procedimientos operativos** (disciplinas D01-D06, anti-patterns, flujos de
  trabajo): cambian frecuentemente porque el equipo aprende y mejora.

Poner ambos en el mismo documento crea un problema: cada vez que alguien aprende
algo nuevo sobre cómo operar mejor (algo deseable), tiene que editar SOMA (algo
que debería ser estable). El resultado es un SOMA que se desestabiliza con la
frecuencia de la metodología en lugar de con la frecuencia de la arquitectura.

### 1.2 El problema de BrainX sin SOMA formal

BrainX nació como un concepto de "plataforma de motores de especialización". Cada
motor (BrainSX, BrainMX, BrainPX) tiene lógica propia, pero sin una arquitectura
formal los motores se construyen ad-hoc, sin un patrón replicable, y sin claridad
sobre qué está en la capa de infraestructura versus qué está en la capa de método.

El resultado: el primer cliente recibe un BrainSX hecho a mano. El segundo recibe
una versión diferente porque quien lo construyó tomó decisiones distintas. La
metafactoría no puede escalar porque no tiene un molde.

### 1.3 Lo que esta arquitectura habilita

Al separar SOMA de MetaPlaybook y formalizarlos como capas distintas dentro de
BrainX, se habilita:

1. **Replicabilidad:** el mismo molde BrainX produce motores de cualquier dominio
   sin reinventar la arquitectura cada vez.
2. **Adaptabilidad por cliente:** la capa metodológica (MetaPlaybook) se adapta al
   proceso del cliente sin tocar la capa arquitectónica (SOMA).
3. **Mejora continua sin riesgo:** el equipo puede actualizar MetaPlaybooks con cada
   aprendizaje sin tocar SOMA — la infraestructura es estable mientras la metodología
   mejora.
4. **Escalabilidad hacia DOIX:** cuando múltiples BrainX se interconectan en una
   organización (DOIX), la capa SOMA es el contrato de interoperabilidad. Si SOMA
   es estable, los BrainX pueden hablar entre sí.

---

## 2. SOMA — DEFINICIÓN REFINADA Y ARQUITECTURA INTERNA

### 2.1 Definición canónica (v02 — refinada)

> **SOMA** (Sistema Operativo Metodológico y Arquitectónico) es la capa de
> **infraestructura cognitiva** que define cómo está construido un BrainX: sus
> componentes, sus capas, sus reglas estructurales, su gobernanza, y los harnesses
> que montan el contexto en tiempo de operación. SOMA no define cómo opera el
> sistema — eso es el MetaPlaybook. SOMA define sobre qué opera.

La analogía del sistema operativo es precisa y debe tomarse literalmente:

| Componente OS | Equivalente SOMA | Qué define |
|---|---|---|
| Kernel | SOMA-Core | Arquitectura base: BMF, DOIX, SherpaX, WORX OS |
| Sistema de archivos + APIs | SOMA-Method | Reglas estructurales: naming, XDoc, gobernanza L0-L3 |
| Drivers | SOMA-Harnesses | Cómo se monta el contexto en cada room o sesión |
| Perfil + apps instaladas | SOMA-[X] | Extensión por dominio (SX, MX, PX) o por cliente |

MetaPlaybook son las aplicaciones. SOMA es el OS. Las aplicaciones corren sobre
el OS, no dentro de él.

### 2.2 Las cuatro capas de SOMA (arquitectura refinada)

La versión original de SOMA tenía tres capas (Core, Method, [Engagement]).
Esta versión añade una cuarta capa explícita: Harnesses.

```
SOMA
├── SOMA-Core        → Arquitectura universal (BMF, DOIX, SherpaX, WORX OS)
│                      Frecuencia de cambio: MUY BAJA
│                      Responsable: Victor Heredia
│                      Condición de cambio: evolución de la arquitectura central
│
├── SOMA-Method      → Reglas estructurales del sistema (naming, XDoc schema,
│                      gobernanza L0-L3, ciclo de vida de activos, registry)
│                      Frecuencia de cambio: BAJA
│                      Responsable: Victor Heredia + equipo senior
│                      Condición de cambio: versión de WORX o decisión de arquitectura
│
├── SOMA-Harnesses   → Configuración de ensamblaje de contexto por room / sesión
│                      (qué SOMA cargar, en qué orden, qué MetaPlaybooks activos,
│                      qué Brain Codes, qué IBs, qué nivel de gobernanza)
│                      Frecuencia de cambio: MEDIA
│                      Responsable: Jay (diseño) + Victor (ratificación)
│                      Condición de cambio: nuevo tipo de room o nuevo dominio
│
└── SOMA-[X]         → Extensión por dominio o por engagement
                       SOMA-SX (ventas) · SOMA-PX (publicaciones) · SOMA-MX (expertise)
                       SOMA-EL (EmpowerLabs como organización)
                       SOMA-PO (Posta como engagement cliente)
                       Frecuencia de cambio: ALTA
                       Responsable: Jay + dueño del dominio/engagement
                       Condición de cambio: evolución del dominio o del cliente
```

**La regla de estabilidad descendente:** cada capa solo puede cambiar por condiciones
propias de su nivel. Un aprendizaje operativo (nivel MetaPlaybook) no justifica
tocar SOMA-Core. Una mejora de procedimiento de ventas (nivel MetaPlaybook-SX)
no justifica tocar SOMA-SX. Si se siente la necesidad de tocar SOMA para reflejar
un aprendizaje, es señal de que el aprendizaje pertenece a un MetaPlaybook.

### 2.3 Los Harnesses — el componente faltante

Un **Harness** (arnés) es la configuración que especifica cómo ensamblar el
contexto completo para un room, sesión o agente específico. Es el equivalente
al driver que conecta el OS con el hardware: sin él, el OS existe pero no sabe
cómo comunicarse con los periféricos.

**Qué define un Harness:**

```yaml
harness:
  id: HNS-EL-LoopX-SalesRoom-v01
  dominio: SX
  room_type: Sales Pipeline Room
  carga_contexto:
    - SOMA-XX-Core-v01          # siempre primero
    - SOMA-XX-Method-v01        # siempre segundo
    - SOMA-SX-v01               # extensión del dominio
    - MetaPlaybook-SX-Demo-v01  # metodología activa en este room
    - BC-VictorHeredia-Own-v01  # Brain Code del dueño
  intellibanks_activos:
    - IB-EL-EmpowerLabs/PB-LoopX/
  brain_codes_activos:
    - BC-VictorHeredia-Own-v01
  gobernanza: L1               # qué ratificación requiere el Sherpa
  TP_raiz: TP-EL-LoopX-Raiz-v01
```

**Por qué Harnesses pertenecen a SOMA y no a MetaPlaybooks:**

Los Harnesses definen la arquitectura de cómo se monta el sistema — no los
procedimientos que el sistema ejecuta. Cambiar un Harness cambia qué tan capaz
es el Sherpa en un room (qué contexto tiene disponible), no qué procedure sigue.
Es una decisión de infraestructura, no de metodología.

**Convención de naming:**

```
HNS-[IB]-[Dominio]-[TipoRoom]-vNN.md
HNS-EL-SX-SalesPipelineRoom-v01.md
HNS-PO-TX-LabMetodoRoom-v01.md
```

### 2.4 Qué entra a SOMA y qué NO

| Entra a SOMA | No entra a SOMA → va a MetaPlaybook |
|---|---|
| Definición de capas de la arquitectura (BMF, DOIX, SherpaX) | Procedimiento de cómo hacer una demo de ventas |
| Reglas de naming convention (estructura del nombre) | Guía de qué decir en cada paso de la demo |
| Esquema canónico del XDoc (qué secciones tiene) | Cómo llenar cada sección del XDoc en el contexto de ventas |
| Niveles de gobernanza L0-L3 (qué puede hacer el Sherpa) | Cómo escalar una objeción específica de prospecto |
| Ciclo de vida de activos cognitivos (estados) | Cuándo y cómo mover una oportunidad entre órbitas |
| Definición de IntelliBank vs. carpeta | Cómo organizar los activos de un cliente específico |
| Configuración de Harness (qué cargar en qué room) | Qué material preparar antes de un Zoom de cierre |
| Definición de Gravity Score (qué es, escala 0-100) | Cómo calcular el Gravity Score de un prospecto específico |

**La prueba de clasificación:** si el contenido responde "¿cómo está construido
el sistema?", es SOMA. Si responde "¿cómo opera el sistema en este dominio?",
es MetaPlaybook.

---

## 3. METAPLAYBOOK — SU LUGAR CORRECTO EN LA ARQUITECTURA

### 3.1 Evolución del concepto

El MetaPlaybook (`MePB-`) existía antes de esta arquitectura como "procedimiento
canónico de operación" — una guía paso a paso para ejecutar algo específico. Los
primeros MetaPlaybooks del ecosistema son de ese tipo: `MePB-XX-BrainCode-Anatomy-v02`
(cómo crear un Brain Code), `MePB-XX-MasterBrainCodeDistiller-v02` (cómo destilar).

Esta arquitectura no elimina esos MetaPlaybooks — los eleva y les da un contexto
de sistema. Un MetaPlaybook ya no es solo una guía flotante: es un componente de
la capa de metodología de un BrainX específico, con un dominio declarado, una
versión trazable, y una relación explícita con el SOMA sobre el que opera.

### 3.2 Definición refinada

> **MetaPlaybook** es el componente de la capa de metodología de un BrainX.
> Define **cómo opera el sistema** en un dominio específico: los workflows,
> los criterios de decisión, las secuencias de acción, y las reglas de ejecución
> que el Sherpa aplica sobre la infraestructura que SOMA provee.
> MetaPlaybook se actualiza con los aprendizajes del equipo sin tocar SOMA.

La analogía correcta: si SOMA es el sistema operativo, MetaPlaybook es la
aplicación que corre sobre él. Actualizar Microsoft Word no requiere reinstalar
Windows. Actualizar el Sales MetaPlaybook no requiere modificar SOMA.

### 3.3 Anatomía de un MetaPlaybook de dominio

Un MetaPlaybook de dominio (a diferencia de los MetaPlaybooks procedurales
anteriores) tiene la siguiente estructura:

```
MetaPlaybook-SX-v01.md
├── 1. PROPÓSITO DEL DOMINIO
│   ¿Qué problema resuelve este BrainX en la organización?
│
├── 2. WORKFLOWS CANÓNICOS
│   Los flujos de trabajo principales del dominio, secuenciados.
│   Cada workflow referencia el Loop[X] correspondiente.
│
├── 3. CRITERIOS DE DECISIÓN
│   Las reglas de juicio del Sherpa: cuándo avanzar, cuándo escalar,
│   cuándo rechazar, cuándo proponer. Codifica el criterio del dueño.
│
├── 4. VOCABULARIO DEL DOMINIO
│   Orbit states específicos, métricas clave, definiciones propias
│   del dominio que amplían o especifican el vocabulario de SOMA.
│
├── 5. SCRIPTS Y MARCOS
│   Frameworks de conversación, marcos de propuesta, estructuras de demo.
│   Lo que el Sherpa puede invocar directamente.
│
├── 6. ANTI-PATTERNS DEL DOMINIO
│   Los errores específicos de este dominio que el Sherpa debe evitar.
│
├── 7. MÉTRICAS DE SALUD
│   Cómo saber si el dominio está operando bien: KPIs, señales de alerta.
│
└── 8. CHANGELOG
    Historial de aprendizajes que modificaron el MetaPlaybook.
```

### 3.4 Tipos de MetaPlaybook

| Tipo | Prefijo | Alcance | Ejemplo |
|---|---|---|---|
| **Dominio** | `MePB-[IB]-[X]-v01` | Un BrainX completo | `MePB-EL-SX-v01` — Sales Brain |
| **Procedural** | `MePB-[IB]-[Proceso]-v01` | Un proceso específico | `MePB-XX-BrainCode-Anatomy-v02` |
| **Engagement** | `MePB-[IB]-[Cliente]-v01` | Adapta el dominio al cliente | `MePB-PO-SX-v01` — Sales Brain adaptado a Posta |
| **MiniPlaybook** | `MiPB-[IB]-[Micro]-v01` | Un micro-proceso muy específico | `MiPB-EL-SX-CierreZoom-v01` |

**Jerarquía de MetaPlaybooks:**

```
MetaPlaybook-SX (dominio universal)
  └── MetaPlaybook-SX-[Cliente] (adaptación por engagement)
        └── MiniPlaybooks específicos (micro-procesos del cliente)
```

Un Sherpa carga el MetaPlaybook de dominio como base y el de engagement como
extensión. Los MiniPlaybooks se invocan on-demand en flows específicos.

---

## 4. LA DISTINCIÓN SOMA ↔ METAPLAYBOOK

### 4.1 La tabla central

| Dimensión | SOMA | MetaPlaybook |
|---|---|---|
| **Pregunta que responde** | ¿Cómo está construido el sistema? | ¿Cómo opera el sistema? |
| **Capa** | Infraestructura + arquitectura | Metodología + procedimiento |
| **Nivel de abstracción** | Alto — reglas del juego | Medio — cómo se juega |
| **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, gobernanza, naming rules | Workflows, criterios, scripts, métricas, anti-patterns de dominio |
| **Relación con BrainX** | Define la arquitectura del brain | Define cómo el brain opera en su dominio |
| **Relación entre sí** | SOMA provee la infraestructura sobre la que MetaPlaybook opera | MetaPlaybook corre sobre SOMA, no dentro de él |
| **Analogía OS** | Kernel + filesystem + drivers | Aplicación instalada |
| **Riesgo de cambio incorrecto** | Alto — puede romper el sistema | Bajo — solo afecta el dominio |
| **Ejemplo BrainSX** | Qué componentes tiene el brain, cómo se conectan, qué Harness carga | Cómo qualificar un prospecto, cuándo escalar, cómo cerrar |

### 4.2 El gradiente de changeability

No todas las capas del sistema cambian igual de fácil o de seguido. El gradiente
va de arquitectura (cambia con menor frecuencia, mayor impacto) a ejecución
(cambia frecuentemente, menor impacto):

```
IMMUTABLE ←──────────────────────────────────────────────────→ FLUID

SOMA-Core    SOMA-Method    SOMA-Harnesses    MetaPlaybook    MiniPlaybook
  │              │                │                │               │
Años         Meses-Años       Semanas-Meses    Días-Semanas    Horas-Días
Arquitectura Reglas struct.  Config. rooms    Metodología      Micro-proceso
Victor solo  Victor+Senior   Jay+Victor       Jay+Equipo       Sherpa

Riesgo de cambio: ████████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
```

**Implicación práctica:** cuando alguien identifica "esto debería funcionar
diferente", la primera pregunta es ¿en qué capa del gradiente vive? Eso determina
quién puede cambiarlo, con qué proceso de ratificación, y qué efecto tiene en el
resto del sistema.

### 4.3 La regla de separación

> *Si cambiar la metodología requiere cambiar la arquitectura, la arquitectura
> está mal diseñada.*

Esta regla es la prueba de fuego de la separación SOMA-MetaPlaybook. Un BrainSX
bien diseñado puede adoptar un proceso de ventas completamente diferente (nuevo
MetaPlaybook-SX) sin que el Sherpa necesite ser reconfigurado a nivel SOMA.

El equivalente: instalar una nueva versión de tu CRM no debería requerir cambiar
el sistema operativo del servidor. Si lo requiere, el CRM está mal diseñado.

### 4.4 El test de cuatro preguntas

Antes de decidir si algo pertenece a SOMA o a MetaPlaybook, aplicar este test:

| Pregunta | Si la respuesta es SÍ → | Si la respuesta es NO → |
|---|---|---|
| ¿Aplica igual sin importar el dominio (ventas / publicaciones / expertise)? | SOMA-Core o SOMA-Method | MetaPlaybook de dominio |
| ¿Cambiar esto requiere notificar a Victor antes de ejecutar? | SOMA | MetaPlaybook |
| ¿Hacerlo mal rompe la interoperabilidad entre múltiples BrainX? | SOMA | MetaPlaybook |
| ¿Es una configuración de contexto (qué cargar, en qué orden)? | SOMA-Harness | MetaPlaybook o MiniPlaybook |

---

## 5. BRAINX — LA PLATAFORMA DE MOTORES DE ESPECIALIZACIÓN

### 5.1 Definición canónica

> **BrainX** es la plataforma que aloja motores de especialización cognitiva
> organizacional. Cada motor (Brain[SX], Brain[MX], Brain[PX]) combina una capa
> de infraestructura (SOMA) con una capa de metodología (MetaPlaybook) y un
> workflow orbital (Loop[X]) para operar de forma autónoma en un dominio específico.
> BrainX no es una herramienta — es un sistema que aprende y se densifica con el uso.

### 5.2 La pila de 5 niveles

Cada BrainX implementado cumple exactamente esta pila de 5 niveles. Sin excepción.
Si alguno falta, el motor no está completo.

```
NIVEL 5 ─── PLATAFORMA ──────────────────────────────────────────────────
│
│  BrainX
│  La plataforma que aloja todos los motores. Proporciona los servicios
│  compartidos: IntelliBanks, WORX OS, SOMA-Core, SOMA-Method,
│  conectores (MCP), interfaz de Sherpa.
│
NIVEL 4 ─── MOTOR DE DOMINIO ───────────────────────────────────────────
│
│  Brain[SX] / Brain[MX] / Brain[PX] / Brain[TX]
│  La instancia del motor para un dominio específico.
│  Tiene su SOMA-[X] (infraestructura del dominio) y su
│  MetaPlaybook-[X] (metodología del dominio).
│
NIVEL 3 ─── WORKFLOW ORBITAL ───────────────────────────────────────────
│
│  Loop[SX] / Loop[MX] / Loop[PX] / Loop[TX]
│  El workflow que mueve los activos del dominio a través de sus estados.
│  En LoopSX: oportunidades se mueven por órbitas (caliente → salida).
│  En LoopPX: manuscripts se mueven por fases (borrador → publicado).
│
NIVEL 2 ─── DOCUMENTO ATÓMICO ──────────────────────────────────────────
│
│  XDoc[SX] / XDoc[MX] / XDoc[PX] / XDoc[TX]
│  La unidad canónica de trabajo del dominio.
│  Estructura de 7 secciones: Cabecera, Contexto, Estado, Protocolo,
│  Next, Discussion, Changelog, Cierre.
│  El sufijo de dominio declara el tipo de XDoc.
│
NIVEL 1 ─── REGISTRO Y MEMORIA ─────────────────────────────────────────

   IntelliBanks + WORX OS + LLM-Wiki
   La memoria estructurada sobre la que opera todo el sistema.
   Sin esta capa, los niveles superiores no tienen dónde vivir.
```

### 5.3 Dependencias entre niveles

El principio es de abajo hacia arriba: cada nivel requiere que el nivel inferior
esté operativo. No se puede operar un Loop sin XDocs. No se puede tener XDocs sin
IntelliBanks. No se puede construir el Motor antes de tener SOMA-[X].

```
Nivel 1 (Memoria)     → prerequisito de todo lo demás
Nivel 2 (XDoc[X])     → requiere Nivel 1 + naming convention de SOMA
Nivel 3 (Loop[X])     → requiere Nivel 2 + Harness de SOMA + MetaPlaybook
Nivel 4 (Brain[X])    → requiere Nivel 3 + SOMA-[X] + MetaPlaybook-[X]
Nivel 5 (BrainX)      → requiere al menos un Brain[X] operativo
```

### 5.4 Cómo se ensambla un BrainX nuevo

Secuencia obligatoria para construir un motor de dominio nuevo:

```
ETAPA 1 · ARQUITECTURA
  1. Definir el dominio ([X]) y su propósito
  2. Crear SOMA-[X]: qué componentes tiene el brain, cómo se conectan
  3. Definir el Harness: qué se carga en cada tipo de room del dominio
  4. Crear la estructura de IntelliBanks del dominio

ETAPA 2 · METODOLOGÍA
  5. Crear MetaPlaybook-[X]: workflows, criterios, scripts, métricas
  6. Definir el vocabulario de dominio (orbit states, métricas propias)
  7. Documentar los anti-patterns específicos del dominio

ETAPA 3 · WORKFLOW
  8. Diseñar Loop[X]: estados posibles, transiciones válidas, triggers
  9. Crear la estructura de XDoc[X]: qué campos específicos del dominio
  10. Construir el Dashboard: visualización del Loop[X] en tiempo real

ETAPA 4 · VALIDACIÓN
  11. Prueba de operatividad: ¿puede un Sherpa nuevo operar el Brain[X]
      solo con SOMA + MetaPlaybook + Harness, sin sesión de briefing?
  12. Prueba de separación: ¿se puede actualizar el MetaPlaybook-[X]
      sin tocar SOMA-[X]?
  13. Prueba de adaptación: ¿puede el Brain[X] ajustarse al proceso de un
      cliente nuevo solo modificando MetaPlaybook-[X]-[Cliente]?
```

---

## 6. DOMINIOS CANÓNICOS — EL SUFIJO [X]

El sufijo de dominio viaja de forma consistente por toda la pila. Un dominio SX
produce: SOMA-SX, MetaPlaybook-SX, LoopSX, XDocSX, Brain-SX. Esto hace que la
arquitectura sea legible sin necesidad de documentación adicional.

### 6.1 SX — Sales Brain (Cerebro de Ventas)

| Componente | Instancia |
|---|---|
| Motor | BrainSX |
| SOMA | SOMA-SX-v01.md |
| MetaPlaybook | MetaPlaybook-SX-v01.md |
| Workflow | LoopSX |
| XDoc | XDocSX |
| Dashboard | LoopX-Pipeline-Dashboard.html |

**Dominio:** gestión orbital de oportunidades comerciales, desde warm-up hasta
cierre o salida. Orbit states: caliente / acercándose / entrante / enfriándose /
latente / salida. Gravity Score: 0-100 (probabilidad × engagement × timing).

**Primer caso en operación:** EmpowerLabs → 8 oportunidades activas al 2026-06-06.

### 6.2 MX — Monetization Brain (Cerebro de Monetización de Expertise)

| Componente | Instancia |
|---|---|
| Motor | BrainMX |
| SOMA | SOMA-MX-v01.md |
| MetaPlaybook | MetaPlaybook-MX-v01.md |
| Workflow | LoopMX |
| XDoc | XDocMX |

**Dominio:** gestión orbital de activos de expertise monetizable: cursos,
programas, masterclasses, Brain Codes productizados, comunidades de práctica.
Orbit states: en_diseño / en_producción / lanzado / escalando / descontinuado.
Gravity Score: escala viabilidad económica × audiencia × urgencia de mercado.

**Conexión con el ecosistema:** cada MetaPlaybook (MPB-) del ecosistema editorial
es un activo de LoopMX. José Fernández (Programa Internacional) es una oportunidad
de LoopMX, no de LoopSX: no es un prospecto de venta — es un partner de
monetización de expertise.

### 6.3 PX — Publishing Brain (Cerebro de Publicaciones)

| Componente | Instancia |
|---|---|
| Motor | BrainPX |
| SOMA | SOMA-PX-v01.md |
| MetaPlaybook | MetaPlaybook-PX-v01.md |
| Workflow | LoopPX |
| XDoc | XDocPX |

**Dominio:** gestión orbital de activos editoriales: libros, decks, artículos,
newsletters, MasterPlaybooks como producto. Orbit states: en_boceto / en_escritura /
en_revisión / listo_para_publicar / publicado / en_mercado / descatalogado.
Gravity Score: escala % completado × impacto esperado × urgencia editorial.

**Conexión con el ecosistema:** la MetaFactoría Editorial (MF-EDITORIAL) es la
factoría que produce los activos que LoopPX rastrea. BrainPX es el cerebro que
gobierna la MF-EDITORIAL.

### 6.4 TX — Transformation Brain (Cerebro de Transformación)

| Componente | Instancia |
|---|---|
| Motor | BrainTX |
| SOMA | SOMA-TX-v01.md |
| MetaPlaybook | MetaPlaybook-TX-v01.md |
| Workflow | LoopTX |
| XDoc | XDocTX |

**Dominio:** gestión orbital de engagements de transformación organizacional
(WORX + DOIX + HIOrg). Un engagement TX tiene un ciclo de vida desde diagnóstico
hasta DOIX operativo. Orbit states: en_diagnóstico / en_lab / en_implementación /
DOIX_activo / mantenimiento. Gravity Score: escala avance de implementación ×
adopción del equipo × ROI documentado.

**Conexión con el ecosistema:** Posta es una oportunidad tanto de LoopSX (la
cuenta comercial) como de LoopTX (el engagement de transformación). Son dos XDocs
distintos sobre la misma empresa, en dos Loops distintos.

### 6.5 Extensión del patrón — nuevos dominios

El sufijo [X] es abierto. Nuevos dominios se crean cuando:
1. Existe un workflow orbital propio (activos con estados y transiciones).
2. El dominio tiene métricas de "gravity" propias (no las de otro dominio).
3. El Sherpa necesita un MetaPlaybook específico para operar en ese dominio.
4. Hay al menos 5 activos activos que justifican el Loop.

Candidatos de próxima generación:

| Sufijo | Dominio | Trigger |
|---|---|---|
| HX | Hiring / Talent | Cuando el equipo supere 10 personas activas en reclutamiento |
| CX | Community / Comunidad | Cuando las comunidades de práctica requieran gestión orbital |
| IX | Intelligence / Research | Cuando el output de investigación sea suficientemente alto |
| AX | Alliance / Alianzas | (alternativa a fusionar alianzas en LoopSX) |

---

## 7. SOMA POR DOMINIO — SOMA-[X]

### 7.1 Definición de SOMA-[X]

Un SOMA-[X] es la capa de infraestructura específica de un motor de dominio. No
es SOMA-Core (universal) ni SOMA-Method (reglas compartidas): es la extensión
que define la arquitectura propia del Brain[X].

Un SOMA-SX define:
- Los componentes del BrainSX: LoopSX, XDocSX, Dashboard, Gravity Engine
- Las conexiones entre esos componentes
- El Harness del dominio: qué cargar para operar en un room de ventas
- Los Brain Codes relevantes para el dominio (cuáles cargar siempre)
- El vocabulario de dominio (orbit states, tier system, alert thresholds)
- Las reglas de escalación específicas de ventas (L0-L3 para decisiones de deal)

Un SOMA-SX NO define:
- Cómo cualificar un prospecto (MetaPlaybook-SX)
- Qué decir en una demo (MetaPlaybook-SX o MiniPlaybook)
- Cuánto cobrar (MetaPlaybook-SX + criterio del owner)

### 7.2 Diferencia entre SOMA-[X] y SOMA-[Engagement]

Esta distinción no existía en SOMA v01 y es crítica para escalar:

| | SOMA-[X] (Dominio) | SOMA-[Engagement] (Cliente) |
|---|---|---|
| **Alcance** | Universal dentro del dominio | Específico del engagement cliente |
| **Ejemplo** | SOMA-SX = arquitectura del Brain de Ventas | SOMA-PO = Posta como engagement |
| **Reutilización** | Se reutiliza en todos los clientes que usan BrainSX | Único — no se reutiliza |
| **Herencia** | Hereda de SOMA-Core + SOMA-Method | Hereda de SOMA-Core + SOMA-Method + SOMA-[X] |
| **Qué agrega** | Arquitectura del dominio (componentes, harness, vocab) | Contexto del cliente (stack, equipo, naming propio) |
| **Responsable** | Victor / arquitecto del dominio | Jay + equipo de engagement |

La cadena de herencia completa para un engagement de ventas con Posta:

```
SOMA-Core (arquitectura universal)
  └── SOMA-Method (reglas universales)
        └── SOMA-SX (arquitectura del dominio ventas)
              └── SOMA-PO (contexto del engagement Posta)
                    └── MetaPlaybook-SX (metodología ventas)
                          └── MetaPlaybook-SX-PO (metodología adaptada a Posta)
```

---

## 8. MODELO DE ADAPTACIÓN POR CLIENTE

### 8.1 El principio de adaptación

La arquitectura BrainX está diseñada para ser adaptable al proceso de cada cliente
sin tocar las capas universales. Esto es lo que hace posible la metafactoría: se
produce el molde una vez, se adapta por cliente.

```
INVARIANTE (igual para todos los clientes)
├── SOMA-Core
├── SOMA-Method
├── SOMA-[X]  (arquitectura del dominio)
└── MetaPlaybook-[X]  (metodología base del dominio)

VARIABLE (único por cliente)
├── SOMA-[X]-[Cliente]  (extensión del dominio al proceso del cliente)
├── MetaPlaybook-[X]-[Cliente]  (metodología adaptada al proceso del cliente)
├── XDoc[X]-[Cliente]  (campos adicionales del XDoc para el cliente)
└── Dashboard-[Cliente]  (visualización del Loop adaptada al branding/proceso del cliente)
```

### 8.2 La prueba de adaptabilidad

Un BrainX bien diseñado pasa esta prueba: se puede reemplazar `MetaPlaybook-SX`
con `MetaPlaybook-SX-Posta` (que refleja el proceso comercial específico de Posta)
y el Sherpa opera con el proceso de Posta — sin que nadie tenga que reconfigurar
SOMA-SX.

**Análogía:** instalar Firefox en lugar de Chrome no requiere reinstalar Windows.
Instalar el proceso comercial de Posta en lugar del proceso comercial estándar no
requiere reconstruir BrainSX.

### 8.3 Lo que se vende y lo que se produce

| Entregable | Capa | Producido por | Reutilizable |
|---|---|---|---|
| BrainX base (plataforma) | Nivel 5 | EmpowerLabs (una vez) | Sí — todos los clientes |
| Brain[X] (motor de dominio) | Nivel 4 | EmpowerLabs (por dominio) | Sí — todos los clientes del dominio |
| SOMA-[X]-[Cliente] | Infraestructura cliente | EmpowerLabs (por engagement) | No |
| MetaPlaybook-[X]-[Cliente] | Metodología cliente | EmpowerLabs + cliente | No |
| XDoc[X] iniciales | Workflow | EmpowerLabs + cliente | Sí (template) |
| Dashboard cliente | Visualización | EmpowerLabs | No (branded) |

---

## 9. RELACIONES CON EL ECOSISTEMA

### 9.1 BrainX en el WORX OS

```
WORX OS
├── Core Prime
│   ├── Info Brain        → LLM-Wiki + IntelliBanks
│   └── Behavior Brain    → Brain Codes + MetaPlaybooks
│
├── BigMetaFactory
│   ├── SOMA              → La arquitectura de BrainX vive aquí
│   ├── Brain[X] Engines  → Los motores de dominio
│   └── MetaPlaybooks     → Las metodologías de dominio
│
└── SherpaX
    ├── Sherpa personal   → Opera los Brain[X] asignados al humano
    └── Corp Sherpa       → Vista agregada de todos los Brain[X] activos
```

### 9.2 BrainX en HIOrg

HIOrg (Organización Hiperinteligente) tiene cinco componentes canónicos.
BrainX no es un componente separado — es la articulación operativa de varios
componentes de HIOrg:

| Componente HIOrg | Rol en BrainX |
|---|---|
| IntelliBanks | Nivel 1 de la pila BrainX (memoria) |
| BMF | La fábrica que produce los activos que los Brain[X] consumen |
| SherpaX | El Sherpa que opera cada Brain[X] |
| EmpowerTeamsX | El equipo humano-IA que trabaja sobre los Brain[X] |
| Organizational Brain | La inteligencia emergente cuando múltiples Brain[X] comparten contexto |

### 9.3 BrainX en DOIX

DOIX emerge cuando múltiples Brain[X] se interconectan. La SOMA de cada Brain[X]
es el contrato de interoperabilidad: si SOMA-SX y SOMA-TX comparten el mismo
SOMA-Core y SOMA-Method, los Sherpas de ambos dominios pueden colaborar sin
necesidad de re-explicar el contexto base.

**Ejemplo:** el Sherpa de BrainSX identifica que una oportunidad (LoopSX) ha
firmado y debe abrirse un engagement de transformación (LoopTX). Si ambos Sherpas
comparten SOMA-Core, la transferencia de contexto es trivial: el XDocSX se
convierte en el punto de partida del XDocTX. Sin SOMA compartido, la transferencia
requiere una sesión de briefing completa.

---

## 10. GLOSARIO CANÓNICO — TÉRMINOS DE ESTA ARQUITECTURA

| Término | Definición canónica |
|---|---|
| **BrainX** | Plataforma de motores de especialización cognitiva organizacional. Aloja Brain[X] por dominio. |
| **Brain[SX/MX/PX/TX]** | Motor de dominio específico dentro de BrainX. Combina SOMA-[X] + MetaPlaybook-[X] + Loop[X]. |
| **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. |
| **SOMA-Method** | Reglas estructurales universales: naming, XDoc schema, gobernanza L0-L3, ciclo de activos. |
| **SOMA-Harness** | Configuración de ensamblaje de contexto para un room o sesión específica. |
| **SOMA-[X]** | Extensión de SOMA por dominio: arquitectura, componentes y harness del Brain[X]. |
| **SOMA-[Engagement]** | Extensión de SOMA por cliente o proyecto: contexto específico del engagement. |
| **MetaPlaybook** | Componente de la capa de metodología. Define cómo opera el sistema en un dominio. Se actualiza sin tocar SOMA. |
| **MetaPlaybook-[X]** | MetaPlaybook de dominio: workflows, criterios, scripts, métricas del Brain[X]. |
| **MetaPlaybook-[X]-[Cliente]** | MetaPlaybook adaptado al proceso específico del cliente. Hereda de MetaPlaybook-[X]. |
| **Loop[X]** | Workflow orbital del dominio. Mueve activos por sus estados usando Gravity Score. |
| **XDoc[X]** | Documento atómico de trabajo del dominio. Estructura de 7 secciones con campos del dominio. |
| **Harness** | Ver SOMA-Harness. El arnés que conecta el OS con la sesión específica. |
| **Gradiente de changeability** | La escala de qué tan fácil/frecuente es cambiar cada capa: Core < Method < Harness < MetaPlaybook < MiniPlaybook. |
| **Prueba de separación** | ¿Se puede actualizar MetaPlaybook-[X] sin tocar SOMA-[X]? Si no: el diseño tiene acoplamiento incorrecto. |
| **SOMAX** | Término informal para SOMA-[X]: el SOMA de un dominio específico de BrainX. |

---

## 11. PREGUNTAS DE DISEÑO ABIERTAS

Estas preguntas están resueltas en concepto pero requieren decisión formal antes
de construir los SOMA-[X] y MetaPlaybooks de dominio:

**P1 — ¿Los Harnesses son archivos propios o secciones dentro de SOMA-[X]?**
Propuesta: archivos propios con prefijo `HNS-`. Razón: los Harnesses cambian con
frecuencia distinta al SOMA-[X] (los Harnesses se crean por tipo de room, el SOMA
se crea por dominio). Archivos separados permiten versionarlos independientemente.

**P2 — ¿Cómo se carga el Harness en un room de Cowork?**
Actualmente el contexto se carga manualmente al inicio de cada room. El Harness
debería ser el primer TP que se carga en cualquier room de un dominio. Pendiente:
definir si el Harness referencia los otros SOMA components o los incluye por copia.

**P3 — ¿LoopMX y LoopPX son dominios distintos o subsets de LoopSX?**
Argumento para distintos: tienen orbit states y métricas de Gravity completamente
distintos. Argumento para subsets: comparten el concepto de "activo en movimiento
orbital". Posición actual: distintos — el Gravity de un libro no se mide igual que
el de un prospecto.

**P4 — ¿Las alianzas (José Fernández, Papaya/MVH) van en LoopSX o en un LoopAX?**
Las alianzas son B2B-Build, no ventas directas. Su Gravity y orbit states son
distintos. Candidato: crear LoopAX (Alliance Brain) cuando las alianzas activas
superen 5. Mientras tanto: flaggear en LoopSX con `inst: B2B-Build` como está hoy.

**P5 — ¿SOMA-EL (EmpowerLabs como organización) existe o debe crearse?**
EmpowerLabs opera como su propio engagement sobre el modelo WORX. Debería tener
su SOMA-EL que define la arquitectura de cómo EmpowerLabs usa BrainX internamente.
Hoy ese contexto está disperso en varios TPs y minutas.

**P6 — ¿Cuándo un MetaPlaybook-[X] "gradúa" a canónico (XX)?**
Los MetaPlaybooks actuales son EL-level (específicos de EmpowerLabs). Cuando
un MetaPlaybook de dominio haya sido validado con 3+ clientes, puede graduarse a
XX-level (universal). El criterio de graduación debe formalizarse.

---

## 12. PRIORIDAD DE CONSTRUCCIÓN

Basado en el estado actual del ecosistema (2026-06-06), los activos más urgentes
para hacer operativa esta arquitectura son:

| Prioridad | Activo | Por qué ahora |
|---|---|---|
| 🔴 1 | `SOMA-SX-v01.md` | BrainSX ya opera (LoopX tiene 8 oportunidades). Formalizar la arquitectura del primer motor activo. |
| 🔴 2 | `MetaPlaybook-SX-v01.md` | El primer MetaPlaybook de dominio. Base para adaptar a cada cliente. |
| 🔴 3 | `HNS-EL-SX-SalesPipelineRoom-v01.md` | El Harness del room de ventas. Define qué carga cada sesión de LoopSX. |
| 🟡 4 | `SOMA-EL-v01.md` | EmpowerLabs como organización necesita su SOMA propio. |
| 🟡 5 | `XDocSX-Template-v01.md` | Template canónico de XDocSX para reemplazar el "XDoc Loop" actual. |
| 🟢 6 | `SOMA-TX-v01.md` | Para cuando Posta y Ibero estén en Lab (engagement TX activo). |
| 🟢 7 | `MetaPlaybook-TX-v01.md` | Metodología de transformación organizacional: WORX operacionalizado. |

---

## CHANGELOG

| Fecha | Versión | Cambio |
|---|---|---|
| 2026-06-06 | v01 | Documento creado. Arquitectura BrainX × SOMA completa: distinción SOMA↔MetaPlaybook, Harnesses formalizados, pila de 5 niveles, 4 dominios canónicos (SX/MX/PX/TX), gradiente de changeability, modelo de adaptación por cliente, glosario canónico, 6 preguntas de diseño abiertas, prioridad de construcción. Surge de sesión de arquitectura Victor × Jay 2026-06-06. |

---

*ARQ-EL-BrainX-SOMA-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-BMF-BigMetaFactory/*
*Generado por Jay · EmpowerLabs Brain OS · 2026-06-06*
*Documento de arquitectura — cambios requieren VoBo de Victor Heredia*
*Para construir Brain[X] nuevos → seguir Sección 5.4 · Para adaptar a cliente → Sección 8*