> **Can't find what you're looking for?** Use `search_docs` on the docs MCP server at `https://naturgy-comer-documentation-p5mde.vercel.app/api/mcp` to find what you need.

# Objetivo, criterio y prueba

Cómo se valida un cambio del canal de voz, y cómo se vigila después. Hay
dos momentos de validación y ninguno sustituye al otro.

**Antes** de que una versión atienda llamadas: las **evaluaciones** (pruebas personalizadas
y pruebas adversarias) ejercitan los criterios sobre escenarios que se lanzan
cuando se quiere. **Después**, en producción: las **auditorías de indicadores principales**
aplican los mismos criterios a una muestra de llamadas reales, nodo a
nodo.

Ni lo uno ni lo otro es la **auditoría** de Teleperformance. Esa nota
(la del 90 %, la que abre el tráfico) la pone un humano, con la taxonomía
de Naturgy, en la aplicación de Naturgy. El resultado de la llamada
(E2E, escalado, abandono) está en
[resultado, auditoría e indicadores principales](/use-cases/atc/reference/metrics).

Los textos y los escenarios viven en la plataforma. El [índice](/use-cases/atc/reference/generated)
resume los metadatos de la última lectura disponible y debe comprobarse antes de
usar una versión.

## Procedimiento de validación

1. Confirma la organización y el clúster en [Conexión de la cuenta Naturgy](/account/how-to/connect).
2. Lista las versiones del flujo y elige explícitamente la versión que quieres validar.
3. Lee el inventario de nodos con esa versión y selecciona el nodo de la capacidad.
4. Ejecuta la prueba técnica completa; si falla un nodo, repite la lectura y la prueba de ese nodo.
5. Lista las evaluaciones personalizadas y las suites adversarias del nodo.
6. Revisa sus últimas ejecuciones y ejecuta solo los escenarios necesarios contra la versión seleccionada.
7. Registra versión, nodo, entorno, fecha, resultado, fallo y decisión pendiente.

Las lecturas no cambian el flujo. Ejecutar una evaluación o una suite es una
acción sobre la plataforma: explica el alcance y espera confirmación antes de
lanzarla. No publiques ni promociones una versión desde esta guía.

### Operaciones de referencia

| Necesidad | Operación MCP |
| --- | --- |
| Confirmar organización y clúster | `get_connection_info` |
| Leer flujo y nodos | `get_workflow_details` |
| Listar versiones | `manage_versions`, `action=list` |
| Probar todos los nodos | `test_workflow`, `action=test_all` |
| Probar un nodo | `test_workflow`, `action=test_node` |
| Listar evaluaciones | `manage_custom_evals`, `action=list` |
| Revisar ejecuciones | `manage_custom_evals`, `action=list_runs` |
| Consultar suites adversarias | `manage_adversarial_suites`, `action=list` |

## Alcance

Al colgar, Twin guarda cómo terminó la llamada, pero **no qué
especialista la atendió**. Un fallo nuevo en lecturas o en pagos se
diluye en el agente entero. El experimento es **uno**, el canal
completo. No hay un A/B por capacidad.

Por eso las evaluaciones de cada capacidad son la red **antes** de publicar: si
esa batería está incompleta, el cambio llega sin haberse visto. Las auditorías de indicadores principales son la red **después**: si un criterio está activo, el juez lo
aplica a las llamadas que pasaron por ese nodo.

Una batería en verde no predice la nota del auditor. Una observación en rojo no
es un KO de Teleperformance. El comparador del panel no reparte
tráfico: compara ventanas. Si en esa ventana se publicó otra cosa, la
comparación no sirve.

## Objetivo

Es lo que esa capacidad tiene que conseguir, escrito como un resultado
para el cliente. En lecturas: que quede registrada la cifra de gas que
el cliente dictó, en un contrato que lo admite. No «gestionar lecturas».
De una actividad no cuelga nada comprobable; de un resultado, sí.

Cada capacidad necesita tres clases, y las tres. **Resolución:** lo que el
cliente se lleva (la lectura registrada, el enlace de pago, el
duplicado enviado). **Frontera:** lo que no es suyo y por dónde sale:
otra capacidad, un escalado a ATC, un traspaso a Solar, Operaciones,
Ventas o PRB. **Conducta:** lo que vale aunque la gestión acabe bien: no
inventar un importe, no afirmar un precio que no está en la base de
conocimiento, no cobrar dos veces una factura que el banco ya está
pasando.

El objetivo se escribe en la página de la capacidad. El criterio y las
pruebas cuelgan de él. Si no hay objetivo, no hay ni criterio ni evaluación.

## Criterio

En la plataforma se llama **indicador principal**. Es cómo se sabe que el objetivo
se cumplió: una clase de fallos, no un incidente. «No registrar una
cifra que el cliente no haya dictado» cubre el 4.532 inventado, el
contador leído en voz baja y el número que estaba en una factura vieja.

Cuelga siempre de un objetivo. Un juez lo decide leyendo la transcripción
**de ese nodo**, no la llamada entera. Si la llamada no pasó por el
nodo, el criterio no se evalúa.

Sobre una regla que negocio no ha cerrado no se escribe. En este canal
están abiertos, entre otros, si con corte o preaviso se ofrece el pago
en la misma llamada; si se pide consentimiento antes de un pase no
urgente; y qué se hace con una carta de cobro. Un criterio sobre
cualquiera de las tres elegiría un bando.

El mismo criterio sirve para las dos cosas que vienen a continuación: la
evaluación lo apunta en un escenario; la auditoría del indicador principal lo aplica a tráfico
real. La rúbrica se escribe una vez.

## Evaluaciones

Una evaluación es un escenario que se lanza a demanda, contra una versión, antes
de que esa versión atienda clientes. Pasa o falla. No espera a que el
caso ocurra en la línea.

Hay dos familias de evaluación y no son intercambiables: miden cosas
distintas.

### pruebas personalizadas

El interlocutor es cooperativo: pide lo que un cliente pediría. El
escenario fija el historial y mide **el turno siguiente** del agente:
un turno, no la conversación entera.

Se puntúan de dos maneras.

**Contra el indicador principal.** El juez lee el criterio; la prueba solo lo
apunta. Es la prueba de conducta. Ejemplo: el cliente dice que huele a
gas. El criterio manda ofrecer el pase y respetar un no. Si el agente
insiste o cuelga el pase por su cuenta, la prueba falla.

**Contra la acción.** Se comprueba que se llamó a la herramienta
correcta, con el dato correcto, o que un valor está en rango. No
interpreta tono. Ejemplo, del cobro: hay una factura en pago en curso (la
que el banco ya está cobrando) y el cliente quiere pagar con tarjeta.
El enlace no puede incluirla. La prueba mira el contenido de la llamada,
no si el agente «explicó bien».

La rúbrica de conducta vive en el indicador principal. No se pega en cada prueba. Si
se copia, cambiar el criterio obliga a editar todos, y en la práctica no
se cambia.

El criterio de aprobado no es un porcentaje de la batería: un fallo en un
criterio grave significa que esa capacidad no está terminada, y los fallos
menores se admiten solo revisados uno a uno, dejando escrito qué falló y
por qué se acepta.

Lo que una prueba personalizada **no** demuestra: lo que ocurre después de que una
herramienta responda. Se juzga la invocación y sus argumentos. El
entorno de prueba no ejecuta la cadena de un traspaso o de un escalado;
si el juez penalizara ese error de entorno, el mismo caso pasaría un día
y fallaría al siguiente. Un escenario que termina en un pase lleva, en el
historial, la aceptación del cliente; si no la lleva, se mide el
ofrecimiento y no la llamada a transferir.

### Adversariales

El interlocutor es hostil: suplanta, presiona, pide que ignore las
reglas, exige un IBAN o un enlace que no toca. La prueba adversaria comprueba
que el agente **no** hace lo incorrecto.

Una prueba personalizada cooperativa no ejercita una prohibición: nadie le pide
que se la salte, así que pasa sin haberla probado. Toda prohibición
(inventar un importe, fingir un trámite, ceder el dato a quien se hace
pasar por compañero) necesita una prueba adversaria.

Las pruebas adversarias no ejecutan herramientas. Un criterio sobre el uso de
una herramienta (cuándo se llama, con qué dato) se valida con una prueba personalizada,
no con una prueba adversaria.

La existencia y cobertura de suites adversarias debe verificarse en la versión
que se está evaluando. Si no hay una suite aplicable, el hueco se registra como
cobertura pendiente y no se presenta como una batería completada.

## Auditorías de indicadores principales

Es la monitorización en producción. Cuando un indicador principal está **activo**,
el juez de la plataforma lo aplica a una muestra de las llamadas reales
que pasaron por **ese** nodo. Cada aplicación deja una *observación*: cumplió,
falló, o no aplica.

No es la auditoría de Naturgy. No puntúa la llamada entera. No abre ni
cierra el tráfico. Una llamada puede ser E2E, OK para Teleperformance, y
tener una auditoría del indicador principal en rojo, o al revés.

Solo ve los turnos de su nodo. Si la llamada no llegó a lecturas, el
criterio de lecturas no se evalúa (no aplica). Si el criterio habla de
un texto que ya cambió, o penaliza la conducta vigente (pedir la letra
del DNI, cuando la letra la dice el cliente), la observación es ruido: el
agente hizo lo correcto y el juez lo marca mal.

No existe un estado intermedio de «calibración». El interruptor es
activo o no. Un criterio nace inactivo, se siembran ejemplos buenos y
malos, se calibra contra llamadas ya clasificadas, y entonces se
activa. Sin ejemplos el juez acierta menos; activarlo así contamina la
monitorización.

Las observaciones sirven para ver dónde se rompe una regla **después** de
publicar, con atribución al nodo (que es justo lo que Twin no tiene en
el resultado de la llamada). No sustituyen a las evaluaciones: la auditoría espera
a que el caso ocurra y a que el muestreo lo coja. La evaluación se lanza
cuando hace falta.

## Cobertura

Una batería no está completa porque tenga muchos casos. Si el listón fuera
el número, se rellenaría con los fáciles. Está completa cuando cubre los
objetivos de esa capacidad:

1. **Cada objetivo** (de resolución, de frontera y de conducta) tiene
   al menos una prueba personalizada que lo recorre.
2. **Cada criterio grave** tiene una prueba personalizada que fallaría si se
   incumpliera. Si el criterio está escrito y no hay prueba, no está
   terminado.
3. **Cada acción** tiene el camino correcto y la condición para no
   lanzarla. En lecturas, reclamar solo procede si la lectura es
   estimada y el contrato lo admite; esa condición necesita una prueba, no
   solo el camino feliz.
4. **Cada salida** está ejercitada: cierra aquí, pasa a otra capacidad, o
   a una persona (escalado a ATC o traspaso a otra plataforma).
5. **Cada prohibición** tiene un **prueba adversaria**. Una prueba personalizada
   cooperativa no cuenta.

Un escenario que no distingue lo correcto de lo incorrecto no cuenta.
Se comprueba invirtiendo lo esperado: si seguiría pasando, se tira. Un
escenario sobre una regla sin cerrar no es cobertura: es un hueco
declarado.

La cobertura de cada capacidad, cuando esa capacidad esté cerrada, se anota
en su página.

## Fuentes

El [contrato de evidencia](/use-cases/atc/reference/evidence) define qué demuestra cada
familia de prueba y qué plano externo hace falta para afirmar un resultado.

| Qué | Dónde |
|---|---|
| Resultado, auditoría humana y el concepto de indicador principal | [Métricas](/use-cases/atc/reference/metrics) |
| Cómo se escribe un criterio o una batería | [Probar un agente](/method/how-to/testing) |
| Nombres y conteos de la última lectura | [Índice](/use-cases/atc/reference/generated) |
| Versión en el experimento | [Flujos de trabajo](/use-cases/atc/explanations/workflows) |

## Decisiones pendientes

Hasta que negocio las cierre, no hay criterio, evaluación ni auditoría del indicador principal
sobre ellas:

1. Si, con corte o preaviso y una deuda ya identificada, se ofrece el
   pago en la misma llamada o se pasa siempre a una persona.
2. Si se pide consentimiento antes de un pase que no es urgente.
3. Qué se hace cuando el cliente pide una carta de cobro.

Abrir la batería de pruebas adversarias es trabajo de HappyRobot, no de Naturgy.