Skip to main content

​
Audit receipts

A valid completed Chain can produce a Chain Record / receipt containing structured governance evidence for that workflow. Receipts are designed to make later mutation detectable and to support authenticated and bounded public verification. They are evidence. They are not a claim that Arclasp executed the customer’s real-world tool.

​
What a receipt represents

A receipt can bind together governance context such as:
  • Chain identity and timing;
  • governed event summaries;
  • cumulative metrics captured for the Chain;
  • policy and approval context;
  • receipt number and issuance metadata;
  • cryptographic integrity material;
  • linkage to supported predecessor receipt state.
The exact fields and verification layers can vary by receipt generation era and artifact type. Treat the API response or export for a specific receipt as the wire-format source of truth rather than copying a hand-written example schema.

​
Signing and hash linkage

Arclasp uses deterministic structured data, cryptographic hashes, signatures, and receipt linkage to make supported evidence tamper-evident. In practical terms:
  • changing signed data should invalidate its integrity/signature checks;
  • supported predecessor linkage lets verification evaluate receipt-chain continuity;
  • verification can report the layers available for the requested artifact.
Do not assume every historical receipt exposes the same verification layers as a newly issued current receipt.

​
Tamper-evident, not tamper-proof

“Tamper-evident” means verification is designed to detect evidence mutation. It does not mean:
  • the surrounding database or infrastructure can never be attacked;
  • the receipt proves legal admissibility;
  • the receipt automatically establishes compliance;
  • the receipt creates legal non-repudiation;
  • an uninstrumented customer-side tool definitely executed exactly as described.
Arclasp can only preserve the governance evidence it actually receives and records.

​
Authenticated verification

Authenticated users can verify supported receipt integrity through the v2 verification API:
The response is server-attested. It can expose integrity and receipt-chain status plus additional role-appropriate verification context. This is not an independent offline verifier over raw private key material.

​
Public verification

Admins can issue an opaque public verification token for eligible evidence. A public viewer uses the tokenized verification surface and receives a bounded projection of verification status rather than private governance payloads or credentials. See Verification.

​
Receipt numbering

Human-readable receipt numbers retain the compatibility format:
The PR- prefix is a frozen compatibility identifier and should not be globally renamed without a deliberate migration.

​
Historical and current receipts

Arclasp has evolved its receipt and verification architecture over time. For public documentation, the safe rule is: verify the artifact you have and trust the layers reported for that artifact. Do not infer that a historical receipt lacking a newer layer is fraudulent, and do not claim a historical artifact has cryptographic material it was never issued with.

​
Exports

Arclasp exposes receipt / Chain Record export surfaces in the product, including structured and document-oriented outputs where available. That is different from independent offline cryptographic proof verification. Do not treat “downloadable export” and “offline verifier” as the same capability.