Skip to content
DSR/1.0 · Specification document

Receipt types.

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 your audit firm — verifying receipts under SOC 2 Type II, ISO 27001, NYDFS Part 500, DORA, or SR 11-7 frameworks. Regulated firms record receipts under these frameworks; Déjà does not certify compliance.

version
DSR/1.0
status
Stable
R1 signs
DSR/1.0.6 · v5-jcs
patents
18/668,178 + 19/430,349 + CIP March 2026 + SDE Provisional March 2026
Illustration: a sample vault with invented data, from the ledger to one receipt, the chain, the monitor and the export, narrated by a synthetic voice.
Transcript of the narration

  1. The ledger

    1. The ledger is every receipt this vault has issued: fifty-two so far. Each row is one receipt, with its time, its type and what it records.
    2. It's append-only, enforced in the database rather than by convention.

  2. One receipt

    1. Open a receipt. The signed part is the decision: the repository and pull request, the field, the score, its margin over the runner-up, the scoring version and the time.
    2. Beside the signature, Déjà keeps what isn't signed: the candidates' details, and the hash of the receipt before it.

  3. The chain and the monitor

    1. Those hashes link each receipt to the one before. Every fifteen minutes, the integrity monitor checks attribution, no-attribution, resolution and governance receipts, and the genesis receipt.
    2. Low-confidence, engagement and the remaining exception receipts aren't checked by the monitor. Each can still be checked on its own.

  4. Export

    1. Export up to 2,500 receipts at a time. Each is a signed file the verifier checks on its own, with no Déjà account.
    2. The export leaves out two types, and the whole-bundle check is for an audit's period report.

  5. In one line

    1. An inspectable record. Checkable without us.
Introduction

Each type is issued by a specific event, named in its section below. Every type stores a link to the previous receipt of its type, inside its signed fields; a receipt issued before its type moved to v5-jcs may keep it outside them.

A Déjà receipt is a structured, cryptographically verifiable record of something that happened in a vault — an incident attributed, an incident resolved, a chain checked by Déjà's integrity monitor, a configuration changed. R1, R2, R0, R1-L, R1-N, R2-F, R2-R, RV, RE and RG are signed with the vault's key — Ed25519 for a Déjà-managed key, RSA-PSS or ECDSA when you bring your own. R0, R2-F and R2-R issued before 27 October 2026 carry a SHA-256 content hash instead, which needs no key to recompute. Receipts are the product's atomic unit of evidence. They are not events, logs, or records; they are cryptographic custody artefacts, and they behave as such. Verifiable offline via dsr-verifier-cli (v1.7.2, open source) by any party with a copy of the signed bundle. R0, R2-F and R2-R receipts issued before 27 October 2026 are the exception: dsr-verifier-cli does not check their content hashes, so the Ledger export lists them in checked-online.json for deja.dev/verify to check instead.

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.

There is no single envelope. Each type signs its own set of fields, listed in its section below. A column a table keeps beside them is not covered unless the list names it.

Taxonomy

The taxonomy.

Ten types, grouped by function. Core receipts document the happy path of an incident lifecycle; exception and lifecycle receipts are structurally essential.

  • R1

    Attribution Receipt

    Incident attributed to a causal PR with CCS above threshold.

    Core · signed

  • R2

    Resolution Receipt

    An incident marked resolved, with its five gate scores and whether they passed. References its R1.

    Core · signed

  • R0

    Ingestion Receipt

    Signal received intact — before any attribution work.

    Exception · signed · Enterprise, Sovereign

  • R1-L

    Low-Confidence Attribution

    Candidate PRs identified but CCS in the low-confidence range (0.60–0.79).

    Exception · signed

  • R1-N

    No-Attribution Receipt

    Examined, and neither an R1 nor an R1-L was issued.

    Exception · signed

  • R2-F

    Resolution-Failed Receipt

    Issued with an R2 whose gates did not all pass.

    Exception · signed

  • R2-R

    Resolution-Reopened Receipt

    The same fingerprint recurred after an R2 whose gates passed.

    Exception · signed

  • RV

    Verification Receipt

    Déjà's integrity monitor checked the receipt chains it covers in a vault, and the genesis receipt.

    Lifecycle · signed

  • RE

    Engagement Receipt

    An audit engagement created, shared or revoked.

    Lifecycle · signed

  • RG

    Governance Receipt

    Configuration change to the vault's custody infrastructure.

    Lifecycle · signed

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, one per type:

  • sde_cross_service_receiptsR1
  • sde_resolution_receiptsR2
  • sde_ingestion_receiptsR0
  • sde_low_confidence_receiptsR1-L
  • sde_no_attribution_receiptsR1-N
  • sde_resolution_failed_receiptsR2-F
  • sde_reopened_receiptsR2-R
  • sde_verification_receiptsRV
  • sde_engagement_receiptsRE
  • sde_governance_receiptsRG

The .dsr export is built on the server from these rows; dsr-verifier-cli checks the exported file and never reads the database. This is by design — the verifier is the contract surface; the database is an implementation detail.

Lifecycle receipts (RV, RE, RG) have dedicated tables and active issuers: RV from Déjà's integrity monitor, RE on engagement changes, and RG on governance changes. Each is signed in the same pipeline as the core receipts.

Also written, and not one of the ten: a genesis record in genesis_receipts, signed once at onboarding over the vault, its region, frameworks, source control, signal sources and zones. Since 27 October 2026 it also signs the core every receipt signs (its organisation, vault, id, time, key and link), and it is a link in the governance chain: it signs the link after the governance receipts made during setup, and the next one links over it. An earlier genesis record signs the configuration alone, and the first governance receipt links to its hash.

R1Core · signed

Attribution Receipt.

Issued when Déjà's Schema Deduction Engine produces a causal attribution with Causal Confidence Score ≥ 0.80. R1 opens an incident's chain: R2, R2-F and R2-R each reference an R1.

Issued when

  • Incident signal received from an integration (Sentry, Splunk On-Call and Alertmanager · Grafana) AND causal PR identified with CCS ≥ 0.80. A Datadog alert never triggers one: Déjà keeps no title, message or stack trace from it, so it cannot name the field, and it ends in an R1-N. Whether an incident from PagerDuty, AWS CloudWatch, Azure Monitor, Google Cloud Monitoring, incident.io, Rootly or FireHydrant reaches scoring is still being checked, so none is claimed here.
  • Incident classified as HIGH_CONFIDENCE_DEDUCTION (CCS ≥ 0.90) or STANDARD_DEDUCTION (0.80 ≤ CCS < 0.90). A score of 0.90 or more is recorded as STANDARD_DEDUCTION when the change's deploy time is unknown, and two candidates at or above 0.80 within 0.01 of each other are recorded as LOW_CONFIDENCE.

Signed fields

  • actor
  • anchoring_basis
  • attribution_margin
  • canonical_form_version
  • ccs_score
  • confidence
  • error_class
  • incident_id
  • is_internal_validation
  • is_synthetic
  • is_trial
  • issued_at
  • matched
  • missing_field
  • organization_id
  • pr_number
  • prior_hash
  • producer_graph_score
  • receipt_id
  • repository
  • schema_stability_score
  • scoring_version
  • service_zone
  • signal_observation_hash
  • signature_algorithm
  • signing_key_id
  • temporal_basis
  • type
  • vault_id
  • version

Signed under v5-jcs since 27 October 2026, every field present and null when unset. Receipts issued before then were signed under v4-jcs (or an earlier form), which binds neither the company, the receipt's id, its type nor its chain link, and still verify. That form signs these fields:

  • ccs_score
  • confidence
  • error_class
  • issued_at
  • matched
  • missing_field
  • pr_number
  • repository
  • scoring_version
  • service_zone

and these when set:

  • actor
  • anchoring_basis
  • attribution_margin
  • incident_id
  • is_internal_validation
  • is_synthetic
  • is_trial
  • producer_graph_score
  • schema_stability_score
  • signal_observation_hash
  • signing_algorithm
  • signing_key_id
  • temporal_basis
  • version

Stored beside it, not signed

  • causal_pr
  • candidate_details
  • prior_match_receipt_id
  • trace_id_used

Example

{
  "dsr_version": "DSR/1.0.6",
  "type": "R1",
  "receipt_id": "r_5f0b2c8e3a418f6e9d278c1a7e4b90d2",
  "vault_id": "a3d9e1f4-6b28-4c75-8e03-2f7b9c1d4e56",
  "organization_id": "7c2e4a90-1d35-4b8f-a6e2-0f9d3b5c7a18",
  "timestamp": "2026-09-14T18:22:47.000Z",
  "actor": "github:5839241",
  "origin": "production",
  "signature": "q3N8r0bK…VvQXw==",
  "signature_algorithm": "ed25519-v1",
  "canonical_form_version": "v5-jcs",
  "signing_key_id": "deja-managed-v1",
  "prior_hash": "5d2f8a…c1a91c",
  "repository": "acme/payments-api",
  "pr_number": 4521,
  "service_zone": "payments-checkout",
  "error_class": "KeyError",
  "missing_field": "customer.tax_id",
  "ccs_score": "0.9400",
  "matched": "true",
  "confidence": "HIGH_CONFIDENCE_DEDUCTION",
  "producer_graph_score": "0.6000",
  "schema_stability_score": "0.0140",
  "is_synthetic": false,
  "is_internal_validation": false,
  "is_trial": null,
  "issued_at": "2026-09-14T18:22:47.000Z",
  "temporal_basis": "deployed",
  "anchoring_basis": "deploy",
  "incident_id": "0c6e7d15-92b4-4a3f-b1e8-6d5c2f9a7b04",
  "scoring_version": "1.0.14",
  "signal_observation_hash": "9b41e7…d02f6a",
  "attribution_margin": "0.1100"
}

An R1 as a .dsr export carries it: the keys and their order are the export's own; the values are an example, and the signature is shortened.

Chain relationships

  • R1 → R2. R1 is referenced by its matching R2 upon resolution. R2 carries attribution_receipt_id, the UUID of this R1.
  • R1 → R2-F. An R2-F records this R1's id in the field named attempted_pr.
  • R1 → R2-R. An R2-R names the original R1 and the new one, by id.
  • prior_match_receipt_id names an earlier R2 whose gates passed for the same fingerprint within 30 days. It is stored, not signed, and is set only once such an R2 exists (issue #626, under R2).
  • previous_hash links the previous R1 in the organisation's vault. A v5-jcs R1 signs it, as prior_hash; an earlier one keeps it outside the signed fields.

R2Core · signed

Resolution Receipt.

Issued 48 hours after a user marks an incident resolved in Déjà, when every gate has a reading, whether or not the gates pass. It records five gate scores — file, rate, infra, feature and duration — and gates_passed, true only when all five reach 0.70. R2 references its R1 by id and links to the previous R2 in the vault. gates_passed is how a regulator distinguishes "incident resolved" from "incident resolved and verified."

Most organisations get no R2 yet. The gates read what the organisation has connected: merged pull requests from its source control, error events from Sentry, and CPU, memory and latency from Datadog (with a metrics read key) or New Relic. Without those, a gate has nothing to read. A gate with nothing to read is not measured, and Déjà issues no verdict on it. The attempt is recorded, unsigned. An R2 issued before issue #626 was fixed records gates_passed = false because its gates were scored without data.

Issued when

  • A user marks the incident resolved in Déjà, the incident has an R1, and every gate has a reading when its window closes.
  • The gates are scored once, 48 hours after resolution, when duration reaches 1.0. Each passes at 0.70. There is no per-zone setting.

Signed fields

  • actor
  • attribution_receipt_id
  • canonical_form_version
  • dsr_fix_code
  • duration_gate_score
  • feature_gate_score
  • file_gate_score
  • gate_evaluated_at
  • gates_passed
  • incident_id
  • infra_gate_score
  • issued_at
  • organization_id
  • prior_hash
  • rate_gate_score
  • receipt_id
  • resolved_at
  • service_zone
  • signature_algorithm
  • signing_key_id
  • temporal_basis
  • time_to_resolution_ms
  • type
  • vault_id
  • version

Signed under v5-jcs since 27 October 2026, every field present and null when unset. Receipts issued before then were signed under v4-jcs (or an earlier form), which binds neither the company, the receipt's id, its type nor its chain link, and still verify. That form signs these fields:

  • attribution_receipt_id
  • duration_gate_score
  • feature_gate_score
  • file_gate_score
  • gate_evaluated_at
  • gates_passed
  • incident_id
  • infra_gate_score
  • issued_at
  • rate_gate_score
  • resolved_at
  • service_zone
  • time_to_resolution_ms
  • vault_id

and these when set:

  • dsr_fix_code
  • signing_algorithm
  • signing_key_id
  • temporal_basis
  • version

Stored beside it, not signed

  • resolved_by

Chain relationships

  • R1 → R2. R2 references exactly one R1, by attribution_receipt_id.
  • R2 → R2-F. Issued alongside when gates_passed is false; its chained_from is this R2's id.
  • R2 → R2-R. An R2 whose gates passed is what a later R2-R names as original_r2.

R0Exception · signed · Enterprise, Sovereign

Ingestion Receipt.

Issued when an incident is posted to Déjà's generic incident webhook, before any attribution work. It records a SHA-256 of the incident as Déjà parsed it, and when the receipt was issued. Most organisations never need R0; regulators who want to prove Déjà didn't selectively ingest certain incidents will require it.

Issued when

  • An incident arrives at POST /api/webhooks/incidents. No provider webhook — Sentry, Datadog, PagerDuty or any other — issues one.
  • The deployment has R0 switched on (FEAT_R0_INGESTION_RECEIPTS), and the organisation's tier is Enterprise or Sovereign.

Signed fields

  • actor
  • canonical_form_version
  • incident_id
  • issued_at
  • organization_id
  • prior_hash
  • raw_signal_hash
  • receipt_id
  • signature_algorithm
  • signing_key_id
  • source_integration
  • type
  • vault_id
  • version

Signed under v5-jcs since 27 October 2026, every field present and null when unset. Receipts issued before then carry a SHA-256 content hash instead, which needs no key to recompute, over these fields:

  • incident_id
  • issued_at
  • raw_signal_hash
  • receipt_id
  • source_integration
  • type
  • vault_id
  • version

Stored beside it, not signed

  • payload_size_bytes

Notes

  • source_integration is the source the caller declares: GitHub, Slack, Jira, Linear, Sentry and Other.

R1-LException · signed

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 — and the leading candidate passes the change-site gate. It signs how many candidates there were and the highest score, and stores up to 10 candidates with their scores beside the signature. Requires human review: an owner, admin or compliance lead confirms or rejects it, which issues an RG receipt. Confirming does not issue an R1.

Issued when

  • The highest CCS is at least 0.60 and below 0.80. One candidate is enough; when the top two are within 0.01 of each other the receipt is presented as tied.
  • The leading candidate changed the field where it is read, or removed or renamed it where it is declared by a service in, or feeding, the failing zone (the change-site gate). Otherwise the incident gets an R1-N.

Signed fields

  • actor
  • attribution_margin
  • candidate_count
  • canonical_form_version
  • highest_ccs
  • incident_id
  • is_synthetic
  • issued_at
  • organization_id
  • prior_hash
  • receipt_id
  • scoring_version
  • service_zone
  • signal_observation_hash
  • signature_algorithm
  • signing_key_id
  • type
  • vault_id
  • version

Signed under v5-jcs since 25 October 2026, every field present and null when unset. Receipts issued before then were signed under v1-legacy, over fewer fields, and still verify.

Stored beside it, not signed

  • candidate_prs
  • status
  • requires_review
  • attribution_presentation

Review

  • Confirming or rejecting issues an RG with change type R1L_CONFIRMED or R1L_REJECTED, signed like any other RG but with confirmed_receipt_id in place of the two state hashes, and with this R1-L's vault.

R1-NException · signed

No-Attribution Receipt.

Issued when Déjà examines the incident and issues neither an R1 nor an R1-L. 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.

Reasons (stored, not signed)

  • no_field_extracted — the signal named no field.
  • no_candidates_found — no change touched the field.
  • highest_ccs_below_threshold — the best score was below 0.60.
  • site_gate_blocked — the score was in the low-confidence range, but the change-site gate did not pass.
  • no_confirmed_producer_relationship — added to site_gate_blocked when no edge confirms the failing zone as a consumer.
  • unreadable_files — a changed file in the lookback window could not be read: no parser for its type, a parse failure, or no diff from GitHub. It replaces no_candidates_found and is added after the other reasons.
  • could_not_read: — one per unread file, after unreadable_files, in the form could_not_read:why:repository:path, where why is unsupported_file_type, parse_failed or patch_unavailable.
  • unreadable_files_truncated — more unread files were recorded than one receipt lists.

Signed fields

  • actor
  • canonical_form_version
  • highest_candidate_ccs
  • incident_id
  • is_synthetic
  • issued_at
  • lookback_days
  • organization_id
  • prior_hash
  • prs_evaluated
  • receipt_id
  • scoring_version
  • service_zone
  • signal_observation_hash
  • signature_algorithm
  • signing_key_id
  • type
  • vault_id
  • version

Signed under v5-jcs since 25 October 2026, every field present and null when unset. Receipts issued before then were signed under v1-legacy, over fewer fields, and still verify.

Stored beside it, not signed

  • reasons

R2-FException · signed

Resolution-Failed Receipt.

Issued alongside an R2 whose gates did not all pass, which needs every gate measured first (issue #626, under R2). The incident stays resolved, and the row records chain_remains_open = true. R2-F is what turns "we tried and it didn't work" from a missing data point into a tamper-evident custody artefact.

Issued when

  • An R2 is issued with gates_passed = false.

Signed fields

  • actor
  • attempted_pr
  • canonical_form_version
  • chained_from
  • gates_failed
  • incident_id
  • issued_at
  • organization_id
  • prior_hash
  • receipt_id
  • regression_detected
  • service_zone
  • signature_algorithm
  • signing_key_id
  • type
  • vault_id
  • version

Signed under v5-jcs since 27 October 2026, every field present and null when unset. Receipts issued before then carry a SHA-256 content hash instead, which needs no key to recompute, over these fields:

  • attempted_pr
  • chained_from
  • gates_failed
  • incident_id
  • issued_at
  • receipt_id
  • regression_detected
  • service_zone
  • type
  • vault_id
  • version

Stored beside it, not signed

  • gate_results
  • chain_remains_open

Notes

  • attempted_pr holds the R1's id, not a pull request. chained_from is the R2's id.

R2-RException · signed

Resolution-Reopened Receipt.

Designed to be issued when a new R1 has the same fingerprint as an earlier R1 whose R2 passed its gates, within 30 days by default. It names the original R1, its R2 and the new R1 by id; nothing is reopened. It needs a passed R2 first, so it is as rare as R2 is (issue #626, under R2). Institutional memory at the receipt level — "this didn't actually stay fixed."

Signed fields

  • actor
  • canonical_form_version
  • days_since_r2
  • fingerprint_match
  • incident_id
  • issued_at
  • new_r1
  • organization_id
  • original_r1
  • original_r2
  • prior_hash
  • receipt_id
  • sde_fingerprint
  • service_zone
  • signature_algorithm
  • signing_key_id
  • type
  • vault_id
  • version

Signed under v5-jcs since 27 October 2026, every field present and null when unset. Receipts issued before then carry a SHA-256 content hash instead, which needs no key to recompute, over these fields:

  • days_since_r2
  • fingerprint_match
  • incident_id
  • issued_at
  • new_r1
  • original_r1
  • original_r2
  • receipt_id
  • sde_fingerprint
  • service_zone
  • type
  • vault_id
  • version

RVLifecycle · signed

Verification Receipt.

Issued by Déjà's integrity monitor, which every 15 minutes checks a vault's R1, R1-N, R2 and RG receipts and its genesis record. It signs what it found (how many receipts it checked, how many were valid and how many invalid) whenever that changes, after any failure, and at least once every 24 hours. It does not check R1-L, R2-F, R2-R, R0 or RE. Verifying with dsr-verifier-cli, or on /verify, issues no RV. Zero-knowledge of content; proof-of-verification only.

Signed fields

  • actor
  • canonical_form_version
  • engagement_id
  • invalid_count
  • issued_at
  • organization_id
  • prior_hash
  • receipt_id
  • signature_algorithm
  • signing_key_id
  • type
  • valid_count
  • vault_id
  • verification_result
  • verified_receipt_count
  • verifier_client
  • verifier_identity_hash
  • version

Signed under v5-jcs since 27 October 2026, every field present and null when unset. Receipts issued before then were signed under v1-legacy, over fewer fields, and still verify.

Chain relationships

  • previous_hash links the previous RV in the vault, inside the signed fields (as prior_hash in a v5-jcs RV).

RELifecycle · signed

Engagement Receipt.

Issued when an audit engagement is created, when a vault is shared with an auditor, and when an engagement is revoked. Exporting an evidence pack issues an RG (pack_exported), not an RE. 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.

Signed fields

  • actor
  • canonical_form_version
  • engagement_id
  • expires_at
  • issued_at
  • organization_id
  • permissions
  • prior_hash
  • receipt_id
  • receipts_in_scope
  • recipient_hash
  • revoked_at
  • scope_hash
  • signature_algorithm
  • signing_key_id
  • type
  • vault_id
  • version

Signed under v5-jcs since 27 October 2026, every field present and null when unset. Receipts issued before then were signed under v1-legacy, over fewer fields, and still verify.

Notes

  • receipts_in_scope is a count. recipient_hash is a SHA-256 of the auditor's email, lowercased. scope_hash covers the zones, the date range and the receipt types. permissions is empty today.
  • prior_hash links the previous RE in the vault, inside the signed fields.

RGLifecycle · signed

Governance Receipt.

Issued when the organisation's custody set-up changes: every change type production records is listed below. RG is custody-of-the-custody-system. The receipt that proves the rules themselves haven't been tampered with.

Change types

Signal sources and integrations

  • signal_source_connected
  • signal_source_disconnected
  • signal_source_secret_rotated
  • integration_connected
  • integration_disconnected
  • integration_secret_revealed
  • source_control_connected
  • source_control_disconnected
  • source_control_uninstalled

Delegated set-up

  • signal_source_delegation_invited
  • signal_source_delegation_cancelled
  • signal_source_delegation_revoked
  • signal-source_delegation_declined
  • source_control_delegation_invited
  • source_control_delegation_cancelled
  • source-control_delegation_declined
  • source_control_delegation_revoked

Members and ownership

  • member_invited
  • member_joined
  • member_invite_revoked
  • member_invite_resent
  • member_invite_declined
  • join_request_denied
  • member_suspended
  • member_restored
  • member_left
  • member_removed
  • member_personal_data_erased
  • member_role_changed
  • member_tier_changed
  • custom_role_assigned
  • custom_role_unassigned
  • custom_role_created
  • custom_role_modified
  • custom_role_deleted
  • custom_role_permissions_changed
  • vault_access_granted
  • vault_access_removed
  • ownership_transfer_initiated
  • ownership_transfer_accepted
  • ownership_transfer_declined
  • ownership_transfer_cancelled
  • ownership_transfer_expired
  • ownership_transferred

The organisation

  • organization_renamed
  • organisation_closed

Vaults and zones

  • genesis_zones_locked

Service zones

  • zone_added
  • zone_repo_linked
  • zone_repo_unlinked
  • zone_renamed
  • zone_deleted
  • zone_excluded
  • zone_included
  • producer_relationship_confirmed
  • producer_relationship_rejected

Frameworks

  • frameworks_changed

Signing

  • signing_key_set_up
  • signing_key_rotated
  • signing_key_staged
  • signing_schedule_changed
  • governance_signer_changed

Sign-in and SSO

  • sso_configured
  • sso_certificate_added
  • sso_enabled
  • sso_disabled
  • sso_enforcement_changed
  • sso_break_glass_changed
  • sso_scim_connected
  • sso_scim_token_rotated
  • sso_scim_disconnected

Domains

  • domain_added
  • domain_verified
  • domain_lapsed
  • domain_removed

Access policy

  • access_idp_mfa_changed
  • access_sessions_ended

API keys

  • api_key_created
  • api_key_replaced
  • api_key_revoked

Edge Parser keys

  • edge_parser_key_registered
  • edge_parser_key_revoked

Notification routing

  • routing_address_requested
  • routing_address_confirmed
  • routing_address_cancelled
  • routing_address_removed

Déjà staff access

  • staff_access_approved
  • staff_access_declined
  • staff_access_ended

Claude in Help

  • claude_vault_read_approved
  • claude_vault_read_declined
  • claude_vault_read_ended
  • claude_vault_read

Engagements and exports

  • engagement_created
  • engagement_extended
  • engagement_reopened
  • engagement_revoked
  • engagement_invitation_resent
  • auditor_first_access
  • pack_exported

Evidence packs

  • pack_made
  • pack_share_link_created
  • pack_share_link_revoked

Billing

  • billing_subscription_activated
  • billing_period_changed
  • billing_details_updated

R1-L review

  • R1L_CONFIRMED
  • R1L_REJECTED

Signed fields

  • actor
  • canonical_form_version
  • change_type
  • issued_at
  • new_state_hash
  • organization_id
  • prior_hash
  • prior_state_hash
  • receipt_id
  • signature_algorithm
  • signing_key_id
  • type
  • vault_id
  • version

Signed under v5-jcs since 27 October 2026, every field present and null when unset. Receipts issued before then were signed under v1-legacy, over fewer fields, and still verify.

Stored beside it, not signed

  • justification
  • affected_resources

Chain relationships

  • prior_hash links the previous RG of the organisation, or the genesis record, which is a link in the same chain, inside the signed fields. An RG issued before 27 October 2026 keeps it outside them: it holds the signature of the one before, or for the first, the genesis record's hash.
  • vault_id is null: governance belongs to the organisation, not a vault. A confirmation RG names the vault of the R1-L it reviews.
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 · v1.7.2 · no Déjà account required

  • Security & trust →

    Signing keys · key custody · row-level tenancy · DPA

  • Patents →

    Filed claim language · Edge Parser embodiment · USPTO record

  • Déjà →

    Product overview · pricing · audit-firm verification model

DSR/1.0 · Receipt Types
Maintained by Déjà · Patents: 18/668,178 + 19/430,349 + CIP March 2026 + SDE Provisional March 2026

Verifier CLI · Engine · System docs