--- type: MePB asset_id: MePB-EL-SX-DemoVaultSherpaGuide-v01 version: v01 status: Draft owner: Victor Heredia sherpa_owner: Jay fecha_creacion: 2026-05-20 fecha_ultima_actualizacion: 2026-05-20 fecha_migracion_bmf: 2026-05-20 intellbank: IB-Clientes/IB-AR-DemoVault subbank: PB-AR-SherpaX proposito: MePB · SX DemoVaultSherpaGuide · IB-AR-DemoVault nota_migracion: Frontmatter BMF agregado en batch masivo 2026-05-20 · Workbench FASE 5C · proposito pendiente revisión manual --- ## Asset Header - **Asset ID:** MePB-EL-SX-DemoVaultSherpaGuide-v01 - **Version:** v01 - **Status:** Draft - **Owner:** Victor Heredia - **IntellBank:** IB-EL-EmpowerLabs - **Tipo:** MePB — MetaPlaybook - **Propósito:** Patrón replicable para construir un Demo Vault sanitizado destinado a un Sherpa Guide externo - **Última actualización:** 2026-04-18 --- # Demo Vault para Sherpa Guide — MetaPlaybook del Patrón ## El clone sanitizado del Reinventaverse que convierte lectores en operadores --- > *Versión Demo Vault — incluida sin sanitización (publicación pública). Fecha: 2026-04-18* ## Nota de evolución > Este MetaPlaybook codifica el patrón reutilizable para construir un **Demo Vault** — un clon sanitizado del Reinventaverse que se entrega a un Sherpa Guide externo (partner formal) para que aprenda el ecosistema por inmersión operativa, no por lectura pasiva. > > Cada instancia concreta (p.ej. Alain Rios / Radsoft) se especifica en su propio documento `PLAN-EL-SX-DemoVault[Nombre]-v01.md`, que instancia este patrón. > > **Regla de actualización:** cuando una nueva instancia revela un patrón que debería ser parte del MetaPlaybook (no una particularidad del partner), se destila aquí y se versiona a v02. --- ## PARTE I — EL CONCEPTO ### 1. ¿Qué es un Demo Vault? Un **Demo Vault** es un IntelliBank completo, navegable y operable que replica la estructura y las reglas del Reinventaverse, poblado con una masa crítica de contenido sanitizado suficiente para que un Sherpa Guide externo pueda: 1. **Explorar** el ecosistema como si estuviera dentro del equipo 2. **Operar** aplicando las reglas BMF reales (naming, registry, convenciones) 3. **Crear** sus propios IntelliBanks, CAS, MPB y materiales comerciales dentro del demo 4. **Aprender por reps**, no por lectura 5. **Pre-configurar** su propio SherpaX a partir de contenido que ya le es familiar No es un paquete de documentos. No es un curso. No es un deck. Es un **sandbox activo** — el equivalente operativo a poner a alguien a manejar un simulador de vuelo antes de entregarle el avión real. ### 2. El problema que resuelve Un consultor externo que necesita vender un ecosistema del que *leyó* pero que no *vivió* se convierte en un vendedor de conceptos. El Sherpa Guide que queremos activar debe poder decir: > "No te estoy presentando un sistema. Yo lo opero. Aquí está mi vault." Eso requiere haberlo operado. El Demo Vault es el atajo que permite esa operación sin comprometer confidencialidad. ### 3. Los tres principios de diseño **Inmersión > Lectura.** Todo lo que se pueda aprender haciendo, se aprende haciendo. La lectura queda como referencia, no como método primario. **Reglas activas > Reglas enunciadas.** Las convenciones BMF (naming, registry, IntelliBanks) no se explican en un manual — se aplican en el vault y se reciben como feedback cuando se violan. El sistema enseña. **Crear > Recibir.** El Sherpa Guide no recibe un archivo muerto. Recibe una estructura que *debe habitar* creando su propio IntelliBank, sus propios BC, sus propios CAS. La apropiación sucede creando. --- ## PARTE II — LOS 6 COMPONENTES DEL DEMO VAULT Todo Demo Vault contiene exactamente estos 6 componentes. El PLAN de cada instancia especifica *el contenido* de cada uno para ese partner particular. ### Componente 1 — Vault Skeleton La estructura BMF completa, idéntica al real: - Carpeta raíz del IntelliBank (p.ej. `IB-AR-DemoVault/`) - Project Banks internos que aplican al caso del partner - Registry maestro propio (`CP-[ENTIDAD]-IntelliBanks-Registry-v01.md`) - Convención de naming activa (ver Parte III) - Índice tipo Wiki con los conceptos core que el partner debe dominar **Criterio:** cuando el partner abra cualquier carpeta, debe sentir que "así se ve el sistema real". ### Componente 2 — Seed Content La masa crítica de documentos sanitizados. **Tamaño estándar: ~30 docs.** Distribución tipo (ajustable por PLAN): - 1 MePB (el propio Demo Vault como ejemplar de MetaPlaybook) - 4–5 MPB / MPB samples (playbooks comerciales y operativos) - 8–10 CAS (casos de estudio — el formato de captura de aprendizaje) - 4–6 RES / OUT (resúmenes ejecutivos, outputs de sesiones) - 4–5 MKT / LP (materiales comerciales como modelo) - 5–6 Papers / DC (documentos canónicos del ecosistema) - 1 Registry (el maestro del propio Demo Vault) **Criterio:** cada doc incluido debe servir para **crear propuestas** o **explicar el ecosistema**. Si no hace una de esas dos cosas, no entra. **Exclusión categórica:** Brain Codes (`BC-`, `BCV-`) y Destillers **no se incluyen** en el Demo Vault bajo ninguna circunstancia, independientemente del tier del partner. Son IP estratégica del ecosistema y no se comparten con externos ni en versión sanitizada. ### Componente 3 — Reglas Activas Las skills BMF que operan sobre el vault: - Naming convention (lint automático de nombres) - Registry updater (mantiene sincronizado el CP) - File renamer (corrige prefijos incorrectos) - Vault orphan rescue (reubica archivos fuera de lugar) - Next scanner (escanea pendientes asignados) El partner recibe estas skills preinstaladas en su entorno para que su operación se autocorrija desde el minuto 1. ### Componente 4 — SherpaX preconfigurado Una instancia de SherpaX con: - Conocimiento pre-cargado del contenido del Demo Vault - Memoria inicial con el perfil del partner (Human Design si aplica, rol, objetivos) - Prompts preconfigurados de "primera ayuda" (ver Componente 5) - Tono calibrado a su perfil (Manifestor se aborda distinto que Generator, etc.) **Criterio:** el partner debe poder escribir "¿qué hay en mi vault?" y recibir una respuesta útil inmediatamente, sin setup adicional. ### Componente 5 — Mission Pack Una secuencia de ejercicios de "primera semana" que llevan al partner de *explorar* a *crear*. Pack canónico (adaptable por PLAN): | # | Misión | Objetivo | Entregable | | --- | ----------------------------- | ---------------------------------- | ----------------------------------------------- | | M1 | Explorar el vault | Familiarización con estructura BMF | Mapa mental del IntelliBank recorrido | | M2 | Crear tu propio IntelliBank | Apropiación del sistema | `IB-[ENTIDAD]-[Nombre]/` creado | | M3 | Documentar tu primer CAS | Formato de captura de aprendizaje | Un CAS redactado sobre una conversación real | | M4 | Generar tu Mapa de Activos | Visión de tu ecosistema | Doc OUT con inventario de activos propios | | M5 | Levantar tu ROI Tracker | Instrumentación comercial | Spreadsheet `CP-[ENTIDAD]-ROI-Tracker-v01.xlsx` | | M6 | Preparar tu primera propuesta | Aplicación comercial | MKT o LP para un prospecto real | ### Componente 6 — Bridge to Real El puente del sandbox a la operación real. Incluye: - Criterios de "graduación": cuándo el partner ya no necesita el demo - Protocolo de bifurcación: cómo el demo queda congelado mientras su vault real evoluciona - Lista de conversaciones pendientes entre Victor y el partner para cerrar el bridge - Primer caso real acordado (p.ej. su empresa familiar como Piloto 1) --- ## PARTE III — REGLAS DE SANITIZACIÓN ### 1. Tiers de confidencialidad Todo doc candidato a seed se clasifica en uno de estos tiers: | Tier | Descripción | Trato en el Demo Vault | |------|-------------|------------------------| | **T0 — Público** | Ya publicado (papers, LPs públicas) | Entra tal cual | | **T1 — Consultor** | Contenido comercial/metodológico sin datos sensibles | Entra con nombres de clientes anonimizados | | **T2 — Partner interno** | Contenido operativo del equipo | Entra sanitizado (ver §2) | | **T3 — Confidencial estratégico** | Roadmaps, financieros, Brain Codes, Destillers, IP del founder | **NO entra** | | **T4 — Maestro (XX)** | Todo contenido en `IB-XX-Maestro` | **NO entra bajo ninguna circunstancia** | **Regla de oro:** ante la duda, sube el tier, no lo bajes. ### 2. Protocolo de sanitización para T2 Cuando un doc T2 entra al Demo Vault, se aplica: - **Nombres propios de clientes/prospectos reales:** reemplazar por placeholders (`[CLIENTE_PILOTO]`, `[CIO_OBJETIVO]`) - **Cifras financieras reales:** reemplazar por rangos o placeholders (`[MONTO_X]`) - **Conversaciones internas sensibles:** omitir o reemplazar por síntesis no-sensible - **Brain Codes y Destillers:** excluidos categóricamente. No se clonan ni se sanitizan — simplemente no entran al Demo Vault - **Emails, teléfonos, IDs:** reemplazar por placeholders - **Fechas sensibles (lanzamientos, negociaciones):** generalizar (`2026-Q2` en lugar de fecha exacta) ### 3. Cambio de ENTIDAD Esta es la regla que resuelve la duplicidad de Asset IDs: > **Todo doc clonado al Demo Vault cambia su ENTIDAD de `EL` (o la que tenga) a la ENTIDAD asignada al partner.** Ejemplos: - `MKT-EL-SX-OfertaProspecto-v01` → `MKT-AR-SX-OfertaProspecto-v01` - `CAS-EL-SX-001-Founder-Inventor-v01` → `CAS-AR-SX-001-Founder-Inventor-v01` - `MPB-EL-SX-GTM-v01` → `MPB-AR-SX-GTM-v01` Todos los WikiLinks internos del Demo Vault se reescriben para que resuelvan **dentro del propio IB-[ENTIDAD]-DemoVault**. Ningún link apunta al vault original. **Excepción:** los docs "patrón" que viajan con el Demo Vault como ejemplo de MetaPlaybook (este mismo documento, por ejemplo) conservan su ENTIDAD `EL` porque son propiedad intelectual de EmpowerLabs que se licencia al partner — no son activos del partner. ### 4. Checklist de sanitización (por doc) Antes de que un doc entre al Demo Vault: - [ ] Tier confirmado (T0/T1/T2) - [ ] Info confidencial reemplazada o eliminada - [ ] ENTIDAD cambiada a la del partner - [ ] WikiLinks internos reescritos - [ ] Frontmatter actualizado (Owner, IntellBank, fecha) - [ ] Nota en el doc: "Versión Demo Vault — sanitizada el [FECHA]" --- ## PARTE IV — TIER CONFIGURABLE POR PARTNER El Demo Vault se calibra según la relación formal con el partner: | Tier de Partner | Accede a | Excluye | |-----------------|----------|---------| | **Sherpa Guide Externo** | T0, T1 | T2, T3, T4 | | **Partner Formal Consultor** | T0, T1, T2 selecto | T3, T4 | | **Partner Formal Interno** *(default)* | T0, T1, T2 completo | T3, T4 | | **Co-Founder / Board** | T0, T1, T2, T3 selecto | T4 | **IB-XX-Maestro nunca se clona, independientemente del tier.** Es el corazón canónico de EmpowerLabs y no sale del vault real. --- ## PARTE V — PROCESO DE CONSTRUCCIÓN Siete fases canónicas. Cada fase produce un entregable verificable. ### Fase 1 — PLAN del partner Se redacta `PLAN-EL-SX-DemoVault[Nombre]-v01.md` que define: - Perfil del partner (incluir Human Design si aplica) - Tier asignado - ENTIDAD asignada (código de 2 letras) - Lista específica de los ~30 docs seed - Mission Pack adaptado a su rol/objetivos - Calendario de entrega - Bridge to Real acordado ### Fase 2 — Curación del seed content A partir del PLAN, se seleccionan los docs reales del vault. Se usa el **LLM Wiki como fuente primaria** de navegación. Por cada doc candidato, se verifica tier y se marca para sanitización. ### Fase 3 — Clonación y sanitización Se crea `IB-[ENTIDAD]-DemoVault/` como área de construcción en el vault de Victor. Se copia cada doc, se aplica el checklist de sanitización del §III.4, se cambia la ENTIDAD. ### Fase 4 — Reescritura de WikiLinks Todos los `[[WikiLink]]` internos se actualizan para que resuelvan dentro del propio IB del Demo Vault. Ningún link fuga al vault real. ### Fase 5 — Preconfiguración de SherpaX Se ingesta el contenido del Demo Vault al SherpaX del partner. Se carga su memoria inicial (perfil, objetivos, prompts base). ### Fase 6 — Empaque y entrega El `IB-[ENTIDAD]-DemoVault/` completo se empaqueta como ZIP, se sube a Drive compartido con el partner, y se envía instrucciones de instalación en su Obsidian local. ### Fase 7 — Onboarding activo Sesión de 60–90 minutos con el partner para: - Tour del vault entregado - Activación del primer Mission (M1 o M2) - Activación del SherpaX - Calendario de sync siguiente (1 semana después) --- ## PARTE VI — BRIDGE TO REAL El Demo Vault no es el destino final. Es la rampa. **Criterios de graduación (el partner ya no necesita el demo):** - Completó al menos M1–M4 del Mission Pack - Creó su propio IntelliBank con >10 docs propios - Tiene su primer caso real en marcha (Piloto 1) - Su SherpaX ya se alimenta más de su operación real que del demo **Protocolo de bifurcación:** - El `IB-[ENTIDAD]-DemoVault/` se congela (read-only en su Obsidian) - Sus IntelliBanks propios quedan como activos vivos - El partner decide si el demo se conserva como referencia o se archiva - Su SherpaX migra a alimentarse de su vault real --- ## PARTE VII — MANTENIMIENTO DEL METAPLAYBOOK **Cuándo actualizar este MePB:** - Cuando una nueva instancia revela un patrón general (no particular del partner) - Cuando cambia una convención BMF que afecta la sanitización - Cuando se agrega/elimina un componente canónico - Cuando se incorpora un nuevo tier de partner **Cuándo crear v02:** - Cambio estructural en los 6 componentes - Cambio en el protocolo de sanitización - Cambio en el Mission Pack canónico Versiones intermedias (v01a, v01b) se permiten para correcciones menores. --- ## ANEXO A — Convenciones de naming dentro del Demo Vault Todos los docs clonados siguen la convención BMF: ``` [TIPO]-[ENTIDAD_PARTNER]-[Proyecto]-[NombreDescriptivo]-vNN.ext ``` Ejemplo completo para Alain Rios (ENTIDAD = `AR`): - `IB-AR-DemoVault/CP-AR-IntelliBanks-Registry-v01.md` - `IB-AR-DemoVault/PB-AR-SherpaXDemo/MPB-AR-SX-GTM-v01.md` - `IB-AR-DemoVault/PB-AR-CIO-Club/CAS-AR-001-PrimerContacto-v01.md` --- ## ANEXO B — Plantilla de PLAN (mínimos no negociables) Un `PLAN-EL-SX-DemoVault[Nombre]-v01.md` debe especificar: 1. **Partner:** Nombre, rol, empresa, Human Design (si aplica) 2. **Tier:** ver Parte IV 3. **ENTIDAD:** código de 2 letras, justificado 4. **Masa crítica:** lista exacta de docs seed (~30), con mapeo doc-real → doc-sanitizado 5. **Mission Pack:** adaptación del canónico 6. **Calendario:** fechas de construcción, entrega y onboarding 7. **Bridge to Real:** primer caso real, criterios de graduación --- ## ANEXO C — Checklist integral de entrega - [ ] PLAN redactado y aprobado - [ ] 30 docs seed curados - [ ] 30 docs sanitizados (checklist §III.4 completado por doc) - [ ] ENTIDAD cambiada en todos los docs - [ ] WikiLinks reescritos (lint final) - [ ] Registry maestro del Demo Vault generado - [ ] SherpaX preconfigurado - [ ] ZIP empaquetado y subido a Drive - [ ] Instrucciones de instalación enviadas al partner - [ ] Sesión de onboarding agendada - [ ] Bridge to Real documentado y firmado --- ## Relationships - **Patrón de:** `PLAN-EL-SX-DemoVault[Nombre]-v01.md` (instancias concretas) - **Depende de (conceptos del vault maestro, fuera del Demo Vault):** `Naming-Convention`, `IntelliBanks`, `4-Clases-Documentos` - **Relacionado (playbooks del vault maestro):** `SherpaX-Ignition`, `SherpaX-GTM`, `EmpowerTeams-X` - **Primera instancia:** `PLAN-EL-SX-DemoVaultAlain-v01` (Alain Rios / Radsoft) --- ## Open Questions / Gaps - Proceso de actualización del Demo Vault cuando el patrón evoluciona y la instancia ya fue entregada - Métricas de éxito del Demo Vault (¿cómo medimos si funcionó?) - Integración con CP-XX-IntelliBanks-Registry: ¿los Demo Vaults aparecen en el registry maestro o quedan fuera? --- *MetaPlaybook canónico — Demo Vault para Sherpa Guide · EmpowerLabs · 2026-04-18*