RCR/1 -- Receipt Commitment Record | RANKIGI

SECTION 1

What is RCR/1

AI agents act across dozens of vendor systems. Stripe processes payments. Anthropic handles inference. Courts accept filings. Hospitals record access. Every vendor emits receipts in their own format.

RCR/1 is the canonical format that any vendor receipt translates into. One schema. Any vendor. One verifiable record.

SECTION 2

The Architecture

RCR/1 sits at the base of a four-layer stack. Vendor receipts translate into canonical records, which are then chained, exchanged, and committed publicly.

Layer 0.5

RCR/1 Translation

Vendor receipts to canonical records

Layer 1

Private Chain

Hash-chained agent events

Layer 2

CCAP

Bilateral counterparty receipts

Layer 3

XACT

Public commitments

SECTION 3

Claim Taxonomy

RCR/1 separates what a receipt claims from how strongly the claim is witnessed. The ladder below runs from weakest to strongest evidence.

customer_asserted

User self-reports it happened

e.g. typed form submission

vendor_lookup_token

Vendor confirms via opaque token

e.g. Stripe charge_id lookup

vendor_signed

Vendor cryptographically signs the event

e.g. Stripe webhook HMAC, DKIM email

notarized

Independent notary timestamps the record

e.g. RFC 3161 TSA token

qualified_seal

eIDAS qualified electronic seal

e.g. PAdES qualified signature

regulator_attested

Regulator confirms in their system of record

e.g. PACER filing receipt

public_ledger

Recorded in a public transparency log or chain

e.g. Sigstore Rekor, Solana settlement

SECTION 4

Schema

The full JSON Schema is published in the CC0 repository. The required record surface is intentionally small enough for adapters to implement and strict enough for deterministic verification.

{
  receipt_id: "rcr_..."
  schema_version: "rcr/1"
  issuer: { name, domain, adapter_id, certification_level }
  source: { vendor_name, source_type, source_received_at }
  action: { action_class, occurred_at }
  effect: { status, terminal }
  hashes: { native_payload, canonical_payload, receipt }
  evidence: { claims: [...] }  // minItems: 1
  chain: { previous_receipt_hash, chain_position }
  integrity: { receipt_hash, signature, sig_alg, key_id }
  disclaimer_uri: "https://rcr.spec/disclaimer/v1"
}

SECTION 5

Adapters

RANKIGI publishes reference adapters for the 10 most common vendor types. Community adapters follow the same interface.

Stripe webhooksAvailable

MCP sidecarComing soon

Anthropic Messages APIComing soon

OpenAI Responses APIComing soon

DKIM emailComing soon

AWS CloudTrailComing soon

DocuSignComing soon

PACER / CM-ECFComing soon

FHIR AuditEventComing soon

OpenTelemetryComing soon

SECTION 6

Legal Disclaimer

An RCR/1 receipt is a structured commitment by the issuing system to a set of observed claims at a point in time. It is not a judicial finding, not a guarantee of underlying transaction validity, and not a substitute for primary records. Evidentiary weight depends on evidence.claims[].strength, witness_class, non_repudiation_level, and jurisdictional rules of evidence. The terms "verified" and "verification" in RCR/1 refer only to the technical check identified in the verification.method field, not to legal truth or finality. RCR/1 makes no representation of legal admissibility in any jurisdiction.

SECTION 7

Standards

RCR/1 is published as CC0. The specification is submitted to the IETF as draft-snow-rcr-receipt. Regulatory mappings for EU AI Act Article 12, ISO/IEC 42001, and SOC 2 are available in the GitHub repository.

SECTION 8

Contribute

Build an adapter. Submit a test vector. Review the IETF draft.

GitHub: github.com/rcr-standard/spec
IETF: datatracker.ietf.org/doc/draft-snow-rcr-receipt/
Email: rcr@rankigi.com

RCR/1