Refinery journal / Data in practice
When Operational Data Should Stay Unresolved
A practical framework for deciding when a data problem needs evidence or human review instead of an automatic correction that could make the source less trustworthy.
An unresolved value can be safer than a plausible one
An incorrect automatic correction can turn a visible question into an invisible source-of-truth problem. That is especially dangerous when the value affects money, identity, permissions, compliance, or an operational decision. A blocked or unresolved record may create extra work, but it preserves the fact that the available evidence does not justify a change.
Consider an illustrative status mismatch: one record says enabled while an approved rule appears to indicate active. That might be a narrow, well-defined correction, or it might reflect a migration, a stale relationship, or an exception that the rule does not describe. The text of the mismatch alone cannot decide which explanation is true.
The useful question is not whether a model can suggest a replacement. Ask whether an authorized process can establish one exact value, apply one bounded change, and prove the result from the source afterward. If not, leave the record unresolved and make the reason visible.
A decision framework for refusing an automatic fix
First, define the decision and its owner. Name the workflow, the affected field, the permitted scope, and the person or policy that can authorize a source change. A connection or a model response is not authorization, and a plan or confidence score cannot create it.
Second, test whether the defect is supported and bounded. There should be an agreed rule or an approved read-only trusted reference that establishes the expected value. The relationship and repair type must be supported; ambiguous identity, destructive changes, financial ambiguity, and arbitrary cross-database work should leave the repair path.
Third, compare the expected-before value immediately before any write. If the source no longer contains that exact value, stop rather than overwriting a newer change. This check turns a proposed correction into a conditional operation instead of permission to replace whatever happens to be present.
Fourth, require proof after the write. A repair claim needs an exact fresh source readback, a durable receipt, and correlated evidence for the authorized operation. A proposal, an approval message, or a successful request without readback is evidence of intent or execution, not proof of the final source state.
The refusal checklist
Keep the record unresolved when the evidence is stale, missing, conflicting, or tied to more than one possible subject. Do not select the most convenient match merely because it makes the workflow proceed.
Keep the record unresolved when the proposed value comes from a model impression rather than an approved rule or trusted reference. A model can help surface or explain a case, but confidence is not write authority and plausibility is not source evidence.
Keep the record unresolved when the change would merge identities, alter an ambiguous financial fact, perform an unrestricted cross-database write, or bypass the required authorization path. Escalate the case to a named owner with the uncertainty and relevant evidence intact.
Keep the record unresolved when the post-write readback or durable receipt is missing. In that situation, the safe conclusion is that the change is unproven, not that it probably worked. This distinction matters when another process may already have changed the record.
Clean the source before checking downstream eligibility
Source cleanup and data eligibility are different jobs. A source correction changes an approved operational record through a governed path. An optional read-only gateway checks whether data is suitable for consumers using that path; it cannot authorize or execute a repair. Sending a questionable value through an eligibility check does not make the underlying source correct.
The practical order is to inspect the approved scope, establish whether a supported correction is justified, and repair only with the required authority and proof. After that, an eligible consumer may receive a separate read-only decision based on its declared purpose and permitted fields. Applications that keep their direct database reads do not need to reroute every query through the gateway.
One important limitation remains: unresolved does not mean permanently prevented. Monitoring can surface recurrence, but it cannot guarantee that a defect will not return. A table-level freshness signal also does not prove that every individual row is fresh. Preserve that uncertainty in operator views and AI workflows rather than presenting a clean-looking value as universal truth.
Refinery is being built around this distinction: connect alongside the operational database, understand supported problems, repair only under authorization, prove the source result, and monitor the approved scope. The browser sample is available without credentials or a card; live connections, repairs, API/MCP access, and purchasing are not publicly released. An early-access fit check can discuss a narrow workflow without sharing production records.