Anchored to a real commit, or not published.
Change history is an audit artefact for the firms who buy this — at engagement time, “does the running version match the version that was audited” is a real question with a real answer. So this ledger records what actually shipped, on the date it shipped, against the commit that carries it.
- ledger opens
- 3 August 2026
- earlier history
- not backfilled
- entries
- anchored to deployed commits
Four rules, and the third one is the load-bearing one.
- Rule one
Deployed, not merged
An entry appears when the change is live in production. Code in main that hasn't shipped isn't a release, and a ledger that counts intent is a roadmap. - Rule two
Fixes are listed as fixes
Including the ones that reveal something was broken longer than we knew. A ledger of features with the defects edited out is marketing with dates on it. - Rule three
No status claims here
Connector maturity lives on the status page and moves only when something is demonstrated end to end. Shipping code is not the same as it working. - Rule four
Corrections stay visible
If an entry turns out to be wrong, the correction is added with the date it was wrong from. Entries are not silently edited or removed.
This ledger starts at its first entry rather than reconstructing the months before it. A backfilled history assembled from memory is exactly the artefact this product exists to replace.
What shipped, and when.
- Latest
Pages for buyers and auditors
deployed
New public pages for the people who evaluate Déjà before anyone uses it, and corrections to older pages that had drifted from the code.
ChangePages for buyers, procurement and audit firms
Integrations, For auditors, Financial services, Procurement, Use cases and Compliance, with pages for SOC 2, NYDFS Part 500 and ISO 27001. Each states what Déjà does not do beside what it does.
ChangeTwo addresses moved
/integrations-intro is now /integrations, and the security page is titled Security & trust, with /trust redirecting to it.
FixOlder pages corrected against the code
Pages that said no resolution receipt (R2) is issued now say when one is: only once every resolution gate has a reading, so most organisations get none yet. Pages that offered an isolated tenant now say tenancy is row-level in a shared database, and that a customer's own signing key is what Enterprise and Sovereign add.
Known limitOpen questions are shown, not filled in
Where the answer is the owner's to give, such as a SOC 2 report date, a dedicated deployment or the verifier's general release, the page says it is awaiting an answer rather than guessing one.
Sentry signing
160ebf44b · deployed
The Sentry Internal Integration path had never verified a webhook since it was built.
Signature verification used a secret Déjà generated, while Sentry signs with the Client Secret it mints and shows once. Every webhook on that path failed verification and was dropped. Fixed, and the wizard step that told customers to paste a value into a field Sentry does not have is corrected.
FixWebhook signature verified against the correct secret
The handler now decrypts the stored Client Secret and uses it for HMAC. Connections made before this change work without reconnecting, provided the Client Secret was pasted correctly at setup.
FixSetup instructions corrected
Step 4 previously displayed a "paste this into Sentry" secret. Sentry has no such field — the only value that goes into Sentry is the webhook URL. Anyone following the old instructions would have concluded they had made a mistake.
ChangeCatalogue labelling clarified
The Internal Integration path and the OAuth connection appeared as two similar entries with no guidance. The idle state now explains which is which.
Secret reveal
74ac5e47e · deployed
A customer who finished the connection wizard without copying their webhook secret had no way to retrieve it — the connected-state view deliberately omitted it, so the only route was rotation, which invalidates a working configuration.
ChangeMasked reveal with copy, on the integration's own page
Retrieves the stored value without rotating it. Rotation clears the revealed value and replaces it.
SecurityRevealing a secret writes a governance receipt
Actor, timestamp and integration are recorded to your ledger and are queryable like any other governance event. Viewing your own credential is an access event, so it produces evidence.
Backfill hardening
080ebb7ad · deployed
A rate-limited history import completed silently with an empty result.
When the change-source API returned 403 or 429, the fetch returned an empty list, so the job recorded success with no changes found — indistinguishable from a change that genuinely altered nothing. On a large import the whole queue could have drained to “completed” with a blank graph.
FixRate-limit responses now fail rather than return empty
The job stays queued and re-enters backoff, carrying the reset time in the error. Terminal failures are recorded and moved on rather than retried forever.
Fix"Fetch failed" separated from "nothing to parse"
Two states that previously shared one reason code. That distinction is the product, so it should not have been collapsed anywhere.
History import
deployed
Connecting a repository now imports its recent merged changes rather than starting from an empty graph. Previously a customer connecting a repository with years of history had nothing to attribute against until new changes arrived.
ChangeRecent merged changes imported at connection
The window matches the scoring lookback so the two stay in step. Repeat imports are safe — duplicate work is discarded rather than reprocessed.
Known limitOnly fires for new connections
Organisations that connected before this change do not re-import automatically. A re-sync action is planned; ask us in the meantime.
Scoring 1.0.9
deployed
The scoring version is now carried on every receipt type rather than only on successful attributions, so a receipt from any month is re-checkable against the rules that produced it.
Specscoring_version present on all attribution-lifecycle receipts
Including low-confidence and no-attribution receipts, which previously carried none — meaning the receipts that record uncertainty were the ones you could not reproduce.
SpecVerifier updated to include the field in the canonical form
Verifier and issuer must agree byte for byte, so both changed together.
Rejection visibility
4f73d1916 · deployed
Some inbound deliveries were dropped without producing any record at all.
A webhook arriving for a source with no matching integration was discarded silently, so a misconfigured connector looked identical to a quiet one.
FixEvery rejection records its class
Bad signature, unknown source, stale timestamp, unhandled event type — each is written with its disposition and attributed to the source that sent it.
Known limitConnector health is still not independently monitored
Rejections are recorded, but nothing yet detects a source that simply stops sending. See the status page.
Genesis signing
deployed
New organisations could not complete onboarding.
The genesis receipt — sequence zero, the root of a vault's chain — failed to sign, so no vault created during the affected window could produce receipts. Fixed, then hardened with deterministic ordering and a transaction around the re-anchoring step.
FixGenesis signing restored
Verified by creating a vault from scratch and confirming the chain advances from sequence zero.
SecurityRe-anchoring made deterministic and atomic
Receipts buffered before genesis are re-anchored in a fixed order inside a single transaction, so the resulting chain is the same every time.
The rules, in full.
- Cadence
- Published as changes deploy — not on a release calendar. A slow week here means a slow week, not a batching policy
- Scope
- Anything a customer or an auditor could notice: behaviour, receipt content, security posture, connector state, and defects that were live in production
- Anchoring
- A commit reference where the change is a single deployment. No reference rather than an approximate one
- Spec changes
- Anything altering a receipt's canonical form ships with the matching verifier change, and both are named in the same entry
- Breaking changes
- Flagged in the entry and announced in advance. An issued receipt never changes — its canonical form is fixed at issuance and later versions do not reinterpret it
- Notifications
- Email subscriptions are not built yet, so we are not collecting addresses that would go undelivered
On the fixes above. Several of these entries describe defects that were live for weeks — a connector that never verified a signature, deliveries dropped with no record, an import that reported success while doing nothing. Publishing them costs something. Not publishing them would cost more, from a company whose product is the difference between "we found nothing" and "we couldn't look." If we ever stop listing that category here, that itself is the signal.
Three things deliberately absent.
- No history
Nothing before 3 August 2026
The platform existed and changed, but the record was not kept contemporaneously — and a history reassembled afterwards from memory is precisely what we tell customers not to accept. - No roadmap
No "coming soon" entries
Planned work belongs in a conversation, not in a ledger of what happened. Everything here has shipped. - No self-grading
No health scores, audit pass-rates or clean-sweep counts
A number we assign ourselves is not evidence, and this is the wrong site to publish one on.