Refinery journal / Data in practice
Building Refinery: Why the Database Stays in Charge
A lesson from designing Refinery is simple: improving operational data should strengthen the source of truth, not create another competing copy.
The tempting shortcut is another clean copy
When operational data is inconsistent, copying it into a cleaner layer can make one dashboard or model easier to use. It can also create a second place that claims to know the current truth.
That split becomes an operating problem. Applications still use the database, teams correct different copies, and nobody can easily show which value was authoritative when a decision was made.
Our design choice: work alongside the operational database
Refinery is being designed to connect alongside a supported operational database. The owner chooses the tables, fields and relationships that may be inspected. Existing applications can continue their direct reads while Refinery monitors that approved scope.
Where configured, an optional read-only trusted-reference database can help establish the correct value for a supported problem. That does not imply arbitrary joins, automatic synchronization, entity merging or unrestricted writes across connected databases.
A correction needs more than a confident recommendation
A useful repair proposal should show the observed value, the expected value and the evidence that connects them. Policy and authorization decide whether a human must approve the repair or whether a currently authorized certified procedure may act.
After the write, Refinery's design calls for reading the source again, comparing the exact result and retaining a durable receipt. If the evidence is uncertain or the readback does not match, the problem should remain unresolved rather than being described as fixed.
What we are still proving
This is a product direction under active development, not a claim that every connector or repair type already works. Coverage must be explicit: a supported database, approved relationships, supported problem types and bounded authority.
The goal is practical and demanding: reduce repeated manual cleanup while keeping the source system authoritative and making every completed repair reviewable. The sample demo explains the decision model; live connections, repairs, API and MCP access, purchasing and onboarding are not publicly released today.