# Capa 1 — Visión y tesis de Objective Guard

## Problema

Los agentes de programación pueden funcionar con gran efectividad mientras el contexto relevante de una tarea sea pequeño y observable. A medida que un repositorio crece orgánicamente, aparecen dependencias implícitas, restricciones dispersas y feedback insuficiente. El agente puede entonces:

- localizar mal el problema;
- construir sobre una hipótesis incorrecta;
- expandir progresivamente el cambio;
- debilitar tests para hacer pasar una solución;
- reemplazar componentes cuyo comportamiento histórico no comprende;
- declarar éxito sin evidencia suficiente.

El costo más evitable no es solamente introducir un error. Es descubrirlo varios pasos después, cuando nuevas decisiones ya dependen de él.

La observación de una curva “pequeño-bien, mediano-mal, grande-estructurado-mejor” continúa siendo una hipótesis confundida. Objective Guard no presupone que sea universal. El producto recolectará evidencia para medir cuándo aparece y qué factores la explican.

## Tesis vigente

La tesis de producto es más limitada y falsable que el PRD inicial:

> Un agente puede trabajar con mayor confiabilidad y menor costo si recibe feedback programático en el primer momento donde existe evidencia reproducible de una violación, y si las expansiones estadísticas de alcance se observan y calibran antes de convertirse en decisiones bloqueantes.

La tesis científica asociada propone que el desempeño depende de la relación entre complejidad efectiva, contexto necesario, localidad, contratos y observabilidad; no sólo del tamaño bruto.

Una mnemotecnia útil, no una cantidad directamente medible, es:

\[
\rho = \frac{K}{C_{\mathrm{eff}}}
\]

Donde \(K\) es el contexto mínimo fundado necesario para una tarea y \(C_{\mathrm{eff}}\) la capacidad efectiva del agente para usar contexto. Ambas son variables latentes y sólo se utilizarán mediante proxies validados.

Objective Guard no necesita probar esta teoría para entregar valor inicial: puede detectar hechos locales como sintaxis rota, tests deshabilitados o dependencias nuevas desde el primer release.

## Principios

### P-01 — Reflejo antes que plano de control

El primer nivel debe reaccionar por edición, con cero configuración y salida delta-only. Los componentes más sofisticados se agregan cuando existe evidencia de que justifican su costo.

### P-02 — Hechos, inferencias y decisiones son objetos distintos

- Hecho: una assertion fue eliminada.
- Inferencia: la superficie del cambio está en el percentil 99.
- Decisión: una política exige pausar y justificar.

El sistema nunca debe presentar una anomalía estadística como demostración de incorrección.

### P-03 — Bloqueo proporcional a evidencia

Una violación reproducible puede bloquear. Una señal no calibrada sólo se registra. Una señal estadística calibrada puede advertir o requerir justificación según política explícita.

### P-04 — Costo proporcional al impacto

El costo de validación debe crecer con el radio de impacto y la incertidumbre, no con el tamaño total del repositorio.

### P-05 — Push y delta-only

Los hallazgos nuevos se entregan automáticamente en el ciclo del agente. Los hallazgos conocidos no consumen tokens repetidamente.

### P-06 — `unknown` es un resultado válido

Ausencia de evidencia no equivale a corrección. Cada criterio puede estar `proven`, `violated`, `unknown` o `not_applicable`.

### P-07 — Fallar sin romper el loop

Un error interno del guard no debe bloquear una edición. Debe quedar registrado y ser observable sin confundirse con un `pass`.

### P-08 — Medir antes de gobernar estadísticamente

Las métricas de deriva comienzan en modo pasivo. Sólo después de calibración fuera de muestra y un ensayo de intervención pueden generar alertas automáticas.

## Límites epistémicos

Objective Guard no puede:

- demostrar formalmente la corrección general de un programa;
- recuperar una intención que nunca fue expresada ni observable;
- garantizar que un contrato humano represente correctamente el objetivo;
- inferir requisitos históricos completos desde el código;
- usar consenso de modelos como sustituto de evidencia independiente;
- convertir tests incompletos en un oráculo perfecto;
- afirmar una probabilidad de incorrección a partir de un percentil de anomalía.

El producto sí puede reducir el espacio de error, hacer visibles incertidumbres, exigir evidencia por criterio y detectar desviaciones antes de que acumulen costo.
