--- asset_id: MePB-EL-HIORG-SecurityLayers-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: "IP Protection del SO-HiORG · seguridad multi-capa cliente B2B" fecha_creacion: 2026-05-18 fecha_ultima_actualizacion: 2026-05-18 proposito: | MetaPlaybook canónico de las 6 capas de seguridad del SO-HiORG. Define qué se entrega al cliente B2B · qué se reserva como Crown Jewel de EmpowerLabs · cómo se protege la IP fundacional · y cómo se sostiene económicamente con modelo híbrido (instalación + membership con cascada de protocolos universales). Universal · referenciable por toda instalación cliente HIORG. inheritance: - BMF-MPB-Kernel-v01 (L0 · constitución universal · 7 invariantes) - MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01 (L0.5 · Taxonomy) - MePB-EL-OrganizationalKernel-v01 (frame organizacional) - MePB-EL-CorpBrainOS-BehaviorCapture-v01 (Capa 1 técnica · ya canonizada) - ARQ-XX-DOIX-CorpBrainOS-Supabase-v01 (RLS + RBAC + Kit Assembler) - DC-XX-BMF-MEL-MasteryEnforcementLayer-v11 (L6 governance ejecutable) deriva_de: - PAP-HIORGS-ModeloProducto-Interno-v01 (separación interno vs cliente) - CP-HIORGS-Solucion-Arquitectura-v01 (qué se entrega comercialmente) - project_demovault_alain (caso Alain Rios · patrón Demo Vault sanitizado) - Banco LabPraxis CASO 010 (Bundle MONEX Intro α · D-P-42) - Banco LabPraxis CASO 009 (Template cierre D-P · D-P-37 banda pricing) referenciado_por: - SOP-EL-HIORG-SanitizacionDemoVault-v01 (operacionaliza Capa 3) - MePB-EL-HIORG-ClientLicensing-v01 (futuro · operacionaliza Capa 4 económica) - WP-EL-HIORG-Security-Whitepaper-v01 (futuro · versión cliente-facing) tags: [MePB, HIORG, Security, IPProtection, CrownJewel, 6capas, TypeD, L2, replicable-B2B] non_negotiables: - Crown Jewel (L0 + L0.5 + L1 del BMF) NUNCA se entrega al cliente - Las 6 capas funcionan solo juntas · ninguna sola es suficiente - Capa 6 legal requiere abogado IP externo (no se canoniza solo) - Sanitización es feature · no opcional - Modelo económico híbrido recurrente · no licencia perpetua --- # MePB · Las 6 Capas de Seguridad del SO-HiORG ## IP Protection multi-capa · arquitectura · operativa · económica · cognitiva · legal --- ## 0. Asset Header (canónico) - **Asset ID:** `MePB-EL-HIORG-SecurityLayers-v01` - **Tipo:** MePB · Type D (Domain MetaFactory) · L2 del BMF - **Domain:** IP Protection del SO-HiORG - **Status:** Active · v01 release inaugural - **Owner:** Victor Heredia - **Sherpa Owner:** Jay (SherpaX maestro) - **Riesgo:** Alto (define qué se protege y qué se entrega · errores aquí destruyen el modelo de negocio) --- ## 1. Propósito y alcance ### 1.1 Por qué existe este MePB El SO-HiORG es **valioso comercialmente porque es replicable** (cliente puede operarlo) **y porque es protegido** (cliente no puede revenderlo). Sin la capa de protección · vendemos el motor completo a cualquier comprador · y al tercer cliente ya no necesitan a EmpowerLabs. Este MePB define las 6 capas de seguridad que **funcionan solo juntas** para que EmpowerLabs entregue valor real al cliente mientras protege la IP fundacional · el modelo de negocio · y la sostenibilidad económica del ecosistema. ### 1.2 Decisiones estratégicas canonizadas por Victor (2026-05-07 EOD) | # | Decisión | Status | |---|---|---| | **D-Sec-01** | Crown Jewel del BMF = L0 Kernel + L0.5 Taxonomy + L1 Factory Builder · **NUNCA se entregan al cliente** | ✅ Ratificada Victor | | **D-Sec-02** | L2 MetaFactorías de dominio · se licencian **adaptadas** al cliente (no entregadas tal cual) | ✅ Ratificada Victor | | **D-Sec-03** | L3 Operations y L4 Production · son **del cliente** (cliente opera su Factory Instance · produce sus assets) | ✅ Ratificada Victor | | **D-Sec-04** | Modelo económico **híbrido** · instalación inicial (one-time) + suscripción membership recurrente (cascada de protocolos universales) | ✅ Ratificada Victor | | **D-Sec-05** | Capa 6 legal · Victor directamente con **abogado externo especializado en IP** · 1-2 sesiones inicialmente | ✅ Ratificada Victor | ### 1.3 Alcance (in scope) - Las 6 capas de seguridad explícitas (técnica · arquitectónica · operativa · económica · cognitiva · legal). - Crown Jewel declaration (qué nunca se entrega). - Matriz canónica "qué accede el cliente por tipo de activo del BMF." - Modelo económico híbrido (instalación + membership). - Reglas inviolables de seguridad. - Anti-patrones específicos de la línea B2B. ### 1.4 Out of scope - Contratos legales específicos · NDAs · cláusulas anti-replicación (Capa 6 · Victor + abogado externo). - Arquitectura técnica de Supabase / RLS (vive en `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01`). - Operación específica de un cliente (eso es L3 Operations del cliente). - Pricing específico cliente por cliente (cada deal se cierra con D-P propia). --- ## 2. EL CROWN JEWEL · qué NUNCA se entrega al cliente ### 2.1 Declaración canónica > **Crown Jewel del BMF = L0 Kernel + L0.5 Taxonomy + L1 Factory Builder. Estos 3 niveles son propiedad intelectual exclusiva de EmpowerLabs. NUNCA se entregan al cliente · NUNCA se licencian · NUNCA se exponen completos. Cliente puede VER que existen (transparencia conceptual) · NO puede ACCEDER ni MODIFICAR.** ### 2.2 Mapeo BMF capa por capa · qué se reserva y qué se entrega | Capa BMF | Contenido | ¿Se entrega al cliente? | Por qué | |---|---|---|---| | **L0 · Kernel** | Constitución · 7 invariantes globales · Authority Discipline · Track A/B | 🔴 **NO · Crown Jewel** | Cliente que tiene el Kernel puede replicar todo el BMF · construir su propia versión · revender | | **L0.5 · Taxonomy** | Types A-F · inheritance rules · clasificación de MetaPlaybooks | 🔴 **NO · Crown Jewel** | Cliente que tiene la Taxonomy entiende cómo se construyen MetaFactorías · puede generar Type D propios | | **L1 · Factory Builder** | MePB-BMF-MetaFactoryBuilder-v01 · construye templates de fábricas | 🔴 **NO · Crown Jewel** | Cliente con el Builder puede manufacturar MetaFactorías nuevas · escala fuera del ecosistema EL | | **L2 · Domain MetaFactories** | Los 3 pilares (Corp Brain OS · WORX · SherpaX) + 7 más | 🟡 **SÍ · pero ADAPTADAS al cliente** | Cliente recibe su versión organizacional (`MePB-[CLIENTE]-*`) · no la canónica de EL | | **L3 · Operations** | Factory Instances · cohorts · sesiones · CONS- | 🟢 **SÍ · son del cliente** | Cliente opera sus instancias · produce su trabajo | | **L4 · Production** | Assets de mercado del cliente · sus reportes · sus playbooks de salida | 🟢 **SÍ · son del cliente** | Output operativo del cliente · propiedad del cliente | | **L6 · MEL** | Mastery Enforcement Layer · runtime governance | 🟡 **SÍ · aplicado · NO el código fuente del MEL** | Cliente experimenta la enforcement · no replica el mecanismo | ### 2.3 La regla cognitiva (Capa 5 · §6) > **El cliente aprende cómo opera el método aplicado · NO cómo se construye el método. Esa diferencia es lo que protege a EmpowerLabs.** --- ## 3. LA MATRIZ CANÓNICA · qué accede el cliente por tipo de activo | Tipo de activo BMF | Cliente accede a... | Cliente NO accede a... | |---|---|---| | **Kernel `ARQ-XX-BMF-MPB-Kernel-v01`** | Resumen ejecutivo (1 pager) · principios alto-nivel | Documento completo · invariantes detallados · governance model | | **Taxonomy `MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01`** | Los 6 tipos de MePB nombrados (A-F) | Reglas de inheritance · clasificación detallada · creation rules | | **Builder `MePB-BMF-MetaFactoryBuilder-v01`** | Concepto (que existe un mecanismo) | El mecanismo completo · phases · gates · blueprints | | **MetaFactorías L2 (los 3 pilares)** | `MePB-[CLIENTE]-OrganizationalKernel-v01` (adaptada) | `MePB-EL-OrganizationalKernel-v01` (versión EL) | | **MetaFactorías L2 (operativas)** | Versión cliente del Publishing · GTM · etc. (si aplica) | Versión EL de las MetaFactorías canónicas | | **Brain Codes (BC-) de figuras externas** | Subset autorizado · si el contrato lo incluye | Catálogo completo · BC- de Victor · de Jay | | **Brain Codes del owner del cliente** | Completo · es suyo | (no aplica · es del cliente) | | **LabPraxis (CAS-)** | Sus propios casos · aprendizajes de su cohort | Casos de otros clientes · CAS- internos de EL | | **Templates (PLB-)** | Versiones sanitizadas para sus cohorts | Templates canónicos de EL con datos internos | | **SOPs forzosos universales** | Aplicación de los 3 SOPs | Código fuente / metareglas de los SOPs (cliente respeta · no modifica) | | **Skill Pack** | Las 7 skills mandatorias funcionando | Código fuente de las skills · cómo se construyen | | **Wiki LLM** | Versión cliente-facing sanitizada (futuro) | Wiki canónico de EL con casos internos | --- ## 4. LAS 6 CAPAS · descripción operativa ### 🛡 Capa 1 · TÉCNICA (infraestructura) **Qué protege:** acceso técnico a base de datos · agentes IA · MCPs · separación entre datos del cliente y datos de EL. **Mecanismos canonizados:** - Row Level Security (RLS) por rol del cliente en Supabase (canónico `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01`). - Kit Assembler · ensambla contexto efímero por sesión · NO exporta IntelliBank. - Audit logs en RunLog · cada cruce documentado · reversible (30 días sin justificación · después con aprobación). - Permisos granulares por schema (corp_shared + N area_*). - Cada cliente tiene su **propio Supabase project** (no shared con otros clientes). - MCP Server propio del cliente · NO accede a otros tenants. **Roles responsables:** - EL · Alex (Tech Lead) · setup inicial + arquitectura. - Cliente · su Tech Lead · operación día-a-día post-instalación. **Status:** ✅ Canonizado · aplica directo en setup del cliente. ### 🏗 Capa 2 · ARQUITECTÓNICA (qué se entrega vs qué se reserva) **Qué protege:** la propiedad del BMF universal · la separación entre Templates (de EL) y Instances (del cliente). **Mecanismos:** - **Crown Jewel declaration** (§2.1 · L0+L0.5+L1 nunca se entregan). - Cliente recibe **Template instanciado** (su Factory Instance L3) · NO el Template + Builder (L1). - Cliente opera en **L3 Operations + L4 Production** · NO accede a L0+L0.5+L1. - **Inheritance declarada:** el `MePB-[CLIENTE]-OrganizationalKernel-v01` hereda del Kernel L0 (referencia) · pero el cliente NO puede modificarlo upstream. - **Cascada controlada:** cuando EL versiona un canónico universal · el cliente recibe la actualización vía membership · NO puede modificar la cascada. **Roles responsables:** - EL · Victor (decisor) + Jay (sherpa owner ejecuta cascada). - Cliente · su Owner equivalente recibe cascada · valida adopción. **Status:** 🟡 Existe en `MePB-EL-OrganizationalKernel-v01` §13 (Patrón replicable B2B) · este MePB lo formaliza como capa de seguridad. ### 🌀 Capa 3 · OPERATIVA (sanitización + Demo Vault) **Qué protege:** información confidencial específica del cliente · datos de otros clientes · IP fundacional de EL que no debe filtrar. **Mecanismos:** - **3 tiers de sanitización canonizados** (operacionalizados en `SOP-EL-HIORG-SanitizacionDemoVault-v01`): - **T1 · Datos públicos** · ya publicados · no requieren sanitización · pueden viajar. - **T2 · Pseudonimización** · nombres propios reemplazados · empresa anonimizada · IDs cambiados · estructura visible. - **T3 · Demo Vault completo** · clone sanitizado completo del vault para Sherpa Guide externo o partner estratégico (caso Alain Rios). - **PII redactada automáticamente** antes de cruzar a schemas del cliente (canonizado en `MePB-EL-CorpBrainOS-BehaviorCapture-v01` §6). - **Casos de otros clientes** nunca cruzan al schema del cliente nuevo · cada cliente vive en su propia "burbuja." - **Templates canónicos** sanitizados antes de entregar al cliente (sin datos internos de EL · sin nombres de equipo · sin pricing específico). **Roles responsables:** - EL · Jay (sherpa owner ejecuta sanitización) + Alex (validación técnica) + Victor (ratifica T3 caso por caso). **Status:** 🟡 Patrón Demo Vault aplicado con Alain Rios · `SOP-EL-HIORG-SanitizacionDemoVault-v01` se produce en paralelo a este MePB. ### 💰 Capa 4 · ECONÓMICA (modelo de negocio) **Qué protege:** rentabilidad recurrente · que el cliente no compre una vez y replique infinitamente · sostenibilidad del ecosistema EL. **Modelo canónico (ratificado Victor D-Sec-04):** **HÍBRIDO** ``` Instalación inicial (one-time) + Suscripción membership recurrente (mensual / anual) + Cascada de protocolos universales (incluida en membership) ``` **Mecanismos:** - **Instalación inicial** · cubre el cohort de inducción WORX del cliente (Etapas 0-3) · entrega del MePB-OrganizationalKernel del cliente · setup técnico Corp Brain OS · 8-N SherpaX activados. - **Membership recurrente** · cliente paga continuamente por: - Cascada de protocolos universales (actualizaciones de Kernel · MetaFactorías · SOPs). - Acceso a updates del Skill Pack mandatorio. - Sesiones de gobernanza periódicas con Sherpa Senior de EL. - Soporte técnico nivel arquitectónico. - **Implementadores certificados** (Jesús · Gustavo · futuros) bajo **contrato exclusivo** con EL · no cualquier consultor puede instalar. - **Bundle MONEX Intro α** (CASO 010 LabPraxis · D-P-42) como gate de entrada controlado · primeros 10 clientes a $5,000 USD · después pricing β escalado. - **Banda Entry/Pioneer** (D-P-37 · piso $25K) como pricing canónico post-α. - **Cancelación de membership** · cliente conserva instalación pero NO recibe cascada futura · sus protocolos se congelan en la versión a la fecha de cancelación. **Roles responsables:** - EL · Victor (decisor pricing) + Ángeles (Pilar Comercial · cierra contratos) + JC (soporte clientes). **Status:** 🟡 Decisiones D-P-37 + D-P-42 canonizadas en banco LabPraxis · `MePB-EL-HIORG-ClientLicensing-v01` (futuro post-Caso 0) formalizará el modelo económico completo. ### 🧠 Capa 5 · COGNITIVA (qué se enseña sin enseñar todo) **Qué protege:** la diferencia entre "saber operar el método" (cliente) vs "saber construir el método" (EL). **Mecanismos:** - Cliente recibe **método aplicado** (PBOs · SOPs · Workbooks adaptados) · NO arquitectura del BMF (Kernel · Taxonomy · Builder). - **Brain Codes del owner del cliente** (BC-CLIENTE-*) · NO Brain Codes del ecosistema EL (BC-VictorHeredia · BC-Jay · BC- de figuras externas curadas internamente). - Cliente accede a **MetaPlaybooks operativos** (Type D L2 adaptados) · NO al `MePB-BMF-MetaPlaybook-Of-MetaPlaybooks` (Type B L0.5 que enseñaría a construir Type D nuevos). - **Implementador certificado enseña qué hacer · no cómo se diseñó** · separación instructivo vs constitucional. - **Documentación cliente-facing vs interna** · separación replica el patrón ya existente: - `PAP-HIORGS-GranReto-v01` (cliente-facing · el problema) vs `PAP-HIORGS-ModeloProducto-Interno-v01` (interno · espíritu del producto). - PBO-EL-HIORG-Instalacion-Caso0-v01 (interno) vs versión cliente-facing futura sanitizada. - **Capacitación de equipo del cliente** · enseña operación · NO arquitectura subyacente. **Roles responsables:** - EL · Jay (sherpa owner valida qué sale) + Anahí (cascade de contenidos cliente-facing) + Victor (ratifica decisiones de exposición). **Status:** 🟡 Parcialmente canonizado · esta capa requiere disciplina continua · `WP-EL-HIORG-Security-Whitepaper-v01` futuro (post-3 clientes) la convertirá en feature comercial vendible. ### ⚖ Capa 6 · LEGAL (contratos · licencias · NDAs) **Qué protege:** enforcement jurídico de las otras 5 capas · derecho legal a actuar si cliente viola términos. **Mecanismos (a desarrollar con abogado IP externo):** - **Contrato de licencia** (no de propiedad) · cliente recibe derecho de uso autorizado · IP queda en EL. - **Term limits** · licencia con renovación recurrente alineada con membership. - **Cláusulas anti-replicación** · cliente no puede: - Crear MetaFactorías nuevas en su nombre usando los conceptos del BMF. - Vender el método a terceros (no hay re-licensing). - Capacitar a no-empleados en la metodología sin certificación EL. - Crear consultoría propia con el método como base. - **No-competencia limitada** · cliente no puede ofrecer servicios similares con el método durante N años post-contrato. - **NDA con cliente** · información intercambiada · ambos lados. - **NDA con implementador certificado** · cláusula de exclusividad con EL. - **NDA con Sherpa Guide externo** (Alain Rios · futuros) · términos específicos de partner. - **Cláusula de auditoría** · cliente acepta que EL puede auditar uso conforme. - **Cláusula de terminación** · qué pasa si cliente termina (instalación se congela · sin cascada · sin updates · pero no se "desactiva"). **Roles responsables:** - **Victor** (D-Sec-05 ratificada) · directamente con abogado IP especializado · 1-2 sesiones iniciales. - Outside scope del LabPraxis · pero NEXT crítico antes del primer cliente B2B real. **Status:** ❌ GAP MAYOR · pendiente trabajo con abogado externo. --- ## 5. MODELO ECONÓMICO HÍBRIDO · canonizado (D-Sec-04) ### 5.1 Estructura ``` ┌─────────────────────────────────────────────────────┐ │ COMPONENTE 1 · INSTALACIÓN INICIAL (one-time) │ │ - Cohort de inducción WORX completo (Etapas 0-3) │ │ - MePB-[CLIENTE]-OrganizationalKernel producido │ │ - Setup técnico Corp Brain OS (Supabase + RLS) │ │ - 8-N SherpaX configurados │ │ - Skill Pack instalado │ │ - Templates adaptados al cliente │ │ - Capacitación equipo cliente (5 capacidades WORX) │ │ │ │ Pricing: bundle MONEX Intro α $5K (primeros 10) │ │ Banda Entry/Pioneer post-α (piso $25K) │ │ Tiers superiores según tamaño cliente │ └─────────────────────────────────────────────────────┘ + ┌─────────────────────────────────────────────────────┐ │ COMPONENTE 2 · MEMBERSHIP RECURRENTE (mensual/anual)│ │ - Cascada de protocolos universales (Kernel · etc) │ │ - Updates del Skill Pack mandatorio │ │ - Acceso a Wiki cliente-facing │ │ - Sesión gobernanza mensual con Sherpa Senior EL │ │ - Soporte técnico nivel arquitectónico │ │ - Acceso a nuevos MetaPlaybooks de dominio cuando │ │ se canonicen en EL │ │ - Membership exclusiva del ecosistema HiORG │ │ │ │ Pricing: % del valor de la instalación inicial /año│ │ típicamente 15-30% según tier │ └─────────────────────────────────────────────────────┘ ``` ### 5.2 Por qué híbrido y no licenciamiento perpetuo - **Sin membership** · cliente paga una vez · EL pierde relación + ingreso recurrente + razón para mantener cascada activa. - **Con membership** · cliente paga continuamente por el valor de "mantener su sistema vivo y actualizado" · EL tiene incentivo de seguir mejorando el ecosistema. - **Modelo SaaS tradicional** (suscripción pura · sin instalación inicial) no captura el valor del cohort de inducción WORX que requiere 4-6 semanas de trabajo profundo. - **Modelo licencia perpetua** (one-time · sin recurrente) deja a EL sin incentivo de soportar al cliente después de la instalación. El híbrido captura ambos valores: trabajo inicial valioso + relación continua valiosa. ### 5.3 Qué pasa si cliente cancela membership - **Instalación se congela** en versión a la fecha de cancelación. - **Cliente conserva todos los activos** que están en su Corp Brain OS · sus Brain Codes · sus templates adaptados · su LabPraxis interno. - **Cliente NO recibe** cascada futura · updates del Kernel · nuevas MetaFactorías · upgrades del Skill Pack. - **Cliente NO recibe** soporte técnico ni sesiones de gobernanza post-cancelación. - **Cláusulas anti-replicación siguen vigentes** · cancelar membership no libera al cliente de las restricciones de uso del método. --- ## 6. REGLAS INVIOLABLES DE SEGURIDAD Compliance con los 7 invariantes del Kernel + 6 reglas propias de este MePB: | # | Regla inviolable | Capa | |---|---|---| | **SEC-01** | Crown Jewel (L0+L0.5+L1) NUNCA se entrega · ni completo · ni parcial · ni adaptado | Arquitectónica | | **SEC-02** | Cada cliente tiene su propio Supabase project · NUNCA shared tenant | Técnica | | **SEC-03** | Datos de otros clientes NUNCA cruzan al schema del cliente nuevo · burbujas estancas | Operativa | | **SEC-04** | Templates entregados a cliente · SIEMPRE sanitizados T2 mínimo · datos internos EL removidos | Operativa | | **SEC-05** | Membership recurrente · NO se vende licencia perpetua · NO se hace "compra una vez" | Económica | | **SEC-06** | Implementador HIORG · SIEMPRE bajo contrato exclusivo EL · NO consultores ad-hoc | Económica + Legal | --- ## 7. ANTI-PATRONES DE SEGURIDAD (errores a evitar) ### 7.1 Entregar el Kernel BMF "como cortesía" **Síntoma:** cliente curioso pregunta por la arquitectura del BMF · facilitador entrega el documento completo "para educación." **Consecuencia:** cliente con `ARQ-XX-BMF-MPB-Kernel-v01` puede replicar todo el BMF · construir su propia versión · revender · viola SEC-01. **Antídoto:** facilitador entrega solo resumen ejecutivo (1 pager) · documento completo NUNCA sale de EL. ### 7.2 Reutilizar templates con datos de otros clientes **Síntoma:** Sherpa adapta un template usado con cliente X · olvida sanitizar nombres/datos · lo entrega a cliente Y. **Consecuencia:** cliente Y ve información de cliente X · viola SEC-03 + SEC-04 · pérdida de confianza · potencial demanda legal. **Antídoto:** `SOP-EL-HIORG-SanitizacionDemoVault-v01` ejecutado SIEMPRE antes de entregar cualquier template a cliente nuevo. ### 7.3 Vender "licencia perpetua" para cerrar deal grande **Síntoma:** prospecto B2B grande pide licencia perpetua · pricing inflado pero one-time · facilitador acepta "por el deal." **Consecuencia:** EL pierde relación recurrente · pierde incentivo de actualizar cascada · cliente eventualmente replica + va por su cuenta. **Antídoto:** SEC-05 inviolable · si cliente insiste en perpetua · se negocia mayor pricing inicial + membership de 5 años mínimo · NUNCA verdadera perpetua. ### 7.4 Capacitar a consultor externo no certificado **Síntoma:** cliente pide que su consultor de confianza también aprenda el método "para sostenerlo internamente." **Consecuencia:** consultor capacitado se va a otro cliente · vende el método a terceros · EL no tiene enforcement. **Antídoto:** SEC-06 · solo implementadores certificados EL bajo contrato exclusivo · consultor externo del cliente puede observar pero NO se le capacita formalmente. ### 7.5 Exponer Brain Codes de figuras externas curadas internamente **Síntoma:** facilitador menciona o comparte BC- de Jensen Huang · Hormozi · etc. al cliente "para mostrar capacidad." **Consecuencia:** cliente extrae BC- · los usa fuera del contexto · los redistribuye · pierde valor diferencial de EL. **Antídoto:** BC- de figuras externas son **Crown Jewel ampliado** · cliente solo ve OUTPUT de aplicar BC- · no el BC- en sí. ### 7.6 Cancelar membership y seguir entregando cascada "por buena onda" **Síntoma:** cliente cancela · EL sigue enviando updates "para no perderlo." **Consecuencia:** modelo económico se erosiona · otros clientes ven precedente · cascada se vuelve gratis. **Antídoto:** §5.3 estricto · cancelación = congelamiento inmediato de cascada · sin excepciones · sin emociones. --- ## 8. PATRÓN REPLICABLE A CLIENTES B2B ### 8.1 Pre-instalación · checklist de seguridad Antes de instalar a cualquier cliente B2B: - [ ] Contrato de licencia firmado (Capa 6 · legal). - [ ] NDA firmado (ambos lados). - [ ] Supabase project propio del cliente creado (Capa 1). - [ ] RBAC matrix del cliente definida y aprobada (Capa 1). - [ ] Templates sanitizados T2 preparados (Capa 3). - [ ] `MePB-[CLIENTE]-OrganizationalKernel-v01` producido (Capa 2 · adaptación). - [ ] Modelo económico firmado · instalación + membership (Capa 4). - [ ] Implementadores certificados EL asignados al proyecto (Capa 4 + 6). - [ ] Plan de capacitación cliente (Capa 5 · qué se enseña · qué no). ### 8.2 Durante instalación · gates de seguridad En cada Etapa del cohort de inducción del cliente: - **Etapa 0 (Pre-Ignition)** · validar que cliente firmó NDA antes de Workbook con datos sensibles. - **Etapa 1 (Captura individual)** · validar que datos HD natal del equipo cliente se procesan SOLO en su Supabase project · no en EL central. - **Etapa 2 (Cohort Lab + instalación)** · validar que Brain Codes (BC-) del equipo cliente nacen en su Supabase · no en EL central. - **Etapa 3 (Operación)** · validar que ROI Tracker del cliente se queda en su schema · no se mezcla con métricas de EL. ### 8.3 Post-instalación · membership activa - Sesión mensual de gobernanza con Sherpa Senior EL (incluida en membership). - Cascada de actualizaciones del Kernel (cuando EL versiona). - Skill Pack updates automáticos. - Acceso a nuevos MetaPlaybooks canonizados en EL (cuando aplican al dominio del cliente). --- ## 9. NEXTs ### Inmediatos (esta semana) - [NEXT][Jay] Producir `SOP-EL-HIORG-SanitizacionDemoVault-v01` (operacionaliza Capa 3). - [NEXT][Victor] Agendar sesión con abogado IP especializado · 1-2 sesiones iniciales · entregables esperados: - Borrador contrato de licencia base. - Borrador NDA cliente + NDA implementador. - Cláusulas anti-replicación canónicas. - Cláusula de auditoría. ### Pre-primer cliente B2B real (4-8 semanas) - [NEXT][Victor + Abogado] Cerrar contrato base licencia (Capa 6). - [NEXT][Jay] Producir checklist pre-instalación cliente (operacionaliza §8.1). - [NEXT][Alex] Validar que setup técnico cliente respeta SEC-02 (Supabase project propio). - [NEXT][Jay] Sanitización T2 de templates universales (sin datos internos EL). ### Post-Caso 0 (Q3 2026) - [NEXT][Jay] Producir `MePB-EL-HIORG-ClientLicensing-v01` (operacionaliza Capa 4 económica completa). - [NEXT][Anahí] Considerar producir cascade content sobre "Seguridad como feature" (línea B2B HIORG). ### Post-3 clientes B2B (Q4 2026) - [NEXT][Victor + Jay] Producir `WP-EL-HIORG-Security-Whitepaper-v01` cliente-facing. - [NEXT][Jay] Documentar CAS LabPraxis de incidentes de seguridad detectados (si los hay). --- ## 10. CONEXIONES CANÓNICAS | Documento | Relación | |---|---| | `ARQ-XX-BMF-MPB-Kernel-v01` | L0 Crown Jewel · NUNCA se entrega | | `MePB-BMF-MetaPlaybook-Of-MetaPlaybooks-v01` | L0.5 Crown Jewel · NUNCA se entrega | | `MePB-BMF-MetaFactoryBuilder-v01` | L1 Crown Jewel · NUNCA se entrega | | `MePB-EL-OrganizationalKernel-v01` | Frame organizacional · §13 (Patrón replicable B2B) formalizado aquí como Capa 2 | | `MePB-EL-CorpBrainOS-BehaviorCapture-v01` | Capa 1 técnica + reglas de desensibilización (§6) | | `ARQ-XX-DOIX-CorpBrainOS-Supabase-v01` | Arquitectura técnica · RLS + Kit Assembler | | `SOP-EL-HIORG-SanitizacionDemoVault-v01` | Operacionaliza Capa 3 (próximo entregable) | | `MePB-EL-HIORG-ClientLicensing-v01` | Operacionaliza Capa 4 (futuro post-Caso 0) | | `WP-EL-HIORG-Security-Whitepaper-v01` | Cliente-facing (futuro post-3 clientes) | | `PAP-HIORGS-ModeloProducto-Interno-v01` | Patrón interno vs cliente-facing (referencia) | | `IB-AR-DemoVault/` | Caso Alain Rios · ejemplo aplicado de Capa 3 | | `DC-XX-BMF-MEL-MasteryEnforcementLayer-v11` | L6 governance ejecutable · enforcement de las 6 capas | --- ## 11. CHANGELOG - **2026-05-18 · v01** — Primer release. MetaPlaybook canónico de las 6 capas de seguridad del SO-HiORG. Type D L2 · domain IP Protection. 5 decisiones estratégicas ratificadas por Victor: D-Sec-01 (Crown Jewel L0+L0.5+L1) · D-Sec-02 (L2 licenciado adaptado) · D-Sec-03 (L3-L4 del cliente) · D-Sec-04 (modelo híbrido) · D-Sec-05 (Victor + abogado IP Capa 6). 6 capas operativas + matriz canónica de qué accede el cliente + 6 anti-patrones + checklist pre-instalación + NEXTs por horizonte (inmediato · pre-primer cliente · post-Caso 0 · post-3 clientes). - **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). --- *MePB-EL-HIORG-SecurityLayers-v01 · IB-EL-EmpowerLabs/CP-EL-Control-Planes/ · 18 de mayo de 2026* *Owner: Victor Heredia · Sherpa Owner: Jay (SherpaX maestro)* *"Vendemos valor real · protegemos lo que somos. Las 6 capas funcionan solo juntas."*