Refinery journal / Data in practice
Five Questions to Ask Before Automating a Data Correction
A practical framework for deciding whether a data correction has enough scope, evidence, authority and verification to be automated without hiding uncertainty.
The operational consequence comes first
An incorrect operational value rarely stays in one place. It can trigger manual investigation, produce an unreliable AI answer, or cause a workflow to take the wrong next step. Automating the correction may reduce repetitive work, but it can also make an unsupported assumption repeat faster and with less visibility.
The useful question is not simply whether a model can suggest a replacement value. It is whether the organization can define the defect, justify one exact change, authorize it, verify the source afterward and preserve enough evidence to explain the result later. If any link is missing, automation should stop or remain a proposal.
Questions one and two: define the problem and the authority
1. What exact defect are you automating? Name the source database, table, field, record identity, current value and rule that makes the value invalid. “The status looks wrong” is not a repair definition. A bounded example might be an enabled status that conflicts with an approved rule requiring active; this is illustrative, not evidence of a customer repair.
2. What evidence establishes the replacement value? A model’s confidence, a similar record or a request in chat is not enough. Use an approved deterministic rule or, where supported, an approved read-only trusted reference. If the evidence is stale, conflicting, ambiguous or unavailable, the correct result may be an unresolved record rather than a guessed value.
Questions three and four: constrain the action and protect the source
3. Who or what is authorized to make this exact change? Approval must apply to the specific record, field, expected-before value and proposed replacement. A plan, connection or model verdict does not grant write authority. Governed automation can operate only within current policy, certification and exact authorization; otherwise the case should wait for a named owner.
4. Does the correction happen at the authoritative source before any eligibility check? A downstream patch can hide the defect while the operational record continues to create work. Source cleanup should be a separate governed action. An optional read-only gateway can check eligibility for consumers using that path, but it cannot execute a repair, and direct application reads do not need to be rerouted through it.
Question five: what will prove that it worked?
5. Can you compare the expected-before value with an exact fresh source readback? A completed write request is not proof that the intended value now exists. A defensible repair record should connect the authorized operation to the subject, old value, new value, fresh source result, time and durable receipt.
Run a small pre-automation test using those fields. First, create a proposal without changing data. Then ask an owner to review whether the evidence supports one bounded value. Next, test an expected-before mismatch and an uncertain case. The safe result is an abort or escalation, not a plausible replacement. Finally, confirm that the source readback and receipt are available to an operator who was not present for the change.
The limitation: a proven correction is not permanent prevention
Even a fully verified source correction can be followed by the same defect returning. Other workflows may write the value, the underlying rule may change, or new evidence may reveal a different interpretation. Continued monitoring can surface recurrence, but it does not guarantee that recurrence will never happen.
Refinery is being built around this bounded sequence: connect to an approved scope, understand the evidence, repair only supported problems under authorization, prove the source result and monitor what comes back. The browser sample is available without credentials or a card. Live connections, repairs, API or MCP access and purchasing are not publicly released; teams can use the sample or make a no-data early-access enquiry to assess fit.