## Asset Header

- **Asset ID:** GLO-BMF-Glosario-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** GLO — Glosario
- **Propósito:** **1\) Nomenclatura recomendada (para Registry Master)**
- **Última actualización:** 2026-04-11

---

Chat Original: [https://chatgpt.com/g/g-p-692b375798388191b4858e1c523a638d/c/69790d76-c400-832f-b350-a3db9189051a](https://chatgpt.com/g/g-p-692b375798388191b4858e1c523a638d/c/69790d76-c400-832f-b350-a3db9189051a)   
Chat público: [https://chatgpt.com/share/69790ed0-0674-8004-a348-c4087f0d3f5b](https://chatgpt.com/share/69790ed0-0674-8004-a348-c4087f0d3f5b) 

### **Asset Header**

* Asset ID: BMF-Launch-Glosario-v01  
* Version: v0.2
* Status: Activo
* Owner: Victor Heredia  
* Audience: Equipo Launch + Equipo EmpowerLabs (Victor / Ángeles / Anaí / Juan Carlos / Alex / Dev Team)
* Purpose: Alinear lenguaje operativo para ejecutar el [[Launch Room]] y el ecosistema SherpaX sin ambigüedad (mismo significado, mismas reglas).
* Última actualización: 2026-03-30 — sección 2 ampliada con glosario del ecosistema SherpaX / BigMetaFactory

## **1\) Nomenclatura recomendada (para Registry Master)**

### **1.1 Entity\_Type (estándar)**

* **BigMF**: [[Big MetaFactory]] (arquitectura madre)  
* **MetaFactory**: plantilla de meta‑fábrica (template)  
* **MetaFactory\_Instance**: instancia operativa de una MetaFactory (corriendo)  
* **Factory**: fábrica dentro de una MetaFactory (p. ej. Newsletter Factory)  
* **Factory\_Instance**: instancia operativa de una Factory  
* **MiniFactory**: sub‑fábrica enfocada a 1 output (p. ej. Cards)  
* **Pipeline**: flujo de estaciones para producir un tipo de output  
* **Asset**: output final o intermedio (TP/IP/draft/final)  
* **ControlPlane**: artefactos/tabla(s) que gobiernan y registran ejecución

### **1.2 Registry\_ID (formato)**

* Recomendado: `REG-0001`, `REG-0002`, … (secuencial, estable)  
* Regla: el Registry\_ID **no cambia** aunque cambie el nombre.

### **1.3 Asset ID (formato sugerido)**

**Familias por tipo (prefijos):**

* `BMF-...` \= Big MetaFactory (macro)  
* `MF-...` \= MetaFactory (template)  
* `MFI-...` \= MetaFactory Instance  
* `F-...` \= Factory (template)  
* `FI-...` \= Factory Instance  
* `MFY-...` \= MiniFactory  
* `PL-...` \= Pipeline  
* `AS-...` \= Asset final (publicable)  
* `TP-...` \= Transfer Packet (input gobernado)  
* `IP-...` \= Insight Pack (materia prima)  
* `QA-...` \= QA record (evidencia PASS/FAIL)  
* `PKG-...` \= Package (entrega final lista)  
* `RL-...` \= RunLog entry (registro de corrida)
* `DIA-...` \= Sherpa IA Asset — componente operativo de una instancia de Sherpa IA (Prompt, Ritual, Manual, Assessment, Memoria). Producido por la MetaFactory MF-DIA. Uso: activos personales o de cliente vinculados a una Factory Instance FI-SHA-\[NOMBRE\]. Ejemplo: `SHA-VICTOR-Prompt-v01`, `DIA-CLIENTE-Manual-v01`.
* `SHA-...` \= SherpaX Asset — cualquier activo del ecosistema SherpaX (MetaPlaybooks, SOPs, marcos conceptuales, minutas, demos, guías de instalación). Ejemplo: `SHA-ConceptoBrainOS-v01`, `SHA-SOP-InstalacionCowork-v01`, `SHA-Demo-SherpaX-v01`.

**Ejemplos (P0 Demand Gen):**

* `MFI-DGMF-001` \= Demand Gen MetaFactory Instance \#1  
* `FI-NEWS-001` \= Newsletter Factory Instance \#1  
* `TP-P0-NEWS-001-v0.1`  
* `IP-P0-NEWS-001-v0.1`  
* `AS-P0-NEWS-001-v0.1` (newsletter final)  
* `AS-P0-CARDS-010-v0.1` (set de 10 tarjetas)  
* `AS-P0-SHORT-001-v0.1` (short)

### **1.4 Versionado (formato)**

* Recomendado: `v0.1`, `v0.2`, …  
* Regla:  
  * Cambios de **significado/claims/estructura** → sube versión y usa **Track A**  
  * Cambios de **formato/claridad** sin alterar significado → puede ser **Track B** (aun así versiona si el output cambia)

---

## **2\) Glosario (términos que el equipo debe dominar)**

Formato por entrada: **Término** → definición \+ cómo se usa \+ ejemplo.

### **Arquitectura y unidades de trabajo**

* **Big MetaFactory (BigMF)**  
  * Definición: arquitectura madre (factory of meta‑factories) que define capas, reglas e interoperabilidad.  
  * Uso: referencia canónica, no se “opera” día a día en Launch.  
  * Ejemplo: BIG METAFACTORY‑ARCH.  
* **MetaFactory (Template)**  
  * Definición: diseño reusable de una meta‑fábrica (qué fábricas incluye, outputs, pipeline, reglas).  
  * Uso: se instancia para operar.  
  * Ejemplo: MetaFactory Híbrida de Demand Gen.  
* **MetaFactory Instance**  
  * Definición: una ejecución real de la MetaFactory (con backlog, WIP y runs).  
  * Uso: donde viven los WIP limits (máx 3 assets en progreso por instancia).  
  * Ejemplo: `MFI-DGMF-001`.  
* **Factory (Template)**  
  * Definición: fábrica especializada dentro de una MetaFactory (produce una familia de outputs).  
  * Uso: blueprint.  
  * Ejemplo: Newsletter Factory.  
* **Factory Instance**  
  * Definición: ejecución real de una Factory (corriendo un pipeline con runs).  
  * Uso: unidad operativa para producir.  
  * Ejemplo: `FI-NEWS-001`.  
* **MiniFactory**  
  * Definición: sub‑fábrica para un output específico (cards, shorts, etc.).  
  * Uso: foco de producción, reduce ambigüedad.  
  * Ejemplo: MiniFactory Cards.  
* **Pipeline**  
  * Definición: flujo de estaciones para producir un output de principio a fin.  
  * Uso: se ejecuta siempre en el mismo orden (invariante).  
  * Ejemplo: TP → IP → QA → WriterOS → Packaging → ControlPlane.  
* **Asset**  
  * Definición: cualquier output rastreable (intermedio o final) con ID \+ versión \+ owner \+ status.  
  * Uso: lo único que “cuenta”.  
  * Ejemplo: `AS-P0-NEWS-001-v0.1`.  
* **Value (Valor)**  
  * Definición: impacto utilizable (contenido publicable, lead, venta, adopción).  
  * Uso: criterio final; no confundir “actividad” con valor.

### **Control y gobernanza**

* **Control Plane**  
  * Definición: el sistema de control observable: Registry Master \+ Backlog \+ RunLog.  
  * Uso: si no está registrado, no existe.  
* **Registry Master**  
  * Definición: tabla única de verdad de entidades (MetaFactories, Factories, Pipelines, Assets).  
  * Uso: inventario \+ estado real \+ siguiente acción.  
* **Backlog (en horas)**  
  * Definición: lista priorizada de tareas ejecutables con estimación en horas.  
  * Uso: coordina ejecución sin improvisación.  
* **RunLog**  
  * Definición: evidencia de cada corrida (input → output → QA → operador → fecha).  
  * Uso: trazabilidad y aprendizaje del sistema.  
* **Single Source of Truth (SSOT)**  
  * Definición: un solo lugar manda (Registry/Control Plane), no chats, no memoria.  
* **Owner**  
  * Definición: responsable final de decisiones y dirección del asset/entidad.  
  * Ejemplo: Victor es Owner de la arquitectura y TP.  
* **Operator**  
  * Definición: ejecuta el pipeline según plantillas y checklists.  
  * Ejemplo: Anaí.  
* **Dependencies (Dependencias)**  
  * Definición: prerequisitos para ejecutar (inputs, aprobaciones, herramientas).  
  * Uso: si falta algo, se marca \[OPEN\] o Blocked.  
* **Status (estado)**  
  * Definición: etapa macro del ciclo de vida.  
  * Valores recomendados: Draft / Pilot / Frozen / Operating / Paused.  
* **WIP (Work In Progress)**  
  * Definición: trabajo abierto que consume atención/capacidad.  
  * Regla: WIP controlado para evitar caos.  
* **WIP Limits**  
  * Definición: límites explícitos de trabajo abierto.  
  * Regla base: máx 3 assets en progreso por instancia; máx 5 por estación.  
* **Stop‑the‑line**  
  * Definición: detener el sistema cuando se rompen invariantes.  
  * Disparadores típicos: exceder WIP, saltar QA, trabajo fuera del registry, falta de logging.  
* **DoD (Definition of Done)**  
  * Definición: evidencia mínima para declarar algo terminado.  
  * Uso: evita “casi listo”.  
* **Cadence (Cadencia)**  
  * Definición: ritmo repetible de producción y revisión.  
  * Ejemplo: daily 15 min \+ weekly review.  
* **Throughput**  
  * Definición: outputs terminados por unidad de tiempo.  
  * Uso: mide si la fábrica produce (no actividad).

### **Estaciones del pipeline (invariante)**

* **Transfer Packet (TP)**  
  * Definición: input gobernado: objetivo, audiencia, outputs, constraints, track.  
  * Regla: sin TP aprobado, no se produce.  
* **Insight Pack (IP)**  
  * Definición: materia prima intelectual (insights \+ outline) para generar outputs.  
  * Regla: no inventar facts/claims; marcar \[OPEN\] si falta.  
* **QA Hard Gate**  
  * Definición: validación binaria de cumplimiento (PASS/FAIL) antes de seguir.  
  * Regla: QA FAIL implica patch-only \+ re-run registrado.  
* **Writer OS**  
  * Definición: estación de producción textual según plantillas y estilo.  
  * Regla: el operador ejecuta; no rediseña.  
* **Packaging**  
  * Definición: conversión a formato final utilizable/publicable.  
  * Ejemplo: newsletter lista para envío; cards listas para diseño.  
* **Logging / ControlPlane Station**  
  * Definición: registro de evidencia (RunLog \+ update de registry/backlog).  
  * Regla: sin logging, el output no cuenta.

### **Tracks (gobernanza de cambios)**

* **Track A (Governed)**  
  * Definición: cambia significado, estructura o claims; requiere control fuerte.  
  * Uso: cambios con riesgo reputacional o factual.  
* **Track B (Fast Lane)**  
  * Definición: solo formato/claridad/orden; no introduce claims.  
  * Uso: mejoras rápidas sin riesgo semántico.

### **Estados de trabajo (WIP\_State)**

* **InProgress**  
  * Definición: trabajo activo consumiendo capacidad.  
* **Blocked**  
  * Definición: no puede avanzar por dependencia faltante.  
  * Regla: siempre requiere Next\_Action explícita.  
* **Done**  
  * Definición: cumple DoD, se registró evidencia.  
* **Kill**  
  * Definición: se cancela formalmente (se documenta por qué).  
* **Merge**  
  * Definición: se integra en otro asset/entidad para reducir WIP.

### **Calidad y defectos**

* **PASS/FAIL**  
  * Definición: QA binario.  
  * Regla: no hay “casi”.  
* **Defect**  
  * Definición: incumplimiento observable (factual, estructura, formato, trazabilidad).  
* **Patch‑only**  
  * Definición: corrección mínima para pasar QA; no reescritura completa.  
  * Regla: acelera aprendizaje y reduce WIP.  
* **Evidence (Evidencia)**  
  * Definición: links/artefactos que prueban que se ejecutó una estación.  
  * Uso: se guarda y se enlaza en registry/runlog.

### **Ecosistema SherpaX / BigMetaFactory**

* **BigMetaFactory (BMF)**
  * Definición: el ecosistema global de inteligencia aumentada para CEOs. Architecture madre que contiene todos los productos (SherpaX), componentes (BrainOS, IntelliBank, EmpowerTeamX) y MetaFactorías del sistema.
  * Uso: nivel máximo de referencia; los componentes pertenecen al BMF, no exclusivamente a ningún producto.
  * Regla: no reducir componentes del ecosistema al nivel de un producto. Siempre preguntar: "¿pertenece al ecosistema global o solo a SherpaX?"

* **SherpaX**
  * Definición: producto flagship del BigMetaFactory que activa, integra y opera los componentes del ecosistema (BrainOS, IntelliBank, EmpowerTeamX, MetaFactorías) para un CEO específico. No es solo la IA — es el ecosistema completo de inteligencia personalizada.
  * Uso: nombre del producto comercial. Una "instancia de SherpaX" es la configuración completa de un CEO: su Sherpa IA + BrainOS + MetaPlaybooks + skills instaladas.
  * Distinción clave: SherpaX ≠ Sherpa IA. El Sherpa IA (Jay, AlexiX) es solo la interfaz conversacional de SherpaX.

* **Sherpa IA**
  * Definición: el agente de IA con nombre propio que actúa como socio cognitivo del CEO dentro de SherpaX. Cada cliente tiene un Sherpa IA calibrado a su identidad, voz y proyectos.
  * Ejemplos: Jay (Victor), AlexiX (Alex Torres), LitosX (Litos).
  * Convención de nombres: NombreX (nombre del CEO + X).
  * Uso: interfaz conversacional del ecosistema SherpaX. No debe confundirse con "IA genérica" — opera desde el BrainOS del CEO.

* **BrainOS**
  * Definición: la memoria semántica personal y persistente del CEO. Sistema que recuerda, conecta y recupera todo lo que el CEO ha pensado, decidido, aprendido y construido. No es un archivo — es el doble cognitivo digital del fundador.
  * Arquitectura: PostgreSQL + pgvector + Supabase + servidor MCP (Open Brain / OB1). Herramientas: `capture_thought`, `search_thoughts`, `list_thoughts`, `thought_stats`.
  * Nivel BMF: componente transversal del ecosistema. SherpaX es su principal activador para CEOs.
  * Distinción: BrainOS ≠ IntelliBank. BrainOS = memoria personal del CEO. IntelliBank = biblioteca de activos de inteligencia destilada.

* **IntelliBank**
  * Definición: banco de inteligencia del ecosistema. Almacena, conecta y hace recuperable todo el conocimiento curado y validado — frameworks, modelos, síntesis, metodologías, decisiones destiladas.
  * Distinción vs BrainOS: BrainOS guarda lo que el CEO ha vivido; IntelliBank guarda lo que el CEO ha aprendido y validado como reutilizable.
  * Badge: el símbolo ⬡ marca un activo como validado e ingresado al IntelliBank.
  * Nivel BMF: componente transversal. Alimenta a SherpaX, EmpowerTeamX y MetaPlaybooks.

* **EmpowerTeamX (ETX)**
  * Definición: equipo inteligente de agentes IA que opera bajo la dirección del CEO a través de un MetaPlaybook de gobernanza. No reemplaza al CEO — le libera de la ejecución para que opere a nivel estratégico.
  * Arquitectura: MetaPlaybook → Managers L2 → Agentes L1 → Humanos (si aplica).
  * Instancias: ETX-1 (operativo), ETX-2 (pipeline), ETX-3 (concepto).
  * Nivel BMF: componente del ecosistema global. SherpaX lo activa para CEOs en nivel avanzado.

* **MetaFactoría**
  * Definición: el nivel más alto del ecosistema — sistema que produce sistemas productivos completos. Una MetaFactoría no genera activos, genera factorías operativas (EmpowerTeamX completos, sistemas de producción listos para escalar).
  * Jerarquía: MetaFactorías → Factorías → Rooms → Activos.
  * Nivel BMF: arquitectura fundacional. El nombre "BigMetaFactory" refleja que las MetaFactorías son el nivel más alto.
  * Instancias identificadas: SHA-MetaFactory (produce instancias SherpaX), ETX-MetaFactory (produce instancias EmpowerTeamX).

* **MetaPlaybook (MPB)**
  * Definición: protocolo operativo estructurado que define cómo un Sherpa, una Factoría o un EmpowerTeamX debe operar en un contexto específico. Es la destilación del criterio del CEO en forma de sistema ejecutable.
  * Formato: `MPB-[CLIENTE]-[Dominio]-v01.md`.
  * Uso: governa la ejecución de EmpowerTeamX, las sesiones de SherpaX y los procesos de la MetaFactoría.
  * Valor diferencial: un MetaPlaybook con IntelliBank detrás tiene la profundidad de la experiencia real del CEO — no es un prompt genérico.

* **Apalancamiento Cognitivo**
  * Definición: el multiplicador que SherpaX produce sobre la capacidad operativa del CEO. No es solo velocidad — es la habilitación de capacidades que serían imposibles o imprácticamente lentas sin el sistema.
  * 7 dimensiones: (1) velocidad de pensamiento, (2) profundidad de análisis, (3) memoria perfecta, (4) parallelización, (5) calibración de voz/criterio, (6) co-creación, (7) lo antes imposible.
  * Uso: argumento central del pitch de SherpaX. El marco correcto no es "más rápido" sino "un CEO diferente — que puede hacer cosas que antes no podía hacer".

* **gen-dictamen**
  * Definición: proceso de captura de pensamiento del CEO en formato stream of consciousness que el Sherpa convierte en materia prima estructurada para el BrainOS y el IntelliBank.
  * Flujo: stream of consciousness → gen-dictamen → insights estructurados → BrainOS/IntelliBank.
  * Uso: método principal de carga de contexto inicial y captura de pensamiento no estructurado.

* **CLAUDE.md**
  * Definición: archivo de inicialización del Sherpa IA dentro de Claude Cowork. Claude lo lee automáticamente al inicio de cada sesión — es el "sistema de arranque" de SherpaX en la plataforma.
  * Contenido típico: identidad del Sherpa, protocolo de bienvenida, instrucciones de uso del BrainOS, MetaPlaybooks disponibles, principios de operación.
  * Uso técnico: mecanismo nativo de Cowork para inicializar contexto sin configuración del cliente.

* **Ignition Program**
  * Definición: programa de onboarding de SherpaX — las primeras semanas de trabajo donde se construye el BrainOS inicial, se calibra el Sherpa IA y se instalan las capacidades base del CEO.
  * Precio: tier de entrada al ecosistema SherpaX.
  * Proceso: instalación técnica (BrainOS + CLAUDE.md) + sesión de identidad + carga inicial del BrainOS + configuración de MetaPlaybooks base.

---

### **Operación del Launch**

* **Pilot Cycle (Piloto)**  
  * Definición: primera corrida end‑to‑end con logging completo.  
  * Uso: prueba del sistema, no del ego.  
* **Freeze (Congelar)**  
  * Definición: declarar estable una versión (v0.1) y prohibir cambios ad‑hoc.  
  * Uso: cambios posteriores van a v0.2.  
* **Scope (Alcance)**  
  * Definición: lo que este room sí hace (arranque+orden+piloto) y lo que no.  
  * Regla: no se diseña “20 cosas nuevas” aquí.  
* **\[OPEN\]**  
  * Definición: marcador explícito de información faltante.  
  * Regla: se permite, pero debe tener Next\_Action para cerrarse.

---

## **3\) Reglas de uso del glosario**

* Si un término se usa en una discusión y no está aquí → se agrega antes de tomar decisiones.  
* Si dos personas entienden un término distinto → se detiene (stop‑the‑line semántico) y se redefine.  
* Todo lo importante debe poder mapearse a:  
  * una fila del Registry Master  
  * una tarea en Backlog  
  * una corrida en RunLog

---

## **4\) Checklist rápido (para nuevos miembros)**

* ¿Qué es un asset y cómo se identifica?  
* ¿Qué significa Track A vs Track B?  
* ¿Qué es WIP y cuándo se activa stop‑the‑line?  
* ¿Cuáles son las estaciones del pipeline?  
* ¿Cómo se registra evidencia (RunLog)?

Si alguien no puede responder estas 5 preguntas, todavía no está listo para operar.

##