Qué parte de una consulta se puede reproducir meses después
Código y catálogos versionados pueden repetirse; una respuesta externa mutable, no siempre. Snapshots, hashes y procedencia separan reproducción de simple reejecución.
Por Marco Ferreiro ·
“Corrimos la misma consulta” no significa necesariamente “reprodujimos el resultado”. Si una fuente externa cambió entre ambas fechas, el mismo código puede devolver otra respuesta y funcionar correctamente. La reproducción necesita distinguir lo que controlamos —código, catálogos, parámetros— de lo que sólo observamos en un momento —el estado de un portal ajeno.
Esa distinción evita promesas imposibles. También orienta qué evidencia conservar sin acumular patentes, actas o datos personales que no hacen falta para el propósito.
Reproducción, reejecución y verificación
Reproducir significa obtener el mismo resultado a partir de las mismas entradas y proceso, dentro de tolerancias declaradas. Reejecutar significa volver a correr el proceso, quizá con entradas externas nuevas. Verificar significa comprobar una propiedad, como que un archivo coincide con una huella registrada.
Una API puede reejecutar hoy una consulta idéntica y obtener una actuación incorporada ayer. No es una falla de reproducibilidad del código; cambió la entrada externa. Sin snapshot histórico, no puede saberse qué habría respondido el portal antiguo más allá de la evidencia conservada.
Usar estas palabras con precisión mejora los informes: “reejecutado con fuente vigente” es distinto de “reproducido desde snapshot”.
Las cuatro capas de una consulta
Un análisis puede dividirse en:
- código y dependencias;
- configuración y catálogo de fuentes;
- datos de entrada o snapshots;
- respuestas externas mutables.
El código se versiona con un commit y un archivo de dependencias. La configuración incluye filtros, zona horaria, normalizaciones y flags. El catálogo identifica qué fuente se intentó consultar y su versión. El snapshot conserva la materia prima necesaria para recalcular.
La cuarta capa es la más difícil. Si una respuesta sólo existió durante la conexión y no fue archivada, meses después puede ser imposible reconstruirla. Un log de “200 OK” no contiene su significado.
Qué aporta la procedencia
W3C PROV define procedencia como información sobre entidades, actividades y personas u organizaciones involucradas en producir un dato. Para una consulta, la respuesta y el reporte son entidades; la llamada y transformación son actividades; el servicio ejecutor y la fuente son agentes.
Un manifiesto sencillo puede registrar esa cadena: entrada X fue obtenida de fuente Y a hora Z, procesada con versión C y produjo salida R. Esto no requiere publicar datos sensibles. Puede usar identificadores internos, conteos y hashes.
La procedencia responde “cómo se produjo”. No garantiza que la fuente fuera completa o correcta, pero permite evaluar esa limitación.
Experimento sintético en dos fechas
Creamos una fuente de laboratorio con 300 registros sintéticos y una respuesta versionada. El día 1, el catálogo v4 consulta el conjunto A y devuelve 42 coincidencias. Guardamos entrada, salida, código, configuración y hashes.
El día 30, la fuente vigente contiene 305 registros y devuelve 45 coincidencias. Al reejecutar contra ella obtenemos 45. Al ejecutar el mismo código contra el snapshot del día 1 volvemos a obtener 42. La primera operación es reejecución; la segunda es reproducción.
Si sólo hubiéramos guardado el número 42, podríamos comparar resultados, pero no verificar por qué surgió. Si sólo guardáramos un hash del snapshot que luego se perdió, sabríamos qué archivo esperar, no podríamos recuperarlo.
El experimento es sintético y no representa una fuente oficial ni actividad de multas.ar.
Hash: prueba de igualdad de bytes
Los algoritmos definidos en FIPS 180-4 producen huellas para mensajes digitales. Si un archivo cambia, su hash cambia con enorme probabilidad. Esto permite verificar que el snapshot disponible es el mismo que se registró.
Para que la comparación sea útil hay que guardar algoritmo, hash, tamaño, formato y regla de serialización. Un JSON con espacios o orden diferente puede tener otra huella aunque contenga datos equivalentes. La normalización debe formar parte del proceso versionado.
El hash no prueba calidad, autoría ni fecha por sí solo. Tampoco anonimiza datos: una huella de un valor de dominio pequeño puede ser atacada por enumeración. No se usa como sustituto automático de protección.
Tiempo: reloj interno y evidencia externa
Registrar una fecha en un log muestra lo que el sistema declaró. Para ciertos usos puede necesitarse evidencia temporal adicional. RFC 3161 describe un protocolo de sellado de tiempo basado en la huella de un dato y una autoridad de sellado.
Un sello verificable puede apoyar que una huella existía en un momento, pero no describe el contenido ni legitima su obtención. También depende de certificados y validación. Para un informe operativo cotidiano, un almacenamiento inmutable y relojes confiables pueden ser suficientes; la necesidad se define por riesgo y propósito.
No conviene agregar una marca de tiempo compleja si luego nadie conserva las claves, políticas o cadena necesarias para verificarla.
Lo que puede quedar no reconstruible
Una pantalla dinámica, un CAPTCHA, una respuesta sin guardar o el orden exacto de resultados de un portal pueden desaparecer. La fuente quizá no ofrece historial ni API versionada. En ese caso, el manifiesto debe decir “respuesta histórica no archivada; no reconstruible”.
Esa declaración es mejor que rellenar el hueco con la respuesta actual. Una captura parcial puede demostrar ciertos campos visibles, pero no toda la carga ni el alcance de la consulta.
Los cambios de catálogo también importan: una URL puede seguir igual mientras la jurisdicción incorporó otra base. Conservar la definición de cobertura de cada versión ayuda a interpretar el resultado antiguo.
Reproducibilidad con privacidad
Guardar todo para siempre no es una política responsable. Antes de archivar una respuesta hay que definir finalidad, acceso, cifrado, retención y eliminación. Si el análisis sólo necesita agregados, puede conservar un snapshot desidentificado o un conjunto sintético de prueba.
Las patentes, DNI, actas y payloads no deben copiarse a repositorios de contenido ni a logs generales. Un manifiesto puede incluir conteos, estados de fuente y hashes de artefactos privados sin exponer los registros.
La prueba de software se separa de la prueba de un caso real. Fixtures sintéticos permiten reproducir transformaciones; evidencia privada y acotada sostiene una investigación autorizada.
Un checklist antes de prometer reproducción
Preguntá si están disponibles la versión de código, dependencias, configuración, catálogo, zona horaria, entrada, salida y esquema. Verificá que los hashes coincidan y que las fuentes externas se hayan reemplazado por snapshots controlados. Documentá cualquier servicio que siga vivo y pueda cambiar.
Si falta una pieza, clasificá el alcance: quizá pueda reproducirse el cálculo pero no la adquisición; verificarse el archivo pero no su fecha; o sólo reejecutarse el flujo actual.
Una conclusión honesta por componente
La reproducibilidad no es un sí o no global. El parser puede ser reproducible, el catálogo versionable y la respuesta histórica inexistente. Informar esa matriz permite saber qué evidencia respalda cada afirmación.
Meses después, el mejor resultado puede ser: “reproducimos la transformación sobre el snapshot conservado; reejecutamos la fuente vigente; no podemos reconstruir la pantalla original”. Esa frase contiene más verdad operativa que asegurar que todo fue “la misma consulta”.
Metodología
- Alcance
- Experimento sintético de dos ejecuciones separadas en el tiempo, distinguiendo artefactos versionados y respuestas externas mutables.
- Unidad de análisis
- Un componente de consulta clasificado como reproducible, reejecutable, verificable por hash o no reconstruible.
- Cobertura
- Modelo de procedencia W3C PROV, estándar de hash NIST y protocolo de sellado de tiempo RFC 3161 revisados el 14 de agosto de 2026.
Limitaciones
- Los ejemplos usan datos sintéticos y no prueban la retención histórica de ningún portal u organismo real.
- Archivar respuestas puede estar limitado por privacidad, términos, seguridad y finalidad; reproducibilidad no justifica conservar datos innecesarios.
Fuentes
- PROV-Overview — World Wide Web Consortium (consultada el )
- FIPS PUB 180-4, Secure Hash Standard — National Institute of Standards and Technology (consultada el )
- RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol — RFC Editor (consultada el )
Preguntas frecuentes
¿Ejecutar hoy la misma consulta reproduce el resultado de hace seis meses?
No necesariamente. Repite el procedimiento contra el estado actual de la fuente. Para reproducir el resultado histórico hace falta conservar la entrada o respuesta que se usó entonces.
¿Un hash demuestra cuándo existía un archivo?
Un hash solo identifica su contenido. Para aportar evidencia temporal hace falta conservar contexto adicional y, si corresponde, un servicio o mecanismo de sellado de tiempo verificable.
¿Conviene guardar todas las respuestas externas completas?
No automáticamente. Deben evaluarse necesidad, autorización, minimización, seguridad y retención. Muchas pruebas pueden conservarse como agregados o manifiestos sin almacenar datos personales innecesarios.
Notas relacionadas
De fuente oficial a resultado: el recorrido de una consulta en multas.ar
Entre ingresar una patente y mostrar un resultado hay decisiones sobre alcance, respuesta de cada fuente, normalización y trazabilidad. Documentarlas evita que un error parezca un cero.
Qué significa “última verificación” en una fuente de multas
La fecha indica cuándo se consultó una fuente y qué respuesta dio en ese momento. No es la fecha del acta, del pago ni una garantía de que no existan novedades en procesamiento.
Consulta repetida o dato nuevo: cómo separamos reintentos de demanda real
Una recarga no representa otro vehículo. Definimos una unidad estadística reproducible para agrupar reintentos sin conservar la patente ni inflar la demanda observada.