---
type: SOP — Standard Operating Procedure
asset_id: SOP-EL-WORX-FrontmatterIntegrity-v01
version: v01
status: DRAFT · pendiente ratificación Victor
owner: Victor Heredia / EmpowerLabs
sherpa_owner: Jay (SherpaX maestro · ejecutor del protocolo)
fecha_creacion: 2026-05-18
fecha_ultima_actualizacion: 2026-05-18
fecha_validada_contra_filesystem: 2026-05-18 (auto-aplicación · este SOP cumple consigo mismo)
intellbank: IB-EL-EmpowerLabs
subbank: PB-EL-Project-Bank / PB-WORX-Worx
proposito: Protocolo de validación de integridad del frontmatter · garantiza que los campos canónicos que se refieren a la realidad observable (fechas, autor, versión, status) coincidan con la realidad del archivo y del momento de canonización
canonical_de: P014 (CASO 018 LabPraxis · CAS-EL-WORX-LabPraxis-BancoCasos-v01 v1.8) — instanciación operativa universal del principio Frontmatter Integrity
caso_origen: CASO 018 (CAS-EL-WORX-LabPraxis-BancoCasos-v01) — Frontmatter heredado de template sin validación temporal · 3 docs del 18-may con fecha_creacion 2026-05-07
ratificado_por: pendiente (Victor · post-revisión)
sistema_worx: K1 CONTEXT (output) · K4 VAULT (sustrato) · K5 GOVERNANCE (gobernanza del cumplimiento) · K7 SIGNAL/TRUTH (eje primario)
output_canonico: nota en CHANGELOG del activo siendo canonizado · "frontmatter validado vs realidad · YYYY-MM-DD"
aplica_a: Toda canonización de activo en el vault — TP, WOI, MePB, MPB, MF, CP, SOP, BC, PLAN, INV, ART, DC, MAP, CAS, CONS, MIN
documentos_hermanos:
  - CAS-EL-WORX-LabPraxis-BancoCasos-v01.md (CASO 018 · origen · P014 propuesto)
  - SOP-EL-WORX-BrainOSFirst-v01.md (P006 · hermano · este SOP extiende Brain OS-First a metadatos)
  - SOP-EL-WORX-DocBySherpa-v01.md (P010 · documentación delegada · este SOP es gate de calidad del sherpa)
  - SOP-EL-WORX-RoomActivation-v01.md (P012 · starter pack loading · incorpora este SOP al arranque)
tags: [SOP, WORX, FrontmatterIntegrity, P014, antídoto, governance, validacion-temporal, metadatos, signal-truth]
---

## 📋 CHANGELOG
| Fecha | Cambio | Por |
|-------|--------|-----|
| 2026-05-18 | Creación · v01 DRAFT · operacionaliza P014 del CASO 018 LabPraxis · 4 niveles de validación canonizados · auto-aplicación verificada (este SOP cumple consigo mismo desde su nacimiento) | @Jay |

---

# SOP — Frontmatter Integrity
## Instanciación operativa del Principio P014 del LabPraxis

---

## I. PROPÓSITO

Garantizar que todo campo del frontmatter que se refiere a un **hecho observable** (fecha de creación, fecha de última actualización, autor, versión, status, ratificador, fechas operativas) **coincida con la realidad observable del archivo y del momento de canonización**.

Heredar frontmatter de templates está permitido y eficiente. Heredar campos que se refieren a la realidad sin validar contra ella **está prohibido** — porque contamina la única fuente declarada de trazabilidad temporal del vault y degrada toda cronología derivada (minutas semanales · registry · LabPraxis · auditorías · cifras agregadas).

Este SOP es la **Estación G1** obligatoria de cualquier canonización: después de Brain OS-First (G0 · contenido validado contra vault) viene Frontmatter Integrity (G1 · metadatos validados contra realidad).

> *"Heredar contenido es eficiencia. Heredar fechas sin validar es ficción."* — CASO 018 LabPraxis · 2026-05-18

---

## II. CUÁNDO APLICA — Las 5 señales que activan obligatoriamente el SOP

### Señal 0 (universal · primaria · siempre aplica):
**Al cerrar la canonización de cualquier activo nuevo o nueva versión.**

Antes de declarar `status: Active` o `status: PROD` o `status: Canonical` o equivalente, ejecutar este SOP sobre el frontmatter del activo.

### Señales 1-4 (situacionales · refuerzan #0):
1. **Activo nuevo creado heredando frontmatter de template o documento previo** — el riesgo de contaminación es máximo aquí.
2. **Edición sustantiva de activo existente** — `fecha_ultima_actualizacion` debe avanzar.
3. **Renombrado o versionado** — campos `version`, `asset_id`, `fecha_ultima_actualizacion` deben actualizarse coherentemente.
4. **Auditoría retrospectiva del vault** — barrido de docs con divergencia frontmatter ↔ filesystem.

**Heurística de duda:** si el sherpa duda si el frontmatter refleja la realidad, la respuesta es siempre VALIDAR. La duda es la señal.

---

## III. CÓMO SE EJECUTA — Los 4 niveles de validación canónicos

### Nivel 1 · Validación temporal

**Verificar `fecha_creacion`:**
- Si el activo es NUEVO: `fecha_creacion` = fecha del día del sistema (verificable con `date '+%Y-%m-%d'`).
- Si el activo es heredado/renombrado: `fecha_creacion` se preserva si refleja el origen real del contenido · de lo contrario se actualiza y se anota la causa en el CHANGELOG.
- **Anti-patrón prohibido:** copiar `fecha_creacion` de template sin verificar.

**Verificar `fecha_ultima_actualizacion`:**
- Siempre = fecha del día del sistema al momento de la edición que se está cerrando.
- Si la edición no produce cambio sustantivo (correcciones tipográficas), igual se actualiza.

**Verificar fechas operativas declaradas** (`fecha_evento`, `fecha_corte`, `fecha_ratificacion`, etc.):
- Cada una debe coincidir con la realidad operativa que describe.
- Si se desconoce, declarar `pendiente` o `por confirmar` · no inventar fecha.

### Nivel 2 · Validación de identidad y autoría

**Campos a verificar:**
- `asset_id`: coincide con el nombre del archivo (sin extensión).
- `version`: refleja la versión real publicada · semver implícito (v01, v01.1, v02, etc.).
- `owner`: persona o entidad con autoridad real sobre el activo.
- `sherpa_owner` / `sherpa`: agente que produjo o mantiene el activo.
- `ratificado_por`: si está declarado, debe ser veraz · si está pendiente, declarar `pendiente`.

**Anti-patrón prohibido:** heredar `owner` o `ratificado_por` de template sin verificar autoridad real.

### Nivel 3 · Validación de status y relaciones

**Campos a verificar:**
- `status`: refleja el estado real (Active · Draft · Deprecated · Superseded · PROD · etc.).
- `tipo`: corresponde al prefijo del `asset_id` (TP-, MePB-, SOP-, etc.).
- `intellbank` / `subbank`: coincide con la ubicación física del archivo en el vault.
- `referencias_relacionadas` / `deriva_de` / `documentos_hermanos`: rutas válidas a archivos que existen.

### Nivel 4 · Documentación de herencia explícita

Si algún campo del frontmatter se heredó de template o documento previo, el sherpa anota en el CHANGELOG del activo siendo canonizado:

```
- 2026-05-18 · frontmatter validado vs realidad · campos heredados de template: [lista]. Verificados manualmente: [lista].
```

Esto deja constancia auditable de qué se heredó conscientemente y qué se validó manualmente.

---

## IV. OUTPUT CANÓNICO — Nota en CHANGELOG del activo

El SOP no produce documento aparte (a diferencia del SOP-BrainOSFirst que produce CONS-). Su output es una línea en el CHANGELOG del activo siendo canonizado:

### Plantilla mínima (sin herencia)

```markdown
- AAAA-MM-DD · vNN — [descripción del release]. Frontmatter validado vs filesystem y realidad del proceso (SOP-EL-WORX-FrontmatterIntegrity-v01 G1 PASS).
```

### Plantilla con herencia documentada

```markdown
- AAAA-MM-DD · vNN — [descripción del release]. Frontmatter validado vs filesystem y realidad (SOP-EL-WORX-FrontmatterIntegrity-v01 G1 PASS). Campos heredados de template `[template-id]` validados manualmente: `fecha_creacion`, `owner`, `sherpa_owner`, `intellbank`. Campos producidos para este activo: `asset_id`, `version`, `status`, `tipo`, `proposito`.
```

### Plantilla de corrección retroactiva (CASO 018 pattern)

```markdown
- AAAA-MM-DD · corrección de frontmatter · `[campo]` actualizado de `[valor antiguo]` a `[valor correcto]`. Causa: [herencia de template sin validación / forward-dating / desactualización al editar]. Referencia: CASO 018 LabPraxis · P014 Frontmatter Integrity.
```

---

## V. CRITERIOS PASS / FAIL DEL GATE G1

El sherpa solo declara el activo `Canonical` / `Active` / `PROD` / `Ratificado` si los 5 criterios pasan:

| # | Criterio | PASS si | FAIL si |
|---|----------|---------|---------|
| **C1** | `fecha_creacion` válida | Coincide con fecha real del día (activo nuevo) o con el origen documentado del contenido (heredado) | Heredada de template sin verificar |
| **C2** | `fecha_ultima_actualizacion` actualizada | = fecha del día del sistema al cierre de la edición | Congelada o ausente cuando hay edición sustantiva |
| **C3** | Identidad y autoría veraces | `asset_id` ≡ nombre de archivo · `owner` y `ratificado_por` verificados | `owner` o `ratificado_por` heredados sin verificar |
| **C4** | Status, tipo y ubicación coherentes | `status` refleja estado real · `tipo` coincide con prefijo del asset_id · `intellbank/subbank` coincide con ruta física | Discrepancia entre frontmatter y realidad observable |
| **C5** | Herencia documentada en CHANGELOG | Línea explícita "frontmatter validado vs realidad" · herencia explicitada cuando aplique | Sin nota de validación en CHANGELOG |

**Regla de oro:** un FAIL en cualquier C bloquea la canonización. El sherpa repite la validación hasta que los 5 pasen, o eleva al owner si encuentra ambigüedad real.

---

## VI. CONTRATO CON OTROS SOPs

### Contrato con SOP-EL-WORX-BrainOSFirst-v01 (P006)

Frontmatter Integrity es la **Estación G1** que sigue inmediatamente a la Estación G0 de Brain OS-First. Secuencia canónica de gates antes de canonizar:

```
G0 · Brain OS-First (SOP-BrainOSFirst) → consulta vault · valida contenido
↓
G1 · Frontmatter Integrity (este SOP) → valida metadatos vs realidad
↓
Canonización (status: Active / PROD / Canonical)
```

Brain OS-First valida **contenido** (¿este concepto ya existe en el vault?). Frontmatter Integrity valida **metadatos** (¿la metadata del archivo refleja la realidad?). Ambos son complementarios y obligatorios.

### Contrato con SOP-EL-WORX-DocBySherpa-v01 (P010 · Documentación Delegada)

Cuando el sherpa documenta por delegación del humano, el sherpa es responsable de aplicar G0 + G1 antes de cerrar el documento. El humano puede exigir la nota de validación en el CHANGELOG como evidencia.

### Contrato con SOP-EL-WORX-RoomActivation-v01 (P012 · Starter Pack Loading)

Todo Starter Pack al activar un room debe incluir invocación de G0 y G1 antes de cualquier producción canónica:

```
> Antes de canonizar cualquier activo en este room, ejecutar:
> (1) SOP-EL-WORX-BrainOSFirst-v01 sobre el alcance del activo.
> (2) SOP-EL-WORX-FrontmatterIntegrity-v01 sobre el frontmatter del activo.
> Documentar ambos gates en el CHANGELOG del activo producido.
```

### Contrato con el Registry maestro

Ningún activo entra al `CP-XX-IntelliBanks-Registry-v01` sin haber pasado G1. El registry asume integridad del frontmatter para sus cifras agregadas — si G1 no se ejecutó, el registry hereda contaminación.

---

## VII. CONEXIÓN CON LA METODOLOGÍA WORX

| WORX Key | Rol del SOP en este Key |
|---------|------------------------|
| **K1 CONTEXT** | El frontmatter es el contexto formal del activo · este SOP garantiza que ese contexto no miente |
| **K4 VAULT** | El vault es la fuente de verdad · este SOP garantiza que la metadata del vault coincide con la realidad del filesystem y del proceso |
| **K5 GOVERNANCE** | Los CHANGELOGs con notas G1 PASS son auditables · permiten al LabPraxis trackear cuántos activos pasaron G1 vs cuántos no |
| **K7 SIGNAL/TRUTH** | **Eje primario.** Frontmatter Integrity es la operacionalización del principio "la información declarada debe coincidir con la realidad observable" |
| **K6 CADENCE** | G1 es estación obligatoria al cierre de toda canonización · establece el ritmo de salida del proceso de producción |

---

## VIII. LO QUE EL SOP PROHÍBE EXPLÍCITAMENTE

1. **Heredar `fecha_creacion` de template sin verificar** — el patrón canónico del CASO 018 que originó este SOP.
2. **Forward-dating** — declarar `fecha_creacion` posterior al timestamp real del archivo (variante detectada en archivos Rebelocity en la auditoría del 18-may).
3. **Congelar `fecha_ultima_actualizacion`** — editar el contenido sin actualizar el campo.
4. **Declarar `ratificado_por: [persona]` sin ratificación real** — heredar campo de template sin que el ratificador efectivamente haya ratificado.
5. **Canonizar (`status: Active` o equivalente) sin nota G1 PASS en el CHANGELOG.**
6. **Modificar `fecha_creacion` retroactivamente sin documentar la corrección en el CHANGELOG.**

---

## IX. CASOS DE USO ILUSTRATIVOS

### Caso A · Activo nuevo desde cero (sin herencia)

```
Sherpa va a crear DC-EL-SX-EjemploNuevo-v01.md
↓
Ejecuta G0 (Brain OS-First) → consulta vault · sin canónico previo
↓
Produce el contenido del activo
↓
Antes de cerrar, ejecuta G1:
  - C1: fecha_creacion = 2026-05-18 (verificado con `date`)
  - C2: fecha_ultima_actualizacion = 2026-05-18
  - C3: owner = Victor Heredia (verificado · es su proyecto)
  - C4: status = Active · tipo = DC · intellbank = IB-EL-EmpowerLabs (coincide con ruta)
  - C5: nota en CHANGELOG agregada
↓
G1 PASS · canonización declarada
```

### Caso B · Activo nuevo heredando frontmatter de doc similar

```
Sherpa va a crear SOP-EL-XX-Ejemplo-v01.md usando SOP-EL-WORX-BrainOSFirst-v01.md como base de estructura
↓
Copia frontmatter del SOP base
↓
G1 obligatorio antes de canonizar:
  - C1: fecha_creacion = 2026-05-18 (CORREGIDO de fecha del template)
  - C2: fecha_ultima_actualizacion = 2026-05-18 (CORREGIDO)
  - C3: owner = verificado · ratificado_por = "pendiente" (declarado explícitamente)
  - C4: asset_id, version, status, tipo, intellbank verificados
  - C5: nota CHANGELOG con plantilla "con herencia documentada"
↓
G1 PASS · canonización declarada
```

### Caso C · Corrección retroactiva (patrón CASO 018)

```
Auditoría detecta MePB-EL-HIORG-SecurityLayers-v01.md con fecha_creacion: 2026-05-07 EOD pero mtime real 2026-05-18
↓
Sherpa ejecuta corrección:
  - Cambia fecha_creacion: 2026-05-07 EOD → 2026-05-18
  - Cambia fecha_ultima_actualizacion: 2026-05-07 EOD → 2026-05-18
↓
Documenta en CHANGELOG con plantilla "corrección retroactiva":
  - "Corrección de fecha (registrada 2026-05-18) — fecha_creacion corregida de 2026-05-07 EOD a 2026-05-18. Causa: frontmatter heredado de template sin validación temporal. Documentado en CASO 018 del LabPraxis. Antídoto: P014 Frontmatter Integrity."
↓
G1 PASS retroactivo · activo recuperado a integridad canónica
```

### Caso D · Auditoría retrospectiva del vault

```
Cierre de semana ejecuta script de auditoría:
  - Compara fecha_creacion (frontmatter) vs mtime (filesystem) para todos los .md
  - Clasifica divergencias en 3 categorías (A · falla canónica · B · desactualizado · C · normal o legacy)
↓
Reporta hallazgos al owner
↓
Owner decide qué corregir · qué diferir · qué dejar como legacy
↓
Correcciones se aplican siguiendo Caso C
```

---

## X. CONEXIONES CANÓNICAS

| Canónico | Conexión |
|---------|----------|
| `CASO 018` (CAS-EL-WORX-LabPraxis-BancoCasos-v01 v1.8) | Origen del SOP · documenta los 3 archivos del 18-may con frontmatter contaminado |
| `P014 Frontmatter Integrity` (propuesto en CASO 018) | Principio canónico que este SOP operacionaliza |
| `SOP-EL-WORX-BrainOSFirst-v01` | Hermano · Estación G0 (contenido) · este SOP es Estación G1 (metadatos) |
| `SOP-EL-WORX-DocBySherpa-v01` (P010) | Documentación delegada · sherpa aplica G0+G1 antes de cerrar |
| `SOP-EL-WORX-RoomActivation-v01` (P012) | Starter pack loading · debe incluir invocación G0+G1 |
| `CP-XX-IntelliBanks-Registry-v01` | Registry maestro · no acepta activos sin G1 PASS |
| `script de auditoría retrospectiva` (audit_frontmatter_v2.py) | Herramienta operativa · ejecuta la validación masiva del Caso D |

---

## XI. AUTO-APLICACIÓN DEL SOP A SÍ MISMO

Este SOP fue producido el 2026-05-18 (lunes) y aplica G1 a su propio frontmatter desde su nacimiento:

- **C1 · fecha_creacion = 2026-05-18** ✓ verificado con `date '+%Y-%m-%d'` antes de escribir
- **C2 · fecha_ultima_actualizacion = 2026-05-18** ✓
- **C3 · owner = Victor Heredia · sherpa_owner = Jay** ✓ verificado
- **C4 · asset_id = SOP-EL-WORX-FrontmatterIntegrity-v01 · tipo = SOP · subbank = PB-WORX-Worx** ✓ coincide con ruta del archivo
- **C5 · nota en CHANGELOG agregada** ✓

**G1 PASS al nacimiento.** Este SOP cumple consigo mismo desde la primera línea — condición necesaria para canonizar el principio.

Campo adicional `fecha_validada_contra_filesystem: 2026-05-18` agregado al frontmatter como evidencia explícita de la auto-aplicación.

---

## XII. NEXTs

→ NEXT[@Victor]: Ratificar canonización de P014 · post-revisión de este SOP · convierte `status: DRAFT` → `status: PROD`.
→ NEXT[@Jay]: Extender `SOP-EL-WORX-BrainOSFirst-v01` con sección VII nueva (Frontmatter Integrity Rule · referencia cruzada a este SOP) — patch en sesión separada.
→ NEXT[@Jay]: Patch retroactivo a Starter Prompts (SP-) priorizados para incluir invocación G0+G1 al activar room.
→ NEXT[@Jay]: Resolver 5 archivos CAT B identificados en la auditoría del 18-may (fecha_ultima_actualizacion congelada).
→ NEXT[@Victor]: Decidir sobre los 2 archivos Rebelocity con forward-dating (XP-REB-Letape-Sprint300Atletas + SP- starter prompt).
→ NEXT[@Jay]: Registrar `script de auditoría retrospectiva` como herramienta canónica · candidato a `TOOL-EL-WORX-FrontmatterAudit-v01`.
→ NEXT[@Jay]: Actualizar el banco LabPraxis al ratificar P014 · cambiar status del CASO 018 de "🔴 Abierto" a "🟡 En piloto" después de ratificación + primera aplicación in-vivo.

---

*SOP-EL-WORX-FrontmatterIntegrity-v01 · IB-EL-EmpowerLabs/PB-EL-Project-Bank/PB-WORX-Worx/ · 18 de mayo de 2026*
*Owner: Victor Heredia · Sherpa Owner: Jay (SherpaX maestro)*
*"Heredar contenido es eficiencia. Heredar fechas sin validar es ficción."*