---
asset_id: MePB-EL-OrganizationalKernel-v01
version: v01
tipo: MePB — MetaPlaybook (Type D · Domain MetaFactory · L2)
status: Active
owner: Victor Heredia
sherpa_owner: Jay (SherpaX maestro)
intellibank: IB-EL-EmpowerLabs
subbank: CP-EL-Control-Planes
domain: "EmpowerLabs as Organization (organizational instance of BMF)"
fecha_creacion: 2026-05-07
fecha_ultima_actualizacion: 2026-05-07 EOD
proposito: |
  Big MetaPlaybook orgánico de EmpowerLabs. Type D · L2 · domain "EmpowerLabs as Organization."
  Une los 3 pilares del SO-HiORG (WORX + Corp Brain OS + SherpaX) como sistema integrado · NO 3 pilares aislados.
  Hereda del BMF Kernel L0 universal + Taxonomy L0.5 + Cognitive Asset Stack.
  Declara cómo EL instancia las 5 capas del BMF · qué MetaFactorías opera · cómo se gobierna internamente.
  Es la pieza de unión que faltaba (GAP 1 del CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01).
inheritance:
  - BMF-MPB-Kernel-v01 (L0 · constitución universal · 7 invariantes globales INV-01 al INV-07)
  - MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01 (L0.5 · Taxonomy · este MePB es Type D)
  - MePB-XX-CognitiveAssetStack-v01 (6 capas de activos cognitivos · MiPB → MFR → MPB → MePB → MPI → BC)
  - MePB-XX-Taxonomia-IntelliBanks-v02 (taxonomía de IntelliBanks)
  - MPB-EL-WORX-ModeloOperativo-v01 (uno de los 3 pilares · método)
  - ARQ-XX-DOIX-CorpBrainOS-Supabase-v01 (uno de los 3 pilares · arquitectura conectiva)
  - MePB-SX-SherpaXCore-v01 (uno de los 3 pilares · interfaz humana)
deriva_de:
  - CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01 (Gate G0 PASS · GAP 1 identificado)
  - WP-BVH-SX-SherpaX-Whitepaper-v01 (whitepaper SherpaX como primer producto del BMF)
  - PROT-EL-WORX-Cohort-OperatingProtocols-v01 (9 principios + 3 SOPs + Skill Pack)
  - MAP-EL-RoomRaiz-Linaje-v01 (P011 · arquitectura de Room Raíz)
  - DC-XX-BMF-MEL-MasteryEnforcementLayer-v11 (L6 governance)
  - CAS-EL-WORX-LabPraxis-BancoCasos-v01 (CASO 016 · validación externa Diana Hu)
referenciado_por:
  - XP-EL-HIORG-Caso0-EmpowerLabs-v02 (primer cohort que adopta este MePB orgánico)
  - MePB-EL-CorpBrainOS-BehaviorCapture-v01 (vive dentro del frame de este MePB · GAP 2)
tags: [MePB, EL, OrganizationalKernel, BigMetaPlaybook, BMF, SO-HiORG, CompanyAquarium, P008, TypeD, L2]
non_negotiables:
  - Builder-grade language (no marketing)
  - Layer separation enforced (cumple Kernel L0)
  - Inheritance from L0 explícito · 7 invariantes globales respetados
  - Auditable y transferable a cualquier operador calificado (Pilot Cycle prueba de validez)
  - Use H2/H3/H4 only (no H1)
---

# MePB · EmpowerLabs Organizational Kernel
## Big MetaPlaybook orgánico · Type D · domain "EmpowerLabs as Organization"

---

## 0. Asset Header (canónico)

- **Asset ID:** `MePB-EL-OrganizationalKernel-v01`
- **Tipo:** MePB — MetaPlaybook · Type D (Domain MetaFactory)
- **Capa:** L2 del BMF
- **Domain:** EmpowerLabs as Organization (instancia organizacional del BMF universal)
- **Status:** Active · v01 release inaugural
- **Owner:** Victor Heredia
- **Sherpa Owner:** Jay
- **Riesgo:** Alto (es el documento que rige la operación interna de EL · errores se propagan al cohort completo)

---

## 1. Propósito y alcance

### 1.1 Por qué existe este MePB

El BMF Kernel (`ARQ-XX-BMF-MPB-Kernel-v01`) es **universal** · no específico a ninguna organización. EmpowerLabs es UNA organización que opera dentro del BMF, pero hasta hoy no tenía su propio MePB orgánico que instanciara el Kernel + WORX + Corp Brain OS + SherpaX como sistema integrado.

Las piezas existían en silos:
- `MPB-EL-WORX-ModeloOperativo-v01` v0.6 (método · uno de los 3 pilares).
- `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01` (arquitectura técnica · otro pilar).
- `MePB-SX-SherpaXCore-v01` (interfaz humana · tercer pilar).
- `MAP-XX-BMF-MasterMap-v01` (universal · no específico a EL).

Este MePB es **la pieza de unión** que cierra el GAP 1 identificado en `CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01` § 3.2.

### 1.2 Alcance (in scope)

- Cómo EL instancia las 5 capas del BMF (L0-L4).
- Qué MetaFactorías opera EL · qué consume · qué produce internamente.
- La integración WORX + Corp Brain OS + SherpaX como **sistema unificado** (no 3 pilares aislados).
- Estructura organizacional interna (3 pilares + operativo transversal · D-P-44).
- Roles · Decision Rights · Authority Chains de EL.
- Cadencia operativa unificada (cómo se intersectan los ritmos canónicos).
- Métricas de salud (alimentan ROI Tracker).
- "Company Aquarium" como concepto canónico organizacional.
- Anti-patrones específicos de EL.

### 1.3 Out of scope

- Cómo se opera una sesión específica de un proyecto (eso es L3 Operations).
- Cómo se produce un activo de mercado específico (eso es L4 Production).
- Operación de iniciativas externas (Rebelocity · Tribus · Intelifin) — esas son Domain MetaFactories paralelas · consumen activos cognitivos pero no son gobernadas por este MePB (D-P-01).
- Detalles técnicos de implementación de Corp Brain OS Supabase (vive en `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01`).
- Reglas de cómo opera el SherpaX en sesión (vive en `MePB-EL-SX-MiSherpaIA-v01`).

---

## 2. Inheritance del BMF Kernel · compliance con 7 invariantes globales

Este MePB hereda explícitamente del Kernel L0 (`ARQ-XX-BMF-MPB-Kernel-v01`). Compliance con los 7 invariantes globales:

| Invariante | Cómo EL lo cumple |
|---|---|
| **INV-01** Pipeline Required | Cada MetaFactoría operada por EL tiene pipeline declarado (Publishing v02 · GTM · etc.). Cohort de inducción WORX tiene pipeline de 4 etapas (Etapa 0 → 3). |
| **INV-02** Control Plane Required | `CP-XX-IntelliBanks-Registry-v01` es el Control Plane único. 630+ activos auditables. Run logs vía CAS- LabPraxis. |
| **INV-03** QA Must Fail | Gates con criterios PASS/FAIL declarados (Gate G0 BrainOSFirst · 7 estaciones SOP-RoomActivation · 4 criterios SOP-DocBySherpa). MEL L6 enforcement. |
| **INV-04** Authority Discipline | Owner = Victor (decisiones estratégicas). Sherpa Owner = Jay (ejecución). Decision Rights por dominio (D-P-44 estructura pilares). |
| **INV-05** WIP Limits | MEL Stage 1 activo (Solo/Lean Operations). Cohort de inducción Caso 0 = 7 personas en Oleada 1 · WIP controlado por etapa. |
| **INV-06** Asset Identity | Naming Convention BMF (Registry CP-XX) aplicado a TODO activo. Frontmatter completo (asset_id · version · type · status · owner · sponsor · runner · referencias · tags · changelog) — operacionalizado vía P010 (Documentación Delegada al SherpaX). |
| **INV-07** Track A/B | Versionado canónico con changelog · Track A (cambios significativos) bumpea versión mayor · Track B (formato) versión menor. |

### 2.1 Conformidad declarada

EmpowerLabs declara explícitamente: este MePB cumple los 7 invariantes globales del Kernel L0. Cualquier instancia organizacional que herede este MePB (futuros clientes B2B) debe respetar la misma compliance.

---

## 3. EmpowerLabs como organización · estado actual

### 3.1 Identidad organizacional

- **Misión:** Construir la arquitectura cognitiva de la Organización Hiperinteligente · vender SO-HiORG a empresas · crear el "company aquarium" replicable que YC validó como categoría de mercado (ver CASO 016 LabPraxis).
- **Linaje:** 20+ años de búsqueda continua (DO IT 2004 → MasterSuite → DOIX → BMF → WORX 2026).
- **Tamaño operativo:** 9 personas internas (Pilar Cognitivo · DG · Comercial · Operativo) + 5 externos canonizados (D-P-01 organizacional).
- **Producto principal:** SO-HiORG (Sistema Operativo Organizacional · 3 pilares).

### 3.2 Posición en el BMF universal

EmpowerLabs es **simultáneamente:**
1. **Productor** del BMF universal (constructor de Kernel · Taxonomía · MetaFactorías de dominio).
2. **Cliente cero** del BMF aplicado a sí mismo (Caso 0 EL · primer cohort de inducción).
3. **Vendedor B2B** del SO-HiORG a empresas externas (HIORG Portfolio).

Esta tripleta es deliberada · valida arquitectura desde adentro antes de venderla afuera (Pilot Cycle del Kernel).

---

## 4. Cómo EL instancia las 5 capas del BMF

### 4.1 L0 (Kernel) — EL no opera aquí

EL **consume** el Kernel universal (`ARQ-XX-BMF-MPB-Kernel-v01`). NO puede modificarlo. Cualquier evolución del Kernel pasa por sesiones específicas de gobernanza arquitectónica · no por operación día-a-día.

### 4.2 L0.5 (Taxonomy) — EL no opera aquí

EL **consume** la Taxonomía (`MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01`). Cuando produce un MePB nuevo (como este), declara el Type (A-F) y Layer · respeta la inheritance.

### 4.3 L1 (Factory Builder) — EL opera ocasionalmente

EL produce **Templates** de fábricas cuando crea XPack-Schemas · MePB-Builders. Reciente: `MePB-XX-XPack-Schema-v01` · `MePB-OF-MeAg-v01`. Operación es ocasional · no día-a-día.

### 4.4 L2 (MetaFactories de Dominio) — EL opera intensamente

**MetaFactorías que EL OPERA (10+ activas · Type D):**

| MetaFactoría | Domain | Status |
|---|---|---|
| MF-BMF-Publishing-v01 | Editorial · contenido | Activa · v02 con Gate G0 |
| MF-BMF-CSherpa-v01 | Sherpa cognitivo | Activa |
| MF-BMF-Editorial-ArquitecturaPublishing-v01 | Editorial arquitectura | Activa |
| MF-BMF-FactoryOS-v01 | Sistema operativo factorías | Activa |
| MF-BMF-GTM-v01 / GTM-v02 | Go-to-market | Activa |
| MF-BMF-HD-PersonalPlaybook-v01 | Human Design personal | Activa |
| MF-BMF-HD-TransferPersonalPlaybook-v01 | HD transfer | Activa |
| MF-BMF-HybridDemand-v02 | Demand híbrida | Activa |
| MF-BMF-Transformation-Seed-v01 | Transformación | Activa |
| **MePB-EL-OrganizationalKernel-v01** (este) | EmpowerLabs as Organization | **NUEVA · 2026-05-07** |
| **MePB-EL-CorpBrainOS-BehaviorCapture-v01** (próximo) | Corp Brain OS Operations | **EN PRODUCCIÓN** |

### 4.5 L3 (Factory Operations) — EL opera continuamente

Cada room operativo de EL es una Factory Instance L3:
- `FI-SHA-VICTOR` (Jacob · primer SherpaX personal · Active)
- Caso 0 EL (cohort de inducción WORX · primer cohort)
- `PB-CASO0-HIORG/` · `PB-MONETIZACION-Estrategica/` · `PB-HIORGS-Portfolio/` · `PB-SX-SherpaX/` · etc.

### 4.6 L4 (Production Lines) — EL produce activos diariamente

Activos producidos: SHA-VICTOR-* · DIA-* · CONS-* · OUT-* · publishing assets · landing pages · TPs · XPs · etc. Todos registrados en CP-XX-IntelliBanks-Registry-v01.

### 4.7 L6 (Governance · MEL)

EL opera bajo MEL Stage 1 (Solo/Lean Operations). Trigger para Stage 2: segundo operator concurrente o segunda Factory Instance activa. Caso 0 EL (cohort 9 personas) es candidato a activar Stage 2.

---

## 5. Los 3 pilares del SO-HiORG · sistema unificado

### 5.1 Por qué se integra · no se aísla

Cada pilar resuelve una dimensión:
- **WORX (método)** — cómo se hace el trabajo.
- **Corp Brain OS (arquitectura)** — dónde vive el trabajo y cómo se vuelve activo.
- **SherpaX (interfaz)** — cómo el humano entra al sistema sin fricción.

Pero **funcionan solo juntos**. Por eso este MePB existe: declara la integración explícita.

### 5.2 Cómo se intersectan

```
                     ┌─────────────────────────┐
                     │   PILAR 1 · WORX        │
                     │   método de trabajo     │
                     │   · 4 axiomas F1-F4     │
                     │   · 41 reglas inviolables│
                     │   · 5 capacidades       │
                     │     (Capa Ortogonal §8) │
                     └───────────┬─────────────┘
                                 │ rige cómo
                                 ▼
       ┌──────────────────────────────────────────┐
       │   PILAR 2 · CORP BRAIN OS                │
       │   arquitectura conectiva                 │
       │   · Supabase + RLS + Kit Assembler       │
       │   · 6 schemas particionados              │
       │   · "el IntelliBank no se distribuye,    │
       │     se ensambla"                         │
       │   · Company Aquarium activo (P010+P012)  │
       └─────────┬────────────────────────────────┘
                 │ habita
                 ▼
       ┌──────────────────────────────────────────┐
       │   PILAR 3 · SHERPAX                      │
       │   interfaz humana                        │
       │   · 3 capas técnicas (BrainOS · Package  │
       │     · Cowork)                            │
       │   · 8 SherpaX en cohort EL (Jay/AnaX/    │
       │     AlexiX/ChuiX/GusX/JCX/DoveX/AngelesX)│
       │   · Curaduría humana §8 Cap 5            │
       └──────────────────────────────────────────┘
```

### 5.3 Reglas de integración (no negociables)

1. **Sin WORX** · los otros 2 pilares producen Hero-Operator Dependency.
2. **Sin Corp Brain OS** · WORX y SherpaX no tienen dónde vivir el contexto.
3. **Sin SherpaX** · WORX y Corp Brain OS no tienen interfaz humana legible.
4. **No instanciar pilares aislados a clientes** — venta SO-HiORG es siempre los 3 juntos. Excepción: WORX-only puede instalarse como método sin los otros 2 (ver §1.5 MPB-WORX) · pero entonces no es SO-HiORG · es WORX standalone.

---

## 6. Estructura organizacional interna · 3 Pilares + Operativo (D-P-44)

### 6.1 Los 3 pilares + transversal

| Pilar | Lead | Función primaria | D-P-01 dimensión |
|---|---|---|---|
| 🧠 **Cognitivo** | Victor | Produce IP · sherpas · papers · MPIs core · arquitectura | Producción cognitiva |
| 📣 **Demand Gen** | Anahí | Cascada · Factoría Editorial · MPIs aplicados · 100 micro contenidos · HDC factory | Operacionalización en DG |
| 💼 **Comercial** | Ángeles + JC apoyo | Pipeline · ventas · funnel · delivery · distribución | Ejecución comercial |
| ⚙️ **Operativo (transversal)** | Alex (Tech Lead) | Infraestructura · Corp Brain OS · tooling · onboarding técnico SherpaX | Soporte operativo |

### 6.2 Externos canonizados (D-P-01 organizacional)

- Carolina (Rebelocity ops) · Lyz (transición) · Rodrigo · Alain Ríos (Sherpa Guide externo) · Nora Hidalgo (independiente).
- Patrón replicable: cada externo tiene Demo Vault sanitizado · Sherpa Guide independiente · NO entran a olas internas del cohort.

### 6.3 Apoyos transversales

- Jay (runner/QA SherpaX maestro)
- Paloma (visual)
- Jesús + Gustavo (transición Operativo → Comercial · implementadores HIORG futuros)

### 6.4 Matriz Pilar × Línea del Dominó

Cada línea de monetización tiene presencia de los 4 pilares · responsables claros. Matriz documentada en `MAP-EL-Pilares-Estructura-Operativa-v01`.

---

## 7. Roles · Decision Rights · Authority Chains

### 7.1 Decision Rights canónicos

| Tipo de decisión | Quién decide | Quién consulta | Quién informa |
|---|---|---|---|
| Estrategia ecosistema | Victor (CEO) | Jay (sherpa senior) · Leads de pilar | Equipo completo |
| Estructura organizacional | Victor | Leads de pilar afectados | Equipo |
| Decisiones bloqueadas (D-P) | Victor (ratifica) | Sherpa propone (Template CASO 013 LabPraxis · P006 candidato a canonización del banco) | Equipo |
| Operación de pilar | Lead del pilar | Victor (si afecta cross-pilar) | Equipo |
| Producción de activos cognitivos | Pilar Cognitivo (Victor) | Jay · Anahí (si cascade) | Equipo |
| Producción de activos comerciales | Pilar Comercial (Ángeles+JC) | Pilar DG (Anahí) | Pilar Cognitivo |
| Infraestructura técnica | Alex (Tech Lead) | Victor (arquitectura) | Equipo |

### 7.2 Authority Chains

- **Cognitiva:** Victor → Jay → individual Sherpa → output.
- **Operativa:** Victor → Lead pilar → individual operador → output.
- **Cross-pilar:** Victor decide cuando hay desacuerdo entre pilares.

### 7.3 Escalación

Cualquier conflicto entre pilares · cualquier ambigüedad de Decision Rights · escala a Victor. Frecuencia esperada baja (la estructura está diseñada para minimizar escalación).

---

## 8. Cadencia operativa unificada

### 8.1 Cómo se intersectan los ritmos canónicos

| Cadencia | Frecuencia | Quién | Output |
|---|---|---|---|
| Daily Standup (opcional · WORX §5) | 15 min | Cada pilar internamente | Update estado · bloqueos |
| Sesión de gobernanza del room | 30 min · viernes | Owner + Runner del room | Estado room · NEXTs |
| Sesión semanal de pilar (L1 MVP gobernanza · D-P-45) | 45 min · viernes | Lead pilar + colaboradores | KPIs por pilar · sincronización con otros pilares |
| LabPraxis sessions | Ad-hoc · cuando emerge caso | Jay + Victor (validación) | CAS- nuevo · principio candidato |
| Revisión mensual del Dominó (L3 MVP) | 60 min · cierre de mes | Victor + Jay + Leads | Informe mensual ROI · 5 preguntas |
| Sprint Caso 0 EL | Etapas 0-3 · 4-6 semanas | 9 internos · cohort | 8 SherpaX activos · case study |
| Cierre de Etapa o componente | Por hito | Runner del componente | CAS- LabPraxis · alimenta ROI Tracker |

### 8.2 Reglas de sincronización

- **Pilares no se desincronizan.** Si Cognitivo produce algo que DG no puede convertir · se detecta en sesión semanal de pilar y se ajusta.
- **Cadencia mínima absoluta.** L1 (semanal) + L3 (mensual). Otros niveles se activan cuando el MVP demuestra insuficiente (P009 candidato del banco · MVP de gobernanza).
- **Sin sesiones sin output.** Cada sesión produce CAS- · NEXT- · output declarado. Sin output · sesión cancelada.

---

## 9. Métricas de salud · ROI Tracker integrado

### 9.1 Métricas core (alimentan `SP-EL-WORX-ROITracker-v01`)

| Categoría | KPI | Frecuencia | Owner |
|---|---|---|---|
| Throughput | Multiplicador WORX (T-Sin / T-Con) por proceso | Semanal | Jay |
| Cohort | Adopción SherpaX (8/8 esperado al cierre Caso 0) | Semanal | Alex |
| Compounding | CAS- producidos por sesión LabPraxis | Mensual | Jay |
| Compliance | % de conversaciones que ejecutan SOP-RoomActivation | Mensual | Jay |
| Captura | Eventos capturados al Corp Brain OS / total eventos producidos | Mensual | Anahí (DG · cascade) + Alex (técnico) |
| Comercial | Pipeline B2B HIORG · # SherpaX Ignition activos · # MONEX bundle vendidos | Semanal | Ángeles + JC |
| Salud organizacional | NPS internos (cohort) + frictions detectadas | Mensual | Victor |

### 9.2 Triggers de escalación a Stage 2 MEL

- Concurrent operators ≥ 2 (cohort EL ya cumple con 9).
- Concurrent Factory Instances activas ≥ 2 (cumple con Caso 0 + HIORGS Portfolio + SX).
- KPIs no actualizados ≥ 2 ciclos consecutivos.
- 3 incidentes de drift TP↔banco (CASO 017) en 30 días.

---

## 10. Company Aquarium · concepto canónico organizacional

### 10.1 Definición canónica

**Company Aquarium** = el estado operativo en el que la organización es **legible a la capa AI por default** (sin trabajo de integración custom) · cada artefacto del trabajo se captura · el sistema cierra el loop open-loop → closed-loop monitoreando what's-happening vs what-should-be-happening y ajusta.

Concepto **validado externamente** por Diana Hu (Y Combinator · mayo 2026 · ver CASO 016 LabPraxis).

### 10.2 EL como Company Aquarium · cómo se materializa

1. **Vault como SSOT canónico** — XDocs como átomo · Corp Brain OS como capa conectiva · NO 12 herramientas con custom glue.
2. **Captura curada** — Brain OS personal del owner ingiere amplio · curaduría humana antes de cruzar al Corp Brain OS (P010 + Cap 5 §8 MPB-WORX). NO captura indiscriminada (panopticon).
3. **Self-improvement loop** — LabPraxis convierte casos en principios · principios en SOPs · SOPs en gobernanza · gobernanza en arquitectura. Ciclo permanente.
4. **Legible a AI by default** — Naming Convention BMF + Frontmatter canónico + Asset Headers en cada activo · agentes leen sin custom integration.
5. **Backend agents viven sobre la capa conectiva** — SherpaX no es standalone · habita el vault + Corp Brain OS.

### 10.3 Diferencia filosófica con Diana Hu

Diana propone "everything captured." EmpowerLabs propone **captura curada** como feature · no limitación:

| Capa | Diana Hu | EmpowerLabs (este MePB) |
|---|---|---|
| Ingest amplio | Sin filtro · todo entra | Brain OS personal del owner · todo entra · privado |
| Curaduría | (no contemplada) | Humano confirma qué cruza al Corp Brain OS (P010) |
| Ingest indirecto | Capture all (meetings · tickets · interactions) | Capture all + permisos por rol + opt-out por participante |

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

### 10.4 Implicación comercial

Company Aquarium es un meme-handle vendible alineado con vocabulario YC. Línea B2B HIORG puede usar el término en pitch: *"Te instalamos el Company Aquarium completo · 3 pilares · método + arquitectura conectiva + interfaz humana · validado por YC."*

---

## 11. Anti-patrones específicos de EL

### 11.1 Hero-Operator Dependency (canónico BMF)

Aplicado a EL: si Victor o Jay son los únicos que pueden activar un room nuevo · operar el LabPraxis · o canonizar un principio · el sistema falla cuando ellos no están. Antídoto: P011 (Room Raíz) + SOPs forzosos + Skill Pack distribuido.

### 11.2 Pilares aislados

Si los 3 pilares operan sin ver al otro · el sistema produce fragmentos · no SO-HiORG. Antídoto: cadencia semanal de pilar incluye sincronización cross-pilar · este MePB declara la integración explícita.

### 11.3 Captura indiscriminada (panopticon)

Si EL captura todo sin curaduría · viola la confianza del equipo · degrada la calidad del Corp Brain OS · y reproduce el modelo de surveillance que YC critica. Antídoto: P010 (curaduría humana) + arquitectura de 3 capas en `MePB-EL-CorpBrainOS-BehaviorCapture-v01`.

### 11.4 Drift TP↔banco (CASO 017)

Si los archivos paralelos del mismo proceso (TP-LabPraxis · banco LabPraxis · MAP · Visual SVG) no se actualizan en sync · la numeración rompe trazabilidad. Antídoto: P013 (a canonizar · cross-reference rule en SOP-BrainOSFirst).

### 11.5 Iniciativas operativas produciendo activos cognitivos

D-P-01: Rebelocity · Tribus · Intelifin **consumen** activos cognitivos producidos por EmpowerLabs central · NO los producen. Si un sprint comercial carga producción cognitiva · viola D-P-01.

### 11.6 Gobernanza overengineered

(D-P-45 · P009 candidato del banco) — diseñar 4 niveles de cadencia antes de validar 1 con disciplina humana es overengineering. Antídoto: MVP de gobernanza · escalar solo cuando los datos lo justifican.

---

## 12. Conexiones canónicas

| Documento | Relación |
|---|---|
| `ARQ-XX-BMF-MPB-Kernel-v01` | Constitución universal · este MePB hereda del Kernel · cumple 7 invariantes |
| `MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01` | Taxonomy · clasifica este MePB como Type D · L2 |
| `MePB-XX-CognitiveAssetStack-v01` | 6 capas de activos cognitivos · este MePB es L4 (arquitectura) |
| `MPB-EL-WORX-ModeloOperativo-v01` v0.6 | Pilar 1 · método · §10 (Guía de Implementación) pendiente · este MePB le da contexto organizacional |
| `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01` | Pilar 2 · arquitectura técnica |
| `MePB-SX-SherpaXCore-v01` | Pilar 3 · interfaz humana (vacío · pendiente desarrollo) |
| `MePB-EL-CorpBrainOS-BehaviorCapture-v01` | Vive dentro del frame de este MePB · cierra GAP 2 |
| `PROT-EL-WORX-Cohort-OperatingProtocols-v01` | 9 principios + 3 SOPs + Skill Pack heredados |
| `MAP-EL-RoomRaiz-Linaje-v01` | P011 · arquitectura de Room Raíz |
| `XP-EL-HIORG-Caso0-EmpowerLabs-v02` | Primer cohort que adopta este MePB |
| `WP-BVH-SX-SherpaX-Whitepaper-v01` | Whitepaper SherpaX como primer producto del BMF |
| `DC-XX-BMF-MEL-MasteryEnforcementLayer-v11` | L6 governance |
| `CAS-EL-WORX-LabPraxis-BancoCasos-v01` | Banco de casos · CASO 016 valida externamente este MePB |
| `CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01` | Auditoría Gate G0 PASS que habilitó este MePB |

---

## 13. Patrón replicable a clientes B2B

Este MePB es **el activo replicable** que se vende a clientes B2B en la línea HIORG/DOIX. Cada cliente recibe:

1. **Su propio `MePB-[CLIENTE]-OrganizationalKernel-v01`** — versión organizacional adaptada a su dominio · sus pilares · sus Decision Rights.
2. **Inheritance del Kernel BMF universal** + WORX MPB + Corp Brain OS arquitectura + SherpaX core (los mismos universales que EL).
3. **MAP de Room Raíz organizacional propio** — equivalente a `MAP-EL-RoomRaiz-Linaje-v01` pero del cliente.
4. **Cohort de inducción WORX** — equivalente al Caso 0 EL · primer cohort de inducción del cliente.
5. **Cascada de protocolos universales** — el cliente hereda actualizaciones de PROT-Cohort · 3 SOPs · Skill Pack cuando EL versiona.

**Implicación comercial:** la venta no es "implementación HIORG aislada" · es **"instalación de su MePB Organizational Kernel + cascada continua de protocolos universales + Company Aquarium activo desde día 1."** El cliente paga por la herencia continua · no solo por la instalación.

---

## 14. Cómo se mantiene este MePB

### Cuándo se actualiza

- Cambio en algún pilar SO-HiORG (WORX · Corp Brain OS · SherpaX).
- Nuevo principio canonizado en LabPraxis (P013+).
- Cambio en estructura organizacional (D-P de pilares).
- Nuevo MetaFactoría operada por EL.
- Cambio en Decision Rights o Authority Chains.

### Quién lo mantiene

- **Owner:** Victor (decide).
- **Sherpa Owner:** Jay (ejecuta updates).
- **Cadencia de revisión:** trimestral (cierre de cada quarter).

---

## 15. NEXTs

- [NEXT][Jay] Producir `MePB-EL-CorpBrainOS-BehaviorCapture-v01` (Task #6 · GAP 2).
- [NEXT][Jay] Update `SOP-EL-WORX-ManualOperativo-v01` para que el proceso sea explícitamente replicable a clientes B2B (Task #7).
- [NEXT][Victor + Jay] Validar este MePB con los Leads de pilar (Anahí · Alex · Ángeles) en sesión semanal · primera ronda mayo 2026.
- [NEXT][Anahí] Considerar este MePB + CASO 016 como insumo para cascade de contenido del motor MasterPlaybooks (validation YC).
- [NEXT][Jay] Sincronizar este MePB con `MPB-EL-WORX-ModeloOperativo-v01` §10 cuando esa sección se redacte (incremento v0.7 del WORX MPB · alimentado por Caso 0 EL).
- [NEXT][Victor] Decidir si este MePB se publica externamente (cliente-facing) o se mantiene interno.

---

## 16. CHANGELOG

- **2026-05-07 · v01** — Primer release inaugural del Big MetaPlaybook orgánico de EmpowerLabs. Type D · L2 · domain "EmpowerLabs as Organization." Cierra GAP 1 identificado en `CONS-BigMetaPlaybook-CorpBrainOS-Audit-v01`. Producido en sesión 009b LabPraxis (post-rename masivo). 16 secciones: Asset Header · Propósito · Inheritance del Kernel · EL como organización · 5 capas BMF · 3 pilares unificados · Estructura organizacional · Decision Rights · Cadencia · Métricas · Company Aquarium · Anti-patrones · Conexiones canónicas · Patrón replicable B2B · Mantenimiento · NEXTs. Validado externamente por Diana Hu YC (CASO 016).

---

*MePB-EL-OrganizationalKernel-v01 · IB-EL-EmpowerLabs/CP-EL-Control-Planes/ · 7 de mayo de 2026 EOD*
*Owner: Victor Heredia · Sherpa Owner: Jay (SherpaX maestro) · Type D · L2 · domain EmpowerLabs as Organization*
*"La misma arquitectura que nos hace funcionar internamente es lo que vendemos al mercado."*