--- asset_id: MPB-EL-WORX-ModeloOperativo-v01 version: v0.6 tipo: MPB — MasterPlaybook (universal) room: WORX — Modelo Operativo owner: Victor Heredia / EmpowerLabs fecha_creacion: 2026-04-18 fecha_ultima_actualizacion: 2026-04-25 estado: En construcción incremental — v0.6 cierra Parte 1 (§§0-3) con voz descentrada del autor + integración del SO-HiORG (3 pilares), 5 capas del Reto y movimientos Nate/Karpathy pendientes del Anexo A. Quedan §§10-11 + Cierre para v0.7. continúa_desde: TP-EL-WORX-MPBModeloOperativo-v01 absorbe: PLB-EL-WORX-MarcoConceptual-v01 (selectivo), SOP-EL-WORX-ManualOperativo-v01 (descartado, reasignable), PAP-HIORGS-GranReto-v01 (5 capas como esqueleto diagnóstico §2.2), XP-EL-HIORGS-Portfolio-v01 (3 pilares SO-HiORG + D-013 + anti-pause) nota_rebrand: 2026-04-18 — La metodología fue renombrada de WERK a WORX y el átomo de "doc estructurado" a "XDoc" en la misma sesión de cierre de v0.1. --- # MasterPlaybook WORX — Modelo Operativo ## Manual universal de arquitectura para la Organización Hiperinteligente --- > MPB universal. Describe cómo se implementa WORX en cualquier organización que lo adopte. > Cada organización deriva luego su MetaPlaybook (MePB) como adaptación a su ADN específico. > El orden es: MPB primero (universal); MePB después (organizacional). --- ## TABLA DE CONTENIDO **PARTE 1 — FUNDAMENTOS** *(por qué y qué)* - Sección 0 — El Gran Reto del Trabajo Moderno ✅ *v0.6* - Sección 1 — Manifiesto de Reinvención ✅ *v0.6* - Sección 2 — Posición en el Ecosistema ✅ *v0.6* - Sección 3 — Arquitectura del Modelo ✅ *v0.6* **PARTE 2 — EL MODELO OPERATIVO** *(cómo)* - Sección 4 — Nivel 1: El XDoc ✅ *v0.1* - Sección 5 — Nivel 2: El Ritmo de Uso ✅ *v0.1* - Sección 6 — Arquitectura Cognitiva ✅ *v0.1* - Sección 7 — Los 5 Contratos ✅ *v0.1* - Sección 8 — Capacidades Personales del Trabajador WORX (Capa Ortogonal) ✅ *v0.2* **PARTE 3 — PLATAFORMA Y ADOPCIÓN** *(hacia dónde)* - Sección 9 — Nivel 3: La Plataforma Emergente ✅ *v0.5* - Sección 10 — Guía de Implementación - Sección 11 — Métricas y Salud del Sistema - Cierre — Manifiesto de Trabajo para la Era de la IA **ANEXOS** - Anexo A — Insumos Externos Evaluados ✅ *v0.5* --- ## RUTA DE VERSIONADO | Versión | Alcance | Estado | |---------|---------|--------| | v0.1 | Parte 2 — Secciones 4, 5, 6 y 7 cerradas (XDoc + Ritmo + Cognitiva + Contratos) | ✅ | | v0.2 | Parte 2 completa — Sección 8 cerrada (Capacidades Personales / Capa Ortogonal) | ✅ | | v0.5 | Parte 3 — Sección 9 cerrada (Plataforma Emergente) + Anexo A creado (Insumos Nate Jones) | ✅ | | v0.3 | Parte 1 cerrada (Secciones 0, 1, 2, 3) — alcance reservado, ejecutado dentro de v0.6 | ✅ | | **v0.6** | Parte 1 cerrada con voz descentrada del autor + integración SO-HiORG (3 pilares) + 5 capas del Reto + callout XDoc/Karpathy en §4.1 + movimientos Nate v0.3 absorbidos | 🟢 actual | | v0.7 | Parte 3 — Secciones 10, 11, Cierre | ⬜ | | v1.0 | Revisión integral de voz y coherencia cross-parte | ⬜ | --- ## NOTA SOBRE NAMING El ecosistema WORX tiene naming DNA con factor X: - **WORX** — la metodología operativa (*Work · Orchestrated · Reinvention · X-factor*). Renombrada desde WERK el 2026-04-18 para reflejar la arquitectura post-pivote (Keys dejó de ser el eje; son propiedades emergentes) y para consistencia con el resto del ecosistema. - **XDoc** — el átomo del modelo. La unidad base de toda pieza de trabajo operativo. - **SherpaX** — el sistema agéntico que opera sobre el vault. - **DOIX** — el modelo organizacional AI-native que fundamenta WORX. La X común no es decorativa: marca la familia del ecosistema y señala el factor agéntico/exponencial que distingue WORX de metodologías pre-IA. --- # PARTE 1 — FUNDAMENTOS ## SECCIÓN 0 — EL GRAN RETO DEL TRABAJO MODERNO El trabajo es el vehículo por el cual las organizaciones crean valor. Cómo se organiza, cómo se coordina y cómo se ejecuta define el techo de lo que una organización puede lograr. Cada era productiva del último siglo contestó la pregunta de su momento — el taylorismo contestó cómo escalar la producción industrial, el management científico cómo medir el rendimiento, la era del *knowledge work* cómo coordinar a especialistas autónomos, el *agile* cómo adaptarse rápido, el trabajo remoto cómo romper la dependencia del espacio físico. Cada una de esas respuestas fue correcta para su momento. Ninguna contesta la pregunta de 2026. La pregunta actual es distinta en naturaleza. No es una variante más sofisticada de "¿cómo coordinamos humanos?". Es una pregunta nueva: *¿qué diseño de trabajo hace posible que humanos y agentes trabajen juntos sin fricción, creando valor al ritmo que el momento permite?* Esta sección establece por qué esa pregunta es urgente, por qué las respuestas anteriores — incluidas las más recientes — ya no alcanzan, y qué cambia en 2026 que obliga al rediseño. ### 0.1 La búsqueda real y continua de mejorar el trabajo Buena parte de lo que hoy se llama *transformación* no es búsqueda sino acomodación: adoptar la tecnología del momento encima de procesos que no fueron diseñados para ella. La búsqueda real — la que produce reinvención y no solo adopción — tiene otro carácter: es continua, se sostiene en el tiempo, y se reformula cada vez que la base tecnológica o social cambia. EmpowerLabs es evidencia de esa búsqueda. Desde 2004, cuando el trabajo remoto aún era periférico, la pregunta ha sido la misma con sujetos distintos: *¿cómo trabaja mejor un equipo, en cualquier lugar, con lo que esté disponible?* Esa pregunta se formuló con Messenger y correo cuando la conectividad era incipiente, con MasterSuite y el principio DO IT cuando la coordinación en tiempo real se volvió técnicamente posible, con DOIX cuando los agentes de IA empezaron a integrarse como participantes activos del trabajo, y con WORX ahora, cuando esa integración necesita arquitectura ejecutable — no solo marco conceptual. Las 5 preguntas que emergieron en ese recorrido — *¿a dónde vamos? / ¿cómo vamos? / ¿qué tengo que hacer ahora? / ¿cómo se debe hacer el trabajo? / ¿cómo podemos mejorar?* — siguen siendo las preguntas que una organización debe poder contestar en todo momento. Lo que cambia de era en era no son las preguntas. Son los mecanismos con que se contestan. Cada breakthrough tecnológico redefine esos mecanismos, y la organización que lo detecta primero y lo integra al diseño de su trabajo se separa del resto. Este MPB es resultado de esa búsqueda continua. No propone un framework más — formaliza la arquitectura a la que veinte años de búsqueda convergen cuando la IA agéntica se vuelve parte estructural del trabajo. ### 0.2 Los costos ocultos del trabajo tradicional El trabajo tradicional — el que combina humanos, correo, reuniones, hojas de cálculo, herramientas colaborativas y una pila variable de aplicaciones de productividad — tiene costos que no aparecen en ningún presupuesto pero consumen la mayor parte de la capacidad operativa de una organización. Son costos de diseño, no de ejecución. **Reuniones de status como parche a coordinación mal diseñada.** Una organización bien diseñada no necesita reuniones para saber dónde está. La reunión existe porque el estado no es legible por otros medios. Cuando se vuelve el canal principal para enterarse, el costo ya no es la reunión en sí — es el trabajo productivo que no se hace durante ella y las decisiones que se toman sobre información obsoleta entre reuniones. **Doble captura de información.** Cada dato importante existe en más de un sistema: CRM, hoja de cálculo operativa, base de clientes del área comercial, deck del pitch, seguimiento del runner. La organización paga ese costo tres veces — al capturar, al reconciliar, y al descubrir que los números no coinciden cuando importan. **Conocimiento que se pierde cuando una persona se va.** El contexto de por qué se tomó una decisión, cuál es el historial con un cliente, qué se probó y no funcionó — vive en la cabeza de quien lo construyó. Cuando esa persona se mueve de rol o sale de la organización, ese contexto desaparece. La organización ejecuta el mismo aprendizaje dos veces. **Decisiones no trazables.** Seis meses después, la pregunta *"¿por qué decidimos esto así?"* no tiene respuesta reconstruible. La decisión se tomó en un thread de chat, en una llamada sin acta, o en un documento que nadie encuentra. La organización revisa la decisión otra vez con menos información que la primera. **El "¿dónde quedó esto?"** — el tiempo que cada colaborador gasta buscando el documento correcto, la versión correcta, el mensaje correcto. Estudios recientes lo sitúan en alrededor de **el 60% del tiempo de los *knowledge workers*** dedicado a coordinación y no a trabajo estratégico (*McKinsey, 2025*). La mayor parte de una semana laboral se va en buscar contexto para poder trabajar. Dos lentes conceptuales recientes ayudan a nombrar este costo con precisión. El primero es **Cognitive Waste**: el trabajo cognitivo que se repite por falta de una superficie canónica donde el contexto viva de forma estable. Cada vez que un humano reconstruye el estado de un proyecto, que un agente busca información ya sintetizada antes, o que dos colaboradores explican lo mismo a interlocutores distintos, la organización paga el costo del diseño fallido. El segundo es **Context over Content**: en la era agéntica, el contexto del trabajo — quién decidió, bajo qué supuestos, qué dependía de qué — pesa más que el contenido suelto. Una organización puede generar más contenido que nunca con ayuda de IA y tener menos claridad operativa que antes, porque contenido sin contexto es ruido. Ambos conceptos aparecen con nombre propio en análisis de IA ejecutiva de 2026 (Nate Jones); la observación que capturan no es nueva, pero su nombramiento ayuda a diagnosticar el problema con filo. ### 0.3 La digitalización no resolvió el problema — lo escaló La respuesta de las últimas dos décadas a estos costos fue digitalizar. Se agregaron herramientas: mensajería de equipo, gestión de proyectos, bases de conocimiento, documentos colaborativos, sistemas de CRM, almacenamiento en la nube, dashboards. Cada herramienta resolvió un fragmento del problema. La pila completa no. La pila moderna de productividad fue diseñada para humanos coordinándose entre sí. No fue diseñada para agentes. Cada herramienta tiene su propio modelo de datos, su propia semántica, su propio formato de registro. El contexto se fragmenta entre Slack, Notion, Jira, correo, Google Drive, Teams, Airtable, y las hojas de cálculo que viven en los laptops de los colaboradores. Cuando una organización agrega un agente sobre esa pila, el agente hereda el problema: no puede operar con un contexto que vive fragmentado en diez superficies con reglas distintas. Las estadísticas del estado de adopción lo confirman. Según PwC 2026, **el 80% de los proyectos de IA fallan** en entregar el valor proyectado, y **solo el 12% de los CEOs reporta beneficios reales** de la inversión en IA al momento del análisis. La interpretación inmediata — que la IA aún no está madura, o que las organizaciones no saben usarla — pierde de vista el problema estructural: la IA se está apilando encima de un diseño de trabajo que los humanos ya no podían sostener. Agregar agentes no arregla el diseño. Lo expone. El síntoma es consistente: más herramientas, más canales que coordinar, más bases duplicadas, más decisiones perdidas en threads muertos. La digitalización escaló la fricción en lugar de eliminarla. Un diseño de trabajo que ya era marginal cuando operaba solo con humanos se vuelve inviable cuando debe incorporar agentes como participantes activos. ### 0.4 El breakthrough cuántico de la era de la IA (el momento 2026) 2026 no es un año más de adopción gradual. Es el momento en que la IA deja de ser herramienta asistiva — autocompletar, resumir, buscar — y se vuelve participante activo del trabajo: un agente con scope declarado, tareas asignadas y autonomía acotada. La diferencia es de tipo, no de grado. La señal más clara la da el propio lenguaje de los ejecutivos. Según MIT CISR 2025, **el 76% de los ejecutivos ya percibe a la IA agéntica como un coworker** — no como una herramienta. Ese cambio semántico tiene consecuencias operativas: cuando algo es herramienta, la pregunta es *"¿para qué sirve?"*; cuando es coworker, la pregunta es *"¿qué hace, cómo se coordina con el resto del equipo, quién responde por lo que hace?"*. Esas preguntas no se contestan con integraciones puntuales. Se contestan con diseño de trabajo. La analogía útil: llegó un nuevo tipo de colaborador al equipo. No duerme, no olvida, trabaja 24/7 y cuesta una fracción del tiempo de un humano por la misma unidad de output. Pero opera bien solo si el ecosistema está diseñado para integrarlo. Si el trabajo vive en reuniones informales, chats efímeros y conocimiento tácito, el nuevo colaborador no tiene superficie donde entrar — y su valor se pierde en la fricción del ecosistema que lo recibe. La pregunta operativa de 2026 no es *"¿cómo incorporamos IA a nuestros procesos?"* sino *"¿qué diseño de trabajo hace posible que humanos y agentes trabajen juntos sin fricción?"*. Las dos preguntas parecen similares pero tienen respuestas completamente distintas: la primera lleva a apilar más herramientas; la segunda obliga a rediseñar el ecosistema. ### 0.5 La exponencialización del valor (de 10X a 100X) La ventaja estructural de integrar agentes al trabajo no es lineal. Cuando el diseño del ecosistema lo permite, el cómputo agéntico se añade al pool de capacidad productiva de la organización: no reemplaza al humano, lo amplía. Lo que un humano hacía en una semana con herramientas tradicionales puede estar listo en un día con humano + agente colaborando bajo un diseño adecuado. Lo que tomaba un mes, una tarde. El lenguaje emergente del análisis ejecutivo de IA en 2026 nombra este patrón **Compute-as-Labor**: el cómputo entra en la misma ecuación que las horas-persona, y deja de medirse solo como costo de infraestructura para medirse como unidad de capacidad productiva. Alrededor de este concepto aparecen dos más que son igualmente estructurales: **Agentic Workflow** — la unidad de trabajo diseñada con puntos explícitos de intervención de agente — y **Orchestration Layer** — la capa de coordinación que hace que múltiples agentes y humanos operen sobre el mismo trabajo sin colisión. La implicación económica es la razón por la que este momento importa. Organizaciones que dominan este patrón pueden pasar de 10X a 100X en output por colaborador — no por heroísmo individual sino por diseño del ecosistema que multiplica lo que cada colaborador puede mover. Organizaciones que no lo dominan ven su productividad estancada mientras sus costos de coordinación siguen creciendo. Esta curva es asimétrica por organización, no por industria. El patrón **Local Hard Takeoff** (Nate Jones, 2026) lo describe con precisión: cuando una organización monta la infraestructura agéntica antes, no compite contra sus pares como lo hacía antes — se separa de ellas. La competencia no se adapta linealmente; la brecha se abre y se vuelve estructuralmente difícil de cerrar con IA encima de la pila anterior. El momento para detectar esta curva y actuar sobre ella es 2026. La HIOrg es la forma organizacional que resulta de actuar; el atraso es estructural para quien no lo hace. ### 0.6 Reinvención: definición operativa La palabra *reinvención* se ha usado tanto que ha perdido filo. Para que sirva en este documento, hay que darle una definición operativa — una que se pueda ejecutar, no solo invocar. **Reinvención, en WORX, es crear la mejor versión a partir de lo mejor de nosotros mismos.** Se rescata lo validado, se descarta lo obsoleto, se construye con lo nuevo. El diseño resultante no es ruptura con el pasado; es continuidad de la búsqueda con mecanismos que el pasado no tenía. Esta definición operativa se traduce en tres exigencias concretas. **Primera exigencia: no es transformación digital con IA encima.** Agregar agentes a una pila digital existente no cambia el diseño, lo carga. La reinvención WORX rediseña el trabajo desde los primeros principios del ecosistema humano-agente, y después elige qué herramientas sobreviven y cómo se integran. **Segunda exigencia: no es contratar prompt engineers ni crear un equipo de IA separado.** El conocimiento de cómo operar con agentes se distribuye en toda la organización, no se encapsula en un silo. Un área de IA separada reproduce el mismo problema que intentaba resolver: fragmenta el contexto en una superficie más. **Tercera exigencia: no es una pila de herramientas nuevas.** La reinvención no se compra. Se construye sobre una arquitectura — la del MPB WORX — que define cómo debe estar organizado el trabajo para que humanos y agentes operen sobre él sin fricción. Las herramientas vienen después, y son consecuencia del diseño. Lo que viene en el resto de este MPB es el rediseño concreto. Sección 1 nombra qué es la metodología y para quién. Sección 2 la posiciona en el linaje DO IT → DOIX → WORX. Sección 3 presenta la arquitectura de tres niveles y una capa ortogonal que atraviesa el documento. Y de Sección 4 en adelante, cada pieza del modelo operativo se vuelve ejecutable — el XDoc como átomo, el ritmo como latido, la plataforma emergente como consecuencia, los contratos como código civil del sistema. Lo que sigue no es teoría. Es la arquitectura que hace posible la reinvención — y la prueba, en un ecosistema que ya la implementa, de que funciona. --- ## SECCIÓN 1 — MANIFIESTO DE REINVENCIÓN Si la Sección 0 nombra la pregunta de 2026, esta sección nombra la respuesta — qué es WORX, qué no es, sobre qué supuestos se construye y para qué unidad de la organización está pensado. La forma manifiesto es deliberada: el modelo operativo que viene en las Partes 2 y 3 solo es legible a la luz de unos pocos compromisos básicos sobre lo que cuenta como trabajo, quién lo ejecuta y dónde vive. ### 1.1 Los cuatro axiomas WORX se sostiene sobre cuatro afirmaciones que el resto del documento da por verdaderas. No son aspiracionales. Cuando se aplican, el modelo opera; cuando se ignoran, el modelo no produce los resultados que promete. **F1 · El trabajo existe para crear valor.** No para producir reportes, no para llenar sistemas, no para sostener ritmos heredados. Toda actividad que no se conecta con un resultado verificable es sobrecarga del sistema. La afirmación parece obvia y casi nunca se cumple — la mayor parte del trabajo en las organizaciones modernas está optimizado para parecerse al trabajo, no para producir valor. WORX corta esa sobrecarga colocando el resultado en la cabeza del XDoc y midiendo todo lo demás contra él. **F2 · La IA es un miembro del equipo, no una herramienta del equipo.** Un colaborador con scope, autonomía acotada y responsabilidad observable. La distinción cambia las preguntas de diseño: no se pregunta *"¿qué tarea le encargamos a la IA?"* — se pregunta *"¿qué tipo de colaborador necesita el equipo y qué condiciones tiene que tener el ecosistema para que pueda operar?"*. La consecuencia es que el agente no se enchufa al trabajo existente; el trabajo se rediseña para que humano y agente operen sobre la misma superficie. **F3 · La documentación ES coordinación.** No es un subproducto del trabajo — es el trabajo, en su forma legible. En un ecosistema donde participan humanos y agentes, lo que no está escrito no existe operativamente. La documentación no es burocracia; es el canal por el que el trabajo se vuelve ejecutable por más de una entidad. Cuando se trata como overhead, el sistema regresa al modo reunión-y-chat y los agentes pierden la superficie sobre la que pueden operar. **F4 · El contexto siempre es transferible.** Toda decisión, dependencia, supuesto y aprendizaje del trabajo deben poder pasar de una persona a otra, de una persona a un agente, o de un agente a otra instancia, sin pérdida significativa. Una organización donde el contexto vive solo en cabezas no es transferible — y por lo tanto no es escalable, no es resiliente y no es operable por agentes. WORX trata la transferibilidad como condición de diseño, no como buena práctica. Estos cuatro axiomas son la base de los cinco contratos (Sección 7), del XDoc como átomo (Sección 4) y de la arquitectura cognitiva (Sección 6). Cualquier decisión de diseño en el resto del documento puede rastrearse hasta uno de ellos. ### 1.2 Qué es WORX WORX es un **método de trabajo para ecosistemas humano-agente**: un conjunto coherente de unidades, ritmos, contratos y mecanismos que permiten que humanos y agentes coordinen producción de valor sobre la misma arquitectura. La sigla compone los cuatro vectores que el método busca encontrar simultáneamente — *Work, Orchestrated, Reinvention, X-factor* — y nombra una posición específica: trabajo orquestado, reinventado desde los primeros principios del ecosistema humano-agente, abierto al factor diferencial que cada equipo aporta. La forma del método es la de un **MetaPlaybook**. No es un producto, no es un software, no es una consultoría. Es la arquitectura ejecutable a la que se llega cuando se aplican F1-F4 con disciplina, expresada como un documento maestro que cualquier organización — interna o externa al ecosistema EmpowerLabs — puede instanciar para su propio contexto. Como todo MetaPlaybook, WORX existe para ser **replicado, adaptado y operado por equipos que no fueron parte de su escritura original**. Esa es la prueba de validez del método. ### 1.3 Qué NO es WORX Cinco confusiones ocupan el espacio donde debería estar WORX. Nombrarlas de frente cierra ese ruido. **No es transformación digital con IA encima.** Una pila digital tradicional con un copiloto enchufado conserva la fragmentación de contexto, la duplicación de superficies y la fricción de coordinación que ya tenía antes de la IA. WORX no se monta sobre una pila legada — se monta sobre el rediseño de la pila a partir de los axiomas. **No es contratar prompt engineers ni crear un equipo de IA separado.** Encapsular el trabajo con IA en un silo reproduce el problema que intentaba resolver: fragmenta el contexto en una superficie más y reserva la capacidad agéntica para quienes ya están en ese silo. WORX distribuye la capacidad de operar con agentes en toda la organización, no la concentra. **No es comprar una pila de herramientas nuevas.** Las herramientas son consecuencia del diseño, no su sustituto. Una organización puede operar WORX con superficies maduras y herramientas sencillas si la arquitectura está bien instalada, y puede fracasar con la pila más sofisticada si los axiomas no se cumplen. **No es pausar el trabajo actual para "transformarse" antes de retomarlo.** Las transformaciones que exigen detener la operación para preparar el cambio fracasan por una razón estructural: el trabajo real es la única fuente de retroalimentación sobre si el rediseño funciona. WORX se instala **sobre proyectos vivos**, no sobre simulacros — la unidad mínima de aplicación es un equipo trabajando un proyecto activo, no un equipo en pausa esperando el rediseño. Esta característica es legado operativo del ecosistema EmpowerLabs y diferenciador estructural frente a las consultorías que sí piden pausa o redirección. **No es reemplazar managers con un dashboard.** El management con visibilidad agéntica no se sustituye por reportería automática. La función gerencial — interpretar señales ambiguas, negociar prioridades, asignar capacidad humana, hacerse responsable de decisiones bajo incertidumbre — se vuelve más importante, no menos, cuando hay agentes en el ecosistema. WORX redefine qué se delega al agente y qué permanece en la persona; no abre la puerta a vaciar la responsabilidad humana en el sistema. ### 1.4 Para quién WORX se aplica a una unidad específica: **un equipo concreto trabajando un proyecto vivo**. No al individuo aislado, no a la organización abstracta, no al departamento como entidad permanente. La unidad que importa es el equipo + el proyecto, y el motivo es operativo: el equipo es donde la coordinación se vuelve costo, el proyecto vivo es donde la reinvención produce evidencia. Sin equipo, no hay coordinación que rediseñar; sin proyecto vivo, no hay retroalimentación sobre si el rediseño funciona. Tres figuras se definen sobre esa unidad. **Líderes de equipo** que reconocen que la coordinación de su equipo se ha vuelto el cuello de botella y quieren rediseñar el trabajo, no solo agregar herramientas. **Profesionales de la transformación organizacional** — consultores DO, arquitectos de procesos, líderes de *change management* — que necesitan una arquitectura ejecutable detrás de la palabra *reinvención*, no un marco más. **CEOs y C-levels** que leen la curva del *Local Hard Takeoff* y entienden que la respuesta no es comprar IA sino diseñar el trabajo que la integra. WORX no requiere que toda la organización adopte el método al mismo tiempo. Empieza con un equipo, con un proyecto, con un ciclo. La generalización es consecuencia de instalaciones exitosas — no precondición. ### 1.5 WORX en relación con el SO-HiORG WORX no es el sistema completo. Es el **método** dentro de un sistema mayor llamado **SO-HiORG** (Sistema Operativo Organizacional de la Organización Hiperinteligente), el producto canónico del ecosistema EmpowerLabs que combina tres pilares: WORX como método, **Corp-Brain-OS** como arquitectura que captura y activa la IP organizacional, y **SherpaX** como interfaz humana del sistema. La separación es deliberada — el método dice cómo se hace el trabajo, la arquitectura dice dónde vive el trabajo y cómo se vuelve activo, la interfaz dice cómo el humano entra al sistema sin fricción. WORX es uno de los tres pilares y a la vez tiene **vida propia fuera del SO-HiORG**. Una organización puede instalar WORX como método sin adoptar el producto completo — en un equipo, en un área, en un proyecto — y obtener parte del valor: trabajo legible, ejecutable por humanos y agentes sobre una superficie común. La instalación completa con los tres pilares es lo que produce los efectos compuestos del SO-HiORG (proyectos resueltos, equipo capacitado y ecosistema instalado simultáneamente). La instalación parcial, con WORX como método, sigue siendo valiosa por sí misma. Este MPB describe WORX. Para cómo se compone con Corp-Brain-OS y SherpaX en el producto SO-HiORG, ver el XPack `XP-EL-HIORGS-Portfolio-v01`. --- ## SECCIÓN 2 — POSICIÓN EN EL ECOSISTEMA WORX no aparece en un vacío. Aparece como respuesta a un agotamiento — el de las arquitecturas del trabajo que dominaron el último siglo y que ya no contienen al ecosistema humano-agente. Esta sección sitúa a WORX en ese paisaje: qué arquitecturas la preceden, qué cambia con la cuarta, por qué el linaje del ecosistema EmpowerLabs llega a este modelo y qué reemplaza o desplaza WORX dentro de la pila digital actual. ### 2.1 Cuatro arquitecturas del trabajo moderno El trabajo organizacional moderno se ha sostenido sobre tres arquitecturas sucesivas y está entrando en una cuarta. **Arquitectura de procesos lineales** (siglo XX). Heredada del taylorismo y del management científico, organiza el trabajo como una secuencia de pasos especializados que recorre un objeto productivo de un departamento al siguiente. Su fuerza es la repetición confiable; su límite es que asume estabilidad de inputs y un único producto. No fue diseñada para el trabajo de conocimiento. **Arquitectura de pila modular** (últimos veinte años). Reemplaza la secuencia por colaboración entre especialistas autónomos coordinados por reuniones, ritmos *agile* y herramientas verticales. Cada equipo elige su mejor herramienta y los equipos se sincronizan en interfaces explícitas. Su fuerza es la velocidad de iteración; su límite es la fragmentación: el contexto vive en cada herramienta vertical y la coordinación se vuelve costo creciente conforme se suman equipos y herramientas. **Arquitectura de pila digitalizada con IA encima** (desde 2022 aproximadamente). Intenta escalar la pila modular agregándole copilotos, integraciones IA y dashboards inteligentes. Mantiene la fragmentación de la arquitectura previa pero le suma la promesa de que la IA cierre la fricción con asistencia. La evidencia agregada — 80% de proyectos de IA que no entregan valor proyectado, 12% de CEOs que reportan beneficios reales (PwC 2026) — sugiere que la promesa no se cumple porque el problema no es de asistencia, sino de diseño. **La cuarta arquitectura** es el trabajo agéntico estructurado: una arquitectura diseñada desde primeros principios para que humanos y agentes operen sobre la misma superficie sin fricción. Sus elementos no son opcionales — exige una unidad atómica común (el XDoc), un ritmo de uso compartido (los cuatro ritmos), una capa cognitiva donde el contexto se vuelve activo y un conjunto de contratos que humanos y agentes respeten por igual. WORX es la formalización de esta cuarta arquitectura. El lenguaje *Agentic Structured Work* y la noción de *Interpretive Boundary* — frontera entre lo que un agente puede ejecutar autónomamente y lo que requiere interpretación humana —, emergentes en el análisis ejecutivo de IA en 2026 (Nate Jones), nombran con precisión lo que esta cuarta arquitectura tiene que resolver: no es solo dónde vive el trabajo, sino dónde está la línea entre delegación y decisión humana, y cómo se mantiene legible para ambas entidades. ### 2.2 Cinco capas del reto que justifican una cuarta arquitectura Que el trabajo necesite una cuarta arquitectura no es afirmación de mercado — es lectura de un problema con cinco capas que las arquitecturas anteriores no contienen. Las capas son acumulativas: cada una se monta sobre la anterior y ninguna herramienta suelta resuelve más de un fragmento. **Capa 1 — Lo que las organizaciones saben que no saben.** La parálisis de arranque frente a la IA es generalizada y costosa. Organizaciones que reconocen el cambio no saben por dónde empezar, qué medir, ni cómo evaluar lo que se les vende. La consecuencia es post-pone, piloteo disperso o adopción defensiva (RAND, MIT Sloan). **Capa 2 — Lo que no saben que no saben.** Por debajo del problema visible viven costos ocultos que ningún reporte estándar levanta: el costo de coordinación interna (Cognitive Waste, Sección 0.2), el costo de oportunidad de no integrar IA al trabajo de quien sí podría hacerlo y el costo estructural de no capturar la IP organizacional en una arquitectura donde se vuelva activable por humanos y agentes (McKinsey, Deloitte, Harvard). **Capa 3 — El caos operacional del día a día.** Quienes más necesitan la IA tienen menos ancho de banda para incorporarla. Los líderes y equipos saturados que cargan con el trabajo crítico son los mismos a los que se les pide rediseñar cómo operan. Sin un método que se instale sobre proyectos vivos sin pausarlos, el cambio no llega a los lugares donde más valor produciría (Bain). **Capa 4 — La carga específica sobre TI.** Sobre el área de tecnología caen siete frentes simultáneos: seguridad de datos con agentes, gobernanza de modelos, arquitectura de integración, velocidad del cambio del stack, IA para operar TI mismo, compatibilidad con sistemas existentes y presión interna por entregar resultados. Ninguna de las arquitecturas anteriores reparte esta carga; toda recae en el equipo más solicitado. **Capa 5 — La dimensión humana.** El estado del compromiso laboral es el peor en una década: solo el 21% de los colaboradores se reportan comprometidos con su trabajo y la pérdida estimada de productividad asociada se ubica en el orden de **USD 8.8 billones** anuales a escala global (Gallup, 2025/26). Una arquitectura que ignore esta capa — que trate la transformación como problema técnico — fracasa antes de empezar, porque la cuarta arquitectura solo opera si los humanos del ecosistema la encuentran legible, justa y valiosa. WORX se diseña para responder a las cinco capas simultáneamente. El método explícito atiende la Capa 1; la arquitectura cognitiva captura la IP escondida y atiende la Capa 2; el principio de instalarse sobre proyectos vivos atiende la Capa 3; la integración técnica explícita en el XDoc y en la plataforma emergente atiende la Capa 4; y la interfaz humana — que en el SO-HiORG es SherpaX — atiende la Capa 5. Ninguna herramienta suelta lo hace. Ningún copiloto lo hace. La cuarta arquitectura es la unidad mínima de respuesta. ### 2.3 Linaje EmpowerLabs: la búsqueda continua El linaje del ecosistema EmpowerLabs es evidencia operativa de que la cuarta arquitectura se ha estado buscando desde antes de que la IA agéntica la hiciera urgente. La búsqueda se sostuvo sobre una pregunta constante con sujetos cambiantes — *¿cómo trabaja mejor un equipo, en cualquier lugar, con lo que esté disponible?* — y produjo cuatro estaciones reconocibles. **2004 — Trabajo distribuido sobre Messenger y correo.** La pregunta nace cuando el trabajo remoto era todavía marginal. La respuesta de la era es identificar que la coordinación es el cuello de botella y que las herramientas disponibles fueron diseñadas para lo síncrono. Aquí se formula por primera vez el principio de que la documentación no es burocracia sino canal. **Era MasterSuite + DO IT.** Cuando la coordinación en tiempo real se volvió técnicamente posible, la respuesta condensa cuatro instrucciones operativas — *Design, ONE place, Intelligence, Team* — que reconocen que el trabajo distribuido necesita diseño explícito, una sola superficie canónica, lectura inteligente del contexto y trabajo en equipo como unidad. DO IT formaliza la primera versión coherente de esa búsqueda. **Era DOIX.** Cuando los agentes de IA empezaron a integrarse como participantes activos del trabajo, DO IT se reformula para incorporarlos: *Design (Distributed)* convierte el diseño en distribuido entre humanos y agentes; *ONE place* se vuelve una superficie operada por ambos; *Intelligence* deja de ser solo lectura de contexto y se vuelve cómputo agéntico activo; *Team* se redefine para incluir agentes. La X que se le agrega a DOIX nombra el factor diferencial que cada equipo aporta y que el método debe poder absorber, no estandarizar. **Era WORX.** WORX es la formalización ejecutable de DOIX como MetaPlaybook. La X persiste — el factor diferencial sigue siendo central — y se le añade *Reinvention* y *Orchestrated* para nombrar que la integración humano-agente exige rediseño desde primeros principios y orquestación explícita. WORX no rompe con el linaje; lo formaliza para que pueda operarse por equipos que no escribieron el método. Esta progresión no es biografía. Es el rastro operativo de la búsqueda — y la prueba de que la cuarta arquitectura no se construye desde cero en 2026: se construye sobre veinte años de aprendizaje que ya descartaron lo que no funciona. ### 2.4 De DO IT a DOIX a WORX — qué se conserva, qué cambia | Letra | DO IT (era humano) | DOIX (era humano-agente) | WORX (cuarta arquitectura) | |---|---|---|---| | **D** | Design — el trabajo se diseña, no se improvisa | Distributed Design — diseño distribuido entre humanos y agentes | Absorbido como condición previa: el XDoc (Sección 4) es el lugar donde el diseño se vuelve ejecutable | | **O** | ONE place — una sola superficie canónica | ONE place — superficie operada por humanos y agentes | **O**rchestrated — la superficie canónica + el ritmo de uso (Sección 5) explicitado | | **I** | Intelligence — lectura inteligente del contexto | Intelligence agéntica — cómputo activo sobre el contexto | Absorbido en **W**ork (Sección 6 — capa cognitiva donde el contexto se vuelve activo) | | **T** | Team — el equipo es la unidad de trabajo | Team — equipo extendido con agentes como miembros | Absorbido en F2 + Contrato Humano-IA + la **X** (factor diferencial del equipo) | | **X** | — | X-factor — el diferencial del equipo entra al método | **X** persiste como factor diferencial; **R**einvention nombra el método de cambio sobre proyectos vivos | Lo que se conserva es la convicción de que el trabajo necesita diseño explícito, una superficie canónica, lectura activa del contexto y un equipo como unidad. Lo que cambia es el sujeto: en DO IT el sujeto es humano, en DOIX el equipo se vuelve humano-agente, en WORX el método se formaliza como MetaPlaybook ejecutable y el factor diferencial del equipo se sostiene como variable estructural, no como ruido. ### 2.5 Las cinco preguntas como hilo rojo Una organización opera con coherencia en la medida en que puede contestar cinco preguntas en cualquier momento: *¿a dónde vamos? / ¿cómo vamos? / ¿qué tengo que hacer ahora? / ¿cómo se debe hacer el trabajo? / ¿cómo podemos mejorar?*. Las preguntas son las mismas desde 2004; los mecanismos con que se contestan han cambiado en cada estación del linaje. En la era humana, las preguntas se contestaban con reuniones, planes y reportería. En la era humano-agente temprana, con dashboards y copilotos sobre la pila modular. En la cuarta arquitectura las cinco preguntas se contestan **directamente sobre la superficie canónica** — el XDoc contiene su contexto, los ritmos producen su actualización, la capa cognitiva responde sin reuniones extras y los contratos hacen ejecutables las respuestas para humanos y agentes. La continuidad del linaje es exactamente esto: las preguntas no cambian; el costo de contestarlas, sí. ### 2.6 Islas transaccionales conectadas — qué reemplaza WORX, qué orbita WORX no destruye la pila digital existente. La reorganiza alrededor de un núcleo. El núcleo es la superficie canónica donde el trabajo vive (XDoc + capa cognitiva). Lo que orbita son **islas transaccionales conectadas**: sistemas verticales (CRM, ERP, suites de productividad, pila de mensajería) que siguen siendo útiles como sistemas de registro o transacción, pero que **dejan de ser la superficie del trabajo** y pasan a ser fuentes y destinos de información orquestados desde el núcleo. La distinción es operativamente importante. **Lo que WORX reemplaza:** el uso de mensajería de equipo como canal donde el trabajo realmente vive; el uso de hojas de cálculo personales como fuente de verdad operativa; la dependencia de reuniones de status como mecanismo de coordinación; el patrón de doble captura entre sistemas. **Lo que WORX orbita y deja en su lugar:** los sistemas transaccionales especializados — CRM como registro de la relación con cliente, ERP como registro financiero, herramientas de almacenamiento — siguen siendo válidos en su rol. El cambio es que dejan de ser donde se trabaja y se vuelven donde se registra y se transacciona. El efecto neto, una vez instalado WORX, es una pila más simple en lo cognitivo y más interconectada en lo técnico: humanos y agentes operan sobre una superficie común; los sistemas verticales reciben y entregan información a esa superficie a través de protocolos explícitos. La pila digital no desaparece. Pierde el rol de superficie y recupera el rol de servicio. --- ## SECCIÓN 3 — ARQUITECTURA DEL MODELO Esta sección presenta el plano completo del modelo WORX en una vista. Las Partes 2 y 3 desarrollan cada componente con detalle ejecutable; aquí se nombran, se ubican y se relacionan entre sí. La utilidad de esta vista panorámica es que hace legibles las decisiones de las secciones siguientes — cuando aparezca un mecanismo, se sabrá a qué componente pertenece y por qué está ahí. ### 3.1 Vista panorámica — tres niveles, una capa ortogonal y dos pilas transversales La arquitectura WORX se compone de cuatro tipos de elementos que cumplen funciones distintas: **tres niveles** que organizan el trabajo de lo atómico a lo emergente, **una capa ortogonal** que atraviesa los niveles y vive en la persona, y **dos pilas transversales** — la arquitectura cognitiva y los cinco contratos — que sostienen la operación de los tres niveles. ``` ┌──────────────────────────────────────────────────────────────────┐ │ MODELO OPERATIVO WORX │ ├──────────────────────────────────────────────────────────────────┤ │ │ │ NIVEL 3 — PLATAFORMA EMERGENTE (Sección 9) │ │ SherpaX genera vistas desde el vault. │ │ Las apps de productividad se reorganizan o desaparecen. │ │ ↑ │ │ NIVEL 2 — RITMO DE USO (Sección 5) │ │ 4 ritmos por rol (Colaborador / Runner / Owner / Sistema). │ │ Las 5 Preguntas se contestan por diseño en cada ritmo. │ │ ↑ │ │ NIVEL 1 — EL ÁTOMO (Sección 4) │ │ XDoc: cabecera + 7 secciones canónicas. │ │ Las 3Cs (Comunicación, Colaboración, Coordinación) integradas. │ │ │ ├──────────────────────────────────────────────────────────────────┤ │ CAPA ORTOGONAL — CAPACIDADES PERSONALES (Sección 8) │ │ Disciplinas mínimas del trabajador WORX que atraviesan niveles.│ ├──────────────────────────────────────────────────────────────────┤ │ ARQUITECTURA COGNITIVA (Sección 6) │ │ Personal Brain OS ←Sherpa personal→ Corp-Brain-OS │ │ Brain Codes como asesores declarados por documento. │ ├──────────────────────────────────────────────────────────────────┤ │ CINCO CONTRATOS — CÓDIGO CIVIL (Sección 7) │ │ Colaborador · Runner · Owner · Sponsor · Humano-IA │ ├──────────────────────────────────────────────────────────────────┤ │ PROPIEDADES EMERGENTES — los 6 Keys │ │ K1 CONTEXT · K2 INTELLIGENCE · K3 AGENCY │ │ K4 VAULT · K5 GOVERNANCE · K6 CADENCE (transversal) │ └──────────────────────────────────────────────────────────────────┘ ``` La lectura del diagrama es de abajo hacia arriba en términos de fundación, y de arriba hacia abajo en términos de experiencia: el XDoc es la fundación operativa, los ritmos lo activan, la plataforma emerge cuando los dos primeros niveles son consistentes; las pilas transversales son lo que hace que los tres niveles operen como un sistema coherente, no como tres capas independientes. ### 3.2 Los tres niveles del modelo **Nivel 1 — El XDoc (Sección 4).** La unidad atómica del modelo. Un documento estructurado con cabecera fija (Owner + Sponsor + estado + dependencias) y siete secciones canónicas (CONTEXTO → ESTADO → PROTOCOLO → NEXT → DISCUSSION → CHANGELOG → CIERRE) que viven juntas como un solo objeto. Todo lo que cuenta como trabajo en WORX vive en un XDoc — no hay trabajo "fuera" del XDoc, solo trabajo que aún no entró. Las 3Cs (Comunicación, Colaboración, Coordinación) están integradas por construcción: cada sección canónica resuelve uno o varios de los tres flujos sin necesidad de canales paralelos. **Nivel 2 — El Ritmo de Uso (Sección 5).** Cómo se opera el XDoc en el tiempo. Cuatro ritmos definidos por rol — Colaborador, Runner, Owner, Sistema — que organizan el contacto con el ecosistema en ventanas acotadas y predecibles. Las cinco preguntas esenciales se contestan por diseño en alguno de esos ritmos: el Morning Check del Colaborador contesta *¿qué tengo que hacer ahora?*, el Weekly Review del Owner contesta *¿cómo vamos?*, el Pase de Balón del Runner mantiene viva *¿cómo se debe hacer el trabajo?*, y así. El nivel del ritmo es lo que evita que el XDoc se vuelva burocracia inerte: lo activa y lo mantiene auditable. **Nivel 3 — La Plataforma Emergente (Sección 9).** Lo que ocurre cuando los dos primeros niveles están bien instalados. SherpaX genera vistas desde el vault — Tablero Personal, Dashboard de Portafolio, Shadow Meeting, vistas ejecutivas — sustituyendo o reorganizando las apps tradicionales de productividad. Este nivel es **emergente**, no construido: aparece como consecuencia de tener un átomo bien diseñado y un ritmo bien instalado. Una organización no instala la plataforma directamente; instala el XDoc y el ritmo, y la plataforma emerge. ### 3.3 La capa ortogonal — capacidades personales Atraviesa los tres niveles y vive en la persona. La capa ortogonal (Sección 8) define las **disciplinas mínimas** que un trabajador WORX necesita para que los niveles operen sobre él: hábitos de Close Loop al cerrar acciones, disciplina de narrar al Sherpa personal en lugar de coordinar manualmente, capacidad de leer un XDoc como objeto técnico, manejo declarativo de su propio Personal Brain OS. Es la capa donde el método se vuelve conducta. Sin ella, la arquitectura existe pero no opera. La distinción entre niveles y capa ortogonal es operativamente útil. Los niveles son **estructura del ecosistema**: cómo se organiza el trabajo. La capa ortogonal es **disciplina de la persona**: cómo entra el humano al ecosistema. Una organización puede tener los tres niveles y carecer de la capa ortogonal — y entonces el modelo está instalado pero no funciona. La instalación completa exige las dos cosas. ### 3.4 La arquitectura cognitiva y los cinco contratos — pilas transversales **Arquitectura cognitiva (Sección 6).** Personal Brain OS de cada colaborador, Corp-Brain-OS de la organización, Sherpas personales que median entre los dos, y Brain Codes como asesores declarados por documento. Esta pila es lo que hace que el contexto sea **activo**, no archivo: el conocimiento de la organización deja de vivir en cabezas y en carpetas y empieza a vivir en una arquitectura que humanos y agentes pueden consultar, citar y extender. La arquitectura cognitiva atraviesa los tres niveles — el XDoc declara los Brain Codes que aplican a su trabajo, los ritmos consultan el Personal Brain OS al cerrar loops, la plataforma usa el Corp-Brain-OS para regenerar vistas. Dentro del SO-HiORG, esta pila es el pilar **Corp-Brain-OS** del producto. **Cinco contratos (Sección 7).** Código civil del sistema. Cinco contratos que humanos y agentes respetan por igual — Colaborador, Runner, Owner, Sponsor y Humano-IA — y que definen qué se puede esperar de cada rol y qué obligaciones asume. Los contratos son lo que hace que el modelo sea **gobernable**: cuando algo falla, hay una referencia explícita contra la cual auditar. Sin los contratos, el modelo es buena intención; con los contratos, es un sistema operable bajo riesgo. ### 3.5 Las 6 Keys como propiedades emergentes K1 CONTEXT, K2 INTELLIGENCE, K3 AGENCY, K4 VAULT, K5 GOVERNANCE y K6 CADENCE son los seis adjetivos que describen un sistema WORX bien instalado. **No son mecanismos**, no son ejes de matriz, no son módulos del producto. Son **propiedades emergentes** que aparecen cuando los tres niveles + la capa ortogonal + las dos pilas transversales operan en conjunto. Un sistema WORX bien instalado tiene contexto activo (K1), inteligencia accesible (K2), agencia distribuida entre humanos y agentes (K3), vault como capa de verdad (K4), gobernanza explícita (K5) y cadencia que sostiene el ritmo (K6). Estas propiedades no se diseñan por separado; se observan en el sistema instalado. K6 CADENCE merece una nota: cumple un papel transversal — es la cadencia con la que los otros cinco se mantienen vivos. Sin K6, los demás se degradan por entropía. K6 no es un Key al mismo nivel; es la propiedad temporal de los otros. ### 3.6 Las 5 preguntas y los 3Cs — principios satisfechos por diseño Las cinco preguntas esenciales (*¿a dónde vamos? / ¿cómo vamos? / ¿qué tengo que hacer ahora? / ¿cómo se debe hacer el trabajo? / ¿cómo podemos mejorar?*) y las tres Cs (Comunicación, Colaboración, Coordinación) **no aparecen como módulos** de WORX. Aparecen como **principios que el modelo satisface por diseño**: las cinco preguntas se contestan en los ritmos del Nivel 2; las tres Cs se integran en las siete secciones canónicas del XDoc en Nivel 1. Una organización que opera WORX no necesita ejecutar workshops sobre las 5 preguntas o las 3Cs — el modelo las contesta sin intervención adicional. Si no las contesta, el modelo está mal instalado. ### 3.7 Mapeo con los pilares del SO-HiORG La arquitectura del modelo se relaciona con los tres pilares del producto SO-HiORG (Sección 1.5) de manera explícita. **WORX como pilar-método** es lo que aporta el método explícito: los tres niveles, la capa ortogonal, los contratos y las propiedades emergentes — todo lo que este MPB describe. **Corp-Brain-OS como pilar-arquitectura** se realiza operativamente como la arquitectura cognitiva (Sección 6) — la pila Personal Brain OS / Corp-Brain-OS / Brain Codes es lo que el producto SO-HiORG monta sobre el método. **SherpaX como pilar-interfaz** se realiza como la plataforma emergente del Nivel 3 (Sección 9) — la cara humana del sistema, donde las vistas se generan y donde el colaborador entra al ecosistema sin tener que aprender la arquitectura interna. Este mapeo permite leer el MPB de dos formas: como descripción autosuficiente de un método (válida para una organización que solo instale WORX) y como descripción del componente-método dentro de un producto mayor (válida cuando se instala el SO-HiORG completo). Las dos lecturas son consistentes; el resto del MPB las soporta sin necesidad de elegir entre ellas. --- # PARTE 2 — EL MODELO OPERATIVO ## SECCIÓN 4 — NIVEL 1: EL XDOC ### 4.1 La unidad base del modelo WORX Para construir un ecosistema de trabajo operable por humanos y agentes, hace falta una unidad base. Una forma canónica a partir de la cual todo lo demás se organiza. En WORX esa unidad se llama **XDoc** — el átomo del modelo. El XDoc no es una plantilla ni un formato de documentación. Es la forma elemental del trabajo. Cada pieza operativa de una organización WORX — un proyecto, un cliente, una decisión, una iniciativa, una cuenta — vive como un XDoc con la misma arquitectura interna. Esa repetición no es rigidez estética: es lo que permite que el trabajo continúe cuando cambia la persona que lo lleva, que un agente lo lea sin ambigüedad, y que la memoria operativa de la organización quede registrada por construcción. Un ecosistema donde cada documento tiene una forma distinta no es un ecosistema. Es un archivo personal distribuido entre colaboradores, con todos los costos de fricción que eso implica. El XDoc resuelve ese problema por especificación: una sola forma, aplicada sin excepciones, para toda pieza de trabajo activo. > **Callout — el XDoc como precondición de convergencia humano-IA.** > El análisis ejecutivo de IA en 2026 (Karpathy, video 2 — ver Anexo A) identifica que el ciclo entre humano e IA solo converge cuando ambos operan sobre **un mismo documento canónico** que actúa como estado compartido del trabajo. Sin ese documento, cada lado mantiene su versión del contexto y la fricción se acumula a cada paso. El XDoc satisface esa precondición por construcción — es la "ONE Document" de cada pieza de trabajo, escrita de forma que ambas entidades puedan leer, escribir y razonar sobre ella sin reconciliación posterior. Esta correspondencia no se diseñó después del hecho: el XDoc tenía esta propiedad desde la primera versión de WORX, y el lenguaje externo de 2026 nombra con precisión lo que el modelo ya producía. ### 4.2 Las cuatro premisas innegociables El XDoc se sostiene sobre cuatro premisas de diseño. Ninguna es aspiracional. Son las condiciones que hacen posible todo lo demás. **Premisa 1. El número de secciones es cerrado.** Siete, siempre las mismas, siempre en el mismo orden. Si un XDoc necesita algo que no cabe en las siete, la respuesta WORX no es agregar una octava sección — es revisar por qué la información no encuentra lugar. Lo habitual es que la información exista, pero esté mal clasificada. **Premisa 2. El formato es estructurado, no prosa libre.** Cada sección tiene su forma predecible: listas, tablas, líneas con campos nombrados. Esto tiene dos consecuencias operativas: un humano escanea el XDoc en segundos, y un agente lo procesa sin interpretar ambigüedad. **Premisa 3. Cada sección tiene una regla de oro sobre quién escribe.** No es una sugerencia de buena práctica. Es parte de la forma. La gobernanza del XDoc está incrustada en la forma misma, no en un layer separado de políticas. **Premisa 4. Un NEXT solo cierra con entrada de CHANGELOG que lo referencia.** Esta es la regla que convierte al XDoc en un sistema auditable. Sin ella, el documento queda como inventario de intenciones; con ella, es el registro operativo verdadero de la organización. ### 4.3 La cabecera canónica Todo XDoc abre con una cabecera que permanece visible durante toda la vida del doc: ``` Owner: @Agente-o-Persona Sponsor: @Persona Runner(s): @Persona [track: X], @Persona [track: Y] Brain Codes asesores: BC-..., BC-... Tipo: [proyecto | cliente | decisión | iniciativa | cuenta] Última actualización: YYYY-MM-DD ``` Cada campo tiene función operativa concreta. **Owner.** Responsable operativo del XDoc. Puede ser **humano o agente** — un SherpaX, un agente especializado, un BC con rol operativo declarado. Una sola entidad nominal por XDoc. **Sponsor.** Autoridad humana final del XDoc. **Siempre es humano**, y existe independientemente de si el Owner es humano o agente. Cuando el Owner es humano, típicamente Owner y Sponsor son la misma persona (se puede omitir la línea o declarar `Sponsor: = Owner`). Cuando el Owner es agente, el Sponsor es el ancla decisional: su firma humana es necesaria para decisiones vinculantes (ver §4.4.6). **Runner(s).** Quienes tienen el balón del trabajo activo en este momento. Pueden ser humanos o agentes. Puede haber varios simultáneos si el trabajo corre en tracks paralelos. **Brain Codes asesores.** Módulos de conocimiento declarados que se invocan cuando hay consulta conceptual sobre el XDoc. **Tipo.** Clasifica el XDoc dentro del catálogo operativo de la organización. **Última actualización.** Señal rápida de vigencia. La cabecera se lee antes de entrar al cuerpo. Si alguien no conoce un XDoc, la cabecera le dice en seis segundos qué es, quién lo maneja, quién responde por él, y cuándo fue la última acción. ### 4.4 Las siete secciones canónicas El cuerpo del XDoc está hecho de siete secciones, en orden fijo: | # | Sección | Quién escribe | Qué contiene | Regla de oro | |---|---------|---------------|--------------|--------------| | 1 | **CONTEXTO** | Owner | Propósito, resultado esperado, stakeholders, BCs asesores | Solo Owner. Casi nunca cambia. | | 2 | **ESTADO** | Owner / Runner | Salud (🟢🟡🔴), hito activo, última decisión, **dependencias**, bloqueos | Actualiza en cada movimiento material. | | 3 | **PROTOCOLO** | Owner | Link al SOP vigente + versión + desviaciones declaradas | Si hay drift, se declara aquí. | | 4 | **NEXT** | Cualquiera agrega / asignado cierra | Acciones pendientes con formato `NEXT[@Persona] — acción — deadline — contexto → estado` | Solo el @Persona asignado cierra. | | 5 | **DISCUSSION** | Cualquiera | Conversación append-only con timestamp + autor | Se promueve a NEXT o CHANGELOG cuando aterriza. | | 6 | **CHANGELOG** | Quien ejecuta / decide / aprende | Append-only. Tags `[EXEC]` `[DECIDE]` `[LEARN]` `[RUNNER]` | Inmutable. `[DECIDE]` requiere firma humana. | | 7 | **CIERRE** | Owner (co-firma Sponsor si Owner es agente) | Aprendizaje final + envío al LabPraxis + archivado | Una sola vez, al final. | El orden no es arbitrario. Refleja cómo se activa y se cierra un XDoc: primero se establece por qué existe (CONTEXTO) y cómo va ahora (ESTADO); luego bajo qué reglas opera (PROTOCOLO); luego se ejecuta (NEXT), se piensa en voz alta (DISCUSSION), se registra lo que pasó (CHANGELOG), y por último se cierra con el aprendizaje (CIERRE). #### 4.4.1 CONTEXTO — por qué existe el XDoc La escribe el Owner una sola vez, y rara vez se reescribe. Contiene: propósito del XDoc, resultado esperado, stakeholders involucrados, y los Brain Codes asesores declarados. Responde *"¿por qué este XDoc existe y qué tiene que lograr?"*. Si el contexto cambia de forma material — cambia el propósito o el resultado esperado — la señal operativa correcta no es reescribir esta sección. Es cerrar el XDoc y abrir uno nuevo. El cambio de contexto es un evento, no una edición. #### 4.4.2 ESTADO — dónde estamos ahora La escriben el Owner y los Runners. Contiene: salud del XDoc (🟢🟡🔴), hito activo, última decisión registrada, **dependencias activas**, y bloqueos vigentes. Se actualiza con cada movimiento material del trabajo. Esta es la sección que se revisa primero en cualquier vista — el Dashboard de Portafolio del Sponsor, el Morning Check del Runner, la auditoría de SherpaX. Un ESTADO desactualizado es ruido sistémico para toda la organización. Por eso su regla de oro es la más exigente: se mantiene viva en cada paso. Las dependencias merecen tratamiento formal propio. ##### 4.4.2.1 Dependencias Las dependencias son las condiciones externas que el XDoc necesita satisfechas para avanzar. Se declaran explícitamente en ESTADO, con tipo y estado. Mantener las dependencias invisibles fue históricamente una de las fuentes principales de fricción en sistemas de trabajo anteriores: lo que falta no quedaba explícito, y cuando un XDoc se trababa por un INPUT pendiente, no había manera rápida de saberlo sin preguntar al Runner. WORX resuelve esto haciendo las dependencias parte canónica del ESTADO. **Los cuatro tipos canónicos de dependencia:** | Tipo | Qué es | Ejemplo típico | |------|--------|---------------| | `[INPUT]` | Entregable material, dato o recurso que el XDoc necesita | Materiales, datos de ventas, research preliminar | | `[APROBACIÓN]` | Firma o validación de un rol autorizado | Legal, Finanzas, Compliance, Sponsor de otro XDoc | | `[DOC]` | Output específico de otro XDoc | Sección de otro XDoc, cierre de otro proyecto | | `[DECISIÓN]` | Decisión humana pendiente sobre una ambigüedad | Pricing, arquitectura, dirección estratégica | **Los tres estados canónicos:** `pendiente`, `satisfecha`, `crítica`. Una dependencia que cruza su deadline sin resolver pasa automáticamente a estado `crítica` y se promueve a Bloqueos. **Ejemplo canónico** — XDoc de producción en una factoría: ``` ESTADO - Salud: 🟡 - Hito activo: fase de producción batch #03 - Última decisión: 2026-04-17 — aprobado proveedor alterno - Dependencias: - [INPUT] materiales grado 2 de @Proveedor-Acme — esperado 2026-04-22 — estado: pendiente - [APROBACIÓN] firma legal contrato batch de @Legal — estado: solicitada - [DOC] diseño arquitectura @PROY-X-v02 sección 3 — estado: en curso - [DECISIÓN] pricing final de @Sponsor — estado: abierta (ver NEXT#8) - Bloqueos: ninguno crítico hoy (dep [INPUT] escalará a bloqueo si no llega antes de 2026-04-23) ``` **Las cuatro reglas operativas de las dependencias:** 1. **Visibilidad canónica.** Toda dependencia del XDoc se declara en ESTADO. No se esconden en NEXT ni en DISCUSSION. 2. **Escalamiento automático.** Una dependencia que cruza su deadline sin resolver pasa a estado `crítica` y se promueve a Bloqueos. La transición no depende del criterio del Runner. 3. **Resolución cross-doc.** Cuando la dependencia es `[DOC]`, SherpaX audita el ESTADO o CHANGELOG del XDoc referenciado, detecta si el output se produjo, y propone marcar la dependencia como `satisfecha` (humano confirma). 4. **Trazabilidad.** Cuando una dependencia se satisface, el evento queda registrado en CHANGELOG con tag `[EXEC]` y evidencia — link al artefacto, decisión o entrada de otro XDoc que la resolvió. #### 4.4.3 PROTOCOLO — bajo qué reglas opera La escribe el Owner. Contiene link al SOP vigente aplicable, su versión, y las desviaciones declaradas si las hay. La utilidad real de esta sección aparece cuando hay **drift**: cuando el trabajo operativo se separa del SOP escrito. En lugar de esconder el drift, WORX lo hace visible: el Runner que opera fuera del SOP lo declara aquí, con razón. Esto convierte el drift en señal operativa — candidato a actualización del SOP — en lugar de dejarlo como fricción invisible entre lo escrito y lo real. #### 4.4.4 NEXT — qué sigue Cualquiera agrega un NEXT. Solo el asignado lo cierra. El formato es: ``` NEXT[@Persona] — acción — deadline — contexto → estado ``` El estado típico de un NEXT es uno de cuatro: `abierto`, `en progreso`, `blocked por NEXT#N`, `done`. NEXT es el canal de ejecución del XDoc. Sin esta sección, el documento se vuelve archivo pasivo; con ella, es organismo activo con acciones pendientes identificables y asignadas. Las dependencias estructurales del XDoc no se escriben aquí — viven en ESTADO §4.4.2.1. NEXT es para acciones concretas asignadas a alguien; las dependencias son condiciones externas que el XDoc espera. #### 4.4.5 DISCUSSION — dónde se piensa en voz alta La escribe cualquiera. Es append-only con timestamp y autor. Aquí se debate, se explora, se pregunta, se problematiza. DISCUSSION **no sustituye** a NEXT ni a CHANGELOG. Cuando una discusión aterriza — se convierte en acción o en decisión — se promueve: si es acción, a NEXT; si es decisión vinculante, al CHANGELOG con tag `[DECIDE]`. La discusión que no aterriza se conserva como rastro de la exploración del XDoc. Regla clave: ninguna decisión vinculante vive solo en DISCUSSION. Si no llegó al CHANGELOG, no fue decidida — fue comentada. #### 4.4.6 CHANGELOG — qué pasó, cuándo, por quién Lo escribe quien ejecuta, decide, aprende, o pasa el balón. Es append-only. Cada entrada lleva fecha, autor, tag, y evidencia. Los tags canónicos son cuatro: - `[EXEC]` — se ejecutó una acción. - `[DECIDE]` — se tomó una decisión vinculante. - `[LEARN]` — se capturó un aprendizaje (candidato a promoverse al LabPraxis). - `[RUNNER]` — se pasó formalmente el balón entre Runners. **Regla adicional sobre `[DECIDE]`:** toda entrada `[DECIDE]` requiere firma humana. Cuando el Owner del XDoc es humano, la firma del Owner es suficiente. Cuando el Owner del XDoc es **agente**, toda `[DECIDE]` debe llevar **co-firma explícita del Sponsor humano**: ``` 2026-04-22 · @SherpaX (Owner) · [DECIDE] ajuste de pricing aprobado · co-firma: @Victor (Sponsor) · evidencia: [link] ``` Esta regla cierra el Contrato Humano-IA en el momento exacto donde importa: el punto donde una decisión se vuelve vinculante para la organización. El CHANGELOG es inmutable. Si una entrada está mal, la corrección es una entrada nueva que referencia la anterior, no un reemplazo. Esta regla es precisamente lo que hace al XDoc auditable seis meses después. #### 4.4.7 CIERRE — qué queda de esto Lo escribe el Owner una sola vez, al final del ciclo del XDoc. Contiene: aprendizaje final sintetizado, contenido promovido al LabPraxis, y archivado formal. Si el Owner es agente, el CIERRE lleva co-firma explícita del Sponsor (es una decisión vinculante de archivado). Un XDoc que nunca cierra es un XDoc que nunca vivió completo. La ausencia sostenida de CIERRE en docs terminados es una señal estructural a revisar: indica que la organización produce sin consolidar, acumulando XDocs abiertos sin aprendizaje extraído. ### 4.5 Los roles del XDoc Cuatro roles conviven en cada XDoc. **Owner.** El responsable operativo del XDoc. Puede ser **humano o agente** — un SherpaX, un agente especializado, o un BC con rol operativo declarado. Una sola entidad nominal (o dos como máximo cuando la propiedad es genuinamente compartida). El Owner casi nunca cambia durante la vida del XDoc. Cuando cambia, es porque la propiedad del trabajo cambió de verdad, y el cambio queda registrado en el CHANGELOG. **Sponsor.** La autoridad humana final del XDoc. **Siempre es humano, y siempre está declarado** — aunque cuando el Owner es humano, típicamente Sponsor y Owner son la misma persona. Cuando el Owner es agente, el Sponsor es el ancla decisional: su firma es necesaria para entradas `[DECIDE]`, y su co-firma obligatoria en el CIERRE. El Sponsor es el puente entre la autonomía acotada del agente y la autoridad de la organización humana. **Runner.** Quien tiene el balón ahora mismo. Puede ser humano o agente. A diferencia del Owner, el Runner rota: puede haber varios simultáneos en tracks paralelos (por ejemplo, un humano trabajando la propuesta comercial y un agente procesando la arquitectura técnica del mismo proyecto). El pase de balón entre Runners no es cambio de etiqueta. Es un evento formal que entra al CHANGELOG con tag `[RUNNER]`, con razón del pase y handoff declarado. **Contribuidor.** Cualquier persona o agente que entra al XDoc sin ser Owner, Sponsor ni Runner. Los contribuidores agregan NEXT, participan en DISCUSSION, aportan evidencia al CHANGELOG. No hay que "pedir permiso" para contribuir: solo seguir las reglas de oro de cada sección. Esta apertura estructurada es lo que hace posible la hipercolaboración real, sin que la apertura degenere en desorden. ### 4.6 El ciclo de cierre de NEXT Este es el latido operativo del XDoc. Cuando se detiene, el sistema colapsa: los NEXT se acumulan abiertos, el CHANGELOG queda incompleto, y seis meses después nadie puede reconstruir qué pasó, quién decidió qué, y con base en qué evidencia. **Ejemplo canónico.** Estado inicial en un XDoc de cliente, sección NEXT: ``` NEXT[@Carla] — revisar propuesta Acme v2 — 2026-04-22 — cliente pidió ajustes → abierto ``` Carla ejecuta el trabajo con sus herramientas habituales, fuera del XDoc. Cuando termina, cierra el loop — en la práctica lo hace narrando a su Sherpa personal, que traduce a estructura WORX (ver Sección 6). El cierre formal consiste en cuatro pasos: **1. Se agrega entrada al CHANGELOG:** ``` 2026-04-22 · @Carla · [EXEC] revisó propuesta Acme v2 — 3 ajustes sugeridos (alcance fase 2, timing, pricing) · evidencia: [link] · cierra NEXT#7 ``` **2. NEXT#7 pasa a estado `done`, tachado con link al CHANGELOG.** **3. Si surgen acciones, se agregan como NEXT nuevos:** ``` NEXT[@Victor] — decidir pricing — 2026-04-24 → abierto NEXT[@Carla] — enviar v3 tras decisión — 2026-04-25 → blocked por NEXT#8 ``` **4. Si hay aprendizaje, entra al CHANGELOG con tag `[LEARN]`**, marcado como candidato a promoverse al LabPraxis en el cierre del XDoc. La regla que sostiene el ciclo completo: **un NEXT no cierra sin entrada de CHANGELOG que lo referencia.** Sin excepciones. Es el contrato entre intención y ejecución, y es lo que hace al sistema auditable en cualquier momento. SherpaX puede hacer esa auditoría de forma continua, y lo hace por default. ### 4.7 El ritual Vault-First El XDoc viene con un ritual asociado: **antes de producir sobre un XDoc existente, consultar el vault.** No es recomendación. Es protocolo. El reflejo WORX es de cuatro pasos: 1. Buscar el Transfer Pack o documento de referencia del proyecto. 2. Leer qué ya está definido — CONTEXTO, ESTADO actual (incluyendo dependencias y bloqueos), últimas decisiones del CHANGELOG. 3. Identificar el punto de partida real. 4. Producir desde ahí, no desde cero. El costo del ritual se mide en minutos. El costo de saltárselo se mide en trabajo duplicado, decisiones ya cerradas que se reproponen, dependencias que se vuelven a pedir cuando ya estaban en marcha, alineación rota entre colaboradores que no saben del trabajo previo. En una organización WORX, la pregunta *"¿dónde quedó esto?"* es una señal de fricción sistémica. La respuesta siempre debería ser la misma: **en el XDoc**. ### 4.8 Las reglas inviolables del Nivel 1 Las siguientes once reglas no se flexibilizan. Son el contrato de la forma del XDoc: 1. El XDoc tiene siete secciones canónicas, en orden fijo. No se agregan, no se reordenan. 2. La cabecera es siempre visible al inicio del XDoc. 3. El Owner puede ser humano o agente. El Sponsor siempre es humano, y siempre está declarado. 4. Toda entrada `[DECIDE]` requiere firma humana. Cuando el Owner es agente, se registra co-firma explícita del Sponsor. 5. Cada sección tiene una regla de oro sobre quién puede escribir en ella. 6. Un NEXT solo cierra con entrada de CHANGELOG que lo referencia. 7. El CHANGELOG es append-only e inmutable. Se corrige con nueva entrada, no se edita. 8. Las dependencias del XDoc se declaran en ESTADO con tipo canónico (`[INPUT]`, `[APROBACIÓN]`, `[DOC]`, `[DECISIÓN]`). Cruzar deadline las promueve a Bloqueos. 9. El pase de balón entre Runners es evento formal, registrado en CHANGELOG con tag `[RUNNER]`. 10. Ningún agente cierra un NEXT, edita un CHANGELOG, ni promueve una DISCUSSION sin confirmación humana. 11. Antes de producir sobre un XDoc existente: Vault-First. Estas once reglas son el piso de la forma. Todo lo demás del modelo WORX — los ritmos, la arquitectura cognitiva, los contratos, la plataforma emergente — descansa sobre ellas. Si el Nivel 1 no se respeta, ninguno de los niveles superiores es sostenible. --- ## SECCIÓN 5 — NIVEL 2: EL RITMO DE USO ### 5.1 Por qué hace falta un nivel de ritmo El XDoc resuelve la forma del trabajo. No resuelve su cadencia. Un ecosistema de XDocs estructuralmente perfectos sin ritmo de uso es un archivo ordenado que nadie abre. La sección 4 hizo operable el átomo; esta sección hace que el átomo se use. La unidad que organiza el ritmo WORX no es el reloj ni el calendario — es el XDoc. Cada rol tiene un ritmo propio expresado como un conjunto acotado de momentos en que interviene sobre el XDoc: cuándo lo abre, qué mira, qué produce, cuándo lo cierra. El ritmo no se decreta desde arriba. Se desprende de la forma del XDoc más la función de cada rol. El ritmo WORX responde por diseño a tres de las cinco preguntas esenciales: *¿Cómo vamos?* (ESTADO consultado en cada Morning Check), *¿Qué tengo que hacer ahora?* (NEXT del día en el Tablero Personal), *¿Cómo podemos mejorar?* (CHANGELOG `[LEARN]` sintetizado en la Retro de Ritmo). El trabajo de responder estas preguntas deja de ser evento; se vuelve flujo. ### 5.2 Los dos principios de ritmo El Nivel 2 se sostiene sobre dos principios. El resto son consecuencias. **Principio 1. Async-first.** El reloj del trabajo es el ritmo del XDoc, no el calendario de reuniones. La coordinación rutinaria ocurre en CONTEXTO/ESTADO/NEXT/CHANGELOG, que son async por construcción. La sincronía se reserva para lo que solo se puede hacer en presencia humana — juicio colectivo, decisiones complejas, ajuste de dirección en momentos de cambio material. Un sistema donde lo async es default y lo síncrono es excepción libera proporciones significativas del tiempo que las organizaciones pre-IA gastaban en coordinar. **Principio 2. Dual cadence.** Dos cadencias paralelas conviven sin fusionarse. *Flujo continuo* para el trabajo exploratorio, donde el descubrimiento es el entregable — sin sprints fijos, el XDoc avanza según su naturaleza. *Pulso sincronizado* para el trabajo de entrega, ingeniería y gobernanza — donde la alineación colectiva necesita un latido compartido. Un equipo WORX no elige entre Kanban y Sprint; opera los dos al mismo tiempo, con claridad sobre qué XDoc vive en cada cadencia. K6 CADENCE, una de las seis propiedades emergentes del modelo, es precisamente lo que se materializa cuando estos dos principios entran en régimen. No es un mecanismo separado; es la consecuencia de que los ritmos por rol, las vistas de Morning Check y la dual cadence funcionen en concierto. ### 5.3 Los cuatro ritmos por rol Cada rol del XDoc tiene un ritmo canónico. La tabla siguiente es el mapa completo; las subsecciones que siguen lo desarrollan. | Rol | Momento diario | Momento por XDoc | Momento periódico | |-----|----------------|------------------|-------------------| | **Colaborador** | Morning Check (5 min) | Close Loop por NEXT cerrado (2–5 min) | — | | **Runner** | Morning Check + Daily Sostén (5 min por XDoc) | Pase de balón como evento formal | Weekly Review (15–20 min por XDoc) | | **Owner / Sponsor** | Revisión por excepción | — | Weekly Portfolio Review (30–45 min) + Monthly Portfolio Close (1 h) | | **Sistema / SherpaX** | Regenera Tableros y Chat Dashboards | Propaga cambios, propone promociones | Resúmenes, audit de drift, salud del sistema | El punto estructural: el tiempo total invertido por rol en mantener el sistema vivo no es grande. Lo que cambia es que ese tiempo queda *concentrado* en ventanas acotadas, sobre vistas generadas por el Sistema, en lugar de disperso en coordinación reactiva permanente. #### 5.3.1 Ritmo del Colaborador Aplica a cualquier persona con NEXTs asignados en uno o más XDocs. Es el ritmo más universal del modelo. - **Morning Check (5 min).** Abre su Tablero Personal generado por Sherpa. Revisa: NEXTs del día, XDocs donde es Runner, Discussion con @mentions, bloqueos promovidos desde dependencias críticas. En cinco minutos queda contestada la pregunta *¿qué tengo que hacer ahora?* - **Execution.** El trabajo profundo ocurre con sus herramientas habituales, fuera del XDoc — editor, hoja de cálculo, código, llamada. El XDoc no pretende ser el espacio de ejecución; es el registro de que la ejecución ocurrió. - **Close Loop (2–5 min por acción).** Al terminar un NEXT, el colaborador cierra el loop: entrada al CHANGELOG con tag `[EXEC]`, NEXT a `done`, y si surgen acciones nuevas o aprendizajes, se agregan como NEXTs o `[LEARN]`. En la práctica esto se hace narrando a su Sherpa personal (Sección 6), que traduce a estructura WORX y el humano confirma. El Close Loop formalizado es lo que hace que el sistema siga auditable. El Colaborador no necesita "saber WORX" en sentido doctrinal. Necesita Morning Check al abrir el día y Close Loop al cerrar cada acción. El resto lo absorbe el Sistema. #### 5.3.2 Ritmo del Runner Quien tiene el balón activo de un XDoc. Hereda todo el ritmo del Colaborador y agrega tres compromisos. - **Daily Sostén (5 min por XDoc).** Revisa la DISCUSSION del XDoc donde tiene el balón, promueve los hilos que aterrizaron (a NEXT si es acción, a `[DECIDE]` si es decisión), y actualiza ESTADO si hubo movimiento material. El sostén diario es lo que evita que el ESTADO se desincronice del trabajo real. - **Weekly Review por XDoc (15–20 min).** Consolida la semana: reescribe ESTADO con el hito activo actual, revisa dependencias abiertas y las escala si corresponde, decide si sigue con el balón o si toca pasarlo. - **Pase de balón formal.** Cuando el balón cambia de Runner, la transición es un evento registrado. Entrada al CHANGELOG con tag `[RUNNER]`, razón del pase, y handoff declarado — qué queda en curso, qué contexto necesita el siguiente Runner para no partir desde cero. Sin esta formalidad el ESTADO se vuelve falso y cada pase silencioso destruye una capa de trazabilidad. #### 5.3.3 Ritmo del Owner y del Sponsor El Owner opera sobre un portafolio de XDocs, no sobre uno a la vez. Su ritmo es el más desplazado hacia la excepción: el Sistema avisa cuándo algo merece atención, y el Owner actúa sobre esa señal. - **Weekly Portfolio Review (30–45 min).** El Owner abre su Dashboard de Portafolio (ver §5.4). Actúa *por excepción*: XDocs en 🟡 o 🔴, dependencias críticas abiertas, drift declarado vs SOP, XDocs sin movimiento en su ventana esperada, NEXTs vencidos del portafolio. La revisión por default no mira XDocs en verde; asume que si el Sistema no levantó señal, el trabajo fluye. - **Monthly Portfolio Close (1 h/mes).** Archiva XDocs cerrados del mes, promueve entradas `[LEARN]` seleccionadas al LabPraxis, revisa drift acumulado del Protocolo vs SOPs, decide actualizaciones del catálogo de SOPs cuando el drift dejó de ser excepción. Cuando el Owner de un XDoc es humano, Owner y Sponsor suelen ser la misma persona, y este ritmo se consolida en un único rol. Cuando el Owner es **agente**, el ritmo se desdobla: el Owner agéntico opera continuo (regenera ESTADO, propone NEXTs, anticipa dependencias), y el Sponsor humano entra en ventanas acotadas — semanal para Portfolio Review, puntual cada vez que el Owner agéntico levanta un `[DECIDE]` que requiere co-firma. El Sponsor no necesita estar dentro del XDoc todos los días; necesita confiar en que el Sistema le muestra los momentos donde su juicio humano es irreemplazable. #### 5.3.4 Ritmo del Sistema (SherpaX) El Sistema tiene un ritmo propio, y ese ritmo es lo que hace posibles todos los demás. - **Morning.** Regenera los Tableros Personales y los Chat Dashboards antes de que los Colaboradores y Runners abran su día. Consolida @mentions, NEXTs del día, bloqueos, dependencias críticas, hilos aterrizados de DISCUSSION. - **Durante el día.** Responde consultas, propaga cambios cross-XDoc (cuando un XDoc satisface una dependencia `[DOC]` de otro, el Sistema detecta y propone al Runner del segundo marcarla como satisfecha — ver §4.4.2.1), propone promociones de DISCUSSION a NEXT o `[DECIDE]` cuando detecta que una conversación aterrizó. - **Weekly.** Produce resúmenes por XDoc para Runners, identifica `[LEARN]` no promovidos, genera el reporte ejecutivo que alimenta la Portfolio Review del Owner. - **Monthly.** Audita drift SOP vs Protocolo declarado a nivel portafolio, identifica candidatos a actualización de SOP, produce la vista agregada de salud del sistema (ver Sección 11). El Sistema propone, nunca cierra. Regenera vistas, detecta patrones, sugiere transiciones de estado. Pero no cierra NEXTs, no edita CHANGELOG, no promueve DISCUSSION, no co-firma `[DECIDE]`. Esa separación entre *lo que el Sistema hace por default* y *lo que requiere acción humana confirmada* es una consecuencia directa de la regla 10 del Nivel 1 — y es lo que vuelve cohabitables los cuatro ritmos sin que el Sistema desborde a los humanos. ### 5.4 Las tres vistas del Morning Check El Morning Check no se hace sobre el XDoc individual. Se hace sobre vistas generadas por el Sistema que agregan los XDocs relevantes para cada rol. Son tres vistas canónicas. **A. Tablero Personal — "mis acciones".** Para todo rol con NEXTs asignados. Contiene: NEXTs del día ordenados por deadline, XDocs donde soy Runner con señal de salud, @mentions recientes en DISCUSSION, bloqueos activos que me tocan. Es el "inbox operativo" del día. **B. Chat Dashboard — "mis conversaciones".** Tercera vista del Morning Check. Agrega las conversaciones activas de DISCUSSION a través de múltiples XDocs, ordenadas por urgencia × importancia. Permite al humano participar conversacionalmente donde haga falta, sin abrir XDoc por XDoc. Cuando un hilo aterriza — se vuelve NEXT o entrada de CHANGELOG — el Sistema lo promueve al XDoc correspondiente y, por default, limpia el thread del Chat. Si el colaborador quiere preservar la conversación bruta, lo indica; el default es limpio. El Chat Dashboard resuelve una fricción real del modelo async-first: la conversación exploratoria necesita un espacio, pero ese espacio no puede convertirse en memoria operativa paralela. **C. Dashboard de Portafolio — "mis XDocs como dueño".** Solo para Owners y Sponsors. Agrega el portafolio completo con salud por XDoc, dependencias críticas cross-doc, NEXTs vencidos del portafolio, drift declarado, XDocs sin cierre en ventana esperada. Es la vista que alimenta la Weekly Portfolio Review y el Monthly Portfolio Close. Las tres vistas comparten una propiedad estructural: **son derivadas, no fuentes**. Ningún campo del Tablero Personal, Chat Dashboard o Dashboard de Portafolio existe ahí de forma primaria. Todo lo que se ve es proyección de contenido que vive en los XDocs. Si una vista se pierde, el Sistema la regenera; si un XDoc se corrompe, las vistas heredan el problema. La dirección de la verdad es siempre *XDoc → vista*, nunca al revés. ### 5.5 Dual cadence en operación El MPB propone dos cadencias paralelas. La elección de cadencia es una propiedad del XDoc, declarada en CONTEXTO o ESTADO. **Flujo continuo (Kanban) — para trabajo exploratorio.** Investigación, aprendizaje, diagnóstico, desarrollo temprano de producto. El descubrimiento es el entregable; imponer sprints fijos rompe el ritmo natural del descubrir. En flujo continuo, el XDoc avanza según su naturaleza, y la Weekly Review del Runner es suficiente para mantener la coherencia. **Pulso sincronizado (Sprint / ciclo fijo) — para trabajo de entrega.** Ingeniería, operaciones, entregables con compromiso externo, gobernanza. Necesita ventanas fijas de alineación colectiva. Aquí los rituales mínimos (§5.6) toman protagonismo: Weekly Downbeat, Demo, Retro. Un equipo WORX típico opera XDocs de los dos tipos al mismo tiempo. Un XDoc de investigación de mercado vive en flujo continuo; un XDoc de entrega de release vive en pulso sincronizado. Los colaboradores transitan entre cadencias según el XDoc en el que estén operando. Lo que no puede suceder es ambigüedad: un XDoc sin cadencia declarada termina operando en la peor versión de ambas — ni la libertad exploratoria del flujo, ni la alineación del pulso. ### 5.6 Los tres tipos de reunión WORX no elimina las reuniones. Las reclasifica, y la reclasificación misma funciona como criterio de eliminación. | Tipo | Propósito | Quién convoca | ¿Es eliminable? | |------|-----------|---------------|-----------------| | **Coordinación** | Actualización de estado, asignación de tareas, revisión de pendientes | Agente / Sistema | ✅ **Sí.** Reemplazable por async sobre el vault. | | **Alineación** | Revisión de avance, ajuste de dirección, demo de trabajo real | Equipo | 🟡 **Parcialmente.** Acortable y menos frecuente con pre-lectura generada por el Sistema. | | **Juicio** | Decisiones complejas, resolución de conflicto, cambio de dirección material | Humanos | ❌ **No.** Es el caso de uso irreemplazable de la sincronía. | La mayor parte del tiempo que una organización pre-IA gasta en reuniones es de tipo Coordinación. En una organización WORX, esas reuniones no existen: la información está en los XDocs, las vistas se regeneran en Morning, y las decisiones rutinarias se toman async. **Shadow Meeting.** Concepto emergente del modelo. Un agente orquesta asincrónicamente la discusión — recopila posiciones, detecta acuerdos, identifica disensos — y si la confianza de consenso supera un umbral declarado, **la reunión no ocurre**. El output es un `[DECIDE]` del XDoc con co-firma humana donde aplica. Cuando el umbral no se alcanza, el agente propone la reunión acotada con agenda pre-cargada y contexto listo para juicio. La sincronía deja de ser default y se vuelve consecuencia. ### 5.7 Los rituales mínimos del equipo Para trabajo en pulso sincronizado, WORX propone un conjunto mínimo de rituales que cubren alineación, demo y mejora. | Ritual | Frecuencia | Duración | Propósito canónico | |--------|-----------|----------|--------------------| | **Weekly Downbeat** | Semanal | 30–45 min | Goals de la semana, riesgos activos, decisiones pendientes del portafolio | | **Demo** | Quincenal | Variable | Mostrar trabajo real (no reportar sobre trabajo) | | **Retro de Ritmo** | Mensual | 60 min | Inspeccionar el ritmo mismo — qué del Nivel 2 está funcionando, qué no | Tres criterios para que estos rituales sean WORX y no teatro operativo: 1. **Pre-lectura generada por el Sistema, no presentación humana.** Nadie llega a una Weekly Downbeat a actualizar verbalmente el estado de sus XDocs. El Sistema produce el reporte ejecutivo, los participantes lo leen antes, la reunión entra directo a riesgos y decisiones. 2. **Demo muestra trabajo real.** No slides de reporte. Output en su estado actual, con señal operativa visible. Si no hay trabajo demostrable, la Demo no ocurre esa quincena. 3. **La Retro de Ritmo evalúa el ritmo, no el trabajo.** ¿Los Morning Checks están funcionando? ¿El Daily Sostén se está haciendo? ¿Los pases de balón entran al CHANGELOG? ¿Hay dependencias crónicamente `críticas`? El output de la Retro son ajustes al ritmo, no acciones sobre los XDocs. Un equipo que cumple estos tres criterios tiene tres rituales al mes y cero reuniones de coordinación rutinaria. El tiempo que sobra es tiempo productivo real — no ahorro cosmético. ### 5.8 Las reglas inviolables del Nivel 2 Siete reglas cierran el contrato del Nivel 2: 1. El ritmo se organiza alrededor del XDoc, no del calendario. 2. Async-first: la coordinación rutinaria ocurre sobre el XDoc; la sincronía se reserva para juicio humano irreemplazable. 3. Cada rol tiene un ritmo canónico declarado. No existen roles con "ritmo a discreción". 4. El Morning Check se hace sobre vistas generadas por el Sistema, no sobre XDocs individuales. 5. Las vistas son derivadas. La fuente de verdad es siempre el XDoc; las vistas se pueden regenerar, los XDocs no. 6. Cada XDoc declara su cadencia: flujo continuo o pulso sincronizado. Un XDoc sin cadencia declarada es una falla estructural. 7. Los rituales mínimos del pulso sincronizado operan con pre-lectura del Sistema. Reuniones de coordinación rutinaria no entran al calendario WORX. Estas siete reglas operan siempre sobre las once del Nivel 1. Un ritmo WORX impecable sobre XDocs mal estructurados no es WORX — es teatro de cadencia. El orden de construcción y de lectura es el mismo: primero la forma del XDoc, después el ritmo que lo hace vivir. --- ## SECCIÓN 6 — ARQUITECTURA COGNITIVA ### 6.1 Por qué una arquitectura cognitiva Las Secciones 4 y 5 resuelven la forma y el ritmo del trabajo: cómo se estructura cada XDoc y cómo se usa a lo largo del tiempo. Lo que no resuelven es la infraestructura de pensamiento que hace ese trabajo posible. Un ecosistema WORX genera cantidades de contexto, decisiones, conocimiento y aprendizaje que exceden por órdenes de magnitud lo que un humano podría sostener por voluntad. La arquitectura cognitiva es la capa que organiza toda esa inteligencia — dónde vive, quién la produce, quién accede, qué filtra qué — para que el trabajo siga siendo humano mientras la memoria operativa se escala como sistema. Tres principios organizan esta arquitectura: 1. **El humano narra, el Sherpa estructura.** El punto de interacción por default no es el XDoc — es la conversación con el Sherpa personal, que traduce a estructura WORX y ejecuta con confirmación humana. 2. **La inteligencia tiene dos capas por naturaleza.** Lo privado del colaborador y lo compartido de la organización son sustancias distintas y no se mezclan sin un filtro explícito. 3. **El conocimiento se declara, no se infiere.** Los asesores conceptuales de un XDoc (los Brain Codes) se enuncian desde la cabecera; la autoridad cognitiva es legible, no difusa. El resultado combinado es un sistema donde el humano trabaja con menos fricción estructural, la organización mantiene memoria operativa completa, y la IA opera como par cognitivo declarado en vez de como capa invisible con acceso indefinido. ### 6.2 El Sherpa personal como interfaz El reflejo WORX que separa este modelo de un workflow con IA añadida es el cambio del punto de interacción. El humano deja de estar frente al XDoc la mayor parte del tiempo. Está frente a su Sherpa personal, y el Sherpa es quien está frente al XDoc. El flujo canónico tiene cinco pasos: ``` HUMANO narra lo que hizo / piensa / decide (libre, conversacional, sin estructura requerida) ↓ SHERPA PERSONAL traduce a estructura WORX · identifica el XDoc o los XDocs afectados · propone entradas de CHANGELOG con tag correcto · propone cierres de NEXT y NEXTs nuevos · propone update de ESTADO si hubo movimiento material · propone promoción de DISCUSSION si un hilo aterrizó ↓ HUMANO revisa el preview y confirma (o ajusta) ↓ SHERPA ejecuta las mutaciones en el vault ↓ SHERPA limpia el thread del chat (default) o lo preserva (si el humano lo indica) ``` Cuatro consecuencias estructurales de este flujo. **La fricción de la estructura se vuelve invisible para el 80% del uso.** El humano no tiene que recordar la forma del XDoc, los tags canónicos del CHANGELOG, el formato de NEXT, las reglas de promoción de DISCUSSION. El Sherpa se encarga. Lo que el humano practica es narrar con claridad lo que hizo o decidió. **Las reglas inviolables del XDoc no se relajan.** El Sherpa opera *sobre* las once reglas del Nivel 1 y las siete del Nivel 2. Si el humano narra algo que violaría una regla — cerrar un NEXT sin entrada de CHANGELOG, editar una entrada existente del CHANGELOG, firmar un `[DECIDE]` sin co-firma del Sponsor cuando el Owner es agéntico — el Sherpa no lo ejecuta. Propone la forma canónicamente correcta y pide confirmación. **El XDoc directo queda como interfaz secundaria.** Owners revisando su portafolio, auditorías formales, consultas puntuales de contexto — estos casos siguen ocurriendo sobre el XDoc en crudo. El Sherpa no los elimina; los relega a uso consciente y acotado. La interfaz primaria es conversacional; la del XDoc directo es documental. **El hábito se reformula.** El reto de adopción de sistemas estructurados siempre fue "aprender a estructurar". En WORX el hábito es "conversar con tu Sherpa". El cambio es cognitivamente más barato y más compatible con cómo opera un humano por default. ### 6.3 Personal Brain OS — el cerebro privado del colaborador Cada colaborador WORX opera con un **Personal Brain OS** — una capa cognitiva privada, del colaborador, que acompaña su uso del ecosistema. Por default es privada. Solo el colaborador y su Sherpa personal tienen acceso. Lo que vive en el Personal Brain OS: - Preferencias personales de comunicación y estilo de trabajo - Historial de productividad personal y patrones de foco - Relaciones con otros colaboradores (cómo trabajar con cada uno, contexto no declarado) - Notas privadas y borradores antes de confirmar al Sherpa - Aprendizajes personales que todavía no se promueven al vault - Chat Dashboard histórico del colaborador - Brain Codes personales (asesores declarados por el colaborador para su propio uso) El Personal Brain OS no es una carpeta escondida. Es una capa declarada cuya naturaleza es privada por diseño. El Sherpa personal tiene acceso completo; el Corp Brain OS no ve nada de esto salvo lo que el humano promueve explícitamente. Esta claridad es operativamente importante. Sin ella, el colaborador resiste (con razón) narrar con libertad a su Sherpa — teme que cualquier borrador o impresión termine en memoria organizacional. Con ella, el Sherpa se vuelve un espacio de pensamiento honesto, y el filtro hacia la organización queda bajo control consciente. ### 6.4 Corp Brain OS — el cerebro compartido de la organización El **Corp Brain OS** es la capa cognitiva compartida. Es la memoria operativa de la organización — lo que está legitimado, consultable por cualquier agente organizacional, y constituye el registro canónico del trabajo. Lo que vive en el Corp Brain OS: - Todos los XDocs del vault, con sus siete secciones completas - Decisiones `[DECIDE]` agregadas (con co-firma del Sponsor humano donde aplica) - Aprendizajes `[LEARN]` promovidos al LabPraxis - Brain Codes organizacionales - SOPs vigentes y el historial de drift declarado vs Protocolo - Patrones operativos agregados (behavioral context de la organización) - Salud agregada del ecosistema (dependencias críticas, XDocs sin cierre, cumplimiento de contratos — ver Sección 11) El Corp Brain OS no es "una base de conocimiento con IA encima". Es un sustrato declarado al que cada XDoc contribuye por construcción. El trabajo ocurre dentro de esta capa; la memoria se produce por el acto mismo de trabajar en WORX. ### 6.5 La regla de flujo y el Sherpa como filtro La separación entre Personal y Corp Brain OS se sostiene sobre una regla de flujo canónica: ``` HUMANO narra al Sherpa personal → Personal Brain OS (siempre, inmediato, por default) → Corp Brain OS (solo lo promovido al vault, después de confirmación explícita) ``` El Sherpa personal es el filtro. No hay otro. Nada entra al Corp Brain OS sin pasar por una confirmación humana. Tres consecuencias prácticas: 1. **Borradores y exploración son seguras.** Un colaborador puede narrar ideas a medio pensar, quejas, dudas, intentos fallidos, sin riesgo de que eso aparezca en el XDoc organizacional. Esa seguridad es lo que hace posible el uso real del Sherpa como espacio cognitivo. 2. **La promoción es un acto declarado.** Cuando un hilo del Personal Brain OS llega al punto de ser útil para el Corp Brain OS, el humano lo confirma y el Sherpa promueve. El acto es trazable; el colaborador sabe qué compartió y cuándo. 3. **La resistencia cultural se desactiva.** La adopción de cualquier sistema con IA organizacional se traba históricamente por miedo a vigilancia. Un flujo donde el humano ve, confirma y controla qué cruza al Corp Brain OS desactiva ese miedo por construcción, no por política. Esta regla se aplica también cuando el Owner de un XDoc es agente. El Owner agéntico produce en el Corp Brain OS por mandato operativo, pero cualquier decisión vinculante (`[DECIDE]`) queda en suspenso hasta la co-firma del Sponsor humano. El filtro en ese caso es el Sponsor, no el Sherpa personal del colaborador — pero la estructura es la misma: nada vinculante ocurre sin confirmación humana explícita. ### 6.6 Brain Codes — los asesores cognitivos declarados La inteligencia de un ecosistema WORX no es genérica. Cada XDoc se abre a dominios de conocimiento específicos, y esos dominios se declaran como **Brain Codes** — módulos cognitivos que el XDoc invoca cuando el trabajo lo requiere. **Qué es un Brain Code.** Un paquete cognitivo declarado con nombre, propósito y scope. Puede ser un marco de análisis (BC-DECISION-RIGHTS), una lente conceptual (BC-CORP-BRAIN-OS), un dominio operacional (BC-LEGAL-COMPLIANCE), o una fuente externa sintetizada (BCV-NATEJONES-AGENTIC). Los Brain Codes viven en el banco BC del Corp Brain OS y se versionan como cualquier otro asset. **Cómo se invocan.** Se declaran en la cabecera del XDoc (§4.3, línea "Brain Codes asesores: BC-..., BC-..."). La declaración es operativa: el Sherpa consulta esos Brain Codes cuando hay una pregunta conceptual sobre el XDoc. No busca conocimiento general; busca en los asesores declarados primero. Si la pregunta excede el scope de los BCs declarados, el Sherpa lo señala y propone extender la cabecera. **Dos niveles de alcance.** Los Brain Codes organizacionales viven en el Corp Brain OS y los puede declarar cualquier XDoc de la organización. Los Brain Codes personales viven en el Personal Brain OS de un colaborador y solo operan en su capa privada — por ejemplo, un BC-STYLE-PERSONAL con su voz de escritura, o un BC-RELATIONS-PERSONAL con cómo trabaja con cada par. **Por qué la declaración explícita importa.** Un sistema donde la IA "busca en todo lo que existe" produce respuestas promedio y decisiones no auditables — nadie sabe qué fuente pesó en qué conclusión. Un sistema donde cada XDoc declara sus asesores produce respuestas especializadas y auditables: la autoridad cognitiva es legible, la decisión se sostiene en fuentes nombradas, y la actualización de un Brain Code se propaga de forma trazable a los XDocs que lo invocan. ### 6.7 Decision Rights — quién decide qué Toda organización con agentes operando sobre decisiones reales necesita una regla clara sobre qué decisiones puede cerrar un agente y cuáles requieren juicio humano. La respuesta WORX no es un listado de tipos de decisión; es un marco de dos ejes. Los dos ejes son el **costo del error** (qué tan caro sería equivocarse) y la **reversibilidad** (qué tan fácil es corregir si se equivocó). | Costo del error | Reversibilidad | Decide | |-----------------|----------------|--------| | Alto | Irreversible | **Humano** — obligatorio, con contexto completo del agente | | Alto | Reversible | **Humano** — con contexto y propuesta estructurada del agente | | Bajo | Reversible | **Agente** — con log inmediato en CHANGELOG y override humano disponible | | Bajo | Irreversible | **Humano** — aunque el costo parezca bajo; la irreversibilidad pesa más de lo que parece | Tres notas operativas sobre cómo se aplica este marco. **La clasificación no vive en la cabeza del Runner.** Cada XDoc declara en su PROTOCOLO (§4.4.3) qué clases de decisión caen en qué cuadrante. La regla universal es abstracta; la aplicación concreta se fija por XDoc, para que nadie improvise en el momento. **Este marco es el que habilita el `[DECIDE]` con firma humana.** La regla 4 del Nivel 1 ("toda entrada `[DECIDE]` requiere firma humana") no es contradicción del cuadrante "Agente decide" — es su consecuencia. Cuando el agente cierra una decisión reversible de bajo costo, lo hace con entrada `[EXEC]` en el CHANGELOG; si el efecto llega a ser vinculante para la organización, se escala a `[DECIDE]` con firma humana. La frontera se fija en si la decisión produce compromiso vinculante, no en quién la cerró técnicamente. **El override humano es canónico.** Una decisión de un agente en el cuadrante "bajo × reversible" entra al CHANGELOG con tag `[EXEC]` y queda disponible para override del Owner humano o Sponsor. El override no es excepción; es parte del contrato. Su existencia es lo que hace segura la delegación. ### 6.8 La trilogía del trabajador WORX Tres prácticas cognitivas personales sostienen el uso del sistema. Se detallan en la Sección 8 (Capacidades Personales); aquí quedan enunciadas porque son parte de la arquitectura cognitiva misma. - **Deep Work como modo por default.** El trabajo profundo es el modo principal del colaborador WORX. La coordinación se comprime a las ventanas del Morning Check, el Daily Sostén y el Close Loop; el resto del día es trabajo con foco. - **Human + SherpaX como par cognitivo.** El humano no opera solo frente al vault. Opera con su Sherpa personal como contraparte: el humano aporta juicio, dirección estratégica y relaciones; el Sherpa aporta ejecución estructurada, síntesis, memoria y acceso al vault. Juntos superan a cualquiera de los dos por separado. - **Vault-First como reflejo.** Antes de producir sobre cualquier XDoc existente, se consulta el vault (§4.7). No es recomendación; es ritual. Convierte al vault en el único punto de partida legítimo para cualquier continuación de trabajo. Estas tres prácticas no son opcionales en un equipo WORX. Son el contrato individual implícito de cada colaborador con la arquitectura cognitiva del sistema. ### 6.9 Las reglas inviolables del Nivel Cognitivo Ocho reglas cierran el contrato de la arquitectura cognitiva: 1. La interfaz primaria de trabajo es el Sherpa personal, no el XDoc directo. 2. El Sherpa propone; el humano confirma; nada vinculante ocurre sin confirmación humana explícita. 3. Personal Brain OS y Corp Brain OS son capas separadas por diseño. Ningún contenido del Personal Brain OS cruza al Corp Brain OS sin promoción confirmada. 4. Los Brain Codes asesores de un XDoc se declaran en la cabecera. El Sherpa consulta primero los declarados. 5. Decision rights se fijan por XDoc en PROTOCOLO, usando el marco canónico (costo × reversibilidad). 6. El override humano sobre decisiones agénticas es parte del contrato, no excepción. 7. Brain Codes se versionan; una actualización se propaga de forma trazable a los XDocs que los invocan. 8. Deep Work, Human+SherpaX y Vault-First son las tres prácticas personales no opcionales del trabajador WORX. Estas ocho reglas operan siempre sobre las once del Nivel 1 y las siete del Nivel 2. Un Sherpa impecable que opere sobre XDocs mal estructurados o ritmos rotos termina amplificando el desorden — la arquitectura cognitiva hace legible y escalable lo que las dos capas anteriores hicieron correcto. --- ## SECCIÓN 7 — LOS 5 CONTRATOS ### 7.1 Por qué hace falta un código civil Las Secciones 4, 5 y 6 dejan el sistema operable: forma del XDoc, ritmo de uso, arquitectura cognitiva. Lo que aún no está resuelto es lo que vuelve al sistema *exigible* — qué le toca a cada quién, qué está autorizado a hacer cada rol, y qué incumplimientos rompen el contrato del modelo. Los contratos WORX son ese código civil. Son cortos a propósito. Viven visibles en el vault. Cada colaborador, Runner, Owner, Sponsor o agente que entra al ecosistema acepta el contrato de su rol como condición de operación. Sin esa aceptación el sistema sigue funcionando como apariencia, pero sin filo: nadie puede sostener una expectativa concreta de nadie. Cinco contratos cierran el modelo. Cuatro corresponden a roles humanos o agénticos que operan sobre los XDocs (Colaborador, Runner, Owner, Sponsor). El quinto es transversal: el Contrato Humano-IA, que rige la relación entre cualquier humano del sistema y cualquier agente (Sherpa personal, SherpaX organizacional, agentes especializados). ### 7.2 Las propiedades comunes de los contratos Los cinco contratos comparten cuatro propiedades estructurales. **Cada uno cabe en cinco a siete puntos.** No son políticas extensas; son listas chicas y exigibles. Si un contrato necesita una página entera para enunciarse, ya está mal redactado. **Son visibles en el vault.** Los contratos viven como documento canónico, no como cultura oral. Un Runner nuevo no necesita preguntar qué se espera de él — abre el contrato y lo lee. **Su cumplimiento es medible.** La Sección 11 (Métricas y Salud del Sistema) define cómo se observa el cumplimiento de cada contrato a nivel agregado. Un contrato no observable no es contrato; es aspiración. **Aplican igual a humanos y a agentes.** Cuando un agente cumple un rol — un SherpaX como Owner, un agente especializado como Runner de un track técnico — acepta el mismo contrato que un humano en ese rol, con el cierre del Contrato Humano-IA encima. ### 7.3 Contrato del Colaborador Aplica a cualquier persona o agente con NEXTs asignados en uno o más XDocs. Es el contrato más universal del modelo. 1. **Morning Check antes de empezar a trabajar.** El Tablero Personal y el Chat Dashboard se revisan al inicio del día. Sin Morning Check no hay forma de saber qué es prioridad real hoy. 2. **Cerrar cada NEXT asignado con entrada en CHANGELOG.** Sin excepciones. Un NEXT que se ejecuta sin entrada de CHANGELOG no se cerró — quedó como intención completada en silencio. 3. **No tomar decisiones vinculantes en DISCUSSION sin promoverlas a `[DECIDE]`.** DISCUSSION es para pensar en voz alta. Si la conversación produjo una decisión, se promueve al CHANGELOG. Nunca se deja "decidida" en el hilo. 4. **Declarar bloqueos antes del deadline, no después.** Cuando una dependencia o un imprevisto va a bloquear un NEXT, el Colaborador lo declara cuando lo ve venir, no cuando ya pasó. Anticipar es parte del contrato. 5. **Escribir estructurado, no prosa libre — o dejar que el Sherpa lo haga.** El Colaborador no necesita dominar la sintaxis canónica. Necesita producir contenido auditable, sea redactándolo él o narrándolo al Sherpa para que traduzca. ### 7.4 Contrato del Runner Aplica a quien tiene el balón activo en un XDoc. Hereda todo el contrato del Colaborador y agrega cinco puntos. 1. **Sostener el ESTADO del XDoc al menos semanalmente.** El ESTADO desactualizado es ruido sistémico para toda la organización. La Weekly Review existe precisamente para que el Runner cumpla este punto. 2. **Promover lo aterrizado de DISCUSSION a NEXT o CHANGELOG.** Cuando un hilo aterriza, el Runner es responsable de la promoción. Una DISCUSSION que crece sin aterrizajes es señal de Runner ausente. 3. **Pasar el balón formalmente, con razón y handoff declarados.** El pase entre Runners no es cambio silencioso de etiqueta. Es entrada al CHANGELOG con tag `[RUNNER]`, razón del pase, y contexto entregado al siguiente Runner para que no parta desde cero. 4. **Escalar bloqueos críticos al Owner / Sponsor.** Cuando una dependencia pasa a estado `crítica` (cruzó deadline) o cuando un bloqueo persiste más allá de 48 horas, el Runner escala. No se queda esperando que se resuelva por sí solo. 5. **Ser contacto primario de los Colaboradores que entran al XDoc en su ventana.** El Runner es la cara humana operativa del XDoc para quien aterriza. Si entra alguien nuevo a contribuir esta semana, su primer punto de contacto es el Runner, no el Owner. ### 7.5 Contrato del Owner Aplica al responsable operativo del XDoc. Recordar: el Owner puede ser **humano o agente** (§4.3). El contrato es uno solo, con dos cláusulas adicionales cuando el Owner es agéntico. **Núcleo del contrato (igual para humano y agente):** 1. **Revisar el portafolio al menos semanalmente vía Dashboard.** La Weekly Portfolio Review es el momento canónico. Sin ella el Owner pierde el latido del portafolio. 2. **Actuar por excepción.** El Owner no microgestiona. Confía en los Runners y en el Sistema; interviene donde la salud lo amerita (XDocs en 🟡 o 🔴, dependencias críticas, drift acumulado, NEXTs vencidos). 3. **Confirmar o corregir las propuestas de ESTADO y `[DECIDE]` que el Sherpa eleva.** Si el Sistema propone marcar una dependencia como satisfecha, promover una DISCUSSION o cerrar un hito, el Owner confirma o corrige. El Sistema nunca avanza solo. 4. **Decidir cierres y archivados de XDocs del portafolio.** El CIERRE del XDoc es decisión del Owner. Una organización que produce sin cerrar acumula XDocs abiertos sin aprendizaje extraído (señal estructural a revisar). 5. **Validar o rechazar las desviaciones de Protocolo declaradas en los XDocs del portafolio.** Cuando un Runner declara drift en PROTOCOLO (§4.4.3), el Owner decide: actualiza el SOP, revierte la desviación, o escala al ciclo de gobernanza emergente. **Cláusulas adicionales cuando el Owner es agente:** 6. **Escalar todo `[DECIDE]` al Sponsor humano para co-firma.** El Owner agéntico nunca firma una decisión vinculante en solitario. La co-firma del Sponsor es condición de validez de la entrada de CHANGELOG. 7. **Operar dentro del scope declarado en el PROTOCOLO del XDoc.** Un Owner agéntico tiene autonomía acotada por el cuadrante de Decision Rights aplicable (§6.7). Decisiones fuera de "bajo costo × reversible" se escalan automáticamente al Sponsor antes de ejecutar. ### 7.6 Contrato del Sponsor Aplica al respaldo humano del XDoc. **Siempre es humano.** Cuando el Owner es humano, típicamente Sponsor y Owner son la misma persona y este contrato se consolida en el del Owner. Cuando el Owner es agente, el Sponsor opera como ancla decisional independiente, y este contrato es el que cierra el Contrato Humano-IA en el momento donde una decisión se vuelve vinculante para la organización. 1. **Co-firmar toda entrada `[DECIDE]` cuando el Owner del XDoc es agente.** La co-firma es explícita en la entrada del CHANGELOG, con timestamp y evidencia. Sin co-firma, el `[DECIDE]` no entra al CHANGELOG. 2. **Co-firmar el CIERRE del XDoc cuando el Owner es agente.** El archivado es decisión vinculante. La co-firma del Sponsor cierra el ciclo del XDoc bajo autoridad humana. 3. **Revisar las propuestas escaladas por el Owner agéntico dentro de su ventana acordada.** El Sponsor no necesita estar dentro del XDoc todos los días; necesita responder a las escalaciones del Owner agéntico con rapidez razonable acordada por XDoc. 4. **Mantener la legitimidad organizacional del XDoc.** Si el Owner agéntico se desvía de su mandato declarado, el Sponsor interviene: re-acota el scope, retira la propiedad agéntica, o reasigna el XDoc a un Owner humano. 5. **Reportar al Owner de Gobernanza cualquier patrón sostenido de fricción Owner-agente / Sponsor-humano.** El sistema aprende de estos patrones; capturarlos es parte del contrato del Sponsor. ### 7.7 Contrato Humano-IA Es el contrato transversal del modelo. Aplica a toda interacción entre cualquier humano del sistema y cualquier agente (Sherpa personal, SherpaX organizacional, agentes especializados, BCs operacionales, Owner agéntico). Tiene dos lados. **El lado del agente.** Cinco compromisos no negociables: 1. **Propone, nunca cierra.** El agente puede generar entradas, sugerir cierres, marcar dependencias, promover hilos. Nunca ejecuta una mutación vinculante sin confirmación humana explícita. 2. **Genera vistas, nunca mantiene bases separadas.** Tableros, dashboards, resúmenes son siempre derivados del vault. El agente no construye memoria propia paralela al Corp Brain OS. 3. **Alerta sin interrumpir.** Las señales del agente (dependencias críticas, NEXTs vencidos, drift detectado) entran al Tablero o Chat Dashboard del rol pertinente. No interrumpen el Deep Work del humano. 4. **Usa Brain Codes declarados.** Cuando hay consulta conceptual sobre un XDoc, el agente consulta primero los BCs declarados en la cabecera. Si la pregunta excede el scope, lo señala antes de improvisar. 5. **Audita drift sin corregirlo unilateralmente.** Si el agente detecta desviación operativa (Protocolo vs SOP, dependencia mal clasificada, NEXT cerrado sin CHANGELOG), levanta la señal al Owner. No corrige por su cuenta. **El lado del humano.** Cinco compromisos correlativos: 1. **Confirma o rechaza explícitamente.** No se acepta por silencio. Si el humano no responde a una propuesta del agente dentro de la ventana acordada, la propuesta queda como pendiente trazable, no como ejecutada por default. 2. **No le pide al agente decisiones vinculantes que requieran juicio humano.** El humano respeta el cuadrante de Decision Rights. Pedirle a un agente que cierre un `[DECIDE]` por uno mismo es romper el contrato desde el lado humano. 3. **Invoca BCs explícitamente cuando los necesita.** Si la consulta requiere un dominio especializado, el humano lo nombra. No espera que el agente adivine la lente correcta. 4. **Reporta errores y sesgos del agente al Owner de Gobernanza.** Cuando el agente falla — propone mal, audita mal, ignora un BC — el humano lo reporta al canal canónico, no se lo guarda. Esa retroalimentación es lo que evoluciona el sistema. 5. **Mantiene su Personal Brain OS bajo su control.** Lo que cruza al Corp Brain OS pasa por confirmación. El humano no delega ese filtro. Estos diez puntos juntos son lo que hace habitable la cohabitación humano-agente en el ecosistema. La asimetría operativa (el agente puede mucho, el humano confirma) se sostiene precisamente porque las dos partes saben qué le toca a cada quién. ### 7.8 Cumplimiento y resguardo de los contratos Los contratos no se sostienen solos. Tres mecanismos los hacen exigibles en operación. **Visibilidad permanente.** Los cinco contratos viven como XDocs canónicos del Corp Brain OS, accesibles a cualquier colaborador o agente. Cuando alguien entra a un rol, el primer paso es leer su contrato. **Observabilidad agregada.** El Sistema mide el cumplimiento de los contratos a nivel portafolio (Sección 11). NEXTs cerrados sin CHANGELOG, ESTADOs sin actualizar, pases de balón silenciosos, `[DECIDE]` sin co-firma cuando aplica — todos son señales rastreables. **Ciclo de gobernanza emergente.** Cuando un patrón de incumplimiento aparece de forma repetida, no es problema personal del Runner o del Owner — es señal de que el contrato necesita revisión. El patrón se documenta en el LabPraxis (CASO operativo), se promueve a Principio si aplica, y eventualmente se incorpora al SOP o al contrato mismo. Los contratos evolucionan por aprendizaje, no por decreto unilateral. ### 7.9 Las reglas inviolables del Nivel Contractual Seis reglas cierran el código civil de WORX: 1. Cada rol del modelo tiene un contrato declarado y visible en el vault. 2. Los contratos caben en cinco a siete puntos. Brevedad es exigibilidad. 3. Aceptar el rol implica aceptar el contrato. No hay rol "de facto" sin contrato firmado. 4. Cuando el rol lo cumple un agente, aplica el mismo contrato más el Contrato Humano-IA. 5. El cumplimiento es observable a nivel agregado. Los contratos son medibles, no aspiracionales. 6. Los contratos evolucionan vía gobernanza emergente (CASO → LabPraxis → Principio → SOP), no por decreto unilateral. Estas seis reglas operan sobre las once del Nivel 1, las siete del Nivel 2 y las ocho del Nivel Cognitivo. El total — 32 reglas inviolables — es el piso completo del modelo WORX. Todo lo demás (la Sección 8 de capacidades personales, las Secciones 9 a 11 de plataforma y métricas) descansa sobre este piso. --- ## SECCIÓN 8 — CAPACIDADES PERSONALES DEL TRABAJADOR WORX ### 8.1 Por qué hace falta una capa ortogonal Las Secciones 4 a 7 resuelven el sistema. El XDoc le da forma al trabajo; el Ritmo lo mueve; la Arquitectura Cognitiva lo sostiene; los Contratos lo vuelven exigible. Con eso, una organización WORX tiene estructura, cadencia, memoria y accountability. Lo que aún no está resuelto es la pregunta más básica: ¿qué necesita tener internalizado un ser humano para operar dentro de este modelo sin colapsar? Porque el sistema puede estar perfectamente especificado, y los contratos perfectamente firmados, y aun así — si el trabajador no tiene ciertas capacidades personales internalizadas como reflejo — el modelo produce fricción crónica. No por defecto del diseño: por ausencia del substrato personal que lo hace habitable. Esa es la razón por la que la Capa Personal es **ortogonal** a los tres niveles, no un cuarto nivel. No describe una capa más del sistema — describe qué trae consigo cada trabajador a los tres niveles existentes. Sin Deep Work, el Ritmo se rompe. Sin Vault-First, el XDoc se convierte en archivo muerto. Sin alianza con el Sherpa personal, la Arquitectura Cognitiva queda en aspiración. La capa es el piso individual sobre el que se para el modelo colectivo. ### 8.2 El trabajador WORX — definición operativa Un trabajador WORX no se define por su puesto, su industria o su antigüedad. Se define por cinco capacidades internalizadas que le permiten operar en el modelo con baja fricción. Estas capacidades no son innatas. Son aprendidas — cultivadas deliberadamente por el individuo, y reforzadas por la organización mediante soporte sistémico (Sherpa personal que educa, LabPraxis que documenta, contratos que las hacen exigibles). Un trabajador maduro en WORX no necesita esfuerzo consciente para ejecutarlas: las opera como reflejo. Las cinco capacidades son transversales. Cada una habilita funcionamiento en los tres niveles del modelo simultáneamente. Cuando una capacidad falta, la falla se manifiesta en niveles distintos a la vez: se rompe el ritmo, se degrada el XDoc, se enreda la cognición. Por eso esta capa no puede tratarse como accesoria — es la condición habilitante del resto. ### 8.3 Capacidad 1 — Deep Work como modo por defecto La primera capacidad es invertir la ecuación del knowledge worker contemporáneo. En el modelo pre-WORX, el 60% del tiempo se gasta en coordinación reactiva y 40% en trabajo estratégico. WORX exige la inversión: 60% Deep Work, 40% coordinación comprimida y protocolizada. Deep Work aquí no es una moda productiva. Es la condición material para producir el tipo de salida que el XDoc requiere: pensamiento estructurado, síntesis densa, decisiones argumentadas. Un XDoc construido entre interrupciones refleja la interrupción — es ruidoso, contradictorio, frágil. Internalizar Deep Work como modo por defecto significa tres cosas en la práctica: bloques largos de atención continua protegidos del calendario reactivo; modo async como respuesta primera a cualquier mensaje entrante (la respuesta síncrona es excepción, no norma); y un umbral alto para que una interrupción justifique romper un bloque en curso. La capacidad se desarrolla por repetición deliberada, no por voluntarismo aislado. Habilitación cruzada: Deep Work hace posible la calidad del XDoc (Nivel 1), sostiene el Ritmo protegido del colaborador (Nivel 2), y es lo que libera al humano de la coordinación mecánica que el Sistema absorbe (Nivel 3). ### 8.4 Capacidad 2 — La alianza Human + SherpaX La segunda capacidad es operar en par cognitivo con el Sherpa personal. El trabajador WORX no trabaja solo. Su Sherpa es el interlocutor permanente: procesa conversación, traduce a estructura, consulta el vault, alerta sobre dependencias, mantiene memoria local. La distribución de trabajo en la alianza tiene una forma canónica. El humano aporta juicio, dirección estratégica, relaciones, decisiones vinculantes. El Sherpa aporta ejecución de la estructura, síntesis de volumen, memoria organizada, vigilancia de protocolo. La regla de oro es la misma del Contrato Humano-IA: el Sherpa propone; el humano confirma. Internalizar esta capacidad significa dejar de verse como ejecutor individual y empezar a verse como dirigente de un par. El humano que insiste en escribir toda su estructura a mano, resistir la propuesta del Sherpa, o ignorar su alerta, no está siendo diligente: está operando como si el Sherpa no existiera, y desperdiciando la palanca que define el modelo. La capacidad se adquiere por uso — conversando con el Sherpa todos los días hasta que la traducción narrativa-a-estructura se siente natural. Habilitación cruzada: la alianza es lo que hace operable la Sección 4 sin que el humano cargue con la sintaxis canónica (el Sherpa la mantiene por él), es el motor del modo conversacional de la Sección 6, y es el vínculo operativo del Contrato Humano-IA en la Sección 7. ### 8.5 Capacidad 3 — Vault-First como reflejo La tercera capacidad es consultar antes de producir. Siempre. Cuando el trabajador va a aportar a un XDoc existente, a responder una pregunta sobre un proyecto, a retomar una conversación o a escribir una propuesta sobre un tema trabajado, el primer movimiento no es abrir un editor en blanco — es consultar el vault. Vault-First no es política administrativa. Es reflejo. La diferencia operativa entre "política" y "reflejo" es que la política se cumple bajo presión y se rompe bajo estrés; el reflejo se cumple bajo estrés porque el cuerpo ya no considera la alternativa. Un trabajador WORX maduro no se pregunta si debería consultar el vault. Lo consulta. El protocolo de cuatro pasos (§4.6) hace operable el reflejo: buscar el XDoc o Transfer Pack pertinente, leer lo que ya está resuelto, identificar el punto real de entrada, producir desde ahí. Cuatro pasos que con práctica ocupan minutos y ahorran horas de trabajo duplicado o desalineado. Habilitación cruzada: Vault-First es lo que convierte al XDoc en una memoria operable y no un cementerio documental (Nivel 1), es lo que sincroniza al trabajador con el Ritmo del equipo sin necesidad de reunión (Nivel 2), y es lo que hace legible el Corp Brain OS cuando lo consulta (Nivel 3). ### 8.6 Capacidad 4 — Ritmo personal diseñado La cuarta capacidad es diseñar el propio ritmo en lugar de sufrirlo. El ritmo personal no emerge solo — emerge como reacción al calendario ajeno, a las notificaciones entrantes, a las urgencias de terceros. Ese ritmo emergente es incompatible con WORX porque choca con todo el diseño del Nivel 2. Diseñar el ritmo personal significa construirlo con cuatro componentes declarados. Primero, bloques de Deep Work protegidos — ventanas fijas del día donde no hay reuniones, no se responden mensajes, no se abre el chat. Segundo, ventanas de coordinación acotadas — momentos explícitos para responder, conversar y coordinar, lo que absorbe todo el ruido entrante en un espacio delimitado. Tercero, un Morning Check ritualizado — el arranque del día pasa por el Tablero Personal y el Chat Dashboard antes de abrir cualquier otra cosa. Cuarto, un cierre de día con transferencia de contexto — el trabajo que queda abierto se deja dejado, no tirado, con una nota al Sherpa para que lo continúe o lo retome sin re-empezar. Internalizar esta capacidad es rechazar la idea de que el ritmo del trabajador lo imponen los demás. Lo impone el trabajador, y se negocia con el equipo a través de los ritmos del Nivel 2. Los cuatro ritmos canónicos (Colaborador, Runner, Owner/Sponsor, Sistema) existen precisamente para que el ritmo personal se sincronice con el colectivo sin someterse a él. Habilitación cruzada: el ritmo diseñado es lo que hace que los ritmos de equipo del Nivel 2 operen en la práctica. Sin esta capacidad, la semana WORX se convierte en aspiración del calendario y realidad en caos. ### 8.7 Capacidad 5 — Curaduría del Personal Brain OS La quinta capacidad es curar activamente el Personal Brain OS. El trabajador WORX opera con dos memorias (§6.6): una organizacional (Corp Brain OS, el vault) y una personal (Personal Brain OS, sus notas privadas, sus conversaciones con el Sherpa, su trabajo en progreso). La relación entre ambas no es automática — es mediada por el humano. El Sherpa personal procesa conversación, toma notas, organiza pensamiento, mantiene el trabajo en curso. Pero nada cruza al Corp Brain OS sin confirmación del humano. Esa confirmación es la capacidad: el trabajador decide qué elevar (aportar al XDoc, promover a decisión, archivar en el IntelliBank correspondiente) y qué mantener local (borradores, especulación, material en proceso, contenido privado). Internalizar esta capacidad significa entender que la salud del Corp Brain OS depende del filtro individual. Si cada trabajador deja que todo su Personal Brain OS se derrame al colectivo, el vault se convierte en ruido. Si nadie eleva nada, el vault se convierte en archivo frío. La curaduría es el juicio continuo sobre qué pasa de privado a público y cuándo. Habilitación cruzada: la curaduría es la contraparte operativa del Contrato Humano-IA desde el lado humano (Sección 7.7, punto 5), protege al Corp Brain OS de la degradación por volumen (Nivel 3), y permite al Sherpa personal operar con libertad en el espacio local sin contaminar el colectivo. ### 8.8 Cómo se desarrollan las cinco capacidades Ninguna de las cinco es innata. Ninguna aparece por decreto. Las cinco se cultivan, y la organización WORX hace del cultivo un proceso sistémico, no una responsabilidad individual aislada. El cultivo opera en dos frentes. Del lado del individuo, la práctica deliberada: calendarizar los bloques de Deep Work hasta que dejan de requerir voluntad, usar el Sherpa personal todos los días hasta que la conversación se vuelve reflejo, ejecutar el protocolo Vault-First como checklist mental hasta que se automatiza, revisar el ritmo personal cada semana hasta que se estabiliza, y mantener el hábito de curar el Personal Brain OS al cierre del día. Seis a doce meses de práctica hacen la diferencia entre un trabajador que ejecuta el modelo y un trabajador que vive el modelo. Del lado de la organización, el soporte sistémico: el SherpaX organizacional observa patrones individuales y ofrece retroalimentación (el Owner de un XDoc que rompe ritmo, el Colaborador que salta Vault-First, el Runner que no cierra día). El LabPraxis (Sección 10) documenta patrones de fricción en CASOs; los patrones recurrentes se promueven a Principios y se incorporan al onboarding. Las cinco capacidades se enseñan explícitamente en los primeros treinta días de incorporación — antes que el dominio del negocio específico. El supuesto estructural es que aprender a trabajar en WORX es prerrequisito de aprender a trabajar en el área funcional. Una organización WORX enseña el método antes del contenido. ### 8.9 Implicación cultural — filtro de incorporación La capa personal cambia la forma en que la organización contrata y onboardea. No contrata por skills técnicos declarados en un CV; contrata por evidencia — o capacidad demostrable — de internalizar las cinco capacidades. Alguien con skills funcionales excelentes que es incapaz de sostener Deep Work, resiste operar con Sherpa, desprecia el Vault-First, vive del calendario ajeno o se niega a curar su Personal Brain OS, introduce fricción estructural al sistema que ningún contrato compensa. La consecuencia práctica es que el onboarding WORX es distinto. Los primeros treinta días no son curso de producto o inmersión en el dominio — son formación de capa personal. Los ritmos del Nivel 2 se practican con un caso sencillo; el XDoc canónico se llena con el acompañamiento del Sherpa personal; el Vault-First se ejercita con recorridos guiados del Corp Brain OS. Recién al mes dos empieza el dominio funcional específico. Esta inversión del orden tradicional (forma antes que fondo) es el rasgo cultural que distingue organizaciones WORX maduras de organizaciones que "adoptaron IA encima del proceso viejo". La adopción superficial deja las cinco capacidades como aspiración; la adopción madura las trata como currículum. ### 8.10 Las reglas inviolables de la Capa Personal Cinco reglas cierran la capa ortogonal: 1. Deep Work es el modo por defecto del trabajador WORX, no la excepción reservada para momentos tranquilos. 2. El humano opera en par cognitivo con su Sherpa personal. Trabajar como ejecutor solitario rompe el modelo por el lado individual. 3. Vault-First es reflejo, no política. Consultar antes de producir se ejecuta sin esfuerzo consciente. 4. El ritmo personal se diseña explícitamente con bloques de Deep Work, ventanas de coordinación, Morning Check y cierre de día. Sin diseño, el Nivel 2 colapsa en aspiración. 5. El Personal Brain OS está bajo control curatorial del humano. Ningún contenido local cruza al Corp Brain OS por default; cruza por decisión. Estas cinco reglas se suman a las 32 de los niveles base (11 del XDoc + 7 del Ritmo + 8 de la Arquitectura Cognitiva + 6 de los Contratos). Las **37 reglas inviolables totales** son el piso completo del modelo WORX. De las Secciones 9 a 11 en adelante, todo lo que se construya (plataforma emergente, guía de implementación, métricas) descansa sobre este piso. --- # PARTE 3 — PLATAFORMA Y ADOPCIÓN ## SECCIÓN 9 — NIVEL 3: LA PLATAFORMA EMERGENTE ### 9.1 Qué es el Nivel 3 El Nivel 3 es la **plataforma emergente**: el conjunto de vistas, transformaciones, agentes y coordinaciones que SherpaX genera y sostiene **derivándolos del vault**. No se diseña como producto terminado — emerge como consecuencia de los Niveles 1 y 2 operando correctamente. El principio es arquitectónico: la plataforma no es una capa adicional que se superpone al trabajo; es la **proyección** del trabajo ya estructurado (Nivel 1) sobre los ritmos que lo consumen (Nivel 2). Si los dos niveles base están bien puestos, el tercero no se diseña — aparece. Si los dos niveles base están rotos, ningún diseño de plataforma los compensa. ### 9.2 El principio de derivación (no de diseño) Una organización WORX no construye su plataforma; la **deriva**. Cada vista que aparece en la plataforma responde a una pregunta que alguien con un rol (colaborador, runner, owner, sponsor) hace en un ritmo específico (morning check, cierre de día, shadow meeting). Si la pregunta no existe, la vista no existe. Este principio invierte la lógica tradicional del software empresarial. Allí, se construyen features en espera de uso; aquí, se generan vistas bajo demanda estructural. El costo de mantenimiento se desplaza de "mantener la plataforma sincronizada con la realidad" a "mantener el vault canónico y dejar que la plataforma se regenere". Para la organización, la consecuencia práctica es que la plataforma WORX **envejece bien**. Un CRM tradicional envejece porque el proceso cambia y la herramienta queda atrás. En WORX, si el proceso cambia, el vault cambia primero (nuevos XDocs, nuevas dependencias, nuevos ritmos) y la plataforma se rederiva. No hay deuda de UI acumulada porque no hay UI construida por separado. ### 9.3 Catálogo de vistas canónicas Cuatro clases de vistas cubren la mayoría de los usos operativos de una organización WORX madura. **9.3.1 Vistas personales (por humano):** - **Tablero Personal** — qué NEXTs me tocan hoy, con qué prioridad, contra qué dependencias. - **Chat Dashboard** — conversaciones clave de múltiples XDocs agregadas por urgencia × importancia (tercera vista del Morning Check, §5). - **Radar de Dependencias** — qué espera de mí, qué espero de otros, con qué umbral de criticidad. - **Vista de Foco (Deep Work)** — el XDoc activo con contexto mínimo, sin notificaciones cruzadas. **9.3.2 Vistas por XDoc:** - **Vista canónica** — las 7 secciones en orden fijo; la superficie principal de trabajo. - **Vista de Progreso** — NEXT + Dependencias + Changelog filtrado por tag. - **Vista de Síntesis** — CONTEXTO + CIERRE (para quien llega por primera vez o para auditoría rápida). - **Vista de Decisión** — [DECIDE] abiertas + Dependencias críticas + Sponsor/Owner responsables. **9.3.3 Vistas agregadas:** - **Dashboard de Portafolio** — salud agregada de múltiples XDocs agrupados por Owner, Sponsor o Proyecto. - **Mapa de Dependencias Cross-Doc** — resolución visible de dependencias tipo `[DOC]` (§4.4.2.1). - **Radar de Decisiones** — [DECIDE] abiertas en todo el portafolio esperando co-firma, ordenadas por reversibilidad × costo. - **Radar de Drift** — discrepancias detectadas entre PROTOCOLO declarado y ejecución observada en Changelog. **9.3.4 Vistas por rol:** - **Vista del Runner** — tracks activos donde llevo el balón, próximos pases de balón, bloqueos por dependencia. - **Vista del Owner** — XDocs bajo mi autoridad, [DECIDE] pendientes, NEXT abiertos del portafolio. - **Vista del Sponsor** — [DECIDE] críticas esperando mi co-firma, XDocs con Owner agéntico bajo mi respaldo. - **Vista del Sistema / SherpaX** — salud agregada, XDocs huérfanos, drift de SOPs, dependencias críticas sin movimiento. Este catálogo es **canónico no exhaustivo**: nombra las vistas que toda organización WORX necesita. Cada organización derivará adicionalmente las vistas específicas de su ADN en el MePB. ### 9.4 Topología Meta-Agent / Task-Agents La plataforma no es un único agente monolítico; es una topología de **un Meta-Agent orquestador sobre task-agents especializados**. En una organización WORX operativa, el Meta-Agent canónico del Corp Brain OS es **SherpaX**; los task-agents son los nueve especializados descritos a continuación. > **Nota arquitectónica — la familia "Meta-" del BMF:** esta topología no es local de WORX ni importada tal cual del léxico Nate/Karpathy. Es una instancia de la familia **Meta-** pre-existente en el Big MetaFactory (MPB, MePB, MePB-OF-MePB, MetaFactory). El patrón es constante: una capa de abstracción gobierna instancias concretas. Un **Meta-Agent (MeAg-)** se registra como asset formal del BMF bajo la constitución `MePB-OF-MeAg-v01`, del mismo modo que un MetaPlaybook se registra bajo `MePB-OF-MePB`. > > **Dualidad MePB ↔ MeAg:** el MePB es el *programa* (patrones de trabajo instanciados a una organización); el MeAg es el *procesador* (agente que orquesta task-agents para ejecutar esos patrones). Una HIOrg madura tiene ambos. `MePB-EL-WORX-EmpowerLabs` describe cómo se trabaja en EmpowerLabs; `MeAg-EL-SherpaX-v01` orquesta los agentes que hacen ese trabajo. El mismo principio que separa Sherpa personal (filtro, confirmación, contexto individual) de SherpaX corporativo (ejecución sobre el Corp Brain OS) se aplica acá: especialización por dominio cognitivo, no por capacidad técnica. En términos BMF, cada Sherpa es un MeAg- con scope distinto — lo que cambia es la declaración de scope y los task-agents subordinados, no la naturaleza del asset. Tres familias de task-agents bajo SherpaX: **9.4.1 Task-agents de coordinación:** - **Agente de Ritmo** — arma y mantiene Morning Checks, cierres de día, shadow meetings. Conoce los 4 ritmos por rol (§5). - **Agente de Dependencias** — detecta dependencias rotas, propone escalamiento a crítica, notifica a Owner dependiente cuando el upstream cierra. - **Agente de Decisión** — tracking de [DECIDE] abiertas, recordatorio a Sponsor/Owner según umbral de tiempo del PROTOCOLO. **9.4.2 Task-agents de síntesis:** - **Agente de Promoción** — detecta cuándo una Discussion ha madurado a decisión y propone su promoción a Changelog. Siempre con confirmación humana (§4.8.11). - **Agente de Síntesis de Portafolio** — arma resúmenes agregados para Owner/Sponsor que cruzan múltiples XDocs del mismo proyecto o programa. - **Agente de Curaduría del Brain OS** — identifica material del Personal Brain OS promovible al Corp Brain OS. Nunca promueve sin consentimiento humano (§6). **9.4.3 Task-agents de ejecución:** - **Agente de Ingest** — procesa input no estructurado (conversación, nota, email, transcript) y propone su conversión a XDoc o a sección canónica de un XDoc existente. - **Agente de Publicación** — genera bajo demanda las vistas del catálogo §9.3. - **Agente de Auditoría** — ejecuta rutinas de salud del sistema (ver §11): XDocs huérfanos, dependencias sin movimiento, drift de SOPs. **Regla común a los nueve task-agents:** ningún task-agent ejecuta sobre el vault sin confirmación humana. Todos operan en modo *propuesta → confirmación → ejecución*, tal como lo define el Contrato Humano-IA (§7.5) y las invariantes del MeAg (INV-MeAg-02 en `MePB-OF-MeAg-v01`). La especialización introduce eficiencia; no introduce autonomía decisional. Esta regla aplica tanto al Meta-Agent (SherpaX) como a cada task-agent subordinado. ### 9.5 Resolución de dependencias cross-doc Las dependencias tipo `[DOC]` (§4.4.2.1) son la espina dorsal de la plataforma. Cuando un XDoc declara en ESTADO una dependencia `[DOC] espera cierre de ASSET-ID-XYZ`, la plataforma ejecuta cuatro acciones: 1. **Graba la arista** en el grafo del Corp Brain OS (XDoc dependiente ← XDoc upstream). 2. **Notifica** al Owner del XDoc dependiente cuando el upstream cierra (satisface la dependencia automáticamente). 3. **Mantiene vivo** el Radar de Dependencias: el dependiente sabe qué espera; el upstream sabe a quién desbloquea al cerrar. 4. **Propone escalamiento** automático a dependencia crítica si transcurre el umbral de tiempo definido en PROTOCOLO sin movimiento. Este mecanismo es lo que convierte al vault — de una colección de documentos paralelos — en un **grafo navegable de trabajo**. El portafolio entero es legible como red, no como lista. ### 9.6 Arquitectura técnica — write-time primario, query-time derivado La plataforma emergente es posible porque WORX es **write-time primario por diseño**. El trabajo interpretativo ya se hizo al escribir el XDoc: cabecera canónica con 6 campos, 7 secciones en orden fijo, dependencias declaradas con sus 4 tipos, changelog con sus 4 tags. Cuando la plataforma consulta, **proyecta** lo ya estructurado; no sintetiza bajo demanda. La consecuencia arquitectónica es concreta: el **Corp Brain OS es un grafo sobre estructura, no un vector DB sobre no-estructura**. La unidad mínima de memoria no es un embedding de texto suelto; es el XDoc con su cabecera y sus 7 secciones. Las consultas atraviesan aristas (Owner, Sponsor, Runner, BCs, Dependencias, Tipo) antes de tocar texto libre. La búsqueda por similitud semántica existe pero es **derivada**, no primaria — se usa para recuperación fina dentro de nodos ya seleccionados por aristas. Esta decisión arquitectónica es la que permite que SherpaX actúe como **mantenedor y no como oráculo**: cura el grafo, propone reajustes, sintetiza proyecciones; pero no genera respuestas desde la nada. La plataforma es auditable porque su raíz es estructura declarada, no síntesis opaca. ### 9.7 Cómo la plataforma orbita las apps transaccionales La adopción de WORX **no requiere** eliminar las apps que la organización ya usa. Requiere que el XDoc sea la fuente única de verdad del trabajo coordinativo y que las apps sean puntos de captura o visualización alineados al vault. Tres patrones de integración cubren la mayoría de los casos: **9.7.1 Reemplazo completo** — casos de alta coordinación cognitiva donde la app transaccional fragmentaba el contexto: - Kanban de proyecto → Vista de Progreso de un XDoc o tablero agregado de XDocs. - Dashboards ejecutivos → Dashboard de Portafolio (§9.3.3). - Apps de gestión de decisiones → Radar de Decisiones (§9.3.3). - Herramientas de status / weekly report → Chat Dashboard + Vista de Síntesis. **9.7.2 Orbitaje** — casos de alta especialización transaccional donde la app sigue siendo la mejor herramienta para su dominio: - CRM → sigue existiendo; pero oportunidades que requieren decisión multi-rol o coordinación cross-equipo se declaran como XDoc. - Calendario → sigue existiendo; pero Morning Checks y Shadow Meetings se reflejan en el vault como entradas del Agente de Ritmo. - Apps de contabilidad, HR, facturación, firma electrónica → fuera del scope de WORX; orbitaje natural. **9.7.3 Sustitución progresiva** — caso más común: - Al arrancar, el XDoc documenta trabajo que antes vivía distribuido en muchas herramientas. - Con el tiempo, las vistas generadas por la plataforma cubren más casos que antes pedían apps específicas. - Las apps transaccionales que quedan se reducen a fuentes de captura o se desactivan sin dolor. **Criterio operativo para decidir:** frecuencia de consulta cruzada. Si la información se consulta atravesando múltiples fuentes y múltiples roles, pertenece al vault. Si es transacción aislada con bajo consumo cross-rol, orbita. La pregunta que decide no es "¿esta app es buena?" sino "¿el contexto que contiene esta app se necesita cruzado con el resto del trabajo?". ### 9.8 Las reglas inviolables del Nivel 3 Cuatro reglas cierran la plataforma emergente: 1. **Derivación, no diseño.** Cada vista en la plataforma responde a una pregunta que alguien hace en un ritmo existente. Sin pregunta, no hay vista. No se construyen features en espera de uso. 2. **El vault es la fuente única de verdad.** La plataforma proyecta lo que el vault contiene; nunca al revés. Si la plataforma dice algo que el vault no dice, el vault gana y la plataforma se rederiva. 3. **Mantenedor, no oráculo.** Ningún agente escribe en el vault sin confirmación humana. La plataforma **propone**; el humano **confirma**; el agente **ejecuta**. El Contrato Humano-IA (§7.5) no se relaja por eficiencia operativa. 4. **Grafo sobre estructura, no síntesis sobre ruido.** El Corp Brain OS atraviesa aristas (Owner, Sponsor, Runner, BCs, Dependencias, Tipo) antes de consultar texto libre. La búsqueda por embedding es recuperación fina derivada, nunca la estructura primaria de la memoria organizacional. Estas cuatro reglas suben el piso total del modelo WORX a **41 reglas inviolables** (11 + 7 + 8 + 6 + 5 + 4). Las Secciones 10 (Guía de Implementación) y 11 (Métricas y Salud del Sistema) descansan sobre este piso ampliado: lo que se implementa y lo que se mide parte del supuesto de que los tres niveles + capa ortogonal ya respetan sus reglas inviolables respectivas. --- ## SECCIÓN 10 — GUÍA DE IMPLEMENTACIÓN *[Por redactar — incremento v0.7]* > **Insumos absorbidos del PLB:** > - Ciclo de gobernanza emergente (Caso → LabPraxis → Principio → SOP → Gobernanza BMF). > - Cómo WORX se construye y evoluciona (práctica → Principios → Keys → MetaPlaybook → Licenciable). > > **Temas pendientes:** > - El reto del hábito y cómo absorberlo. > - El beneficio tangible para adopción. > - Las islas transaccionales: integración sin reemplazo. --- ## SECCIÓN 11 — MÉTRICAS Y SALUD DEL SISTEMA *[Por redactar — incremento v0.7]* > **Insumos absorbidos del PLB:** > - Formato de tabla "Estado del marco por dimensión" con estados ✅🟡🔴⬜. > > **Temas pendientes:** > - Cumplimiento de contratos por rol. > - XDocs huérfanos, XDocs sin cierre. > - Drift de SOPs vs Protocolo declarado. > - Dependencias críticas abiertas a nivel agregado de portafolio. > - Salud agregada de los Corp Brain OS. --- ## CIERRE — MANIFIESTO DE TRABAJO PARA LA ERA DE LA IA *[Por redactar — incremento v0.7]* --- # ANEXO A — INSUMOS EXTERNOS EVALUADOS *Captura de análisis estructurados sobre insumos externos que validan, enriquecen o extienden el modelo WORX. Vive en el MPB durante la fase de construcción y migra a un doc de referencia independiente una vez que el contenido quede absorbido en las secciones correspondientes. Se actualiza aditivo — cada insumo nuevo se apila con su fecha de análisis.* ## A.1 Insumos Nate Jones — dos videos analizados el 2026-04-19 Nate Jones es analista IA con audiencia ejecutiva. Dos videos de 2026 consumidos como validación externa de la arquitectura WORX. Ambos BCVs quedan almacenados en `IB-EL-EmpowerLabs/BC-EL-BrainCodes/`. ### A.1.1 Video — World Models Failure / Cognitive Stack **BCV:** `BCV-WORLD-MODELS-FAILURE-CognitiveStack-v02` **Tesis del video:** las organizaciones fallan al integrar IA porque imponen un modelo del mundo global (un "world model" enterprise-wide) en vez de respetar las fronteras interpretativas locales donde el trabajo ocurre. Nate distingue tres arquitecturas posibles para organizar memoria organizacional IA-nativa — Vector DB (búsqueda por similitud sobre texto suelto), Structured Ontology (schema fijo impuesto), Signal Fidelity (estructura que preserva el contexto del acto original) — y argumenta que sólo la tercera escala sin perder contexto. **Conceptos introducidos:** - **Interpretive Boundary** — la frontera contextual de un acto de trabajo. Fuera de ella, la información pierde significado. - **Signal Fidelity** — preservación del contexto del acto original al momento de registrarlo. - **Outcome Encoding** — codificar el trabajo por resultado esperado, no por tema o categoría. - **Editorial Function** — el rol del agente como curador editorial del material, no como autor. - **Shadow Mode** — operar en paralelo sin intervenir hasta que hay validación humana. - **Local Hard Takeoff** — la asimetría de productividad ocurre organización por organización, no globalmente. **Validaciones con WORX:** - **Signal Fidelity = cabecera canónica del XDoc + BCs declarados en CONTEXTO.** Lo que Nate describe como discipline requerida, WORX lo tiene como invariante estructural de §4. - **Interpretive Boundary = scope del XDoc con Owner/Sponsor.** Cada XDoc tiene frontera explícita: quién es responsable, qué decide, a qué portafolio pertenece. - **Editorial Function = Contrato Humano-IA.** §7.5 define al Sherpa como curador/editor, no como autor. Nate lo describe como hallazgo; WORX lo tiene como contrato. - **Third Architecture (Signal Fidelity) = WORX por diseño.** Ni vector DB puro ni ontología fija — estructura canónica declarada con metadata rica. - **Local Hard Takeoff = tesis HIOrg.** Validación externa de que la curva de adopción es asimétrica por organización. **Movimientos propuestos:** - *v0.3 · §1 o §2* — añadir 4ª "NOT" a la definición de HIOrg: *no es reemplazar managers con un dashboard*. - *v0.3 · §2* — posicionar WORX como "cuarta arquitectura" operativa: Agentic Structured Work con Interpretive Boundary explícita. - *v0.7 · §11* — métricas derivadas: Exception Catch Rate, Signal Lag, Boundary Compliance Rate, Drift Declaration Rate. - *v1.0 · Glosario* — incorporar los 6 términos con atribución a Nate Jones. **Sesgos a filtrar:** - Pesimismo de adopción empresarial (WORX es prescriptivo, no diagnóstico de adopción fallida). - Determinismo binario en "quien no lo haga desaparece" (framing HIOrg: quien lo monte se separa). - Asunción de agentes homogéneos (WORX distingue Owner agéntico + Sponsor humano). - Sobre-énfasis en métricas externas como solución a problemas culturales. ### A.1.2 Video — AI Memory Architectures / Karpathy Loop **BCV:** `BCV-AI-MEMORY-ARCHITECTURES-CognitiveStack-v02` **Tesis del video:** las arquitecturas de memoria IA divergen en dos caminos. **Karpathy** propone una wiki viva como superficie editable única donde humano e IA escriben juntos (write-time synthesis). **OpenBrain** propone un filing cabinet con librarian que sintetiza bajo demanda (query-time synthesis). Ambos tienen trade-offs. La solución híbrida que Nate propone es **graph DB sobre datos estructurados con AI en rol de mantenedor, no de oráculo**. **Conceptos introducidos:** - **ONE Document** — la superficie canónica única que hace converger el ciclo humano-IA (hallazgo de Karpathy). - **Write-Time Synthesis vs Query-Time Synthesis** — dónde se paga el costo de interpretar. - **AI as Maintainer, not Oracle** — el agente cura la memoria; no genera respuestas desde la nada. - **Karpathy Triplet** — *one surface, one metric, one time budget*: la terna que hace converger un loop agéntico. - **Trace Infrastructure** — registro granular que permite al sistema distinguir señal de ruido en su propia historia. - **Hybrid (graph over structured)** — grafo DB sobre datos estructurados; ni vector puro ni ontología rígida. - **Cognitive Waste** — trabajo cognitivo repetido por falta de superficie canónica. - **Context over Content** — el contexto del trabajo pesa más que el contenido suelto. - **Transparency of Synthesis** — el agente debe mostrar qué combinó y qué descartó (no sólo el razonamiento). - **Meta-agent / Task-agent split** — topología de dos niveles: un orquestador sobre agentes especializados. **Validaciones con WORX (ocho puntos estructurales):** 1. **El "ONE Document" = el XDoc.** El hallazgo central del video — una superficie canónica única donde humano e IA escriben — es el **axioma fundacional de WORX desde la primera versión**. Karpathy llegó al mismo punto por vía técnica; WORX llegó por vía organizacional. La coincidencia valida que el XDoc no es elección estética sino **precondición estructural** para que el ciclo humano-IA converja. La regla inviolable §4.8.1 ("no existe trabajo fuera de un XDoc") pasa de disciplina operativa a invariante de sistema. 2. **Write-Time Synthesis = el ritmo de Cierre.** WORX es write-time por diseño. El CHANGELOG (§4.4.6), el CIERRE canónico (§4.4.7), la promoción de Discussion a decisión registrada (§4.8.3) son todos actos de síntesis al escribir. Cuando la plataforma consulta, el trabajo interpretativo ya está hecho. Esto responde estructuralmente a la pregunta *por qué tanta disciplina de cabecera + 7 secciones en orden fijo*: porque el costo se paga al escribir, no al consultar. 3. **AI as Maintainer = el Contrato Humano-IA.** "El agente no decide, cura" es exactamente §7.5. La regla §4.8.11 (Sherpa nunca cierra NEXT / edita Changelog / promueve sin consentimiento) operacionaliza el principio antes de que Nate lo nombrara. 4. **Karpathy Triplet = XDoc + NEXT + Dependencias/Ritmo.** La terna *one surface / one metric / one time budget* mapea directo: superficie = XDoc (§4), métrica = NEXT con criterio de cierre (§4.4.4), presupuesto = Dependencias (§4.4.2.1) + Ritmo (§5). WORX tiene la terna completa. 5. **Trace Infrastructure = Discussion + Changelog.** WORX tiene dos niveles de trace: Discussion como pensamiento en vivo (§4.4.5) y Changelog con los 4 tags EXEC / DECIDE / LEARN / RUNNER como trazo consolidado (§4.4.6). La regla §4.8.3 (Discussion no sustituye Changelog, se promueve) convierte trace bruto en trace utilizable. 6. **Meta-agent / Task-agent split = Sherpa Personal vs Corporativo + agentes especializados de §9.4.** Topología equivalente: Personal Brain OS con Sherpa personal como filtro, Corp Brain OS con SherpaX orquestando nueve agentes especializados (coordinación, síntesis, ejecución). 7. **Local Hard Takeoff = tesis HIOrg.** Validación externa de la curva de adopción asimétrica que WORX predice: la organización que monta la infraestructura antes se separa; la competencia no se adapta lineal. 8. **Transparency of Synthesis = CIERRE + BCs declarados.** Cuando un BC entra a un XDoc queda declarado en cabecera; cuando SherpaX propone una síntesis, queda registrada como propuesta antes de confirmación humana. Transparencia de cabecera, no aspiracional. **Tratamiento específico del "ONE Document":** Lo que Karpathy y Nate identifican como hallazgo técnico de los últimos seis meses — *la condición estructural para que un loop humano-IA converja es una única superficie canónica de escritura y lectura* — es el axioma fundacional de WORX desde su primera versión. Tres lecturas: - **Validación dura.** La intuición acumulada en años (el problema era formal antes que tecnológico) acaba de ser confirmada por la frontera técnica de la IA agéntica. Esto eleva la expectativa sobre el MPB: no está proponiendo una moda, está proponiendo la estructura a la que la industria está convergiendo por vía de prueba-error con cómputo. - **Palanca retórica.** En §2 y §9, citar a Karpathy con atribución correcta da un bloque de legitimidad externa fuerte. - **Protección del axioma.** Si el XDoc es precondición estructural, cualquier propuesta futura que diga *"para casos simples no hace falta XDoc"* está atacando el cimiento. §4.8.1 pasa de norma operativa a invariante de sistema. **Zonas de absorción al MPB:** | Sección | Concepto | Forma de incorporación | |---|---|---| | §2 Diagnóstico | Cognitive Waste, Context over Content | Añadir el costo oculto del contexto disperso al análisis del problema | | §4 XDoc | Write-Time Synthesis, Karpathy Triplet | Callout en §4.1: "XDoc como precondición de convergencia humano-IA" con cita Karpathy | | §6 Arq. Cognitiva | AI as Maintainer, Transparency of Synthesis | Reformular §6.1–6.2 en torno a "curador, no oráculo"; nombrar meta-agent/task-agent topology | | §7 Contratos | Trace Infrastructure | Reforzar Contrato Humano-IA: el trace es condición de colaboración, no opcional | | §9 Plataforma | Write-Time vs Query-Time, Hybrid, Meta/Task-agent | **Incorporado en v0.5** (§9.4, §9.6, §9.8) | | §10 Adopción | Karpathy Loop como patrón de deployment | Primer ciclo de implementación = montar la terna antes de escalar | | §11 Métricas | Trace Infrastructure | Métricas de salud del sistema write-time | **Vocabulario absorbible (con atribución):** - *Cognitive Waste* (Nate Jones) — trabajo cognitivo repetido por falta de superficie canónica. - *Context over Content* (Nate Jones) — el contexto pesa más que el contenido suelto. - *AI as Maintainer* (Karpathy / Nate Jones) — agente como curador, no fuente. - *Transparency of Synthesis* (Nate Jones) — el agente muestra qué combinó y qué descartó. - *Karpathy Triplet* (Karpathy) — one surface / one metric / one time budget. - *Trace Infrastructure* (Nate Jones) — registro granular que distingue señal de ruido. - *Local Hard Takeoff* (Nate Jones) — la asimetría es por organización, no global. **Sesgos a filtrar:** - Pesimismo de enterprise (WORX es prescriptivo, no diagnóstico). - Fascinación con auto-optimización sin filtro humano (WORX protege el Contrato Humano-IA). - Framing binario de supervivencia vs desaparición (HIOrg framing: separación vs adaptación tardía). - Reducción a métrica única en toda la organización (el NEXT por XDoc tiene criterio de cierre, pero la HIOrg tiene múltiples objetivos). ## A.2 Plan de absorción consolidado **Movimientos ya incorporados en v0.5 (Sección 9):** - §9.6 — Write-Time primario, query-time derivado, grafo sobre estructura. - §9.4 — Topología Meta-Agent (SherpaX) / Task-Agents (9 especializados) como arquitectura de agentes, con callout explícito de la dualidad MePB ↔ MeAg. - §9.8.3 — Regla inviolable "Mantenedor, no oráculo". - §9.8.4 — Regla inviolable "Grafo sobre estructura, no síntesis sobre ruido". **Decisión estructural cascadeada al BMF (no queda sólo en WORX):** El análisis de los dos videos catalizó una formalización al nivel constitucional del ecosistema. La topología meta-agent / task-agent identificada por Nate/Karpathy no se importó tal cual — se reconoció como coincidencia con el patrón **Meta-** pre-existente en el BMF (MPB, MePB, MePB-OF-MePB, MetaFactory) y se formalizó como variante local: - **Prefijo `MeAg-`** registrado en `ARQ-XX-BMF-NamingConvention-v01` con definición canónica y ejemplos. - **Constitución `MePB-OF-MeAg-v01`** creada en `IB-XX-Maestro/IPI-XX-IP-Infraestructura/IPI-XX-BMF-Engine/` como paralelo directo de `MePB-OF-MePB` (misma capa L0.5, misma función: definir el tipo). - **3 invariantes nuevas** (INV-MeAg-01 a INV-MeAg-03) que extienden las INV-01 a INV-07 del Kernel. - **Dualidad MePB ↔ MeAg** formalizada: el MePB es el programa, el MeAg el procesador. Una HIOrg madura tiene ambos declarados. Lectura: el BMF tenía la familia Meta- en lo estático (playbooks, factories) pero incompleta en lo dinámico (agentes). El análisis Nate hizo visible el hueco; la adopción interna lo llenó manteniendo coherencia lingüística y constitucional con lo pre-existente. **Movimientos absorbidos en v0.6 (Parte 1 — Fundamentos):** - ✅ §1.3 · Quinta "NOT" — *no es reemplazar managers con un dashboard* (Nate video 1) absorbida como una de las cinco confusiones que cierra el manifiesto. - ✅ §1.3 · NOT adicional canónica del ecosistema EmpowerLabs — *no es pausar el trabajo actual para "transformarse" antes de retomarlo* (anti-pause, legado de Victor) absorbida en la misma lista. - ✅ §2.1 · WORX como **cuarta arquitectura** operativa — Agentic Structured Work con Interpretive Boundary explícita (Nate video 1) absorbida en el cuadro de las cuatro arquitecturas del trabajo moderno. - ✅ §0.2 · Diagnóstico con Cognitive Waste y Context over Content como lentes del costo oculto (Nate video 2) — colocado en §0.2 (donde realmente vive el diagnóstico de costos), no en §2 como decía la nota original. Decisión validada @Victor 2026-04-25. - ✅ §4.1 · Callout sobre el XDoc como precondición de convergencia humano-IA, con cita a Karpathy (video 2). **Insumos nuevos absorbidos en v0.6 (más allá de Nate/Karpathy — del room HIORGS):** - ✅ §1.5 · Mapeo WORX ↔ pilares del SO-HiORG (WORX = método; Corp-Brain-OS = arquitectura; SherpaX = interfaz). Fuente: `XP-EL-HIORGS-Portfolio-v01` D-012 / Síntesis F. - ✅ §1.4 · Unidad mínima de aplicación = **equipo + proyecto vivo** (D-013). Fuente: `XP-EL-HIORGS-Portfolio-v01`. - ✅ §2.2 · **Cinco capas del Reto** como esqueleto diagnóstico que justifica la cuarta arquitectura. Fuente: `PAP-HIORGS-GranReto-v01`. - ✅ §3.7 · Mapeo explícito Niveles WORX ↔ pilares SO-HiORG (Nivel 3 ↔ SherpaX; Sección 6 ↔ Corp-Brain-OS; método completo ↔ pilar WORX). **Movimientos pendientes para v0.7 (§§10-11):** - §10 · Karpathy Loop como patrón canónico de deployment — primer ciclo = montar la terna (superficie/métrica/presupuesto) antes de escalar. - §11 · Métricas derivadas de Nate video 1: Exception Catch Rate, Signal Lag, Boundary Compliance Rate, Drift Declaration Rate. - §11 · Trace Infrastructure como condición de legibilidad del sistema (video 2). **Movimientos pendientes para v1.0 (revisión integral):** - Glosario al cierre con 13 términos Nate/Karpathy (6 del video 1 + 7 del video 2), con atribución correcta. - Reforzar §6.1–6.2 con framing explícito "curador, no oráculo". - Reforzar §7.5 con trace como condición de colaboración, no opcional. --- - **2026-04-18** · @Claude (Sherpa de redacción) / @Victor (Owner humano) · `[EXEC]` · Scaffolding inicial del MPB creado (bajo naming WERK original). Sección 4 cerrada con 8 subsecciones. Checkpoint previo absorbió selectivamente el PLB y reasignó el SOP. - **2026-04-18** · @Victor (Owner) · `[DECIDE]` · Rebrand WERK → WORX y átomo → XDoc aprobado. Razón: arquitectura post-pivote dejó obsoleto el acrónimo WERK=Keys; WORX aporta consistencia de familia X con SherpaX/DOIX/XDoc y carga X-factor agéntico. Archivo renombrado de MPB-EL-WERK-ModeloOperativo-v01 a MPB-EL-WORX-ModeloOperativo-v01. - **2026-04-18** · @Victor (Owner) · `[DECIDE]` · Cabecera del XDoc extendida: Owner puede ser humano o agente; Sponsor (siempre humano) se añade como ancla decisional. Toda entrada `[DECIDE]` requiere firma humana; co-firma del Sponsor obligatoria cuando Owner es agéntico. - **2026-04-18** · @Victor (Owner) · `[DECIDE]` · Dependencias del XDoc se formalizan como subestructura de ESTADO (§4.4.2.1) con 4 tipos canónicos (`[INPUT]`, `[APROBACIÓN]`, `[DOC]`, `[DECISIÓN]`) y escalamiento automático a Bloqueos. Razón: gap no resuelto en MasterSuite — dependencias invisibles generaban fricción sistémica. - **2026-04-18** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 4 reescrita con los tres cambios estructurales + rebrand completo. Reglas inviolables pasaron de 9 a 11 (se agregaron: Sponsor humano obligatorio + `[DECIDE]` con firma humana; y dependencias en ESTADO). v0.1 estabilizada. - **2026-04-18** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 5 cerrada: Nivel 2 — El Ritmo de Uso, 8 subsecciones. Consolida 4 ritmos por rol (Colaborador, Runner, Owner/Sponsor, Sistema/SherpaX), las 3 vistas del Morning Check, dual cadence, los 3 tipos de reunión + Shadow Meeting, rituales mínimos y 7 reglas inviolables del Nivel 2. Owner agéntico tratado explícitamente en §5.3.3 con desdoble Owner/Sponsor. v0.1 extendida — Parte 2 avanza a dos secciones cerradas. - **2026-04-18** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 6 cerrada: Arquitectura Cognitiva, 9 subsecciones. Formaliza el Sherpa personal como interfaz primaria (flujo canónico de 5 pasos), la separación Personal Brain OS / Corp Brain OS con el Sherpa personal como único filtro, Brain Codes como asesores declarados por XDoc con dos niveles de alcance (personal y organizacional), marco de Decision Rights (costo × reversibilidad) aplicado por PROTOCOLO, y la trilogía Deep Work + Human+SherpaX + Vault-First. 8 reglas inviolables del Nivel Cognitivo operando sobre los Niveles 1 y 2. v0.1 extendida — Parte 2 con tres secciones cerradas. - **2026-04-18** · @Victor (Owner) · `[DECIDE]` · Sección 7 se renombra de "Los 4 Contratos" a "Los 5 Contratos". Razón: el desdoble Owner/Sponsor (decisión previa 2026-04-18) creó un rol humano con responsabilidades propias que no caben dentro del Contrato del Owner. El Contrato del Sponsor se formaliza como quinto contrato del modelo (§7.6). - **2026-04-18** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 7 cerrada: Los 5 Contratos, 9 subsecciones. Contratos de Colaborador, Runner, Owner (con cláusulas adicionales cuando Owner es agente), Sponsor (nuevo) y Humano-IA (transversal, con 5+5 puntos humano/agente). Anclaje a Decision Rights (§6.7) y a la regla de co-firma del Sponsor (§4.4.6). 6 reglas inviolables del Nivel Contractual. El piso total del modelo WORX queda en 32 reglas inviolables (11+7+8+6). v0.1 cierra Parte 2 en cuatro secciones cerradas. - **2026-04-19** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Cascada de rebrand WERK→WORX completada end-to-end: 144 archivos con contenido actualizado, 42 archivos renombrados, 6 carpetas renombradas (IPC-XX-WERK/, PB-WERK/, PB-WERK-Werk/), CloudVault sincronizado, LLM Wiki actualizado (WERK.md → WORX.md), skill `werk-diagnostic` → `worx-diagnostic`, 3 referencias conceptuales "átomo" → "XDoc" en PLB y TP. QA final: sólo persisten las 4 referencias históricas intencionales en este MPB (frontmatter nota_rebrand, §0 definición de WORX, entradas 2026-04-18 `[EXEC]` y `[DECIDE]` del Changelog). - **2026-04-19** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 8 cerrada: Capacidades Personales del Trabajador WORX (Capa Ortogonal), 10 subsecciones. Define las 5 capacidades transversales — Deep Work como modo por defecto, alianza Human + SherpaX en par cognitivo, Vault-First como reflejo, ritmo personal diseñado, curaduría del Personal Brain OS — con el argumento ortogonal (no es 4° nivel; es substrato individual que habilita los 3 niveles). Incluye sección de cultivo (práctica + soporte sistémico) y filtro de incorporación (forma antes que fondo). 5 reglas inviolables de la Capa Personal. El piso total del modelo WORX sube a **37 reglas inviolables** (11+7+8+6+5). Parte 2 cerrada completa. v0.1 → v0.2. - **2026-04-19** · @Claude (Sherpa) / @Victor (Owner) · `[LEARN]` · Análisis estructurado de dos videos Nate Jones incorporados como validación externa: BCV-WORLD-MODELS-FAILURE-CognitiveStack-v02 (3 arquitecturas + Signal Fidelity + Interpretive Boundary + Local Hard Takeoff) y BCV-AI-MEMORY-ARCHITECTURES-CognitiveStack-v02 (ONE Document + Karpathy Triplet + AI as Maintainer + Write-Time Synthesis). Hallazgo de fondo: el "ONE Document" que Karpathy identifica como precondición de convergencia del ciclo humano-IA es el XDoc desde la primera versión de WORX — valida el axioma §4.8.1 como invariante estructural, no disciplina operativa. Decisión: capturar análisis completo en Anexo A del MPB para no perder el trabajo entre sesiones; movimientos de absorción distribuidos en backlog de v0.3 / v0.7 / v1.0. - **2026-04-19** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 9 cerrada: Nivel 3 — La Plataforma Emergente, 8 subsecciones. Principio de derivación (no diseño) como eje; catálogo canónico de 4 familias de vistas (personales, por XDoc, agregadas, por rol); 9 agentes especializados en 3 familias (coordinación, síntesis, ejecución) orquestados por SherpaX con regla común de propuesta→confirmación→ejecución; resolución de dependencias cross-doc vía grafo del Corp Brain OS; arquitectura técnica write-time primario con grafo sobre estructura (absorbe Karpathy/Nate video 2); tres patrones de integración con apps transaccionales (reemplazo / orbitaje / sustitución progresiva). 4 reglas inviolables del Nivel 3 — derivación / vault como fuente única / mantenedor no oráculo / grafo sobre estructura. El piso total del modelo WORX sube a **41 reglas inviolables** (11+7+8+6+5+4). Parte 3 inicia fuera de orden — Parte 1 (§§0-3) queda diferida a v0.3. v0.2 → v0.5. - **2026-04-19** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Anexo A creado: Insumos Externos Evaluados. Captura estructurada de los dos videos Nate Jones con validaciones punto-por-punto, zonas de absorción por sección, vocabulario con atribución, sesgos a filtrar, y plan de absorción consolidado (movimientos cerrados en v0.5 y pendientes para v0.3 / v0.7 / v1.0). El Anexo vive en el MPB durante construcción y migra a doc de referencia independiente cuando todo el contenido quede absorbido en secciones. - **2026-04-19** · @Victor (Owner) · `[DECIDE]` · Formalización de **Meta-Agent (MeAg)** como tipo de asset del BMF, no sólo concepto local de WORX. Razón: el análisis Nate/Karpathy hizo visible que la familia Meta- del BMF (MPB, MePB, MePB-OF-MePB, MetaFactory) estaba completa en lo estático pero incompleta en lo dinámico. Adopción elegida: Opción A + seed de Opción C — registrar prefijo formal, crear constitución seminal, reservar decisión de capa (L0.5 vs L0.7) para cuando haya 3+ MeAg- assets activos. Vocabulario Meta-Agent se adopta como variante local de la familia Meta- pre-existente, no como importación directa del léxico Nate/Karpathy. - **2026-04-19** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Cascada MeAg ejecutada en tres artefactos del BMF + ajuste WORX §9.4. (1) `ARQ-XX-BMF-NamingConvention-v01` actualizado con prefijo `MeAg-` en tabla §2.1 y Quick Reference §6 — incluye definición canónica, governance reference y ejemplos (MeAg-EL-SherpaX, MeAg-EL-VH-SherpaPersonal, MeAg-EL-Publishing). (2) Creado `MePB-OF-MeAg-v01` en `IB-XX-Maestro/IPI-XX-IP-Infraestructura/IPI-XX-BMF-Engine/` como constitución seminal del tipo, paralelo directo de `MePB-OF-MePB`, con 3 invariantes nuevas (INV-MeAg-01 a 03), campos requeridos, dualidad MePB↔MeAg formalizada, y trazabilidad al análisis Nate/Karpathy como catalizador. (3) WORX §9.4 renombrada de "Agentes especializados" a "Topología Meta-Agent / Task-Agents", con callout arquitectónico sobre la familia Meta- del BMF y la dualidad programa↔procesador. Los 9 agentes pasan a llamarse formalmente "task-agents bajo SherpaX". (4) Anexo A §A.2 ampliado con sección "Decisión estructural cascadeada al BMF" explicando que el análisis Nate no se importó tal cual — hizo visible un hueco pre-existente y la formalización mantiene coherencia con el patrón Meta- del BMF. - **2026-04-25** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 0 cerrada: El Gran Reto del Trabajo Moderno, 6 subsecciones — pregunta de 2026 como protagonista, búsqueda continua, costos ocultos del trabajo tradicional con Cognitive Waste y Context over Content (Nate video 2), digitalización como escalada del problema (PwC 2026: 80% fallan, 12% beneficios), breakthrough cuántico de la era IA (MIT CISR 2025: 76% como coworker), exponencialización 10X→100X con Compute-as-Labor / Agentic Workflow / Orchestration Layer / Local Hard Takeoff (Nate), definición operativa de reinvención con tres exigencias. Voz descentrada del autor — EmpowerLabs como evidencia de búsqueda, no biografía. Audiencia: CEOs, consultores DO, líderes de transformación. - **2026-04-25** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 1 cerrada: Manifiesto de Reinvención, 5 subsecciones — los 4 axiomas F1-F4 (trabajo crea valor / IA es miembro del equipo / documentación ES coordinación / contexto siempre transferible) absorbidos del PLB; qué es WORX (método para ecosistemas humano-agente expresado como MetaPlaybook); qué NO es WORX en cinco confusiones (incluida la 4ª "NOT" Nate — *no es reemplazar managers con un dashboard* — y la 5ª NOT canónica del ecosistema EL — *no es pausar el trabajo actual*); para quién es WORX (equipo + proyecto vivo como unidad mínima — D-013); WORX en relación con el SO-HiORG (uno de tres pilares con vida propia — D-012/Síntesis F). - **2026-04-25** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 2 cerrada: Posición en el Ecosistema, 6 subsecciones — cuatro arquitecturas del trabajo moderno (procesos lineales / pila modular / pila digitalizada / WORX como cuarta — Agentic Structured Work + Interpretive Boundary, Nate video 1); cinco capas del Reto absorbidas del `PAP-HIORGS-GranReto-v01` como esqueleto diagnóstico (lo que saben que no saben / lo que no saben que no saben / caos operacional / carga sobre TI / dimensión humana, citas RAND/McKinsey/Deloitte/Bain/Gallup); linaje EmpowerLabs 2004 → MasterSuite/DO IT → DOIX → WORX como evidencia de búsqueda; tabla comparativa DO IT vs DOIX vs WORX por letra; las 5 preguntas como hilo rojo del linaje; islas transaccionales conectadas — qué reemplaza WORX y qué orbita. - **2026-04-25** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Sección 3 cerrada: Arquitectura del Modelo, 7 subsecciones — vista panorámica con diagrama ASCII (3 niveles + capa ortogonal + 2 pilas transversales); tres niveles (XDoc / Ritmo / Plataforma Emergente) con apuntadores a §§4-5-9; capa ortogonal (Capacidades Personales) con apuntador a §8; arquitectura cognitiva y los cinco contratos como pilas transversales con apuntadores a §§6-7; los 6 Keys explícitos como propiedades emergentes (no mecanismos); las 5 preguntas y los 3Cs como principios satisfechos por diseño; mapeo con los pilares del SO-HiORG (WORX-método ↔ MPB completo / Corp-Brain-OS ↔ §6 / SherpaX ↔ §9). Cierra el plano completo del modelo en una vista. - **2026-04-25** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · §4.1 ampliada con callout sobre el XDoc como precondición de convergencia humano-IA (Karpathy, video 2). Cierra el último movimiento Nate/Karpathy de v0.3 listado en Anexo A. La correspondencia entre "ONE Document" del análisis externo y XDoc del modelo se reconoce explícitamente como invariante estructural pre-existente en WORX, no importación. - **2026-04-25** · @Victor (Owner) · `[DECIDE]` · **Voz descentrada del autor ratificada para Parte 1.** El problema y la propuesta son protagonistas; EmpowerLabs aparece como evidencia de búsqueda continua, no como biografía. Audiencia explícita: CEOs, consultores DO, líderes de transformación organizacional. Esta voz se conserva al pasar a v0.7 y v1.0. - **2026-04-25** · @Victor (Owner) · `[DECIDE]` · **Integración del SO-HiORG en el MPB-WORX ratificada.** El MPB describe WORX como MetaPlaybook universal con vida propia y reconoce explícitamente su rol como pilar-método del SO-HiORG. Cross-references a `XP-EL-HIORGS-Portfolio-v01` y `PAP-HIORGS-GranReto-v01` agregadas en frontmatter (campo `absorbe`) y en §§1.5 / 2.2 / 3.7. El MPB se mantiene leíble en dos modos — autosuficiente como descripción del método y como componente del producto SO-HiORG. - **2026-04-25** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Anexo A §A.2 actualizado: backlog de v0.3 marcado como absorbido en v0.6 (5 movimientos Nate/Karpathy + 4 movimientos nuevos del room HIORGS). Backlog v0.7 / v1.0 sin cambio. - **2026-04-25** · @Claude (Sherpa) / @Victor (Owner) · `[EXEC]` · Bump v0.5 → v0.6. Frontmatter, ruta de versionado, TOC y CHANGELOG actualizados. v0.3 (alcance Parte 1) cierra dentro de v0.6 — sin entrada propia en frontmatter porque es alcance, no checkpoint cronológico. **41 reglas inviolables se mantienen** (la Parte 1 no introduce reglas nuevas; describe los fundamentos sobre los que las reglas de Parte 2/3 operan). --- *MPB-EL-WORX-ModeloOperativo-v01 · EmpowerLabs / WORX · Creado 2026-04-18 · v0.6 2026-04-25* *v0.6 — Parte 1 cerrada con voz descentrada + integración SO-HiORG (3 pilares) + 5 capas del Reto absorbidas + callout XDoc/Karpathy en §4.1. 41 reglas inviolables. Quedan §§10-11 + Cierre para v0.7 y revisión integral para v1.0.* *Continúa desde TP-EL-WORX-MPBModeloOperativo-v01.*