--- type: MAP asset_id: MAP-MPX-FactoriaEditorial-EstructuraCanonica-v01 version: v01 status: Active — ratificado por Victor (L3) 2026-06-17 owner: Victor Heredia sherpa_owner: Jay ratificador: Victor Heredia (L3+) intellbank: IB-MPX-MasterPlaybooks subbank: PB-MPX-FactoriaEditorial fecha_creacion: 2026-06-17 fecha_ultima_actualizacion: 2026-06-17 modelo_objetivo: Opus / Fable 5 (trabajo arquitectónico de portafolio de líneas) proposito: > Estructura canónica de la Factoría Editorial: un backbone único de 4 bloques + un módulo de Sherpa compartido, sobre el que corren N líneas de producción (instancias del mismo patrón). Unifica las tres numeraciones hoy dispersas (P1–P6 del TP/loops, 8 fases del MPMF, E0–E8 de la Book Factory) y define las cuatro líneas vigentes (Resúmenes, MasterPlaybook, Guías & Reviews, Playbooks de Empresa), su diferenciación y sus fronteras. Cada línea priorizada por el LoopXOP-Editorial entra a este backbone. referencias_canonicas: - TP-MPX-FactoriaEditorial-Arranque-v02 (la máquina · 5 loops E1–E5 · Quick Start) - TP-MPX-EcosistemaPublicaciones-Arranque-v01 (room de mando · qué se publica) - DC-MPX-EcosistemaPublicaciones-LoopContract-v01 (LoopXOP-Editorial · orquestador) - CP-MPX-PublishingMetaFactoryPlan-v01 (MPMF · 8 fases · línea B) - SOP-MPX-BookFactorySistema-v02 (Book Factory v2.1 · E0–E8 · línea A) - ARQ-MPX-BookFactory-Architecture-v01 (arquitectura conceptual de resúmenes) - TP-EL-VOXFactory-Arranque-v01 + vox-distiller (la voz · insumo del Bloque 1) - PP-EL-LoopX-MacroLoopX-Arquitectura-v01 (regla fractal · una línea = una instancia) - DC-EL-LoopX-XDocMaestro-HubSpoke-v01 (XDoc Maestro por autor / título / cliente) tags: [MAP, factoria-editorial, estructura-canonica, backbone, n-lineas, resumenes, masterplaybook, guias-reviews, playbooks-empresa, sherpa, macroloopx, mpx] --- # MAP — Estructura Canónica de la Factoría Editorial ## Un backbone, N líneas: cómo se produce cualquier publicación de Master Playbooks --- > **✅ RATIFICADO — Victor Heredia (L3) · 2026-06-17.** La estructura de 4 bloques + módulo de Sherpa compartido + las 4 líneas (A–D) y la frontera D↔HIOrg quedan canónicas. Backbone abierto a N líneas. Este MAP es la referencia de arquitectura de la Factoría Editorial; los pipelines de cada línea se leen contra él (§6). > **Qué es este documento.** La definición canónica de *cómo está estructurada* la Factoría Editorial: un backbone único de cuatro bloques con un módulo de Sherpa compartido, sobre el que corren varias **líneas de producción** (hoy cuatro, abierto a más). Es la pieza que faltaba entre el room de mando (qué se publica) y los pipelines sueltos de cada línea (cómo se produce cada tipo). > > **Qué NO es.** No es el room de mando del portafolio (eso es `TP-MPX-EcosistemaPublicaciones-Arranque-v01`), ni el pipeline detallado de una línea (esos son el MPMF y el SOP Book Factory). Este MAP es la **arquitectura que los unifica**. --- ## §1 · La tesis — un backbone, N líneas La Factoría Editorial no es un pipeline; es **un backbone con líneas enchufables**. Toda publicación —un resumen de un best seller, un MasterPlaybook de un autor, una guía de compra, un playbook de una empresa— recorre **el mismo flujo de cuatro bloques**. Lo que cambia entre líneas es el *input*, la *voz*, el *output al lector* y la *capa de Sherpa* — no el flujo. Esto es la regla fractal del MacroLoopX aplicada hacia adentro: así como *una factoría = una instancia del MacroLoopX*, aquí **una línea = una instancia del backbone editorial**. Agregar una línea nueva no rediseña la factoría: instancia el backbone con un perfil de entrada distinto. ``` LoopXOP-Editorial (orquesta QUÉ se publica) │ handoff de un título priorizado a su línea ┌──────────┬───────────┼───────────┬──────────────┐ ▼ ▼ ▼ ▼ ▼ (ranura abierta) A·Resúm. B·MPlaybook C·Guías&Rev D·Playbooks Emp. (E·papers/…) └──────────┴───────────┴───────────┴──────────────┘ ▼ BACKBONE COMÚN — un solo flujo para todas las líneas Bloque 0 → Bloque 1 → Bloque 2 → Bloque 3 ▼ MÓDULO COMPARTIDO · Activación de Sherpa (RAG → QA → activo) ▼ Publicación viva → caso/aprendizaje a LoopXKZ → estado al LoopXOP-Editorial ``` **Invariante (heredado del MacroLoopX):** *los loops orquestan, las factorías producen*. El LoopXOP-Editorial decide y prioriza; el backbone produce. Las líneas son productores enchufables — nunca soldados al loop. --- ## §2 · El orquestador — el LoopXOP-Editorial El backbone no decide qué se publica; eso lo hace el **LoopXOP-Editorial** (`DC-MPX-EcosistemaPublicaciones-LoopContract-v01`, Active, ratificado 14-jun), con su room de mando (`TP-MPX-EcosistemaPublicaciones-Arranque-v01`). Su trabajo: curar el portafolio, fijar fronteras entre publicaciones, secuenciar el roadmap y **hacer handoff** de cada título priorizado a la línea que corresponda. La relación es limpia: el loop entrega a una línea un **título priorizado con su frontera y su nivel confirmados**; la línea lo produce vía el backbone y devuelve el activo + el estado. El catálogo y el roadmap del room de mando se mantienen vivos con ese retorno. --- ## §3 · El backbone — los 4 bloques Cada bloque tiene una misión, un gate de salida y un mapeo a las estaciones que ya existen en cada línea. La numeración es **canónica y única**: reemplaza las tres numeraciones previas (ver §6). ### Bloque 0 · Entrada & Viabilidad — *el paquete de producción* Concepto + análisis de mercado + estudio de viabilidad, al estilo del paquete de Monetiza tu Expertise. Aquí se decide **qué libro, para quién, vale la pena y a qué precio**. - **Regla de entrada (Victor):** si el **paquete de producción ya viene listo** (concepto + viabilidad + decisión de tipo), se **valida y entra** directo a Bloque 1. Si no existe, **este bloque lo genera** como primer paso. El backbone nunca produce sin paquete aprobado. - **Gate 0→1 (PASS/FAIL):** Paquete de Producción aprobado — brief + viabilidad de mercado + pricing + decisión de tipo/idioma. Un AUTO-FAIL no mata el título; admite override con rationale (hay piezas de autoridad estratégica que no pasan el scoring estándar). ### Bloque 1 · Arquitectura Editorial — *la estructura y la voz* Antes de redactar una palabra, se define **la estructura** de la pieza y se **carga la voz**. Es donde se afina todo lo editorial: arquitectura de capítulos/secciones, promesa→diagnóstico→sistema→implementación, y el activo de voz que regirá la redacción. - La **voz** entra aquí desde la Factoría de VOX (`TP-EL-VOXFactory`, skill `vox-distiller`) en las líneas con autor, o desde el perfil intelectual derivado en las líneas sin autor. - **Gate 1→2:** estructura ratificada + voz/VOX cargada (Test ≥90% cuando aplica VOX). ### Bloque 2 · Producción + QA editorial — *el contenido* Producción del contenido con **estaciones de control de calidad explícitas**: | Estación QA | Verifica | Falla si… | |---|---|---| | **QA-Redacción** | Que el contenido dice lo correcto y está completo por sección | Falta sección requerida · contenido genérico o impreciso | | **QA-Estilo** | Corrección de estilo + consistencia de voz a lo largo de la pieza | No suena al autor/voz · inconsistencia entre secciones | | **QA-Formato** | Formato canónico **listo para la plataforma** (estructura, assets, metadata) | Formato fuera de norma · faltan elementos requeridos por plataforma | - **Gate 2→3:** QA editorial PASS — **Test VOX ≥90%** (cuando aplica voz) **+ formato listo para plataforma**. El draft no avanza sin pasar. ### Bloque 3 · Plataforma + SherpaIA — *la publicación* Conexión a la **plataforma MasterPlaybooks** y configuración de la **capa de Sherpa**. Incluye, cuando la línea lo requiere, los **templates de artefactos interactivos** (MasterPlaybook Inteligente) y el **launch pack** de marketing como módulo paralelo opcional. - **Gate 3→cierre:** publicación confirmada en plataforma + Sherpa QA PASS → el caso y los aprendizajes van a **LoopXKZ** (mejora del oficio) y el estado vuelve al LoopXOP-Editorial. --- ## §4 · El módulo compartido — Activación de Sherpa La configuración del SherpaIA **no se inventa por línea**: es un módulo único, ya probado en la Book Factory, que todas las líneas que necesitan Sherpa reutilizan. Es el mecanismo de mayor apalancamiento de toda la arquitectura. ``` Fuente Completa RAG → QA del Sherpa (4 tipos de pregunta) → Activación + verificación (documento maestro A · recuperación directa upload del .md al RAG en voz, por chunks B · aplicación/inferencia + 5 preguntas de humo con prioridad RAG) C · preguntas de borde (qué NO cubre) + Sherpa live D · preguntas trampa (no alucinar) ``` - **Thresholds:** Score ≥8.0 → publica · 7.0–7.9 → revisión humana · <7.0 → mapa de retrabajo. Tipo D: **0 fallos permitidos**. - Para la **Línea B (MasterPlaybook Inteligente)**, este módulo *es* la configuración del SherpaIA del MPI; se suma a los templates de artefactos. Para las demás líneas, produce el Sherpa de la pieza (del libro, de la categoría, de la empresa). ### §4.1 · Dos modos de contexto del Sherpa (ajuste 17-jun) El módulo admite dos formas de alimentar al Sherpa; la QA de 4 tipos es la misma para ambos. - **Modo RAG** (Fuente Completa): documento maestro por chunks con prioridad de recuperación. Default histórico de la Book Factory. - **Modo Context Pack** (✅ canónico para **Línea A · Resúmenes**, decisión Victor 17-jun): en lugar de generar el RAG, el Sherpa se alimenta de **tres activos de contexto**: 1. **Destilado del libro** (SuPB-style · esencia comprimida del contenido). 2. **Destilado del autor** (su mundo, posición, obra — comprimido). 3. **Brain Code completo del autor** (`BC-…` en formato CognitiveStack, banco `IB-EL-EmpowerLabs/BC-EL-BrainCodes`). **Gate G0 de reuso/producción (regla Victor):** si el equipo **proporciona** el destilado y/o el BC, se validan y se usan. Si **no se proporcionan**, el Sherpa (Jay) **consulta el banco de BC**: si ya existe el BC del autor, se reutiliza; si no existe, **decide si producirlo** según el valor del autor (un BC completo para autores recurrentes/estratégicos; solo destilado para los de una sola pieza). Nada se produce de cero si ya existe. Skills relacionados: `brain-code-saver` (persiste el BC en el banco), Book Distiller (genera el destilado SuPB-). --- ## §5 · Las líneas (instancias del backbone) Cuatro líneas vigentes. El backbone es idéntico; cambia el perfil de instancia. | Dimensión | **A · Resúmenes / Best Seller** | **B · MasterPlaybook (Est./Intel.)** | **C · Guías & Reviews** | **D · Playbooks de Empresa** | |---|---|---|---|---| | **Input** | Libro de 3ro (título, PDF o destilado) | Autor + su expertise (de cero) | Categoría / decisión de compra | Una empresa: procesos + conocimiento operativo | | **Cliente / consumidor** | Lector MasterPlaybooks | Autor experto (y sus lectores) | Comprador (B2C/B2B) | La empresa (uso interno) | | **Voz** | Voz del autor del libro (perfil intelectual) | VOX destilada del autor | Voz editorial experta e **imparcial** | Filosofía operativa / BrainOS de la empresa | | **Output al lector** | Resumen publicable (.docx) | MasterPlaybook completo | Guía comparativa / review | Playbook corporativo + SOPs | | **Capa Sherpa** | Sherpa del libro | SherpaIA configurable + templates | Asesor de compra de la categoría | Copiloto operativo interno (SOP vivo) | | **QA crítico** | Fidelidad de voz | Test VOX ≥90% + arquitectura MPB | **Fact-check (precios/specs) + imparcialidad** (riesgo legal) | Precisión operativa + cumplimiento | | **Monetización** | Plataforma | Premium (capa inteligente) | **Afiliados / lead-gen** (liga a LoopXDG) | Servicio a empresa (vía HIOrg) | | **Pipeline base hoy** | `SOP-MPX-BookFactorySistema-v02` (E0–E8) | `CP-MPX-PublishingMetaFactoryPlan-v01` (8 fases) | A diseñar (instancia nueva) | A diseñar (instancia nueva, apoya en BrainOS) | | **Estado** | 🟢 diseñado · ~9 libros resumidos | 🟢 diseñado · falta correr 1 end-to-end | 🟡 nueva · backbone aplica, falta perfil | 🟡 nueva · backbone aplica, falta perfil + frontera | > **Ranura abierta (Línea E+).** El backbone admite líneas adicionales (p. ej. artículos/papers, contenido social) sin rediseño. Entran cuando el LoopXOP-Editorial las priorice y se les defina su perfil de instancia. *Nota: contenido social y media/audio-video ya tienen factorías propias (Content / MediaFactory); solo migran aquí si conviene unificarlas bajo este backbone.* ### Notas por línea - **Línea A — Resúmenes / Best Seller.** Es la más madura. Diferenciación de entrega (pedido de Victor): el cliente puede darnos **el título**, **el PDF del resumen**, o **una versión destilada** — la factoría produce desde cualquiera de esos puntos de entrada. Cuando el libro no está disponible, se activa la reconstrucción (Libro Virtual) dentro del Bloque 0/1. **Sherpa en modo Context Pack** (no RAG): destilado del libro + destilado del autor + BC completo del autor (ver §4.1). - **Línea B — MasterPlaybook.** El proceso completo de cero, con el autor. Tipo A (Estándar) vs Tipo B (Inteligente, con SherpaIA + templates + pricing premium) se tipifica en el Bloque 0. - **Línea C — Guías & Reviews.** Perfil distinto: el QA pesa hacia **verificación factual y neutralidad** (precios, specs, comparativas de empresas/productos reales → riesgo legal de difamación; nunca afirmaciones sin fuente). Única línea con monetización nativa por afiliados/lead-gen, lo que la enlaza directo al LoopXDG (DemandGen). Su "voz" es editorial-evaluadora, no la de un autor. - **Línea D — Playbooks de Empresa.** Ver §5.1 (frontera con HIOrg). ### §5.1 · Frontera de la Línea D — Editorial vs HIOrg La Línea D pisa el terreno de HIOrg / BrainOS / WORX. La frontera se fija así: > La **Factoría Editorial produce** el activo de conocimiento de la empresa (el playbook/SOP documentado y su Sherpa) — es la **línea de producción**. **HIOrg lo opera** — es el **sistema operativo** que hace correr a la organización con esos activos. - Se **produce aquí**, se **opera allá**. El input de la Línea D (procesos, conocimiento tácito) llega típicamente del contexto BrainOS/HIOrg de la empresa; el output (playbooks + SOPs + copiloto interno) se entrega a la operación HIOrg. - Implicación: la Línea D no es un entregable HIOrg disfrazado de libro, ni un libro que pretende operar la empresa. Es la fábrica que convierte el conocimiento operativo en activos estructurados y vivos. --- ## §6 · Reconciliación de numeraciones (el huevo de Colón) Hoy lo mismo se nombra de tres maneras. El backbone las unifica. Esta tabla es la **piedra Rosetta**: al ratificar este MAP, las tres se leen contra los 4 bloques. | Backbone canónico | MPMF (línea B · 8 fases) | Book Factory (línea A · E0–E8) | Loops del TP (E1–E5) | |---|---|---|---| | **Bloque 0 · Entrada & Viabilidad** | F1 Concepto/Book Brief · F2 Investigación+Viabilidad · F3 Pitch (Gates 1–3) | E0 Intake · E1 Investigación · (E2 Libro Virtual condicional) | pre-E2 · arranque | | **Bloque 1 · Arquitectura Editorial** | F4A Author OS · arquitectura de capítulos | E3 Perfil Intelectual (lentes · voz · filtros) | E1 Voz (VOX) · E2 Arquitectura | | **Bloque 2 · Producción + QA** | F4C Capítulos · F4D Estilo · F4E Imágenes · F5 QA | E4A Resumen · E4B Chunks · E4C Visuales | E3 Producción · E4 Calibración (Test ≥90%) | | **Bloque 3 · Plataforma + SherpaIA** | F6 Templates (Intel.) · F7 Marketing · F8 Publicación | E5 Fuente RAG · E6 QA Sherpa · E7 Publicación · E8 Mantenimiento | (delivery LoopXOP) | | **Módulo compartido · Sherpa** | F6 + Sherpa de plataforma | **E5 → E6 → E7 (patrón origen)** | — | | **Transversal · Conocimiento** | (RunLog) | E8 Mantenimiento / versiones | **E5 Conocimiento (LabPraxis editorial)** | > El **módulo de Sherpa** nace en la línea A (Book Factory E5→E6→E7) y se **gradúa a componente compartido** del backbone — lo reutilizan todas las líneas. Ese es el mayor hallazgo de esta unificación. --- ## §7 · Gobernanza · naming · ubicación - **Casa:** `IB-MPX-MasterPlaybooks/PB-MPX-FactoriaEditorial` (junto al TP de la máquina, el room de mando y el mapa de constelación). - **Tripleta:** Owner Victor · Sherpa Jay · Ratificador Victor (L3+). El diseño de la estructura y de cada línea es **L3** (decide Victor). - **Gate G0:** consultar este MAP + los pipelines base antes de producir o de crear una línea nueva. Nada de cero. - **Vault-First:** cada activo en su banco, registrado. - **Prefijos / XDoc Maestro:** por cliente de cada línea (patrón hub-spoke) — `XD-MPX-AUT-[Autor]-Master` (B), `XD-MPX-LIB-[Libro]-Master` (A), `XD-MPX-CAT-[Categoría]-Master` (C), `XD-MPX-EMP-[Empresa]-Master` (D). Outputs: `MPI-`/`MPB-`, `RES-`, `GUI-`/`REV-`, `SOP-`/`PLB-` según línea. - **Capa meta:** el **Modelo de Factorías** destilado de operar este backbone gradúa a `IB-XX-Maestro` (MePB Type D) cuando esté probado; esta Factoría Editorial sigue siendo el Caso 0 vivo en `IB-MPX`. --- ## §8 · Gate G0 — lo que ya existe (se reutiliza, no se reconstruye) | Pieza | Activo | Rol en la estructura | |---|---|---| | Orquestador | `DC-MPX-EcosistemaPublicaciones-LoopContract-v01` | LoopXOP-Editorial · decide qué entra al backbone | | Room de mando | `TP-MPX-EcosistemaPublicaciones-Arranque-v01` | Catálogo · fronteras · roadmap | | Máquina + loops | `TP-MPX-FactoriaEditorial-Arranque-v02` | 5 loops E1–E5 · Quick Start de producción | | Pipeline línea B | `CP-MPX-PublishingMetaFactoryPlan-v01` (MPMF) | Las 8 fases de la línea MasterPlaybook | | Pipeline línea A | `SOP-MPX-BookFactorySistema-v02` · `ARQ-MPX-BookFactory-Architecture-v01` | Las estaciones E0–E8 de Resúmenes + el módulo Sherpa origen | | Voz | `TP-EL-VOXFactory` · `vox-distiller` · `VOX-VH-VictorHeredia-v02` | Insumo del Bloque 1 | | Patrón fractal | `PP-EL-LoopX-MacroLoopX-Arquitectura-v01` | "una línea = una instancia del backbone" | | Hub-Spoke | `DC-EL-LoopX-XDocMaestro-HubSpoke-v01` | XDoc Maestro por cliente de cada línea | --- ## §9 · NEXTs - [x] **Ratificar este MAP** (estructura de 4 bloques + módulo Sherpa + 4 líneas) — Victor (L3). ✅ 2026-06-17 - [ ] Confirmar si entra una **5ª línea** (papers/artículos u otra) al backbone. - [ ] Ratificar la **frontera Línea D ↔ HIOrg** (§5.1). - [ ] Graduar el **módulo de Sherpa** de la Book Factory a componente compartido formal (extraerlo del SOP de línea A). - [ ] Unificar las tres numeraciones en los pipelines base contra §6 (actualizar MPMF y SOP con la nota de mapeo). - [ ] ⏸️ **PENDIENTE (en pausa · decisión Victor 17-jun)** — Diseñar el **perfil de instancia** de la Línea C (Guías & Reviews): QA factual + imparcialidad + monetización afiliados/lead-gen. Se retoma después de poner a correr la Línea A. - [ ] ⏸️ **PENDIENTE (en pausa · decisión Victor 17-jun)** — Diseñar el **perfil de instancia** de la Línea D (Playbooks de Empresa): input desde BrainOS, handoff a HIOrg. Se retoma después de la Línea A. - [ ] Definir las **estaciones QA del Bloque 2** (Redacción · Estilo · Formato) como checklist reutilizable por todas las líneas. - [ ] Correr **1 pieza end-to-end** por línea madura (A y B) sobre este backbone para validar la unificación. --- ## CHANGELOG | Versión | Fecha | Cambio | |---|---|---| | v01 · amend | 2026-06-17 | **Ajuste de proceso Línea A** (Victor, con Juan Carlos y Anahí): la capa de Sherpa de Resúmenes se genera como **Context Pack** (destilado del libro + destilado del autor + Brain Code completo del autor) en vez de Fuente Completa RAG. §4.1 añadido con los dos modos (RAG / Context Pack) y el Gate G0 de reuso/producción del BC. §5 nota Línea A actualizada. | | v01 | 2026-06-17 | **Ratificado por Victor (L3). Status → Active.** Estructura canónica de la Factoría Editorial como backbone único de 4 bloques (Entrada & Viabilidad · Arquitectura Editorial · Producción + QA · Plataforma + SherpaIA) + módulo de Sherpa compartido, sobre el que corren N líneas. Define 4 líneas vigentes (A Resúmenes, B MasterPlaybook, C Guías & Reviews, D Playbooks de Empresa) con su diferenciación y la frontera D↔HIOrg. Reconcilia las tres numeraciones previas (P1–P6 / 8 fases MPMF / E0–E8 Book Factory) contra los 4 bloques. Regla de entrada del paquete de producción en Bloque 0; estaciones QA explícitas en Bloque 2; SherpaIA del MPI = módulo Sherpa compartido (origen Book Factory). Pendiente ratificación L3. |