--- type: DC asset_id: DC-EL-LoopX-ModeloDentroBMF-v01 version: v01 status: Canonical · documento de criterio · paso 4 de la fase de diseño (cerrado) owner: Victor Heredia sherpa_owner: Jay fecha_creacion: 2026-05-30 fecha_ultima_actualizacion: 2026-05-30 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank / PB-LoopX tipo: DC — documento de criterio · modelo operativo de BrainX Loop dentro del BigMetaFactory motor: BrainX Loop (código de proyecto: LoopX) proposito: > Cerrar el paso 4 de la agenda de diseño: cómo se inserta BrainX Loop en el marco BMF. Decisión: escenario B — Loop es una capa de orquestación que se monta AL LADO de la Hybrid Demand MetaFactory (lee de M5, escribe en M6), no soldada dentro de los módulos. Con anotación de que la profundidad de la frontera Loop↔HD es ajustable a futuro. referencia_canonica: - MF-BMF-HybridDemand-v02 (MetaFactory de demanda · módulos M1–M8) - XP-EL-LoopX-DisenoYPiloto-v01 (XPack del Room) - PP-XX-SX-SherpaXComoPlataforma-BrainX-v01 (motores portátiles · razón del escenario B) - DC-EL-LoopX-InfraestructuraTecnica-v01 (paso 3) - PP-EL-LoopX-ConceptoYModelo-v01 (paper vivo) tags: [dc, brainx-loop, loopx, bmf, hybrid-demand, escenario-b, orquestacion, paso-4] --- # BrainX Loop — modelo dentro del BigMetaFactory ## Paso 4 de la fase de diseño · decisión de inserción --- ## 1. La tesis BrainX Loop **no es una factoría nueva ni un pipeline nuevo.** Es la capa de criterio que opera los módulos de demanda que la Hybrid Demand MetaFactory (`MF-BMF-HybridDemand-v02`) ya define —les pone cerebro. El BMF ya sabe capturar, nutrir y convertir; lo que no tenía era el criterio + dark social + gravity que los opera con juicio. --- ## 2. Mapeo con la Hybrid Demand MetaFactory | Módulo HD | Relación con BrainX Loop | |---|---| | M1 Positioning · M2 Evidence · M3 Atomization · M4 Distribution | **Lo alimentan** → producen y distribuyen contenido que culmina en los MasterPlaybooks Inteligentes (canal de entrada + señal automática del gravity) | | M5 Capture & Nurture | **Loop lo orquesta** → lee de aquí los prospectos y la señal | | M6 Conversion · Offer Ladder | **Loop escribe aquí** → la órbita hacia la conversión, graduada por valor × complejidad | | M7 Delivery-to-Demand Loop | **Loop lo cierra** → reinversión: lo trabajado alimenta de vuelta el sistema | **Inbound (lo alimenta):** M1→M4 → MasterPlaybooks Inteligentes. **Feedback (Loop alimenta de vuelta):** M2 Evidence (deal ganado → caso de éxito → más contenido), M7 (reinversión), y el aprendizaje de dark social informa qué produce M1/M3. Esto cierra el growth loop. --- ## 3. La decisión: escenario B (capa de orquestación al lado) Se evaluaron dos escenarios: - **A — Loop upgradea M5/M6 en su lugar** (se vuelve la inteligencia *dentro* de los módulos). - **B — Loop se monta al lado** de la HybridDemand como capa de orquestación que lee de M5 y escribe en M6. **Decisión: escenario B.** El desempate es estratégico, no operativo. Como SherpaX es plataforma y los BrainX son **motores portátiles que se enchufan al host**, el escenario A soldaría Loop a una factoría y arruinaría la plantilla de motor para los demás BrainX (Coach, Sales, etc.). B respeta la arquitectura host↔motor, y además es más rápido de pilotar, más reversible y de menor riesgo. Razones que sostienen B: - **Coherencia con BrainX** — Loop sigue siendo motor portátil, no soldado a HD. - **Reutilización del patrón** — Loop es la plantilla del spec de motor para los siguientes BrainX. - **Acoplamiento suelto** — frontera limpia; si Loop no rinde, HD sigue operando mecánicamente. - **Velocidad y bajo riesgo** — Loop se enchufa sobre M5/M6 existentes sin reescribir el doc canónico de HD. - **Ownership claro** — el equipo HD posee contenido/distribución; SherpaX+Loop posee criterio/orquestación. --- ## 4. Anotación · la frontera Loop↔HD es ajustable "Al lado" no significa desconectado. Loop lee los outputs de M5 y escribe en M6 vía el puente MCP/Vault. La **profundidad de esa frontera es un parámetro de diseño ajustable**: si con el tiempo la integración prueba valor, se puede *profundizar* (Loop asumiendo más de la operación de M5/M6) sin llegar nunca a soldarse. Regla invariante: **nunca soldar el motor a la factoría.** El patrón de motor portátil es el activo estratégico; la profundización de la frontera se permite hasta el límite donde Loop deje de ser desmontable. Cualquier ajuste de frontera se documenta como nueva versión de este DC. --- ## 5. Implicación L2/L3 BrainX Loop es blueprint (L2) que se replica por instancia (L3) —las 5 unidades de negocio—, alineado con el diseño de "instancia por cliente" que la propia HybridDemand contempla en su §8. Cada instancia de Loop orquesta los módulos de demanda de su unidad. --- ## 6. Alcance del feedback a M2 Evidence El feedback de deals ganados → casos de éxito (M2 Evidence) queda **declarado en la arquitectura pero fuera del alcance del piloto inicial**. El piloto high-end se concentra en orquestar M5→M6 con criterio; el cierre del loop hacia Evidence/contenido (M2/M7) entra en fase posterior, una vez validada la operación básica. --- ## 7. Estado de la fase de diseño - Paso 1 — Naturaleza del sistema: **cerrado**. - Paso 2 — Modelo operativo del Sherpa: **cerrado**. - Paso 3 — Infraestructura técnica: **cerrado**. - Paso 4 — Modelo dentro del BigMetaFactory: **cerrado** (este documento · escenario B). - Paso 5 — Conexión con CRM convencional: parcial (depende de la prueba de humo OneRocket↔MCP). --- **Owner:** Victor Heredia · **Sherpa:** Jay · **Fecha:** 2026-05-30 · **Status:** Paso 4 cerrado (escenario B · frontera ajustable)