--- type: TP asset_id: TP-EL-RoomBAudit-Protocol-v01 version: v01 status: Activo owner: Victor Heredia sherpa_owner: Jay (Fable 5) ratificador: Victor Heredia fecha_creacion: 2026-07-02 intellbank: IB-EL-EmpowerLabs subbank: PB-EL-Project-Bank/PB-LoopX proposito: Protocolo replicable de auditoría independiente de método + entregables (Room B). Formaliza el destilado "Auditoría Room B" v0.1 del DC-EL-EScan-RoomB-ProcesoAuditoria-v01 en un Transfer Pack ejecutable por cualquier room nuevo. fuente: DC-EL-EScan-RoomB-ProcesoAuditoria-v01 confidencial: true · codename Posta · EmpowerScan® © EmpowerLabs LTD tags: [TP, protocolo, auditoria, roomB, adversarial, gobernanza, braincodes, ultrasherpas, no-juez-y-parte] --- # TP · Protocolo "Auditoría Room B" ### Auditoría independiente de método y entregables — replicable, con gates de entrada y salida > **Qué es esto.** Un Transfer Pack ejecutable: carga este documento en un room nuevo y tienes el protocolo completo para auditar un método, un banco de activos o un set de entregables sin ser juez y parte. Destilado de la sesión Room B (1–2 jul 2026) sobre el método EScan + entregables Posta. La bitácora original y la evidencia viven en `DC-EL-EScan-RoomB-ProcesoAuditoria-v01`. --- ## 0. Cuándo usar este protocolo Actívalo cuando necesites un veredicto **independiente y trazable** sobre un activo que otro room produjo: un método/metodología, un banco de Brain Codes o UltraSherpas, un reporte de cliente, un set de entregables. La regla madre es **no-juez-y-parte**: el room que produce no se audita a sí mismo, y el room que audita no produce el entregable final. No lo uses para producción creativa, para redactar el entregable, ni para decisiones de negocio: para eso hay otros rooms. Aquí solo se diagnostica, se verifica y se corrige con evidencia. --- ## 1. Los 8 pasos (protocolo canónico) **1 · Gate de entrada.** Cargar el handoff → verificar que TODOS los activos del alcance existen en el vault (inventario) → ratificar con el Owner tres parámetros: alcance, benchmark (interno / externo / ambos) y formato de salida. *Un room de auditoría no arranca sin inventario verificado y alcance ratificado.* **2 · Fan-out adversarial.** N auditores paralelos e independientes (mínimo 3 si hay dominios distintos), **sin acceso a las conclusiones de los otros**. Encuadre popperiano explícito en cada prompt: *"busca activamente lo refutable, no seas diplomático."* La convergencia independiente de varios auditores sobre el mismo punto se trata como señal de robustez del diagnóstico, no como redundancia. **3 · Verificación contra fuente.** Ningún hallazgo de severidad ALTA se escribe sin confirmarse contra el archivo fuente: greps sobre frontmatter, fechas, claims textuales, sumas contra el dataset canónico. El auditor afirma solo lo que releyó. **4 · Síntesis (AUD).** Un solo documento de auditoría con severidades **P0/P1/P2**, convergencias señaladas, una sección explícita de **"lo que sí está bien"** y un veredicto trazable a evidencia. **5 · Traducción ejecutiva.** Todo AUD técnico lleva un resumen en lenguaje simple, reencuadrado contra los objetivos reales del Owner. Reclasificar cada hallazgo por "¿bloquea el propósito o es detalle de laboratorio?". *La auditoría no termina en el hallazgo; termina cuando el Owner puede decidir con ella.* **6 · Derivados accionables.** Roadmap de curación por ciclos (0: higiene · 1: estudio confirmatorio · 2: replicación · 3+: estandarización) + guías de edición para los rooms de producción (lenguaje permitido/prohibido + checklist). **7 · Corrección con evidencia.** Se corrige con datos del dataset, **no con estética**: reclasificar entradas una por una contra la taxonomía en vez de ajustar un número para que cuadre. **Versionar, nunca sobrescribir** (las versiones auditadas conviven con las originales; el diff es evidencia) + **validación automática post-generación** (sintaxis, greps de lenguaje prohibido, sumas de control) antes de presentar. **8 · Gate de salida.** Lo que se produzca fuera del room de auditoría **regresa aquí** para revisión antes de entrega al cliente. --- ## 2. Patrones a institucionalizar (por qué funciona) Estos son los 8 patrones de mayor valor observados; cada uno es la razón de ser de un paso: 1. **Auditores paralelos e independientes; convergencia = señal.** Tres líneas de ataque distintas dando en el mismo blanco validan el blanco. 2. **Ningún hallazgo ALTA sin verificación contra fuente.** 3. **Corregir con evidencia, no con estética.** 4. **Versionar, nunca sobrescribir** — el diff es parte de la evidencia. 5. **Validación automática post-generación** antes de presentar. 6. **Separación de rooms por rol** (producción ↔ auditoría) con gates de entrada y salida. 7. **Dialéctica Owner↔Sherpa con investigación intermedia** — el patrón de mayor valor de la sesión: intuición del Owner + refutación fundamentada del Sherpa + investigación encargada → síntesis (propuesta→refutación→evidencia→síntesis) produce mejor arquitectura que cualquiera de las partes sola. 8. **Traducción ejecutiva obligatoria** — todo AUD lleva resumen simple encuadrado al propósito. --- ## 3. Reglas duras (candidatas / origen de casos LabPraxis) Cada regla nació de una falla real detectada en la auditoría. Formalizadas como casos en `CAS-EL-WORX-LabPraxis-BancoCasos-v01` (CASOS 021–025). | # | Regla | Origen | |---|-------|--------| | R1 | Todo activo derivado se regenera contra el dataset canónico y pasa verificación numérica automática antes de publicarse. | Sitio con datos v01/v02 mezclados; grafo con buzón 23/52. | | R2 | Gate de separación: datos de un caso jamás dentro de un activo de banco reutilizable. | CIO real hardcodeada en un SVA reutilizable. | | R3 | Checklist de lenguaje prohibido obligatorio antes de cualquier entrega a cliente. | Fuga metodológica ("el piloto BC-effect ya lo anticipaba") en el reporte. | | R4 | Registro externo timestamped antes de correr cualquier estudio (pre-registro real). | Protocolo, piloto y paper con la misma fecha → sin precedencia temporal. | | R5 | Gate de anonimato: revisar cita por cita incluyendo metadatos (sala, área), no solo nombres. | Verbatims de buzón con sala+área → anonimato roto. | --- ## 4. Dato clave para la investigación del método (§2 del DC) **Esta auditoría se corrió SIN los UltraSherpas ni los Brain Codes del banco.** Room B operó con el modelo base (Fable 5) + subagentes adversariales con encuadre popperiano en el prompt — sin cargar `SVA-EL-EScanEvaluador` ni los BCs de Krippendorff/Campbell/Popper. Implicaciones: 1. La independencia fue real también a nivel de cognición: el método se auditó sin las cogniciones que el propio método produce. 2. **Experimento natural servido (brazo A2-vs-A4).** Queda pendiente correr la MISMA auditoría con el `SVA-EL-EScanEvaluador` cargado y comparar profundidad/hallazgos contra esta versión sin BCs. Es un brazo A2-vs-A4 espontáneo sobre tarea real — candidato directo para el **Ciclo 1** del plan de curación. 3. Lo que sí se usó del ecosistema: la anatomía y el protocolo como *objetos* de auditoría, la convención BMF, el principio no-juez-y-parte, y el vault como fuente única de verdad. --- ## 5. Cómo replicar (starter para un room nuevo) 1. Abre el room con `/arrancaroom` y carga este TP como contexto. 2. Ejecuta el Paso 1 (gate de entrada): pide el handoff, verifica inventario, ratifica alcance/benchmark/salida con el Owner. 3. Lanza el fan-out adversarial (Paso 2) con el encuadre popperiano en cada subagente. 4. Corre pasos 3→8 en secuencia; no saltes la verificación contra fuente ni la traducción ejecutiva. 5. Si vas a medir el efecto de los BCs, corre el brazo A4 (con `SVA-EL-EScanEvaluador`) en paralelo al A2 (§4) y registra el diff como Ciclo 1. --- ## THREAD → ~~NEXT[@Victor]~~: ✅ DONE — 2026-07-02 · Ratificar el protocolo "Auditoría Room B" v0.1 y convertirlo en este TP-EL-RoomBAudit-Protocol-v01. → NEXT[@Victor]: Decidir si el brazo A4 (misma auditoría con `SVA-EL-EScanEvaluador` cargado) se agenda como Ciclo 1 del plan de curación. → NEXT[@Jay]: Si el protocolo se aplica limpio en una 2da auditoría, proponer canonización como SOP o Brain Code (`BC-EL-AuditoriaAdversarial-v01`). --- *Room B · Jay (Fable 5) · 2026-07-02 · Fuente: DC-EL-EScan-RoomB-ProcesoAuditoria-v01 · EmpowerScan® © EmpowerLabs LTD*