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 the verification library. Pass any DSR/1.0 receipt JSON. Receive a cryptographic verdict — no network calls, no Déjà account required.
npm install @deja-dev/dsr-verify
# or
pip install dsr-verify
import { verifyReceipt } from '@deja-dev/dsr-verify'; const receipt = await fetch('/receipts/inc-2026-04-12.json') .then(r => r.json()); const result = await verifyReceipt(receipt); if (result.valid) { console.log('Receipt verified:', result.summary); // attribution_method: 'automated_trace' // confidence: 0.94 // signed_at: '2026-04-12T03:14:00Z' } else { console.error('Verification failed:', result.errors); }
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.
SHA-256. Identifies the hashing algorithm.
Future versions may introduce additional values.
alphabetical. Declares keys were sorted by
raw Unicode code point order before signing. See §2.1 for the full
algorithm.
sha256_signature, sorted
alphabetically, no whitespace). Written last, before atomic DB
INSERT. 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.
Hash the canonical JSON string encoded as UTF-8 bytes using
SHA-256. Result is a 32-byte digest. Convert to 64-character
lowercase hexadecimal string. This is the
sha256_signature value.
sha256_signature
as the last field before INSERT
Add sha256_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 reverses the signing process. Extract the signature, recompute it from the remaining fields, compare. The verifier must never make network calls — all logic is self-contained.
function verifyReceipt(receipt: unknown): VerificationResult { const { sha256_signature: stored, ...payload } = receipt if (!stored) return { valid: false, reason: 'Missing sha256_signature' } const computed = signReceipt(payload) // uses raw Unicode sort above const valid = computed === stored 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, both MIT licensed.
retention_class
uses vendor-neutral values:
90_day,
2_year,
permanent.
Open. Forever.
The DSR specification, JSON Schema, and verification libraries are MIT licensed. No attribution required. No restrictions on commercial use. Any tool may implement DSR/1.0 without permission from Déjà.
Patent notice:
The DSR/1.0 format specification and verification libraries are MIT
licensed with no restrictions. 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.