Automated Data Revision & Recovery

I redesigned and refactored the legacy revision mechanism around four questions: where source and target disagree, which hourly partitions are affected, whether the required input is ready, and how quickly repairs should start.

I also connected the targeted rebuild to source verification. The surrounding producers and datasets remain shared platform work, and rerun safety still depends on the selected scope, input, output-commit behavior, and concurrency conditions of the particular repair.

The workflow compares source and destination state, identifies affected hourly partitions, waits for input readiness, controls revision start rate, and invokes a targeted rebuild. Source verification closes the loop, so a successful command is not mistaken for recovered data.

The state transition is explicit: discrepancy → hourly scope → ready input → targeted rebuild → source verification. Each handoff gives an operator a place to inspect the plan or stop before a write starts.

A fixed delay can make an hourly job appear stable until an upstream producer writes late data. I chose an input-readiness gate tied to the producer state, rather than treating elapsed time or a broad replay as proof that an hour was safe to rebuild.

The plan uses reconciliation, hourly scope, readiness, and a controlled start rate. It does not claim a global concurrency limit or universal idempotence: safe reruns depend on the specific input, output commit, and execution conditions, so the repaired slice is checked against its source.

The interface keeps comparison, hourly selection, input readiness, rebuild, and source verification separate. If the discrepancy cannot be localized or the input is still arriving, the plan stops instead of broadening the blast radius.

After a targeted rebuild, the source check must show that the selected gap is gone. A completed job alone is not a recovery result, and an unresolved difference remains visible for further investigation.