Receipt ledger

Every governed record should leave evidence

A receipt turns data-quality work from invisible cleanup into inspectable operational control. Refinery produces receipts for detection, decision, writeback, verification, and blocked actions.

What a receipt contains

Record identity and governed path
Decision outcome: accept, normalize, block, escalate, or review
Policy version in force at decision time
Issues detected: duplicate, invalid, missing, stale, conflicting, AI-unsafe
Automatic actions applied under policy
Blocked actions prevented from silent landing
Human review requirement and approver when applicable
Writeback status: pending, verified, failed, or blocked
Evidence hash referencing supporting material

Why receipts matter

CRM / ERP hygiene

Prove why a duplicate merge was blocked or a field normalized before sync.

AI governance

Show which records were marked unsafe before copilot or RAG consumption.

Audit and compliance

Export decision trails without exposing raw PII unnecessarily.

Example receipt

{
  "record": "crm_account:acme-bv",
  "path": "web_form_to_crm",
  "decision": "normalized_and_escalated",
  "policy_version": "customer-master-v3",
  "issues": ["email casing", "possible duplicate", "missing industry"],
  "automatic_actions": ["normalized email casing"],
  "blocked_actions": ["duplicate merge", "industry overwrite"],
  "human_review_required": true,
  "writeback_status": "verified",
  "evidence_hash": "sha256:..."
}

Privacy-aware evidence

Receipts can mask PII in customer-facing exports while preserving decision structure, policy version, and verification outcome for audit.

FAQ

Are receipts the same as data lineage?

Receipts are decision-level evidence for governed operational repair. Lineage tracks movement; receipts prove why a record was accepted, changed, or blocked.

See baseline sample receipts

Start read-only. No production writeback required. Do not submit secrets through public website forms. Privacy