A practical change-review loop for recurring public data

# webdev# automation
A practical change-review loop for recurring public dataNimblique Studio

Every recurring public-data workflow eventually hits the same awkward question: was this difference...

Every recurring public-data workflow eventually hits the same awkward question: was this difference caused by the world changing, by the source changing, or by our own collection process changing?

Treating every difference as an incident creates alert fatigue. Ignoring differences creates quiet downstream errors. A usable workflow needs enough evidence to let a person make the call.

Start with a comparable snapshot

A comparison is only useful when it preserves the context needed to understand it later: when the run happened, which input produced it, the record count, the observed fields, and a stable identifier for the result. That turns “the pipeline looks different” into a reviewable claim.

Separate record changes from schema changes

A value changing and a field disappearing are different failures. The first may be a valid business update. The second often changes the meaning of every record downstream. I treat them as separate queues, with a small sample of affected records rather than a giant raw export.

Reduce noisy duplicates before review

Duplicate entities turn a small issue into a misleading count. Deduplication should be deterministic and explainable: select a key, state the rule, and retain enough provenance to audit why records were merged.

Export evidence where the team reviews it

The point of a scheduled workflow is not to create another private dashboard. A lightweight review packet in a shared sheet, ticket, or webhook destination gets checked more consistently than a new interface people have to remember.

Track source health alongside the payload

A source that returns syntactically valid but incomplete data is different from a source that is unavailable. Capture health signals separately: response status, fetch timing, unexpected empty results, policy changes, and changes in source structure.

Small tools for each control

I build commercial developer tools around those narrow controls, so a team can adopt one without replacing its stack:

The useful test is simple: when a difference appears, can someone explain it, assess its impact, and decide whether to act without rerunning the entire pipeline? If not, improve the evidence before adding another alert.