Skip to content
How it works

One signal, end to end — including the ways out.

One incident signal, followed from the endpoint it lands on to the bundle your auditor checks on their own laptop — with every exit it can take along the way.

Most product diagrams show the path where everything works. This one shows every point where a signal can leave the path, because those are the majority — three of them end in a receipt, and the other two say why they don't.

Trace · one incident signal
Stages7Exit points5Weighted signals8
  1. 01 · inbound

    The signal arrives

    Your error tracker posts an event to a per-source endpoint. Déjà runs nothing inside your network. Besides receiving webhooks, it calls the APIs of the tools you connect, with the access you grant — for example to import past pull requests, fetch each merged pull request's files, and check once a day that the GitHub App is still installed.

    EventKeyError: total_centscheckout-api · 03:07:41
  2. 02 · authenticate

    Signature and freshness

    The payload signature is checked against the source secret, and the timestamp against the replay window. A rejected delivery is recorded with its rejection class.

    Exit A · Rejected→ no receipt

    Bad signature, unknown source or stale timestamp. No receipt is issued; the rejection is logged with its disposition and surfaces on the source's status.

  3. 03 · scope

    Vault and zone resolved

    The event is bound to one vault and one zone, and the binding is part of what gets sealed.

    Scopevault Payments platformzone checkout
  4. 04 · queue

    Queued for scoring

    A signal from Sentry, the signal source demonstrated end to end today, is queued for scoring, and nothing is sealed yet: its receipt is issued when scoring ends, at stage 05, 06 or 07, whether or not anything is found. Datadog, Splunk On-Call and Alertmanager · Grafana alerts are scored too, but not yet demonstrated end to end, and a Datadog alert ends only in a no-attribution record (R1-N). An ingestion receipt (R0), written on arrival before any analysis, is issued only for incidents posted to Déjà's own incident endpoint, on Enterprise and Sovereign plans where R0 is switched on.

    Jobqueued for scoringno receipt yet
    Exit B · Not scored yet→ no receipt

    Alerts from New Relic, Dynatrace, Honeycomb, AppDynamics and Splunk (alerts) are received but not scored yet, so they stop here with no receipt. Whether PagerDuty, AWS CloudWatch, Azure Monitor, Google Cloud Monitoring, incident.io, Rootly and FireHydrant incidents reach scoring is still being checked.

  5. 05 · eligibility

    Can this be scored at all?

    Attribution needs an affected field, a parseable language, a connected change source and a resolvable service edge. All four, or the gate isn't entered.

    Exit C · Not scorable→ R1-N

    No affected field in the signal — a threshold alert or a page. The receipt records the failed condition and the changes in the window, and stops there.

  6. 06 · examine

    Candidates enumerated and scored

    Producer-side changes in the lookback window are collected and each is scored against the affected field on eight weighted signals.

    Examined14 candidates · 30d windowscoring_version 1.0.14
    Exit D · Nothing cleared→ R1-N

    Scoring ran and no candidate reached the threshold. The receipt lists every change examined and the highest score reached.

  7. 07 · issue

    Receipt signed and delivered

    At or above the threshold the receipt carries the candidate, the score and the scoring version, and is signed. Inside the low-confidence band it is issued as R1-L instead.

    Receipte4a17c92-5b3d-4f08-9a61-2d7c8e0f4b19CCS 0.96 · signed
    Exit E · Low confidence→ R1-L

    A top score inside the 0.60–0.80 band whose 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. A record of uncertainty, not a finding — and if either condition fails, the incident gets an R1-N instead.

5 of the 7 stages can end the path. Three of the 5 still write to the ledger — that is the difference between a record of the period and a record of the successes. A delivery that fails authentication is logged against its source rather than sealed, because a payload we could not authenticate is not evidence of anything. An alert from a source Déjà does not score yet is received and gets no receipt, and the trace says so at stage 04 rather than leaving it out.

Setup

Roughly fifteen minutes, and nobody changes how they work.

There is no agent, no sidecar, no library to import and no change to your incident process. Déjà attaches to the tools that were already going to fire.

  1. Create the vault

    A vault is the organisation-level scope that owns a chain. Signup needs a work email address, because a vault is identified by an organisation rather than a person.
  2. Connect an error tracker

    This is the signal side. Déjà reads event payloads — error class, message, service, timestamp — and nothing else from that system. Sentry is the source demonstrated end to end today; the status page lists the rest honestly.
  3. Connect a change source

    This is the change side. Déjà reads merge and deploy metadata and the diffs needed to detect field-level changes. It does not clone your repositories or read code unrelated to a change.
  4. Sign the genesis receipt

    Written once at setup, with your organisation and the time inside the signature, as a link in your governance chain: every later governance receipt chains behind it, and the ledger is append-only, enforced in the database rather than by convention.
  5. Invite your audit firm

    Auditor access is scoped to an engagement, is read-only, and is itself recorded as a governance receipt. Auditors are never counted as seats and never charged for.
What Déjà reads

What it reads, and where it writes back.

Déjà approves nothing, remediates nothing and runs no agent in your runtime. Besides delivering receipts to the destinations you configure, it writes back in two places. 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.

For a security review: Déjà holds the credentials you connect with, so a compromise of Déjà exposes what those credentials allow — the reads, and the writes listed here. Nothing of Déjà's runs in your runtime or inside your network.

Secrets are per source and rotatable, with a 24-hour overlap window so a rotation doesn't drop deliveries. The rotation itself is sealed as a governance receipt, so the fact that a credential changed is part of the record rather than a line in someone's ticket.

Scopes and data handling

Reads
Error events, service names, timestamps
Reads
Merge and deploy metadata, changed-field diffs
Reads
Membership and role changes, for governance receipts
Writes
An event into Honeycomb when an incident is resolved (on by default); ServiceNow incidents, only with incident sync on; receipts, to the destinations you configure
Never
clones repositories or reads unrelated source
Never
trains models on your data or pools it across tenants
Network
Webhooks in, and calls out to the APIs of the tools you connect — nothing runs inside your network
Isolation
Every record is bound to one vault. Tenancy is row-level in a shared database
Scoring

8 weighted signals, published thresholds, no model.

There is no inference step and nothing is ranked probabilistically. The same normalised inputs and the same pinned scoring version produce the same result and the same score, which is what makes a second run a check rather than a second opinion.

The 8 weighted signals of the Causal Confidence Score, with the weight each contributes.
SignalWhat it asksWeight
W1 Field OverlapDoes the change touch the field the signal named?0.30
W2 Temporal ProximityHow close was the change to the failure?0.17
W3 Blast RadiusHow widely is the changed thing consumed?0.13
W4 Error Type MatchIs the operation consistent with the error?0.13
W5 Author HistoryHas this author broken this surface before?0.08
W6 Zone BoundaryDid the change cross a service-zone boundary?0.07
W7 Producer DistanceDoes a producer-to-consumer relationship exist?0.07
W8 Historical Schema StabilityHow long since the affected field last changed?0.05
Total1.00

And three gates, which are not weights

  • Deploy anchor

    Merged is not deployed. Where deploy anchoring is available it distinguishes the two; where it is not, the receipt records that the anchor was unavailable rather than assuming release.

  • Change site

    A low-confidence receipt additionally requires that 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. A candidate inside the band that meets none of these produces an R1-N, and the receipt records that the gate blocked it.

  • Eligibility

    An affected field, a parseable language, a connected change source and a resolvable service edge. All four, or scoring is never entered and the incident exits at stage 05.

  • Threshold

    0.80 to attribute

    At or above, the receipt names the candidate and carries the score, and is signed. Below, the incident takes one of the two exits beneath.

  • Low-confidence band

    0.60 – 0.80

    Inside the band, and with the change-site gate passed, the receipt is issued as R1-L: a record that something was found and that we are not confident in it. Below the band there is no candidate to be unsure about, and the incident gets an R1-N.

  • Version

    scoring_version 1.0.14

    Every receipt carries the scoring version that produced it, so a receipt from March is re-checkable against March's rules rather than today's.

Changing a weight changes the scoring version, and historical receipts keep the version that issued them. A vendor that can silently re-tune the thing that produced your evidence has not given you evidence. The weights above are the ones this build ships, read from the same constant the engine scores with.

Failure behaviour

What happens when something goes wrong on our side.

The question a security review actually asks is not how the product behaves when it works. These are the failure modes and what each one produces.

  • A source goes quiet

    Not detected yet

    Déjà does not yet alert you when a connected source stops sending, and in the ledger a quiet source looks the same as a quiet period. Until that exists, check a long silence at the source.

  • A delivery is rejected

    Rejections carry a disposition

    Bad signature, unknown source, stale timestamp, unhandled event type — each is recorded with its class rather than silently dropped, and surfaces against the source that sent it.

  • A secret is rotated

    Both secrets accepted for 24 hours

    The overlap window means a rotation doesn't lose deliveries, and the rotation is sealed as a governance receipt so the change is part of the record.

  • The fix doesn't hold

    The failure is on the chain too

    A resolution whose gates do not all pass gets its own receipt (R2-F), and a recurrence after one that passed is designed to be linked to it (R2-R) rather than start a fresh story. Both follow a resolution receipt. Most organisations get no resolution receipt (R2) yet: Déjà issues one only for an incident with an attribution receipt (R1), once 48 hours have passed since a user marked it resolved, and only if every gate then has a reading, which takes connected source control, Sentry, and Datadog (with a metrics read key) or New Relic.

  • Extraction fails

    Recorded, never guessed

    Where a field can't be extracted from a payload shape, the receipt says extraction failed. It does not fall back to a lower-confidence guess presented as a result.

  • We have an outage

    Queued, not lost

    Inbound deliveries are queued and processed when service resumes. A receipt sealed after a delay carries its own timing rather than pretending to be contemporaneous.

Every one of these produces something readable in your ledger. The failure mode we consider unacceptable is the silent one — a status indicator that stays green because the thing that would have turned it red was never recorded.

Verification

The last step happens on a machine we don't control.

Generate the period report for an audit engagement and hand its bundle to your audit firm. They run the open CLI against a published key on their own laptop — no Déjà account, no API call to us, no request we could refuse, delay or fail to answer. The ledger export takes up to 2,500 receipts at a time and leaves out RV and RE receipts. Each receipt in it is a signed file dsr-verifier-cli checks on its own, except an R0, R2-F or R2-R issued before those types were signed, which is sealed by a content hash and listed in checked-online.json for deja.dev/verify to check; the bundle the CLI checks as a whole is the period report of an audit engagement.

The check recomputes each receipt's canonical form and compares it to what was signed, checks that the pack's sequence numbers have no gaps, counts the receipts that pass by receipt type, and lists each one that fails by sequence number and receipt ID. Signed and sealed are different guarantees, and a receipt's type decides which one applies.

Signed receipts remain signature-verifiable offline, and exported bundles remain independently integrity-checkable, whether or not we are still here. That property is the reason an auditor should care about any of this.

On the auditor's machine

dsr-verifier-cli verify-bundle bundle.zip --key deja-managed-v1.pub

bundle
Payments platform · Q3 2026 SOC 2 audit · 36 receipts
key
ed25519:4f2a…c19b· published
manifest
valid· signature
signature
valid· 36 signed receipts
canonical form
match· recomputed
sequence
no gaps· 1–36
network calls
0
result
bundle verified

Fifteen minutes to the first sealed receipt.

Fourteen days to decide, and the trial is more useful with your audit firm in it than without.