--- asset_id: XP-EL-LoopX-DisenoYPiloto-v01 version: v01 status: Canonical · XPack · activación de Room para proyecto mayor owner: Victor Heredia sherpa: Jay fecha: 2026-05-25 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank / PB-LoopX tipo: XP — XPack · consolidación + activación de Room para proyecto mayor de EmpowerLabs room_destino: PB-LoopX (Room nuevo · activar con este XPack) proposito: > Activar el Room dedicado al diseño, construcción e implementación piloto del Sistema LoopX dentro de EmpowerLabs. LoopX es un proyecto mayor cuyo alcance excede cualquier conversación de cliente individual. Se diseña y se prueba in-house primero como primera instancia operativa. Eventualmente se replica externamente como producto. disparador: > Conversación 2026-05-25 entre Victor Heredia y Jay sobre arquitectura de gestión orbital de prospectos para FCB Newlink. Conclusión: la propuesta original (sistema tipo CRM con XDocs) tiene alcance estructural mayor al de Newlink y requiere su propio proyecto + Room dedicado. LoopX se construye dentro de EmpowerLabs; Newlink y otros clientes se atienden en Rooms separados que eventualmente reciben LoopX como producto. scope_explicito_fuera_de_loopx: - Conversación y propuesta comercial con FCB Newlink (vive en PB-NLK-Newlink) - Producción de briefs de pre-reunión para Mario (vive en TP-EL-NLK-RoomAnalisisProspectos-v01) - Configuración de rol de Mario en Newlink (vive en MarioVazquez-ConfiguracionRol-Newlink-v01) referencia_canonica: - MF-BMF-HybridDemand-v02 (MetaFactory base de generación de demanda) - DC-MPX-MPbooksInteligentes-Compilacion-v0.1 (MasterPlaybooks Inteligentes) - DC-MPX-FeatureMap-Recomendaciones-v01 (capacidades técnicas de la plataforma) - TP-EL-NLK-RoomAnalisisProspectos-v01 (Room hermano para Newlink · escalará a LoopX) - TP-EL-NLK-InfografiaLoopX-v01 (Transfer Prompt de la infografía visual del sistema) - DC-XX-WORX-HIOrgs-Sintesis-v02 (framework conceptual sobre el cual opera LoopX) tags: [xpack, loopx, proyecto-mayor, piloto-inhouse, empowerlabs, room-nuevo, sistema-orbital, multi-instancia] --- # XPack · LoopX ## Activación de Room para diseño + implementación piloto --- ## 0. Síntesis ejecutiva (60 seg) **LoopX es un proyecto mayor de EmpowerLabs**, no un sub-proyecto de Newlink. Es un sistema de gestión orbital de prospectos cuya arquitectura única se replica configurándose por unidad de negocio. Este XPack activa el Room dedicado al diseño, construcción e implementación piloto de LoopX dentro de EmpowerLabs como primera instancia operativa. EmpowerLabs es su propio primer cliente — el mismo principio operativo que ya valida la Factoría Editorial in-house. **El alcance del proyecto LoopX en esta primera fase es:** - Diseñar la arquitectura nuclear del sistema (genérica, replicable) - Construir el primer pilot operativo dentro de EmpowerLabs - Validar el sistema con prospectos propios antes de cualquier exposición externa - Documentar el caso de éxito interno como base para replicación **Lo que LoopX NO es en esta fase:** - No es producto público todavía - No es ofrecimiento a clientes - No es parte del scope de la conversación comercial con FCB Newlink Newlink eventualmente será cliente externo del producto LoopX una vez maduro. Esa conversación vive en otro Room (`PB-NLK-Newlink`). --- ## 1. Por qué LoopX requiere su propio proyecto y Room Tres razones estructurales: **Razón 1 · Alcance.** LoopX no es un sistema único centralizado — es una arquitectura que se replica en al menos cinco instancias dentro del propio EmpowerLabs (una por unidad de negocio). Esa escala estructural excede cualquier conversación de cliente individual. **Razón 2 · Propiedad intelectual.** LoopX es activo de EmpowerLabs. Su diseño, su metodología, su evolución son IP nuclear que se monetiza vía implementación, licenciamiento o uso interno. No puede vivir dentro de la conversación de un cliente porque ahí se diluye. **Razón 3 · Velocidad de iteración.** El diseño y prueba in-house requieren iteración rápida sin coordinación externa. Si LoopX vive dentro del Room de Newlink, cada decisión tiene que pasar por consideraciones de la alianza. Aislado, puede iterar al ritmo propio de EmpowerLabs. --- ## 2. Scope del proyecto LoopX ### 2.1 Lo que SÍ incluye este proyecto - Diseño de la arquitectura nuclear del sistema (replicable, multi-instancia) - Definición de la taxonomía canónica (LoopX como sistema · LoopDoc como artefacto unitario · Tablero LoopX · Sherpa LoopX) - Construcción técnica del primer pilot operativo dentro de EmpowerLabs - Integración con HighLevel CRM (capa de ejecución automática ya existente) - Integración con MasterPlaybooks Inteligentes (canal de entrada de demanda) - Desarrollo del Sherpa LoopX con calibración inicial - Definición empírica del gravity score (R&D operativo) - Documentación del caso de éxito interno - Especificación replicable para instancias adicionales (B2B, B2C, B2B2C) ### 2.2 Lo que NO incluye este proyecto en su fase actual - Implementación de LoopX en clientes externos (eso es siguiente fase, otro proyecto) - Conversación comercial con Newlink o cualquier otro cliente (esos viven en sus propios Rooms) - Productización del sistema para licenciamiento (eso es producto downstream) - Construcción de Dispatch mobile (puede ser fase posterior) - Integraciones técnicas con stacks de clientes específicos --- ## 3. Arquitectura conceptual ### 3.1 LoopX es una arquitectura, no una instancia LoopX se compone de cuatro capas que operan en conjunto: - **Canales de entrada al loop** — múltiples puntos por donde un prospecto orbita por primera vez - **Capa de criterio estratégico** — LoopDocs (artefactos por prospecto) + Tablero LoopX + Sherpa LoopX - **Capa de ejecución automática** — HighLevel CRM con email automation, social posting, calendarios, formularios - **Interfaz humana** — el operador comercial interactúa con su Sherpa para revisar estado, recibir alertas, tomar decisiones ### 3.2 LoopX se replica por unidad de negocio EmpowerLabs requiere al menos cinco instancias de LoopX, una por unidad de negocio: | Instancia | Unidad de negocio | Tipo | |---|---|---| | LoopX · B2B HiOrg Ecosystem | Prospectos del ecosistema HiOrg | B2B | | LoopX · B2C Monetiza tu Expertise | Prospectos individuales de monetización | B2C | | LoopX · RebelocityClub | Comunidad colaborativa | B2B2C | | LoopX · TribusRRHH | Comunidad colaborativa | B2B2C | | LoopX · MasterPlaybooks.com | Comunidad colaborativa | B2B2C | Cada instancia opera con la misma arquitectura nuclear pero se configura distinta en: tipo de ICP, MasterPlaybook generador de demanda, oferta del catálogo, calibración del Sherpa, gravity score específico, sponsor humano correspondiente. ### 3.3 Taxonomía canónica - **LoopX** — el sistema completo (arquitectura + metodología + integración) - **LoopDoc** — el artefacto canónico por prospecto (extensión del XDoc canónico) - **Tablero LoopX** — vista visual agregada de todos los LoopDocs de una instancia - **Sherpa LoopX** — el Sherpa IA configurado para operar el sistema en cada instancia - **Gravity Score** — métrica empírica de calificación de prospectos dentro del loop --- ## 4. Stack tecnológico identificado Componentes ya existentes que LoopX integra (no construye): - **HighLevel CRM** — ya operativo · capa de ejecución automática (email, social, calendarios, formularios, secuencias de nurture) - **MasterPlaybooks Inteligentes** — ya operativa · canal de entrada con calificación en vivo vía Sherpa contextual - **Vault EmpowerLabs (IntelliBanks + BMF)** — ya operativo · capa de criterio y memoria persistente - **Brain Codes canonizados** — disponibles · alimentan perfiles de decision makers - **Sherpa IA infraestructura** — ya operativa · base sobre la cual se construye Sherpa LoopX Componentes nuevos a desarrollar: - **Plantilla canónica LoopDoc** — formato Markdown + frontmatter BMF - **Tablero LoopX visual** — vista agregada (HTML/SVG o framework similar) - **Puente de sincronización HighLevel ↔ Vault** — bidireccional, ambas direcciones - **Sherpa LoopX calibrado** — configuración específica del Sherpa para operar el loop - **Mecanismo empírico de gravity score** — protocolo de calibración progresiva --- ## 5. Agenda del Room · fase de diseño antes de cualquier construcción El Room opera en dos fases claramente separadas. La fase de construcción NO arranca hasta que la fase de diseño esté completa y validada. No correr antes de caminar. ### 5.1 Fase de diseño · arquitectura y modelo operativo Estas son las preguntas que el Room debe responder en orden, antes de cualquier decisión de instancia o implementación: 1. **Naturaleza del sistema LoopX.** Qué es exactamente, qué resuelve, qué no resuelve. Definición precisa antes de cualquier diseño técnico. 2. **Modelo operativo con el Sherpa como interfase.** Cómo opera el operador humano (Victor / Anahí / eventual sponsor comercial) con el Sherpa como interfase principal. Qué hace el humano, qué hace el Sherpa, dónde está la frontera. 3. **Infraestructura técnica.** Qué stack soporta el sistema. Componentes ya existentes vs componentes a desarrollar. Decisión de arquitectura técnica. 4. **Modelo operativo dentro del BigMetaFactory.** Cómo se inserta LoopX en el marco BMF existente. Qué pipelines del BMF lo alimentan. Qué nuevos pipelines requiere. 5. **Conexión con CRM convencional para automatizaciones.** Específicamente cómo se conecta con HighLevel (u otro CRM convencional) para mantener las automatizaciones de email, secuencias, redes sociales, calendarios. Diseño del puente de sincronización. ### 5.2 Fase de implementación · solo después de fase 1 validada Una vez que la fase de diseño produce arquitectura validada, las decisiones de implementación entran al Room: - Cuál de las 5 instancias se construye primero como pilot - Equipo operativo dedicado durante la construcción - Cronograma específico con hitos y métricas - Protocolo de R&D del Sherpa LoopX (cómo se entrena empíricamente) - Criterios de gradación pilot → replicación a instancias adicionales --- ## 6. Stakeholders y roles - **Owner ejecutivo del proyecto** · Victor Heredia - **Operador del Room** · Anahí (con asistencia de Jay) - **Sherpa de acompañamiento** · Jay - **Stakeholders informados** (no operativos) · equipo EmpowerLabs general --- ## 7. Conexiones con otros proyectos del vault - **PB-NLK-Newlink** — Room hermano de FCB Newlink. Eventualmente recibe LoopX como producto cuando esté maduro. Hoy opera con `TP-EL-NLK-RoomAnalisisProspectos-v01` como solución pre-LoopX. - **PB-MPX-MasterPlaybooks** — proyecto de la plataforma MasterPlaybooks. LoopX consume su capacidad de calificación vía MasterPlaybooks Inteligentes. - **PB-WORX-Worx** — proyecto WORX. LoopX hereda la taxonomía XDoc de WORX y la extiende con LoopDoc. - **PB-BMF-BigMetaFactory** — proyecto BMF. LoopX se construye sobre infraestructura BMF. --- ## 8. Asset register inicial del proyecto Activos canonizados o referenciados que pertenecen al proyecto LoopX: | Asset ID | Tipo | Estado | |---|---|---| | XP-EL-LoopX-DisenoYPiloto-v01 | XPack · este documento | Canonical | | TP-EL-NLK-InfografiaLoopX-v01 | Transfer Prompt · infografía del sistema | Canonical (vive en PB-NLK por origen, referenciado aquí) | Activos por construir dentro del Room una vez activado: - Plantilla canónica `LoopDoc-[Instancia]-[Empresa]-v01.md` - Especificación técnica del puente HighLevel ↔ Vault - Configuración inicial del Sherpa LoopX - Documento de diseño de la primera instancia pilot (la elección de qué instancia se toma en el Room) - Cronograma del pilot - Documento de gravity score (versión inicial empírica) --- ## 9. Starter Prompt para activar el Room Cuando se inicia la primera sesión operativa del Room LoopX, se carga el siguiente Starter Prompt: ``` Estás operando el Room "LoopX · Diseño + Piloto" dentro de EmpowerLabs. Misión del Room en su fase actual: diseñar la arquitectura nuclear y el modelo operativo del sistema LoopX. La construcción NO arranca hasta que la arquitectura esté validada. LoopX es un proyecto mayor de EmpowerLabs. NO es sub-proyecto de ninguna conversación con cliente externo. Es activo de EmpowerLabs que eventualmente se replicará a clientes como producto maduro. Las cinco instancias futuras que LoopX deberá soportar (informativo, no decisión inmediata): 1. LoopX · B2B HiOrg Ecosystem 2. LoopX · B2C Monetiza tu Expertise 3. LoopX · RebelocityClub (comunidad colaborativa) 4. LoopX · TribusRRHH (comunidad colaborativa) 5. LoopX · MasterPlaybooks.com (comunidad colaborativa) Cuál instancia se construye primero es decisión POSTERIOR a la fase de diseño. No se anticipa. AGENDA DE LA FASE DE DISEÑO (en este orden, sin saltarse pasos): 1. Definir la naturaleza del sistema LoopX. Qué es, qué resuelve, qué no resuelve. Definición precisa antes de cualquier diseño. 2. Definir el modelo operativo con el Sherpa como interfase principal. Cómo opera el humano con el Sherpa. Qué hace el humano, qué hace el Sherpa, dónde está la frontera entre ambos. 3. Definir la infraestructura técnica. Qué stack soporta el sistema. Componentes existentes que se integran (HighLevel CRM, MasterPlaybooks, Vault, Brain Codes) vs componentes nuevos a desarrollar. 4. Definir el modelo operativo dentro del BigMetaFactory. Cómo se inserta LoopX en el marco BMF existente. Qué pipelines del BMF lo alimentan. Qué nuevos pipelines requiere. 5. Definir la conexión con CRM convencional (HighLevel) para mantener automatizaciones de email, secuencias, redes sociales, calendarios. Diseño del puente de sincronización bidireccional. SOLO DESPUÉS de validar estos cinco puntos de arquitectura entra al Room la fase de implementación (decisión de instancia pilot, cronograma, equipo dedicado, R&D del Sherpa, criterios de gradación). Activos referencia que se consultan continuamente: - MF-BMF-HybridDemand-v02 (MetaFactory base de generación de demanda) - DC-MPX-MPbooksInteligentes-Compilacion-v0.1 (MasterPlaybooks Inteligentes) - DC-MPX-FeatureMap-Recomendaciones-v01 (capacidades técnicas plataforma) - TP-EL-NLK-InfografiaLoopX-v01 (Transfer Prompt infografía visual) - Documentación canónica del BigMetaFactory en IB-XX-Maestro/MF-XX-MetaFactorias Reglas operativas no negociables: - NO mezclar este proyecto con conversaciones de cliente externo. - NO construir nada hasta que la fase de diseño esté completa y validada. - NO saltarse pasos de la agenda de diseño. Cada paso se cierra antes del siguiente. - NO pre-decidir cuál instancia se pilota primero. Esa decisión llega después de la fase de diseño. - SÍ documentar cada decisión arquitectónica como artefacto canónico del Room. - SÍ avanzar paso a paso, sin acelerar más allá del criterio. - SÍ todo el diseño se inserta dentro del marco BigMetaFactory existente. Pregunta de apertura del Room: "¿Cuál es la naturaleza precisa del sistema LoopX? Qué resuelve, qué no resuelve, y cómo se distingue conceptualmente de un CRM convencional o de un funnel comercial tradicional." ``` --- ## 10. Próximos pasos para activar el Room - Ratificación de este XPack por Victor (señal de luz verde para activar el Room) - Asignación formal de operador del Room (Anahí confirmada · pendiente confirmación de disponibilidad) - Primera sesión del Room: arrancar agenda de diseño por la pregunta 1 (naturaleza del sistema LoopX) - Producción progresiva de los artefactos de diseño (uno por cada pregunta de la agenda, en orden) - Validación de la arquitectura completa antes de cualquier decisión de construcción o pilot La fase de diseño se considera completa cuando los cinco puntos de la agenda producen artefactos canónicos validados. Solo entonces se abre la fase de implementación. --- ## 11. Notas de gobernanza ### 11.1 Frontera con el Room de Newlink LoopX vive aislado del Room de FCB Newlink. La conversación con Mario y Eric NO se traslada a este Room. Las decisiones de LoopX NO requieren input de stakeholders externos. Cuando LoopX esté maduro, se ofrecerá a Newlink como producto vía conversación que vive en su propio Room. ### 11.2 Propiedad intelectual LoopX es IP exclusiva de EmpowerLabs. Cualquier replicación externa (a Newlink, a clientes finales) opera bajo modelo de licenciamiento o implementación pagada, no como transferencia de IP. ### 11.3 Confidencialidad Los artefactos producidos dentro de este Room son confidenciales internos de EmpowerLabs hasta que se decida explícitamente publicarlos o compartirlos externamente. ### 11.4 Revisión periódica del XPack Este XPack se revisa cada 60 días o cada vez que haya un giro estructural en el proyecto. Versiones siguientes (v02, v03) consolidan el aprendizaje del Room. --- **Status final del XPack:** Canonical · pendiente ratificación Victor para activación del Room. **Owner:** Victor Heredia **Próximo paso del owner:** ratificar este XPack y activar el Room con su primera sesión de decisión sobre cuál instancia se pilota primero.