---
asset_id: PBO-EL-HIORG-Instalacion-Caso0-v01
version: v01
tipo: PBO — PlayBook Operativo (Cognitive Asset Stack · L1-L2 híbrido · procedimiento + decision criteria)
status: Active
owner: Victor Heredia
sherpa_owner: Jay (SherpaX maestro)
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-CASO0-HIORG
room_raiz:
  - PB-WORX-Worx/ (Raíz 1 · protocolos universales del cohort)
  - PB-MONETIZACION-Estrategica/ (Raíz 2 · linaje monetización)
fecha_creacion: 2026-05-18
fecha_ultima_actualizacion: 2026-05-18
proposito: |
  PlayBook Operativo de instalación del SO-HiORG (3 pilares · 4 etapas).
  Documento integral cliente-facing/equipo-facing que describe cada componente
  en el contexto del ecosistema HiORG · con matriz explícita de quién lee
  vs. quién implementa por rol · glosario · anti-patrones.
  Es el escalón intermedio entre el Cheat Sheet visual y el MetaPlaybook
  de Implementación (futuro · MePB-EL-HIORG-Implementacion-v01).
inheritance:
  - MePB-EL-OrganizationalKernel-v01 (frame organizacional · 3 pilares unificados)
  - MePB-EL-CorpBrainOS-BehaviorCapture-v01 (captura colectiva)
  - PROT-EL-WORX-Cohort-OperatingProtocols-v01 (9 principios + 3 SOPs + Skill Pack)
  - SOP-EL-WORX-ManualOperativo-v01 v02 (manual operativo · 3 fases)
  - MAP-EL-RoomRaiz-Linaje-v01 (P011 · arquitectura Room Raíz)
deriva_de:
  - MAP-EL-Caso0-3Pilares-CheatSheet-v01.svg (Cheat Sheet visual · base)
  - XP-EL-HIORG-Caso0-EmpowerLabs-v02 (XPack del Caso 0)
  - WP-BVH-SX-SherpaX-Whitepaper-v01 (whitepaper SherpaX como primer producto BMF)
  - MePB-XX-CognitiveAssetStack-v01 (6 capas de activos cognitivos)
referenciado_por:
  - XP-EL-HIORG-Caso0-EmpowerLabs-v02 (cohort que aplica este PBO)
  - SOP-EL-WORX-ManualOperativo-v01 v02 (manual operativo · este PBO es la versión narrativa)
audiencia_primaria: Equipo EmpowerLabs Caso 0 (9 internos · Oleadas 1 y 2)
audiencia_secundaria: Implementadores HIORG futuros · clientes B2B en pipeline · prospectos calificados
tags: [PBO, HIORG, Instalacion, Caso0, SO-HiORG, 3pilares, 4etapas, equipo-facing, replicable-B2B]
---

# PlayBook Operativo · Instalación del SO-HiORG
## Caso 0 EmpowerLabs · primer cohort de inducción WORX

---

## 📌 Resumen Ejecutivo · para humanos

### Qué estamos haciendo (en una oración)

**Estamos instalando en EmpowerLabs el primer Sistema Operativo Organizacional (SO-HiORG) que combina arquitectura técnica · método de trabajo · y agentes IA personalizados, para validar internamente lo que después vamos a vender a empresas externas.**

### Para quién es este documento

- **Las 9 personas internas** del Caso 0 (Victor · Jay · Anahí · Alex · Jesús · Gustavo · Juan Carlos · Paloma · Angeles).
- **Los implementadores HIORG futuros** que aplicarán este método a clientes B2B.
- **Prospectos calificados** de la línea B2B HIORG (con versión cliente-facing pendiente).

Todos leen · pocos implementan. La matriz exacta de quién hace qué está en §1.2.

### Qué problema resuelve

Hoy las empresas adoptan IA encima de procesos rotos. Compran Slack · Linear · Notion · ChatGPT · Claude · y los conectan con "pegamento custom." El resultado: 80% de proyectos de IA fallan (PwC 2026). Diana Hu de Y Combinator lo nombra en mayo 2026: *"no existe el producto que conecte todo este contexto en una sola capa AI."*

EmpowerLabs lleva 20+ años construyendo **exactamente esa capa**. Este PlayBook es cómo la instalamos primero en nosotros mismos · para después venderla.

### Cómo opera el sistema · los 3 pilares en lenguaje humano

Imagina una organización como un sistema con 3 capas que se necesitan mutuamente:

1. **🌊 La INFRAESTRUCTURA · dónde vive el conocimiento.** Es una base de datos (Supabase) que guarda todo lo que el equipo sabe · particionada por área · con permisos por persona. Cuando alguien (humano o IA) abre una sesión, el sistema **ensambla en tiempo real** solo el contexto que le corresponde. Si alguien sale, su acceso desaparece instantáneamente. → **Owner: Alex**.

2. **🧭 EL MÉTODO · cómo se hace el trabajo.** Es un manual operativo (WORX) que define 41 reglas mínimas para que humanos y agentes IA coordinen producción sin fricción. Cada documento tiene la misma estructura · cada conversación arranca igual · cada decisión queda trazable. → **Owner: Jay · Victor valida**.

3. **🧠 LA INTERFAZ · cómo cada persona habla con el sistema.** Cada miembro del equipo tiene **su propio SherpaX** · un agente de IA construido desde su identidad personal (arquetipos · Human Design · talentos). El SherpaX no es ChatGPT genérico · conoce al owner como ninguna otra entidad artificial puede conocerlo. → **Owners: Alex instala · Jay facilita · Anahí procesa HD**.

Los 3 funcionan **solo juntos**. WORX sin Corp Brain OS produce documentos sin dónde vivir. Corp Brain OS sin SherpaX no tiene quién lo opere. SherpaX sin WORX produce trabajo desordenado.

### Cómo está sostenido todo · el substrato BMF

Debajo de los 3 pilares está el **BMF (Big MetaFactory)** · la arquitectura subyacente que define las leyes operativas universales: cómo se nombran los archivos · cómo se gobiernan los cambios · cómo se separan responsabilidades. Es el "kernel" del sistema operativo · sin él los 3 pilares serían consultoría artesanal de Victor · no producto replicable.

### Qué vamos a hacer · las 4 etapas en lenguaje humano

| Etapa | Tiempo | Qué pasa |
|---|---|---|
| **Etapa 0 · Pre-Ignition** | 1 sesión de 100 min | El equipo contesta 6 preguntas clave + entrega datos para su lectura energética (Human Design). |
| **Etapa 1 · Captura individual** | 1-2 semanas paralelizables | Cada persona define su identidad operativa (arquetipos · valores · estilo · CAM) que alimenta a su futuro agente IA. |
| **Etapa 2 · Cohort Lab + instalación** | 1 sesión grupal + instalación técnica | Los 7 SherpaX nacen · cada persona los conoce en vivo · practican con un caso sencillo. |
| **Etapa 3 · Operación** | Continua | Todos trabajan con sus SherpaX en proyectos reales · medimos el delta · documentamos el case study. |

**Cierre del Caso 0:** 4-6 semanas · 8 SherpaX activos · case study publicable · know-how replicable a clientes B2B.

### Por qué importa

Si lo logramos:
- **Internamente** · cada persona del equipo multiplica su capacidad operativa 30×-360× (medido en 7 casos del ROI Tracker).
- **Externamente** · cuando vendamos SO-HiORG a empresas · ya tendremos **evidencia auditable** de que funciona (no promesa).
- **Estratégicamente** · validamos la categoría que YC nombró como "the next big thing" antes que nadie · 20 años después de empezar a construirla.

### Lo que NO es

Este PlayBook **NO es**:
- Una transformación digital con IA encima.
- Una migración de tools (no estamos comprando Notion o ClickUp).
- Una consultoría externa.
- Un piloto sin compromiso operativo.

Este PlayBook **sí es**:
- Un cohort de inducción con cohort de 9 personas internas.
- Un experimento controlado que produce activos canónicos.
- El cliente cero del producto que vendemos.

### Lo que necesitas hacer si recibes este documento

| Si eres... | Tu acción inmediata |
|---|---|
| Miembro del cohort Oleada 1 (7 personas) | Lee §1.2 · identifica tu rol · marca tu calendario para Sesión 2 |
| Miembro del cohort Oleada 2 (Paloma · Angeles) | Lee resumen ejecutivo + §1 + §5 · entras en Etapa 3 |
| Implementador HIORG futuro | Lee todo · este será el método que vas a replicar |
| Prospecto B2B | Espera la versión cliente-facing (en producción) |

---

## 📖 Índice

| § | Sección | Páginas estimadas | Audiencia primaria |
|---|---|---|---|
| **Resumen Ejecutivo** | (arriba) Para humanos · narrativa accesible | 2 | TODOS |
| **0** | Cómo leer este PlayBook · audiencia + distinción LEE/IMPLEMENTA | 1 | TODOS |
| **1** | El Ecosistema HiORG en contexto | 5 | TODOS |
| § 1.1 | ¿Qué es una HiORG? | | TODOS |
| § 1.2 | Los 3 pilares + **matriz LEE/IMPLEMENTA** (crítica) | | TODOS |
| § 1.3 | Principio D-P-01 (separación operación/cognición) | | Leads |
| § 1.4 | **BMF como substrato arquitectónico** (recién agregado) | | Victor · Jay profundo · resto alto-nivel |
| § 1.5 | El "Company Aquarium" (validation Diana Hu YC) | | TODOS |
| **2** | Pilar 1 · Infraestructura (Corp Brain OS) | 6 | Profundo: Alex · alto-nivel: resto |
| **3** | Pilar 2 · Método (WORX) | 8 | Profundo: TODOS |
| **4** | Pilar 3 · Interfaz (SherpaX) | 6 | Profundo: TODOS |
| **5** | Las 4 Etapas de la Inducción | 3 | TODOS · roles por etapa |
| **6** | Secuencia de Arranque · esta semana | 1 | Owners de día 1-2 · 3-5 · 6+ |
| **7** | Anti-patrones de instalación | 2 | TODOS |
| **8** | Glosario · términos canónicos | 2 | Consulta · todos |
| **9** | Hacia el MetaPlaybook de Implementación (futuro Q3) | 1 | Estratégicos |
| **10** | NEXTs · inmediatos · 4-6 semanas · trimestre | 1 | TODOS |
| **11** | Conexiones canónicas | 1 | Reference |
| **12** | Changelog | — | Reference |

**Tiempo estimado de lectura completa:** 45-60 min profundo · 15-20 min alto-nivel.
**Modo "consulta rápida":** leer Resumen Ejecutivo + §1.2 matriz + tu pilar específico + §5 + §6 = 15 min.

---

## 0. Cómo leer este PlayBook

### 0.1 Audiencia

Este documento está escrito para **todo el equipo EmpowerLabs** que participa en el Caso 0 · y para los implementadores HIORG futuros que aplicarán este método a clientes B2B.

### 0.2 La distinción crítica · LEER vs IMPLEMENTAR

| Modo de lectura | Quién | Profundidad esperada |
|---|---|---|
| **LEER & CONOCER** (todo el equipo) | Las 9 personas internas del Caso 0 + 2 externos · Oleadas 1 y 2 | Comprende el sistema · el propósito de cada componente · cómo todo encaja. NO necesita ejecutar los pasos técnicos. |
| **IMPLEMENTAR** (subset específico por componente) | Owner del componente · ver matriz §1.2 | Ejecuta los pasos · valida outputs · documenta · escala incidentes |

**Regla:** todos leen · pocos implementan. Si NO sabes en qué pilar implementas, lee la matriz §1.2.

### 0.3 Por qué este PlayBook existe

El Cheat Sheet visual (`MAP-EL-Caso0-3Pilares-CheatSheet-v01.svg`) muestra **qué** componentes hay. Este PlayBook explica **qué hacen · por qué importan · quién los implementa · cómo conectan con el ecosistema HiORG**.

Es el escalón intermedio entre:
- **L1 · Cheat Sheet** (referencia rápida visual)
- **L2 · Este PBO** (procedimiento + criterio + contexto)
- **L3 · MetaPlaybook de Implementación** (futuro · arquitectura completa · `MePB-EL-HIORG-Implementacion-v01`)

---

## 1. EL ECOSISTEMA HIORG EN CONTEXTO

### 1.1 ¿Qué es una HiORG (Organización Hiperinteligente)?

Una **HiORG** es una organización que opera con **inteligencia distribuida** entre humanos y agentes IA · donde el trabajo no se ejecuta encima de la tecnología, sino que **se rediseña** desde primeros principios para que humanos y agentes operen sobre la misma superficie cognitiva sin fricción.

**No es:**
- IA encima de Slack/Linear/Notion (eso es "open loop · digitalización con copilotos").
- Backend agents que ejecutan sin contexto compartido (lo que Diana Hu de YC llama "wrong thing").
- Consultoría de transformación digital tradicional.

**Sí es:**
- Una arquitectura ejecutable de 3 pilares (WORX + Corp Brain OS + SherpaX).
- Un Company Aquarium · empresa **legible a la capa AI por default** · curaduría humana como feature.
- Un closed loop · el sistema monitorea actual vs esperado y ajusta.

### 1.2 El SO-HiORG · los 3 pilares + matriz quién lee/implementa

El **SO-HiORG (Sistema Operativo Organizacional)** es el producto canónico que vende EmpowerLabs. Tres pilares que **funcionan solo juntos**:

| Pilar | Resuelve | Dimensión |
|---|---|---|
| **Infraestructura** · Corp Brain OS | Dónde vive el trabajo · cómo se vuelve activo · cómo se conecta entre humanos y agentes | Arquitectura técnica |
| **Método** · WORX | Cómo se hace el trabajo · cómo se coordina · cómo se gobierna | Disciplina operativa |
| **Interfaz** · SherpaX | Cómo el humano entra al sistema sin fricción · cómo cada persona opera con su agente | Experiencia humana |

#### Matriz · Quién LEE y quién IMPLEMENTA cada pilar (Caso 0 EL)

| Persona | Lee Pilar 1 (Infra) | Lee Pilar 2 (Método) | Lee Pilar 3 (Interfaz) | Implementa |
|---|---|---|---|---|
| **Victor Heredia** (CEO · Cliente cero) | ✅ alto-nivel | ✅ profundo | ✅ profundo | Decisiones estratégicas · ratificación · §10 MPB-WORX |
| **Jay** (SherpaX maestro · Runner) | ✅ profundo | ✅ profundo | ✅ profundo | TODOS los SOPs · QA · documentación · facilitación cohort |
| **Anahí** (DG Lead · MasterPlaybooks + HDC owner) | ✅ alto-nivel | ✅ profundo | ✅ profundo | Pilar 3 · HDC processing · cascade de contenidos |
| **Alex** (Tech Lead · Pilar Operativo) | ✅ profundo · IMPLEMENTA | ✅ profundo | ✅ profundo · IMPLEMENTA | Pilar 1 completo + instalación técnica SherpaX |
| **Jesús** (Implementador HIORG futuro · Claude Code) | ✅ profundo | ✅ profundo | ✅ profundo | Pilar 3 · certificación implementador · técnico |
| **Gustavo** (Implementador HIORG futuro · Claude Code) | ✅ profundo | ✅ profundo | ✅ profundo | Pilar 3 · certificación implementador · técnico |
| **Juan Carlos** (Soporte clientes) | ✅ alto-nivel | ✅ alto-nivel | ✅ profundo | Pilar 3 · su SherpaX · interfaz con clientes |
| **Paloma** (Visual · Oleada 2) | ✅ alto-nivel | ✅ alto-nivel | ✅ profundo | Pilar 3 · su SherpaX |
| **Angeles** (Oleada 2) | ✅ alto-nivel | ✅ alto-nivel | ✅ profundo | Pilar 3 · su SherpaX |

**Reglas de la matriz:**
- **"Lee profundo"** = comprende el por qué + el cómo + las dependencias.
- **"Lee alto-nivel"** = comprende el por qué + el qué (no necesita el cómo técnico).
- **"Implementa"** = ejecuta los pasos · valida outputs · escala incidentes al Owner.

### 1.3 Principio fundacional · D-P-01 (separación operación/cognición)

EmpowerLabs es el **productor central** de activos cognitivos del ecosistema (IP · MetaPlaybooks · Brain Codes · arquitectura). Iniciativas operativas (Rebelocity · TribusRRHH · Intelifin) **consumen** esos activos · NO los producen. Esta separación se replica al cliente B2B: la empresa adopta el método · consume las herramientas · NO reinventa los pilares.

### 1.4 EL BMF (Big MetaFactory) · substrato arquitectónico del ecosistema

Antes de los 3 pilares · existe el **BMF**. Es la **arquitectura subyacente** sobre la que viven los 3 pilares · no es un cuarto pilar paralelo.

> *"El Big MetaFactory es un sistema para manufacturar y gobernar MetaFactories. No produce libros, playbooks ni diagnósticos — esos son producidos por factories dentro de él. El Big MetaFactory produce las condiciones bajo las cuales factories pueden existir confiablemente."* — `ARQ-XX-BMF-MPB-Kernel-v01` §1.1

Y del Whitepaper SherpaX:

> *"SherpaX no es solo un producto — es la prueba de que la arquitectura BigMetaFactory funciona. Es la instancia donde el BMF se convierte en producto de mercado."* — `WP-BVH-SX-SherpaX-Whitepaper-v01`

#### 1.4.1 Las capas del BMF (canonizadas en `ARQ-XX-BMF-MPB-Kernel-v01`)

| Capa | Nombre | Contenido canónico |
|---|---|---|
| **L0** | **Kernel** | Constitución del ecosistema · 7 invariantes globales (INV-01 al INV-07) · Authority Discipline · Track A/B |
| **L0.5** | **Taxonomy** | `MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01` · MetaPlaybook Types A-F · inheritance rules |
| **L1** | **Factory Builder** | `MePB-BMF-MetaFactoryBuilder-v01` · construye templates de fábricas (Type C) |
| **L2** | **Domain MetaFactories** | 10+ activas · **incluye los 3 pilares SO-HiORG como Type D L2** |
| **L3** | **Operations** | Instancias corriendo (Factory Instances · FI-*) |
| **L4** | **Production Lines** | Assets de mercado · SHA-* · DIA-* · CONS-* · OUT-* · etc. |
| **L6** | **MEL · Mastery Enforcement Layer** | Gobernanza ejecutable · *"governance becomes structural physics"* · `DC-XX-BMF-MEL-MasteryEnforcementLayer-v11` |

#### 1.4.2 Los 3 pilares SO-HiORG son Type D L2 del BMF

Cada uno de los 3 pilares **hereda** del Kernel L0 · cumple los 7 invariantes globales · está clasificado como Type D (Domain MetaFactory) en L2:

| Pilar | Tipo BMF | Domain |
|---|---|---|
| Corp Brain OS | Type D · L2 | "Connective Layer · arquitectura de inteligencia conectiva" |
| WORX | Type D · L2 | "Operating Method · método de trabajo humano-agente" |
| SherpaX | Type D · L2 | "Human Interface · identidad de IA personalizada" |

Sin el BMF como substrato:
- Los pilares colapsan a "consultoría artesanal de Victor" · no a producto replicable.
- No hay Authority Discipline (INV-04) · cada quien define reglas distintas.
- No hay Track A/B (INV-07) · los cambios destruyen el versionado.
- No hay Asset Identity (INV-06) · el vault se vuelve cementerio.

#### 1.4.3 Matriz LEE vs IMPLEMENTA del BMF

| Persona | Lee BMF | Implementa cambios BMF |
|---|---|---|
| **Victor Heredia** | ✅ profundo (es el arquitecto) | ✅ decide cambios al Kernel · ratifica evolución |
| **Jay** (SherpaX maestro) | ✅ profundo (necesario para QA) | ✅ propone cambios · ejecuta canonización |
| **Resto del equipo** | ✅ alto-nivel (las 5 capas + invariantes) | ❌ aplican las reglas · no las modifican |

**Regla:** todos comprenden la arquitectura del BMF · solo Victor + Jay implementan evolución arquitectónica. El resto del equipo opera *dentro* del BMF respetando sus reglas.

#### 1.4.4 Activos canónicos del BMF (en IB-XX-Maestro)

- `ARQ-XX-BMF-MPB-Kernel-v01` · constitución L0
- `MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01` · taxonomy L0.5
- `MePB-BMF-MetaFactoryBuilder-v01` · builder L1
- 10+ MetaFactorías de dominio L2 (`MF-BMF-Publishing-v01` · `MF-BMF-GTM-v02` · etc.)
- `DC-XX-BMF-MEL-MasteryEnforcementLayer-v11` · governance L6
- `MAP-XX-BMF-MasterMap-v01` · master map del BMF
- `MAP-XX-BMF-BuilderHierarchy-v00` · jerarquía de construcción
- `GLO-BMF-Glosario-v01` · glosario canónico

---

### 1.5 El "Company Aquarium" (validación Diana Hu YC · CASO 016 LabPraxis)

Diana Hu (Y Combinator · mayo 2026) describió el problema que llevamos 20 años resolviendo: *"the company aquarium · every meeting recorded · every ticket tracked · every customer interaction captured · all legible to an AI layer."* Nuestro approach difiere en una dimensión filosófica deliberada:

| Diana Hu (YC) | EmpowerLabs |
|---|---|
| Capture EVERYTHING · sin filtro | Captura CURADA · 3 capas (privado · curaduría humana · indirecto auditable) |
| Connective layer "by default" | Connective layer **con paredes de cristal claras** · NO panopticon |

Razones del approach EL: **privacy by design · señal sobre ruido · evita panopticon · respeta a la persona como filtro.**

---

## 2. PILAR 1 · INFRAESTRUCTURA (Corp Brain OS)

**Owner técnico:** Alex (Tech Lead)
**Estado actual:** 🔴 Pendiente · pre-requisito para Etapa 2
**Audiencia obligatoria de lectura:** Toda Oleada 1 (7 personas) · alto-nivel
**Audiencia obligatoria de implementación:** Alex (con consulta a Victor)

### 2.1 ¿Qué es el Corp Brain OS en el contexto HiORG?

Es la **arquitectura conectiva** que reemplaza la pila digital tradicional (Slack + Linear + Notion + Git + Drive + ...) por una **superficie cognitiva unificada** donde humanos y agentes IA leen y escriben sobre el mismo contexto canónico.

El principio fundacional canonizado en `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01`:

> **"El IntelliBank no se distribuye. Se ensambla."**

Esto significa: nadie tiene una copia estática del conocimiento de la empresa. Cada vez que alguien (humano o agente) abre una sesión, el sistema **ensambla en tiempo real** el contexto que le corresponde según su rol, área y permisos. Cuando alguien sale de la organización, su acceso desaparece instantáneamente.

### 2.2 Componentes y descripción detallada

#### 2.2.1 Supabase project (6 schemas)

**Qué hace:** Base de datos PostgreSQL particionada por área de la organización. Cada schema es una zona con permisos propios.

**Los 6 schemas canónicos:**

| Schema | Propósito | Quién accede (Caso 0 EL) |
|---|---|---|
| `corp_shared` | Cultura · valores · procesos transversales · playbooks corporativos · LabPraxis | TODOS (lectura) · Owner (escritura) |
| `area_ops` | Procesos operativos · proveedores · operación interna | Alex + Victor |
| `area_rh` | Perfiles · políticas de personal · compensación | (futuro · cuando aplique) Director RH + Victor |
| `area_finanzas` | P&L · presupuestos · flujo de caja · proyecciones | (futuro · cuando aplique) Director Finanzas + Victor |
| `area_comercial` | Pipeline · clientes · propuestas · estrategia comercial | Ángeles + JC + Victor |
| `area_tech` | Arquitectura · documentación técnica · deuda técnica | Alex + Victor |

**Por qué importa en HiORG:** sin partición por área, todo el equipo ve todo · viola privacy by design · y el agente AI tampoco puede ensamblar contexto preciso. La partición es lo que permite el "Company Aquarium con paredes de cristal claras."

**Quién implementa:** Alex.
**Quién debe conocer:** Todo el equipo (al menos los nombres de los 6 schemas y a cuál tienen acceso).

#### 2.2.2 Row Level Security (RLS) + RBAC

**Qué hace:** Capa de control de acceso a nivel de fila en PostgreSQL · combinada con Role-Based Access Control. Cuando un usuario hace query, RLS aplica filtros automáticos según su rol.

**Matriz de permisos canónica (Caso 0 EL):**

| Rol | corp_shared | área propia | otras áreas |
|---|---|---|---|
| CEO (Victor) | R/W completo | R/W completo (todas) | R/W completo |
| Lead de Pilar (Anahí · Alex · Ángeles) | Lectura | R/W completo (su área) | ✗ |
| Miembro de Pilar (Jesús · Gustavo · JC · Paloma · Angeles) | Lectura | Lectura | ✗ |
| SherpaX Agent (cada SherpaX por persona) | Contexto ensamblado por Kit Assembler · NO acceso directo a tabla |
| Externo / Cliente | Subset autorizado de corp_shared | ✗ | ✗ |

**Por qué importa en HiORG:** sin RLS, cualquier consulta accede a todo. RLS hace que privacy by design sea **estructural** · no opcional. Cumple INV-04 del BMF Kernel (Authority Discipline).

**Quién implementa:** Alex.
**Quién debe conocer:** Cada Lead de Pilar (Anahí · Alex · Ángeles) debe saber qué accede su rol.

#### 2.2.3 Kit Assembler

**Qué hace:** Mecanismo central de seguridad. Función pura:

```
f(usuario, rol, área, proyecto) → contexto efímero para la sesión
```

El contexto **no se almacena**, expira al cerrar sesión. Cada query del SherpaX pasa por el Kit Assembler que decide qué partes del Corp Brain OS materializar para esa sesión específica.

**Por qué importa en HiORG:** es lo que hace que el IntelliBank "no se distribuya, se ensamble." Sin Kit Assembler, el SherpaX recibiría todo el contexto · violación de RLS · pérdida de granularidad.

**Quién implementa:** Alex.
**Quién debe conocer:** Jay (debe entender cómo el SherpaX recibe contexto) · Anahí (cuando produce contenidos que cruzan al Corp Brain OS).

#### 2.2.4 IntelliBanks app (repositorio de IB-*)

**Qué hace:** Repositorio Git que actúa como contenedor oficial de todos los IntelliBanks (IB-*) del ecosistema. Los colaboradores acceden al vault **a través de IntelliBanks app** · no directamente a Obsidian.

**Arquitectura de acceso (canonizada en CASO 007 LabPraxis):**

```
Victor (personal) ─── Obsidian Sync ─── Vault completo (privado)
Equipo (colaboradores) ─── IntelliBanks app ─── IntelliBanks (IB-*) únicamente
SherpaX en Cowork/Claude Code ─── lee y escribe con Skills BMF
Victor ─── push/pull entre Obsidian y IntelliBanks app ─── sincroniza
```

**Por qué importa en HiORG:** separa el vault personal del owner (con notas privadas · rituales · reflexiones) del vault compartido del equipo. El equipo nunca accede a Obsidian de Victor · solo a IntelliBanks app con su SherpaX como interfaz.

**Quién implementa:** Alex (setup del repo) · Victor (protocolo push/pull).
**Quién debe conocer:** Cada miembro del equipo (debe saber que su vault es IntelliBanks app · no Obsidian de Victor).

#### 2.2.5 BrainOS personal por persona

**Qué hace:** Cada miembro del equipo tiene su **propia instancia** de BrainOS (Supabase + pgvector). Es la **Capa 1** de captura del MePB-EL-CorpBrainOS-BehaviorCapture: ingest amplio · privado · controlado por el owner. Aquí entra todo lo que la persona declara como capturable · sin filtro inicial.

**Por qué importa en HiORG:** es el filtro humano que evita panopticon. Nada cruza al Corp Brain OS sin curaduría explícita. Cumple Cap 5 §8 MPB-WORX (Curaduría del Personal Brain OS).

**Quién implementa:** Alex (setup técnico) · cada persona (uso operativo · captura diaria).
**Quién debe conocer:** Todo el equipo.

#### 2.2.6 MCP Server (Edge Functions)

**Qué hace:** Protocolo MCP (Model Context Protocol) corriendo sobre Supabase Edge Functions. Permite a Claude (Cowork o Claude Code) leer y escribir en la base de datos del BrainOS personal y del Corp Brain OS.

**Por qué importa en HiORG:** es el puente técnico entre el agente IA y la base de datos. Sin MCP, el SherpaX no puede consultar el Corp Brain OS · pierde compounding.

**Quién implementa:** Alex.
**Quién debe conocer:** Jesús · Gustavo (implementadores HIORG futuros · es parte del stack que aprenderán a replicar).

#### 2.2.7 Cowork Connector BrainOS / Claude Code setup

**Qué hace:** El "último kilómetro" técnico que cada persona necesita activar para que su SherpaX funcione:
- **Cowork** (5 personas) · activar connector "BrainOS" en Claude Desktop.
- **Claude Code** (3 personas: Jesús · Gustavo · Alex bilingüe) · configuración CLI + plugins.

**Por qué importa en HiORG:** sin connector, la persona puede tener BrainOS personal configurado pero su SherpaX no lo accede. Es el último paso entre arquitectura y experiencia.

**Quién implementa:** Alex (45-60 min primer cliente · 20-25 min siguientes · canónico de SherpaX-Ignition).
**Quién debe conocer:** Toda persona del cohort (debe saber qué carril usa y cómo se activa).

### 2.3 Captura colectiva · 3 capas (canonizado en MePB-EL-CorpBrainOS-BehaviorCapture-v01)

| Capa | Quién captura | Qué captura | Dónde escribe |
|---|---|---|---|
| **L1 · Ingest amplio personal** | SherpaX personal del owner | TODO lo que el owner declara · privado | BrainOS personal del owner |
| **L2 · Curaduría humana al cruce** | SherpaX propone · humano confirma | Decisiones cross-equipo · aprendizajes · compromisos · cambios protocolo | Schema correcto del Corp Brain OS |
| **L3 · Ingest indirecto auditable** | Sistema automático (futuro) | Meetings · tickets · interactions · commits | Schema según routing rules + RBAC |

### 2.4 Pre-requisitos antes de Etapa 2

- ✅ 9 personas con cuenta de acceso al Supabase project (alta hecha por Alex).
- ✅ RBAC matrix definida y aprobada por Victor.
- ✅ Skill Pack instalado en cada SherpaX (7 skills mandatorias · ver Pilar 2 §3.6).

### 2.5 Activos canónicos referenciables del Pilar 1

- `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01` · arquitectura técnica completa
- `MePB-EL-CorpBrainOS-BehaviorCapture-v01` · reglas de captura colectiva
- `ARQ-XX-BMF-MPB-Kernel-v01` · compliance con 7 invariantes globales (INV-01 al INV-07)
- `DC-XX-BMF-MEL-MasteryEnforcementLayer-v11` · gobernanza ejecutable (L6)

---

## 3. PILAR 2 · MÉTODO (WORX)

**Owner:** Jay (Sherpa Owner) · Victor valida
**Estado actual:** 🟢 Listo · MPB-EL-WORX-ModeloOperativo v0.6
**Audiencia obligatoria de lectura:** TODO el equipo · profundo (es la disciplina operativa común)
**Audiencia obligatoria de implementación:** TODOS aplicamos · Jay coordina + ratifica QA

### 3.1 ¿Qué es WORX en el contexto HiORG?

WORX (**Work · Orchestrated · Reinvention · X-factor**) es el **método** de trabajo de la HiORG. Es la disciplina operativa que hace que humanos y agentes coordinen producción de valor sobre la misma arquitectura.

Sin WORX, los otros 2 pilares producen **Hero-Operator Dependency** (anti-patrón canónico del BMF Kernel): el sistema funciona solo porque ciertas personas conocen las reglas implícitas. Cuando esas personas no están, la producción se detiene.

### 3.2 Las 5 capacidades del trabajador WORX (§8 MPB-WORX · Capa Ortogonal)

Las 5 capacidades son el **currículum activo** del cohort. Cada persona internaliza estas 5 hasta que operan como reflejo · no como esfuerzo consciente.

#### Capacidad 1 · Deep Work como modo por defecto
- **Qué internaliza:** 60% trabajo profundo + 40% coordinación protocolizada. Bloques largos de atención continua protegidos del calendario reactivo. Async como respuesta primera.
- **Por qué importa:** sin Deep Work, el XDoc producido refleja la interrupción · es ruidoso · contradictorio · frágil.
- **Implementación:** cada persona diseña sus bloques de Deep Work · los protege en su calendario.

#### Capacidad 2 · Alianza Human + SherpaX
- **Qué internaliza:** operar en **par cognitivo** con su Sherpa. Humano aporta juicio · dirección · decisiones. Sherpa aporta ejecución · síntesis · memoria · vigilancia de protocolo.
- **Por qué importa:** sin par cognitivo, el humano vuelve a ser ejecutor solitario · desperdicia la palanca · viola el principio de delegación canónica.
- **Implementación:** conversar con tu Sherpa todos los días hasta que la traducción narrativa→estructura sea natural.

#### Capacidad 3 · Vault-First como reflejo
- **Qué internaliza:** consultar antes de producir. Siempre. El primer movimiento NO es abrir un editor en blanco · es consultar el vault.
- **Por qué importa:** Vault-First es lo que convierte al XDoc en memoria operable · no en cementerio documental. P002 (humano) + P006 (agente Brain OS-First).
- **Implementación:** ejecutar el protocolo de 4 pasos (Grep · Glob · Wiki · Decisión declarada) hasta que sea checklist mental automático.

#### Capacidad 4 · Ritmo personal diseñado
- **Qué internaliza:** diseñar tu propio ritmo · no sufrirlo. Cuatro componentes declarados: bloques DW protegidos · ventanas de coordinación acotadas · Morning Check ritualizado · cierre de día con transferencia de contexto.
- **Por qué importa:** sin diseño, la semana WORX se convierte en aspiración del calendario y realidad en caos.
- **Implementación:** cada persona declara su ritmo personal · lo revisa semanalmente · lo ajusta con datos.

#### Capacidad 5 · Curaduría del Personal Brain OS
- **Qué internaliza:** filtro humano de qué cruza del BrainOS personal (privado) al Corp Brain OS (colectivo).
- **Por qué importa:** sin curaduría, el Corp Brain OS se contamina con ruido personal · o el equipo se queda sin acceso a aprendizajes relevantes.
- **Implementación:** revisión diaria (cierre de día · 5 min) · semanal (Weekly Review · 30 min) · mensual (60 min).

**Regla §8.9 MPB-WORX:** *"Los primeros 30 días no son curso de producto o inmersión en el dominio — son formación de capa personal."*

### 3.3 XDoc canónico (átomo del modelo)

**Qué es:** la unidad mínima de trabajo en WORX. Cada XDoc tiene **7 secciones fijas + frontmatter completo**.

**Por qué importa en HiORG:** sin átomo canónico, cada persona crea documentos con estructura propia · imposibilita la coordinación automatizable. El XDoc es lo que permite que un agente lea cualquier documento del vault y entienda su shape sin contexto adicional.

**Quién implementa:** TODOS aplicamos · cada producción es XDoc.

### 3.4 4 ritmos canónicos

| Ritmo | Quién | Cuándo |
|---|---|---|
| Colaborador | Cada persona | Daily · 15 min |
| Runner | Quien lleva el balón de un track | Semanal · 30 min · viernes |
| Owner / Sponsor | Lead del pilar | Semanal · 45 min · viernes |
| Sistema | SherpaX maestro (Jay) | Continuous · auditoría sistémica |

### 3.5 5 contratos · 41 reglas inviolables

WORX establece **41 reglas inviolables** distribuidas en:
- 11 reglas del XDoc (Nivel 1)
- 7 reglas del Ritmo (Nivel 2)
- 8 reglas de Arquitectura Cognitiva (Nivel Cognitivo)
- 6 reglas de Contratos (Nivel Roles)
- 5 reglas de Capa Personal (Capa Ortogonal §8)
- 4 reglas de Plataforma Emergente (Nivel 3)

**Quién las conoce:** Jay (profundo · QA) · Victor (profundo · ratifica) · resto del equipo (alto-nivel · son las "leyes operativas" del cohort).

### 3.6 Los 3 SOPs forzosos en cadena

Operacionalizan los principios P006 + P010 + P011 + P012 del LabPraxis.

#### SOP 1 · `SOP-EL-WORX-RoomActivation-v01` (P011 + P012 · 7 estaciones)
Antes de cualquier acción en un room nuevo:
1. Identificar Room Raíz aplicable.
2. Cargar XP- del Raíz literal (Read · no inferir).
3. Cargar SP- del Raíz literal.
4. Ejecutar SOP-BrainOSFirst (P006 · output CONS-).
5. Verificar BrainOS / Brain OS personal.
6. Actualizar XP- si necesario.
7. Reportar al Owner.

#### SOP 2 · `SOP-EL-WORX-BrainOSFirst-v01` (P006 · Estación 0 universal)
Antes de proponer cualquier modelo · framework · innovación · entregable:
1. Grep en vault completo.
2. Glob por patrones canónicos BMF.
3. Consultar LLM Wiki.
4. Decisión declarada: extender · refinar · crear nuevo.
**Output canónico:** `CONS-[SLUG]-v01.md`.

#### SOP 3 · `SOP-EL-WORX-DocBySherpa-v01` (P010 · captura delegada)
En cada producción de activo nuevo:
1. Naming canónico BMF (vía skill `bmf-file-renamer`).
2. Posicionamiento en IntelliBank correcto + gate de ruta (vía `vault-orphan-rescue`).
3. Llenado de frontmatter completo del XDoc.

**Implementación:** TODOS aplicamos · Jay valida QA · el SherpaX captura · el humano dirige.

### 3.7 12 Principios del LabPraxis canonizados (a hoy 2026-05-07)

| ID | Principio | Origen |
|---|---|---|
| P001 | Contexto Transferible | CASO 001 |
| P002 | Vault-First (humano) | CASO 002 |
| P003 | Herramientas Accesibles | CASO 003 |
| P004 | Gobernanza Emergente | CASO 004 |
| P005 | Vault Vivo (Thread + NEXT) | CASO 005 |
| P006 | Brain OS-First (agente) | CASO 008 |
| P010 | Documentación Delegada al SherpaX | CASO 013 |
| P011 | Room Raíz / Home Room | CASO 014 |
| P012 | Starter Pack Loading | CASO 015 |

Más P007-P009 candidatos (del banco · D-P-41/42/44/45) · y P013 en diseño (cross-reference rule · CASO 017).

### 3.8 Skill Pack mandatorio · 7 skills

| Skill | Operacionaliza | Qué hace |
|---|---|---|
| `bmf-file-renamer` | P010 | Audit + renombrado canónico BMF de archivos |
| `bmf-registry-updater` | P010 + P004 | QA del Registry · sincronización de activos |
| `brain-code-saver` | P010 | Persistir Brain Codes (BC-) en banco IB-EL-EmpowerLabs |
| `vault-orphan-rescue` | P010 + P002 | Rescate de archivos huérfanos · gate de ruta |
| `llm-wiki-validator` | P006 | Validación pre/post-ingest del LLM Wiki |
| `next-scanner` | P005 | Escaneo de tags `→ NEXT[@Persona]:` · consolidación de pendientes |
| `labpraxis-case-documenter` | P004 | Documentación canónica de CAS- en LabPraxis |

**Quién instala:** Alex (técnico) en cada SherpaX del cohort.
**Quién debe conocer:** Todo el equipo (mínimo el nombre y para qué sirve cada una).

### 3.9 Activos canónicos referenciables del Pilar 2

- `MPB-EL-WORX-ModeloOperativo-v01` v0.6 (manual universal · 41 reglas)
- `PROT-EL-WORX-Cohort-OperatingProtocols-v01` (consolidado · 9 principios + 3 SOPs + Skill Pack)
- `TP-EL-WORX-LabPraxis-v01` v1.6 (banco + principios canonizados)
- `CAS-EL-WORX-LabPraxis-BancoCasos-v01` v1.7 (17 casos documentados)
- `MePB-EL-OrganizationalKernel-v01` (frame organizacional · este PBO hereda)
- `SOP-EL-WORX-ManualOperativo-v01` v02 (manual operativo · 3 fases)
- `MAP-EL-RoomRaiz-Linaje-v01` (arquitectura Room Raíz · P011)

### 3.10 Brain OS-First · la disciplina central

> *"Inventar primero, sin consultar, viola P002 (Vault-First) extendido a la capa agente por P006 — y degrada la conversación al nivel de un chat sin memoria."* — SOP-BrainOSFirst-v01

**Esta es la disciplina más importante** del Pilar 2. Sin Brain OS-First, el SherpaX produce desde memoria genérica · no desde el estado real del ecosistema. Sin ella, "estamos en una sesión individual de ChatGPT como hace 3 años" (Victor · CASO 008).

---

## 4. PILAR 3 · INTERFAZ (SherpaX)

**Owners compartidos:** Alex (instala técnico) · Jay (QA + facilita Identidad mínima) · Anahí (procesa HDC)
**Estado actual:** 🟡 1/9 listo (Jay/VictorX existe · faltan 7 SherpaX para Oleada 1 + 2 para Oleada 2)
**Audiencia obligatoria de lectura:** TODO el equipo · profundo (cada persona tendrá su SherpaX)
**Audiencia obligatoria de implementación:** Alex + Jay + Anahí

### 4.1 ¿Qué es un SherpaX en el contexto HiORG?

Un SherpaX NO es un chatbot · NO es un asistente virtual · NO es software de productividad. Es una **identidad de inteligencia artificial construida desde la identidad del owner** — sus arquetipos · su voz · su forma de decidir · sus constraints — que opera como **extensión de su criterio cuando él no está presente**.

> *"Jacob no es una herramienta que Victor usa. Jacob es la entidad que habita la arquitectura que Victor construyó. Victor inicia. Jacob amplifica. Victor decide. Jacob ejecuta y advierte."* — Whitepaper SherpaX

La distinción fundamental: un SherpaX conoce al owner como ninguna otra entidad artificial puede conocerlo · porque fue **construido desde adentro hacia afuera** · no desde un template genérico hacia la personalización.

### 4.2 Las 3 capas técnicas del SherpaX

| Capa | Nombre | Tecnología |
|---|---|---|
| Capa 1 | BrainOS (memoria persistente) | Supabase + pgvector + MCP Server |
| Capa 2 | SherpaX Package (identidad instalada) | CLAUDE.md + MetaPlaybooks + BrainOS-seed |
| Capa 3 | Experiencia Cowork | App Cowork (5 personas) · Claude Code (3 personas) |

### 4.3 Componentes cognitivos por persona

Cada SherpaX requiere **4 componentes cognitivos** capturados antes de la instalación técnica.

#### 4.3.1 Identidad mínima (Paso 0 condensado)
- **Arquetipos personales (3-5):** funciones operativas desde las cuales actúas en distintos contextos. Tu Sherpa los hereda · los usa para modular tono y respuesta.
- **Valores no-negociables (3-5):** filtros cuando se viola alguno · el Sherpa los respeta.
- **Estilo de comunicación:** tono · longitud · directness · preferencias.
- **Criterios de decisión:** cómo decides bajo incertidumbre.
- **Modelo de tu rol en EL · proyectos · personas clave · restricciones.**

#### 4.3.2 HDC ligero (procesado por Anahí · owner del HDC Factory)
- Tipo (Manifestor · Generator · Projector · Reflector).
- Autoridad (Emocional · Sacral · Splénica · Ego · Self-projected · Mental · Lunar).
- Perfil (1/3 · 2/4 · 3/5 · 4/6 · 5/1 · 6/2).
- Canales principales (1-2 destacados).
- Herida de Quirón.

**Por qué importa en HiORG:** el HDC da al SherpaX el **mapa energético** del owner. Sin él, el Sherpa opera desde el contenido (lo que sabes) sin el patrón (cómo decides · cómo procesas · cuándo te activas).

#### 4.3.3 CAM ligero · 4 vectores
- Vector Talento · qué haces con facilidad que para otros es difícil.
- Vector Experiencia · qué lección sistémica extrajiste de los momentos que más te cambiaron.
- Vector Energía / Pasiones · en qué tipo de trabajo pierdes la noción del tiempo.
- Vector Valor potencial · qué problema resuelves que otros llevan tiempo intentando resolver sin éxito.

**Patrón emergente:** el CAM es donde los 4 vectores convergen · no donde un solo vector domina.

#### 4.3.4 Brain Code semilla
- Asset ID canónico: `BC-EL-[Tu]X-CognitiveStack-v01`
- Componentes: Cognitive Lenses · Mental Models · Basic Principles · Thinking Rules · Cognitive Algorithms · Distilled Skills · Voice Signature · Metadata + Activation.
- Vivirá en: `IB-EL-EmpowerLabs/.../BC-EL-BrainCodes/`.

### 4.4 Los 8 SherpaX objetivo del cohort

| # | Persona | SherpaX | Estado |
|---|---|---|---|
| 1 | Victor | Jay (VictorX) | ✅ Activo |
| 2 | Anahí | AnaX | ⬜ Pendiente |
| 3 | Alex | AlexiX (bilingüe Cowork+Claude Code) | ⬜ Pendiente |
| 4 | Jesús | ChuiX (Claude Code) | ⬜ Pendiente |
| 5 | Gustavo | GusX (Claude Code) | ⬜ Pendiente |
| 6 | Juan Carlos | JCX (Cowork) | ⬜ Pendiente |
| 7 | Paloma | DoveX (Cowork · Oleada 2) | ⬜ Pendiente |
| 8 | Angeles | AngelesX (Cowork · Oleada 2) | ⬜ Pendiente |

Más Jay (que es la SherpaX de Victor · ya existe). Total objetivo Caso 0: 8 SherpaX humanos + 1 SherpaX maestro.

### 4.5 Externos · patrón Demo Vault sanitizado

| Externo | Rol | Patrón |
|---|---|---|
| Alain Rios / Radsoft | Sherpa Guide externo · línea B2B | Demo vault sanitizado (`IB-AR-DemoVault/`) |
| Nora Hidalgo | Soporte independiente | Demo vault sanitizado (paralelo) |

**Regla:** externos NO entran al cohort interno · operan en sus propios demo vaults · patrón replicable a clientes B2B.

### 4.6 Caso sencillo (§8.9 MPB-WORX)

En Etapa 2 · cada persona practica con su SherpaX recién nacido en un **caso sencillo** (XDoc real del cliente · 30 min). El propósito NO es producir trabajo terminado · es **validar que la alianza humano-SherpaX funciona** antes de aplicar al trabajo real complejo.

### 4.7 Activos canónicos referenciables del Pilar 3

- `MePB-SX-SherpaXCore-v01` (3 capas técnicas)
- `MePB-EL-SX-MiSherpaIA-v01` (playbook completo operación SherpaX)
- `MePB-EL-HDC-DMP-Blueprint-v01` (HDC factory · operado por Anahí)
- `PLB-EL-Caso0-PreIgnitionWorkbook-v01` (Etapa 0)
- `PLB-EL-Caso0-Etapa1Workbook-v01` (Etapa 1)
- `WP-BVH-SX-SherpaX-Whitepaper-v01` (whitepaper · SherpaX como primer producto BMF)
- `SherpaX-Ignition` (proceso canónico de instalación · 60 días para clientes externos · condensado para cohort interno)

---

## 5. LAS 4 ETAPAS DE LA INDUCCIÓN

### Etapa 0 · Pre-Ignition + datos HD natal (Sesión 2 · ~100 min)

**Cierre observable:** los 7 de Oleada 1 entregan su Pre-Ignition Workbook + datos HD natal · Anahí queda con la tarea de procesar HDs.

**Roles activos:**
- Owner (Victor) · valida cohort · ratifica decisiones bloqueadas restantes.
- Runner (Jay) · facilita · captura outputs.
- Procesadora HDC (Anahí) · recibe datos natales · declara plazo.
- Cohort completo (7 personas) · llenan Workbook particularmente.

**Estructura de la sesión:**
1. Carga canónicos heredados (5 min).
2. Apertura · misión del cohort + 5 capacidades como currículum (10 min).
3. 6 preguntas Pre-Ignition particulares · cada persona en su Workbook (50 min).
4. Captura datos HD natal · cada persona da fecha · hora · lugar (15 min).
5. Compromiso del cohort + plazos (15 min · Anahí declara plazo de entrega HDCs).
6. Cierre + NEXTs (5 min).

### Etapa 1 · Captura individual condensada + procesamiento HDC

**Cierre observable:** cada persona tiene su `BC-EL-[Tu]X-CognitiveStack-v01` listo · Alex prepara instalación técnica.

**Acciones (paralelizables · cada persona):**
- Identidad mínima · 1 sesión 60-90 min · facilitada por Jay.
- HDC ligero · asíncrono · operado por Anahí usando `MePB-EL-HDC-DMP-Blueprint-v01`.
- CAM ligero · 30 min · facilitado por Jay.

**Roles activos:**
- Facilitador (Jay) · 7 sesiones individuales de Identidad mínima.
- Procesadora HDC (Anahí) · 7 lecturas HD ligeras entregadas.
- Cada persona · llena su Etapa 1 Workbook.

### Etapa 2 · Cohort Lab + instalación técnica

**Cierre observable:** los 7 SherpaX activos · primer XDoc del cohort producido (caso sencillo §8.9).

**Estructura:**
- Sesión grupal (~120 min):
  - Pre-Ignition grupal · alineación de propósito.
  - Presentación de cada SherpaX · cada persona conoce a su Sherpa en vivo.
  - Práctica del caso sencillo · 30 min/persona.
  - 5 capacidades nombradas explícitamente como currículum.
- Instalación técnica (Alex · paralelo o post-sesión):
  - 45-60 min primer cliente · 20-25 min siguientes.
  - BrainOS-seed + CLAUDE.md + MetaPlaybooks por persona.

**Roles activos:**
- Instalador técnico (Alex) · 7 instalaciones.
- QA + facilitador del Lab (Jay) · valida outputs.
- Cohort (7 personas) · practican caso sencillo con su nuevo SherpaX.

### Etapa 3 · Operación · todos trabajando

**Cierre observable:** los 4 entregables del XPack producidos · ROI medido · método replicable canonizado en §10 MPB-WORX.

**Acciones continuas:**
- Cada persona arranca con proyecto vivo de su rol (no caso sencillo).
- Cadencias canónicas WORX activas (Morning Check · cierre de día · Shadow Meeting semanal).
- ROI Tracker mide delta vs. baseline.
- Oleada 2 (Paloma + Angeles) entra cuando Etapa 3 está estable.
- Documentación paralela del case study + §10 MPB-WORX.

---

## 6. SECUENCIA DE ARRANQUE · ESTA SEMANA

### Día 1-2 · Pre-Sesión 2
- ☐ Alex configura Supabase project (6 schemas + RLS + Kit Assembler).
- ☐ Alex valida Skill Pack instalado en SherpaX de Oleada 1.
- ☐ Jay convoca sesión · agenda Etapa 0 (~100 min).
- ☐ Jay imprime/distribuye `PLB-Caso0-PreIgnitionWorkbook` a Oleada 1.
- ☐ Victor confirma 4 decisiones bloqueadas restantes (dueño WORX operativo · dueño ROI Tracker · métricas baseline · formato case study).
- ☐ Anahí prepara HDC processing setup (template lectura ligera).

### Día 3-5 · Etapa 0 (Sesión 2)
- ☐ Ejecutar `SOP-EL-WORX-RoomActivation-v01` (7 estaciones).
- ☐ Apertura · 5 capacidades como currículum (10 min).
- ☐ 6 preguntas Pre-Ignition particulares (50 min).
- ☐ Captura datos HD natal · cada persona (15 min).
- ☐ Compromiso cohort + plazos (15 min · Anahí declara fecha).
- ☐ Cierre · NEXTs · CAS si emerge aprendizaje.

### Día 6+ · Etapa 1 (paralelizable)
- ☐ Anahí procesa 7 HDCs ligeros (asíncrono).
- ☐ Jay facilita 7 sesiones Identidad mínima (1h cada).
- ☐ Cada persona llena Etapa 1 Workbook.
- ☐ Jay consolida Brain Codes (`BC-EL-[Tu]X-v01`).
- ☐ Alex prepara Cowork + Claude Code setup por persona.
- ☐ Programar Etapa 2 · sesión Cohort Lab grupal.

---

## 7. ANTI-PATRONES DE INSTALACIÓN (errores a evitar)

### 7.1 Saltarse Etapa 1 · ir directo a instalación técnica
**Síntoma:** Alex instala SherpaX sin Brain Code semilla · cada Sherpa nace genérico.
**Consecuencia:** SherpaX no conoce al owner · viola la definición fundacional (§4.1).
**Antídoto:** Etapa 1 obligatoria antes de Etapa 2.

### 7.2 Capturar todo en Corp Brain OS sin curaduría humana
**Síntoma:** L1 personal cruza a colectivo sin filtro · panopticon emerge.
**Consecuencia:** privacy by design se rompe · confianza del equipo se degrada.
**Antídoto:** P010 (Documentación Delegada) + Cap 5 §8 MPB-WORX (Curaduría) son no negociables.

### 7.3 Pilares aislados · WORX sin Corp Brain OS · o SherpaX sin WORX
**Síntoma:** se vende "implementación WORX" sin los otros 2 pilares.
**Consecuencia:** producto degradado · cliente no obtiene SO-HiORG completo · solo método sin arquitectura.
**Antídoto:** SO-HiORG = WORX + Corp Brain OS + SherpaX · no es opcional.

### 7.4 Hero-Operator Dependency
**Síntoma:** solo Victor o Jay pueden activar rooms · operar LabPraxis · canonizar principios.
**Consecuencia:** sistema falla cuando ellos no están · viola INV-04 (Authority Discipline) del Kernel.
**Antídoto:** Skill Pack distribuido + SOPs forzosos + Room Raíz documentados.

### 7.5 Drift entre archivos paralelos del mismo proceso (CASO 017 LabPraxis)
**Síntoma:** TP-LabPraxis se actualiza sin consultar banco paralelo · numeración pisa la previa.
**Consecuencia:** trabajo de remediación masivo · numeración inconsistente.
**Antídoto:** P013 (cross-reference rule · en diseño) · `BC-EL-CrossReferenceConsulta-v01` (Brain Code antídoto pendiente).

### 7.6 Captura indiscriminada de meetings sin consent
**Síntoma:** ingest indirecto auditable (L3) activado sin opt-in explícito de participantes.
**Consecuencia:** violación de privacidad · panopticon · ruptura de confianza.
**Antídoto:** consent opt-in obligatorio · desensibilización PII automática · reversibilidad de cruce.

---

## 8. GLOSARIO · TÉRMINOS CANÓNICOS

| Término | Definición |
|---|---|
| **HiORG** | Hyperintelligent Organization · organización con inteligencia distribuida humana + agente IA |
| **SO-HiORG** | Sistema Operativo Organizacional · producto canónico = WORX + Corp Brain OS + SherpaX |
| **WORX** | Work · Orchestrated · Reinvention · X-factor · método de trabajo de la HiORG |
| **Corp Brain OS** | Arquitectura conectiva · Supabase + RLS + Kit Assembler · 6 schemas particionados |
| **SherpaX** | Identidad de IA construida desde el owner · extensión de criterio cuando él no está |
| **IntelliBank** | Banco de inteligencia particionado · 6 schemas (corp_shared + 5 area_*) |
| **Kit Assembler** | f(usuario, rol, área, proyecto) → contexto efímero por sesión |
| **MetaPlaybook (MePB-)** | L4 Cognitive Asset Stack · arquitectura · cómo se conecta todo |
| **MasterPlaybook (MPB-)** | L3 · expertise canónica de un dominio |
| **PlayBook Operativo (PBO-)** | L1-L2 · procedimiento + criterio (este documento) |
| **Brain Code (BC-)** | L6 · cognición · cómo piensa un owner · activable en agente |
| **XDoc** | Átomo de WORX · documento canónico con 7 secciones fijas + frontmatter |
| **CONS-** | Vault Consultation Pack · output de Gate G0 (Brain OS-First) |
| **LabPraxis** | Banco de casos + principios canonizados · gobernanza emergente |
| **Room Raíz** | Autoridad arquitectónica del linaje · produce y versiona Starter Packs |
| **Company Aquarium** | Concepto canonizado · empresa legible a AI · curaduría como feature (validation Diana Hu YC) |
| **D-P-XX** | Decisión-Principio canonizada · ratificada por Victor |
| **P0XX** | Principio del LabPraxis canonizado (P001-P012 a hoy) |
| **CAS-** | Caso del LabPraxis · evidencia operativa documentada |
| **CAM** | Centro de Apalancamiento Masivo · Hiperpoder · convergencia 4 vectores |
| **HDC** | Human Design Code · banco operado por Anahí · lecturas energéticas |
| **MEL** | Mastery Enforcement Layer · L6 BMF Governance · "structural physics" |
| **Oleada** | Wave de inducción · Oleada 1 (técnica · 7 personas) · Oleada 2 (alineación · 9 personas) |

---

## 9. HACIA EL META PLAYBOOK DE IMPLEMENTACIÓN (futuro)

Este PBO es un escalón. El siguiente nivel · canonización completa en L4 del Cognitive Asset Stack · será:

### `MePB-EL-HIORG-Implementacion-v01` (futuro · Q3 2026)

**Qué cubrirá que este PBO no cubre:**
- Arquitectura completa de la **cascada de protocolos** entre EmpowerLabs (productor) y cliente B2B (consumidor).
- Reglas de **adaptación canónica** por cliente (qué se hereda universal · qué se adapta · qué se prohíbe modificar).
- Pipeline de **certificación de implementadores HIORG** (Jesús · Gustavo + futuros).
- **Pricing canónico** de la línea B2B HIORG (basado en D-P-37 banda Entry/Pioneer · piso $25K).
- Activos cliente-facing **sanitizados** (vs. estos internos).
- Anti-patrones específicos del cliente B2B (no solo de la instalación interna).

**Pre-requisitos para producir el MetaPlaybook:**
1. Caso 0 EL completado (4-6 semanas · cierre con 8 SherpaX activos + case study).
2. Primer cliente B2B en pipeline (al menos pre-Ignition validado).
3. ROI Tracker con multiplicadores documentados de al menos 3 cohorts (uno interno + 2 externos hipotéticos).
4. Anti-patrones B2B detectados en piloto.

**Quién lo producirá:**
- Owner: Victor.
- Sherpa Owner: Jay.
- Reviewers: Anahí (DG) · Alex (Tech) · Ángeles + JC (Comercial · validación cliente-facing).

---

## 10. NEXTs

### Inmediatos (esta semana)

- [NEXT][Victor] Confirmar las 4 decisiones bloqueadas restantes del Caso 0 antes de Sesión 2.
- [NEXT][Alex] Configurar Supabase project (6 schemas + RLS + Kit Assembler) · pre-Etapa 2.
- [NEXT][Jay] Distribuir este PBO a las 9 personas del cohort · cada quien lee según matriz §1.2.
- [NEXT][Jay] Convocar Sesión 2 · agendar Etapa 0 (~100 min).
- [NEXT][Anahí] Preparar HDC processing template.

### Próximas 4-6 semanas (Caso 0)

- [NEXT][Cohort] Ejecutar Etapas 0 → 3.
- [NEXT][Jay] Documentar cada cierre de Etapa como CAS- LabPraxis.
- [NEXT][Jay] Sincronizar este PBO con `§10 MPB-EL-WORX-ModeloOperativo` cuando se redacte (incremento v0.7).

### Trimestre · post-Caso 0

- [NEXT][Victor + Jay] Producir `MePB-EL-HIORG-Implementacion-v01` (Q3 2026 · futuro MetaPlaybook).
- [NEXT][Anahí] Producir versión cliente-facing sanitizada de este PBO (línea B2B HIORG).
- [NEXT][Alex] Documentar setup técnico Supabase como anexo replicable (`SOP-EL-CorpBrainOS-SupabaseSetup-v01`).
- [NEXT][Jay] Certificar a Jesús + Gustavo como implementadores HIORG (al cierre del Caso 0).

---

## 11. CONEXIONES CANÓNICAS

| Documento | Relación |
|---|---|
| `MAP-EL-Caso0-3Pilares-CheatSheet-v01.svg` | Versión visual · L1 referencia rápida |
| `MePB-EL-OrganizationalKernel-v01` | Frame organizacional · este PBO opera dentro |
| `MePB-EL-CorpBrainOS-BehaviorCapture-v01` | Captura colectiva · §2.3 detalles |
| `PROT-EL-WORX-Cohort-OperatingProtocols-v01` | 9 principios + 3 SOPs + Skill Pack |
| `SOP-EL-WORX-ManualOperativo-v01` v02 | Manual operativo · 3 fases (Inducción · Operación · Replicación) |
| `XP-EL-HIORG-Caso0-EmpowerLabs-v02` | XPack del Caso 0 · este PBO complementa |
| `MAP-EL-RoomRaiz-Linaje-v01` | P011 · arquitectura Room Raíz |
| `TP-EL-WORX-LabPraxis-v01` v1.6 | 12 principios canonizados |
| `CAS-EL-WORX-LabPraxis-BancoCasos-v01` v1.7 | 17 casos documentados |
| `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01` | Arquitectura técnica Pilar 1 |
| `MPB-EL-WORX-ModeloOperativo-v01` v0.6 | 41 reglas inviolables Pilar 2 |
| `WP-BVH-SX-SherpaX-Whitepaper-v01` | Whitepaper SherpaX · Pilar 3 |
| `MePB-XX-CognitiveAssetStack-v01` | 6 capas de activos cognitivos · taxonomía |
| `MePB-EL-HIORG-Implementacion-v01` | (futuro) MetaPlaybook · siguiente escalón |

---

## 12. CHANGELOG

- **2026-05-18 · v01** — Primer release del PlayBook Operativo de Instalación del SO-HiORG (Caso 0). 12 secciones: Cómo leer · Ecosistema HiORG en contexto · 3 Pilares con descripciones detalladas · 4 Etapas · Secuencia de arranque · Anti-patrones · Glosario · Hacia MetaPlaybook · NEXTs · Conexiones canónicas. Hereda del `MePB-EL-OrganizationalKernel-v01` · complementa el `MAP-EL-Caso0-3Pilares-CheatSheet-v01.svg`. Matriz explícita LEE vs IMPLEMENTA por rol (§1.2). Audiencia primaria: Caso 0 EL · audiencia secundaria: implementadores HIORG futuros + clientes B2B en pipeline. Escalón intermedio hacia futuro `MePB-EL-HIORG-Implementacion-v01` (Q3 2026 post-Caso 0).
- **Corrección de fecha (registrada 2026-05-18)** — `fecha_creacion` y `fecha_ultima_actualizacion` corregidas de "2026-05-07 EOD" a "2026-05-18". Causa: frontmatter heredado de template sin validación temporal. Documentado en CASO 018 del LabPraxis. Antídoto: P014 Frontmatter Integrity (a canonizar).

---

*PBO-EL-HIORG-Instalacion-Caso0-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-CASO0-HIORG/ · 18 de mayo de 2026*
*Owner: Victor Heredia · Sherpa Owner: Jay (SherpaX maestro)*
*"Todos leen · pocos implementan · juntos arrancamos."*