---
type: PLB
asset_id: PLB-EL-BCAFable-Aplicacion-v01
version: v01
status: Activo — Borrador operativo
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia
fecha_creacion: 2026-07-11
intellibank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank/PB-EL-IALab
proposito: |
  Playbook de aplicación del BCA-Fable-CognitiveStack-v01 al portafolio real de
  EmpowerLabs: cuándo gastar ventana Fable, cuándo usar Opus+BCA, cuándo basta
  Haiku+BCA. Incluye la tabla comparativa Fable / Opus+BCA / Opus y la integración
  con el método Wargaming (MePB-EL-WarRoom-WargamingPlaybook-v01).
canonicos_referenciados:
  - BCA-Fable-CognitiveStack-v01 (BC-EL-BrainCodes)
  - TP-XX-BCComplex-FableRoom-v01 (FM-XX-Formulas-Maestras)
  - MePB-EL-WarRoom-WargamingPlaybook-v01 (WG-EL-WarRoom)
tags: [plb, bca-fable, runtime, wargaming, asignacion-de-modelo, ialab]
---

# PLB — Aplicación del BCA-Fable al Portafolio EmpowerLabs
## Cuándo Fable, cuándo Opus+BCA, cuándo Haiku+BCA — y cómo se acopla al Wargaming

---

## 1. El principio económico que gobierna todo

La ventana Fable es el recurso más caro y escaso del sistema. La regla es la misma que ya opera en el War Room ("convertir tokens del modelo caro en activos permanentes"):

> **Fable se gasta en LAB — donde se produce inteligencia que se reutiliza.
> El BCA-Fable existe para que PROD — donde se ejecuta volumen — herede su disciplina sin gastar su ventana.**

Tres preguntas deciden la asignación, en orden:

1. **¿El output es un activo canónico nuevo o una simulación de alto riesgo?** → Fable directo (LAB).
2. **¿Es ejecución de volumen o de un contrato ya diseñado?** → Opus/Sonnet + BCA-Fable (PROD).
3. **¿Es mecánico: triage, QA, extracción, clasificación?** → Haiku + BCA-Fable RA-1.

Anti-patrón #1: gastar Fable ejecutando lo que un ejecutor con BCA ya puede ejecutar.
Anti-patrón #2: pedirle a Haiku+BCA lo que solo la capacidad (no la disciplina) puede dar. El BCA transfiere proceso, no techo de razonamiento (CAL Límite 0).

---

## 2. Tabla comparativa — Fable · Opus+BCA-Fable · Opus solo

| Dimensión | **Fable 5** | **Opus + BCA-Fable (RA-3)** | **Opus solo** |
|---|---|---|---|
| Síntesis compleja / unknown-unknowns | ★★★★★ — zona de ventaja irreemplazable | ★★★★ — capacidad Opus con proceso Fable | ★★★★ — capaz pero converge más rápido a la respuesta cómoda |
| Disciplina de proceso (clasificar, scope, red-team) | Nativa | **Instalada y consistente** — Layer H la fuerza en cada ruta | Variable — depende del prompt de cada sesión |
| Calibración de incertidumbre | Nativa | **Forzada por V5/H3** — "sé/infiero/ignoro" en cada output | Buena pero no sistemática; cede ante presión por certeza |
| Consistencia entre rooms/sesiones | Alta | **Alta — es el punto del BCA:** mismo protocolo en todo room | Baja-media: cada room arranca con su estilo |
| Tensión sostenida (no colapsar dilemas) | Nativa | Prescrita (C3-3 activada en RA-3) | Tiende a resolver prematuramente |
| Costo / disponibilidad de ventana | Muy caro · ventana limitada | Medio · disponible | Medio · disponible |
| Uso canónico | **LAB:** wargames 🔴, destilación de BCs, arquitectura de sistemas, decisiones L3 | **PROD:** ejecutar contratos WG-, producción documental seria, edición de libros, auditorías | Conversación general, borradores exploratorios, tareas donde el proceso no es crítico |
| Riesgo típico | Desperdiciarlo en ejecución | Creer que iguala a Fable en síntesis (no lo hace) | Falsa certeza + output sin scope bounding |
| En el Wargaming | **Wargamer** (simula, nunca ejecuta) | **Ejecutor estándar del Handoff Spec** | Ejecutor legacy — sin harness, requiere más supervisión |

**Lectura ejecutiva de la tabla:** Opus+BCA no acerca a Opus al *techo* de Fable; lo acerca a su *piso* — elimina los días malos. Para el 80% del trabajo de PROD, el piso consistente vale más que el techo ocasional.

*(Complemento Haiku+BCA RA-1, fuera de tabla: triage de briefs, QA de naming/registry, extracción de NEXTs, clasificación de Idea Bank, verificación de checklists. BLUF + 3-5 líneas. Nunca destila, nunca wargamea, nunca redacta capítulo.)*

---

## 3. Playbook por tipo de proyecto

### 3.1 Edición de libros (MediaFactory · Empowernomics · Monetiza tu Expertise)
**Perfil: P2 (producción documental) · División LAB/PROD:**

| Fase | Modelo | Por qué |
|---|---|---|
| Arquitectura del libro: tesis, arco, estructura de capítulos, voz | **Fable** | Síntesis compleja + tensión sostenida — decisión que gobierna todo lo demás |
| Redacción/edición de capítulos contra la arquitectura ratificada | **Opus+BCA P2** | Volumen con disciplina: scope bounding por capítulo, Occam contra el bloat, BLUF = el texto mismo |
| Pases de consistencia: léxico, continuidad, estilo, anti-AI-voice | **Haiku+BCA RA-1** | Mecánico y barato; H3 (purga de filler) es su zona |

Regla de handoff: la arquitectura ratificada por Victor es el **contrato** — el ejecutor P2 no la renegocia; toda desviación se declara como Soft Variable (H1.2), no se improvisa. Es el mismo patrón WG-: el diseño caro viaja como contrato al ejecutor barato.

### 3.2 Generación de dashboards (BRD- / VIZ- del vault)
**Perfil: P3 (código/técnico) · División:**

| Fase | Modelo | Por qué |
|---|---|---|
| Arquitectura de información: qué pregunta responde el dashboard, jerarquía, qué NO va | **Fable** (solo dashboards nuevos de sistema — ej. Control Planes) | El error caro en dashboards es de arquitectura, no de código |
| Construcción HTML/JS contra la arquitectura | **Opus+BCA P3** o Sonnet+BCA | H2.2 stress test (dataset vacío, valores extremos), sin abstracciones no pedidas |
| Actualización de datos de dashboards existentes (weeklysync, boards) | **Haiku+BCA RA-1** | Mecánico; H2.3 recalcula todo número antes de publicar |

Hard Variables permanentes (H1.2) para todo ejecutor de dashboards: la norma de fondo oscuro (mínimo #777 en texto, escala para fondos #0a0a0a) entra como Hard Variable, no como preferencia — el ejecutor no la "recuerda", la recibe en el contrato.

### 3.3 Desarrollo de modelos cognitivos (BCs · UltraSherpas · FLA)
**Perfil: P4 (destilación) · División:**

| Fase | Modelo | Por qué |
|---|---|---|
| Destilación de BCs nuevos y BCAs · diseño de ontología FLA | **Fable + TP-FableRoom** | Es el trabajo de mayor densidad del portafolio; RA-1/RA-2 no destilan |
| Updates v01→v02 de BCs existentes · fusiones SVA con receta ratificada | **Opus+BCA P4** | El molde ya existe (anatomía v02 + BC previo); es ejecución disciplinada, no creación |
| QA de BCs: checklist de 6 tests, verificación de evidencia citada, registry | **Haiku+BCA RA-1** | Checklist mecánico |

### 3.4 Análisis estratégico y proyectos cliente (DemandGen · Bayer · Estafeta · Intelifin · NewLink)
**Perfil: P1 (análisis/estrategia) · División:**
- **Fable:** diagnósticos de sistema completos, decisiones que comprometen dinero/reputación del cliente, y todo lo que califique para wargame (ver §4).
- **Opus+BCA P1:** análisis recurrentes, propuestas contra un molde validado, preparación de sesiones. Red flag del perfil activada: ninguna recomendación sale sin sus Missing Variables declaradas.
- **Haiku+BCA RA-1:** monitoreo, resúmenes de avance, triage de inputs del cliente.

### 3.5 Operación del vault (registry, minutas, Idea Bank, WikiX)
**Todo Haiku+BCA RA-1**, salvo curaduría del WikiX con drift conceptual (Sonnet+BCA) y rediseños de estructura del vault (Fable). Es el volumen más alto y el menor riesgo unitario del sistema — exactamente lo que RA-1 existe para absorber.

---

## 4. Integración con el Wargaming (MePB-EL-WarRoom-WargamingPlaybook-v01)

El acople es natural porque ambos activos implementan la misma economía: inteligencia cara → contrato → ejecutor barato. El BCA-Fable es la pieza que el Handoff Spec (§6 del WG-) tenía implícita y ahora tiene explícita:

### 4.1 Los roles quedan así

| Rol del método | Antes | Con BCA-Fable |
|---|---|---|
| **Wargamer** (LAB) | Fable 5 | Fable 5 — sin cambio. El BCA NO sustituye a Fable como wargamer de misiones 🔴 |
| **Ejecutor** (PROD) | "Opus/Sonnet/humano" genérico | **Opus+BCA-Fable con perfil declarado** — el Handoff Spec ahora especifica: `Ejecutor: Opus + BCA-Fable RA-3 · Perfil P<n>` |
| **Wargamer degradado** | — (si no hay ventana Fable, la misión espera) | **Opus+BCA P1 puede wargamear misiones 🟡** — nunca las 🔴, que siguen esperando ventana Fable |

### 4.2 Mapeos directos entre el WG- y el Layer H del BCA

El ejecutor con BCA no lee el WG- como texto — lo mapea a su harness:

- **Ledger de supuestos (WG- §2) → H1.2:** variables resueltas = Hard Variables; sin resolver = Missing Variables. El BCA ya obliga a declararlas antes de actuar — el corolario P022 ("la variable sin owner bloquea el move") se ejecuta solo.
- **Moves con rama de falla (WG- §3) → H0 ruta PROFUNDA:** todo move marcado 🔴 en el blueprint fuerza la ruta profunda del router; los moves rutinarios corren en LIGERA. El wargame pre-computó lo que el router habría tenido que decidir.
- **Contramoves (WG- §3) → H2 pre-resuelto:** el adversarial pass del ejecutor no parte de cero — verifica contra las causas de falla ya simuladas y solo escala si observa una falla NO mapeada (eso es un trigger de recalibración, no de improvisación).
- **Condiciones de aborto (WG- §4) → override absoluto:** ninguna ruta del router ni regla del harness pasa por encima de un aborto declarado. Aborto → detener y escalar al owner, siempre.
- **Ratificación (WG- §5-6) → CAL Límite 5:** la regla de silencio de H4.3 nunca aplica frente al Ratificador — el ejecutor muestra su razonamiento completo en cada punto de ratificación del Handoff Spec.

### 4.3 Lo que el acople habilita (la tesis IDE-060, ahora operable)

El WG- ratificado + BCA-Fable instalado = las dos mitades del contrato de misión de la ontología FLA (Shell × BrainCode × **Harness** × Gobernanza): el WG- aporta el mapa de fallas de ESTA misión; el BCA aporta la disciplina de ejecución de TODA misión. Juntos justifican subir la autonomía del ejecutor de L1 a L2 — la supervisión humana se concentra en los puntos de ratificación y en fallas no mapeadas, no en cada move.

### 4.4 Bucle de validación (mata dos pájaros)

El BCA está en readiness ⭐⭐⭐ pendiente de Test 3 (utilidad funcional). La próxima ejecución real de un WG- ratificado ES el test: correr el ejecutor como Opus+BCA, registrar (a) % de fallas anticipadas por el WG- (métrica §8.2 del MePB) y (b) si el output fue Fable-like sin ventana Fable. Un solo ciclo alimenta las métricas del War Room Y el readiness del BCA.

**NEXT [Victor]:** elegir el próximo WG- a ejecutar y declararlo primer piloto Opus+BCA (candidato natural: el que tenga ejecución más próxima en Wargames/). Registrar resultado como CAS- al LabPraxis y recalibrar ambos activos.

---

## CHANGELOG

| Versión | Fecha | Cambio |
|---|---|---|
| v01 | 2026-07-11 | Creación. Lógica de asignación Fable/Opus+BCA/Haiku+BCA, tabla comparativa, playbook por tipo de proyecto (libros, dashboards, modelos, cliente, vault) e integración con Wargaming (roles, mapeos WG-↔Layer H, tesis IDE-060, bucle de validación Test 3). Room: TP-XX-BCComplex-FableRoom · Jay + Victor. |