---
type: DC
asset_id: DC-XX-WORX-TaxonomiaXDoc-v01
version: v01
status: Canonical · documento de criterio · taxonomía
owner: Victor Heredia
sherpa_owner: Jay
fecha_creacion: 2026-05-30
fecha_ultima_actualizacion: 2026-05-30
intellbank: IB-XX-Maestro
subbank: IPC-XX-WORX
tipo: DC — documento de criterio · taxonomía de variantes del XDoc
proposito: >
  Establecer que el XDoc deja de ser un artefacto único genérico y pasa a ser una familia:
  un XDoc base (las 7 secciones canónicas de WORX) que se especializa en variantes tipadas
  por dominio (XDoc Loop, XDoc Editorial, XDoc Coach…). El tipado es lo que permite workflows
  más potentes y dashboards precisos. XDoc Loop es la primera variante de referencia.
referencia_canonica:
  - MPB-EL-WORX-ModeloOperativo-v01 (define el XDoc base · §4)
  - PP-XX-SX-SherpaXComoPlataforma-BrainX-v01 (paralelo: motores BrainX)
  - PP-EL-LoopX-ConceptoYModelo-v01 (XDoc Loop en operación)
tags: [dc, worx, xdoc, taxonomia, xdoc-loop, esquema, dashboards, brainx]
---

# Taxonomía del XDoc

## De artefacto único a familia tipada

---

## 1. El cambio de paradigma

El XDoc nació como artefacto único y genérico: cabecera fija + 7 secciones canónicas (CONTEXTO → ESTADO → PROTOCOLO → NEXT → DISCUSSION → CHANGELOG → CIERRE), definido en `MPB-EL-WORX-ModeloOperativo-v01` §4. Sirve para cualquier trabajo.

Pero no es lo mismo un XDoc operativo en una factoría editorial que el documento por prospecto de un sistema de gestión orbital. El XDoc genérico se queda corto cuando el workflow necesita estructura específica.

La decisión: **el XDoc se vuelve una familia.** Hay un XDoc base, y variantes especializadas que lo extienden por dominio. Es el mismo patrón que en la plataforma: así como SherpaX se especializa en motores BrainX, el XDoc se especializa en variantes tipadas. Y se emparejan —cada motor BrainX opera sobre su variante de XDoc.

```
SherpaX  : BrainX        ::  host : motor especializado
XDoc     : XDoc Loop     ::  artefacto base : artefacto especializado
BrainX Loop ←→ XDoc Loop  (motor opera su variante)
```

---

## 2. Por qué importa: tipado = precisión

Un XDoc genérico no puede alimentar un dashboard preciso porque no tiene campos conocidos. Un XDoc **tipado** sí: tiene esquema, y el esquema es lo que permite agregar, calificar y visualizar con exactitud.

Esto es lo que hace que la decisión Vault-native rinda dashboards reales: sin tipado, los documentos en markdown son notas sueltas; con tipado, son data agregable. La especialización del XDoc es la pieza que convierte el Vault en fuente de tableros precisos.

---

## 3. El modelo: base + extensiones (herencia de esquema)

**XDoc base** — los campos y secciones compartidos por todas las variantes:

- Cabecera: Owner, Sponsor, estado de salud (🟢🟡🔴), dependencias, Brain Codes asesores.
- 7 secciones canónicas: CONTEXTO, ESTADO, PROTOCOLO, NEXT, DISCUSSION, CHANGELOG, CIERRE.

**Extensiones por variante** — cada variante añade frontmatter tipado y/o estructura de dominio sobre la base, sin romperla.

Esto da dashboards de dos niveles: los campos base permiten vistas cruzadas entre tipos; las extensiones tipadas permiten tableros precisos por tipo.

---

## 4. El conjunto inicial de variantes

El principio: una variante no se inventa, se deriva de un workflow o motor que necesita un registro tipado y agregable. No se trata de complicar —se trata de 3-4 tipos que potencien los workflows.

| Variante | Dominio / motor | Estado |
|---|---|---|
| **XDoc Loop** | Prospecto · BrainX Loop · gestión orbital | Activa (primera de referencia) |
| **XDoc Editorial** | Unidad de trabajo en factoría editorial | Por definir |
| **XDoc Coach** | Persona en desarrollo · BrainX Coach | Futura (cuando exista el motor) |
| *(reservado)* | Workflow nuevo que lo requiera | — |

El XDoc base sigue disponible como tipo genérico/fallback para trabajo que no necesita variante.

---

## 5. XDoc Loop — la variante de referencia

**Nombre canónico:** XDoc Loop. *(LoopDoc queda como alias informal.)*

XDoc Loop es las 7 secciones canónicas instanciadas para un prospecto, más un frontmatter tipado que alimenta el Tablero Loop:

Mapeo de las secciones base al dominio Loop:

- **CONTEXTO** — quién es el prospecto, la relación, el resultado esperado, Brain Codes del decision maker.
- **ESTADO** — gravity score, estado de órbita, última señal, dependencias.
- **PROTOCOLO** — nivel de autonomía aplicable (según valor × complejidad).
- **NEXT** — la siguiente acción decidida.
- **DISCUSSION** — criterio e inteligencia de dark social capturada por el humano.
- **CHANGELOG** — bitácora de interacciones y movimientos.
- **CIERRE** — desenlace y aprendizaje.

Frontmatter tipado (campos que el Tablero agrega): `prospecto`, `gravity_score`, `orbit_state`, `value_tier`, `signal_auto`, `signal_humano`, `instancia`, `owner`, `status`.

**Convención de instancia:** los XDocs reales se nombran con prefijo `XD-` (convención WORX ya existente). Un XDoc Loop concreto sería `XD-EL-Loop-[Instancia]-[Prospecto]-vNN`.

---

## 6. Relación con la plataforma

Esta taxonomía es el complemento documental de la arquitectura BrainX: cada motor produce y consume su variante de XDoc. La pareja motor↔artefacto (BrainX Loop ↔ XDoc Loop) es la unidad funcional de la plataforma. Definir bien las variantes del XDoc es, por tanto, parte de definir el estándar de los motores.

---

## 7. Estado y próximo paso

- **Status:** Canonical · taxonomía declarada.
- **Próximo paso:** definir el esquema completo de XDoc Loop en el doc de infraestructura del Room PB-LoopX (paso 3), y evaluar la actualización ligera del XDoc base en `MPB-EL-WORX-ModeloOperativo-v01` para que reconozca la familia.

---

**Owner:** Victor Heredia · **Sherpa:** Jay · **Fecha:** 2026-05-30