Refinery journal / Data in practice
When a Read-Only Reference Can Establish a Correct Value
A practical framework for using an approved read-only reference to evaluate conflicting operational data without turning the reference into a second system of record.
A conflicting value can block an operational decision
An operational record can be present, readable and still be unsafe to use. If a workflow sees a customer segment, entitlement or status that conflicts with an approved reference, the immediate consequence may be a delayed decision, manual investigation or an unreliable AI answer. The problem is not merely that two values differ; it is that the workflow has no defensible basis for choosing one.
The first question is therefore not, “Which value looks more plausible?” It is, “Which source is authorized to establish this value for this specific decision?” A read-only reference can provide evidence for that question, but it does not automatically make every disagreement resolvable or authorize a change.
What the reference is allowed to do
An approved read-only reference is a separate trusted source used for bounded checks. In the supported design, one operational PostgreSQL database remains the source being improved, while the reference supplies approved evidence for supported relationships and repair types. The reference is not another operational write target.
That distinction prevents a common failure mode: copying a cleaner value into the operational system simply because it came from a different database. A reference lookup should establish why a value is preferred, not silently synchronize systems, merge entities or create unrestricted cross-database writes.
The reference is useful only when its role has been defined in advance. The owner should specify the decision, the operational record, the reference fields that may be consulted, the relationship connecting them and the rule for resolving agreement, disagreement or missing evidence. If those boundaries are unclear, the correct outcome is uncertainty or human review.
A practical decision framework
1. Define the operational decision. Name the workflow and the exact value it needs. “Improve data quality” is too broad; “determine the approved service tier for this account” is testable.
2. Identify the source roles. Record which database is operational and which source, if any, is an approved read-only reference. Do not treat connectivity as permission to inspect or change every table.
3. Test the relationship. Confirm that the operational record maps to exactly one approved reference record through a supported relationship. Zero matches and multiple matches are evidence of unresolved identity or scope problems, not invitations to guess.
4. Check the reference evidence. Evaluate whether the reference value is in scope, current under the agreed evidence rules and appropriate for this decision. A plausible value without an approved basis is not a correct value.
5. Compare before proposing anything. Preserve the operational value as the expected-before state and show the reference value, relationship and rule that support the proposed result. A proposal or model confidence alone does not prove a correction.
6. Separate cleanup from consumption. If the operational value is wrong and the repair is supported, the source-cleanup path still requires current authorization, an exact governed write, a fresh source readback and a durable receipt. Only after that evidence exists should the change be described as proven.
7. Keep unresolved cases visible. Conflicting identity, unsupported relationships, ambiguous facts or missing reference evidence should remain limited or blocked for review rather than being converted into a confident replacement.
Illustrative example: an approved service tier
Consider an illustrative workflow that prepares an account-management task. The operational PostgreSQL database says an account is on the Standard tier, while an approved read-only reference contains a single matching account with the Premium tier. The difference matters because the workflow may choose different support or entitlement actions.
A safe evaluation would first verify the account relationship, the reference’s approved role and the rule that makes its tier authoritative for this decision. If the match is unique and the evidence meets the agreed requirements, the reference can support a bounded proposal about the operational value. It still cannot write to the operational database or authorize itself.
If the operational value is changed through an authorized supported repair, the proof must come from the operational source: compare the expected-before value, perform the governed exact change, read the source again and retain a durable receipt correlated with the operation. The reference explains the proposed value; it does not replace source readback as evidence of the repair.
If two reference records match, the reference is stale or the account’s authority is unclear, the right result is unresolved. A useful system should expose that limitation instead of selecting the most recent-looking record or presenting a fallback as fact.
Limits and a restrained way to evaluate the idea
This approach does not establish universal correctness. It depends on an approved reference, supported relationships, clear authority and evidence that is appropriate for the decision. It does not provide automatic synchronization, arbitrary joins, entity merging or unrestricted writes across databases. Even a proven correction may recur, so monitoring remains necessary and does not guarantee prevention.
Refinery is being built around this separation: source cleanup comes before any optional read-only gateway check. The gateway, when available, is for consumers using that path to assess data eligibility; it cannot execute a repair. Applications can continue reading their operational databases directly. Product signup, live connections, repairs and API or MCP access are not publicly released.
For now, a useful evaluation is the browser sample demo, which requires no credentials or card. Teams can also request a no-data fit check or register non-binding early interest. Do not send production records, database credentials, model keys or secrets. The practical test is whether one narrow workflow has a clear source role, an approved reference rule and an evidence plan for both the decision and any later source correction.