Cuando corregimos una estadística: cómo versionamos el cambio
Corregir un porcentaje no debería borrar el anterior. Un registro con muestra, consulta, motivo, impacto y hashes permite ver qué cambió y si la conclusión todavía se sostiene.
Por Marco Ferreiro ·
Una estadística corregida no debería aparecer como si siempre hubiera tenido el nuevo valor. La cifra anterior formó parte de una publicación, pudo orientar decisiones y merece quedar asociada a la razón de su reemplazo. Editarla sin rastro impide distinguir una mejora metodológica de un error de carga o de un cambio real en los datos.
La política de revisión de INDEC ofrece una idea útil: las revisiones forman parte del proceso estadístico y deben seguir procedimientos transparentes. En un producto de consultas vehiculares, esa transparencia se traduce en versiones pequeñas y verificables: qué se publicó, qué cambió, con qué evidencia y qué ocurrió con la conclusión.
La unidad de corrección es una versión
Una versión no es sólo un porcentaje. Incluye el período observado, la población elegible, las exclusiones, el numerador, el denominador, la consulta o programa que produjo el agregado y los artefactos de entrada. Si cualquiera de esos componentes cambia, existe una nueva versión.
La publicación original se conserva como “reemplazada”, no se presenta como vigente. La nueva versión la enlaza y explica el motivo. Esto permite reconstruir el recorrido sin obligar a que dos resultados contradictorios parezcan simultáneamente actuales.
También conviene separar la fecha del período. Una estadística de abril a junio puede publicarse en julio y corregirse en agosto. Cambiar la fecha de publicación por la de corrección borraría esa secuencia.
Un changelog mínimo pero suficiente
Cada entrada debería guardar:
- identificador y fecha de versión;
- cifra anterior y cifra nueva;
- numerador y denominador de ambas;
- período y filtros aplicados;
- causa clasificada de la corrección;
- versión de la consulta o código;
- hashes de snapshots y salidas;
- responsable del cambio;
- impacto editorial.
La causa puede ser “registro tardío”, “exclusión mal aplicada”, “duplicado detectado”, “definición revisada” o “error de transcripción”. Una frase concreta es más útil que “ajuste metodológico”, que puede abarcar demasiadas cosas.
Ejemplo sintético con más de cien casos
Imaginemos una muestra ficticia de 12.400 consultas completas. La versión 1 informa 3.224 sesiones con al menos una infracción: 26,00%. Después se descubre que 180 sesiones de prueba estaban incluidas en el denominador y 10 también en el numerador.
La versión 2 excluye esas sesiones: numerador 3.214, denominador 12.220, resultado 26,30%. El changelog registra ambos cálculos, la regla de exclusión, el identificador de la consulta corregida y los hashes de los archivos sintéticos.
La diferencia es 0,30 puntos porcentuales. Si el texto decía “aproximadamente una de cada cuatro consultas”, la conclusión general puede sostenerse. Si afirmaba que el valor estaba por debajo de 26,1%, debe corregirse. El registro explica ambas decisiones.
Los números son ilustrativos y no describen actividad de multas.ar. Su tamaño evita confundir el ejemplo con una celda pequeña, pero no lo transforma en un dato propio.
Corregir no siempre significa que hubo un error
Una revisión puede incorporar información que llegó después del primer corte. También puede aplicar una definición mejor documentada o recalcular una serie con una metodología actualizada. La etiqueta debe distinguir estas causas de un fallo de programación.
Esa diferencia importa para interpretar estabilidad. Si una fuente externa entrega registros tardíos, la versión inicial puede haber sido correcta según su corte. Si la consulta omitía una exclusión ya declarada, existía un error de implementación. Ambos cambian el número, pero requieren acciones preventivas distintas.
El hash verifica integridad, no significado
Un hash criptográfico permite comprobar si dos archivos tienen exactamente los mismos bytes. FIPS 180-4 documenta algoritmos de hash seguros usados para ese propósito. Guardar el algoritmo y el valor ayuda a detectar modificaciones accidentales o sustituciones.
Pero el hash no explica qué columnas contiene un archivo, no demuestra que la fuente sea correcta y no permite recrear un snapshot perdido. Para reproducir el cálculo hay que conservar el artefacto, su esquema, la consulta, los parámetros y el entorno. El hash es una pieza de la cadena de evidencia.
También debe calcularse después de ordenar y serializar de forma determinista. Dos archivos equivalentes con filas en distinto orden producirán huellas diferentes aunque representen el mismo conjunto.
Procedencia: entidades, actividades y responsables
W3C PROV propone describir entidades, actividades y agentes involucrados en producir un dato. En un changelog, el snapshot y el resultado son entidades; la consulta y el proceso de agregación son actividades; el sistema o responsable que ejecutó la revisión es un agente.
No hace falta publicar una ontología completa para aprovechar la idea. Un manifiesto legible puede enlazar cada salida con sus entradas y proceso. Lo importante es evitar un porcentaje huérfano, sin forma de saber de dónde salió.
Qué debe ver el lector
La nota corregida necesita una advertencia visible cerca del dato, con fecha y resumen. Un enlace debe llevar al detalle de la corrección. Si el cambio altera título, gráfico o conclusión, esos elementos deben actualizarse y el changelog debe mencionarlo.
No conviene obligar al lector a comparar dos JSON. Una tabla breve puede mostrar antes, después y diferencia. La documentación técnica queda disponible para auditoría, pero la explicación editorial debe responder en lenguaje común por qué importa.
Umbrales y celdas pequeñas
La corrección no habilita a publicar segmentos que no superan el umbral de privacidad. Si una nueva exclusión reduce una celda a menos de 100 casos, esa celda se suprime en todas las vistas públicas, aunque antes haya aparecido por error. El changelog puede declarar la supresión sin exponer su valor exacto.
Los agregados tampoco deben permitir reconstruir patentes o personas mediante cruces. El historial de versiones conserva métricas agregadas y artefactos privados; no publica microdatos.
Una corrección termina con una prueba nueva
Después de recalcular, hay que ejecutar verificaciones independientes: que numerador no supere denominador, que las exclusiones sean mutuamente coherentes, que el período no cambie por accidente y que tablas, textos y gráficos coincidan. También conviene reproducir la versión anterior con sus propios artefactos.
La corrección está completa cuando otra persona puede explicar el cambio sin depender de memoria oral. La cifra nueva puede ser más precisa, pero su valor editorial proviene de una historia verificable. Versionar esa historia convierte el error o la revisión en información útil, en lugar de esconderlo.
Metodología
- Alcance
- Esquema reproducible para corregir estadísticas agregadas de consultas sin reemplazar silenciosamente la publicación anterior.
- Unidad de análisis
- Una versión estadística con período, población elegible, exclusiones, numerador, denominador, consulta y artefactos hasheados.
- Cobertura
- Políticas oficiales de revisión estadística, procedencia de datos y estándares de hash consultados el 14 de agosto de 2026.
Limitaciones
- El ejemplo numérico es sintético y no representa consultas reales ni el parque automotor argentino.
- Un registro de cambios mejora la trazabilidad, pero no compensa datos fuente incompletos ni vuelve reproducible una respuesta externa no archivada.
Fuentes
- Balanza de pagos, posición de inversión internacional y deuda externa. Metodología INDEC N.º 23 — Instituto Nacional de Estadística y Censos (consultada el )
- Metodologías — Instituto Nacional de Estadística y Censos (consultada el )
- FIPS PUB 180-4, Secure Hash Standard — National Institute of Standards and Technology (consultada el )
- PROV-Overview — World Wide Web Consortium (consultada el )
Preguntas frecuentes
¿Corregir una cifra obliga a borrar la versión anterior?
No. Conviene conservarla como versión histórica, marcar que fue reemplazada y enlazar la corrección. Así puede reconstruirse qué vieron los lectores y por qué cambió el resultado.
¿Un hash permite reconstruir los datos originales?
No. Sirve para comparar la integridad de un archivo que ya se posee. Para reproducir el cálculo también hacen falta snapshot, definición de campos, consulta versionada, parámetros y entorno.
¿Cuándo una corrección cambia la conclusión editorial?
Cuando altera el sentido o la magnitud relevante del hallazgo, cruza un umbral publicado o invalida una comparación. Ese efecto debe explicarse aparte del cambio numérico.
Notas relacionadas
Cómo definimos una consulta completa antes de publicar estadísticas de multas.ar
Antes de convertir consultas operativas en porcentajes o rankings, exigimos cobertura identificable, respuestas comparables y controles que separen un resultado válido de un fallo técnico.
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.
Qué fecha de la UF corresponde a un monto y cómo auditarla
Fecha del hecho, vigencia de la resolución y momento de conversión no siempre coinciden. Para revisar un monto hay que reconstruir la versión de UF que declara la fuente.