---
type: DC
asset_id: DC-XX-FAC-SherpaX-LoopContract-v01
version: v01
status: Draft — 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: Factory Loop Contract de FI-SHA (SherpaX) en el MetaLoopX — los 10 elementos del harness de factoría. Ataca la brecha crítica: FI-SHA está Instanciada pero su Factory OS está en Draft, no operacionalizado (dependencia Hero-Operator). Define el plan para cruzar G-IN→OP
relacionados: "PP-XX-BMF-MetaLoopX-Arquitectura-v01 · BRD-XX-BMF-MetaLoopX-Dashboard-v01 · ARQ-XX-BMF-ArquitecturaFactorias-v01 · FOS-EL-BMF-SherpaX-v01 · XD-XX-FAC-Publishing-Master-v01"
tags: [dc, loop-contract, factoria, fi-sha, sherpax, metaloopx, factory-os, brecha-critica]
---

# Factory Loop Contract — FI-SHA · SherpaX
## La brecha crítica: instanciada sin Factory OS operativo

> **Por qué este contrato primero:** FI-SHA tiene MetaPlaybook ✅ y producto validado (SHA-GTM cerrado con GO), pero opera en **modo Hero-Operator** (depende de Victor). Existe un FOS-EL-BMF-SherpaX-v01 pero está en **Draft** — es un esqueleto de runtime de abril, no un runtime operado. Por eso FI-SHA está en **Instanciada (L3)**, no en Operando. Este contrato define qué falta para cruzar **G-IN→OP**.

**Estado orbital hoy:** 🟡 **INSTANCIADA (L3)** · gravedad 55 · bloqueada por FOS no operacionalizado

---

## Los 10 elementos del Factory Loop Contract

### 1. Identidad
- **Factoría:** FI-SHA · SherpaX (Capa 2 — Core)
- **Instancia:** EL interno (Caso 0); futura: por cliente
- **Dominio BrainX:** SX-adyacente / interfaz del ecosistema

### 2. Misión + output medible
- **Misión:** producir e instalar SherpaX para Owners/CEOs (B2O) sin depender de Victor como operador único.
- **Output medible:** instancias SherpaX activas · prospectos en pipeline Ignition · retención mensual.

### 3. Métrica de gravedad de factoría
| Componente | Estado | Nota |
|------------|--------|------|
| MetaPlaybook (Type D) | ✅ | SHA-MetaFactory-v01 + SHA-ProdSpec-Ignition-v01 |
| Factory OS | 🟡 Draft | [[FOS-EL-BMF-SherpaX-v01]] existe como esqueleto (State Tracker abril); **no operacionalizado** |
| Brain Codes | 🟡 | BC-Victor parcial |
| Telemetría | ❌ | sin datos fluyendo en runtime |
| Dependencia del fundador | 🔴 alta | Hero-Operator — la brecha a cerrar |
**Gravedad: 55 / 100.**

### 4. Estados orbitales de la unidad (la factoría)
Concebida ✅ → Blueprint ✅ → **Instanciada (actual)** → Operando ⏳ → Replicable.

### 5. Equipo
- **Humanos (tripleta):** Owner Victor · Sherpa Jay · Ratificador Victor. Operadores futuros: Sherpa Guides (Anahí senior).
- **Agentes IA:** SherpaX mismo (ejecución) · agente de telemetría (registro autónomo, L0) · agente de calibración (propone, L1).

### 6. BrainX Advisory (opcional)
- Construcción/escala: Kaizen Toyota (estandarización) + Eli Goldratt (cuello de botella = Hero-Operator).
- Regla: recomienda y valida — nunca decide. La tripleta decide.

### 7. Productores conectados (por interfaz, nunca soldados)
- **MetaFactoryBuilder** → ya entregó el blueprint (MePB ✅).
- **Factory Builder** → instanció producto + Ignition.
- **Factory OS** → **el eslabón a operacionalizar** (de Draft a runtime vivo).

### 8. Gates de entrada/salida + criterios
- **Gate activo: G-IN→OP.** PASS cuando:
  1. FOS-SHA pasa de Draft a runtime operado (State Tracker vivo + Session Memory + Gate Engine + Telemetry con datos reales).
  2. Al menos un operador distinto de Victor corre una sesión completa con el FOS (prueba de no-dependencia).
  3. Arranca su MacroLoopX (LoopXSA de prospectos SherpaX con gravity tracking).

### 9. Tablero
- **Fuente de verdad:** este contrato + su futuro `XD-XX-FAC-SherpaX-Master-v01` (crear al cruzar a Operando).
- **Visualización:** tarjeta FI-SHA en [[BRD-XX-BMF-MetaLoopX-Dashboard-v01]].

### 10. Rituales
- Revisión de maduración quincenal (¿bajó la dependencia del fundador?).
- Sync con minuta/dashboard semanal de EL.
- Reporte de aprendizajes a LoopXKZ del MacroLoopX y al LabPraxis (CAS-).

---

## Plan para cruzar G-IN→OP (la brecha crítica)

| # | Acción | Output | Dueño |
|---|--------|--------|-------|
| 1 | Operacionalizar FOS-SHA: convertir el esqueleto de abril en runtime vivo (State Tracker + Session Memory + Gate Engine + Telemetry) | FOS-EL-BMF-SherpaX-v02 (Activo, operado) | Alex (infra) + Jay |
| 2 | Cargar datos reales: instancias + prospectos Ignition actuales | Telemetría con datos | Juan Carlos (Ops/CRM) |
| 3 | Prueba de no-dependencia: un Sherpa Guide corre una sesión completa con el FOS | Evidencia de operación sin Victor | Anahí |
| 4 | Arrancar LoopXSA SherpaX (gravity tracking de prospectos B2O) | MacroLoopX vivo de FI-SHA | Jay |
| 5 | Cruzar G-IN→OP → crear XD-XX-FAC-SherpaX-Master-v01 | Maestro de factoría + estado Operando | Victor (ratifica) |

## CHANGELOG

| Versión | Fecha | Cambio |
|---------|-------|--------|
| v01 | 2026-06-13 | Creación. Factory Loop Contract de FI-SHA (10 elementos). Diagnóstico de la brecha crítica: FOS en Draft no operacionalizado + dependencia Hero-Operator. Plan de 5 pasos para cruzar G-IN→OP. Draft para ratificación |