Purpose-bound and read-only
An approved AI use case receives only its allowed fields. A gateway request cannot call the repair executor.
Current trust posture
Refinery is designed to fail closed: uncertain data is limited or blocked, a gateway read cannot execute a repair, and no completed repair claim exists without exact source readback and durable proof.
An approved AI use case receives only its allowed fields. A gateway request cannot call the repair executor.
Stale, conflicted, disallowed, wrong-identity, or insufficiently proven data is never silently returned as trusted.
After an allowed repair, Refinery reads the authoritative source fresh and keeps a durable receipt of the exact result.
Claims we can make now
The current scope is controlled and PostgreSQL-first. General availability, broader connector readiness, and customer outcomes remain separate proof gates.
Before any design-partner path
No customer-data engagement begins on trust alone. Its purpose, scope, access, decision policy, and evidence plan must be reviewed and documented.
The exact AI or workflow decision, PostgreSQL scope, data class, volume, and accountable business owner.
The minimum credentials, permissions, network path, storage, and retention needed for the agreed mode.
Whether the connector is read-only, setup-ready, certification-required, or proven for the bounded repair path.
Which cases may be decided deterministically, which require human review, and which must be blocked.
What must be read back, what a receipt contains, who reviews the result, and what stops the pilot.
Evaluate the boundary first
A fit check should expose what is proven, what remains path-specific, and what Refinery will refuse to do.