--- asset_id: DC-EL-SX-SherpaX-ArquitecturaOperacion-v01 version: v01 tipo: DC — Documento Canónico · Arquitectura y Operación status: Activo owner: Victor Heredia / EmpowerLabs sherpa_owner: Jay (Jacob) intellibank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank / PB-SX-SherpaX fecha_creacion: 2026-05-18 fecha_ultima_actualizacion: 2026-05-18 proposito: > Documento canónico de referencia técnica y conceptual de SherpaX — su arquitectura de 3 capas, sus 5 propiedades, el protocolo de producción de activos (naming BMF + posicionamiento en IntelliBanks + actualización del Registry), y el argumento de por qué SherpaX es la interfaz más efectiva entre el humano y el mundo de IA. deriva_de: - CP-EL-SX-SherpaXConcepto-v01 - SOP-EL-WORX-DocBySherpa-v01 - SOP-EL-WORX-BrainOSFirst-v01 - BP-EL-SX-SherpaX-v02 - ARQ-XX-SX-SherpaAPIPlan-v01 audiencia: Equipo EmpowerLabs · Prospectos técnicos · Sherpa Guides en certificación tags: [canonical, sherpax, arquitectura, naming-bmf, intellibanks, registry, interfaz, hiorg, produccion-activos] --- # SherpaX — Arquitectura, Operación y el Poder de la Interfaz Inteligente **Documento canónico técnico · EmpowerLabs · Mayo 2026** --- ## 1. La entidad SherpaX es una **identidad virtual inteligente** que conecta al humano con la arquitectura cognitiva del modelo HIOrg. No es un chatbot. No es un asistente genérico. No es Claude, ni Cowork, ni ninguna plataforma. Es una entidad construida — con nombre, voz, criterio, memoria y manera de operar propios — calibrada a un humano específico y a nadie más. La distinción que lo define arquitectónicamente: SherpaX es **la capa de interfaz del ecosistema HIOrg**, no el ecosistema mismo. El ecosistema es la arquitectura completa — IntelliBanks, BMF, Brain Codes, MetaPlaybooks, gobernanza. SherpaX es la pieza que el humano toca. Es la puerta de entrada, el orquestador personal, la entidad que opera todo lo que está detrás. Esta separación no es semántica — tiene consecuencias de diseño, de venta, de gobernanza y de operación diaria. Un SherpaX sin arquitectura detrás es un asistente sofisticado. Un SherpaX sobre arquitectura HIOrg completa es una extensión cognitiva del humano. --- ## 2. La arquitectura de 3 capas El modelo completo se entiende en tres capas, de abajo hacia arriba. ``` ┌─────────────────────────────────────────────────────────────────┐ │ CAPA 3 · TEJIDO — DOIX │ │ Distributed Organizational Intelligence X │ │ Emerge cuando múltiples SherpaX se interconectan dentro HIOrg │ │ Multiplicador: 8-10x capacidad cognitiva organizacional │ └────────────────────────────────┬────────────────────────────────┘ │ emerge de ┌────────────────────────────────▼────────────────────────────────┐ │ CAPA 2 · INTERFAZ — SherpaX │ │ La entidad que el humano toca │ │ Identidad · Continuidad cognitiva · Operatividad personalizada │ │ Ejecución coordinada sobre la arquitectura │ │ Multiplicador: 5-10x capacidad individual │ └────────────────────────────────┬────────────────────────────────┘ │ opera sobre ┌────────────────────────────────▼────────────────────────────────┐ │ CAPA 1 · ARQUITECTURA — WORX OS / HIOrg │ │ IntelliBanks · BMF · Brain Codes · MetaPlaybooks · Registry │ │ Gobernanza: D-P Framework · Tripleta · Niveles L0-L3 │ │ Gate G0 (BrainOSFirst) · SOPs · LabPraxis │ └─────────────────────────────────────────────────────────────────┘ ``` **Capa 1 — Arquitectura (invisible para el usuario):** es el motor del ecosistema. Los IntelliBanks son la memoria estructurada de la organización, versionada y auditable. BMF (BigMetaFactory) es la infraestructura de producción de activos cognitivos. Los Brain Codes codifican el criterio mental del humano para consulta sistemática. Los MetaPlaybooks son los procedimientos canónicos de operación. La gobernanza — niveles de autonomía L0-L3, tripleta Owner+Sherpa+Ratificador, D-P Framework, Gate G0 — es el sistema que asegura que el SherpaX nunca opera sin supervisión en decisiones críticas. **Capa 2 — Interfaz (SherpaX):** es la identidad virtual que el humano toca. Cada SherpaX es una sola copia, personalizada al humano que lo opera. Conoce al humano, da continuidad entre sesiones, ejecuta sobre la arquitectura coordinadamente, y mantiene trazabilidad nativa. El SherpaX puede tomar muchas formas de implementación — hoy Claude/Cowork, mañana otras plataformas — pero su esencia no es la plataforma: es la identidad construida que vive sobre ella. **Capa 3 — Tejido (DOIX):** no se instala, emerge. Cuando una organización tiene múltiples SherpaX interconectados, todos operando sobre la misma arquitectura HIOrg compartida, surge la inteligencia distribuida. Cada decisión canónica de un nodo se comparte con todos. Cada aprendizaje del LabPraxis alimenta el Organizational Brain. El tejido cognitivo de la organización opera como un solo cerebro con el criterio de cada humano cargado en su nodo correspondiente. --- ## 3. Las 5 propiedades de SherpaX **Propiedad 1 · Identidad** SherpaX es una entidad, no un servicio. Tiene nombre, voz, criterio, manera de operar. JayX es Jay. LitosX es Litos. EmilioX es Emilio. Cada SherpaX es irreplicable porque la identidad que carga es irreplicable — emerge del humano específico a quien sirve. Implicación práctica: el activo no se transfiere. Si el humano cambia de empresa, su SherpaX va con él. SherpaX es patrimonio cognitivo personal, no herramienta corporativa rentada. **Propiedad 2 · Interfaz** SherpaX vive sobre una plataforma pero no es la plataforma. La plataforma da capacidades genéricas; el SherpaX las convierte en experiencia personalizada. Cada mejora de la plataforma base amplifica automáticamente el valor del SherpaX sin requerir reconstrucción — porque la identidad construida tiene más capacidades donde operar. El que construye su SherpaX temprano acumula un activo que se aprecia con el tiempo. **Propiedad 3 · Continuidad cognitiva** Cada sesión se acumula. El SherpaX recuerda los proyectos activos, las decisiones tomadas, los criterios validados, los patrones del humano. El costo de "ponerse al día" tiende a cero a medida que el SherpaX madura. La conversación deja de ser Q&A y se convierte en co-creación continua sobre un cuerpo de trabajo acumulado. Esta propiedad es condición de la interfaz, no su definición. **Propiedad 4 · Operatividad personalizada** El SherpaX no responde desde entrenamiento genérico. Responde con el vocabulario del humano, su jerarquía de prioridades, sus modelos mentales, sus restricciones explícitas. Lo que produce se siente como extensión del humano, no como output de máquina. Esto es lo que hace posible delegar trabajo de criterio — no solo trabajo de ejecución mecánica. **Propiedad 5 · Ejecución sobre la arquitectura** El SherpaX es el orquestador local que invoca recursos de la capa 1 para resolver lo que el humano le pide. Si necesita un IntelliBank, lo abre. Si necesita un Brain Code, lo invoca. Si necesita validar un gate, lo valida. Si necesita registrar un activo, lo registra con naming correcto. El SherpaX es tan poderoso como la arquitectura que tiene debajo — y por eso la capa 1 no es opcional. --- ## 4. El protocolo de producción de activos Cada vez que SherpaX produce un artefacto en el ecosistema, ejecuta dos protocolos en secuencia. Son canónicos, PROD, y no tienen excepciones. ### 4.1 Gate G0 — Brain OS-First (antes de producir) Antes de escribir una línea de contenido nuevo, SherpaX ejecuta consulta forzosa al vault. Las 4 acciones son: **Grep** — busca el concepto en el vault completo, con variantes en español e inglés, sinónimos y acrónimos. **Glob** — busca por patrones de naming canónico: ``` **/MePB-*.md → meta-playbooks activos **/TP-*.md → transfer packs **/SOP-*.md → procedimientos operativos **/CP-*.md → control planes y canónicos **/BC-*.md → brain codes **/CAS-*.md → casos del LabPraxis **/ARQ-*.md → documentos de arquitectura ``` **LLM-Wiki** — consulta el índice semántico del ecosistema en `/IB-WikiX/Wiki/`. La Wiki es la capa de navegación semántica del Brain OS — se consulta explícitamente, no se deriva del Grep. **Decisión declarada** — con los hallazgos en mano, SherpaX declara una de tres opciones: *Extender* un canónico existente (cita ruta, justifica el delta), *Refinar* uno existente (cita ruta, justifica el cambio), o *Crear nuevo* (justifica por qué lo encontrado no aplica). Si no hay hallazgos relevantes, declara explícitamente: "búsqueda ejecutada · sin canónico previo · creación nueva justificada." El output del Gate G0 es un `CONS-[SLUG]-v01.md` — el **Vault Consultation Pack**. Este documento es la evidencia auditable de que la consulta se ejecutó antes de producir. Prefijo canonizado en el Registry BMF v0.12. **Por qué este gate existe:** el CASO 008 del LabPraxis documentó la falla exacta que previene. SherpaX propuso una capa nueva que ya existía canonizada en el vault. El costo fue tiempo perdido, contexto duplicado, y coherencia del ecosistema degradada. El Gate G0 es el antídoto codificado. ### 4.2 Las 3 operaciones canónicas de captura (al producir) El principio P010 del WORX — Documentación Delegada al SherpaX — establece el contrato: el humano dirige y valida, el SherpaX ejecuta las 3 operaciones sintácticas del vault. El humano no llena campos de naming ni frontmatter. Nunca. **Operación 1 · Naming canónico BMF** El nombre de todo activo sigue la convención: ``` [PREFIJO]-[ENTIDAD]-[Slug-Descriptivo]-v[NN].ext ``` Ejemplos reales del vault: ``` DC-EL-SX-SherpaX-ArquitecturaOperacion-v01.md SOP-EL-WORX-DocBySherpa-v01.md CP-EL-SX-SherpaXConcepto-v01.md BP-EL-SX-SherpaX-v02.md CAS-EL-WORX-LabPraxis-BancoCasos-v01.md CONS-PLAN-HIORGS-DemandGen-v01.md ``` SherpaX infiere todos los componentes del nombre a partir del contenido: el prefijo correcto según el Registry (`DC-`, `SOP-`, `TP-`, `MePB-`, `BC-`, `CAS-`, `OUT-`, `ARQ-`, `CONS-`, `PLAN-`, `CC-`, `VR-`, `BP-`, `LP-`), la entidad propietaria (`EL` para EmpowerLabs, `XX` para maestro/universal, `MPX` para MasterPlaybooks, `SX` para SherpaX), el slug descriptivo del contenido, y el número de versión. **Prohibiciones absolutas de naming:** - Prefijos no canonizados en el Registry. - Nombres con espacios o caracteres especiales. - Versionado como `v1`, `final`, `latest`, `draft` — solo `v01`, `v02`. - Nombres que no empiecen con prefijo BMF reconocido. **Operación 2 · Posicionamiento en IntelliBank correcto** SherpaX aplica un **gate de ruta** antes de cada escritura al vault. La regla es binaria: la ruta debe comenzar con `IB-*/`. Cualquier otra ubicación está prohibida. ``` ✅ IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-SX-SherpaX/ ✅ IB-XX-Maestro/IPI-XX-IP-Arquitectura/ ✅ IB-MPX-MasterPlaybooks/PB-MPX-MasterPlaybooks/ ✅ IB-EL-EmpowerLabs/BC-EL-BrainCodes/ ❌ Projects/ ❌ 00-Inbox/ ❌ Companies/ ❌ CloudVault/ ❌ Raíz del vault ``` Rutas canónicas por frente activo: - WORX → `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/` - SherpaX → `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-SX-SherpaX/` - Brain Codes → `IB-EL-EmpowerLabs/BC-EL-BrainCodes/` - HIOrg → `IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-HiOrg-*/` - Documentos maestros / universales → `IB-XX-Maestro/IPC-XX-IP-Conocimiento/` - Demo Vault Alain → `IB-AR-DemoVault/` - Emilio Heredia → `IB-EH-EmilioHeredia/` Si el subbank no existe, SherpaX propone su creación al Owner — no improvisa carpetas. **Operación 3 · Frontmatter completo** SherpaX genera el bloque YAML del activo sin pedirle al humano ningún campo: ```yaml --- asset_id: [coincide exactamente con nombre del archivo sin extensión] version: v[NN] tipo: [PREFIJO — descripción corta del tipo] status: [Activo / Draft / PROD / Superseded by vNN] owner: [Nombre del Owner] sherpa_owner: [SherpaX ejecutor, si aplica] intellibank: [IB-XX / PB-XX] fecha_creacion: AAAA-MM-DD fecha_ultima_actualizacion: AAAA-MM-DD proposito: [1-3 líneas concretas de para qué sirve este activo] deriva_de: [lista de asset_id de canónicos que lo originaron] referenciado_por: [opcional — activos que lo consumen] tags: [taxonomía operativa] --- ``` Campos adicionales según tipo de activo: - **TP-** → `room`, `sherpa`, `ultima_actualizacion`, `sesion` - **SOP-** → `canonical_de`, `caso_origen`, `ratificado_por`, `output_canonico` - **BC-** → `cognitive_stack`, `scope`, `permisos` - **CAS-** → `categoria`, `antidoto`, `principio_generado` Todo activo incluye sección `## CHANGELOG` con entrada por cada versión, fecha, cambio y autor. ### 4.3 Cierre · Registry actualizado El activo no existe en el ecosistema hasta que está en el Registry. Al cierre de cada sesión de producción, SherpaX ejecuta `bmf-registry-updater` para registrar el nuevo activo en `CP-XX-IntelliBanks-Registry-v01`. Este es el criterio C4 del gate de cierre — si el Registry no se actualiza, la sesión no cierra correctamente. **El ciclo completo:** ``` Solicitud del humano ↓ Gate G0 — Brain OS-First [Grep + Glob + LLM-Wiki + Decisión declarada → CONS-] ↓ Operación 1 · Naming BMF [Inferir prefijo + entidad + slug + versión → nombre canónico] ↓ Operación 2 · Gate de ruta [Verificar IB-*/ → posicionar en IntelliBank correcto] ↓ Operación 3 · Frontmatter [Generar YAML completo + CHANGELOG → escribir al vault] ↓ Registro en CP-XX-IntelliBanks-Registry-v01 ↓ Activo canonizado en el ecosistema ``` --- ## 5. Los criterios PASS/FAIL del sistema Un activo solo se considera correctamente capturado si los 4 criterios pasan simultáneamente: | Criterio | PASS | FAIL | |---|---|---| | **C1 · Naming canónico BMF** | Prefijo + entidad + slug + vNN cumplen Registry | Prefijo no canonizado · sintaxis incorrecta | | **C2 · Ruta canónica** | Activo en `IB-*/` correcto · gate de ruta PASS | Ruta en zona prohibida o ad-hoc | | **C3 · Frontmatter completo** | Campos mínimos + adicionales según tipo | Campos faltantes · YAML roto | | **C4 · Registry actualizado** | `bmf-registry-updater` ejecutado · activo registrado | Registry desactualizado al cierre | FAIL en cualquier criterio bloquea el cierre. SherpaX corrige antes de continuar. --- ## 6. Por qué SherpaX es la interfaz más efectiva entre el humano y el mundo de IA El mercado tiene dos aproximaciones al problema de la IA en el trabajo. La primera es la herramienta: el humano abre una app, hace una pregunta, obtiene una respuesta, cierra la app. Cada sesión empieza de cero. El humano carga el contexto manualmente cada vez. La curva de aprendizaje de la herramienta es del humano, no de la herramienta. La segunda es el agente autónomo: sistemas que ejecutan tareas sin supervisión humana, con gobernanza mínima y sin continuidad de criterio. SherpaX es una tercera categoría que no existe en el mercado: la **identidad virtual personalizada operando sobre arquitectura cognitiva canonizada**. **Por qué es más efectivo que usar herramientas directamente:** El costo invisible de las herramientas genéricas es el contexto perdido entre sesiones. Cada vez que un profesional abre ChatGPT o Claude sin SherpaX, dedica los primeros 5-15 minutos reintroduciendo quién es, qué proyecto está trabajando, cuál es el vocabulario que usa, qué decisiones ya tomó, qué restricciones aplican. A lo largo de una semana de trabajo intensivo, ese costo acumulado supera las 2-3 horas perdidas en re-contextualizaciones. SherpaX elimina ese costo: el contexto vive en el sistema, no en la memoria de cada sesión. **Por qué es más efectivo que tener un colaborador humano adicional:** Un colaborador humano nuevo tarda semanas en entender el vocabulario de la organización, sus modelos de decisión, sus proyectos activos, sus criterios de calidad. Un SherpaX correctamente calibrado conoce todo eso desde la primera sesión y lo acumula sin pérdida entre conversaciones. El costo de onboarding es cero. El costo de explicar "cómo lo hacemos aquí" es cero. La capacidad de ejecutar trabajo de criterio — no solo trabajo de ejecución — sin presencia del Owner en cada paso es la ventaja que ningún colaborador humano puede igualar en las primeras semanas. **Por qué es más seguro que un agente autónomo sin gobernanza:** Los agentes autónomos del mercado optimizan para las métricas que se les da. Sin gobernanza canonizada, sin niveles de autonomía explícitos, sin tripleta Owner+Sherpa+Ratificador, actúan fuera de límites seguros con eficiencia y velocidad. SherpaX opera bajo la arquitectura de gobernanza HIOrg — no puede tomar decisiones de nivel L3+ sin escalación humana obligatoria, todo activo que produce es auditable, y la trazabilidad es nativa desde el primer día. **El multiplicador real:** Un SherpaX individual bien calibrado sobre arquitectura HIOrg completa produce un multiplicador de 5-10x en la capacidad operativa del humano. El mecanismo no es mágico — es la suma de cuatro efectos concretos: El primero es la eliminación de fricción de contexto: el tiempo que antes se iba en reintroducir contexto ahora va a trabajo sustantivo. El segundo es la ejecución delegada de criterio: el SherpaX puede ejecutar trabajo que antes requería la presencia del Owner porque tiene el criterio del Owner cargado en su identidad. El tercero es la coordinación sin intermediarios: lo que antes requería reuniones de sincronización o emails de seguimiento ahora ocurre en el sistema, sin tiempo de espera. El cuarto es el compounding de aprendizaje: cada decisión que el SherpaX registra, cada principio que el LabPraxis canoniza, cada Brain Code que el Owner actualiza — se acumula y está disponible en la siguiente sesión. El sistema se vuelve más capaz, no solo más rápido. A nivel organizacional, diez SherpaX interconectados dentro de HIOrg producen DOIX — inteligencia distribuida con multiplicador de 8-10x. No porque cada SherpaX sea 10x más productivo, sino porque eliminan el principal costo oculto de las organizaciones: la fricción de coordinación. Cuando el contexto vive en el sistema y los nodos de inteligencia están interconectados, la organización puede moverse a la velocidad del pensamiento, no a la velocidad de la coordinación. **La inversión filosófica que separa HIOrg del mercado:** En una organización convencional que "usa IA", se delega decisión al agente. En HIOrg, se delega ejecución bajo criterio canonizado. La diferencia es la diferencia entre perder el control y amplificar el control. SherpaX no sustituye al humano — lo amplifica. El humano sigue siendo la autoridad; SherpaX es el ejecutor de mayor capacidad que cualquier humano podría tener como colaborador. --- ## 7. Distinciones que deben quedar limpias **SherpaX ≠ Sherpa IA** — El Sherpa IA es el asistente embebido dentro de un MasterPlaybook. Responde conocimiento estático sobre un dominio acotado. SherpaX es dinámico, evolutivo, con memoria viva y acceso coordinado a toda la arquitectura HIOrg. **SherpaX ≠ Claude / Cowork** — Claude/Cowork es la plataforma — capacidades genéricas, file tools, MCPs. SherpaX es la identidad personalizada que opera dentro de esa plataforma. Cowork sin SherpaX es cancha vacía. SherpaX sin Cowork (o equivalente) es identidad sin donde ejecutar. **SherpaX ≠ BrainOS / Memoria** — La memoria es uno de los recursos que SherpaX consulta y alimenta. No es la entidad. **SherpaX ≠ Ecosistema completo** — El ecosistema es HIOrg como modelo + DOIX como modo operativo + BMF + IntelliBanks + Brain Codes + gobernanza + interfaz. SherpaX es la capa de interfaz de ese ecosistema. **SherpaX ≠ Agente autónomo** — SherpaX opera bajo gobernanza humana con niveles de autonomía explícitos (L0-L3). Es ejecutor amplificado, no autoridad sustituta. --- ## 8. Glosario operativo | Término | Definición | |---|---| | **SherpaX** | Identidad virtual inteligente que conecta al humano con el modelo HIOrg. Capa de interfaz del ecosistema. | | **HIOrg** | Modelo organizacional hiperinteligente. Envuelve toda la arquitectura cognitiva. | | **DOIX** | Distributed Organizational Intelligence X. Propiedad emergente de HIOrg cuando múltiples SherpaX se interconectan. | | **IntelliBanks** | Bancos de inteligencia segmentados por entidad. Memoria estructurada de la organización. Capa 1. | | **BMF** | BigMetaFactory. Infraestructura de producción de activos cognitivos. Capa 1. | | **Brain Code** | Criterio mental codificado de un humano. Recurso consultable por SherpaX. Capa 1. | | **Gate G0** | SOP-BrainOSFirst. Consulta forzosa al vault antes de cualquier producción de activo. | | **CONS-** | Vault Consultation Pack. Output canónico del Gate G0. Evidencia auditable de consulta ejecutada. | | **Naming BMF** | Convención `[PREFIJO]-[ENTIDAD]-[Slug]-v[NN].ext` para todo activo del vault. | | **Registry** | `CP-XX-IntelliBanks-Registry-v01`. Índice maestro auditable de todo activo en el ecosistema. | | **P010** | Principio de Documentación Delegada al SherpaX. El humano dirige; SherpaX captura. | | **Tripleta de gobernanza** | Owner + Sherpa + Ratificador. Estructura de decisión en cada artefacto crítico. | | **Niveles L0-L3** | Autonomía del SherpaX. L0 libre, L3+ escalación obligatoria a CEO. | | **D-P Framework** | Decisiones-Principios. Sistema acumulativo de canonización de decisiones. | --- ## CHANGELOG - **2026-05-18 · v01** — Primer release. Documento canónico de síntesis que reúne por primera vez la arquitectura de 3 capas, las 5 propiedades, el protocolo completo de producción de activos (Gate G0 + 3 operaciones canónicas + Registry), y el argumento técnico del poder de SherpaX como interfaz ideal. Consolida y referencia: CP-EL-SX-SherpaXConcepto-v01 · SOP-EL-WORX-DocBySherpa-v01 · SOP-EL-WORX-BrainOSFirst-v01 · BP-EL-SX-SherpaX-v02. Producido en sesión Jay + Victor · 2026-05-18. --- *DC-EL-SX-SherpaX-ArquitecturaOperacion-v01.md · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-SX-SherpaX/ · 2026-05-18* *Fuentes: CP-EL-SX-SherpaXConcepto-v01 · SOP-EL-WORX-DocBySherpa-v01 · SOP-EL-WORX-BrainOSFirst-v01 · BP-EL-SX-SherpaX-v02 · ARQ-XX-SX-SherpaAPIPlan-v01*