## Asset Header

- **Asset ID:** DC-MPX-RevisionEstructuralBookFactory-v01
- **Version:** v01
- **Status:** Draft
- **Owner:** Victor Heredia
- **IntellBank:** IB-MPX-MasterPlaybooks
- **Tipo:** DC — Document Canónico
- **Propósito:** Revisión Estructural — Book Factory vs. Big MetaFactory
- **Última actualización:** 2026-04-11

---

# Revisión Estructural — Book Factory vs. Big MetaFactory

## Diagnóstico General

La Book Factory tiene una base sólida y el esqueleto correcto. Sin embargo, hay **6 brechas estructurales** que, si no se corrigen antes de escalar, van a generar fricción operativa y artefactos inconsistentes.

---

## ✅ Lo que está bien alineado

**1. Pipeline lineal con estaciones definidas.**
Cada fase tiene inputs, outputs y artefactos nombrados. Eso es la base de cualquier MetaFactory bien diseñada.

**2. Routing condicional explícito.**
La bifurcación `libro_disponible = sí/no` está bien modelada. Es una decisión de entrada que cambia el flujo — exactamente como debe ser en una fábrica.

**3. Checkpoints humanos en puntos de alto riesgo.**
Los 3 checkpoints están ubicados en los momentos correctos: antes de invertir trabajo (Intake), antes de comprometer la reconstrucción (Índice), y antes de publicar (QA).

**4. El artefacto final está claro.**
El sistema sabe qué produce: un `.docx` para el lector y una Fuente Completa para Sherpa. Dos salidas, dos destinos.

**5. QA con criterios concretos.**
Los thresholds (≥8.0, pesos por dimensión, tipos de preguntas) son operables — no son criterios subjetivos.

---

## 🔴 Las 6 brechas estructurales

---

### Brecha 1 — Numeración rota del pipeline

**El problema:** Las fases están numeradas `1A → 1B → 2 → 3 → 4 → 5 → 6`, pero la secuencia real de ejecución es `1A → 2 → 1B → 3 → 4 → 5 → 6`. El número no refleja el orden de ejecución — viola el principio de trazabilidad de una MetaFactory.

**Impacto:** Un operador nuevo leyendo el número `2` asume que va después de `1B`. Pero `2` va entre `1A` y `1B`. Esto genera errores de secuencia a escala.

**Corrección propuesta:**
```
Renombrar secuencialmente por orden de ejecución:

Actual          →   Propuesto
Intake          →   Estación 0 — Intake
Fase 1A         →   Estación 1 — Investigación
Fase 2          →   Estación 2 — Libro Virtual (condicional)
Fase 1B         →   Estación 3 — Perfil Intelectual
Fase 3          →   Estación 4 — Producción del Resumen
Fase 4          →   Estación 5 — Fuente Completa RAG
Fase 5          →   Estación 6 — QA
Fase 6          →   Estación 7 — Publicación
```

---

### Brecha 2 — No hay artefacto de tracking del libro

**El problema:** No existe una "tarjeta de producción" que acompañe al libro a través de todas las estaciones. Cada fase produce sus artefactos de forma independiente, pero no hay un registro maestro que diga: *este libro pasó por aquí, con estos scores, tomadas estas decisiones, en estas fechas.*

**Impacto:** A 20 libros/semana es imposible saber el estado de cada libro, qué checkpoints pasó, o por qué fue rechazado en el QA. El sistema no es auditable.

**Corrección propuesta — Ficha de Producción:**
```yaml
# FICHA DE PRODUCCIÓN — [Título del libro]
id_libro: [hash único]
titulo: ...
autor: ...
fecha_entrada: ...
operador: ...

estaciones:
  intake:        { fecha: ..., operador: ..., status: ✅ }
  investigacion: { fecha: ..., status: ✅, fuentes: N }
  libro_virtual: { activada: sí/no, score_cobertura: %, status: ✅ }
  perfil:        { fecha: ..., lentes: N, status: ✅ }
  resumen:       { fecha: ..., chunks: N, status: ✅ }
  fuente_rag:    { fecha: ..., version: v1.0, status: ✅ }
  qa:            { score: X.X, dictamen: ..., status: ✅ }
  publicacion:   { fecha: ..., operador: ..., status: ✅ }

versiones:
  v1.0: publicado [fecha]
  v1.1: pendiente [motivo]
```

---

### Brecha 3 — No hay loops de retrabajo definidos en el pipeline

**El problema:** El QA (Fase 5) puede dictaminar "Regresar a Fase X", pero el pipeline no muestra estos loops. La fábrica solo dibuja el camino feliz. Una MetaFactory real tiene rutas de retrabajo explícitas tanto como rutas de avance.

**Impacto:** Cuando el QA rechaza, el operador no sabe cuántos artefactos debe regenerar, en qué orden, ni qué hacer con la Ficha de Intake del libro rechazado.

**Corrección propuesta — Mapa de retrabajo:**
```
Causa del fallo QA         → Regresar a      → Re-ejecutar
─────────────────────────────────────────────────────────
Sherpa inventa hechos      → Estación 5      → Fuente Completa RAG
Voz no suena al autor      → Estación 3      → Perfil Intelectual
Tema sin cobertura         → Estación 4      → Sección específica del Resumen
Fallo en pregunta trampa   → Estación 3      → Filtros negativos
Playbook no ejecutable     → Estación 4      → Playbook de esa sección
```
Este mapa debe ser parte de la Estación 6 (QA), no una nota al pie.

---

### Brecha 4 — Fase 3 viola la atomicidad de estación

**El problema:** La Estación 4 (Fase 3 actual) hace tres cosas distintas: produce el resumen narrativo, produce los chunks RAG, y produce los prompts visuales. Son tres tareas con propósitos y destinatarios diferentes.

**Impacto:** Si hay que regenerar solo los prompts visuales, el operador debe re-ejecutar toda la fase. Si los chunks están mal estructurados, todo el trabajo del resumen narrativo se pierde con ellos.

**Corrección propuesta — dividir en 3 sub-estaciones:**
```
Estación 4A — Resumen Narrativo     → .docx para el lector
Estación 4B — Estructuración RAG    → Chunks .md para Sherpa
Estación 4C — Prompts Visuales      → 5 imágenes Midjourney
```
Cada sub-estación puede re-ejecutarse de forma independiente. Los prompts visuales son además opcionales o paralelizables — no bloquean el pipeline principal.

---

### Brecha 5 — Fronteras borrosas entre Fase 3 y Fase 4

**El problema:** La Fase 3 ya produce "chunks RAG" (Prompt 3.2), pero la Fase 4 también produce "la Fuente Completa RAG". ¿Cuál es la diferencia real? El documento dice que los chunks de Fase 3 son el *insumo* de Fase 4, pero en la práctica ambas producen artefactos RAG y la distinción no es obvia para el operador.

**Impacto:** Riesgo de que el operador confunda los chunks de Fase 3 con el documento maestro de Fase 4, o suba el documento equivocado al sistema RAG.

**Corrección propuesta — nombrar con intención diferente:**
```
Fase 3 / Estación 4B — produce: "Chunks de Contenido"
  → Son los bloques del resumen, estructurados para ser integrados
  → Formato: múltiples archivos .md por sección
  → Propósito: materia prima para la Fuente Completa

Fase 4 / Estación 5  — produce: "Fuente Completa Sherpa v1.0"
  → Es UN documento maestro que integra, enriquece y prioriza
  → Formato: un solo .md con 4 bloques y headers semánticos
  → Propósito: el documento que va al RAG — ESTE y solo este
```
Además: añadir nota explícita en el Intake del operador: *"No subir los chunks de Fase 3 al RAG. Solo subir la Fuente Completa de Fase 4."*

---

### Brecha 6 — Sin protocolo de versiones para libros actualizados

**El problema:** El sistema produce `v1.0` del libro, pero no hay protocolo para cuando el libro necesita una `v1.1` — ya sea por error detectado en producción, nueva edición del libro, o fallo reportado por un lector de Sherpa.

**Impacto:** A 20 libros/semana, en pocos meses habrá decenas de libros que necesitan actualización. Sin protocolo, cada corrección se gestiona de forma ad hoc.

**Corrección propuesta — Estación 8: Mantenimiento:**
```
Trigger de re-entrada:
  a) Fallo reportado por lector en Sherpa
  b) Nueva edición del libro disponible
  c) Score QA cayó por debajo del umbral en auditoría periódica

Protocolo:
  1. Identificar qué estaciones afecta el cambio
  2. Re-ejecutar solo esas estaciones (no todo el pipeline)
  3. Actualizar la Ficha de Producción con versión y motivo
  4. Publicar v1.1 con nota de cambio
```

---

## Resumen Ejecutivo

| Brecha | Severidad | Esfuerzo de corrección |
|--------|-----------|----------------------|
| 1 — Numeración rota | 🔴 Alta | Bajo — renombrar |
| 2 — Sin ficha de tracking | 🔴 Alta | Medio — diseñar plantilla |
| 3 — Sin loops de retrabajo | 🟡 Media | Medio — documentar mapa |
| 4 — Fase 3 no atómica | 🟡 Media | Bajo — dividir en 4A/4B/4C |
| 5 — Fronteras borrosas 3→4 | 🟡 Media | Bajo — renombrar artefactos |
| 6 — Sin protocolo de versiones | 🟠 Media-Alta | Alto — diseñar Estación 8 |

---

## Recomendación de siguiente paso

Antes de implementar las Fases 4, 5 y 6, corregir primero las brechas **1, 2 y 4** — son las de mayor impacto y menor esfuerzo. Las otras tres pueden resolverse en paralelo al Sprint 3.

---

*Revisión estructural v1.0 · Book Factory · 2026-03-13*