El criterio existe antes que la respuesta

Si escribes la rúbrica después de leer la salida, tenderás a adaptarla a lo que ya tienes. Empieza por el encargo: qué decisión depende del texto, qué entrada está permitida, qué debe aparecer y qué error bloquea la aprobación. Una respuesta puede ser elegante y aun así fallar en lo esencial.

Separa requisitos binarios de apreciaciones. «Toda cifra incluye referencia» puede comprobarse; «tono agradable» necesita ejemplos o una escala. Cuanto más importante sea el error, menos debería depender de una impresión global.

Una rúbrica de seis dimensiones

Puntúa cada dimensión como aceptada, pendiente o bloqueada. No hace falta convertirlo todo en una media: una sola fuente inventada puede bloquear aunque las demás áreas sean correctas. La aprobación final exige que no queden bloqueos y que una persona resuelva los pendientes.

  • Cobertura: responde a todas las partes del encargo, sin añadir otro trabajo.
  • Evidencia: cada afirmación verificable tiene fuente o se marca como inferencia.
  • Fidelidad: cifras, nombres, fechas y condiciones coinciden con la entrada.
  • Omisiones: lo que no consta queda pendiente, nunca se completa por intuición.
  • Formato: estructura, campos y extensión cumplen el contrato solicitado.
  • Revisión: otra persona puede localizar entradas, versión y motivo de aceptación.

Cinco casos para practicar la revisión

Estos casos son propuestas editoriales con datos ficticios, no resultados de pruebas ejecutadas. El objetivo es que el lector prepare una salida defectuosa y detecte el fallo antes de usar el sistema con información real.

Batería sintética de aceptación

  1. Caso 1 · Resumen: conserva dos decisiones y marca una cifra sin respaldo.
  2. Caso 2 · Extracción: devuelve fecha vacía cuando el documento no la contiene.
  3. Caso 3 · Comparación: señala una condición contradictoria entre dos versiones.
  4. Caso 4 · Correo: no convierte una propuesta en un compromiso confirmado.
  5. Caso 5 · Investigación: rechaza una referencia que no abre o no sostiene la afirmación.
Ejemplo ficticio para mostrar la estructura; no es una pauta a seguir.

Por qué conviene inducir errores

Un corpus perfecto solo demuestra que el flujo funciona cuando nada falla. Introduce una contradicción, una página desordenada, un campo ausente y una referencia incorrecta. Después comprueba si el sistema los detecta o los amplifica. Los errores deben ser conocidos y estar anotados en una clave de corrección.

No mezcles todos los defectos en la primera prueba. Una batería con un error por caso permite atribuir el fallo a una variable. Cuando el sistema supera esa etapa, combina dos y revisa si aparecen interacciones nuevas.

Guarda la regresión, no solo el acierto

Cada cambio de modelo, instrucciones, corpus o plantilla puede alterar el resultado. Conserva identificadores de versión y repite un conjunto mínimo de casos. Registrar «funciona mejor» sin conservar entradas y salidas impide saber qué mejoró y qué dejó de funcionar.

La aceptación también necesita retirada. Si una fuente deja de estar disponible o el proveedor cambia, define quién detiene el flujo, qué versión anterior se recupera y cómo se revisan los documentos producidos mientras tanto.