Refinery journal / Data in practice

The Hidden Cost of Fixing Data Everywhere Except the Source

Teams often patch bad data in reports, exports and prompts. The visible error disappears while the source record keeps creating the same operational cost.

Connect→Understand→Repair→Prove→Monitor
Supported scope. Required authorization. Proof at the source.

One bad value can create five different fixes

A wrong value in an operational database rarely stays in one place. It reaches a dashboard, an export, a support view and an AI prompt. Each consumer can add a workaround, but every workaround creates another rule to maintain.

The source record remains authoritative. The next consumer that does not know about the workaround still receives the problem, and teams lose time debating which copy is trustworthy.

Illustrative example: the customer status that changes by screen

Illustrative example, not a customer result: an account is stored as enabled in one approved table while the supported business rule expects active. A reporting query translates the value, a spreadsheet replaces it again, and a support agent learns to ignore the original field.

The report may look correct, yet the database still says enabled. A new application or AI assistant reading the source can make a different decision because it never sees the downstream patches.

A source-first test for any data correction

Before adding another patch, ask four questions: which source record is authoritative, what evidence supports the intended value, who is allowed to approve the change, and how will a fresh source read prove the exact result?

If any answer is missing, keep the problem visible. A plausible replacement value is still only a proposal. Identity conflicts, unsupported repair types and ambiguous facts should stay unresolved until the evidence and authority are adequate.

How Refinery is being designed around the source

Refinery is being built to connect alongside an operational database, inspect an approved scope and propose supported repairs. Customer applications can keep their direct database reads. A repair executes only through the required policy and authorization, followed by a fresh readback and durable receipt.

The planned optional read-only gateway comes later in the story. It can check whether data meets a consumer's declared requirements, but only for applications and AI using that path. Live connections, repairs, API and MCP access, purchasing and onboarding are not publicly released today.

Sources and further reading