RefinerySay what the AI needs
Name the AI or workflow, its purpose, the approved source, the fields it needs, and what must never be exposed.
Design-partner conversations · PostgreSQL-first
Give AI data it can actually trust.
Refinery checks operational data before AI or automation uses it. Trusted data passes. Uncertain data is held. Eligible issues can be repaired safely and verified in the source before they are called fixed.
- Purpose-bound
- Read-only gateway
- Proof before fixed
One request. One trust decision.
support_agent · billing_status
01SourceRead current PostgreSQL data.
02PurposeBind the approved AI use case.
03FreshnessCheck that the record is current.
04TrustCheck scope, quality, and policy.
05DecisionAllow, limit, or block.
06EvidenceReturn the reason with the result.
ELIGIBLE
billing_status · valid for support1 use caseStart with one AI or workflow decision that matters.
PostgreSQL-firstProve a bounded source scope before expanding.
3 outcomesTrusted, limited, or blocked — always with a reason.
Verified Data Gateway
A trust check between your systems and your AI. Refinery returns data that is safe for the approved purpose — or clearly explains why it must be limited or blocked.
How Refinery works
A trust check between your systems and your AI.
Refinery does not replace your source systems. It checks each approved request against current data, the declared use case, and your policy before anything reaches AI or automation.
Check the data now
Refinery evaluates freshness, completeness, identity, evidence, and policy using current source data.
Return only what is safe
Trusted data passes. Limited data carries an explicit warning. Unsafe or uncertain data is blocked with a reason.
A simple example
An AI support agent asks for a customer's billing status.
Without a trust check, stale or conflicting data can become a confident answer. Refinery checks the request before the record reaches the agent.
Refinery checks
- Is this the approved support use case?
- Is the customer identity unambiguous?
- Is the billing status current and in scope?
- Is the field allowed for this consumer?
Refinery returns
- Trusted data when every required check passes
- Limited data with an explicit condition
- A block when the data is stale, conflicted, or disallowed
- A clear next step instead of a guessed value
If a safe issue can be resolved: Refinery routes it through policy or human approval, checks the expected current value, performs the governed change, reads PostgreSQL back, and creates a durable receipt. Only then may the record be called fixed.
Who Refinery is for
Teams putting operational data behind AI and automation.
Refinery is useful when a wrong, stale, or disallowed record can create a bad answer, a failed workflow, manual review, or an audit problem.
“Can this data be trusted now?”
Give an AI system purpose-bound operational data without handing it unrestricted source access.
“Who fixes the underlying problem?”
Turn important exceptions into evidence-backed decisions instead of another growing alert queue.
“Can we prove what happened?”
Connect the purpose, source evidence, decision, repair attempt, readback, and receipt.
A focused first engagement
Prove one important AI or workflow decision.
Start read-only. Measure the current risk, establish what data may be trusted, and decide whether verified resolution removes meaningful operator work.
A good design-partner fit
- An AI or workflow decision depends on PostgreSQL data
- Freshness, completeness, identity, or policy is questioned
- Manual review or downstream failures are measurable
- A data owner can approve a narrow, read-only scope
What the website does not claim
- Universal connector repair or MDM replacement
- AI can silently overwrite source systems
- Autonomous identity merges or ambiguous financial changes
- General availability, public SLA, or proven customer outcomes
The short answers
What Refinery is — and what it is not.
The release boundary is part of the trust promise. These answers separate the product direction, the current commercial scope, and the safety rules.
What is Refinery?
Refinery checks operational data before an approved AI system or workflow uses it. Trusted data passes, uncertain data is limited or blocked, and eligible low-risk issues can enter a governed repair path with exact source readback and durable proof.
What can we discuss now?
Controlled design-partner conversations are open for a PostgreSQL-first scope. Every engagement starts with one use case, one approved source scope, and a read-only baseline. Refinery is not generally available today.
Does AI directly edit production data?
No. AI may help analyze evidence and prepare recommendations, but it is not write authority. Any change requires explicit policy or approval, an exact expected-before state, a certified connector path, fresh readback, and a durable receipt.
When does Refinery call a record fixed?
Only after a governed write is verified by reading the target back and a durable receipt ties the change, subject, and proof together.
Which systems are supported?
The first commercial scope is PostgreSQL-first. Setup, read eligibility, repair certification, and production readiness are separate claims; each must be proven for the exact path before it is advertised.
How do I check whether my use case fits?
Use the short fit-check form. Describe the AI or workflow decision, the PostgreSQL data it depends on, and what failure costs you. Do not send credentials, secrets, or production records.
One use case. One evidence standard.
Which AI decision depends on data you cannot fully trust?
We will map the purpose, approved source, current risk, and evidence needed to decide whether a bounded design-partner path makes sense.