## Asset Header

- **Asset ID:** MePB-BMF-IntelliBanks-DomainMetaFactory-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** MePB — MetaPlaybook
- **Propósito:** IntelliBank — Domain MetaFactory para la gestión de activos cognitivos
- **Última actualización:** 2026-04-11

---

# IntelliBank — Domain MetaFactory para la gestión de activos cognitivos
## MPB-INTELLIBANK-DomainMetaFactory-v01

---

## 0. Asset header

**Asset ID:** MPB-INTELLIBANK-DomainMetaFactory-v01
**Título:** IntelliBank — Domain MetaFactory para gestión de activos cognitivos (L2)
**Versión:** v0.1
**Estado:** Draft
**Owner:** Victor Heredia
**Project Class:** BIG METAFACTORY (L2)
**Tipo taxonómico:** Type D — Domain MetaFactory MetaPlaybook
**Dominio:** Gestión de activos cognitivos
**Hereda de:** BMF-MPB-Kernel-v01 (L0), MPB-OF-MPB-MetaPlaybookOfMetaPlaybooks-v01 (L0.5), MFB-MPB-MetaFactoryBuilder-v01 (L1)
**Complementa a:** MPB-SKILLS-DomainMetaFactory-v01 (L2, dominio Skills) — aquel define cómo se construyen skills; este define dónde viven, cómo se gobiernan y cómo acumulan valor todos los activos cognitivos, incluyendo skills
**Fuentes:** SHA-ConceptoIntelliBank-v01, NJ-Skills-Como-Infraestructura-Cognitiva-v01 (principio "skills compound, prompts evaporate"), input directo de Victor Heredia (2026-03-30)
**Audiencia primaria:** Arquitectos de dominio, operadores de SherpaX, CEOs construyendo su IntelliBank

---

## 0.1 Propósito

Definir la arquitectura canónica del IntelliBank: el contenedor donde viven, se actualizan, se versionan y se gobiernan los activos cognitivos de una persona o una organización.

El IntelliBank no es un repositorio pasivo de archivos. Es un sistema activo que hace que cada activo cognitivo sea encontrable, conectado con otros activos, versionado, y recuperable en contexto cuando se necesita — por un humano o por un agente.

## 0.2 Scope

**In scope:**
- Qué es un activo cognitivo y qué tipos existen (taxonomía de activos)
- Cómo se ingresa un activo al IntelliBank (pipeline de ingesta y validación)
- Cómo se almacenan, indexan, tagean y versionan los activos
- El sistema de badge ⬡ y niveles de madurez
- Cómo se recuperan activos en contexto (para humanos y para agentes)
- El ciclo de vida completo: ingesta → validación → acumulación → conexión → recuperación → deprecación
- La diferencia entre IntelliBank personal e IntelliBank organizacional
- Las interfaces con BrainOS, Skills, EmpowerTeamX, SherpaX

**Out of scope:**
- Cómo se construyen skills (pertenece a MPB-SKILLS-DomainMetaFactory-v01)
- Cómo se construyen MetaPlaybooks (pertenece a MFB-MPB-MetaFactoryBuilder-v01)
- Procedimientos operativos día a día de gestión del IntelliBank (pertenece a un Type E, L3)
- La arquitectura constitucional del ecosistema (pertenece al Kernel, L0)
- Memoria personal del CEO — contexto, historia, voz (pertenece a BrainOS)

## 0.3 Non-negotiables

- El IntelliBank almacena inteligencia procesada, no información cruda
- Todo activo en el IntelliBank tiene identidad: Asset ID, versión, tipo, estado, owner
- El badge ⬡ es binario — se tiene o no se tiene. No hay "casi validado"
- Los activos se versionan — cada actualización genera una nueva versión, no un reemplazo silencioso
- El IntelliBank es transferible — puede compartirse con el equipo, con agentes, o ser heredado cuando el CEO se va
- Herencia del Kernel explícita — INV-01 a INV-07 aplican
- Un activo sin registro en el IntelliBank es un activo huérfano (INV-06)

---

## 1. Orientación

### 1.1 Qué es el IntelliBank

El IntelliBank es el **contenedor gobernado donde viven los activos cognitivos** de una persona o una organización. Es a la inteligencia destilada lo que un banco es al capital: no solo guarda — organiza, protege, conecta, y hace disponible cuando se necesita.

Un activo cognitivo fuera del IntelliBank es como dinero debajo del colchón: existe pero no acumula, no se conecta con nada, y se pierde fácilmente. Un activo dentro del IntelliBank es capital cognitivo invertido: crece con cada conexión, se versiona con cada mejora, y está disponible para cualquier agente o humano que lo necesite.

> El IntelliBank no guarda información. Guarda inteligencia ya procesada — lista para ser aplicada.

### 1.2 La distinción fundamental: IntelliBank vs. BrainOS

Son dos capas complementarias que no deben confundirse:

| Dimensión | BrainOS | IntelliBank |
|-----------|---------|-------------|
| **Qué almacena** | Memoria personal: contexto, historia, voz, criterio, identidad | Activos de inteligencia: frameworks, skills, MetaPlaybooks, síntesis, modelos validados |
| **Origen** | Lo que el CEO ha vivido, pensado y decidido | Lo que el CEO (o la organización) ha aprendido, curado y validado como reutilizable |
| **Acceso típico** | "¿Qué decidimos sobre esto? ¿Cómo suena nuestra voz?" | "¿Qué frameworks aplican aquí? ¿Tenemos un skill para esto? ¿Qué dice nuestro MetaPlaybook?" |
| **Transferibilidad** | Personal — no se transfiere (es la identidad del CEO) | Transferible — se comparte con equipo, agentes, sucesores, clientes |
| **Crecimiento** | Orgánico — crece con cada sesión de trabajo | Curado — crece cuando se valida y destila inteligencia nueva con badge ⬡ |
| **Naturaleza** | Es quién eres | Es qué sabes y cómo operas |

**La regla simple:** Si lo pierdes y necesitas reconstruir la identidad, es BrainOS. Si lo pierdes y necesitas reconstruir la capacidad operativa, es IntelliBank.

### 1.3 Por qué el IntelliBank es necesario ahora

El principio que lo fundamenta todo: **la inteligencia acumula donde la información se evapora.**

Sin IntelliBank, cada conversación con IA que termina se lleva el contexto. Cada framework descubierto vive en una nota suelta. Cada MetaPlaybook vive en una carpeta sin conexión con los demás. Cada skill vive en un archivo sin versión ni registro. La expertise del CEO está dispersa en 47 carpetas, 12 apps, y la cabeza de 5 personas — ninguna de las cuales tiene la imagen completa.

Con IntelliBank, toda esa inteligencia está gobernada:
- Cada activo tiene identidad (Asset ID, versión, tipo, estado)
- Cada activo está clasificado por tipo y nivel de madurez
- Cada activo es recuperable en contexto por humanos y agentes
- Cada actualización es versionada — nada se pierde silenciosamente
- Cada activo está conectado con los demás — el framework de hace seis meses enriquece la decisión de hoy

**El efecto compuesto:** Cada activo que entra al IntelliBank aumenta el valor de todos los demás. Esto es "connect the dots" de Steve Jobs — pero sistemático, deliberado y operativo. Es el mecanismo concreto detrás de la continuidad cognitiva que define a SherpaX.

### 1.4 IntelliBank personal vs. IntelliBank organizacional

El IntelliBank aplica a dos escalas:

**IntelliBank personal (para un CEO o practitioner):**
- Contiene los activos cognitivos de una persona
- Es el equivalente de tu "biblioteca de criterio destilado"
- Lo construyes con SherpaX a lo largo del tiempo
- Es vendible como producto (MetaPlaybooks como activo comercial)
- Ejemplo: El IntelliBank de Victor contiene el MetaPlaybook de Rebelocity, los skills de SherpaX Ignition, los frameworks de monetización, las síntesis de lecturas clave

**IntelliBank organizacional (para una empresa o equipo):**
- Contiene los activos cognitivos de la organización
- Es la inteligencia institucional que trasciende a las personas
- Se construye con la contribución de múltiples practitioners
- Sobrevive a la rotación de personal — cuando alguien se va, su conocimiento queda
- Ejemplo: El IntelliBank de EmpowerLabs contiene los skills de Tier 1 (marca, formato), los MetaPlaybooks de dominio, los frameworks de venta validados

**La diferencia de gobierno:** Un IntelliBank personal tiene un owner (el CEO). Un IntelliBank organizacional tiene un steward (el arquitecto del ecosistema) y múltiples contributors.

---

## 2. Definiciones canónicas del dominio

### 2.1 Términos del dominio

**Activo cognitivo:** Cualquier unidad de inteligencia procesada que ha sido formalizada, validada, y registrada como reutilizable. Los activos cognitivos son el contenido del IntelliBank. Un activo cognitivo no es un archivo — es un archivo con identidad, tipo, versión, estado, y contexto de uso.

**Tipos de activos cognitivos:**

| Tipo | Qué es | Ejemplo |
|------|--------|---------|
| **MetaPlaybook** | Sistema canónico de restricciones operativas con herencia y gobernanza | MPB-SKILLS-DomainMetaFactory-v01 |
| **Playbook** | Guía operativa para un proceso específico sin la formalidad de gobernanza de un MPB | Playbook de onboarding de clientes |
| **Skill** | Metodología codificada en formato ejecutable por agentes (SKILL.md) | SKILL_METAPLAYBOOK_OPS |
| **Framework** | Modelo mental o estructura de pensamiento codificada | Framework ROI 3D de SherpaX |
| **Síntesis** | Conocimiento externo procesado y adaptado al contexto del owner | NJ-Skills-Como-Infraestructura-Cognitiva-v01 |
| **Template** | Estructura reutilizable para producir un tipo específico de output | Template de caso de transformación |
| **Prompt calibrado** | Instrucción probada y optimizada para un resultado específico | Transfer Prompt de Ecosystem Map |
| **Decisión destilada** | Registro de una decisión estratégica con su razonamiento completo | Decisión de priorizar MasterPlaybooks sobre marca personal |
| **Lección aprendida** | Insight validado por experiencia — qué funcionó, qué no, y por qué | "La continuidad cognitiva vende más que la velocidad" |

**Badge ⬡ (IntelliBank):** Marca que indica que un activo ha sido validado como inteligencia reutilizable. El badge es binario — se tiene o no. Indica: el activo fue revisado, cumple estándares de calidad, es recuperable en contexto, y está disponible para agentes y equipo.

**Ingesta:** El proceso por el cual un activo entra al IntelliBank. No es un copy-paste — es una validación que verifica identidad, tipo, calidad, y relevancia antes de otorgar el badge ⬡.

**Recuperación contextual:** La capacidad de encontrar y activar un activo del IntelliBank en el momento en que es relevante para una tarea, decisión o conversación. No es búsqueda por keyword — es activación por contexto semántico.

**Deprecación:** El proceso formal de retirar un activo del IntelliBank cuando ya no es relevante, ha sido reemplazado por una versión superior, o contiene información obsoleta. Un activo deprecado no se borra — se marca como deprecado con fecha y razón.

**Efecto compuesto:** La propiedad del IntelliBank donde cada activo nuevo aumenta el valor de los activos existentes al crear conexiones y enriquecer el contexto disponible. Es el mecanismo concreto detrás de "skills compound."

### 2.2 Términos heredados del Kernel

Los siguientes se usan con su definición canónica del Kernel (BMF-MPB-Kernel-v01, Sección 2.1): Asset, Run, Defect, Change, Control Plane, Invariant, Pipeline, QA, Station.

---

## 3. Arquitectura del IntelliBank

### 3.1 El modelo de capas

```
┌─────────────────────────────────────────────────────────┐
│                    CAPA DE ACCESO                        │
│   Recuperación contextual · Búsqueda · Activación       │
│   (humanos y agentes consultan aquí)                     │
├─────────────────────────────────────────────────────────┤
│                    CAPA DE CONEXIÓN                      │
│   Tags · Relaciones entre activos · Clusters temáticos  │
│   (lo que hace que 1+1 = 3)                             │
├─────────────────────────────────────────────────────────┤
│                    CAPA DE GOBERNANZA                    │
│   Versionado · Badge ⬡ · Estados · Deprecación          │
│   (lo que mantiene la calidad)                           │
├─────────────────────────────────────────────────────────┤
│                    CAPA DE ALMACENAMIENTO                │
│   Activos con identidad · Registro · Índice             │
│   (lo que hace que nada se pierda)                       │
└─────────────────────────────────────────────────────────┘
```

**Capa de almacenamiento:** Cada activo tiene Asset ID, tipo, versión, estado, owner. Existe un registro (índice) que es la fuente de verdad de qué activos existen. Un activo sin registro es un activo huérfano.

**Capa de gobernanza:** Cada activo tiene un estado de madurez (Sección 3.3). Las actualizaciones generan nuevas versiones. El badge ⬡ se otorga o se revoca. Los activos obsoletos se deprecan formalmente.

**Capa de conexión:** Los activos no viven aislados — están tageados y relacionados. Un skill de análisis competitivo está conectado con el framework de evaluación de mercado y con la síntesis de inteligencia competitiva. Cuando se recupera uno, los relacionados están disponibles.

**Capa de acceso:** Humanos y agentes consultan el IntelliBank. La recuperación es contextual — no buscan por nombre de archivo sino por relevancia para la tarea en curso.

### 3.2 Estructura de organización

```
IntelliBank/
├── registry/
│   └── ASSET_REGISTRY.md          ← índice maestro de todos los activos
├── metaplaybooks/                  ← activos Type MPB
├── playbooks/                      ← guías operativas
├── skills/                         ← SKILL.md ejecutables
├── frameworks/                     ← modelos mentales codificados
├── synthesis/                      ← conocimiento externo procesado
├── templates/                      ← estructuras reutilizables
├── prompts/                        ← prompts calibrados y verificados
├── decisions/                      ← decisiones destiladas con razonamiento
├── lessons/                        ← lecciones aprendidas validadas
└── deprecated/                     ← activos retirados (no borrados)
```

La estructura puede adaptarse por contexto (más carpetas, subcarpetas por dominio), pero la regla es: **cada tipo de activo cognitivo tiene su lugar, y el registro es la fuente de verdad.**

### 3.3 Estados de madurez de un activo

Todo activo en el IntelliBank tiene un estado de madurez que refleja su nivel de validación y confiabilidad:

```
DRAFT → VALIDATED → BADGED ⬡ → HARDENED → DEPRECATED
```

| Estado | Significado | Quién puede usarlo | Badge |
|--------|------------|--------------------|----|
| **Draft** | Existe, tiene identidad, pero no ha sido validado. Puede contener errores o estar incompleto | Owner solamente | No |
| **Validated** | Ha sido revisado y cumple los estándares mínimos de calidad para su tipo | Owner y equipo cercano | No |
| **Badged ⬡** | Ha sido validado como inteligencia reutilizable. Es confiable para ser consultado por agentes y equipo | Todos — humanos y agentes | ⬡ |
| **Hardened** | Ha sido usado en producción real al menos 3 veces sin producir defectos. Es la referencia de confianza | Todos — referencia autoritativa | ⬡+ |
| **Deprecated** | Ya no es relevante o ha sido reemplazado. Se mantiene para referencia histórica pero no se activa | Solo para consulta histórica | ✗ |

**Regla de progresión:** La progresión es lineal y no se salta. Un activo no puede ser Badged ⬡ sin haber sido Validated primero. Un activo Hardened tiene evidencia de uso en producción.

### 3.4 El registro (Asset Registry)

El registro es el índice maestro del IntelliBank — la fuente de verdad de qué activos existen, en qué estado están, y dónde viven.

**Campos requeridos por entrada:**

| Campo | Descripción |
|-------|-------------|
| Asset ID | Identificador único |
| Tipo | MetaPlaybook / Playbook / Skill / Framework / Síntesis / Template / Prompt / Decisión / Lección |
| Versión | Versión actual (vN.N) |
| Estado | Draft / Validated / Badged ⬡ / Hardened / Deprecated |
| Owner | Persona responsable |
| Dominio | Área temática (Publishing, Consulting, Eventos, etc.) o "Transversal" |
| Tags | Palabras clave para conexión y recuperación |
| Fecha creación | Cuándo entró al IntelliBank |
| Última actualización | Cuándo se modificó por última vez |
| Ubicación | Path del archivo |
| Relaciones | IDs de activos conectados |

**Un activo que no está en el registro no existe para el IntelliBank.** Puede existir como archivo, pero no es un activo cognitivo gobernado hasta que tiene entrada en el registro.

**Gobernanza del registro mismo:**

- **Quién escribe:** El owner (IntelliBank personal) o el steward designado (IntelliBank organizacional). Los agentes no modifican el registro directamente — proponen entradas que el owner/steward aprueba.
- **Versionado del registro:** El archivo ASSET_REGISTRY.md se versiona junto con el IntelliBank. Cada cambio al registro (nueva entrada, actualización de estado, deprecación) genera un commit o timestamp con descripción del cambio.
- **Audit trail:** El registro mantiene un log de cambios al final del archivo (o en archivo separado REGISTRY_CHANGELOG.md) con formato: `[fecha] | [acción: add/update/deprecate] | [Asset ID] | [descripción breve] | [quién]`. Esto cumple INV-02 (Control Plane auditability).
- **Revisión periódica:** Al menos una vez al mes (o según cadencia definida en el Type E Operations cuando exista), el owner verifica: ¿hay activos huérfanos (archivos sin entrada en registro)? ¿Hay entradas fantasma (registro sin archivo correspondiente)? ¿Hay activos Draft sin progreso en 30+ días?

---

## 4. Pipeline de ingesta y validación

### 4.1 De dónde vienen los activos

Los activos cognitivos no se crean directamente en el IntelliBank. Se crean en contextos de trabajo y luego se ingresan al IntelliBank cuando demuestran valor reutilizable.

**Fuentes de activos:**

| Fuente | Ejemplo | Frecuencia |
|--------|---------|------------|
| Sesiones de trabajo con SherpaX/Jay | Un framework descubierto en conversación, un skill construido, una síntesis de un video | Alta — cada sesión puede producir candidatos |
| Factorías del ecosistema BMF | MetaPlaybooks producidos, skills generados por el pipeline de skills | Media — por ciclo de producción |
| Lecturas y fuentes externas | Síntesis de libros, artículos, videos procesados al contexto del owner | Variable |
| Experiencia operativa | Lecciones aprendidas, decisiones destiladas con su razonamiento | Continua |
| Importación de terceros | Skills de marketplaces, frameworks de consultorías, templates de industria | Ocasional |

### 4.2 El pipeline de ingesta

No todo lo que se produce merece entrar al IntelliBank. La ingesta es un proceso de curaduría, no un volcado automático.

**Test de ingesta (las 3 preguntas):**

1. **¿Es reutilizable?** Si solo sirve para esta situación específica y nunca más, no es un activo cognitivo — es un entregable. Los entregables viven en las carpetas de proyecto, no en el IntelliBank.

2. **¿Está destilado?** La inteligencia cruda (notas sueltas, transcripciones sin procesar, datos sin analizar) no entra al IntelliBank. Debe estar procesada — convertida en framework, skill, síntesis, o decisión destilada.

3. **¿Tiene identidad?** Si no tiene Asset ID, tipo, versión, y owner, no está listo para entrar. La identidad es el requisito mínimo de gobernanza.

Si las tres respuestas son sí, el activo es candidato a ingesta.

---

## 5. El sistema de conexión

### 5.1 Por qué la conexión importa más que el almacenamiento

Un IntelliBank con 200 activos aislados es una biblioteca desordenada. Un IntelliBank con 200 activos conectados es un sistema de inteligencia.

La conexión es lo que produce el efecto compuesto: el framework de evaluación de mercado enriquece el skill de análisis competitivo, que enriquece el MetaPlaybook de strategy, que informa la decisión sobre sponsors de Rebelocity. Sin conexiones, cada activo está solo. Con conexiones, cada consulta trae profundidad.

### 5.2 Mecanismos de conexión

**Tags semánticos:** Cada activo tiene tags que lo conectan con temas, dominios, y conceptos. Los tags no son categorías rígidas — son puntos de conexión semántica.

Ejemplo de tags para un skill de análisis competitivo:
`[análisis-competitivo, estrategia, mercado, evaluación, framework-5-fuerzas, tier-2]`

**Relaciones explícitas:** Cada activo declara en su registro con qué otros activos está relacionado. Las relaciones son tipadas:

| Tipo de relación | Significado | Ejemplo |
|-----------------|------------|---------|
| **depends-on** | Este activo necesita al otro para funcionar | Skill de análisis → Framework de evaluación |
| **extends** | Este activo profundiza o amplía al otro | MetaPlaybook v02 → MetaPlaybook v01 |
| **complements** | Ambos se enriquecen mutuamente sin dependencia | Síntesis de Nate Jones ↔ MetaPlaybook de Skills |
| **supersedes** | Este activo reemplaza al otro (el otro se depreca) | Framework v2 → Framework v1 |
| **derived-from** | Este activo se generó a partir del otro | Skill de Rebelocity → MetaPlaybook de Rebelocity |

**Clusters temáticos:** Grupos de activos que orbitan alrededor de un tema o proyecto. No es una carpeta — es una vista virtual que agrupa activos de diferentes tipos por relevancia temática.

Ejemplo de cluster "Estrategia de Eventos Premium":
- MetaPlaybook de Rebelocity (MPB)
- Skill de viabilidad de sponsors (Skill)
- Framework de arquitectura de sponsors (Framework)
- Decisión de no-go con sponsors que no cumplen criterio (Decisión)
- Lección sobre pricing de L'Étape (Lección)

### 5.3 Recuperación contextual

La recuperación no es búsqueda — es activación por contexto.

**Para humanos:** "Estoy preparando una propuesta para un sponsor nuevo" → el IntelliBank activa: Framework de arquitectura de sponsors + Skill de viabilidad + Lecciones sobre sponsors previos + Decisiones de criterio de filtro.

**Para agentes:** Un agente de EmpowerTeamX recibe la tarea "evalúa a este sponsor potencial" → consulta el IntelliBank → carga el skill relevante + el framework de evaluación + las lecciones previas → produce un output calibrado al criterio del CEO.

**Lo que diferencia al IntelliBank de una carpeta de archivos:** La carpeta requiere que sepas el nombre del archivo. El IntelliBank activa lo relevante basándose en el contexto de la tarea.

---

## 6. Ciclo de vida completo de un activo

```
CREACIÓN (fuera del IB)
    ↓
INGESTA (test de 3 preguntas)
    ↓ pasa?
    ├── NO → queda como entregable de proyecto, no entra al IB
    └── SÍ ↓
REGISTRO (Asset ID + tipo + versión + owner + tags + relaciones)
    ↓
ESTADO: DRAFT
    ↓ revisión de calidad
ESTADO: VALIDATED
    ↓ validación por owner como inteligencia reutilizable
ESTADO: BADGED ⬡
    ↓ uso en producción real (3+ veces sin defectos)
ESTADO: HARDENED ⬡+
    ↓ (eventualmente)
ESTADO: DEPRECATED — cuando es reemplazado u obsoleto
    → movido a deprecated/ con fecha y razón
    → relación "superseded-by" con el activo que lo reemplaza
```

**La regla de versionado:** Toda actualización a un activo Badged ⬡ o Hardened genera una nueva versión (minor para ajustes, major para cambios de significado). La versión anterior se mantiene accesible. El registro se actualiza. Esto es lo que permite la trazabilidad — puedes ver cómo evolucionó un framework desde v0.1 hasta v2.3.

### 6.1 Ejemplo concreto: Journey del Framework ROI 3D de SherpaX

Este ejemplo traza un activo real desde su creación hasta estado Badged ⬡, pasando por cada estación.

**Estación 1 — Detección:**
Durante una sesión de trabajo con Jay (2026-03-22), Victor articula que el ROI de SherpaX tiene tres dimensiones: velocidad, nueva capacidad, y antes imposible. Jay reconoce el patrón como framework candidato.

- Test de 3 preguntas: ¿Es reutilizable? Sí — aplica a cualquier demo de SherpaX. ¿Está destilado? Sí — las 3 dimensiones están articuladas con criterio. ¿Tiene identidad? Todavía no → pasa a Formalización.
- Gate: PASS.

**Estación 2 — Formalización:**
Se crea el activo con identidad completa:

```
Asset ID: FWK-SHERPAX-ROI3D-v01
Tipo: Framework
Versión: v0.1
Estado: Draft
Owner: Victor Heredia
Dominio: SherpaX / Consultoría
Tags: [roi, ventas, sherpax, demo, propuesta-de-valor]
```

Contenido estructurado: las 3 dimensiones definidas con ejemplos para cada una.
- Gate: Identidad completa + estructura del tipo cumplida = PASS.

**Estación 3 — Validación:**
QA verifica contra rúbrica de Framework (Sección 7.2): ¿Internamente consistente? Sí. ¿Falsificable? Sí — aplica solo a productos de SherpaX, no a cualquier servicio. ¿Probado en al menos 1 contexto? Sí — usado en la sesión con Litos (2026-03-29). ¿Componentes identificables? Sí — 3 dimensiones claras.
- Gate: PASS. Estado → Validated.

**Estación 4 — Badging:**
Victor revisa el framework Validated y confirma: "Este es criterio destilado que quiero que cualquier agente o sesión futura use cuando hable de valor de SherpaX." Se otorga badge ⬡.
- Entrada completa en Asset Registry:

| Campo | Valor |
|-------|-------|
| Asset ID | FWK-SHERPAX-ROI3D-v01 |
| Tipo | Framework |
| Versión | v0.1 |
| Estado | Badged ⬡ |
| Owner | Victor Heredia |
| Dominio | SherpaX |
| Tags | roi, ventas, sherpax, demo, propuesta-de-valor |
| Fecha creación | 2026-03-22 |
| Última actualización | 2026-03-29 |
| Ubicación | IntelliBank/frameworks/FWK-SHERPAX-ROI3D-v01.md |
| Relaciones | complements: MPB-SHERPAX-IGNITION; derived-from: proyecto-sherpax-roi-framework |

- Gate: PASS. Estado → Badged ⬡.

**Estación 5 — Conexión:**
Relaciones tipadas declaradas:
- `complements` → MPB-SHERPAX-IGNITION (lo usa en demos)
- `derived-from` → sesión de trabajo 2026-03-22
- `complements` → FWK-CONTINUIDAD-COGNITIVA (argumento complementario)

Cluster asignado: "SherpaX — Propuesta de valor y ventas"
- Gate: ≥1 relación explícita = PASS.

**Estación 6 — Mantenimiento (futuro):**
Si después de usar el framework en 5 demos se descubre que la dimensión "antes imposible" necesita subdividirse en "antes imposible individual" y "antes imposible organizacional", se hace version bump a v0.2 con ChangeLog documentado.

> Este ejemplo demuestra que el IntelliBank no es teórico — es un sistema por el que pasan activos reales con gates reales.

---

## 7. Estaciones del pipeline de IntelliBank

### 7.1 Archetypes de estación

| Estación | Propósito | Input | Output | Gate |
|----------|-----------|-------|--------|------|
| **Detección** | Identificar candidato a activo cognitivo en contexto de trabajo | Output de sesión, factoría, lectura, o experiencia | Candidato identificado con tipo propuesto y justificación de reutilizabilidad | Las 3 preguntas de ingesta = SÍ → PASS |
| **Formalización** | Dar identidad y estructura al candidato | Candidato bruto + estándar del tipo | Activo con Asset ID, tipo, versión v0.1, owner, estructura completa para su tipo | Identidad completa + estructura del tipo cumplida = PASS |
| **Validación** | Verificar calidad y corrección del contenido | Activo formalizado | Activo en estado Validated con reporte de QA | Contenido correcto + sin conflictos con activos existentes = PASS |
| **Badging** | Otorgar badge ⬡ como inteligencia reutilizable | Activo Validated + aprobación del owner | Activo en estado Badged ⬡ + entrada completa en registro + tags + relaciones | Owner valida como reutilizable + registro completo = PASS |
| **Conexión** | Establecer relaciones con activos existentes | Activo Badged ⬡ + catálogo de activos existentes | Activo con relaciones tipadas + tags semánticos + asignación a cluster(s) | Al menos 1 relación explícita declarada = PASS |
| **Mantenimiento** | Actualizar, versionar o deprecar activos existentes | Trigger de actualización (nuevo conocimiento, defecto detectado, obsolescencia) | Activo actualizado con nueva versión O activo deprecado con razón | Versión bumped + ChangeLog entry = PASS; o deprecación documentada = PASS |

### 7.2 Rúbricas de validación por tipo de activo

La estación Validación (7.1) requiere "contenido correcto" para PASS. Esta sección define qué significa "correcto" para cada tipo de activo cognitivo. Sin estas rúbricas, la validación es subjetiva.

| Tipo de activo | Criterios de validación para PASS |
|----------------|----------------------------------|
| **MetaPlaybook** | Cumple la clasificación Type A-F de MPB-OF-MPB + herencia de Kernel declarada + secciones requeridas presentes según tipo + sin cross-layer leakage |
| **Playbook** | Objetivo claro + pasos ejecutables + audiencia definida + resultado esperado medible + no duplica un MPB existente |
| **Skill** | Estructura SKILL.md válida (metadata + body ≤500 líneas) + description como señal de routing + output como contrato + testeado con al menos 1 ejecución real + sin dependencias rotas |
| **Framework** | Internamente consistente (sin contradicciones) + falsificable (se puede determinar cuándo NO aplica) + probado en al menos 1 contexto real + componentes identificables |
| **Síntesis** | Fuente original citada + procesado al contexto del owner (no es copy-paste) + insight accionable extraído + fecha de vigencia declarada |
| **Template** | Genera output consistente cuando se llena + todos los campos obligatorios marcados + instrucciones de uso incluidas + probado con al menos 1 instancia real |
| **Prompt calibrado** | Resultado esperado definido + probado con al menos 3 ejecuciones + varianza de resultados aceptable + modelo/versión de IA declarados |
| **Decisión destilada** | Contexto de la decisión documentado + opciones consideradas + criterio de selección explícito + resultado observado (si ya ejecutada) |
| **Lección aprendida** | Situación original descrita + qué se esperaba vs. qué ocurrió + insight generalizable extraído + aplicabilidad futura definida |

**Regla:** Si un activo no cumple todos los criterios de su tipo, el gate de Validación es FAIL. El activo regresa a Formalización con los criterios faltantes documentados.

### 7.3 Contratos de artefactos

**Contrato de output del pipeline de ingesta:**

Todo activo que recibe badge ⬡ debe contener:
- Asset ID (formato según convención del tipo)
- Tipo declarado (de la taxonomía de Sección 2.1)
- Versión (vN.N)
- Estado: Badged ⬡
- Owner declarado
- Dominio y tags asignados
- Al menos 1 relación explícita con otro activo del IntelliBank
- Entrada completa en el Asset Registry

---

## 8. Módulos configurables

### 8.1 Template registry del dominio

| Template | Propósito | Formato | Aplicado en |
|----------|-----------|---------|-------------|
| **Asset Registry Entry** | Formato estándar de una entrada en el registro | Markdown (tabla) | Estación Formalización |
| **Ingesta Checklist** | Las 3 preguntas + campos mínimos de identidad | Markdown | Estación Detección |
| **QA Validation Report** | Reporte de validación de calidad por tipo de activo | Markdown | Estación Validación |
| **Badge Request** | Solicitud formal de badge ⬡ con evidencia de reutilizabilidad | Markdown | Estación Badging |
| **Connection Map** | Mapa de relaciones de un activo con otros activos del IntelliBank | Markdown/Visual | Estación Conexión |
| **Deprecation Notice** | Registro formal de deprecación con fecha, razón, y activo sucesor | Markdown | Estación Mantenimiento |
| **Version Bump Log** | Registro de cambio de versión con qué cambió y por qué | Markdown | Estación Mantenimiento |

### 8.2 Módulos por instancia

| Módulo | Propósito | Opciones | Default |
|--------|-----------|----------|---------|
| **Scope** | Alcance del IntelliBank | Personal (1 owner) / Organizacional (múltiples contributors) | Personal |
| **Storage Backend** | Dónde se almacenan físicamente los activos | Obsidian vault / GitHub repo / Carpeta local / Notion / Hybrid | Carpeta local (Reinventaverse) |
| **Registry Format** | Formato del índice maestro | Markdown table / CSV / JSON / Database | Markdown table |
| **Governance Intensity** | Nivel de rigor en la gobernanza | Light (solo registro + badge) / Standard (registro + badge + versioning + connections) / Full (todo + deprecation formal + audit trail) | Standard |
| **Recovery Mechanism** | Cómo se activa la recuperación contextual | Manual (humano busca) / Assisted (agente sugiere) / Automatic (agente carga proactivamente) | Assisted |
| **Access Control** | Quién puede ver y modificar | Owner-only / Team-read / Team-write / Public-read | Owner-only |

---

## 9. Delegation contracts con Factory Builders (L1)

### 9.1 Contrato L2 → L1

Cuando un Factory Builder instancia un IntelliBank para un nuevo CEO o equipo, recibe:

| Artefacto entregado | Contenido |
|---------------------|-----------|
| **Station archetypes** | Las 6 estaciones de Sección 7.1 |
| **Template pack** | Todos los templates de Sección 8.1 |
| **Module defaults** | Configuración inicial de los 6 módulos |
| **Taxonomía de activos** | Los 9 tipos de activos cognitivos con definiciones |
| **Estados de madurez** | El modelo Draft → Validated → Badged ⬡ → Hardened → Deprecated |

### 9.2 Contrato L1 → L2

El Builder debe producir:

| Artefacto requerido | Criterio de aceptación |
|---------------------|----------------------|
| **IntelliBank instanciado** | Estructura de carpetas creada, registro inicializado, módulos configurados |
| **Seed pack** | Al menos 5 activos cognitivos del owner ya ingresados, formalizados, y registrados como seed inicial (ver criterios abajo) |
| **Pilot ingesta** | 1 activo nuevo ingresado end-to-end (detección → badge ⬡) con evidencia documentada |
| **Owner trained** | El owner puede ingresar un activo nuevo sin asistencia del Builder |

**Criterios del seed pack:**

1. **Selección:** Elegir activos que el owner ya usa en su trabajo cotidiano — no los más ambiciosos, sino los más usados. Priorizar diversidad de tipos (no 5 frameworks; idealmente 2-3 tipos distintos).
2. **Calidad mínima:** Todos los activos del seed deben alcanzar al menos estado Validated. Al menos 2 de los 5 deben llegar a Badged ⬡ durante el proceso de seed.
3. **Timeline:** El seed pack se completa dentro de las primeras 2 semanas del Build. Si a los 14 días no hay 5 activos Validated, escalar al L2.
4. **Conexión mínima:** Al menos 3 de los 5 activos del seed deben tener al menos 1 relación explícita entre ellos. Esto demuestra que el sistema de conexión funciona desde el día 1.

**Protocolo de handoff (Builder → Owner):**

| Paso | Acción | Evidencia requerida |
|------|--------|---------------------|
| 1 | Builder presenta el IntelliBank instanciado al owner | Walkthrough documentado de la estructura |
| 2 | Builder ejecuta la pilot ingesta con el owner observando | Asset ingresado end-to-end + registro actualizado |
| 3 | Owner ejecuta una ingesta asistida (Builder observa) | Asset ingresado por el owner con coaching |
| 4 | Owner ejecuta una ingesta sin asistencia | Asset ingresado por el owner sin intervención del Builder |
| 5 | Builder valida que el registro, tags, y relaciones del asset del paso 4 son correctos | QA report del Builder |
| 6 | Handoff formal: Builder documenta estado del IntelliBank y entrega al owner | Documento de entrega con: # activos, configuración de módulos, gaps conocidos |

**Gate de handoff completado:** El owner puede articular en 2 minutos: qué es el IntelliBank, dónde está el registro, cómo ingresa un activo nuevo, y qué tipos de activos tiene. Si no puede → handoff incompleto → el Builder continúa.

### 9.3 Escalación

- Ambigüedad en tipo de activo → escalación a este MetaPlaybook para clarificación
- Conflicto entre activos existentes → escalación al owner para resolución
- Módulo no contemplado → propuesta documentada con justificación

---

## 10. Interfaces con otros componentes del ecosistema

### 10.1 Interface con BrainOS

**BrainOS → IntelliBank:**
- BrainOS alimenta el contexto personal que enriquece los activos del IntelliBank
- La voz del CEO en BrainOS informa cómo se expresan las síntesis y frameworks
- Las decisiones registradas en BrainOS son candidatas a destilarse como activos en IntelliBank

**IntelliBank → BrainOS:**
- Los activos del IntelliBank enriquecen la memoria operativa del BrainOS
- Cuando Jay necesita profundidad, consulta IntelliBank antes de responder genéricamente

**La regla de separación:** BrainOS es quién eres. IntelliBank es qué sabes. No se mezclan.

### 10.2 Interface con MPB-SKILLS (dominio Skills)

**MPB-SKILLS → IntelliBank:**
- Los skills producidos por el pipeline de skills son candidatos a ingesta en IntelliBank
- Todo skill que pasa QA en MPB-SKILLS puede ser propuesto para badge ⬡

**IntelliBank → MPB-SKILLS:**
- La fase de Extracción de MPB-SKILLS consulta IntelliBank para identificar frameworks y criterio existente
- Los skills en IntelliBank informan qué gaps existen (qué áreas no tienen skills aún)

### 10.3 Interface con EmpowerTeamX

- Los agentes L1 consultan el IntelliBank antes de ejecutar tareas
- Solo activos Badged ⬡ o Hardened son consultables por agentes
- Los agentes no modifican el IntelliBank — solo lo consultan

### 10.4 Interface con SherpaX (producto comercial)

- Cada sesión de SherpaX es una fuente de candidatos a activos cognitivos
- SherpaX Ignition incluye la construcción del IntelliBank seed (primeros 5-10 activos)
- El IntelliBank del CEO es el argumento de continuidad cognitiva más poderoso en demos
- "¿Ves este framework que construimos hace tres meses? Está enriqueciendo la decisión que estamos tomando hoy."

### 10.5 Interface con MasterPlaybooks (plataforma)

- Los MetaPlaybooks del IntelliBank del CEO son la fuente de los productos de MasterPlaybooks
- Un MetaPlaybook con badge ⬡+ (Hardened) en el IntelliBank es candidato a ser productizado para la plataforma
- La transferencia de IntelliBank → MasterPlaybooks es un proceso de empaquetado (L4) que no modifica el activo original

---

## 11. QA de este MetaPlaybook

### 11.1 Distinción

La Sección 7 define cómo se validan los activos que entran al IntelliBank. Esta sección define cómo se evalúa este MetaPlaybook mismo como documento de gobernanza Type D.

### 11.2 QA hard gate

**Structural QA:**
- [ ] Todas las secciones universales requeridas presentes
- [ ] Todas las secciones Type D presentes (domain declaration, inheritance, stations, artifact registry, module registry, template registry, delegation contracts, QA extensions, Control Plane hooks)
- [ ] Asset Header completo
- [ ] Inheritance stack declarado explícitamente
- [ ] Scope in/out definidos con ownership mapping

**Semantic QA:**
- [ ] Sin cross-layer leakage
- [ ] Definiciones no conflictúan con Kernel ni con MPB-SKILLS
- [ ] Contenido prohibido para Type D ausente
- [ ] Boundaries con BrainOS claramente definidos (Sección 1.2)
- [ ] Boundaries con MPB-SKILLS claramente definidos (Sección 10.2)

### 11.3 Definition of Done

**Trainable:** Un CEO o arquitecto que lea este MetaPlaybook puede entender qué es el IntelliBank, qué tipos de activos contiene, cómo se ingresan, cómo se gobiernan, y cómo se conectan entre sí — sin preguntar.

**Enforceable:** Las reglas producen PASS o FAIL. Si un activo no tiene Asset ID, es FAIL. Si no pasó las 3 preguntas de ingesta, es FAIL. Si se otorgó badge ⬡ sin validación previa, es FAIL.

**Escenarios de prueba (si la respuesta es determinista, el MetaPlaybook funciona):**

1. *Un consultor envía al CEO una transcripción sin procesar de una entrevista y dice "agrégala al IntelliBank."* → Respuesta esperada: FAIL en la pregunta 2 (¿Está destilado?). No entra hasta que se procese en una síntesis con insight accionable.

2. *Un agente de EmpowerTeamX pide el framework de evaluación de sponsors para preparar un análisis.* → Respuesta esperada: el agente recibe solo activos Badged ⬡ o Hardened. Si el framework está en Draft, el agente no lo recibe y se notifica al owner que hay un gap.

3. *Un skill fue creado hace 8 meses, nunca se actualizó, y la herramienta de IA para la que fue diseñado cambió significativamente.* → Respuesta esperada: La revisión periódica del registro lo detecta → se propone deprecación o actualización → se documenta en REGISTRY_CHANGELOG.

4. *El owner quiere dar badge ⬡ a un playbook que acaba de crear ayer porque "es urgente."* → Respuesta esperada: FAIL. La progresión es lineal (Draft → Validated → Badged ⬡). No se salta Validated. La urgencia no es un bypass de gobernanza.

5. *Se descubre que dos frameworks en estado Hardened dan recomendaciones contradictorias para la misma situación.* → Respuesta esperada: Escalación al owner (Sección 9.3). El owner decide cuál prevalece. El otro se actualiza o depreca. Se documenta la decisión como activo tipo "Decisión destilada."

---

## 12. Anti-patterns

### 12.1 El IntelliBank-vertedero

**Patrón:** Todo se mete al IntelliBank sin curaduría. Notas sueltas, transcripciones sin procesar, screenshots, borradores a medio hacer. En 3 meses hay 500 "activos" y ninguno es confiable.

**Por qué falla:** Sin el filtro de las 3 preguntas de ingesta, el IntelliBank se llena de ruido. Los agentes que lo consultan obtienen inteligencia mezclada con basura. La confianza en el sistema se erosiona.

**La cura:** Las 3 preguntas son un gate real, no una formalidad. Si no es reutilizable, no está destilado, o no tiene identidad — no entra.

### 12.2 El IntelliBank-museo

**Patrón:** Los activos entran pero nunca se actualizan ni se deprecan. El framework de 2024 sigue ahí igual aunque el mercado cambió completamente. Nadie revisa si los activos siguen siendo válidos.

**Por qué falla:** Un IntelliBank sin mantenimiento se convierte en un museo de ideas obsoletas que los agentes consultan como si fueran vigentes. Es peor que no tener IntelliBank — porque da falsa confianza.

**La cura:** La estación de Mantenimiento (Sección 7.1) no es opcional. Debe existir un ritual periódico de revisión: ¿qué activos necesitan actualización? ¿Cuáles están obsoletos?

### 12.3 El IntelliBank sin conexiones

**Patrón:** Cada activo tiene su identidad y su badge pero vive aislado. No hay tags, no hay relaciones, no hay clusters. El IntelliBank es una lista de archivos con formato bonito.

**Por qué falla:** Sin conexiones, no hay efecto compuesto. Cada activo aporta valor aislado pero no enriquece a los demás. La recuperación contextual no funciona porque no hay red semántica.

**La cura:** La estación de Conexión es obligatoria. Todo activo Badged ⬡ debe tener al menos 1 relación explícita y tags semánticos. Si no puedes conectarlo con nada existente, pregúntate si realmente pertenece aquí.

### 12.4 El IntelliBank-persona

**Patrón:** Todo el IntelliBank vive en la cabeza del owner o en la de Jay. Si se pierde la sesión o el owner no está, nadie puede encontrar nada.

**Por qué falla:** Es la versión digital del mismo problema que el IntelliBank pretende resolver: expertise atrapada en una persona. Si necesitas al CEO para encontrar un framework, el IntelliBank no está funcionando como sistema.

**La cura:** El registro es la fuente de verdad, no la memoria de nadie. Si no está en el registro, no existe. Si está en el registro, cualquiera puede encontrarlo.

---

## 13. Boundaries y fuera de scope

### 13.1 Lo que este MetaPlaybook no hace

| Tema | Dónde pertenece |
|------|----------------|
| Cómo se construyen skills | MPB-SKILLS-DomainMetaFactory-v01 (L2) |
| Cómo se construyen MetaPlaybooks | MFB-MPB-MetaFactoryBuilder-v01 (L1) |
| Memoria personal del CEO (voz, identidad, historia) | BrainOS (componente separado) |
| Operación día a día del IntelliBank (cadencia, WIP, rituales) | Type E — Operations MetaPlaybook (L3, pendiente) |
| Empaquetado de activos para venta en MasterPlaybooks | Type F — Production MetaPlaybook (L4) |
| Reglas constitucionales del ecosistema | BMF-MPB-Kernel-v01 (L0) |

### 13.2 Siguiente paso recomendado

**Prioridad:** Un Type E Operations MetaPlaybook que defina: con qué frecuencia se revisa el IntelliBank, cómo se detectan activos huérfanos, cuándo se hace maintenance review, y cómo se gestiona el backlog de candidatos a ingesta.

---

## 14. Declaración de herencia

Este MetaPlaybook hereda y cumple:

- **BMF-MPB-Kernel-v01 (L0):** Todas las invariantes INV-01 a INV-07. En particular: INV-02 (Control Plane — el registro es el Control Plane del IntelliBank), INV-03 (QA puede fallar — las 3 preguntas de ingesta y los gates de estación son PASS/FAIL), INV-06 (identidad de asset — todo activo necesita Asset ID, versión, tipo, estado, owner).
- **MPB-OF-MPB (L0.5):** Clasificado como Type D, Layer L2, Domain: Gestión de Activos Cognitivos, Function: MetaFactory, Audience: Arquitecto/CEO/Operador, Risk: Medium.
- **MFB-MPB-MetaFactoryBuilder-v01 (L1):** Sigue el proceso Thinking→Design→Build→Operate. Este documento es el output de la fase Design.

---

*Asset ID: MPB-INTELLIBANK-DomainMetaFactory-v01 | Version: v0.1 | Status: Draft | Owner: Victor Heredia*
*Fuentes: SHA-ConceptoIntelliBank-v01 + NJ-Skills (principio compound) + Input directo Victor 2026-03-30*