Refinery journal / Data in practice
What an Evidence-Backed Data Repair Proposal Should Show Its Owner
A practical framework for reviewing a proposed source correction before approval, including scope, evidence, expected values, authority, uncertainty and the proof required afterwards.
A plausible correction can still create an operational incident
When a bad value reaches an operational workflow, the tempting response is to replace it quickly. That can be worse than leaving the record visibly unresolved if nobody can explain why the replacement is correct, which source was authoritative, or what permission allowed the change.
An owner should therefore review a repair proposal as a bounded decision, not as a recommendation from a confident model. The proposal must make the subject, field, current value, proposed value, reason and evidence understandable before anyone authorizes a source change.
The following is an illustrative review pattern, not a customer result or a claim that a particular repair has been released. It is intended for a narrow supported workflow where the operational database remains the source of truth.
The proposal packet: six questions to answer
1. What exact record and field are in scope? Identify the source database, table, relationship, record identity and field. A broad instruction such as “clean customer data” is not an approval boundary. The owner should be able to point to one bounded subject and one exact change.
2. What is the expected-before value? Show the value currently present at the source when the proposal was prepared. This matters because an approval should not silently apply to a record that changed while the proposal was being reviewed.
3. What value is proposed, and why? State the replacement exactly, along with the rule, approved relationship or configured read-only trusted reference that supports it. A model’s confidence score can help prioritize review, but it cannot establish authority or prove correctness.
4. What evidence could disprove the proposal? List conflicting records, missing values, stale signals, ambiguous identity matches and policy exceptions. If the evidence is incomplete, the proposal should say unresolved or require human review rather than presenting a plausible value as fact.
5. Who may authorize this exact change? Approval must be tied to the proposed operation and current policy. A chat message, a plan level or a generic “looks good” does not grant write authority. Supported certified automation, where available, must still operate within its current authorization.
6. What will count as proof afterwards? Define the fresh source read, the expected result and the durable receipt before execution. A completed request or successful write response is not enough to call the record fixed.
A practical owner review test
First, remove the proposed value from the packet and ask whether the evidence still identifies a single outcome. If several values remain plausible, the proposal is not ready for approval. The right result may be escalation, not an automated correction.
Next, compare the proposal with the source immediately before any governed write. The operation should proceed only when the source still contains the exact expected-before value. If it does not, the proposal is stale and should stop or return for review.
Then check the boundaries: is the database supported, is the record within the approved scope, is the relationship supported, and is the change type allowed? A connection does not authorize every table or operation. Arbitrary joins, identity merges and unrestricted cross-database writes should not be smuggled into a narrow repair request.
Finally, require an exact fresh read from the authoritative source and a durable, correlated receipt. The receipt should connect the subject, field, authorized operation, before value, result, actor or execution path and time. If the readback or receipt is missing, the owner should not use the word fixed.
Source cleanup comes before optional eligibility checks
A source repair and a data-eligibility decision solve different problems. The first changes a supported value in the operational database under governed authority. The second, through an optional read-only gateway, checks whether data is suitable for a consumer using that path. The gateway cannot execute a repair, and it does not make an unproven source value correct.
That ordering matters for AI builders. If the operational record is wrong, filtering one request may hide the symptom while the same value continues to affect applications, reports or later decisions. Where a supported correction is justified, the source should be cleaned and the result proven first. Consumers can then perform their own purpose-bound eligibility check when they use the optional gateway path.
The important limitation is that a source correction does not guarantee permanent prevention. Monitoring can surface recurrence, uncertainty or a returned defect, but it cannot establish that every future record is correct. Unresolved cases should remain visible, and the owner should decide whether the workflow is safe to continue.
What would change the owner’s decision
Approve only when the scope is exact, the evidence supports one bounded outcome, the expected-before value still matches, current authorization covers the operation and the post-change proof has been defined. If any of those conditions is absent, pause, narrow the request or assign it to a named human owner.
Evidence that should change the conclusion includes a conflicting approved reference, multiple possible identities, a changed source value, an unknown or stale freshness signal, an unsupported relationship or a repair type outside current certification. These are not inconveniences to hide; they are reasons to block or escalate.
Refinery is being built around this distinction: connect alongside the operational database, understand the supported problem, propose a governed repair, prove the source result and monitor the approved scope. The browser sample is available without credentials or a card. Live connections, repairs, API/MCP access and purchasing are not publicly released; interested teams can use the fit-check or early-access route without sending production records or secrets.