v1.0.0 · April 2026 · Stable

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.

Status Stable
Version 1.0.0
Signing SHA-256
Format JSON-LD
License MIT
§0 Quick Start

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.

Install Terminal
npm install @deja-dev/dsr-verify
# or
pip install dsr-verify
Verify a Receipt TypeScript
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.

Don't have a receipt yet? Generate a cryptographically valid signed sample.
Load Sample →
§1 Schema Definition

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.

§1.1 — Identity Fields
FieldTypeStatusDescription
@context
string
Locked
Must be https://standard.deja.dev/v1. Identifies DSR/1.0 conformance and provides JSON-LD context. Must never be a different URL.
@type
string
Locked
Must be CrossServiceReceipt. Identifies document type within the DSR context.
canonical_version
string
Locked
Must be DSR/1.0. Used by the verification library to select the correct signing algorithm.
receipt_id
string
Required
Globally unique identifier. Recommended format: rcpt_{ulid}. Must be immutable after issuance — the same receipt_id must never be reissued.
vault_id
string
Required
The tenant isolation boundary identifier. Used for RLS and evidence scoping during audits.
service_zone
string
Required
The named service zone where the incident occurred. Example: payments-checkout, auth-login
issued_at
string
Required
ISO 8601 UTC only. Format: YYYY-MM-DDTHH:MM:SSZ. Milliseconds optional. Timezone offset prohibited. This is when the receipt was signed, not when the incident occurred.
issuer
string
Optional
Identifies the issuing tool. Format: tool-name/version. Included in the signed payload when present. Example: deja/1.0.0
§1.2 — Attribution Fields
FieldTypeStatusDescription
causal_pr
string
Required
Compound PR identifier: org/repo#prNumber. Must reference a real, verifiable PR. Example: acme-corp/payments#412
ccs_score
number
Required
Causal Confidence Score. Float 0.0000–1.0000 to 4 decimal places. Scores below 0.80 must not produce receipts under deterministic_sde.
confidence
enum
Required
HIGH_CONFIDENCE_DEDUCTION (ccs_score ≥ 0.90) or STANDARD_DEDUCTION (≥ 0.80 and < 0.90). Must be consistent with ccs_score.
attribution_method
enum
Required
Declares how the causal PR was identified. See §3 for all valid values. The key field for auditors.
trace_id_used
boolean
Always false
Must be literal false — never true, never variable. Enforced at DB level as a CHECK constraint. A receipt requiring trace IDs is not DSR/1.0 compliant.
missing_fields
string[]
Optional
Field names missing or mismatched in the consumer service at incident time. Corresponds to fields changed in causal_pr.
§1.3 — Compliance Fields
FieldTypeStatusDescription
soc2_ready
boolean
Always true
Must be literal 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.
iso27001_ready
boolean
Always true
Must be literal true. Issuer assertion of conformance with ISO 27001 Annex A 5.24. NOT a certification. Never compute — structural declaration only.
dora_eu_ready
boolean
Optional
When 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.
retention_class
enum
Optional
Data retention tier. Values: 90_day (standard), 2_year (extended), permanent (unlimited). Vendor-neutral — any issuer may map these to their own retention policies.
§1.4 — Integrity Fields
FieldTypeStatusDescription
signing_algorithm
string
Locked
Must be SHA-256. Identifies the hashing algorithm. Future versions may introduce additional values.
canonical_order
string
Locked
Must be alphabetical. Declares keys were sorted by raw Unicode code point order before signing. See §2.1 for the full algorithm.
sha256_signature
string
Required
64-character lowercase hex. SHA-256 hash of canonical JSON payload (all fields except sha256_signature, sorted alphabetically, no whitespace). Written last, before atomic DB INSERT. Never recomputed after issuance.
§2 Signing Algorithm

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

1
Collect all fields except sha256_signature

Collect all key-value pairs. Remove sha256_signature entirely. The remaining fields form the canonical payload.

2
Sort keys by raw Unicode code point order

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.

3
Serialize to compact JSON — no whitespace

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.

4
Compute SHA-256 hash

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.

5
Write 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.

Reference Implementation TypeScript
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.

Verification TypeScript
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'
  }
}
Interactive Tool Client-Side · No Network

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.

DSR/1.0 Receipt Verifier · @deja-dev/dsr-verify v1.0.0
SHA-256 · Browser
Paste Receipt JSON ⌘+Enter to verify
§3 Attribution Method Enum

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.

ValueDescriptionIssuer
deterministic_sde
Attribution by Déjà Schema Deduction Engine using AST-parsed PR diffs and W1–W6 weighted scoring. Identical inputs always produce identical output. No ML, no trace IDs. Highest-quality method.
Déjà
probabilistic_ml
Attribution by ML model or embedding similarity. Same inputs may produce different outputs across runs. Reproducibility not guaranteed.
Third party
manual_review
Attribution by a human engineer who reviewed the incident. Quality depends on the engineer's judgment at the time.
Any issuer
automated_rule
Attribution by a deterministic rule (e.g. 'most recent PR touching this file'). Reproducible but no causal graph analysis.
Any issuer
unknown
Attribution method not recorded. Valid for legacy migration only. New receipts must not use this value.
Migration only

§3.1 Confidence Levels

LevelThresholdDescription
HIGH_CONFIDENCE_DEDUCTION
≥ 0.90
CCS 0.90 or above. All six factors returned strong signals. Auditor can treat as standalone primary evidence without corroboration.
STANDARD_DEDUCTION
≥ 0.80, < 0.90
CCS 0.80–0.89. Threshold met. Reliable for compliance but may benefit from corroborating logs in high-stakes audits.
— (no receipt issued)
< 0.80
Below attribution threshold for deterministic_sde. No receipt issued. Incident flagged for manual review. A signed low-confidence receipt is more dangerous than no receipt.
§4 Versioning Policy

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.

Allowed in Minor Versions (1.x)
Adding new optional fields
Adding new attribution_method enum values
Adding new confidence level enum values
Extending the verification library
Adding new compliance fields
Never Allowed Without Major Version
Removing any existing field
Changing a field's type
Changing a locked field's value
Changing the signing algorithm
Changing the canonical ordering rule
Changelog

Release history.

v1.0.0 April 2026
Initial Release DSR/1.0 — First stable release

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.

License

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.