Proveniencia campo por campo: de dónde salió el monto de un acta
Citar una fuente global no alcanza cuando monto, estado y fecha provienen de observaciones distintas. Cada valor normalizado necesita origen, regla y momento auditables.
Por Marco Ferreiro ·
Una respuesta puede declarar source: portal_oficial y aun así ser imposible de auditar. ¿El monto, el estado y la fecha vinieron de la misma captura? ¿Algún valor fue calculado? ¿Qué ocurrió si dos páginas oficiales discreparon?
La proveniencia campo por campo responde esas preguntas. No agrega una etiqueta decorativa: conserva la observación, la transformación y la regla que respaldaron cada valor publicado de un acta.
Por qué una fuente global es insuficiente
Supongamos que un portal de consulta muestra estado “pendiente” y otro canal oficial del mismo organismo publica un monto actualizado. Una integración puede combinar ambos para ofrecer una respuesta útil. Si sólo guarda una URL global, pierde qué dato vino de dónde.
El problema se vuelve crítico cuando una regla cambia. Sin la observación original no se puede recalcular ni explicar por qué ayer se eligió un importe y hoy otro. Tampoco se distingue una modificación de la fuente de una modificación del normalizador.
La proveniencia debe seguir a cada campo del acta, no quedar únicamente en el encabezado de la respuesta.
Entidad, actividad y agente según PROV
W3C PROV propone tres conceptos centrales:
- entidad: algo sobre lo que existe información, como una respuesta capturada o un valor derivado;
- actividad: proceso que usa o genera entidades, como extracción, conversión o selección;
- agente: actor asociado con esa actividad, como una fuente, servicio o versión del software según el modelado.
PROV-O expresa esas relaciones de manera formal, y el Primer muestra ejemplos más accesibles. No obliga a exponer RDF o JSON-LD en cada respuesta. Puede inspirar un modelo interno más simple mientras se mantengan las relaciones esenciales.
El sobre mínimo de un campo normalizado
Un campo auditable podría conservar esta estructura sintética:
{
"amount": {
"value": 1200,
"source_observation_id": "obs_2",
"observed_at": "2026-08-14T12:00:00Z",
"rule_version": "amount-selection-v3"
}
}
Los valores son inventados y no representan una multa. obs_2 apunta a una observación preservada; rule_version identifica la actividad que eligió o transformó el valor. Si hubo conversión de unidad, redondeo o prioridad entre fuentes, esa regla debe estar documentada.
No es necesario devolver todos los metadatos a todos los clientes. Sí deberían existir en el sistema y ser accesibles según el contrato y los permisos.
Un fixture contradictorio sin datos personales
Probemos un caso ficticio con dos observaciones de la misma acta:
obs_1: estado “pendiente”, monto 1.000, observado a las 10:00;obs_2: estado “pendiente”, monto 1.200, observado a las 12:00;- ambas fuentes son oficiales y publican el mismo identificador de acta sintético;
- la regla vigente prioriza la observación más reciente sólo para el monto;
- la fecha del hecho proviene de
obs_1porqueobs_2no la publica.
La respuesta combina monto de obs_2, estado confirmado por ambas y fecha de obs_1. Una sola etiqueta de jurisdicción no alcanza: cada campo del acta tiene su trayectoria.
La prueba debe verificar que eliminar obs_1 vuelva inexplicable la fecha de la infracción y que cambiar la regla de monto produzca una nueva derivación, sin sobrescribir el resultado anterior.
Cómo modelar una contradicción
No conviene descartar silenciosamente el valor perdedor. Conservá ambas observaciones, marcá la discrepancia y registrá la política aplicada. Algunas alternativas son priorizar la jurisdicción designada, usar el dato más reciente, no publicar el campo o devolver un estado de conflicto.
La elección depende del contrato. Debe ser determinista y versionada. Un ejemplo:
conflict_detected: true;candidate_observations: [obs_1, obs_2];selected_observation: obs_2;selection_reason: newer_observation;rule_version: amount-selection-v3.
Estas claves son ilustrativas. Lo importante es que la decisión sea reproducible y no una edición manual sin rastro.
Valores originales y derivados
El texto original debe conservarse por separado del dato normalizado. Si el portal publica “$ 1.200,00”, el parser puede producir moneda, unidades y valor decimal. Reemplazar el original impide revisar errores de formato.
También debe indicarse cuándo un valor es inferido. Un acta con status = paid no debería derivarse de amount = 0 salvo que el contrato y la jurisdicción lo definan; cero, ausente y pagado son conceptos distintos.
La proveniencia permite mostrar que el estado del acta vino de una etiqueta explícita mientras el monto fue transformado. Esta diferencia mejora soporte y reduce conclusiones falsas.
Versionado y reproducción
Cada actividad de normalización necesita una versión inmutable o un hash de configuración. Si la lógica se actualiza, los resultados nuevos deben indicar la regla nueva. Para auditar una respuesta histórica se ejecuta la versión original sobre las observaciones preservadas, dentro de los límites de retención.
Un registro mínimo contiene:
- instante de captura y zona horaria;
- fuente y endpoint autorizados;
- hash o identificador de la observación;
- parser y versión;
- regla de selección y versión;
- campo generado y relación con sus entradas;
- motivo de ausencia o conflicto.
La respuesta pública puede resumirlo con un identificador de trazabilidad, sin exponer internamente rutas, secretos ni payloads sensibles.
Privacidad, seguridad y retención
Guardar proveniencia no autoriza a duplicar datos personales indefinidamente. Hay que minimizar lo almacenado, definir retención, cifrar evidencias y limitar accesos. Para pruebas de reglas, usá fixtures sintéticos sin patentes, DNI, nombres ni números de acta reales.
Los hashes tampoco vuelven anónimo un identificador de baja entropía. Hashear una patente sin controles adicionales puede permitir intentos de recuperación. La trazabilidad debe diseñarse junto con privacidad, no después.
Si una fuente tiene restricciones de redistribución, puede conservarse una referencia y metadatos permitidos en vez del documento completo, siempre que el modelo siga explicando el origen.
Cómo probar la implementación
Un conjunto de pruebas debería incluir campos ausentes, valores iguales, contradicciones, cambios de regla y observaciones fuera de orden. Cada valor devuelto debe poder recorrer un camino hasta al menos una observación. Cada transformación debe identificar una versión.
También se prueba lo contrario: ninguna observación debe atribuirse a un campo que no respaldó. Si una jurisdicción sólo publicó el monto, no puede aparecer como procedencia de la fecha por comodidad.
Una interfaz de soporte puede reconstruir el grafo de un campo sin mostrar las patentes de otra cuenta. Esa separación de permisos es parte de la calidad del sistema.
Método y límites de esta propuesta
El modelo se basa en PROV-O, el Primer y recomendaciones de acceso a proveniencia, aplicado a un fixture contradictorio sin identificadores reales. JSON-LD demuestra una posible serialización, pero no obliga a adoptar un formato específico.
La propuesta no resuelve cuál fuente debe ganar en todos los casos. Exige algo más fundamental: que la regla elegida quede explícita. Cuando el monto, el estado del acta y la fecha tienen historias distintas, la API debe poder contar cada historia sin inventar una fuente única que nunca existió.
Metodología
- Alcance
- Aplicación del modelo W3C PROV a un fixture sintético donde dos observaciones oficiales discrepan en monto y estado.
- Unidad de análisis
- Un campo normalizado con valor, observación fuente, instante de captura, actividad de transformación y versión de regla.
- Cobertura
- Recomendaciones W3C consultadas el 14 de agosto de 2026; el contrato de ejemplo debe adaptarse a seguridad, retención y necesidades de cada integración.
Limitaciones
- La estructura propuesta no es un estándar oficial de multas ni garantiza interoperabilidad sin un contrato y vocabulario compartidos.
- El ejemplo no usa actas ni identificadores reales y no cubre todas las políticas posibles para resolver contradicciones.
Fuentes
- PROV-O — The PROV Ontology — World Wide Web Consortium (consultada el )
- PROV Model Primer — World Wide Web Consortium (consultada el )
- JSON-LD 1.1 — A JSON-based Serialization for Linked Data — World Wide Web Consortium (consultada el )
- PROV-AQ — Accessing and Querying Provenance — World Wide Web Consortium (consultada el )
Preguntas frecuentes
¿Proveniencia significa guardar toda la respuesta oficial para siempre?
No necesariamente. Debe conservarse evidencia suficiente y autorizada para auditar cada valor, con controles de acceso y retención. Los datos sensibles no deben duplicarse sin una finalidad legítima.
¿Conviene reemplazar el dato original por el normalizado?
No. El original y el valor derivado cumplen funciones diferentes. Guardar ambos permite recalcular con una nueva regla y explicar por qué una transformación cambió.
¿W3C PROV define un contrato obligatorio para APIs de multas?
No. PROV ofrece un modelo general de entidades, actividades y agentes. El esquema JSON de esta nota es un ejemplo de implementación, no un estándar oficial de infracciones.
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.
Cómo versionar una respuesta cuando cada jurisdicción cambia
Una respuesta agregada necesita distinguir versión de contrato, revisión de datos y estado de cada fuente. Así un cambio municipal no obliga a reinterpretar silenciosamente todo el resultado.
Cobertura de una API: cómo comunicar fuentes caídas y resultados parciales
Una integración de infracciones necesita informar qué fuentes respondió, cuáles fallaron y si el resultado es completo. Un cero sin cobertura comprobada puede inducir decisiones incorrectas.