---
type: DC
asset_id: DC-EL-LoopX-InfraestructuraTecnica-v01
version: v01
status: Canonical · documento de criterio · paso 3 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 · infraestructura técnica de BrainX Loop
motor: BrainX Loop (código de proyecto: LoopX)
proposito: >
  Cerrar el paso 3 de la agenda de diseño: definir el stack que soporta BrainX Loop,
  qué se reusa vs. qué se construye, las decisiones de arquitectura técnica, el esquema
  completo de XDoc Loop, y el sketch del spec del motor BrainX (Loop como referencia).
  Principio rector: no sobre-construir; reusar todo lo existente y construir lo mínimo
  para el piloto high-end.
referencia_canonica:
  - XP-EL-LoopX-DisenoYPiloto-v01 (XPack del Room)
  - DC-EL-LoopX-NaturalezaDelSistema-v01 (paso 1)
  - PP-EL-LoopX-ConceptoYModelo-v01 (paper vivo · modelo operativo paso 2)
  - DC-EL-LoopX-HighLevelMCP-EvaluacionDesarrollo-v01 (puente OneRocket↔Vault)
  - DC-XX-WORX-TaxonomiaXDoc-v01 (familia XDoc · XDoc Loop)
  - PP-XX-SX-SherpaXComoPlataforma-BrainX-v01 (plataforma · spec del motor)
tags: [dc, brainx-loop, loopx, infraestructura, vault-native, xdoc-loop, gravity-score, mcp, spec-motor, paso-3]
---

# BrainX Loop — infraestructura técnica

## Paso 3 de la fase de diseño · decisiones de arquitectura

---

## 1. Principio rector

No sobre-construir. Reusar todo lo que ya existe en el ecosistema y construir solo lo mínimo necesario para el piloto high-end. La sofisticación (DB estructurada, scoring aprendido, sub-agentes, artefacto vivo) entra después, cuando el volumen o el escalamiento lo exijan.

---

## 2. Inventario · reusar vs. construir

| Componente | Estado | Rol en BrainX Loop |
|---|---|---|
| OneRocket (sobre HighLevel) | Existe | Capa de ejecución · vía MCP |
| MasterPlaybooks Inteligentes | Existe | Canal de entrada + fuente de señal automática |
| Vault (IntelliBanks / BMF) | Existe | Capa de criterio y memoria · hogar del XDoc Loop |
| BrainCodes | Existe | Calibración del motor + perfiles de decision makers |
| SherpaX + Cowork / Agent SDK | Existe | Host + runtime del motor |
| XDoc Loop (plantilla + store) | Construir | Artefacto de criterio tipado por prospecto |
| Motor gravity score | Construir | Fusión señal automática + criterio humano |
| Tablero Loop | Construir | Vista orbital agregada |
| Puente OneRocket↔Vault | Parcial | MCP ya existe; falta verificar herencia + lógica de sync |
| Spec del motor BrainX | Construir | Estándar reusable (Loop = referencia) |

---

## 3. Decisiones de arquitectura

**3.1 Vault-native (markdown) para el piloto.** El criterio, el dark social y las decisiones viven como XDoc Loop en markdown versionable en el Vault —donde ya vive todo y lo ve BrainOS/Wiki. La data estructurada de alta frecuencia (engagement, etapa, gravity numérico) se espeja desde OneRocket vía el frontmatter tipado. Un store estructurado (DB) entra solo al escalar a instancias de alto volumen.

**3.2 Un solo agente-motor con skills, no sub-agentes.** Para el piloto, un BrainX Loop con su set de skills (vigilancia, scoring, redacción, ejecución, memoria) que el SherpaX invoca. Más simple, más barato en contexto, más fácil de calibrar. La descomposición en sub-agentes reales entra solo cuando el volumen/paralelismo lo exija.

**3.3 Gravity score por reglas/heurística, no ML.** Una fórmula transparente y calibrable a mano que fusiona señal automática + criterio humano. El "R&D empírico" del XPack. El scoring aprendido viene después, con datos del piloto.

**3.4 El puente = MCP de HighLevel, sujeto a prueba de humo.** Lectura alimenta gravity; escritura ejecuta. La verificación OneRocket↔MCP (ver doc del equipo de desarrollo) es la compuerta que desbloquea esta capa. Detalle técnico, scopes y checklist en `DC-EL-LoopX-HighLevelMCP-EvaluacionDesarrollo-v01`.

**3.5 Tablero Loop = vista renderizada ligera primero.** Un HTML/artefacto generado desde los XDoc Loop + gravity, refrescable. Puede evolucionar a artefacto vivo que jala data en tiempo real más adelante.

**3.6 El spec del motor BrainX como subproducto.** Al construir Loop se define el estándar de motor (sección 6).

---

## 4. Esquema canónico de XDoc Loop · perfiles por ticket

XDoc Loop es la variante tipada del XDoc base (ver `DC-XX-WORX-TaxonomiaXDoc-v01`). Conserva las 7 secciones canónicas y las 11 reglas inviolables; añade frontmatter tipado. No es un documento único: tiene **3 perfiles alineados a los 3 niveles de autonomía** (paso 2). La forma (7 secciones) es invariante; lo que cambia entre perfiles es la profundidad de cada sección, el frontmatter, quién la llena y el peso del gravity.

| Perfil | Tier | Decision makers | Gravity dominante | Profundidad del doc |
|---|---|---|---|---|
| **XDoc Loop · High-Ticket** | 3 · decisión humana | Comité de compra | Criterio humano | Rica (mapa de cuenta, dark social pesado) |
| **XDoc Loop · Mid** | 2 · propuesta opt-out | Pocos | Balanceado | Media (interpolación) |
| **XDoc Loop · Velocity** | 1 · autónomo | Uno | Señal automática | Ligera (frontmatter hace el trabajo) |

Para el piloto se construye a fondo **High-Ticket** (plantilla lista: `XD-EL-Loop-Plantilla-HighTicket-v01`); Velocity queda como sketch (§4.3) y Mid emerge por interpolación.

**4.1 Frontmatter — perfil High-Ticket:**

```yaml
type: XD
asset_id: XD-EL-Loop-HiOrg-[Prospecto]-vNN
variante: XDoc-Loop
perfil: high-ticket
motor: BrainX Loop
instancia: B2B-HiOrg
prospecto: [empresa / cuenta]
deal_value_est: [estimado $]
owner: [humano]
sponsor: [humano]
gravity_score: [0-100]
gravity_breakdown: {signal_auto: [..], signal_humano: [..]}   # high-ticket: pesa lo humano
orbit_state: [entrante | acercándose | caliente | enfriándose | latente | salida]
value_tier: high-ticket
autonomia: decisión-humana
decision_maker_principal: [nombre]
buying_committee:
  - {nombre, rol, postura: [champion|neutral|bloqueador], braincode}
competidores: [..]
riesgo_principal: [..]
next_review: [fecha]
status: [activo | pausado | ganado | perdido]
ultima_actualizacion: [fecha]
```

**4.2 Las 7 secciones — instanciación High-Ticket:**

- **CONTEXTO** *(Owner, una vez)* — la cuenta, el problema, el resultado esperado · **mapa del buying committee** (cada decision maker con su postura y su BrainCode) · narrativa/posicionamiento de entrada · por qué es high-ticket.
- **ESTADO** *(Owner+Sherpa)* — gravity + desglose auto/humano (por stakeholder si aplica) · estado de órbita · última señal · dependencias · bloqueos · riesgo · competidores.
- **PROTOCOLO** — Tier 3: el humano decide todo lo clave; el Sherpa prepara y propone · reglas específicas de la cuenta.
- **NEXT** — siguiente movimiento, hacia qué stakeholder, con qué objetivo.
- **DISCUSSION** — *la sección más pesada en high-ticket:* inteligencia de dark social por stakeholder, política interna, lo que se oyó, hipótesis. Donde vive la ventaja.
- **CHANGELOG** — bitácora append-only de cada touchpoint y movimiento de órbita.
- **CIERRE** — desenlace + aprendizaje + (si ganado) semilla de caso de éxito para M2 Evidence.

**4.3 Perfil Velocity (sketch para fase posterior):** mismo esqueleto, pero el frontmatter hace casi todo el trabajo y las 7 secciones se colapsan a mínimas (CONTEXTO de una línea, ESTADO autopoblado por señal, PROTOCOLO Tier 1 por referencia, NEXT autosugerido, DISCUSSION opcional, CHANGELOG autologueado, CIERRE flag ganado/perdido). El Sherpa lo mantiene solo; diseñado para volumen.

**4.4 Convención de instancia:** prefijo `XD-` (estándar WORX). Un XDoc Loop concreto: `XD-EL-Loop-[Instancia]-[Prospecto]-vNN`. Plantilla lista para copiar: `XD-EL-Loop-Plantilla-HighTicket-v01`.

---

## 5. Flujo de datos (el loop operativo, técnico)

1. **Señal entra** — MasterPlaybooks + OneRocket generan engagement; el motor lo lee vía MCP.
2. **El motor actualiza** el `signal_auto` y recalcula la parte automática del gravity en el XDoc Loop.
3. **El humano aporta** dark social/criterio vía su SherpaX → se deposita en DISCUSSION y ajusta `signal_humano`.
4. **Gravity se fusiona** (regla transparente) → `gravity_score` + `orbit_state`.
5. **El motor prioriza** el Tablero y propone NEXT según `autonomia`.
6. **Ejecución** — autónoma (vía OneRocket) o con visto bueno humano, según el nivel.
7. **CHANGELOG** registra; el loop reinicia.

---

## 6. Sketch del spec del motor BrainX (Loop como referencia)

Como BrainX Loop es el motor de referencia, su construcción define qué declara cualquier motor para enchufarse al SherpaX:

- **(a) Contexto que lee del dueño** — qué del SherpaX necesita (perfil, voz, criterio, relaciones).
- **(b) Set de skills/herramientas** — las capacidades que trae (Loop: vigilancia, scoring, redacción, ejecución, memoria).
- **(c) Objeto de datos** — su variante de XDoc (Loop: XDoc Loop, con su esquema tipado).
- **(d) Política de autonomía** — la regla de cuándo actúa solo vs. interrumpe (Loop: por value_tier × complejidad).
- **(e) Conectores de ejecución** — a qué sistemas escribe (Loop: OneRocket vía MCP).

Este sketch se promueve a spec formal (`DC-XX-SX-SpecMotorBrainX-vNN`) cuando se construya el segundo motor y se valide el patrón. Por ahora vive como referencia derivada de Loop.

---

## 7. Compuertas y dependencias

- **Compuerta técnica del paso 3:** la prueba de humo OneRocket↔MCP (generar un PIT desde OneRocket y leer contra el endpoint oficial). Hasta confirmarla, la capa de ejecución es supuesto, no hecho.
- **Punto de partida real:** MasterPlaybooks↔OneRocket ya ejecuta tareas básicas bajo control; el build potencia lo existente, no parte de cero.

---

## 8. 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** (este documento).
- Paso 4 — Modelo dentro del BigMetaFactory: pendiente.
- 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 3 cerrado