## Asset Header
- **Asset ID:** SOP-XX-IntellBank-Build-Process-v01
- **Version:** v01
- **Status:** Active
- **Owner:** Victor Heredia
- **IntellBank:** IB-XX-Maestro
- **Tipo:** SOP — Procedimiento operativo estándar
- **Propósito:** Proceso completo para construir un IntellBank desde cero — para uso interno y para el onboarding de clientes SherpaX. Cubre desde la decisión arquitectónica inicial hasta la configuración del LLM Wiki local del cliente.
- **Última actualización:** 2026-04-11
---

# SOP: Construcción de un IntellBank

> *Un IntellBank no es una carpeta con documentos. Es un sistema de conocimiento con identidad, estructura y semántica. Este SOP describe cómo construirlo correctamente — la primera vez y cada vez.*

---

## Contexto: ¿Por qué existe este SOP?

El error más común al implementar SherpaX con un cliente es tratar el IntellBank como "una carpeta de Obsidian donde guardamos cosas". El resultado: un repositorio desorganizado que nadie mantiene y que no puede alimentar a un agente de IA con contexto real.

Un IntellBank construido correctamente:
- Tiene identidad clara (qué tipo de activos vive aquí)
- Tiene convención de nombres consistente (el agente puede navegar sin ambigüedad)
- Tiene headers de activos en cada documento (el sistema sabe qué es cada cosa)
- Tiene un registry maestro (hay un punto de verdad)
- Puede alimentar un LLM Wiki local (capa semántica consultable por el agente)

Este SOP garantiza ese resultado.

---

## Paso 0 — Decisión arquitectónica: ¿cuántos bancos?

Antes de crear cualquier carpeta, definir cuántos IntelliBanks necesita este cliente.

**Referencia:** La arquitectura de EmpowerLabs tiene 6 bancos separados porque tiene 6 contextos distintos (canonical, operational, editorial, publications, verticals, specific brands). La mayoría de los clientes SherpaX arranca con 1-2 bancos.

### Regla de separación

Crear un banco separado cuando:
- El conjunto de documentos tiene una audiencia o propósito distinto (ej: operativo vs. publicaciones)
- El conjunto necesita permisos de acceso diferenciados en el futuro
- El volumen esperado supera 100 documentos en 12 meses

Empezar con 1 banco consolidado cuando:
- El cliente tiene menos de 50 documentos iniciales
- Todos los documentos sirven al mismo propósito operativo

**Resultado de este paso:** Lista de bancos a crear con nombre y entidad.

### Convención de nombre para un nuevo banco

```
IB-[ENTIDAD]-[NombreDescriptivo]
```

Ejemplos:
- `IB-ABC-MexicoOps` — banco operativo de la empresa ABC
- `IB-JD-JohnDoe` — banco personal de un individuo
- `IB-REB-Rebelocity` — banco de una marca/vertical específica

La `[ENTIDAD]` son 2-4 letras que identifican al cliente o contexto de forma única dentro del ecosistema.

---

## Paso 1 — Crear la estructura de carpetas

Para cada banco definido en el Paso 0, crear la siguiente estructura:

```
IB-[ENTIDAD]-[Nombre]/
├── BC-[ENT]-BrainCodes/          ← Códigos de personas, metodologías, tradiciones
├── BOS-[ENT]-Corp-BrainOS/       ← Configuración del Corp BrainOS (si aplica)
├── CP-[ENT]-Control-Planes/      ← Registry, plan maestro, mapas de activos
├── EQ-[ENT]-Equipo/              ← Perfiles del equipo (si aplica)
└── PB-[ENT]-Project-Bank/        ← Bancos de proyectos activos
    └── PB-[ENT]-[NombreProyecto]/  ← Una subcarpeta por proyecto
```

Subcarpetas opcionales (según el tipo de cliente):
```
├── MF-[ENT]-[NombreFactoría]/    ← Si el cliente usa MetaFactorías
├── FI-[ENT]-[NombreFI]/         ← Instancias de fábricas específicas
└── LW-[ENT]-LLM-Wiki/           ← Si se crea un wiki local (ver Paso 6)
```

**Nota:** No todas las carpetas tienen que estar llenas desde el inicio. La estructura se pre-crea para que el sistema tenga las "habitaciones" definidas y el agente sepa dónde buscar cada tipo de activo.

---

## Paso 2 — Crear el Registry maestro

El primer archivo que existe en cualquier IntellBank es su Registry.

**Nombre:** `CP-[ENT]-[Nombre]-Registry-v01.md`
**Ubicación:** `IB-[ENT]-[Nombre]/CP-[ENT]-Control-Planes/`

### Contenido mínimo del Registry

```markdown
## Asset Header
- **Asset ID:** CP-[ENT]-[Nombre]-Registry-v01
- **Version:** v01
- **Status:** Active
- **Owner:** [Nombre del cliente]
- **IntellBank:** IB-[ENT]-[Nombre]
- **Tipo:** CP — Control Plane / Registry
- **Propósito:** Registry maestro de activos del IntellBank [Nombre].
- **Última actualización:** YYYY-MM-DD
---

# Registry: IB-[ENT]-[Nombre]

## Panel de control

| Métrica | Valor |
|---------|-------|
| Total activos | 0 |
| Última actualización | YYYY-MM-DD |
| Versión | v01 |

## Activos registrados

| Asset ID | Subcarpeta | Tipo | Versión | Status | Notas |
|----------|-----------|------|---------|--------|-------|
| (vacío) | | | | | |

## Convención de nomenclatura
`TIPO-ENTIDAD-Proyecto-NombreDescriptivo-vNN.ext`
El TIPO siempre va primero.

## Historial de versiones
| Versión | Fecha | Cambio |
|---------|-------|--------|
| v01 | YYYY-MM-DD | Creación inicial del registry |
```

---

## Paso 3 — Definir los tipos de documentos del cliente

Antes de cargar cualquier documento, identificar qué tipos de activos producirá este cliente y mapearlos a los prefijos canónicos.

### Prefijos más comunes para clientes nuevos

| Prefijo | Tipo de documento | Cuándo usar |
|---------|-------------------|-------------|
| `SOP-` | Procedimiento operativo | Cómo se hace algo paso a paso |
| `TP-` | Technical Protocol | Arquitectura, instalación, configuración |
| `PLB-` | Playbook | Guía de referencia por tema |
| `PBO-` | Playbook operativo | Guía de referencia con criterios de decisión |
| `MP-` | MetaPlaybook | Receta canónica del CEO/founder |
| `MKT-` | Marketing | Copy, estrategia, posicionamiento |
| `CP-` | Control Plane | Mapas de activos, registros, índices |
| `OUT-` | Output de sesión | Resultado de una sesión de trabajo |
| `MiPg-` | Minuta | Registro de reunión o sesión |
| `PA-` | Paper | Documento de conocimiento profundo |
| `PBO-` | Playbook operativo | Con criterios de decisión |
| `BC-` | Brain Code | Perfil de persona, metodología o tradición |

**Resultado de este paso:** Lista de 3-5 tipos de documentos que el cliente usará en los primeros 30 días.

---

## Paso 4 — Cargar los primeros documentos

Con la estructura lista y los tipos definidos, cargar los documentos existentes del cliente.

### Proceso de carga

**4a. Migración de documentos existentes**

Si el cliente tiene documentos en Google Drive, Notion, Word u otras herramientas:
1. Exportar en formato Markdown (.md) si es posible, o en texto plano
2. Renombrar según la convención: `TIPO-ENT-Proyecto-Nombre-v01.md`
3. Colocar en la subcarpeta correspondiente

**4b. Agregar el Asset Header**

Cada documento debe tener el header al inicio:

```markdown
## Asset Header
- **Asset ID:** [nombre del archivo sin extensión]
- **Version:** v01
- **Status:** Draft
- **Owner:** [Nombre del cliente]
- **IntellBank:** IB-[ENT]-[Nombre]
- **Tipo:** [PREFIJO] — [Nombre completo del tipo]
- **Propósito:** [Una línea que describe para qué sirve este documento]
- **Última actualización:** YYYY-MM-DD
---
```

**4c. Registrar en el Registry**

Después de cargar cada documento, agregar una fila en el Registry maestro.

### Herramienta de carga masiva

Para clientes con más de 20 documentos iniciales, usar el script de actualización de headers para procesar todos los archivos en batch (ver `SOP-XX-AssetHeader-BulkUpdate-v01.md` cuando esté disponible).

---

## Paso 5 — Configurar el CLAUDE.md del IntellBank

El archivo `CLAUDE.md` en la raíz del IntellBank es el que el agente lee al inicio de cada sesión. Es el "mapa del territorio" que orienta al agente.

**Nombre:** `CLAUDE.md`
**Ubicación:** `IB-[ENT]-[Nombre]/` (raíz del banco)

### Contenido del CLAUDE.md

```markdown
# [Nombre del Cliente] — IntellBank CLAUDE.md

## Quién soy
[2-3 oraciones sobre el cliente: quién es, qué hace, cuál es su misión]

## Estructura de este banco
```
IB-[ENT]-[Nombre]/
├── CP-[ENT]-Control-Planes/    ← Registry y mapas
├── PB-[ENT]-Project-Bank/      ← Proyectos activos
└── [otras carpetas activas]
```

## Tipos de documentos en este banco
- **SOP-**: Procedimientos paso a paso
- **PLB-**: Playbooks de referencia
- [otros tipos relevantes del cliente]

## Convención de nombres
`TIPO-[ENT]-Proyecto-Nombre-vNN.md`

## Registry maestro
Ver: `CP-[ENT]-Control-Planes/CP-[ENT]-[Nombre]-Registry-v01.md`

## Proyectos activos
[Lista de proyectos principales del cliente]

## Contexto del momento actual
[Estado operativo actual, prioridades, qué se está construyendo]
```

El CLAUDE.md se actualiza en cada sesión de trabajo significativa (mensualmente como mínimo).

---

## Paso 6 — LLM Wiki local (opcional, para clientes avanzados)

Para clientes que ya tienen un IntellBank con 50+ documentos y quieren que el agente tenga acceso a conocimiento semántico, crear un LLM Wiki local.

### Estructura del Wiki local

```
IB-[ENT]-[Nombre]/
└── LW-[ENT]-LLM-Wiki/          ← o en raíz del vault si es banco único
    ├── index.md
    ├── Raw/
    │   └── IB-[ENT]-[Nombre]/  ← copia de los documentos fuente
    └── Wiki/
        └── [concepto].md       ← páginas de síntesis
```

### Cuándo activar el Wiki local

- El cliente tiene 50+ documentos
- El cliente hace preguntas recurrentes que requieren contexto de múltiples documentos
- Se aproxima una demo 2+2 o una presentación importante
- Se va a incorporar un nuevo colaborador al equipo del cliente

### Proceso de construcción del Wiki local

Seguir el mismo proceso de ingest descrito en `LLM-Wiki-Playbook.md` en el Wiki maestro de EmpowerLabs, adaptando las rutas al banco del cliente.

---

## Paso 7 — Mantenimiento continuo

Un IntellBank sin mantenimiento se convierte en un repositorio desordenado en 60-90 días.

### Cadencia de mantenimiento

| Frecuencia | Tarea |
|-----------|-------|
| Cada sesión | Actualizar/crear el documento generado; agregar al registry |
| Semanal | Revisar Status de activos recientes (¿siguen en Draft o ya son Active?) |
| Mensual | Actualizar CLAUDE.md con el contexto del momento actual |
| Trimestral | Auditoría de registry: ¿hay activos deprecados? ¿hay huecos? |

### Señales de deterioro

Si el cliente reporta alguna de estas señales, hacer una auditoría inmediata:
- "El agente no sabe de [tema] que sí tenemos documentado"
- "No sé dónde está el documento de [X]"
- "Hay muchos archivos con nombres similares"
- "El agente me da respuestas genéricas aunque le doy contexto"

---

## Checklist de construcción de un IntellBank

Usar este checklist para verificar que el banco está bien construido antes de entregar al cliente:

```
[ ] Paso 0 — Arquitectura decidida: número de bancos, nombres, entidades
[ ] Paso 1 — Estructura de carpetas creada
[ ] Paso 2 — Registry maestro creado con tabla de activos (puede estar vacía)
[ ] Paso 3 — Tipos de documentos definidos y comunicados al cliente
[ ] Paso 4 — Documentos iniciales cargados con nomenclatura correcta
[ ] Paso 4 — Asset Headers agregados a todos los documentos
[ ] Paso 4 — Registry actualizado con todos los activos cargados
[ ] Paso 5 — CLAUDE.md creado y configurado
[ ] Paso 6 — LLM Wiki local creado (si el cliente califica)
[ ] Verificación final — Abrir el banco en Obsidian y confirmar que la navegación funciona
[ ] Verificación final — Hacer una query de prueba con el agente para confirmar que tiene contexto
```

---

## Tiempo estimado de construcción

| Escenario | Tiempo aproximado |
|-----------|------------------|
| Banco nuevo vacío (estructura + registry + CLAUDE.md) | 30-45 minutos |
| Migración de 20-50 documentos existentes | 2-4 horas |
| Migración de 50-100 documentos existentes | 4-8 horas |
| Construcción de LLM Wiki básico (20 páginas) | 3-4 horas adicionales |
| Construcción de LLM Wiki completo (30+ páginas) | 6-8 horas adicionales |

**Nota:** Con experiencia y el script de bulk headers, los tiempos de migración se reducen 50-60%.

---

## Errores comunes a evitar

| Error | Consecuencia | Prevención |
|-------|-------------|------------|
| No definir la entidad (ENT) antes de empezar | Inconsistencia de nomenclatura en todo el banco | Decidir ENT en el Paso 0 |
| Mezclar tipos de documentos (OUT- con SOP-) | El agente no distingue conocimiento de registro | Aplicar criterios de clasificación estrictamente |
| No actualizar el registry | El registry se desincroniza y pierde utilidad | Actualizar el registry en la misma sesión en que se crea el documento |
| CLAUDE.md genérico | El agente no tiene contexto real del cliente | Dedicar tiempo a escribir el contexto del momento actual |
| Crear subcarpetas sin prefijo de tipo | El sistema no puede navegar automáticamente | Todas las subcarpetas llevan prefijo TIPO-ENT- |

---

*SOP creado durante el Retiro Creativo EmpowerLabs · 11-abr-2026*
*Basado en la experiencia de construcción del vault Reinventaverse (498 activos, 6 IntelliBanks)*