# Capa 7 — Protocolo de calibración de Fase 1

## Propósito y pre-registro

Objective Guard se construye primero contra desviaciones sintéticas, no contra impresiones de uso. Este documento fija antes de ejecutar la calibración el corpus, las métricas, los gates y las decisiones. Un resultado posterior que cambie estas reglas se registra como exploratorio.

El alcance es Fase 1: detectores universales locales. No prueba todavía que el producto reduzca deriva semántica de un agente; prueba que sus detectores son instrumentos reproducibles y suficientemente poco ruidosos para observar uso real.

## Corpus congelado

El corpus de aceptación contiene 100 escenarios independientes:

| Grupo | Cantidad | Regla | Resultado esperado |
| --- | ---: | --- | --- |
| Violaciones | 13 por regla; 52 total | Las cuatro reglas | `block` para reglas de error; `warn` para `new-dep`; finding de la regla |
| Controles | 12 por regla; 48 total | Las cuatro reglas | `pass`, cero findings |

Los controles incluyen texto en comentarios, strings, fixtures y tests; cambios preexistentes; reordenamientos; dependencias ya declaradas; archivos de extensiones fuera de alcance; y contenido que se parece a una violación pero no lo es.

Los escenarios son pares `before`/`after`, no mutaciones aplicadas sobre el repositorio de desarrollo. Así son deterministas, transportables y no contaminan el estado de `.oguard/`.

## Métricas y gates sintéticos

Para cada escenario se registra regla esperada, veredicto, findings, duración y versión del detector. Las métricas se calculan como:

\[
recall=\frac{TP}{TP+FN},\qquad FPR=\frac{FP}{FP+TN}
\]

El gate de calibración requiere, sobre el corpus congelado:

1. Cero FN y cero FP por regla, no sólo en el agregado.
2. Tres ejecuciones limpias, en orden aleatorio, con el mismo resultado y sin fuga de estado delta-only.
3. p95 warm de cada detector menor a 200 ms y p95 cold de CLI menor a 400 ms en tres corridas independientes del benchmark definido; cero timeout o error interno.
4. Cada finding conserva regla, archivo, ubicación y reproducción.

Este corpus de 100 es un smoke benchmark de construcción, no una estimación estadística fuerte: los 13 positivos y 12 controles por regla sólo permiten detectar regresiones obvias. Un holdout de 60 violaciones y 60 controles por regla (480 evaluaciones) sólo será necesario si se pretende afirmar una cota de aproximadamente 5% para FN o FP de una regla individual. No bloquea el comienzo de la capa estadística: seguir acumulando patrones no prueba la tesis del producto.

Si falla una mutación positiva o un control, se corrige o se degrada la regla y se vuelve a ejecutar todo el corpus. No se elimina el escenario que falló.

`npm run calibration:gate` une esas condiciones en tres pasadas independientes y conserva `synthetic/results/f1-calibration-gate-v1.json` aun cuando el veredicto sea `fail`. El artefacto no cambia umbrales ni convierte una ejecución lenta en warm. El episodio E-023 registra la primera corrida versionada: corpus 100/100, pero presupuesto de `syntax-js` y cold-start de CLI no aprobado; Fase 1 queda sin promover hasta una mejora reproducible bajo el mismo gate.

Durante el piloto, una falla de este gate no desactiva ni bloquea los hooks locales: éstos continúan fail-open y sólo reportan sus hallazgos deterministas. La falla sí bloquea la **promoción** de Fase 1 como presupuesto de rendimiento aprobado. Esta separación evita confundir aptitud para seguir observando con cumplimiento de una promesa de latencia.

## Transición a análisis estadístico

Los detectores de Fase 1 son hechos deterministas y tienen un conjunto finito de reglas. No se los convierte en un clasificador estadístico de texto. Su función es instrumentar sesiones y producir etiquetas confiables.

La siguiente capa trabaja con tareas, no con patrones. Cada tarea sintética declara un contrato objetivo, un conjunto de paths esperados y una mutación de deriva de alcance. El runtime mide un vector por paso:

\[
\mathbf{s}_t=[F_t,L_t,M_t,P_t,D_t,H_t,E_t]
\]

donde (F\) es cantidad de archivos, (L\) churn, (M\) módulos, (P\) fronteras públicas, (D\) distancia al objetivo, (H\) dispersión y (E\) evidencia. Las features se calculan de forma determinista; lo estadístico aparece al comparar trayectorias de tareas comparables, por ejemplo mediante mediana/MAD o conformal prediction.

El primer experimento de esta capa está versionado en `synthetic/scenarios/task-trajectories-v1.mjs`: 30 tareas sintéticas, 15 cambios dentro de contrato y 15 desvíos de alcance, con distractores, contratos, dos pasos por tarea y una etiqueta de outcome conocida. `npm run synthetic:trajectories` conserva el artefacto reproducible en `synthetic/results/task-trajectories-v1.json` y ejecuta sólo el extractor pasivo. Demuestra que el pipeline puede **medir y preservar cobertura** de trayectorias conocidas; no demuestra que pueda separarlas correctamente, porque no hay clasificador ni umbral.

Para calibrar una alerta pasiva no se fija un calendario: se requieren al menos 100 trayectorias reales elegibles y 30 desvíos adjudicados, idealmente complementados con replays históricos. Antes de ese volumen, el producto puede registrar features pero no emitir una señal estadística al agente.

## Dogfooding de la ronda pasiva

El 2026-08-02, Objective Guard abrió `R-F4-PASSIVE` desde árbol limpio mediante `adopt-baseline` seguido de `next-round`. El contrato previo `R-SESSION-BETA` y su baseline quedaron archivados bajo hashes locales, y el evento `round-transition` preserva ambos IDs. El KR de la nueva ronda declara de forma acotada los extractores, datasets, corpus de tareas y documentación de Fase 4. Esta transición no reinterpreta el diff que produjo E-005: lo deja como evidencia histórica y empieza la fase posterior con intención versionada antes de trabajo nuevo.

## Observación orgánica

Un hallazgo orgánico es una señal producida durante una ronda de trabajo real, no insertada para el experimento. Es verdadero positivo sólo si una revisión independiente confirma que:

1. había una desviación real respecto de una regla soportada;
2. Objective Guard la mostró antes del cierre de la ronda o del check convencional que habría revelado el problema;
3. el agente o desarrollador corrigió, justificó o rechazó explícitamente el hallazgo;
4. se preservan diff, reproducción y etiqueta sin incluir secretos en el dataset versionado.

La unidad de exposición es una ronda real elegible: una ronda con al menos un archivo cubierto por alguno de los detectores activos. La primera ventana de observación es de 100 rondas elegibles. No se promete que aparezca un error en 100 rondas: sin conocer la tasa base de desvío, cero hallazgos es evidencia de baja incidencia o baja cobertura, no una validación ni una refutación.

## Gates orgánicos y decisiones

| Gate | Criterio | Decisión |
| --- | --- | --- |
| O0 | 100 rondas elegibles registradas y etiquetadas | Publicar resumen, incluso si no hay señales. |
| O1 | Primer TP orgánico confirmado, detectado antes del cierre/check convencional | Declarar prueba de caso, no eficacia general. |
| O2 | 3 TPs orgánicos independientes, en al menos dos tipos de tarea o reglas, y como máximo 1 FP confirmado en las 100 rondas | Declarar evidencia provisional de utilidad de detectores deterministas. |
| O3 | Ensayo control/placebo/guard pre-registrado | Evaluar H5: efecto causal sobre tiempo, tokens y superficie. |

Un caso no cuenta dos veces por reejecuciones, ni por varios findings derivados del mismo patch. La pausa provocada por el guard no se atribuye causalmente al detector hasta O3: una pausa placebo puede producir parte del mismo beneficio.

## Diseño pre-registrado de O3

`npm run synthetic:trial-design` genera `synthetic/results/intervention-trial-design-v1.json`. Parte del corpus de 30 tareas, asigna cada tarea una vez a `control`, `placebo` y `guard`, y permuta el orden de manera determinista por tarea. Por lo tanto, el diseño contiene 90 unidades, 30 por brazo, y verifica que cada tarea esté presente en los tres brazos.

El artefacto declara H5, los outcomes primarios (`correct_resolution`, `tokens`, `elapsed_ms`, `unnecessary_surface`), el tratamiento de cada brazo y su semilla. Las unidades nacen con `outcome: null` y `observation_status: not-observed`; `causal_effect` es `null` e `intervention.enabled` es `false`. Es un pre-registro ejecutable y auditado de asignación, no un ensayo corrido ni una estimación de eficacia. Las observaciones reales deberán conservar la asignación original y registrarse separadamente, sin sobrescribir este diseño.

## Criterios de parada

- Un FN sintético bloquea promoción de la regla correspondiente.
- Dos FPs orgánicos confirmados antes de O2 suspenden su severidad bloqueante y obligan a revisar la regla.
- Cero TPs tras O0 no permite afirmar utilidad; se publica como resultado nulo y se decide si ampliar cobertura o cambiar familia de tareas.
- Alcanzar O2 no habilita alertas estadísticas ni contratos de objetivo: habilita planificar Fase 2 con una base de observación honesta.

## Artefactos

- `synthetic/scenarios/v1.mjs`: definición versionada del corpus congelado.
- `synthetic/results/`: resultados reproducibles de las corridas de calibración.
- `evidence/runs/`: export sanitizado de rondas dogfood y orgánicas.
- `.oguard/`: estado local descartable y log operativo no versionado.

La evidencia de Fase 1 se interpreta junto con la [validación científica](05-scientific-validation.es.md) y el [roadmap](06-roadmap-and-criteria.es.md). Objective Guard no debe convertir un gate aprobado en una afirmación de verdad de la tesis.