Una estructura de recolección que separa los datos fuente de los snapshots de ejecución

✨ Resumen de GPT-5.5

Registro de cómo separé el evidence fuente, las observations, los datos de referencia, los snapshots de ejecución y los artefactos de entrega al migrar a PostgreSQL unos datos de referencia que no dejaban de cambiar entre JSON, CSV y DuckDB.

Los datos de referencia no dejaban de cambiar entre JSON, CSV y DuckDB

Durante varios días, mientras preparaba el flujo de recolección, revisión, ejecución y entrega de datos, no dejaban de aparecer distintos problemas. Como nunca he aprendido ni manejado DBs de verdad, cambié con frecuencia la forma de guardar los datos, y cada cambio acababa siendo mucho más que una simple sustitución.

Al principio recolectaba los datos en JSON/CSV y usaba DuckDB para verlos. Pero los artefactos de los workers se mezclaron con una estructura en la que el coordinador reconstruía la DB una y otra vez, y no dejaba de cambiar qué era dato fuente y qué era dato de referencia.

También llegué a preparar un plan para construir la DB con MySQL. Pero el problema no era MySQL en sí, sino que varios workers o scripts modificaban directamente los datos de referencia. Con esa estructura, era muy probable que se repitieran los problemas de updates simultáneos, conflictos, ownership y rollback.

Después revisé otras alternativas, pero el problema central seguía siendo el mismo. Si los límites entre los datos recolectados, los datos de referencia, los datos de ejecución y los artefactos de entrega son borrosos, al final vuelve a aparecer el mismo problema.

Lo esencial no era el motor de base de datos, sino la responsabilidad sobre las mutaciones

Pasar a PostgreSQL no iba a resolver el problema por sí solo. Antes de decidir qué DB usar, tenía que establecer quién podía modificar los datos de referencia.

Los workers dejan el evidence fuente y las observations en modo append-only. No modifican directamente los datos de referencia. El coordinador revisa el evidence y las observations y, solo después, actualiza los datos y valores de referencia. Al concentrar en un solo lugar la responsabilidad de modificar los datos de referencia, también podía rastrear qué había que revertir cuando surgía un conflicto.

Separé los roles dentro de PostgreSQL

Así que hoy, al migrar a PostgreSQL, también ordené el flujo completo que llevaba varios días preparando. En vez de tratarlo todo como un único bloque de DB, separé los roles.

• Evidence fuente
  • Guarda las pruebas y los valores originales recolectados de fuentes públicas
  • Los valores procesados y sus estados se registran en un historial separado, sin sobrescribir el origen
  • Los archivos JSON/CSV pueden ser un mirror del evidence, pero no son los datos de referencia
• Observation
  • Cada worker solo envía las observaciones de su canal de recolección a un ledger append-only
  • La búsqueda y el enriquecimiento se dividen en roles distintos
  • Los workers no modifican directamente los datos de referencia
• Datos de referencia
  • El coordinador revisa el evidence y las observations
  • Solo los valores revisados se incorporan a los datos de referencia según una estructura definida
  • Las views se usan como superficies para cálculo, revisión y exportación
• Snapshot de ejecución
  • Una view de recolección no se usa directamente como base de una ejecución real
  • Los targets que superan la deduplicación y los quality gates se fijan en un snapshot de un momento concreto
  • Los resultados de ejecución y los estados de exclusión o seguimiento se gestionan por separado de los datos de referencia
• Artefactos de entrega
  • Los archivos para CSV, Google Sheet, Excel o vox.ai se generan desde los datos de referencia o el snapshot de ejecución
  • Son artefactos destinados a visualización o entrega
  • Los artefactos no se vuelven a modificar como si fueran datos de referencia

Pude rastrear desde el evidence hasta la ejecución y la entrega

Así quedó completo un flujo en el que puedo rastrear dónde se acumula el evidence recolectado, qué deja cada worker, qué valor se convierte en referencia, qué snapshot se usa en la ejecución real y qué termina siendo un artefacto de entrega.

Claro que sigue siendo una estructura con muchas carencias, así que habrá mucho más que tocar. Seguiré probando, recibiendo feedback y corrigiendo, y seguramente habrá todo tipo de cambios grandes. Así irán mejorando el flujo, la estructura del harness y también mi intuición.

Lo comparto por si la forma en que preparé este flujo puede ayudar a alguien.