DéjàDSR / 1.0
Specification/Receipt Types
Specification/Receipt Types
DSR/1.0 · Specification document

Receipt types.

Every custody-relevant event in a Déjà vault produces a tamper-evident, hash-chained receipt. This document specifies the ten receipt types defined by DSR/1.0 — their triggers, schemas, and relationships. It is the canonical reference for Heads of Risk, CISOs, security architects, and audit-firm technologists — including teams at firms such as KPMG, Deloitte, EY, PwC, BDO, Grant Thornton, and independent auditors — verifying receipts under SOC 2 Type II, ISO 27001, NYDFS Part 500, DORA, or SR 11-7 frameworks.

version: DSR/1.0status: Stablerevised: 2026-04-19patents: 18/668,178 + 19/430,349 + CIP March 2026 + SDE Provisional March 2026

A Déjà receipt is a structured, cryptographically verifiable record of something that happened in a vault — an incident attributed, a fix verified, an auditor verifying a chain, a configuration changed. Core and lifecycle receipts (R1, R2, RV, RE, RG) carry an Ed25519 asymmetric signature; exception receipts carry a SHA-256 content hash for tamper-evidence. Receipts are the product's atomic unit of evidence. They are not events, logs, or records; they are cryptographic custody artifacts, and they behave as such. Verifiable offline via dsr-verifier-cli (pre-release · public release Q3 2026) by any party with a copy of the signed bundle.

The taxonomy is partitioned into three families: core receipts that document the happy path of an incident lifecycle (R1, R2); exception receipts that document the unhappy paths most systems silently drop (R0, R1-L, R1-N, R2-F, R2-R); and lifecycle receipts that record actions on the custody infrastructure itself (RV, RE, RG). The partition matters because a chain of custody with gaps is worse than no chain at all — Déjà records the failures too. Regulated firms operating under continuous-evidence obligations cannot afford silent gaps.

Every receipt carries the same base envelope: type, version, vault_id, actor, timestamp, prior_hash (for chained types), and signature. The type-specific fields documented below extend this envelope.

The taxonomy.

Ten types, grouped by function. Core receipts account for approximately 95% of issuance volume in typical vaults; exception and lifecycle receipts are rare but structurally essential.

SPEC vs IMPLEMENTATION · TRANSPARENCY NOTE

The DSR/1.0 specification defines ten receipt types as semantic categories. The current Déjà codebase materializes them across ten dedicated database receipt tables:

  • sde_cross_service_receipts — covers the attribution surface (R1), distinguished at the data level via a confidence field with values HIGH_CONFIDENCE_DEDUCTION (CCS ≥ 0.90) and STANDARD_DEDUCTION (0.80 ≤ CCS < 0.90).
  • sde_resolution_receipts — covers the resolution surface (R2, R2-F, R2-R), distinguished via gates_passed and gate_evaluated_at fields rather than as separate receipt rows.

The dsr-verifier-cli projects the database representation back into the canonical DSR/1.0 receipt format. Audit firms verifying receipts offline see the spec-correct view: a single canonical R-subtype envelope per event, signed and chain-verifiable, regardless of how the database stores the underlying record. This is by design — the verifier is the contract surface; the database is an implementation detail.

Lifecycle receipts (RV, RE, RG) are fully implemented with dedicated tables (sde_verification_receipts, sde_engagement_receipts, sde_governance_receipts) and active issuers. Verification (RV), evidence-bundle export (RE), and governance configuration changes (RG) are issued as receipt-grade cryptographically signed artifacts in the same pipeline as core receipts. The full subtype documentation below describes the canonical DSR/1.0 envelope and materialization details explicitly per subtype.

R1· Core

Attribution Receipt.

Issued when Déjà's Schema Deduction Engine produces a causal attribution with Causal Confidence Score ≥ 0.80. R1 is the first receipt in a custody chain — every downstream receipt (resolution, verification, export) references it.

Triggers
Incident signal received from an integration (Datadog, Sentry, PagerDuty) AND causal PR identified with CCS ≥ 0.80.
Incident classified as HIGH_CONFIDENCE_DEDUCTION (CCS ≥ 0.90) or STANDARD_DEDUCTION (0.80 ≤ CCS < 0.90).
Schema
Field
Type
Description
incident_id
string · req
Source system's incident identifier (e.g., DD-INC-84729).
service_zone
string · req
Derived zone identifier — see Zone Derivation spec.
error_type
string · req
Canonicalized error class (e.g., RedisConnectionRefused).
causal_pr
string · req
Pull request URL or identifier, e.g., acme/payments#412.
ccs_score
float · req
Causal Confidence Score in [0.0, 1.0].
signals
object · req
Weighted signal contributions — code change match, temporal proximity, field overlap, etc.
prior_match
ref · optional
Hash of a prior R1 with the same fingerprint, if any.
author
string · req
Commit author identified as causal — from git log.
method
string · req
Attribution method — deterministic_sde for Schema Deduction Engine.
Example
R1 · signed
{
  "type":           "R1",
  "version":        "DSR/1.0",
  "receipt_id":     "r_01hwxak9vz",
  "vault_id":       "vault_01hx2k",
  "incident_id":    "DD-INC-84729",
  "service_zone":   "payments-checkout",
  "error_type":     "RedisConnectionRefused",
  "causal_pr":      "acme/payments#412",
  "ccs_score":      0.9200,
  "signals": {
    "code_change_match":    0.94,
    "temporal_proximity":   0.89,
    "field_overlap":        0.91,
    "stack_trace_match":    0.98
  },
  "prior_match":    null,
  "author":         "m.rodriguez@acme.com",
  "method":         "deterministic_sde",
  "timestamp":      "2026-04-19T14:02:33.441Z",
  "signature":      "a7f3c8d2e94b1052f6a38c7d9e2b4f01..."
}
Chain relationships
R1R2R1 is referenced by its matching R2 upon resolution. R2 carries chained_from = hash(R1).
R1R2-FIf the fix fails observation gates, R2-F is issued and references this R1.
R1R1prior_match references an earlier R1 with matching fingerprint — institutional memory.
R2· Core

Resolution Receipt.

Issued when all five operational gates pass within the observation window following a deployed fix. R2 closes the chain opened by R1 — chained by hash. The presence of an R2 is how a regulator distinguishes "incident happened" from "incident resolved and verified."

Triggers
All 5 gates pass: error_rate_normalized, infrastructure_green, feature_flags_stable, observation_window, file_rate_baseline.
Observation window (default 15 min, configurable per zone) elapsed without regression.
Schema
Field
Type
Description
chained_from
hash · req
SHA-256 hash of the R1 this R2 resolves.
resolved_pr
string · req
The PR that deployed the fix — may differ from causal_pr.
gate_results
object · req
Per-gate result object with passed_at timestamps.
observation_window_ms
int · req
Duration of the observation window in milliseconds.
mttr_ms
int · req
Mean-time-to-resolution in milliseconds, from R1 timestamp.
resolved_by
string · req
Commit author of the resolving PR.
Chain relationships
R1R2R2 always chains to exactly one R1. Unchained R2 is a protocol violation.
R2R2-RIf the same fingerprint recurs within 30 days, R2-R re-opens this chain.
R0· ExceptionEnterprise

Ingestion Receipt.

Issued the instant an incident signal enters Déjà, before any attribution work. Proves the signal was received intact at timestamp X regardless of what happens next. Most organizations never need R0; regulators who want to prove Déjà didn't selectively ingest certain incidents will require it.

Triggers
Raw signal received from any ingestion integration — no attribution attempted yet.
Feature flag r0.enabled = true on vault (Enterprise tier default: false).
Schema
Field
Type
Description
raw_signal_hash
hash · req
SHA-256 of the raw incoming signal payload.
source_integration
string · req
Installed integration identifier (e.g., datadog:ubs-prod).
received_at
timestamp · req
UTC timestamp of receipt at Déjà ingestion endpoint.
payload_size_bytes
int · req
Size of the raw signal payload.
R1-L· ExceptionStandard+

Low-Confidence Attribution.

Issued when candidate PRs are identified but the highest CCS falls in the low-confidence range (0.60 ≤ CCS < 0.80) — below attribution threshold but above the floor for non-trivial signal. Explicitly marks the attribution as ambiguous and carries the top three candidate PRs with individual scores. Requires human review; can be upgraded to R1 by a human confirmation (issues a chained RG receipt).

Triggers
Incident attributed with 0.60 ≤ CCS < 0.80 — below attribution threshold but above the low-confidence floor, with non-trivial candidate signal.
Multiple candidate PRs above the inferred-attribution cap with no clear dominant match.
Schema
Field
Type
Description
status
literal · req
Always "ambiguous".
candidate_prs
array[3] · req
Top 3 candidates with { pr, ccs_score, signals } per entry.
requires_review
bool · req
Always true for R1-L.
reviewer
string · opt
Populated when human confirms — upgrades to R1 via RG chain.
R1-N· ExceptionStandard+

No-Attribution Receipt.

Issued when Déjà examines the incident and finds no causal attribution above the inferred-attribution cap. Most incident tooling silently discards these. Déjà signs them — a custody chain with gaps is worse than no chain at all. The "we looked and came up empty" receipt is what makes the system trustable.

Triggers
All candidate PRs score below the inferred-attribution cap, or no candidates identified.
Signals insufficient for deterministic attribution (e.g., no recent PRs, insufficient field overlap).
Schema
Field
Type
Description
reasons
array · req
Enumerated reasons — no_recent_prs, insufficient_field_overlap, no_stack_trace, etc.
signals_examined
object · req
Full signal analysis — shows what WAS looked at, even though nothing matched.
highest_candidate_ccs
float · req
Best score found — always below the 0.80 attribution threshold for R1-N.
R2-F· ExceptionStandard+

Resolution-Failed Receipt.

Issued when a fix is deployed but one or more gates fail within the observation window. The incident remains in open-chain state. R2-F is what turns "we tried and it didn't work" from a missing data point into a tamper-evident custody artifact.

Triggers
Any gate fails within observation window (error rate regression, infra red, flag rollback, etc.).
Observation window expires with at least one gate unresolved.
Schema
Field
Type
Description
chained_from
hash · req
Hash of the R1 this resolution attempt targeted.
attempted_pr
string · req
The PR that attempted the fix.
gate_results
object · req
Per-gate with passed/failed status and failure reason for failed gates.
regression_detected
bool · req
True if metrics got worse after deployment.
chain_remains_open
literal · req
Always true — R2-F does not close the chain.
R2-R· ExceptionStandard+

Resolution-Reopened Receipt.

Issued when a previously-closed R2 chain reopens because the same fingerprint recurs within a defined window (default 30 days). Chains to the original R1 AND the new R1. Institutional memory at the receipt level — "this didn't actually stay fixed."

Schema
Field
Type
Description
original_r1
hash · req
Hash of the initial R1 in the recurring chain.
original_r2
hash · req
Hash of the R2 that was supposed to have closed it.
new_r1
hash · req
Hash of the new R1 representing the recurrence.
days_since_r2
int · req
Days between the closing R2 and the reopening event.
fingerprint_match
float · req
Similarity score between original and recurrence.
RV· LifecycleEnterprise

Verification Receipt.

Issued when an external party — auditor, regulator, internal SOC — verifies one or more receipts via the open DSR/1.0 verifier. This is the receipt that proves an auditor looked and the chain held. Zero-knowledge of content; proof-of-verification only.

Schema
Field
Type
Description
verified_receipt_ids
array · req
Receipt IDs or hashes that were verified in this call.
verifier_identity_hash
hash · req
SHA-256 of the verifier's SSO identity claim.
verification_result
enum · req
valid / invalid / partial.
engagement_id
string · opt
If verification occurred inside an audit engagement, its ID.
verifier_client
string · req
Verifier type — dsr-verifier-cli, dsr-verifier-web, or third-party.
RE· LifecycleEnterprise

Export / Engagement Receipt.

Issued when an evidence bundle is exported or an audit engagement is signed. Proves what was shared, with whom, and when. RE is the bridge receipt between internal custody and external sharing — an RE with a defined recipient is itself an audit engagement.

Schema
Field
Type
Description
engagement_id
string · req
Unique engagement identifier.
receipts_included
array · req
Hash list of every receipt in the projection.
recipient_hash
hash · req
SHA-256 of the recipient's organizational identity.
scope_definition
object · req
Zones, time range, framework — fully defining the scope.
permissions
array · req
Enumerated capabilities: view, verify, export, download_raw.
expires_at
timestamp · req
UTC timestamp at which auditor access terminates.
RG· LifecycleEnterprise

Governance Receipt.

Issued when any configuration of the vault's custody infrastructure changes: retention policy, integration added or removed, team access granted, routing rule edited, zone merged. RG is custody-of-the-custody-system. The receipt that proves the rules themselves haven't been tampered with.

Change categories
Zone merge, alias change, team ownership assignment.
Retention override added, modified, or removed.
Delivery rule created, edited, paused, deleted.
Integration installed, uninstalled, or re-authorized.
Engagement revoked before natural expiration.
R1-L upgraded to R1 by human reviewer.
Schema
Field
Type
Description
change_type
enum · req
One of the change categories above, normalized.
actor
string · req
Authenticated user or service principal.
prior_state_hash
hash · req
Hash of the configuration state before the change.
new_state_hash
hash · req
Hash of the configuration state after the change.
justification
string · opt
Human-provided rationale. Required for retention overrides and engagement revocations.
affected_resources
array · req
Resource IDs touched by the change (zone IDs, rule IDs, etc.).
REFERENCES · DEEPER MATERIAL
The Engine →
CCS scoring · validation gates · receipt issuance pipeline
System Documentation →
Glossary · entity model · integrations · service-level objectives
Verifier CLI →
Offline receipt verification · open-source · pre-release · public release Q3 2026 · no Déjà account required
Security →
Cryptographic posture · Ed25519 signing · tenant isolation · DPA
Patent Family →
Filed claim language · Edge Parser embodiment · USPTO record
Déjà →
Product overview · pricing · audit-firm verification model
DSR/1.0 · Receipt Types · Revised 2026-04-19
Maintained by Déjà · Patents: 18/668,178 + 19/430,349 + CIP March 2026 + SDE Provisional March 2026