The spec is the product.
Everything Déjà produces is a receipt in an open format, verifiable by a tool we don't control against a key we publish. The format, the signing scheme and the verification procedure are documented here — because a proprietary evidence format is a contradiction in terms.
Nine classes, and the integrity column is the one to read.
- receipt classes
- DSR/1.0.2 · rev 1.0.2
- schema
- standard.deja.dev/v1/schema.json
- canonicalisation
- JCS · RFC 8785
| Class | What it records | Integrity | Issued when |
|---|---|---|---|
| GENESIS | Sequence zero — the root of a vault's chain | Signed | Once, at vault creation |
| R0 | An incident posted to Déjà's own incident endpoint arrived, with its content hash and timestamp. No provider webhook issues one | SignedContent hash before 27 October 2026 | On arrival, before any analysis — Enterprise and Sovereign, where switched on |
| R1 | A producer-side field change scored at or above threshold for the affected field the signal carried | Signed | When scoring clears the threshold |
| R1-L | Low confidence — a leading candidate below threshold, or two candidates inside the tie band | Signed | When scoring runs but does not resolve |
| R1-N | No attribution — either scoring ran and nothing cleared, or the signal was not scorable and the gate was never entered. The receipt says which | Signed | Whenever attribution does not produce a candidate |
| R2 | A resolution was recorded against a prior attribution | Signed | When a fix is attested |
| R2-F | The recorded resolution failed | SignedContent hash before 27 October 2026 | When a fix does not hold |
| R2-R | Recurrence — the same field broke again, linked to the original rather than starting a new story | SignedContent hash before 27 October 2026 | On a repeat of an attributed failure |
| RG | Governance — connector grants, key rotations, zone locks, membership and role changes, auditor engagements, secret reveals, destruction | Signed | On any governed action, incident or not |
The schema is authoritative — if this table and schema.json disagree, the schema is right and this page is a bug. The integrity column matters: signed and content-hashed are different guarantees, and every bundle states which applies per receipt. A content hash bounds what the receipt says; a signature also binds it to the holder of a published key. Vaults on Déjà's managed key sign with Ed25519, and every managed vault shares that one key. Enterprise and Sovereign vaults can sign with their own AWS KMS key instead, using RSA-PSS or ECDSA. Déjà's managed key is published with any key it has retired, so receipts signed with it verify offline. For vaults on their own KMS key, Déjà publishes the current public key of at most one such vault per organisation and no key that has been rotated out, so any other key an auditor needs comes from the customer.
Each class in detail: receipt types.
Three steps, and only one of them is ours to do.
Setup runs in the browser — there is no CLI to install and nothing to add to your codebase. The only command-line tool in the product is the verifier, and it's the one your auditor runs, not you.
- Step 01
Create the vault
Sign up with a work email address and name your organisation. A vault is the org-level scope that owns a chain, so personal domains are declined at signup. Your genesis receipt is sealed here. - Step 02
Connect two sources
An error tracker for the signal side and a change source for the producer side, both read-only, from the Connections page. Send one real event to confirm the path end to end before you rely on it. - Step 03
Verify a receipt
Confirms the signature covers the JCS-canonical payload and the receipt conforms to the schema. Runs with networking disabled, with no account.
# fully offline · no account
dsr-verifier-cli verify receipt.json --key deja-managed-v1.pubStep 02 is the one that deserves the extra minute. A connector that reports connected has not proven it delivers. Send a real event from the vendor and confirm a receipt appears before you consider the source live — that check is the difference between a working integration and one that looks working.
Which sources are scored, and what every other connector does today: integrations.
A failure your code catches and only logs never reaches the tracker, so it never reaches Déjà. Making failures observable shows the change for three common patterns, and what each costs.
DSR/1.0.2 — open, by necessity.
Every receipt is validated against the published JSON Schema. The specification defines the envelope, the signing algorithm — Ed25519 over a JCS-canonical payload per RFC 8785 — the verification procedure, and each receipt class in the table above.
Canonicalisation is the part that carries the weight. Two implementations reading the same receipt must produce byte-identical canonical form or verification is meaningless, which is why the standard names an existing RFC instead of inventing a serialisation. If our verifier and yours disagree about a receipt, that is a bug in one of them and we want the report.
The schema is machine-readable and publicly hosted, so you can validate a bundle in your own pipeline without our tooling at all.
Verifying a bundle · your auditor's machine
- Signature · over the canonical payload
- valid · 36 signed
- Canonical form · recomputed
- match
- Sequence · the pack's file numbers
- no gaps · 1–36
- Passes · counted by receipt type
- 36 / 36
- Failures · by sequence number and receipt ID
- none
- Network calls
- 0
$ dsr-verifier-cli verify-bundle bundle.zip --key deja-managed-v1.pub
Delivery is downstream-only, always.
Delivery has zero effect on how receipts are issued, signed or appended. A delivery outage never loses a receipt — the ledger is written first and the channel reads from it.
| Channel | Destination | Status | Notes |
|---|---|---|---|
| Outbound webhook | Your HTTPS endpoint | Demonstrated | HMAC-SHA256 signed payload, retry with backoff, and secret rotation with a 24-hour dual-signing overlap so a rotation never drops a delivery. |
| Recipient addresses | Supported | Recipient double opt-in and an unsubscribe link on every message. | |
| Slack | Workspace incoming webhook | Supported | Posts to a channel, attach-only. Connected but not yet demonstrated end to end by us. |
| ServiceNow | Your instance, via OAuth | Beta | Built and not yet validated against a live instance by us. Behaviour described below is the intended contract — confirm it in your own trial before relying on it. |
| Jira Service Management | Atlassian cloud, via OAuth 3LO | Beta | Same position as ServiceNow. Sandbox validation is on the list, not behind us. |
| ServiceNow GRC | One control on your instance, via OAuth | Beta | Every receipt attached as evidence to one GRC control you name: the signed receipt and its PDF. Built and not yet validated against a live instance by us. |
| Archer | One record on your instance, via its REST API | Beta | Every receipt attached as evidence to one record's Attachment field you name, keeping what is already there: the signed receipt and its PDF. Built from the published Archer REST API shapes and not yet validated against a live instance by us. |
| Vanta | Documents linked to your SOC 2 controls, via an API application | Beta | Each attribution and no-attribution receipt filed as SOC 2 evidence under the controls Déjà maps it to, as the signed receipt. Test and synthetic receipts are never filed. Built to Vanta's published API and not yet run against a live account by us. |
| Drata | Your SOC 2 controls, via an API key | Beta | Each attribution and no-attribution receipt filed as external evidence on the Drata controls Déjà maps it to, as the signed receipt. Test and synthetic receipts are never filed. Built to Drata's published API and not yet run against a live account by us. |
- Matching
Exact equality, never a guess
You tell Déjà where your alerting tool writes the alert key — a correlation field, a label, a custom field. Déjà queries for equality, never a contains or text search. One match attaches. Zero holds for the configured window then goes Unmatched. Two or more goes Unmatched immediately — it never picks one.
- Attach-only
The channels attach; three settings write more
The ServiceNow and Jira Service Management channels write a work note or internal comment plus a signed attachment to a record that already exists. They do not create, transition, assign, reassign or resolve anything, and request only
readandwritescopes — never admin or transition. Every attempt is logged. Three ServiceNow settings write more, and each is off until you set it up: the connection on the ServiceNow settings page creates a record in the table you choose for each receipt above your threshold; custom-field stamping writes Déjà's fields onto the matched incident; and incident sync creates and updates incidents from Déjà's own. - On failure
A lost delivery is not a lost receipt
The receipt is signed and on your ledger regardless of delivery state. Unmatched and failed jobs can be retried automatically or matched by hand from the Connections page.
What lands on the ticket: a comment carrying the receipt ID, the attribution, the score, and the exact dsr-verifier-cli verify command — plus the signed receipt JSON as an attachment. Download the attachment and verify it offline against the published key; the file contains the payload as signed.
What is documented, and what isn't yet.
Docs that quietly omit their own gaps waste your afternoon. This is the current state.
- stable
The specification and the verifier
The receipt format, canonicalisation, signing scheme, schema and verification procedure are stable and published today. If you are evaluating whether the evidence model works, everything you need is already here. - stable
Delivery semantics
Matching rules, attach-only behaviour, scopes and failure handling are documented above and are the contract we hold ourselves to, including on the channels still in beta. - thin
Per-connector setup guides
Setup currently runs through the in-product wizard rather than written guides. We are walking each connector end to end against the real vendor and correcting the instructions as we go — a process that has already found steps that asked for things the vendor doesn't have. - thin
Language SDKs
There is a public REST API (v1, described in OpenAPI at /api/v1/openapi.json) for reading receipts, vaults, engagements, evidence packages, frameworks and the audit log, for verifying a receipt, and for creating and revoking API keys. Keys are scoped and expiring, and an Owner or Admin creates them under Settings › API keys. There is no SDK and no CLI for setup. - missing
Walkthroughs and worked examples
Interactive guides and a full documentation site are planned. Until they exist, a security review or a trial conversation is the faster route, and you will be talking to someone who wrote the thing.
Public API. The OpenAPI 3.1 description of v1 is at /api/v1/openapi.json, readable without an account. The data endpoints take an API key, scoped to one vault or to your whole organisation.
If a document you need is missing, ask — the answer is either a link, a written response within a day, or an honest "we haven't written that yet."
Verify a receipt before you believe a word of this.
The spec and the verifier are the two things you can check without us in the room. Start there — it's the fastest way to find out whether the evidence model does what the rest of the site says it does.