Audit posture
Audit Receipts for Data Quality, AI Governance, and Verified Writeback
Refinery’s audit posture is built around record-level decision trails: what was detected, which policy applied, who or what decided, what changed, and whether the target state was verified. Receipts make data-quality decisions inspectable for operators, audit, and AI governance teams.
What a receipt should contain
The rule, policy version, threshold, or review requirement used for the decision.
The source fields, detected issue, duplicate evidence, AI rationale, or review context.
System, AI judge, reviewer, or operator associated with the decision.
Accepted, normalized, blocked, escalated, reviewed, written, verified, or rejected.
Why receipts matter
Bad data-quality work often disappears into scripts, cleanup projects, spreadsheets, or opaque automation. Receipts make data-quality decisions inspectable. They help teams explain why a record was changed, why it was blocked, why AI was used, and whether the target system confirmed the result.
Example receipt JSON
{
"record": "crm_account:acme-bv",
"path": "web_form_to_crm",
"decision": "normalized_and_escalated",
"policy_version": "customer-master-v3",
"automatic_actions": ["normalized email casing"],
"blocked_actions": ["duplicate merge"],
"human_review_required": true,
"writeback_status": "verified",
"evidence_hash": "sha256:..."
}
Export formats
Receipts support operator review in product and audit export under enterprise agreements. PII can be masked in customer-facing exports while preserving decision structure.
Why receipts matter for AI governance
When AI contributes to a decision, receipts record model involvement, policy constraints, and verification — supporting AI governance programmes that require explainability.
Enterprise audit posture
Enterprise buyers often need to answer: who changed this record, under which policy, with what evidence, and did the target system confirm the result? Receipts are designed to support those questions without requiring teams to reconstruct history from ad-hoc scripts or spreadsheet cleanups.
Audit export depth, retention windows, and PII masking rules are configured under enterprise agreement. Refinery supports compliance workflows; it is not a substitute for your own control framework or formal certification.
Receipt anatomy for reviewers
- Record identity — stable identifier across source and target
- Path — governed route (e.g. web form → CRM → ERP)
- Issue detection — duplicate, invalid, missing, stale, conflicting, AI-unsafe
- Policy version — which rule set governed the decision
- Actor — system, AI judge, reviewer, or operator
- Writeback status — shadow_only, pending_review, verified, rejected
- Target verification — whether the destination confirmed the outcome
Compliance posture
Refinery should support compliance work by making decisions reviewable and exportable. It should not be presented as a compliance certification by itself. SOC 2, ISO, or other formal claims should only be made when they are true and supported by evidence.
Shadow mode and baseline receipts
During a 14-day Shadow Baseline, receipts may show writeback_status: shadow_only — proving what would have happened without changing production. This gives audit and RevOps teams evidence before live repair is enabled.