Home / How it works
How it works · early accessRefinery 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.
Choose the tables, fields and relationships Refinery may inspect. A supported source correction follows a separate, authorized path.
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.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.
Wrong values create rework, unreliable answers and recurring incidents. Refinery is being built to find supported problems, correct them at the source and show the evidence.
Your applications can keep reading the database directly. Source cleanup does not require rerouting every query through Refinery.
Start with approved read-only inspection. Source changes follow a separate governed path with the required policy, certification and authorization.
Start with the sample, with no account or card. When product access is available, the same five steps keep the supported work understandable.
Connect a supported database and choose the tables, fields and relationships Refinery may inspect. Start with approved read-only access.
Identify supported problems and inconsistencies across approved tables. Where configured, consult an approved read-only trusted reference to establish the correct value.
Propose an evidence-backed correction. Execute only through the required policy and authorization: human approval where required, or currently authorized certified automation.
Read the source again, verify the exact change and retain a durable receipt. Show unresolved and uncertain problems honestly.
Continue checking the approved scope within the usage allowance. Surface recurring problems; a correction does not permanently prevent recurrence.
A source correction, a gateway eligibility decision and recovery of a downstream workflow are different outcomes. Each needs its own evidence.
Cross-table checks and repairs depend on supported relationships and repair types. A connection alone does not grant permission to inspect or change every table.
Free starts with one operational PostgreSQL database and five active tables. Builder adds an optional separate read-only trusted reference, with 25 active tables across both. The reference supplies approved evidence; it is not another operational write target.
Up to five databases in approved roles and 100 active tables. Wider cross-database relationships remain planned / early access, subject to supported coverage and availability.
No arbitrary joins, automatic synchronization, entity merging or unrestricted writes across connected databases. Unknown values and identity conflicts need evidence or human review.
Available now: the browser-only sample. Live database connections, API/MCP and repairs are not publicly released. Usage allowances are being finalized for launch.
Only eligible low-risk defect classes reach this path. A gateway read can never trigger it — reading and repairing are separated so that an AI asking a question cannot become an AI changing an answer.
Identify the exact invalid or missing value using current source evidence and an agreed rule — not a model's impression of what looks wrong.
A single correction carrying its reason, subject, the exact value expected to be present now, and its supporting evidence.
Current policy and exact authorization for a certified repair. Conversation text and model confidence grant nothing. AI is never write authority.
The governed write applies through a certified connector path, and only if the record still holds the exact expected value. Otherwise it aborts.
Refinery re-reads the authoritative source after the write. A successful write is not evidence of a correct result.
Durable receipts and the evidence chain bind the exact subject, operation, tenant, actor and time. Only the fully proven source change is called fixed. Data eligibility is then checked again.
The expensive part is often the work after discovery: finding the right correction, securing approval, changing the source and checking whether the workflow can use the result. Refinery is being built to carry that whole bounded job.
A supported repair changes the authoritative record under current authorization. Your source remains the source of truth; a cleaner downstream copy is a different outcome.
Compare the expected-before value with the fresh readback. Follow the durable evidence chain. A confident answer or a completed request cannot substitute for proof.
Continue checking the approved scope and surface repeated defects or uncertainty. A correction does not permanently prevent the problem from returning.
Use these questions when evaluating Refinery, another platform or a workflow you build yourself.
| Ask any platform | Refinery's approach |
|---|---|
| Can my AI use it without moving every task into a new chat? | API-first service and MCP for external assistants; Workspace for controls and exceptions. |
| What permits a source change? | Current policy, exact authorization and a certified repair; the plan price never grants authority. |
| What proves the correction? | Exact fresh source readback, durable receipts and a correlated evidence chain. |
| What happens when evidence is missing? | Explicit limits or a blocked result with a reason. No plausible replacement value presented as fact. |
| What happens after the repair? | Continue monitoring the approved scope. Optional gateway consumers receive a separate eligibility check; actual workflow recovery needs its own evidence. |
Explore the sample to understand the approach. Validate the supported workflow in your own approved scope when access is available.
Applications and AI can optionally request data through Refinery’s read-only gateway, which checks whether it meets their declared requirements.
Only consumers using this path receive the eligibility check. Existing direct database reads remain available. The gateway can return eligible or explicitly limited data, or block a request with a reason. A gateway query cannot execute a repair.
Optional product interface · not publicly released. Source-cleanup work does not require every application query to use this path.
Before anything is read, the engagement is written down: which AI or workflow, what decision it makes, the approved source, the exact fields it may see, and what must never be exposed. That declaration is the unit of approval. Two AI systems reading the same table can have entirely different answers about what they may see.
The gateway design evaluates each request against a fresh source read for its declared purpose. Recurring monitoring is separate and remains bounded by the plan and approved usage allowance.
Is this consumer approved for this declared purpose right now? An expired or unapproved purpose fails here, before anything is read.
Is this exact source supported and approved? The supported source scope is one operational PostgreSQL database and an optional read-only trusted reference. Broader connectors are not a launch promise.
Does the approved table's freshness signal sit inside the agreed window? Stale or unknown fails closed. This is a table-level signal today.
Does exactly one record match the subject? Zero matches and multiple matches are both failures, and neither is resolved by picking one.
Is this specific field inside the approved set, and does classification policy allow it to reach this consumer?
Is the value itself coherent against the agreed domain, complete, and supported by the evidence this purpose requires?
It is to return only what the declared consumer may safely use, and to make the reason visible when it cannot.
The freshness signal passes and the data is in scope, policy-allowed, and supported by the evidence this purpose requires. Returned with the evidence that allowed it.
Usable only with an explicit limitation — a redaction, an expiry, or required human oversight. The condition is returned with the value and is not optional.
Stale, unknown, conflicted, out of scope, wrong identity, or insufficiently proven. No raw fallback value is silently returned in its place.
Applications can use the API and external AI assistants can use MCP to request supported assessment, repair work, operation status and proof. These interfaces do not grant extra authority.
Prepare evidence and a proposal, then enter the existing governed execution path only with the required current authorization. Otherwise return the approval requirement. A request or model answer is not proof of a repair.
Request bounded data and an eligibility decision through the separate optional read path. This query cannot call the repair executor.
Handle connections, policies, approvals, exceptions and receipts in Workspace. Routine supported work can start in your application or external assistant.
API and MCP access are included in every tier when released. Product access and these integrations are not publicly released; join early access to register interest.
Explore the sample without signup or a card. Planned prices are Free €0, Builder €99 and Team €399/month when available, excluding VAT and separate model/source costs. API and MCP are included in every tier when released.