Refinery journal / Data in practice
Keep Direct Database Reads While Improving Operational Data
A practical framework for improving data at its source without forcing every application read through a new gateway or replacing the operational database.
The operational consequence of replacing every read
When a team introduces a data-quality tool, it may be tempted to route application queries through that tool immediately. That creates a second operational dependency before the underlying data problem is understood. Existing services may need new connection paths, failure handling, permissions and latency assumptions, while the original database still contains the value that needs attention.
An alternative is to improve the source alongside the applications that already use it. In this model, applications keep their direct database reads, while the data-improvement process inspects an approved scope and, for supported cases, follows a separately governed path to the authoritative record. This reduces the architectural change required to begin a focused investigation; it does not remove the need for careful authorization or verification.
Illustrative example: a service reads an account field directly from its operational PostgreSQL database. A separate data workflow checks that field against an approved rule, identifies an inconsistency and records the evidence for review. The service does not need to change its read path merely because the source-data workflow is being evaluated. The example describes an approach, not a released Refinery connection or customer outcome.
A decision framework for choosing the read path
Start by asking what outcome the workflow needs. If the goal is to improve the authoritative record, source cleanup comes first: define the approved tables, fields and relationships, identify the evidence for a supported problem, and determine who may authorize a source change. A cleaner downstream copy or a transformed response is not equivalent to correcting the source.
Next, separate ordinary application reads from optional eligibility checks. Applications can continue reading their databases directly. An optional read-only gateway is a different path for consumers that use it; it checks whether data is eligible for that declared use. It does not automatically govern direct application reads, and a gateway read cannot execute a repair.
Use this sequence when assessing a proposed architecture: preserve the current read path where it is working; establish the source scope and evidence; repair only through the required governed authority; read the source again; then decide whether a particular consumer needs an additional eligibility check. This keeps source correction, data eligibility and downstream workflow recovery as separate claims with separate evidence.
A plan, model verdict or successful request is not proof that the source is correct. A repair claim requires an authorized governed write, an expected-before comparison, an exact fresh source readback, a durable receipt and correlated evidence. If those conditions are not met, describe the result as a proposal, an unresolved issue or a limited eligibility decision rather than a completed correction.
A practical checklist before adding a gateway
1. Name the source of truth. Identify the operational database that owns the record and confirm that the proposed workflow is intended to improve that source rather than create a competing copy.
2. Limit the inspection scope. Record the approved database, tables, fields and supported relationships. A connection alone does not grant permission to inspect or change every table.
3. Define the evidence. State the rule, reference or comparison that can establish the expected value. An approved read-only trusted reference may help with supported exact lookups, but it is evidence, not another operational write target.
4. Separate authorities. Confirm that read-only inspection, optional consumer eligibility and source repair are distinct paths. Access to a gateway must not become implicit permission to write.
5. Specify the proof. Require the expected-before value, exact source readback and durable receipt before calling a source change fixed. Keep uncertain or conflicted records visible instead of silently selecting a replacement value.
6. Check the application impact. Even when applications keep their direct reads, source changes can affect their behavior. Test the supported workflow, document the owner and decide what should happen if evidence is stale, ambiguous or missing.
The important limitation and what would change the decision
Keeping direct reads is not a promise that every workflow is safe without an eligibility layer. A consumer that needs purpose-bound checks may benefit from the optional read-only gateway, but only when it uses that path. The gateway can assess approved scope and evidence for that request; it does not certify every row as fresh, authorize a repair or prove that a downstream process recovered.
The source-first approach also has a bounded scope. Refinery is being built around supported problems, relationships and repair types, initially centred on one operational PostgreSQL database, with an approved read-only trusted reference available for some planned scope. It does not promise arbitrary joins, automatic synchronization, entity merging or unrestricted cross-database writes.
The conclusion should change when direct reads cannot meet the consumer's declared requirements, when the source is too stale or ambiguous for the decision, or when the workflow needs evidence that the current path cannot provide. In those cases, block or limit the use, involve the named owner and investigate the narrowest supported alternative rather than hiding uncertainty behind a new read layer.
Refinery's browser sample is available for understanding the intended journey without credentials or production data. Live connections, repairs, API and MCP access, signup and purchasing are not publicly released. An early-access or fit-check conversation can explore whether a narrow source-data problem fits, without requesting secrets, credentials or production records.