Comparar dos fuentes para el mismo dominio

Una integración que consulta dos fuentes para el mismo dominio rara vez recibe dos respuestas idénticas. Aparece un acta en una y no en la otra, los montos no coinciden, los estados se llaman distinto. La reacción habitual es preguntar cuál tiene razón, y casi siempre es la pregunta equivocada.

Una comparación pareada no busca un ganador: busca decidir si cada diferencia es explicable. Es un procedimiento con condiciones previas, una normalización declarada y una clasificación del resultado. Sin esas tres cosas, el diff termina midiendo el ruido de nuestro propio conversor.

Qué hace comparables dos respuestas

La primera condición es temporal. Dos capturas separadas por horas no comparan fuentes: comparan momentos. Cada respuesta se guarda con el instante en que se obtuvo y con su relación explícita con UTC, que es lo que RFC 3339 exige de toda marca de tiempo de internet. Una hora local sin esa referencia no se puede ordenar contra la de la otra fuente.

La segunda es de alcance. Sólo tiene sentido comparar el subconjunto que ambas fuentes declaran cubrir. Que un acta municipal no aparezca en una fuente que nunca dijo alcanzar ese organismo no es un error, es cobertura declarada. Comparar fuera del solapamiento produce diferencias que no informan nada.

La tercera es el estado de cada consulta. Una fuente que devolvió error o venció por tiempo aporta “no consultada”, no “sin resultados”. Mezclar ambas cosas transforma una caída de disponibilidad en una diferencia de datos.

Normalizar antes de restar

Comparar los cuerpos crudos genera falsos positivos: orden de claves, espacios, mayúsculas, ceros a la izquierda, acentos compuestos de dos maneras distintas. El anexo 15 del estándar Unicode define las formas de normalización para eso: dos cadenas equivalentes tienen una única representación binaria recién cuando pasan por la misma forma.

Para la estructura sirve una forma canónica. RFC 8785 ordena las propiedades de manera recursiva para que dos documentos equivalentes produzcan los mismos bytes, lo que permite hashear cada captura y comparar sin que el orden de las claves cuente como cambio.

Ese mismo RFC deja dos advertencias. La canonicalización preserva las cadenas tal como llegaron y no las normaliza, así que el paso de Unicode es previo y separado. Y los números se serializan con precisión de flotante de doble precisión, por lo que recomienda transportar como cadenas los valores que necesitan más; en montos, ignorarlo genera diferencias que introdujo nuestro conversor y parecen discrepancias entre fuentes.

Normalizar es para comparar, no para reemplazar: la captura original se conserva. Los criterios para decidir si dos registros describen el mismo hecho son un paso anterior y están en la misma acta en dos fuentes.

Tres planos y una clasificación

La comparación se lee en tres planos: el conjunto, es decir qué registros aparecen sólo en una fuente, sólo en la otra o en las dos; el campo, para los pares ya emparejados; y la consulta, con lo que cada fuente dijo sobre su propia completitud.

Con eso, cada diferencia se clasifica antes de escalarla:

• desfasaje: una fuente publicó el cambio antes que la otra;
• alcance: el registro queda fuera de lo que esa fuente cubre;
• vocabulario: el mismo hecho con estados nombrados de otro modo;
• normalización propia: la diferencia la introdujo nuestro conversor;
• contradicción: mismos campos, misma ventana, valores incompatibles.

Sólo la última merece escalarse. Una forma barata de separar la primera de la última es repetir la comparación en una segunda ventana: si la diferencia desaparece sola, era desfasaje.

Qué queda registrado

Una diferencia sirve la segunda vez sólo si quedó registrada la primera. Cada una guarda de qué dos observaciones salió, con qué versión de reglas se normalizó, en qué ventana se corrió y en qué clase quedó. Eso vuelve comparable la corrida siguiente con la anterior, y convierte el “esto ya lo vimos” en un dato y no en un recuerdo.

Es el modelo de proveniencia de W3C —qué cosa, producida por qué proceso, bajo la responsabilidad de quién— aplicado a la comparación misma y no al valor que se publica. PROV-O lo expresa formalmente, aunque no hace falta publicar RDF para adoptar la idea; cómo se lleva campo por campo lo tratamos en proveniencia campo por campo.

El registro tampoco necesita el dominio en claro: identificadores internos y hashes de la captura canónica alcanzan para reproducir el caso, según el criterio que describimos en cómo guardar evidencia.

Qué decide una comparación

El resultado útil no es “la fuente A es mejor”. Una puede ser más rápida en el estado y la otra más completa en el detalle del acta; la política puede elegir distinto campo por campo, siempre que la regla esté escrita y versionada.

Antes de convertir una comparación en decisión, verificá cuatro cosas: que las dos capturas caigan en la misma ventana; que el alcance declarado se solape; que la normalización sea reversible y esté versionada; y que la diferencia se reproduzca en una segunda corrida.

Una diferencia que se repite deja de ser un hallazgo y pasa a ser un monitor. Una que no se reproduce era ruido, y conviene dejarlo escrito para no volver a investigar lo mismo el mes que viene.

Metodología

Alcance

Procedimiento de comparación entre dos fuentes que responden por el mismo dominio dentro de una integración - condiciones previas, normalización, planos de lectura y clasificación de diferencias. No evalúa proveedores concretos ni recomienda cuál contratar.

Unidad de análisis

Un par de capturas del mismo dominio, tomadas dentro de una misma ventana temporal y normalizadas con la misma versión de reglas.

Cobertura

Criterios técnicos derivados de RFC 3339 para marcas de tiempo con desplazamiento, RFC 8785 para la forma canónica de JSON, el anexo de normalización de Unicode para comparación de texto y el modelo PROV para el registro de proveniencia.

Limitaciones

• La nota no fija intervalos de repetición ni umbrales - dependen de la frecuencia de actualización de cada fuente y de la tolerancia del proceso que consume el resultado.
• Una comparación describe lo que dos fuentes publicaron en una ventana; no determina cuál refleja el expediente que conserva la autoridad competente.
• Los criterios de identidad para decidir si dos registros son el mismo hecho son un paso previo y se tratan por separado.

Fuentes

• RFC 3339 — Date and Time on the Internet — RFC Editor (consultada el 2026-08-29)
• RFC 8785 JSON Canonicalization Scheme — RFC Editor (consultada el 2026-08-29)
• Unicode Standard Annex #15: Normalization Forms — Unicode Consortium (consultada el 2026-08-29)
• PROV-O — The PROV Ontology — World Wide Web Consortium (consultada el 2026-08-29)

Preguntas frecuentes

¿Una diferencia entre dos fuentes significa que una está equivocada?

No necesariamente. Puede tratarse de desfasaje temporal, de alcance distinto o de vocabularios que nombran el mismo estado de otra forma. Recién cuando los mismos campos se contradicen dentro de la misma ventana y del alcance común hay una discrepancia para escalar.

¿Alcanza con comparar los dos JSON tal como llegaron?

No. El orden de las claves, los espacios y las formas alternativas de una misma cadena acentuada producen diferencias que no existen. Hacen falta dos pasos distintos. Uno normaliza el texto según las formas que define Unicode; el otro serializa en la forma canónica de RFC 8785, que ordena la estructura pero preserva las cadenas tal como llegaron.

¿Qué monto se publica si las dos fuentes muestran valores distintos?

La comparación no elige por sí sola. Se conserva cada valor con su fuente y su momento de observación, y la política de selección se documenta y se versiona campo por campo, para poder explicar después por qué se publicó ese número.

¿Sirve comparar contra una fuente que respondió con error?

No como diferencia de datos. Una consulta fallida o vencida por tiempo aporta el estado “no consultada”, no “sin resultados”. Confundirlas convierte una caída de disponibilidad en una discrepancia inexistente.

Notas relacionadas