---
type: PP
asset_id: PP-XX-BMF-MetaLoopX-Arquitectura-v01
version: v01
status: Draft — recomendación para ratificación de Victor
owner: Victor Heredia
sherpa_owner: Jay
ratificador: Victor Heredia
fecha_creacion: 2026-06-13
intellbank: IB-XX-Maestro
subbank: IPI-XX-IP-Infraestructura/IPI-XX-BMF-Engine
proposito: Arquitectura del MetaLoopX — el loop de orden superior de la BigMetaFactory. Orbita FACTORÍAS (no productos): gobierna su concepción, construcción, maduración, operación y replicación. Es el motor de la fábrica de fábricas. Eleva la "Capa 1 — sistema nervioso" de ArquitecturaFactorias a un loop gobernado, consume al MetaFactoryBuilder como productor y enmarca al MacroLoopX como lo que corre DENTRO de cada factoría operando
relacionados: "PP-EL-LoopX-MacroLoopX-Arquitectura-v01 · DC-EL-LoopX-XDocMaestro-HubSpoke-v01 · ARQ-XX-BMF-ArquitecturaFactorias-v01 · MePB-BMF-MetaFactoryBuilder-v01 · MF-BMF-FactoryOS-v01 · DC-XX-BMF-FactoryOS-Concepto-v01 · ARQ-XX-BMF-Architecture-v01"
tags: [metaloopx, macroloopx, bmf, factoria-de-factorias, metafactoria, factoryos, recursion, fractal, gobernanza, arquitectura]
---

# MetaLoopX — Arquitectura de la fábrica de fábricas
## El loop de orden superior de la BigMetaFactory · orbita factorías, no productos

> **La tesis:** la BigMetaFactory no produce productos — produce **factorías**. Así como el MacroLoopX formaliza cómo una *idea* se vuelve producto→demanda→cliente→entrega→mejora, el **MetaLoopX** formaliza cómo una *factoría* nace, se construye, madura, opera y se vuelve replicable. Su unidad orbital es la factoría misma (MetaFactoría o factoría de dominio), y abarca tanto las factorías de EmpowerLabs (Caso 0) como las de clientes futuros. Es el verdadero motor que da vida al ecosistema: el que regula y hace visible la construcción del sistema-de-sistemas.
>
> **Qué NO es:** no reemplaza al MacroLoopX ni al MetaFactoryBuilder ni al Factory OS. El MetaLoopX **orquesta**; el MetaFactoryBuilder y el Factory Builder **producen** las factorías; el Factory OS las **opera**; el MacroLoopX es lo que **corre dentro** de una factoría una vez que ésta llega a Operando. Misma invariante que el MacroLoopX, un nivel arriba: *los loops orquestan, las factorías producen — nunca soldar.*

---

## 1. Análisis — qué ya tenemos y por qué falta el loop (Gate G0)

### 1.1 Lo que ya existe y se aprovecha

| Pieza existente | Estado | Rol en el MetaLoopX |
|---|---|---|
| **ARQ-XX-BMF-ArquitecturaFactorias-v01** | Draft canónico (abr-2026) | Define el mapa de factorías (FI-SHA, FI-PUB, FI-GTM, FI-ET, FI-BC, soporte) y su **modelo de madurez** (MetaPlaybook · Factory OS · Brain Codes · Telemetría). Su **"Capa 1 — sistema nervioso (Plan→Ejecuta→Mide→Mejora)"** es justo el hueco que el MetaLoopX llena: ahí estaba descrito el ciclo, pero sin loop gobernado, sin contrato, sin gravedad, sin tablero |
| **MePB-BMF-MetaFactoryBuilder-v01** | Draft | El sistema que **produce** Domain MetaFactories (Type D / L2) y delega a Factory Builders (L1). ES el productor principal dentro del MetaLoopX (análogo a MF-GTM dentro de LoopXPR) |
| **Factory OS (MF-BMF-FactoryOS-v01 · DC-XX-BMF-FactoryOS-Concepto-v01)** | Operando (FOS-PUB-EL Caso 0) | El **runtime** que hace que una factoría opere (State Tracker, Gates, Telemetry). Es lo que cruza una factoría de "Instanciada" a "Operando" |
| **PP-EL-LoopX-MacroLoopX-Arquitectura-v01** | Ratificado (jun-2026) | El proceso de 5 loops (PR·DG·SA·OP·KZ) que **corre dentro** de una factoría operando. La regla fractal del XDocMaestro §5 ya lo anticipaba: *"una factoría = la instancia del MacroLoopX de un dominio"* |
| **DC-EL-LoopX-XDocMaestro-HubSpoke-v01** | Active | El patrón hub-and-spoke + la regla fractal (caso MONEX). El MetaLoopX hereda el patrón: cada factoría tendrá su **XDoc Maestro de Factoría** |
| **ARQ-XX-BMF-Architecture-v01** | Active | La arquitectura del ecosistema (capas Conocimiento→SOMA→Metodología→Motores→Interfaz→Org→Gobernanza). El MetaLoopX vive en la capa de Gobernanza/Motores como el ciclo que regula la construcción de factorías |

**Conclusión del análisis:** igual que con el MacroLoopX, *no falta construcción — falta el loop que conecte*. Tenemos el productor (MetaFactoryBuilder), el runtime (Factory OS), el mapa (ArquitecturaFactorias) y el proceso interno (MacroLoopX). Lo que no existe es el **ciclo gobernado que los orquesta**: que sepa, en todo momento, en qué fase de maduración está cada factoría, qué la bloquea, qué gate le falta cruzar y cuándo está lista para replicarse en un cliente. Eso es el MetaLoopX.

### 1.2 La corrección conceptual — dónde encaja sin duplicar

El error fácil sería tratar esto como "otro loop del MacroLoopX". No lo es. La unidad orbital del MacroLoopX es la idea/producto/prospecto/entrega. La unidad orbital del MetaLoopX es **la factoría completa**. Es un nivel de recursión arriba:

> **MetaLoopX : factoría :: MacroLoopX : producto.**
> El MetaFactoryBuilder es al MetaLoopX lo que MF-GTM es al LoopXPR: el productor que vive dentro del loop, conectado por interfaz, nunca soldado.

---

## 2. El MetaLoopX — la unidad orbita la factoría

### 2.1 Los estados orbitales de una factoría

Una factoría, vista desde el MetaLoopX, orbita por cinco estados (derivados del modelo de madurez de ArquitecturaFactorias §VIII y del lifecycle del MetaFactoryBuilder §4):

```
  CONCEBIDA → BLUEPRINT (L2) → INSTANCIADA (L3) → OPERANDO → REPLICABLE/GRADUADA
  (intent)    (Type D MePB)     (Factory OS +      (produce con   (Caso 0 probado ·
                                 BrainCodes)        telemetría ·   activo vendible ·
                                                    corre su        instalable en cliente)
                                                    MacroLoopX)
```

| Estado | Qué significa | Evidencia / artefacto |
|--------|---------------|------------------------|
| **Concebida** | La factoría existe como intención declarada (un dominio identificado en el mapa, aún sin blueprint) | Entrada en el mapa de ArquitecturaFactorias marcada "❌ NO EXISTE" / Intent Declaration |
| **Blueprint (L2)** | Tiene su Domain MetaFactory MetaPlaybook (Type D) producido por el MetaFactoryBuilder y QA-PASS | MePB Type D · Hardened/Canonical |
| **Instanciada (L3)** | Tiene Factory OS construido + Brain Codes inyectados; la instancia existe pero aún no produce con régimen | FOS-* · BC-* asociados |
| **Operando** | Produce output medible con telemetría; **corre su propio MacroLoopX** (los 5 loops sobre sus productos/clientes) | Telemetría activa · dashboard MacroLoopX vivo |
| **Replicable / Graduada** | Probada como Caso 0; empaquetada como activo vendible/instalable en clientes (la meta-regla de ArquitecturaFactorias §VII) | MePB graduado a capa universal · primer cliente instanciado |

### 2.2 La recursión de 3 niveles (lo que Victor pide visualizar)

```
┌─────────────────────────────────────────────────────────────────────┐
│  METALOOPX · BigMetaFactory          ← orbita FACTORÍAS              │
│  Concebida → Blueprint → Instanciada → Operando → Replicable         │
│  Productores: MetaFactoryBuilder · Factory Builder · Factory OS      │
└───────────────┬───────────────────────────────────────┬─────────────┘
                │ (una factoría llega a "Operando")       │
                ▼                                         ▼
   ┌────────────────────────────┐          ┌────────────────────────────┐
   │ MACROLOOPX · Factoría EL    │          │ MACROLOOPX · Factoría Cliente│
   │ orbita PRODUCTOS/CLIENTES   │   ...    │ (futuro — misma arquitectura)│
   │ PR→DG→SA→OP→KZ              │          │ PR→DG→SA→OP→KZ               │
   └───────────┬────────────────┘          └──────────────────────────────┘
               │ (cada loop)
               ▼
        producto · prospecto · entrega   ← la unidad del MacroLoopX
```

- **Nivel BMF (MetaLoopX):** el tablero de la fábrica de fábricas. Cada tarjeta = una factoría con su estado de maduración y su gravedad.
- **Nivel Factoría (MacroLoopX):** cuando una factoría llega a *Operando*, su tarjeta enlaza a su instancia MacroLoopX (el dashboard de 5 loops que ya existe).
- **Nivel Unidad:** el detalle de producto/prospecto/entrega dentro de cada loop.

Las factorías de clientes **no** viven en el tablero de EL: igual que la regla fractal del MacroLoopX (los clientes de MONEX viven en el tablero de MONEX), las factorías de un cliente viven en la instancia MetaLoopX de ese cliente. En el tablero BMF de EmpowerLabs, un cliente aparece una vez como una factoría replicada, con link a su propia instancia.

---

## 3. El Factory Loop Contract — harness de toda factoría en órbita

Toda factoría instanciada en el MetaLoopX se gobierna con un contrato (paralelo al Loop Contract de 10 elementos del MacroLoopX, instanciado para factorías):

1. **Identidad:** código de factoría (FI-*) + dominio + instancia (EL interno / cliente)
2. **Misión** de la factoría (qué produce) + tipo de output medible
3. **Métrica de gravedad de factoría** (§3.1)
4. **Estado orbital** actual (Concebida→…→Replicable) + última transición
5. **Equipo:** humanos (tripleta) + agentes IA con nivel de autonomía
6. **BrainX Advisory de factoría** (opcional): qué Brain Codes asesoran su construcción/operación
7. **Productores conectados:** MetaFactoryBuilder (blueprint), Factory Builder (instanciación), Factory OS (runtime) — por interfaz, nunca soldados
8. **Gates de maduración** (§4.1) + criterios PASS
9. **Tablero:** su XDoc Maestro de Factoría (fuente de verdad) + tarjeta en el dashboard BMF; si Operando, link a su MacroLoopX
10. **Rituales:** cadencia de revisión de maduración, sync con minuta/dashboard, reporte de aprendizajes a LoopXKZ del MacroLoopX y al LabPraxis BMF

### 3.1 Gravedad de factoría (generalización del modelo de madurez)

La gravedad de una factoría = qué tan cerca está de ser un activo replicable y autónomo. Se compone de la tabla de inventario de ArquitecturaFactorias §VIII:

| Componente | Fuente automática | Fuente de criterio humano |
|------------|-------------------|---------------------------|
| MetaPlaybook (Type D) | ✅/❌ en Control Plane | QA del MetaFactoryBuilder |
| Factory OS | ✅/❌ runtime activo | Lectura del builder |
| Brain Codes | nº de BC asociados | Pertinencia del consejo |
| Telemetría | datos reales fluyendo | Salud operativa (delivery lead) |
| Autonomía del Hero-Operator | dependencia de Victor (alta→baja) | Criterio de Victor (¿escala sin mí?) |

> La gravedad alta = factoría con MePB + Factory OS + Brain Codes + telemetría + baja dependencia del fundador = lista para graduar y vender. Es la traducción operativa de la ecuación final de ArquitecturaFactorias: *1 MetaPlaybook + 1 Factory OS + N Brain Codes = 1 factoría operativa.*

---

## 4. Gobernanza del MetaLoopX

### 4.1 Gates de maduración (los handoffs entre estados)

| Gate | De → A | Cruza cuando | Productor responsable |
|------|--------|--------------|------------------------|
| **G-CO→BP** | Concebida → Blueprint | Intent + Domain Declaration aprobados | MetaFactoryBuilder (produce Type D, QA Hard Gate PASS) |
| **G-BP→IN** | Blueprint → Instanciada | MePB Type D Hardened + Factory Builder instancia + Brain Codes inyectados | Factory Builder (L1) |
| **G-IN→OP** | Instanciada → Operando | Factory OS activo + primera corrida con telemetría + arranca su MacroLoopX | Factory OS |
| **G-OP→RE** | Operando → Replicable | Caso 0 probado (output con resultado) + dependencia del fundador baja + MePB graduable a universal | Victor (decisión L3) + MetaFactoryBuilder (promoción) |

### 4.2 Matriz de autonomía (hereda del MacroLoopX §4.2)

| Valor × complejidad | Agente IA | Humano |
|---------------------|-----------|--------|
| Bajo (telemetría, status, registro) | Ejecuta autónomo, reporta | Audita por muestreo |
| Medio (preparar blueprint, ensamblar Brain Codes) | Propone con opt-out | Ratifica por excepción |
| Alto (**graduar una factoría, decidir construir una nueva, instanciar en cliente, cambios de arquitectura BMF**) | Prepara y recomienda | **Victor decide siempre (L3)** |

### 4.3 Invariantes (no negociables)

1. **El MetaLoopX orquesta; el MetaFactoryBuilder/Factory Builder/Factory OS producen y operan.** Nunca soldar el loop a un builder (extiende la regla del escenario B un nivel arriba).
2. **Una factoría no entra a Operando sin Factory OS** — sin runtime, sigue siendo blueprint o instancia, no factoría viva.
3. **Una factoría no se gradúa a Replicable sin Caso 0 probado** — la meta-regla "lo que construyes para ti es vendible" exige evidencia, no promesa.
4. **Toda factoría en el tablero tiene XDoc Maestro de Factoría** o se marca "por crear" (deuda visible) — hereda la regla del XDocMaestro.
5. **Toda factoría que cruza un gate viaja con su contexto completo** (no hay handoffs ciegos).
6. **Vault-First + naming BMF:** los artefactos viven en su banco, registrados en el Registry maestro.

### 4.4 BrainX Advisory de construcción (propuesto)

| Estado/decisión | Consejo propuesto |
|-----------------|-------------------|
| Concebir factoría (¿qué dominio?) | Clayton Christensen (jobs-to-be-done) + Geoffrey Moore |
| Blueprint (diseño de MetaFactoría) | el propio MetaFactoryBuilder + Toyota (estandarización) |
| Operación/escala | Kaizen Toyota + Eli Goldratt (teoría de restricciones) |
| Graduar/replicar a cliente | Criterio Victor + casos LabPraxis |

---

## 5. Jerarquía de tableros (3 niveles, espejo de la recursión)

1. **Tablero MetaLoopX (BMF)** — `BRD-XX-BMF-MetaLoopX-Dashboard-v01`. Una tarjeta por factoría (EL + clientes), su estado de maduración y gravedad. **Este room lo construye.**
2. **Tablero MacroLoopX (por factoría)** — el BRD-EL-MacroLoopX-Dashboard-v02 ya existente es la instancia de la factoría EL. Cada factoría operando tiene el suyo; la tarjeta del nivel 1 enlaza aquí.
3. **Tablero por unidad** — producto/prospecto/entrega, dentro de cada MacroLoopX.

Regla heredada: **el tablero visualiza; el XDoc Maestro de Factoría es la fuente de verdad.** Enlace vía `obsidian://open?vault=Intellibanks&file=...`.

---

## 6. Capas BMF e instanciación

- **L0/L1 (builders):** el MetaFactoryBuilder y el Factory Builder ya son la maquinaria de producción. El MetaLoopX es el **ciclo de gobernanza** que los activa y secuencia — la "Capa 1 sistema nervioso" de ArquitecturaFactorias, ahora formalizada.
- **L2 (blueprint):** este paper define el patrón MetaLoopX. Si se ratifica, se gradúa como MePB Type D del dominio "Factory Lifecycle" en IB-XX-Maestro.
- **L3 (instancias):** EmpowerLabs es la primera (Caso 0). Cada cliente futuro recibe su propia instancia MetaLoopX cuando EL le instala su fábrica de fábricas.

**Inventario inicial de factorías para el tablero** (de ArquitecturaFactorias §VIII, con su estado estimado hoy):

| Factoría | Estado orbital estimado | Notas |
|----------|--------------------------|-------|
| FI-PUB (Publishing / Editorial) | 🟢 Operando | MePB ✅ · FOS-PUB-EL ✅ · Caso 0 más maduro |
| FI-SHA (SherpaX) | 🟡 Instanciada (sin FOS) | MePB ✅ · FOS ❌ · opera en modo Hero-Operator |
| FI-GTM (Go-to-Market) | 🟡 Blueprint→Instanciada | MePB ✅ (MF-GTM) · FOS ❌ · pipeline probado |
| FAC-DemandGenPack | 🟡 Blueprint | MePB en este room · es productor de LoopXDG |
| FI-EmpowerScan (diagnósticos) | 🟡 Concebida→Blueprint | producto en LoopXPR ~70% · factoría de delivery |
| FI-ET (EmpowerTeams) | 🔴 Concebida | solo metodología · gap estratégico (el puente) |
| FI-BC (Brain Codes) | 🔴 Concebida | proceso orgánico · sin pipeline formal |
| Soporte (Legal/Finance/Ops) | ⚪ Capa 3 | baja prioridad estratégica |

---

## 7. Ruta de implementación propuesta

| # | Paso | Output | Esfuerzo |
|---|------|--------|----------|
| 1 | Ratificar esta arquitectura (naming MetaLoopX, estados, gates, invariantes) | Este PP → Active | Decisión Victor |
| 2 | Construir el tablero BMF MetaLoopX (nivel 1) con el inventario §6 | BRD-XX-BMF-MetaLoopX-Dashboard-v01 | 🟢 (este room) |
| 3 | Crear el primer XDoc Maestro de Factoría (FI-PUB, la más madura) como patrón | XD-XX-FAC-Publishing-Master-v01 | 🟢 |
| 4 | Reconciliar ArquitecturaFactorias-v01 → v02 (declarar Capa 1 = MetaLoopX) | ARQ v02 | 🟡 |
| 5 | Factory Loop Contract de FI-SHA (la brecha crítica: instanciada sin FOS) | 1 contrato + plan FOS-SHA | 🟡 |
| 6 | Graduar el patrón a MePB Type D "Factory Lifecycle" vía MetaFactoryBuilder | MePB-XX-BMF-MetaLoopX | 🟡 — tras validar en EL |
| 7 | Primera instancia MetaLoopX de cliente (cuando EL instale una fábrica de fábricas) | Instancia L3 cliente | 🔵 — futuro |

## CHANGELOG

| Versión | Fecha | Cambio |
|---------|-------|--------|
| v01 | 2026-06-13 | Creación. Arquitectura MetaLoopX: el loop de orden superior que orbita factorías (Concebida→Blueprint→Instanciada→Operando→Replicable), Factory Loop Contract, gravedad de factoría derivada del modelo de madurez de ArquitecturaFactorias, 4 gates de maduración, matriz de autonomía, invariantes, jerarquía de 3 tableros y recursión con el MacroLoopX. Integra (no duplica) ArquitecturaFactorias, MetaFactoryBuilder y Factory OS. Draft — recomendación para ratificación |