The open standard for
production incident receipts.
DSR/1.0 defines a cryptographically signed, vendor-neutral format for documenting how a production failure was attributed and resolved. Any tool can issue one. Any auditor can verify one. No account required. No subscription required.
Verify a receipt in five minutes.
Install a reference implementation. Pass any DSR/1.0 receipt JSON. Receive a cryptographic verdict — no network calls, no Déjà account required.
dsr-verifier-cli is a reference implementation of the
canonical form and signature scheme this document specifies; DSR/1.0
is the protocol, and any tool may implement it.
brew install deja-app/tap/dsr-verifier-cli # or download a signed binary: # https://github.com/deja-app/dsr-verifier-cli/releases/latest
# 1 · Fetch the issuing party's published Ed25519 public key. # The endpoint is issuer-specific — Déjà's is shown as an example. curl -s https://deja.dev/api/public/signing-key | jq -r .publicKey > issuer.pub # 2 · Verify. Offline from here — no network calls, no account. dsr-verifier-cli verify receipt.json --public-key issuer.pub # ✓ Key authority check ................. OK # ✓ Signature verification .............. OK # Algorithm: ed25519-v1 # # Result: VERIFIED · 2 check(s) passed # exit 0 (1 failed · 2 parse error · 3 missing file · 4 key error)
attribution_method is the key field auditors check
first. It declares whether the root cause was identified by
automated tooling, manual investigation, or a combination — and must
match the signing key class in the
integrity
block to pass verification.
Every field. Every constraint.
A valid DSR/1.0 receipt must contain all required fields. Locked fields must carry their specified literal value — they may never be computed, variable, or absent. Fields are serialized in strict alphabetical key order before signing.
https://standard.deja.dev/v1. Identifies
DSR/1.0 conformance and provides JSON-LD context. Must never be a
different URL.
CrossServiceReceipt. Identifies document type
within the DSR context.
DSR/1.0. Used by the verification library to
select the correct signing algorithm.
rcpt_{ulid}. Must be immutable after issuance — the
same receipt_id must never be reissued.
payments-checkout,
auth-login
YYYY-MM-DDTHH:MM:SSZ.
Milliseconds optional. Timezone offset prohibited. This is when
the receipt was signed, not when the incident occurred.
tool-name/version. Included in the signed payload
when present.
Example: deja/1.0.0
org/repo#prNumber. Must
reference a real, verifiable PR.
Example: acme-corp/payments#412
0.0000–1.0000 to 4
decimal places. Scores below 0.80 must not produce
receipts under deterministic_sde.
HIGH_CONFIDENCE_DEDUCTION (ccs_score ≥ 0.90) or
STANDARD_DEDUCTION (≥ 0.80 and < 0.90). Must be
consistent with ccs_score.
false — never true,
never variable. Enforced at DB level as a
CHECK constraint. A receipt requiring trace IDs is
not DSR/1.0 compliant.
causal_pr.
true. Format assertion by the issuer
that this receipt conforms to SOC 2 Type II incident response
evidence requirements.
NOT a certification
by Déjà or any auditing body.
true. Issuer assertion of conformance
with ISO 27001 Annex A 5.24.
NOT a certification.
Never compute — structural declaration only.
true, issuer asserts DORA EU Article 17
compliance. Reserved for DSR/2.0 formal definition. Issuers
setting this in DSR/1.0 take sole responsibility for the
assertion.
90_day (standard),
2_year (extended),
permanent (unlimited). Vendor-neutral — any issuer
may map these to their own retention policies.
ed25519-v1 for all receipts issued from DSR/1.0.2
onward. sha256-legacy identifies receipts issued
before the Ed25519 cutover (pre-1.0.2). Verifiers must dispatch
on this field to select the correct verification primitive.
alphabetical. Declares keys were sorted by
raw Unicode code point order before signing. See §2.1 for the full
algorithm.
signing_algorithm=ed25519-v1: the 64-byte raw
Ed25519 signature over the canonical JSON payload bytes,
base64-encoded (88 chars). For
signing_algorithm=sha256-legacy: 64-character
lowercase hex SHA-256 digest of the canonical JSON payload.
Written atomically with the receipt. Never recomputed after
issuance.
How the signature is computed.
The signing process is deterministic. The same receipt fields always produce the same signature. This is what makes verification possible without contacting the issuer.
§2.1 Canonical Ordering Rule
sha256_signature
Collect all key-value pairs. Remove
sha256_signature entirely. The remaining fields
form the canonical payload.
CRITICAL: Sort using raw Unicode code
point comparison —
not
locale-sensitive comparison.
✓ Correct: .sort(([a], [b]) => a < b ? -1 : a > b ?
1 : 0)
✗ Wrong: .sort(([a], [b]) => a.localeCompare(b))
localeCompare is environment-dependent and
produces different results across Node.js versions, browsers,
and operating systems. The sort must be identical everywhere.
Nested objects are not recursively sorted — top-level keys
only.
No spaces after colons, no spaces after commas, no newlines.
JavaScript: JSON.stringify(sorted)
Python: json.dumps(sorted, separators=(',', ':'))
Output must be a single unbroken UTF-8 string.
Sign the canonical UTF-8 bytes with the Ed25519 private key
(DSR/1.0.2+). The 64-byte raw signature is base64-encoded
(88 chars). This is the signature field value.
For receipts issued before DSR/1.0.2
(signing_algorithm=sha256-legacy), compute SHA-256
of the canonical bytes and hex-encode the 32-byte digest.
signature
as the last field before INSERT
Add signature to the receipt. The database
INSERT must be atomic — signature and payload in one
transaction. Never update the signature after initial write.
import { createHash } from 'node:crypto' function signReceipt( fields: Omit<DsrReceipt, 'sha256_signature'> ): string { // Step 2: Raw Unicode sort — NOT localeCompare const sorted = Object.fromEntries( Object.entries(fields).sort(([a], [b]) => a < b ? -1 : a > b ? 1 : 0 ) ) // Step 3: Compact JSON const canonical = JSON.stringify(sorted) // Step 4: SHA-256 hex return createHash('sha256') .update(canonical, 'utf8') .digest('hex') }
Correctness note: Use raw Unicode comparison
a < b ? -1 : a > b ? 1 : 0 — not
a.localeCompare(b). Locale-sensitive comparison is
environment-dependent and breaks cross-platform verification.
§2.2 Verification
Verification reconstructs the canonical payload, then uses the Ed25519 public key to confirm the stored signature covers exactly those bytes. The verifier never makes network calls — all logic is self-contained given the public key.
async function verifyReceipt( receipt: unknown, publicKey: CryptoKey // Ed25519 CryptoKey from /api/public/signing-key ): Promise<VerificationResult> { const { signature: stored, ...payload } = receipt if (!stored) return { valid: false, reason: 'Missing signature' } const canonical = canonicalise(payload) // raw Unicode sort + JSON.stringify const sigBytes = base64ToBytes(stored) const dataBytes = new TextEncoder().encode(canonical) const valid = await crypto.subtle.verify('Ed25519', publicKey, sigBytes, dataBytes) return { valid, receipt_id: payload.receipt_id, issued_at: payload.issued_at, attribution_method: payload.attribution_method, ccs_score: payload.ccs_score, confidence: payload.confidence, reason: valid ? undefined : 'Signature mismatch — receipt may have been tampered with' } }
Verify any receipt. No account required.
Paste any DSR/1.0 receipt JSON below. Verification runs entirely in your browser using the Web Crypto API — nothing is sent to Déjà's servers. Click 'Load Sample' to see a valid receipt.
Declaring how attribution was made.
The
attribution_method
field is the most important field in the spec for auditors. It
declares the quality and reproducibility of the attribution on the
face of the signed document.
§3.1 Confidence Levels
deterministic_sde. No receipt issued. Incident flagged for manual review. A
signed low-confidence receipt is more dangerous than no receipt.
What can change. What cannot.
Locked fields never change. trace_id_used,
soc2_ready, iso27001_ready,
signing_algorithm, canonical_order, and
@type are fixed for the lifetime of the major version.
Release history.
Initial publication defining all four field groups, SHA-256
canonical signing with raw Unicode key ordering, the
attribution_method enum with five values, two confidence levels,
and the versioning policy.
@deja-dev/dsr-verify
npm and
dsr-verify
PyPI packages — libraries, since superseded by
dsr-verifier-cli as the reference implementation.
retention_class
uses vendor-neutral values:
90_day,
2_year,
permanent.
Open. Forever.
The DSR specification and JSON Schema are MIT licensed. No
attribution required. No restrictions on commercial use. Any tool may
implement DSR/1.0 without permission from Déjà — the reference
implementation, dsr-verifier-cli, is Apache-2.0.
Patent notice:
The DSR/1.0 format specification and JSON Schema are MIT licensed
with no restrictions, and the reference implementation is
Apache-2.0. The Déjà Schema Deduction Engine
(SDE) — which produces receipts with
attribution_method: 'deterministic_sde' — is covered by
a pending patent. Any tool may implement and issue DSR/1.0 receipts
using any other attribution method without restriction.
MIT License Copyright (c) 2026 Déjà, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.