Refinery journal / Data in practice
A Data-Quality Alert Is Not a Proven Correction
An alert can identify a possible data problem. A proven correction requires authorized action at the source, a fresh readback, and durable evidence of what changed.
The operational problem: knowing about bad data is not the same as fixing it
A team may discover that an operational record has an unexpected status. The alert is useful, but it does not show whether anyone changed the source record, whether the change was authorized, or whether the correction is still present.
This distinction matters when applications continue reading directly from an operational database. A dashboard, report, or proposed fix can describe the intended state without changing the data that other systems rely on.
Illustrative example: enabled to active
Illustrative example, not evidence of a customer repair: a supported workflow identifies a record marked enabled when the approved business rule says it should be active.
An alert might report the mismatch. A proposal might recommend changing enabled to active. Neither is proof of a correction. A correction claim requires an authorized governed write to the source, a comparison with the expected before-state, an exact fresh readback from the source, and a durable receipt linked to the relevant evidence.
If the fresh readback does not match the intended result, the uncertainty should remain visible. Model confidence or an approval by itself is not proof that the source data changed.
What a trustworthy correction record should contain
A useful evidence trail separates the stages of the work: what was observed, what was expected, who or what was authorized to act, what write was attempted, and what the source returned immediately afterward.
The receipt should be durable and correlated with the supporting evidence. This makes it possible to distinguish a detected issue from a governed correction and to review the result later.
Monitoring still has a role after a correction. It can help identify whether the supported problem appears again, but continued monitoring does not guarantee that recurrence will be prevented.
How Refinery is designed to approach this distinction
Refinery is designed around Connect, Understand, Repair, Prove, and Monitor. Its planned scope is specific supported relationship and repair types rather than arbitrary joins, automatic synchronization, entity merging, or unrestricted cross-database writes.
The planned product connects alongside operational databases, so applications can keep reading their databases directly. An optional read-only gateway is secondary: it checks data eligibility only for consumers using that path; it is not the proof that a source correction occurred.
Nothing is publicly released yet for live connections, repairs, signup, API or MCP access, or purchasing. A browser sample demo and early-access enquiry are available without credentials or production records. Organizations considering the approach can use a no-data fit check to discuss whether they have one operational PostgreSQL database, a supported narrow workflow, and a named owner able to authorize scope.