Home / Try the demo
Interactive example · sample data · no live connectionRefinery monitors your data, repairs supported problems at the source, and proves what changed. Connect alongside your operational database. Your applications can keep their direct database connections.
Browser sample available. Live customer connections, API/MCP access and repairs are not publicly released.
Follow a browser example with sample data: what can be read, what must be withheld, and what a supported repair needs.
This sample needs human approval for enabled → active. Certified automation can run only under current policy and authorization; it cannot authorize itself.
enabledactiveVerify the exact change with a fresh source read and a durable receipt. Unknown or unresolved records stay visible.
Your AI needs more than database access. It needs to know whether the data is usable for this task, right now.
Explains why data was released for a specific purpose and time, checked against approved freshness, quality, scope and policy requirements. A limited result carries explicit restrictions; a blocked result withholds the requested data.
A read check does not create a repair receipt.Proves an authorized source correction only after exact fresh readback and durable receipt evidence match the operation. A proposal, a routine check or an AI request is not proof of a repair.
The gateway only reads. Repair uses a separate governed path.An AI assistant asks for account status and service tier within an approved support task. In this example, the source is authoritative and the approved table-level freshness signal passes.
The status field meets the task’s approved requirements and can be returned with read evidence.
The available values disagree. This field is withheld; a limited result explains the restriction. If the required freshness signal were stale, the affected request would be blocked.
A separate repair request: an AI may request a proposal for a supported correction. In this example a human must approve the exact change. Only an authorized write, exact fresh source readback and a durable repair receipt allow it to be called fixed. Conflicting evidence must first be resolved through an approved basis; the AI cannot pick a value or authorize a write merely by asking.
Existing applications may keep direct database connections. Only consumers using the optional gateway receive its eligibility check; the source database remains authoritative. An AI can request a supported repair, but cannot authorize or execute one merely by asking.
The browser sample is available. Live customer connections, API/MCP access and repairs are not publicly released.
Freshness is currently table-level. Row-level freshness is not release-proven.
Refinery connects alongside your database to inspect, propose supported repairs and prove changes. The examples below explore the optional read-only gateway: what happens when an AI asks for data. The first example also walks through a separate, simulated repair.
Choose an example
An AI assistant asks for a customer’s account status. Change the situation to see what can be shared, what needs review and why.
Illustrative checks against sample data. These are not live database results.
A status of 'enabled' when the agreed domain says 'active'. Every human reading it knows what it means. The gateway refuses to assume, because assuming is how a data problem becomes a confident wrong answer. This is the defect class Refinery treats as reference: single row, reversible, no identity or financial effect — so it can be closed under governance rather than queued.
Nothing dramatic: an approved consumer, an approved field, a fresh read, a freshness signal inside its window, one unambiguous subject, a canonical value. The value is returned with the evidence that allowed it, so the decision can be reconstructed later.
The data may well be correct. It is not proven current, so it does not pass. Note what is not returned: no cached value, no best guess, no silent fallback. The AI gets a reason and a next step, which is a far better input to a customer conversation than a stale number stated with certainty.
The agent has a working connection, a valid subject, and fresh data — and still cannot read the field, because it is not in the approved set for this purpose. Widening what an AI can see stays a deliberate decision instead of a side effect of database access.
Two records match the same person with different statuses. Refinery will not choose between them and will not merge them — not with approval, not with a receipt. Identity conflicts go to a named human owner. A repair you cannot justify is a guess with paperwork attached.
In case 01 the proposal sits there doing nothing until you approve it, and the write only lands because the row still held the exact expected value. Then the source is read back and a receipt is recorded. That order — expected-before, write, readback, receipt — is what separates a proven fix from a claimed one.
Tell us which AI workflow you would put behind this and which PostgreSQL data it reads. The fit check is free, needs no credentials or data, and ends in a straight yes or no.