Refinery journal / Data in practice
Finding a Data Problem Is Not Proving the Source Correction
A practical framework for separating detection, authorization, source cleanup and proof when operational data is wrong or uncertain.
A wrong value can become an operational failure
An incorrect operational value does more than make a dashboard look untidy. It can cause an application to take the wrong path, make an AI answer unreliable, trigger manual rework or leave the same incident waiting for the next person to discover it. Finding the suspicious value is therefore only the beginning: the important question is whether the authoritative source was changed correctly and whether that change can be demonstrated later.
Consider an illustrative example: a record has status enabled, while an approved rule says the status should be active. A detector can identify the mismatch. A model can propose active. Neither fact proves that the source was authorized to change, that the record still contained enabled when the write occurred, or that the source now contains active. A completed request is not the same as a verified correction.
Use four separate questions before calling data fixed
First, ask whether the problem is supported and evidenced. Define the operational database, tables, fields, relationship and rule in scope. Compare current source values with an approved rule or, where configured, an approved read-only trusted reference. Unknown values, identity conflicts and ambiguous facts should remain visible rather than being replaced with a plausible guess.
Second, ask whether the proposed change has authority. A proposal, chat message or model confidence cannot authorize a write. The exact correction must pass the current policy and authorization path, with human approval where required or certified automation where already permitted. The source-cleanup path is separate from a read-only eligibility check: a gateway request cannot execute a repair.
Third, ask whether the write was safe to apply. A governed repair should check the expected-before value and apply only the bounded change that was authorized. If the source no longer matches the expected value, the operation should stop or escalate rather than overwrite a concurrent change. This excludes arbitrary joins, entity merging, destructive changes and unrestricted cross-database writes.
Fourth, ask whether the result is proven. The authoritative source must be read again after the write. The fresh readback must match the intended value, and a durable receipt must connect the subject, operation, authorization, actor, time and supporting evidence. Without that chain, the strongest honest conclusion may be “proposed,” “blocked” or “unresolved,” not “fixed.”
A practical evaluation checklist
Use this checklist when assessing a data-quality workflow or designing one yourself:
1. Scope: Is there one named operational source, an explicit table and field set, and a supported relationship? 2. Evidence: What rule or approved reference establishes the expected value? 3. Identity: Does exactly one record match the subject? 4. Authority: Who may approve this exact change, and is that authority current? 5. Concurrency: What expected-before value must still be present? 6. Execution: Is the connector and repair type certified for this bounded operation? 7. Verification: Was the authoritative source freshly read after the write? 8. Receipt: Can an independent reviewer correlate the result with the authorized operation? 9. Recurrence: Will the approved scope be checked again, with repeat defects surfaced rather than silently repaired?
The conclusion should change when the evidence changes. A missing or stale freshness signal, multiple identity matches, revoked approval, a changed expected-before value or an absent readback should move the outcome from eligible or proposed to blocked, limited or human review. Conversely, a current source read, a clear supported rule, exact authorization, a successful expected-before check, matching fresh readback and durable receipt support a bounded claim about that specific correction. They do not support a claim that all data is correct.
Clean the source before considering a read path
Source cleanup and downstream data eligibility are different jobs. Refinery is being built to work alongside operational databases: applications can keep their direct database connections while supported problems are inspected and, when released and authorized, corrected at the source. The intended sequence is Connect, Understand, Repair, Prove and Monitor. Cleanup does not require routing every application query through another gateway.
An optional read-only gateway serves a narrower purpose for consumers that use that path. It can check whether data meets declared requirements such as scope, policy and a table-level freshness signal, and can return a limited or blocked outcome when evidence is insufficient. It cannot execute a repair, and a gateway eligibility decision does not prove that a downstream workflow recovered. Source cleanup should therefore be established first; any later read eligibility check should be evaluated as its own outcome with its own evidence.
The important limitation is scope and availability. Refinery is being built, and live database connections, repairs, API and MCP access and purchasing are not publicly released. The current described scope is a supported operational PostgreSQL database, with an optional approved read-only trusted reference in the applicable coverage. Broader connectors, row-level freshness certification, automatic synchronization and unrestricted cross-database work should not be assumed. The browser sample demo is available without credentials or a card, and a no-data fit check or early-access enquiry can explore whether a narrow workflow is suitable.