---
title: "Metrología: qué significa que esto funciona"
description: "ALLAN emite números que deciden si un agente se publica, cuánto cuesta y cuánta autonomía tiene. Este ensayo separa cuáles de esos números son mediciones, cuáles son declaraciones, y qué haría falta para admitir uno nuevo."
allan.topic: foundation
allan.service: allan-registry
allan.date: 08/04/2026
allan.fuente: [Platform Server/internal/agents/eval_engine.go, Platform Server/internal/forge/validation_llm.go, Platform Server/internal/forge/validation_report.go, Platform Server/internal/forge/repair.go, Platform Server/cmd/allan-server/registry_validate.go, Agent Registry/agent_registry/services/lifecycle.py, Agent Registry/agent_registry/domain/policy.py, Economics/economics/domain/evidence.py, Economics/economics/domain/rating.py, Economics/economics/domain/lint.py, Economics/economics/config.py]
allan.audiencia: [desarrollador]
allan.madurez: emergente
---

Un sistema agéntico se defiende con números. El de ALLAN dice que un candidato
puntuó 0,86 sobre un umbral de 0,8 y que por tanto puede publicarse; que la
misión de referencia consume unos 141 WU —el ejemplo trabajado del que cuelgan
todos los presupuestos de capacidad (`Economics/economics/domain/capacity.py:85`)—;
y que un agente es `supervised`, y que por eso sus automatizaciones necesitan
aprobación humana. Los tres enunciados tienen la misma gramática y no el mismo
estatuto. Uno es una convención con una identidad aritmética que la fija; otro es
una cadena de texto en un YAML que nadie ha comparado nunca con el comportamiento
del agente; el tercero, la puntuación, es el único que se presenta como medición
y el único que no lo es.

La pregunta no es si ALLAN funciona, sino qué tendría que ser verdad para que la
frase «esto funciona» significase algo comprobable, y cuánto de eso está hoy
escrito en código.

## Qué mide una puntuación de eval

La pregunta parece de ingeniería y es de psicometría. Cuando el motor emite
`score: 0.86`, ¿de qué magnitud es esa cifra la medida? No de la corrección de
una respuesta: no hay respuesta correcta con la que compararla. No de una tasa
de éxito: no hay una población de tareas de la que los escenarios sean muestra
definida. La magnitud pretendida es algo parecido a «este paquete está listo para
usuarios reales», y no está definida operacionalmente en ningún fichero.

La disciplina que nombró este problema lo hizo hace setenta años. Cronbach y
Meehl escribieron que la validación de constructo interviene siempre que un test
se interpreta como medida de un atributo que no está definido operacionalmente, y
fijaron la condición que la obliga: hay que investigarla siempre que ningún
criterio ni universo de contenido se acepte como enteramente adecuado para
definir la cualidad que se quiere medir. Ése es el caso de un eval de agente. La
consecuencia es la incómoda: para que un constructo sea científicamente admisible
tiene que aparecer en una red nomológica de la que al menos algunas leyes
involucren observables. Un número que no se relaciona con nada más observable no
es la medida de nada.

La puntuación de eval de ALLAN no está hoy en ninguna red. No se compara con la
tasa de fallos posteriores, ni con las intervenciones humanas que el agente
provoca, ni con el coste de sus misiones, ni con nada que ocurra después de la
publicación. El paquete declarativo tiene un campo pensado para cerrar ese
círculo: `success_metrics`, cuyo comentario de esquema promete que se compararán
«against real UsageEvent data post-deployment»
(`Platform Server/internal/agents/agent_schema.yaml:74-76`). Se generan, se
serializan en el `agent.yaml` y se editan desde la API del Registry
(`Agent Registry/agent_registry/services/agents.py:219-223`); ahí termina su
vida, porque no hay en los nueve repositorios un solo consumidor que las calcule
contra uso real. La red nomológica está declarada y vacía.

Que esto no sea un escrúpulo académico lo confirma la literatura reciente sobre
modelos fundacionales, que ha importado el vocabulario entero: König y
colaboradores evalúan las estrategias de investigación mediante los cuatro tipos
de validez de las ciencias sociales empíricas —estadística, interna, externa y
de constructo— y advierten que el ahorro de cómputo se paga en supuestos ocultos,
a veces no comprobables, que al violarse invalidan la afirmación. Los atajos de
medición no se pagan en precisión: se pagan en que la afirmación deja de estar
sostenida.

## El examen lo escribe quien va a ser examinado

La segunda dificultad es estructural y peor que la primera. En ALLAN, el agente
candidato, la rúbrica con la que se le juzga, los escenarios que se le plantean,
el juez que puntúa cada uno, el revisor adversarial y el guardián final son todos
salidas del mismo proveedor de modelos, y todos reciben en su prompt el mismo
texto: el contexto de ejecución del propio agente.

Esto no es una inferencia sobre el diseño; es la firma de cinco funciones.
`designEval` recibe `agentContext` y produce la rúbrica y su umbral
(`internal/agents/eval_engine.go:486-501`); `generateScenarios` recibe
`agentContext` y la rúbrica (`:504-519`); `judgeScenario`, además, el escenario y
la salida del agente (`:521-544`); `redTeamEval` recibe `agentContext`
(`:546-561`); y `gatekeeper`, `agentContext` más el informe completo serializado
(`:563-580`). Los evals de los que todo parte los escribió antes el propio
pipeline de creación, por inferencia desde la misma solicitud en lenguaje natural
que produjo el agente.

Hay una salvaguarda real y conviene reconocerla: el agente bajo prueba **no**
recibe sus propios evals en el contexto. `LoadExecutionContext` carga
`agent.yaml`, `AGENT.md`, habilidades, prompts, hooks y memoria, y `evals/` sólo
entra con `IncludeEvals` (`internal/agents/package_context.go:21-25,76`), opción
que ningún llamador de producción activa. El examinado no ve el examen. Pero los
examinadores sí ven al examinado, y ésa es la mitad que sigue abierta.

La literatura sobre jueces-modelo describe con precisión esa configuración.
Zheng y colaboradores, al proponer el método, enumeraron sus sesgos: de posición,
de verbosidad y de auto-preferencia. Panickssery, Bowman y Feng midieron el
mecanismo del tercero: una correlación lineal entre capacidad de
auto-reconocimiento y fuerza del sesgo de auto-preferencia. Un juez que reconoce
su propia escritura la puntúa mejor, y aquí lo que juzga es literalmente suyo.
Shankar y colaboradores añaden el problema de la rúbrica generada —los
evaluadores generados por un modelo heredan todos los problemas de los modelos
que evalúan— y la circularidad que ALLAN reproduce entera: hacen falta criterios
para calificar salidas, pero calificar salidas es lo que ayuda a definirlos.

Y hay un detalle del código que agrava el diagnóstico más allá de cualquier
sesgo conocido: el umbral no lo fija la plataforma. El informe se inicializa con
`Threshold: 0.8` (`eval_engine.go:248`), pero el guardián devuelve en el mismo
objeto JSON su puntuación **y** su umbral, y si el umbral devuelto es mayor que
cero se instala en el informe (`:357-360`). El veredicto es una conjunción de
cuatro términos —`gate.Pass && report.Score >= report.Threshold &&
evalArtifactsPassed(report.EvalArtifacts) && !artifacts.HasErrors(issues)`
(`:361`)—, y sólo el último de los cuatro es del motor: los dos primeros los
emitió una sola llamada al guardián y el tercero se resuelve un nivel más abajo
contra `Design.PassThreshold`, que escribió el diseñador de rúbricas
(`:730-733`). El 0,8 de reserva sólo sobrevive si el modelo declina responder.
Descontando los defectos estructurales del paquete, en toda la cadena numérica
no queda un valor fijado fuera del modelo.

## Dos puertas con el mismo nombre y dos reglas de decisión distintas

El mismo informe alimenta dos compuertas que no deciden igual, y la diferencia
determina qué se publica.

| | Forge (creación) | Registry (gate de publicación) |
|---|---|---|
| Escenarios | 5 si `supervised`, 3 si no; +1 si el bundle declara herramientas (`validation_llm.go:113-134`, `:140-150`) | 2 por defecto, o `ALLAN_AGENT_EVAL_SCENARIOS` (`registry_validate.go:184-191`) |
| Catálogo de herramientas | vista de solo lectura del registro vivo del tenant (`eval_engine.go:238`) | ninguno: `Tools` no se pasa, luego `mcp.NewRegistry()` vacío (`registry_validate.go:138-142`, `eval_engine.go:388-391`) |
| Presupuesto de ejecución | escalado por autonomía (`validation_llm.go:119-132`) | valores por defecto: 4 pasos raíz, 8 llamadas a herramienta (`eval_engine.go:48-71`) |
| Aviso a los jueces | los jueces saben que fue un sandbox (`eval_engine.go:460-470`) | `Sandboxed=false`; los jueces no reciben ese aviso |
| Qué decide | presencia de hallazgos `blocker` (`validation_report.go:310-316`) | el booleano `passed` del informe (`services/lifecycle.py:673`) |

La última fila es la más importante y la menos evidente. En Forge la puntuación
**no decide nada**: se transporta (`validation_report.go:505-509`) y el veredicto
se calcula contando hallazgos bloqueantes. Cada `required_fix` que el guardián
escribe se convierte en un `blocker` con independencia de si dijo `pass`
(`:514-523`), mientras que las correcciones de los jueces de rúbrica y del equipo
rojo se degradan a `risk` y no bloquean nunca (`:557`, `:571`). La variable de
decisión efectiva de Forge es si el guardián se molestó en redactar prosa en un
campo de lista. En el Registry, en cambio, el booleano sí depende de la
desigualdad entre dos números que emitió la misma llamada.

La puerta que gobierna la publicación es, además, más débil que la que gobierna
la creación, y lo es en la dimensión que el propio diseño identificó como
crítica: lo que el documento de Forge llama un agente amputado es la
configuración en la que corre el gate del Registry hoy.

Y hay un escalón más abajo: los gates de publicación son opcionales y el
predeterminado no exige evals en **ningún** ámbito. `PublicationGates` inicializa
`require_evals = False` (`Agent Registry/agent_registry/domain/policy.py:17-20`)
y `default_policy` activa `require_validation` y `require_approval` para `tenant`
y `global`, pero nunca `require_evals` (`:48-63`); el gate sólo corre si un
administrador lo activa (`services/lifecycle.py:707-708`), cosa que el README
desaconseja mientras el aislamiento sea de sistema de ficheros y no de tenant. En
un despliegue por defecto, ninguna puntuación de eval bloquea nada.

## Lo que ALLAN descartó, y por qué

El corpus de diseño contiene descartes que, leídos juntos, son una teoría
implícita de la medición honesta, y merecen citarse con su motivo textual.

El primero es el registro de herramientas vacío, rechazado por invalidez de
constructo aunque el documento no use esas palabras: «Antes recibía un registro
de herramientas vacío (`mcp.NewRegistry()`), de modo que juzgaba a un agente
amputado y todo defecto de selección de herramientas quedaba invisible hasta
producción» (`docs/agentes/agent-forge-design.md:227`). El mismo párrafo rechaza
fabricar resultados para las llamadas retenidas, con la razón correcta: «un juez
puntuando datos falsos puntúa ruido».

El segundo es la ceguera del reparador. Cuando la validación falla y el autor
pide `refine`, el cirujano recibe hallazgos y correcciones, nunca la nota: «El
cirujano recibe hallazgos y correcciones; ni puntuación, ni umbral, ni rúbrica,
ni transcripción del juez. Es estructural: `BundleEditInstructions` no tiene
dónde poner una puntuación. Un reparador que puede leer el examen optimiza contra
el examinador» (`:270`). La restricción vive en el tipo, no en el prompt
(`internal/forge/repair.go:34-39`), y un test comprueba que ninguna instrucción
contenga `score`, `threshold`, `rubric` ni los valores numéricos del informe
(`repair_test.go:80-107`). Es la aplicación más limpia de Goodhart del
repositorio.

El tercero es la guarda anti-Goodhart del Mejorador: «Un run del Mejorador **o**
edita artefactos del agente contra evals congelados, **o** propone cambios de
evals — **nunca ambos**» (`docs/agentes/agent-improvement-design.md:193`). El
documento afirma que se aplica en código. No hay código: `internal/improver` no
existe en el árbol.

El cuarto está fuera del ciclo de vida del agente y es el más importante porque
sí se implementó: el plan de superficies económicas rechaza tratar la ausencia de
medición como una medición buena
(`docs/economics-surfaces-implementation-plan.md:26-29`). Se sustituye el
booleano `launchable` por un estado —`not_measured`, `insufficient`,
`out_of_model`, `not_launchable`, `launchable`— y «jamás se pinta en verde lo no
medido».

## La única disciplina metrológica que existe hoy

Ese descarte produjo el módulo más riguroso de los nueve repositorios, y está en
Economics. `economics/domain/evidence.py` define un `Calibrated[T]` que
transporta el valor junto con su procedencia
—`measured`, `modelled`, `insufficient`, `not_measured`—, las muestras, los
**sujetos distintos** detrás de ellas y los que la afirmación requeriría; la
distinción entre muestras y sujetos está justificada en el código: «Thirty months
of one customer is one customer's opinion thirty times, not thirty observations
of the population» (`evidence.py:60-61`). Sólo `measured` y `modelled` habilitan
una decisión (`:68-70`), y un valor modelado se reporta como modelado aunque el
ledger coincida, porque «the two answer different questions and only one of them
survives a customer disputing it» (`:131`).

El tamaño de muestra tampoco se elige: se deriva. `required_sample_for` resuelve
por búsqueda entera el menor `n` tal que `q^n ≤ 1 − c` (`:84-113`), que es la
familia de intervalos de tolerancia por estadísticos de orden —el manual del NIST
la introduce con la propiedad que aquí importa: valen para una distribución de
cualquier forma—. Con los ajustes por defecto salen 59 sujetos distintos, y el
comentario dice de quién es la decisión: «lowering either number lowers the bar
for calling a plan launchable, so both are deliberate commercial decisions rather
than tuning» (`config.py:112-118`).

La misma capa trata sus propias constantes como objetos falsables. `K`, la
denominación del Work Credit, vale 10 y está congelada: `UNIT-001` rechaza como
BLOCKING cualquier escritura que la mueva (`domain/lint.py:394-411`). `n_anchor`
no es un parámetro libre sino la solución de una ecuación —la llamada ancla debe
ratear exactamente 1000 milliWU— y `ANCHOR-001` lo comprueba ejecutando el rater
auténtico (`lint.py:443-467`). Y `kappa`, el multiplicador por clase de ejecución
que se aplica sólo a la entrada, puede cambiarse, pero si el cambio mueve el
conjunto de llamadas de referencia más de 5 por mil salta `ANCHOR-002` y obliga a
reexpresar la capacidad mensual de todos los planes en el mismo cambio
(`lint.py:477-500`, `config.py:103-105`): un umbral de deriva declarado, con
unidades, y una consecuencia explícita al cruzarlo. El validador vive dentro del
escritor y no admite interruptor: «There is deliberately no switch to disable it:
a validator that can be turned off is a validator that will be turned off on the
day it would have mattered» (`config.py:92-95`).

Falta lo esencial, y el propio código lo dice: los valores concretos de kappa no
están calibrados contra nada. El fichero de perfiles admite que «the STRUCTURE is
stable; the NUMBERS are calibrated against real traffic in shadow-rating before
launch — treat them as a starting point to be measured, not as settled truth»
(`domain/capacity.py:80-82`), y el comentario de la clase `embeddings` explica
que su kappa es 1000 no porque se haya medido, sino porque era el valor que el
camino de reserva le daba de hecho: «Naming the class and repricing it are two
different acts» (`domain/rating.py:134-142`). Mientras el shadow-rating no corra
sobre tráfico real, esos multiplicadores son una hipótesis sobre el coste
relativo del razonamiento, no una medida de él. Es la deuda más honesta del
repositorio: Economics no sabe si sus constantes son correctas y ha construido la
maquinaria para enterarse; el resto de la plataforma ni siquiera la tiene.

## Fiabilidad, potencia y tamaño de efecto: lo que falta entero

Cada escenario se ejecuta una vez y se juzga una vez. Con entre tres y seis
escenarios por artefacto y sin repeticiones, la diferencia entre 0,79 y 0,81 no
es interpretable, y decirlo no requiere experimento alguno: sin repeticiones no
hay varianza estimable; sin varianza, ni error estándar, ni tamaño de efecto, ni
cálculo de potencia. ALLAN no declara ninguna diferencia mínima detectable
porque no podría calcularla.

Miller parte de que las evaluaciones son experimentos y de que su literatura ha
ignorado la de otras ciencias sobre análisis y planificación experimental, y
propone cinco medidas: errores estándar de la media por el teorema central del
límite; errores estándar agrupados cuando las preguntas vienen en grupos
relacionados; reducción de varianza remuestreando respuestas y analizando
probabilidades del siguiente token; inferencia sobre diferencias pareadas a nivel
de pregunta al comparar dos modelos; y análisis de potencia para decidir si un
eval es siquiera capaz de contrastar la hipótesis de interés. Ninguna está
implementada. La segunda es especialmente pertinente: los escenarios de un mismo
artefacto los generó una sola llamada a partir de una sola rúbrica, luego están
correlacionados por construcción, y tratarlos como observaciones independientes
infla la confianza de forma sistemática.

Cuánto importa la repetición está medido. Alvarado Gonzalez y colaboradores
reevaluaron ocho modelos con tres corridas independientes: 10 de 12 cortes
invierten al menos un orden por pares respecto a la mayoría de tres corridas, y
recomiendan tratar la evaluación como un experimento, reportar incertidumbre y
usar al menos dos repeticiones bajo decodificación estocástica. Mustahsan y
colaboradores traen de la ciencia de la medición el coeficiente de
correlación intraclase, que descompone la varianza observada entre dificultad de
la tarea e inconsistencia del agente, y encuentran que converge hacia las 8-16
repeticiones en tareas estructuradas y necesita 32 o más en razonamiento
complejo. Frente a esas cifras, una corrida única por escenario no es una
aproximación barata: es otra cantidad.

Repetir tampoco bastaría sin controlar el entorno. Yuan y colaboradores muestran
que la reproducibilidad del rendimiento de un LLM es frágil, y que cambiar la
configuración del sistema —tamaño de lote, número y versión de GPU— puede
introducir diferencias significativas en las respuestas, con la causa trazada a
la no asociatividad de la aritmética en coma flotante bajo precisión limitada.
Para ALLAN la implicación es directa: el informe no registra proveedor, modelo ni
versión de configuración. La respuesta que el motor devuelve al Registry tiene
seis campos —`agent_id`, `version`, `passed`, `issues`, `summary`, `score`
(`registry_validate.go:33-40`)— y ninguno identifica al aparato de medida. Dos
informes del mismo paquete no son comparables ni siquiera en principio.

Queda el juez mismo. Lee y colaboradores muestran que su sensibilidad y
especificidad imperfectas sesgan las puntuaciones ingenuas, y corrigen el sesgo
con intervalos que incorporan la incertidumbre del conjunto de prueba y la de un
conjunto de calibración etiquetado por humanos. ALLAN no tiene ese conjunto: no
hay muestra de paquetes con veredicto humano contra la que medir el acuerdo del
guardián, luego no hay forma de saber si es estricto, laxo o ruidoso.

## Contaminación, o el problema contrario

La contaminación clásica —el solapamiento no intencionado entre los datos de
entrenamiento y los de prueba, que según Cheng, Chang y Wu puede inflar
artificialmente el rendimiento— apenas se deja aplicar aquí, porque los
escenarios se generan frescos en cada corrida. Eso elimina un problema y crea
otro peor: sin conjunto fijo no hay comparación entre versiones, entre agentes ni
entre fechas. Cada agente se examina de un examen distinto, escrito para él, por
un modelo que acaba de leer su descripción. Es lo contrario de la sobreadaptación
que Kapoor y colaboradores diagnostican —muchos benchmarks de agentes tienen
conjuntos de retención inadecuados, y a veces ninguno, lo que ha producido
agentes frágiles que toman atajos—, y comparte con ella la consecuencia final: el
número no informa sobre el mundo.

La crítica metodológica reciente añade una razón para no envidiar la alternativa.
Zhu y colaboradores muestran que los defectos de diseño de tarea o de recompensa
pueden llevar a sub- o sobreestimar el rendimiento hasta en un 100 % en términos
relativos: SWE-bench Verified usa casos de prueba insuficientes y TAU-bench
cuenta respuestas vacías como exitosas. Wang, Bianchi y colaboradores, auditando
168 benchmarks, encuentran problemas críticos en más del 25,7 % de las tareas. Y
Wang, Li, Mang, Cheung, Sen y Song sintetizan exploits que puntúan casi perfecto
sin resolver una sola tarea.

Ese último hallazgo tiene una lectura específica para ALLAN. El *reward hacking*
que describen requiere un objetivo estable contra el que optimizar, y el examen
regenerado lo dificulta: en eso el diseño está por encima de la media. Pero aquí
quien podría explotarlo no es un atacante externo sino el propio proveedor de
modelos, que escribe a la vez la respuesta y el criterio, y contra eso la
regeneración no protege.

## Invariantes que el sistema sí garantiza

Enunciados de forma que puedan refutarse leyendo el código.

Ningún reparador automático puede leer una puntuación, un umbral o una rúbrica:
la estructura que se le pasa no tiene campos para ellos
(`internal/forge/repair.go:34-39`), y un test falla si aparecen en el texto de
una instrucción (`repair_test.go:80-107`).

Ninguna herramienta que no declare `readOnlyHint` en sus anotaciones MCP se
ejecuta durante una validación de Forge, y ninguna llamada retenida recibe un
resultado inventado: se responde con un aviso explícito y se registra como
evidencia (`internal/agents/eval_sandbox.go:30-45`).

Forge nunca produce un agente `autonomous` —la petición es un techo y la misma
normalización se reaplica en los checkpoints (`internal/forge/brief.go:120-140`)—
y un nivel desconocido nunca cumple un umbral: cualquier fallo al resolverlo deja
la automatización pendiente de aprobación humana (`internal/forge/types.go:76-82`,
`internal/app/events_tools.go:484-486`).

Ninguna escritura económica puede mover la denominación del Work Credit ni dejar
la llamada ancla rateando algo distinto de 1 WU, y no hay interruptor para
desactivar esas comprobaciones (`Economics/economics/config.py:92-95`,
`domain/lint.py:394-467`); ninguna cifra marcada `not_measured` o `insufficient`
puede conducir una decisión (`domain/evidence.py:68-70`).

## Lo que está roto, sin terminar o sin evidencia

**La medida de convergencia entre intentos no es estable.** La huella de un
hallazgo se calcula sobre `(check, path, field, source, título, corrección)`
(`internal/forge/validation_report.go:148-152`), y para los hallazgos del
guardián título y corrección **son** el texto libre que el modelo generó en esa
pasada (`:514-523`). Entre dos intentos el juez redacta de nuevo; un mismo
defecto descrito con otras palabras produce otra huella y cuenta como resuelto.
El flag `converging` es `len(resolved) > 0`
(`internal/forge/repair.go:298`), luego será verdadero casi siempre, incluso
cuando el segundo intento no haya arreglado nada: mide la variabilidad de la
prosa del juez y se presenta al autor como progreso.

**Los pesos de la rúbrica se piden y se ignoran.** El prompt del diseñador exige
que los pesos de los criterios sumen aproximadamente 1,0 (`eval_engine.go:500`) y
la estructura los transporta (`:148`), pero la agregación es una media aritmética
sin pesos de las puntuaciones de los jueces más la del equipo rojo (`:711-744`).
El campo `Weight` no lo lee nadie.

**La normalización de la escala infiere la unidad de la magnitud.**
`normalizeScore` divide entre 100 cualquier valor en el intervalo `(1, 100]`
(`eval_engine.go:762-764`). Un juez que devuelva 85 queriendo decir 85 % obtiene
0,85, que es lo correcto; uno que devuelva 1,2 por error obtiene 0,012, y esa
puntuación entra en la media sin señal de anomalía. Inferir la unidad del tamaño
del número es lo que una unidad bien definida evita.

**Las correcciones de los jueces que fallan se pierden.** `scoreArtifactReport`
recibe el informe por valor y le añade `RequiredFixes` a `Findings`
(`eval_engine.go:711-718`); el llamador sólo usa los dos valores devueltos
(`:348`). Forge los recupera desde `Judgements`
(`validation_report.go:549-565`), pero el informe del gate del Registry sale con
ese campo vacío.

**El umbral de autonomía no está anclado a ninguna evidencia.** El diseño dice
que la promoción a `autonomous` es «una decisión posterior, respaldada por
evidencia acumulada de evals en producción» (`agent-forge-design.md:250`), y ese
camino no existe: el nivel se resuelve por una tabla determinista en la creación
(`internal/forge/blueprint.go:56-73`), el editor del Registry deja la clave
`level` deliberadamente intacta (`services/agents.py:400-403`) y en tiempo de
disparo el motor la relee del `agent.yaml` (`internal/app/events_tools.go:77-100`).
La cadena es consistente y en ningún punto consulta una medición.

## Qué exigiría admitir un número al corpus

De lo anterior se deduce un criterio, y su mérito es que hoy casi ninguna cifra
de ALLAN lo cumple. Una cifra puede entrar en la documentación, en una pantalla o
en una compuerta si, y sólo si, se sabe qué la produjo —proveedor, modelo,
versión de configuración, número de escenarios—, cuántas observaciones y cuántos
sujetos distintos hay detrás, con qué dispersión entre repeticiones, contra qué
referencia fija se compara, y qué otra cosa observable predice. Si falta lo
último, la cifra puede publicarse como diagnóstico para una persona, nunca como
umbral para una máquina. Si faltan los dos primeros, no se publica.

El tipo que implementa ese criterio ya existe en la casa: `Calibrated[T]`
transporta procedencia, muestras, sujetos y requisito, y su `is_actionable` es
una línea que niega la acción a lo no medido. No hay razón técnica para que un
`AgentEvalReport` no lo lleve; la razón por la que no lo lleva es que las dos
disciplinas se desarrollaron en repositorios distintos y nunca se hablaron.

Mientras tanto, la lectura defendible del informe de validación es la que el
propio diseño defiende para el informe del autor: una lista de hallazgos con su
evidencia, útil porque nombra defectos concretos y auditable porque cada hallazgo
apunta a un artefacto. Esa parte sostiene lo que afirma. La puntuación que la
acompaña, no; y que en Forge ya no decida nada es más una casualidad afortunada
que una decisión.

Queda la advertencia de fondo. Manheim y Garrabrant definen la sobreoptimización
como lo que ocurre cuando una métrica que sirve para mejorar un sistema se usa
hasta el punto en que seguir optimizando es inútil o dañino; la formulación breve
que circula —cuando una medida se convierte en objetivo, deja de ser una buena
medida— se atribuye a Marilyn Strathern. ALLAN se protegió del caso obvio, el
reparador que no ve el marcador, y dejó abierto el difícil: el examinador escribe
el examen leyendo al examinado y fija el aprobado en la misma llamada en la que
pone la nota. La ceguera del reparador es una buena idea aplicada al único sitio
donde no era suficiente.

## Referencias

- **Cronbach, L. J. y Meehl, P. E. (1955).** *Construct Validity in Psychological
  Tests*. Psychological Bulletin 52, 281–302. Texto recuperado en Classics in
  the History of Psychology, York University.
  https://psychclassics.yorku.ca/Cronbach/construct.htm — «Construct validation
  is involved whenever a test is to be interpreted as a measure of some attribute
  or quality which is not "operationally defined."»; «Construct validity must be
  investigated whenever no criterion or universe of content is accepted as
  entirely adequate to define the quality to be measured.»; «A necessary
  condition for a construct to be scientifically admissible is that it occur in a
  nomological net, at least some of whose laws involve observables.»; «A
  construct is some postulated attribute of people, assumed to be reflected in
  test performance.»

- **Zheng, L., Chiang, W.-L., Sheng, Y. et al. (2023).** *Judging LLM-as-a-Judge
  with MT-Bench and Chatbot Arena*. arXiv:2306.05685.
  https://arxiv.org/abs/2306.05685 — «We examine the usage and limitations of
  LLM-as-a-judge, including position, verbosity, and self-enhancement biases, as
  well as limited reasoning ability, and propose solutions to mitigate some of
  them.»

- **Panickssery, A., Bowman, S. R. y Feng, S. (2024).** *LLM Evaluators Recognize
  and Favor Their Own Generations*. arXiv:2404.13076.
  https://arxiv.org/abs/2404.13076 — «By fine-tuning LLMs, we discover a linear
  correlation between self-recognition capability and the strength of
  self-preference bias; using controlled experiments, we show that the causal
  explanation resists straightforward confounders.»

- **Shankar, S., Zamfirescu-Pereira, J. D., Hartmann, B., Parameswaran, A. G. y
  Arawjo, I. (2024).** *Who Validates the Validators? Aligning LLM-Assisted
  Evaluation of LLM Outputs with Human Preferences*. arXiv:2404.12272.
  https://arxiv.org/abs/2404.12272 — «Yet LLM-generated evaluators simply inherit
  all the problems of the LLMs they evaluate, requiring further human
  validation.»; «users need criteria to grade outputs, but grading outputs helps
  users define criteria».

- **Kapoor, S., Stroebl, B., Siegel, Z. S., Nadgir, N. y Narayanan, A. (2024).**
  *AI Agents That Matter*. arXiv:2407.01502. https://arxiv.org/abs/2407.01502 —
  «Third, many agent benchmarks have inadequate holdout sets, and sometimes none
  at all. This has led to agents that are fragile because they take shortcuts and
  overfit to the benchmark in various ways.»; «First, there is a narrow focus on
  accuracy without attention to other metrics. As a result, SOTA agents are
  needlessly complex and costly, and the community has reached mistaken
  conclusions about the sources of accuracy gains.»

- **Miller, E. (2024).** *Adding Error Bars to Evals: A Statistical Approach to
  Language Model Evaluations*. arXiv:2411.00640.
  https://arxiv.org/abs/2411.00640 — «Fundamentally, evaluations are experiments;
  but the literature on evaluations has largely ignored the literature from other
  sciences on experiment analysis and planning.» Las cinco recomendaciones se
  recuperaron de https://arxiv.org/html/2411.00640v1 : «Computing standard errors
  of the mean using the Central Limit Theorem»; «When questions are drawn in
  related groups, computing clustered standard errors»; «Reducing variance by
  resampling answers and by analyzing next-token probabilities»; «When two models
  are being compared, conducting statistical inference on the question-level
  paired differences, rather than the population-level summary statistics»;
  «Using power analysis to determine whether an eval (or a random subsample) is
  capable of testing a hypothesis of interest». Sobre potencia: «Power refers to
  the ability of an experiment to make a measurement of interest in the presence
  of statistical noise.»

- **Cheng, Y., Chang, Y. y Wu, Y. (2025).** *A Survey on Data Contamination for
  Large Language Models*. arXiv:2502.14425. https://arxiv.org/abs/2502.14425 —
  «the reliability of performance evaluation has come under scrutiny due to data
  contamination—the unintended overlap between training and test datasets. This
  overlap has the potential to artificially inflate model performance».

- **Yuan, J., Li, H., Ding, X. et al. (2025).** *Understanding and Mitigating
  Numerical Sources of Nondeterminism in LLM Inference*. arXiv:2506.09501.
  https://arxiv.org/abs/2506.09501 — «We demonstrate that the reproducibility of
  LLM performance is fragile: changing system configuration, such as evaluation
  batch size, GPU count, and GPU version, can introduce significant differences
  in the generated responses.»; «We trace the root cause of this variability to
  the non-associative nature of floating-point arithmetic under limited numerical
  precision.» La cifra concreta que da el artículo —«For instance, under bfloat16
  precision with greedy decoding, a reasoning model like DeepSeek-R1-Distill-
  Qwen-7B can exhibit up to 9% variation in accuracy and 9,000 tokens difference
  in response length due to differences in GPU count, type, and evaluation batch
  size.»— está acotada en la propia fuente a un modelo, una precisión y un modo
  de decodificación, y por eso no se usa en el cuerpo como propiedad general.

- **Zhu, Y., Jin, T., Pruksachatkun, Y. et al. (2025).** *Establishing Best
  Practices for Building Rigorous Agentic Benchmarks*. arXiv:2507.02825.
  https://arxiv.org/abs/2507.02825 — «For example, SWE-bench Verified uses
  insufficient test cases, while TAU-bench counts empty responses as successful.
  Such issues can lead to under- or overestimation of agents' performance by up
  to 100% in relative terms.»

- **Alvarado Gonzalez, M. A., Bruno Hernandez, M., Peñaloza Perez, M. A., Lopez
  Orozco, B., Cruz Soto, J. T. y Malagon, S. (2025).** *Do Repetitions Matter?
  Strengthening Reliability in LLM Evaluations*. arXiv:2509.24086.
  https://arxiv.org/abs/2509.24086 — «Our findings shows that Single-run
  leaderboards are brittle: 10/12 slices (83%) invert at least one pairwise rank
  relative to the three-run majority»; «treat evaluation as an experiment, report
  uncertainty, and use ≥2 repetitions under stochastic decoding».

- **Mustahsan, Z., Lim, A., Anand, M., Jain, S. y McCann, B. (2025).**
  *Stochasticity in Agentic Evaluations: Quantifying Inconsistency with
  Intraclass Correlation*. arXiv:2512.06710. https://arxiv.org/abs/2512.06710 —
  «Yet current evaluation practice, reporting a single accuracy number from a
  single run, obscures the variance underlying these results, making it
  impossible to distinguish genuine capability improvements from lucky
  sampling.»; «We demonstrate that ICC converges by n=8-16 trials for structured
  tasks and n>=32 for complex reasoning, enabling practitioners to set
  evidence-based resampling budgets.»

- **Lee, C., Zeng, T., Jeong, J., Sohn, J. y Lee, K. (2025).** *How to Correctly
  Report LLM-as-a-Judge Evaluations*. arXiv:2511.21140.
  https://arxiv.org/abs/2511.21140 — «However, imperfect sensitivity and
  specificity of the LLM judges induce bias in naive evaluation scores.»; «Our
  framework constructs confidence intervals that account for uncertainty from
  both the test dataset and a human-labeled calibration dataset.»

- **Wang, H., Li, H., Mang, Q., Cheung, A., Sen, K. y Song, D. (2026).** *Do
  Androids Dream of Breaking the Game? Systematically Auditing AI Agent
  Benchmarks with BenchJack*. arXiv:2605.12673. https://arxiv.org/abs/2605.12673
  — «BenchJack synthesizes reward-hacking exploits that achieve near-perfect
  scores on most of the benchmarks without solving a single task, surfacing 219
  distinct flaws across the eight classes.»; «Our results show that evaluation
  pipelines have not internalized an adversarial mindset, and that proactive
  auditing could help close the security gap for the fast-paced benchmarking
  space.»

- **Wang, J., Bianchi, F., Zhu, S., Nie, F., Kwon, Y., Dhingra, B. y Zou, J.
  (2026).** *Automated Benchmark Auditing for AI Agents and Large Language
  Models*. arXiv:2605.26079. https://arxiv.org/abs/2605.26079 — «Across this
  corpus, ABA identifies critical issues including ambiguous task design,
  execution environment conflicts, and incorrect ground truths in over 25.7% of
  the evaluated tasks.»; «filtering out these tasks with issues shifts model
  rankings and increases average performance on SWE-bench Verified and
  Terminal-Bench 2 by 9.9% and 9.6%, respectively».

- **König, G., Pawelczyk, M., von Luxburg, U. y Bordt, S. (2026).** *Validity
  Threats for Foundation Model Research*. arXiv:2606.05029.
  https://arxiv.org/abs/2606.05029 — «savings in compute come at the cost of
  validity threats -- hidden and sometimes untestable assumptions that, when
  violated, can invalidate research claims»; «we evaluate different research
  strategies through four types of validity adapted from the empirical social
  sciences -- statistical, internal, external, and construct validity».

- **Manheim, D. y Garrabrant, S. (2018).** *Categorizing Variants of Goodhart's
  Law*. arXiv:1803.04585. https://arxiv.org/abs/1803.04585 — «This occurs when a
  metric which can be used to improve a system is used to an extent that further
  optimization is ineffective or harmful, and is sometimes termed Goodhart's
  Law.»

- **Strathern, M. (1997).** *'Improving ratings': audit in the British University
  system*. European Review 5, 305–321. **Original NO VERIFICADO**: el PDF
  accesible (archive.org, gwern.net) es un escaneado en compresión de fax del que
  no se pudo extraer texto en esta sesión, de modo que la frase no se ha leído en
  la fuente primaria. Se cita a través de una fuente secundaria sí recuperada:
  M. E. McIntyre, *Goodhart's Law*, DAMTP, University of Cambridge,
  https://www.damtp.cam.ac.uk/user/mem2//papers/LHCE/goodhart.html — «Professor
  Marilyn Strathern FBA, following Hoskin (1996, see below), has re-stated
  Goodhart's Law more succinctly and more generally: `When a measure becomes a
  target, it ceases to be a good measure.'» Nótese que la atribución de la página
  es a Strathern «siguiendo a Hoskin (1996)», y que remite a su artículo de 1997
  sin dar número de página.

- **NIST/SEMATECH.** *e-Handbook of Statistical Methods*, §7.2.6.4, «Tolerance
  intervals based on the largest and smallest observations».
  https://www.itl.nist.gov/div898/handbook/prc/section2/prc264.htm —
  «Tolerance intervals can be constructed for a distribution of any form»; «One
  obvious choice for a two-sided tolerance interval for an unknown distribution
  is the interval between the smallest and largest observations from a sample».
  Se cita como referencia de la familia de métodos por estadísticos de orden; la
  variante unilateral que implementa `required_sample_for` (`q^n ≤ 1 − c`) no
  aparece en esa página, que trata el caso bilateral.