What we process, and what we keep.

Where these definitions conflict with the principal services agreement, this addendum controls on matters of data processing, privacy and security.

Payload Data

Technical input sent by a connected tool: webhook bodies, error events and pull-request diffs. We keep the parts listed under "Kept" for as long as §8 says, and use them only to produce, verify and explain receipts.

Metadata

Derived hashes, bounded identifiers, receipts, correlation records, ingest-rejection diagnostics and retry envelopes.

Customer Data

Payload Data and Metadata together, for which the customer is controller and Déjà is processor.

Subprocessor

A third party engaged by Déjà to process Customer Data on our behalf. Listed in §6. Destinations you direct receipts to are not subprocessors — see §6.

Déjà acts solely as processor for Customer Data. For account data we collect directly from users, we are the controller; that processing is described in the privacy policy.

Payload Data is received over TLS. What we keep of it is listed above, under Kept; the rest is held in memory only while the request is handled.

Two failure paths write bounded metadata, described in the frame above and repeated here for completeness: structured ingest-rejection diagnostics with a 90-day time-to-live, and normalised retry envelopes containing validated structured fields with a 30-day time-to-live. Neither contains the raw request body.

The most sensitive things we hold are the diffs of your pull requests, with secrets removed, and the text of the errors your monitoring sends us. We never hold a copy of a repository.

We process Customer Data only on your documented instructions and only for the purposes in the principal agreement. We will not:

• Use it for marketing or analytics directed at any identifiable data subject
• Combine it with another customer's data to produce benchmarks, aggregates or comparative analytics
• Sell, rent or transfer it to any third party for that party's own purposes
• Permit onward processing by anyone outside §6, except where the law requires and after telling you where we lawfully can

If we believe an instruction from you would breach data protection law, we will tell you promptly and are not obliged to follow it.

We do not train, fine-tune or improve any machine learning, language or generative model using Customer Data. This flows down to every subprocessor by contract.

• No training of models, fine-tuning datasets or evaluation suites
• No embedding or similarity index built from Customer Data for training purposes
• No subprocessor agreement granting a training right, however it is characterised — "service improvement", "abuse detection" and "telemetry" included

The controls below are the ones we can evidence today. Detail on what each rests on — and what we do not yet claim — is on the security page.

Encryption in transit

TLS 1.2 or higher, and TLS 1.3 where the client supports it, for all traffic carrying Customer Data

Encryption at rest

AES-256 over retained metadata, signing keys, governance entries and configuration, with managed key rotation

Tenant isolation

Row-level security policies, enforced by the database, scope each customer's requests through the application to that customer's organisation. Background processing runs on a privileged connection, where tenant isolation is enforced in the application's queries and checked by automated tests. Vaults on Déjà's managed key share one signing key; Enterprise and Sovereign vaults can use their own.

Ledger integrity

Append-only. DELETE and TRUNCATE are rejected by database triggers on every receipt table, and UPDATE is rejected except to record a review decision or fill an empty link or hash once. A change to a signed field breaks its signature

Access control

Least privilege for personnel; multi-factor authentication required for production access

Access logging

Operator actions against a customer vault write governance receipts into that customer's own ledger — including revealing an integration secret, where one can be displayed at all

Key management

Déjà's managed signing key is held as an encrypted secret in our hosting environment, never in the database; Enterprise and Sovereign vaults can sign with their own key in AWS KMS.

Personnel

Confidentiality obligations surviving engagement; access limited to the smallest set of people who need it

We engage a deliberately small chain. Each is bound by terms at least as protective as this addendum, including the covenant in §4.

Change notice. At least 30 days' written notice before adding or replacing a subprocessor, except where an urgent security or legal circumstance requires shorter. You may object on reasonable grounds and we will work in good faith to find an alternative.

This list is mirrored on the security page, which is the canonical version. Where the two differ, the security page controls.

We assist you in meeting requests under Articles 15 to 22 and equivalent provisions elsewhere.

• Access — we provide the means to retrieve metadata associated with an identified data subject within the platform's data model
• Rectification — customer-controlled fields can be corrected directly. Signed receipts cannot be modified after issuance; the route is deletion under §8, not amendment
• Erasure — executed as customer-initiated deletion under §8
• Restriction — processing from a source stops when you disconnect it; data already received and receipts already issued are kept
• Portability — export of your receipts in documented formats at any time during the term
• Objection — forwarded to you; we act only on your documented instructions

We do not respond directly to data subjects on your behalf. A request reaching us is forwarded to you within five business days, and the data subject is told we have done so.

Retention is fixed by your tier, not set per vault: incidents are kept for two years on Charter and five years on Standard, and are not removed on a schedule on Enterprise and Sovereign. Signed receipts, and any incident a receipt points to, are kept on every tier.

Deletion is performed by secure removal of Customer Data records from our storage systems, and confirmed to you in writing within 30 days of your request. The confirmation describes the method applied and the scope of data removed. A signed deletion receipt in your exported ledger is on the roadmap, not current.

On termination you may export your receipts at any time. Data is then destroyed on your instruction and on your schedule. Governance entries describing the deletion event itself — who initiated it, when, and its scope — are kept for the life of the vault and contain no Customer Data.

Receipts you have already exported are outside our control. Bundles held by your audit firm are, by design, beyond our reach; our deletion commitments apply to what we hold.

All Customer Data is currently processed and stored in the United States. Where data is transferred from the EEA, the UK or Switzerland, the transfer relies on Standard Contractual Clauses or another recognised mechanism, executed as part of the signable copy of this addendum.

EU regional infrastructure is planned. We are not publishing a date for it here, because a date on a legal page becomes a commitment — ask us for the current position and you will get the honest one.

We will not transfer Customer Data to a jurisdiction in a way that conflicts with an applicable adequacy decision, except where the law requires it and we have told you where we lawfully can.

We notify you of a personal data breach affecting Customer Data without undue delay and within 72 hours of becoming aware of it. The notification includes, so far as known: the nature of the breach and the categories and approximate number of records affected; the likely consequences; the measures taken or proposed; and a named contact for updates.

We assist you in meeting your own notification obligations to supervisory authorities and data subjects.

Anything affecting the integrity or completeness of evidence is disclosed to you even where no data subject is affected and no law requires it. A silent failure in an evidence product is the failure that matters most.

We make available the information reasonably necessary to demonstrate compliance with this addendum, including subprocessor documentation for anyone listed in §6, and our security control narrative and current gap list — the latter available now, without an NDA, because a gap list is more useful to you than a certificate we do not hold.

Attestation reports will be available under NDA on completion. We are not listing target dates in this addendum; the status page carries the current position and is updated as it changes.

On-site audits may be requested by customers in regulated industries no more than annually, on at least 30 days' notice, at your expense and subject to scope agreement and our reasonable security requirements. Findings are addressed in a remediation plan with timelines proportionate to severity.

Term. Effective from the date above and continuing for as long as we process Customer Data on your behalf. Provisions on deletion confirmation, breach notification and audit support survive termination for as long as needed to give effect to data subject rights.

Liability under this addendum is subject to the limitations in the principal agreement. Nothing here limits liability that cannot lawfully be limited.

Modifications. Material changes are notified at least 30 days in advance and published here with a revised version number. Non-material changes take effect on publication. Prior versions are available on request.

Precedence. Where this addendum and the principal agreement conflict on data processing, privacy or security, this addendum controls. Where this addendum and the security page differ on the subprocessor list, the security page controls.