Organised for lookup, not for reading.

Spec

DSR/1.0

Contents verified

22 September 2026

Sections written

7

Sections absent

5

Where this page and schema.json disagree, the schema is right and this page is a bug. Connector state is not published here — it lives on the status page and moves only when something is demonstrated end to end.

1. 01

   Vocabulary

   Every term the system operates on.

2. 02

   Data model

   Entities, mutability and enforced invariants.

3. 03

   Normalisation

   What is hashed, and what each hash is for.

4. 04

   Scoring

   The eight weights and both thresholds.

5. 05

   Receipt taxonomy

   Classes, integrity property, retention.

6. 06

   Change management

   How the spec evolves without breaking auditors.

7. 07

   Non-goals

   What Déjà deliberately does not do.

The terms the system operates on.

Vault

A container for receipts, scoped to one customer organisation. Every receipt belongs to exactly one vault, and cross-vault access is forbidden at the storage layer. Backed by the products table internally — an early naming that survives for migration safety.

Receipt

A record of one event in the evidence lifecycle, conforming to DSR/1.0. Sealed at issuance with a content hash, and signed — Ed25519 on Déjà's managed key, RSA-PSS or ECDSA on a vault's own KMS key. R0, R2-F and R2-R receipts issued before 27 October 2026 carry the content hash alone. Updates and deletes are rejected by database triggers, and a change to a signed field breaks its signature.

Schema Deduction Engine

The deterministic pipeline producing attribution outcomes from webhooks: ingest, parse, score, sign. No inference step and no learned weights at any stage.

Confidence score

A composite in [0, 1] from eight named factors. Attribution threshold 0.80; low-confidence floor 0.60. Fully decomposable: an attribution receipt signs the total with two of the factors (W7 and W8), and keeps all eight beside it.

Producer graph

A directed graph of schema-producing services and their consumers, built from merged change metadata. Each node is keyed on the change and stores the typed schema delta extracted from it.

Zone

A logical service boundary, typically aligned with a domain or topic. W6 scores a change from the incident's own zone 1.0 and one from another zone 0.0, so a cross-zone change needs more of its evidence from the other seven factors.

Fingerprint

Two SHA-256 hashes, for two jobs. The incident fingerprint covers the error type, the service zone and the normalised first line of the alert title, and finds earlier resolutions of the same error. For Sentry events, a stack hash covers the application's frames without line numbers, and finds similar past incidents. Neither is a scoring input: candidate changes are found by field name.

Governance log

Append-only record of grants, rotations, access, membership changes and operator actions. Writes only, enforced below the application layer, and it cannot be switched off.

Entities, mutability, and invariants.

Not everything is reduced to a fact. A merged pull request's diff text is stored with secrets scrubbed; each matched diff line is kept, cut to 200 characters; and error-tracker events are stored as delivered — for Sentry, with the stack trace, tags and user id.

• Everything is vault-scoped

  Every row carries its vault, and the isolation is enforced by row-level policy rather than by a WHERE clause an application could forget.

• The governance log cannot be edited

  Update and delete are rejected by database triggers on the governance and audit tables, below the application layer. A schema migration can lift a trigger, and one has: 0188 backfilled an organisation id on audit rows and re-enabled the triggers in the same transaction.

• Signed fields are fixed at issuance

  The canonical form is computed once and signed. A later spec version does not reinterpret it, and the scoring version travels on the receipt so the rules that produced it stay identifiable.

• Diffs are kept, scrubbed

  A merged pull request's changed-file list is stored with its diff text, secrets scrubbed before anything is written, beside the typed schema delta extracted from it.

Two hashes, two jobs.

Two occurrences of one fault should hash the same, so a new incident can be matched to an earlier one and its resolution. Neither hash takes part in attribution, which finds candidate changes by field name. These are the parts each hash ignores.

• Error type

  Used as the alert source gives it, lowercased: for Sentry, the first word of the issue title; for Datadog, the error type with an Unhandled, Uncaught or Fatal prefix removed, or a category read from the monitor or check; PagerDuty and Splunk On-Call alerts each carry one fixed label.

• Title line

  Only the first line is kept. UUIDs, ISO timestamps, hex addresses, line:column positions and numbers of four or more digits become placeholders; file paths and shorter numbers stay, so they still tell two faults apart.

• Stack frames

  Sentry events only, and only in the stack hash. Library frames are dropped and line and column numbers removed, so code moving within a file keeps its hash; a minified stack falls back to its top three frames, marked low fidelity.

Eight named factors. Published weights.

No model, no learned weights, no inference. Every factor is named, weighted, versioned, and carried on the receipt it produced — so a receipt from March is re-checkable against March's rules rather than today's.

0.80 and above

Attribution threshold

The receipt names the candidate and carries the score.

0.60 – 0.80

Low confidence

Issued as R1-L with the highest score reached — a record of uncertainty, not a finding — when the top 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. Otherwise an R1-N that records the gate blocked it.

Below 0.60

No attribution

Issued as R1-N listing what was examined and the highest score any candidate reached.

Changing a weight changes the scoring version, and historical receipts keep the version that issued them — currently 1.0.14. A vendor able to silently re-tune the thing that produced your evidence has not given you evidence.

Class, integrity property, retention.

Integrity is the column to read. “Signed” and “sealed” are different guarantees, and every exported bundle states which applies per receipt rather than asserting one word across all of them.

Retention. Retained. No receipt class is deleted by the retention sweep, and database triggers reject deletes on every receipt table. Customer-invoked erasure with its own signed deletion receipt is not available yet. Exception classes are never counted against any plan limit on any tier.

Verifier exit codes · v1.7.2

0

Verified. Every check passed — signature or content hash matches and the receipt conforms to the schema.

1

Verification failed. A check did not pass and the verifier COULD reach a verdict — this is the tampering-shaped result. It is not returned when the verifier merely cannot read the receipt; that is 5.

2

Parse error — the receipt file is malformed and could not be read as a receipt at all.

3

Missing file — the receipt or the key file was not found.

4

Key error — the key file is not a valid Ed25519 public key.

5

Cannot verify — the verifier cannot produce a verdict, because the receipt declares a canonical form this build does not know or the export is incomplete. Distinct from 1 by design: an unreadable receipt is not a finding of tampering.

How the spec evolves without breaking auditors.

Receipts are verified months or years after issuance, often with a verifier version different from the one that produced them. Backward compatibility here is a commitment to a regulated reader, not an engineering preference.

Versioning

MINOR versions never remove

New fields may be added; existing fields are never removed or repurposed. New fields are optional, so receipts issued before a field existed simply omit it and older verifiers ignore what they don't recognise.

Issued receipts

Never reinterpreted

A receipt's canonical form is fixed at issuance. A later spec version does not change what an earlier receipt means, and the scoring version travels on the receipt so the rules that produced it are identifiable. Current scoring version 1.0.14.

Breaking changes

Six-month minimum window

Any breaking change is announced with a migration path at the start of the window. A MAJOR version change requires an explicit verifier upgrade rather than happening underneath anyone.

Governance

Spec changes are public

Changes to DSR/1.0 are published before adoption. Charter customers hold seats in the working group that reviews them.

What Déjà deliberately does not do.

Stated so category-fit evaluation takes minutes instead of a discovery call. None of these is a roadmap item held back — they are boundaries the design depends on.

• Not a logging platform

  Déjà does not store, search or retain log content. It reads event metadata and discards payloads after extraction.

• Not an APM

  No spans, no traces, no runtime metrics. Attribution works without distributed tracing, which is the point rather than a limitation.

• Not an alerting tool

  Receipts are produced and delivered to channels. Déjà never pages anyone, and it sits behind your paging tool rather than in front of it.

• No anomaly detection or learning

  The score comes from named factors with published weights. Nothing is inferred, ranked probabilistically or learned from your data.

• Not a substitute for incident management

  It augments the tools that run your incidents. Postmortems remain useful as explanation; they stop being the record.

• Never approves or remediates

  No approvals, no remediation, and nothing running in your runtime. Déjà writes where you configure a destination — a Slack message, a ticket, or a ServiceNow record or work note with the signed receipt attached — and in two places besides. When an incident is resolved in Déjà, it posts an event into Honeycomb if Honeycomb is connected. That is on by default, and disconnecting Honeycomb stops it. If you turn on ServiceNow incident sync, which is off by default, Déjà also creates and updates incidents in your ServiceNow instance.

5 sections that don’t exist yet.

Listed as absent rather than filled with an outline of what they would contain. A reference that pads its gaps is harder to trust on the sections it does have.

Configuration reference

Not written. Setup is wizard-driven today.

Performance and scaling

Not written. No production baseline to publish.

Failure semantics

Not written. Partial detail on the status page.

Threat model

Not written. See the security page meanwhile.

Troubleshooting

Not written. See the security page meanwhile.