Refinery monitors your data, repairs supported problems at the source, and proves what changed.
Alongside your database. Under your control.
Browser sample available. Live customer connections, API/MCP access and repairs are not publicly released.
activeenabled !Guest checkout sends a new customer record to your database.
The approved rule maps enabled → active. The similar names need a separate human review.
Only Samuel’s status would change. Names stay unchanged.
The source now returns active. A sample receipt records approval, write and exact readback.
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.
Improve operational data at its source, prove supported repairs, and help AI use data only when it meets declared requirements.
Applications and AI can optionally request data through Refinery’s read-only gateway. Only consumers using this path receive its eligibility check. Existing applications can keep direct database connections.
The browser sample is available. Live customer connections, API/MCP access and repairs are not publicly released.
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.
Current freshness boundary: freshness is checked at table level against the agreed window. A recent table signal does not establish the age or correctness of every record. Row-level freshness is not release-proven.
Explore the browser sample →Start with the sample, with no account or card. When product access is available, the same five steps keep the supported work understandable.
Choose a supported database and the tables, fields and relationships Refinery may inspect.
Find supported inconsistencies. Use approved rules or a configured read-only trusted reference to establish the right value.
Review an evidence-backed correction. Require human approval or current authority for a certified procedure.
Read the source again. Verify the exact change and retain a durable receipt. Keep uncertain problems visible.
Check the approved scope again. 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.
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.
This browser-only sample starts with an optional gateway request that finds an inconsistent status. Open the repair path to review the correction, give sample approval and inspect the simulated readback and receipt. No real source is connected or changed.
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.
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.
Three clear platform plans. Choose the approved database coverage that fits your workflow. Nothing is purchasable today.
€0/month
One database to begin with.
Not released. Join early access to register your interest.
Join early access€99/month
Add a trusted reference.
Not released. Join early access to register your interest.
Join early access€399/month
Expand approved coverage.
Multi-database coverage is planned / early access and is not publicly released.
Join early accessSupported capacity, deployment and service requirements by agreement. Scope and availability are agreed separately; no standard SLA, compliance certification or unlimited-service promise.
Same safeguards in every tier. Current authorization, connector and repair certification, exact expected-before checks, fresh source readback and durable receipts remain required.
Active tables are the tables you explicitly include in the approved scope, counted across the plan's databases. A trusted-reference database is a separate, read-only connection used for approved exact lookups; it does not become a second operational database. Free's relationships stay inside its one database.
Usage allowances are being finalized for launch. Record-evaluation, repair-attempt, request and scheduling limits will be disclosed before activation. Table counts do not promise unlimited scans or repairs. Limits never remove required post-write verification or receipt access.
Two bounded design-partner pilots first. Then a founding subscription offer for the first 20 qualifying independent organizations. Both depend on release and approval.
Custom connectors and bespoke integration or deployment projects are excluded. Availability remains subject to release and partner approval. Billing starts only when the agreed pilot environment is available. No automatic subscription conversion.
Join early accessPlatform fees only. No lifetime discount, no stacking and no discount on bespoke services. Qualification and availability are confirmed before signup. All prices exclude VAT; BYOK model charges and source-system costs are separate.
Join early accessApplications 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.
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.
You do not need a large data organisation to have this problem. You need one automated decision that customers feel when it goes wrong.
Built for technical founders, AI application developers and operational data teams with one recurring PostgreSQL problem, a named workflow and an owner who can authorize a bounded repair.
The release boundary is part of the trust promise, so it is answered here rather than in a call.
Read evidence explains why data was released for a specific purpose and time against approved requirements. A repair receipt proves an authorized source correction after exact fresh readback and durable evidence. Routine checks do not generate repair receipts. The gateway only reads; an AI repair request cannot authorize or execute a change merely by asking. Live connections, API/MCP access and repairs are not publicly released.
No. Existing applications can keep reading the database directly while Refinery monitors approved scope and performs authorized supported repairs at the source. The read-only gateway is an optional path for consumers that need a purpose-specific eligibility decision. That path adds processing, so its latency needs release testing; no response-time SLA is claimed. Direct database reads do not receive a Refinery eligibility decision.
No. Refinery inspects the approved scope and supported relationships. A correction needs evidence of the right value, a supported repair type and the required current policy and authorization. Some repairs require human approval; currently authorized certified automation may run only within its exact permitted scope. Unknown values, identity conflicts and unsupported writes remain blocked or escalated. Monitoring can surface recurrence; a correction does not permanently prevent it.
Refinery evaluates freshness at table level against the agreed window. Row-level freshness is not release-proven. A recent table signal does not establish the age or correctness of every record; eligibility also depends on the approved scope, purpose and evidence.
Refinery monitors your data, repairs supported problems at the source, and proves what changed. It connects alongside existing operational databases, so applications can keep reading them directly. Choose the tables, fields and supported relationships Refinery may inspect. Corrections need evidence, current policy and the required authorization; exact source readback and a durable receipt prove the change. Monitoring surfaces unresolved and recurring problems. Applications and external AI assistants can use supported capabilities through API and MCP when released. A separate, optional read-only gateway checks data against a consumer’s declared requirements. Product access is not open yet.
A purpose-bound trust layer between an operational system of record and an approved AI or workflow consumer. It checks freshness, scope, identity, evidence and policy before returning eligible or explicitly limited data, or blocking the request. The source stays authoritative. The implemented freshness check is table-level; row-level freshness is not release-proven.
You can try the browser-only sample demo without an account, card, database credentials or model key, and join early access. Signup, live connections, API and MCP access, repairs and purchasing are not released. Join early access for availability updates. Team multi-database coverage remains planned expansion, subject to availability.
Planned pricing is Free at €0/month, Builder at €99/month and Team at €399/month when available, with Enterprise capacity and services by agreement. Prices exclude VAT. BYOK model charges and source-system costs are separate. API and MCP access are included in every tier when released. There is no per-seat or per-agent platform fee and no automatic overage billing. Nothing is purchasable today.
Free covers one operational database and five active tables. Builder covers one operational database plus one read-only trusted-reference database and 25 active tables across both. Team plans up to five databases in approved roles and 100 active tables; that wider coverage is not released. Usage allowances are being finalized for launch. All tiers retain the same authorization, verification and receipt safeguards.
Two founding design-partner pilots are planned at €1,000 each, excluding VAT. Each lasts six weeks and covers one supported workflow, one operational database, an optional approved read-only trusted reference and up to eight hours of assistance. Custom connectors and bespoke integration or deployment projects are excluded. Availability remains subject to release and partner approval. Billing starts only when the agreed pilot environment is available, with no automatic subscription conversion.
After the initial pilots, the first 20 qualifying independent organizations receive 50% off platform fees for 12 months: Builder at €49.50/month, renewing at €99/month; Team at €199.50/month when available, renewing at €399/month. Prices exclude VAT; model and source-system costs are separate. There is no lifetime discount, no stacking and no discount on bespoke services. Qualification and availability are confirmed before signup.
AI is not write authority. Applications and AI assistants can request supported repairs through API or MCP when available, but execution uses the separate governed path. Human approval is required where policy demands it. Certified automation requires current policy, certification and exact execution authority; it cannot authorize itself. Both paths require an expected-before check, fresh source readback and durable receipts. A read-only gateway query cannot execute a repair.
Only after an authorized governed write, an exact fresh readback and durable receipt and evidence-chain proof match the subject, operation, tenant, actor and time. A write attempt or model answer is not proof. Data eligibility is checked again after the proven repair; source correction alone does not prove downstream workflow recovery.
The planned Free and Builder entry scope is one operational PostgreSQL database, with an optional approved read-only trusted reference in Builder. Cross-table work requires supported relationships and repair types. Team adds planned multi-database expansion. Arbitrary joins, automatic synchronization, entity merging and unrestricted writes across connected databases are not supported. Live product access is not publicly released.
Describe your workflow and the problem in general terms. Never send database credentials, connection URLs, model keys, exports or production records through a marketing form or chat. The form sends an enquiry; it does not create a product account, authorize data access or collect payment. Credentials will belong only in the approved secure connection flow after release.
Duplicate or entity merges, identity conflicts, wrong-identity cases, destructive changes, ambiguous financial facts and unsupported connector writes remain blocked or escalated. A higher price, a high confidence score or a policy name never makes them safe automatic repairs. Source systems remain authoritative.
Bring the workflow, the PostgreSQL data behind it, and what it costs when the data is wrong. You get a straight answer about fit — including a no.