Only Institute / Knowledge

Follow your curiosity.

AI sends your question and public excerpts to PrimeSwarm.

Try agent memory, governance, or a project name.

All Publications
specification

PSR-001: A Receipt Format for AI Governance Decisions

A framework-agnostic spec for cryptographically verifiable receipts — any governance system can produce them, any auditor can verify them

Grigori Korotkikh 2026-09-12 8 min
PSR-001SpecificationReceiptsAuditStandardsOpen Source
Only Institute — PSR-001: A Receipt Format for AI Governance Decisions

PSR-001: A Receipt Format for AI Governance Decisions

Why we published a spec

Auditors don't need another log. They need a receipt they can replay.

Every AI governance system produces some form of audit trail. Microsoft AGT produces a Merkle hash chain. NVIDIA NeMoClaw produces lifecycle logs. PrimeSwarm produces cryptographic receipts. These are all different formats, with different fields, different semantics, and different verification procedures.

An auditor who needs to verify an AI decision across systems that use different governance tools faces a problem: there is no common format. They cannot write one query, run one verifier, or produce one audit report. They must learn each system's format, trust each system's logs, and hope the formats don't change.

PSR-001 is our proposal for a common receipt format. It is framework-agnostic. Any governance system — PrimeSwarm, AGT, NeMoClaw, or a custom implementation — can produce PSR-001 receipts. An auditor can parse receipts from any conforming system using a single interface.

What a PSR-001 receipt contains

A receipt is a JSON document with these required fields:

  • spec_version — PSR-001, so parsers know what they're reading
  • receipt_id — a unique identifier
  • timestamp — ISO 8601 UTC, when the decision was made
  • gate_state — ALLOW, DENY, or ESCALATE
  • policy — the language, version, and SHA-256 hash of the policy script that was evaluated
  • input — the SHA-256 hash of the input (PII stripped), the input type, and optional field values
  • evidence — the residual, healing indices, reason codes, and replay inputs
  • receipt_hash — SHA-256 binding all required fields

Optional fields:

  • identity — the agent that proposed and the human that approved
  • signature — Ed25519 signature over the receipt hash

What makes it a receipt, not a log

A log says "this happened." A receipt says "this happened, here is the proof, and here is how you can verify it."

The difference is replay. A PSR-001 receipt includes evidence.replay_inputs — the exact inputs needed to reproduce the evaluation. An auditor can:

  1. Retrieve the policy script
  2. Verify SHA-256(script) == policy.script_hash
  3. Reconstruct the input from evidence.replay_inputs
  4. Verify SHA-256(sanitized_input) == input.input_hash
  5. Run the open-source verifier against the script and input
  6. Compare the result to gate_state, evidence.residual, and evidence.reason_codes
  7. Recompute receipt_hash and confirm it matches

If all checks pass, the decision is verified. The auditor did not trust the system. They verified it.

Framework-agnostic by design

The policy.language field identifies what was evaluated:

Systempolicy.languageNotes
PrimeSwarmonly-langFull receipt — residual, healing, replay
Microsoft AGTyamlAGT verdicts map to ALLOW/DENY/ESCALATE. warn → ALLOW with reason code. transform → ALLOW with reason code.
NVIDIA NeMoClawcustomNetwork policy decisions. input_type is network_request.
Customrego, cedar, python, customAny deterministic decision system

A conforming implementation must produce all required fields, compute receipt_hash per the spec, strip PII before hashing, and include evidence.replay_inputs sufficient for independent verification.

What this does not require

  • It does not require ONLY Lang. Any policy language works.
  • It does not require PrimeSwarm. Any governance system can produce conforming receipts.
  • It does not require a specific verifier. Any open-source verifier that can replay the evaluation is sufficient.
  • It does not require Ed25519 signatures. Signatures are recommended but optional.
  • It does not require a specific SIEM. The JSON format is SIEM-agnostic.

Mapping to existing implementations

The spec includes appendices mapping PSR-001 to:

  • PrimeSwarm VerificationReceipt (dgv-verifier) — the existing struct maps directly, with gate_status → gate_state and residual_final → evidence.residual
  • PrimeSwarm EvidencePack (only-lang) — run_id → receipt_id, decision_hash → receipt_hash, replay_inputs → evidence.replay_inputs
  • Microsoft AGT Audit Entry — decision → gate_state, agent_id → identity.agent_id. AGT's Merkle chain provides tamper detection but not replay. A conforming adapter would add script_hash, input_hash, and replay_inputs.

Why we open-sourced this

If PrimeSwarm receipts become the format auditors expect, it doesn't matter what NVIDIA or Microsoft build. The auditor asks for a PSR-001 receipt. The enterprise has to produce one. Any system can produce one — the spec is open.

This is not a moat through secrecy. This is a moat through standardization. The more systems that produce PSR-001 receipts, the more valuable the format becomes. The more auditors who expect PSR-001 receipts, the more systems have to produce them.

Status and next steps

This is version 0.1 (Draft). We are publishing it now to get feedback from:

  • Auditors and compliance officers — does this format give you what you need?
  • SIEM vendors — can you parse and index this format?
  • Governance system vendors — can your system produce conforming receipts?
  • Standards bodies — ISACA, AICPA, NIST — is this a useful reference implementation for AI audit evidence?

Future versions:

  • PSR-002 — batch receipts (multiple decisions in one document)
  • PSR-003 — Merkle chain (hash-linked receipt sequences, for systems that need ordered audit trails)
  • PSR-004 — cross-system attestation (multiple systems co-signing a decision)

Read the full spec

The full specification is at /specs/psr-001. It includes:

  • The complete field reference
  • The receipt hash computation procedure
  • The replay verification procedure
  • An example receipt
  • SIEM integration guidance
  • Framework compatibility mapping
  • JSON Schema for validation
  • Appendix mapping to existing implementations

The JSON Schema is at /specs/psr-001/schema.json.

Try it

  • Run the governance gate in your browser at /try — every run produces a receipt you can inspect
  • Browse all 89 DGV test cards at /dgv/registry — each one is a receipt-generating test
  • Download the auditor bundle at /try/bundle — run all 89 cards locally and produce signed receipts

If you are an auditor, a compliance officer, or a standards body, we want your feedback. Contact us at /contact.


Back to Publications

Published by Only Institute