What we hold, and what we never take.

Déjà, Inc. operates an evidence-custody service for organisations. This policy covers two distinct relationships, and which one applies changes who you should talk to.

• Where we are the controller: information we collect directly from you — your name, work email, the hash of your password, your organisation's domain, sign-in provider identifiers, and usage data generated by your use of the product.
• Where we are the processor: everything ingested from tools your organisation connects, processed on their instruction. Your employer is the controller for that data. Requests about it should generally go to them; we assist as set out in the Data Processing Agreement.

Enterprise customers sign a DPA. Where it differs from this policy, the DPA governs.

Account data — you give it to us

• Work email address, and your organisation's domain, which identifies your vault
• Name, if you enter one
• A hash of your password. The password itself is never stored
• Identifiers from a sign-in provider, if you use one
• If someone asks you to complete one step of their set-up, we create an account for the address they invited, which holds only that address and your authenticator enrolment.

Service data — you authorise us to process it

• Event payloads sent by the tools you connect, read at the moment they arrive
• Change metadata from your source-control provider, including the author each change is recorded against
• The receipts we produce, and the governance entries recording administrative actions in your vault

Usage data — collected automatically

• IP address and the approximate region derived from it
• Browser, operating system and device type
• Pages and features used within the product
• Session cookies that keep you signed in, and error logs used to diagnose faults

• To operate the service — sealing signals, examining changes, issuing and delivering receipts
• To authenticate you and protect your vault from unauthorised access
• To send service messages: verification, password reset, receipt delivery, security notices
• To answer you when you contact us
• To find and fix faults, and to detect abuse or security incidents
• To meet legal obligations, including responses to valid legal process

Aggregate usage patterns inform product decisions. Individual customer data does not leave the purpose it was collected for.

• We do not sell your data, and we do not share it with advertisers, data brokers or marketing partners
• We do not use customer data to train models. The attribution engine is deterministic — there is no learning step anywhere in it
• We do not pool data across customers. Every record is bound to one vault
• We do not read from your systems except through the connections you authorise. We never clone a repository. When you connect GitHub, we import up to two years of merged pull requests, including their changes. When an incident is resolved, we post an event into Datadog, New Relic or Honeycomb if you have connected them, and if you turn on ServiceNow incident sync we create and update incidents there. Where you configure a delivery destination — a Slack channel, a ticketing instance, your own webhook — we write there, because that is what you asked for, and only what §5 describes
• We use no advertising cookies, tracking pixels, or analytics that share data with ad networks

These providers process data on our behalf. Each is bound by contract to use it only to provide services to us. We give 30 days' written notice before adding or changing a subprocessor, and enterprise customers may object under the DPA.

Delivery destinations you configure are not subprocessors. Where you direct receipts to a system you operate — your own webhook endpoint, your own ticketing instance — that destination is under your control and requires no change to this list.

We may also disclose data where required by law under valid process, where you explicitly ask us to, or in connection with a merger or acquisition, in which case you will be notified and may terminate.

Receipts

Kept for the life of the vault. They are append-only and are not deleted on a schedule; they leave only when you delete the vault's records under §7.

Governance entries

Kept for the life of the vault. These are not trimmed on a schedule: each one chains to the one before it, so removing the oldest would break verification of every entry after it. Where volume becomes a problem the answer is archival, not deletion.

Account data

The life of the vault, plus 30 days after deletion

Inbound event logs

90 days, for fault diagnosis

Usage data

12 months in identifiable form; aggregate data may be kept longer

Session data

Until the session expires

On termination you can export your receipts at any time before your data is destroyed. After export, data is destroyed on your instruction and on your schedule.

This section exists because our product has a property most services don't, and we'd rather set it out plainly than have it discovered.

Receipts are append-only. Once issued, a receipt is never edited or removed — the constraint is enforced in the database, not by policy, and the evidential value of the whole chain depends on it. Receipts contain personal data: the author your source-control provider records against a change; the person who took an administrative action, by account, email address or source-control login; and the text of the error an incident receipt describes.

Two consequences follow.

• Deletion is not editing. Where data must be removed, the route is deletion of the vault's records under the retention terms above, not modification of individual receipts. We cannot silently alter a receipt for anyone, including for ourselves.
• Exported bundles are outside our control. Evidence bundles are designed to be held by your audit firm, on their systems, indefinitely. Once exported, we cannot reach those copies — that independence is the point of the product, and it means our retention and deletion commitments apply to what we hold, not to what you have distributed.

If you are an individual whose change is recorded in a customer's ledger, your employer is the controller of that record. Contact them first; write to us at privacy@deja.dev and we will assist them as the DPA requires.

Depending on where you live, you may have rights to access, correct, delete, port, or object to the processing of your personal data. To exercise any of them, write to privacy@deja.dev with "Privacy Request" in the subject line. We will verify your identity before acting, and respond within the period applicable law requires.

Where the data concerned is processed on behalf of a customer, that customer is the controller. Send your request to them; we will support them in answering it.

Exercising these rights costs nothing and we will not treat you differently for doing so.

We use three kinds, and none of them are for advertising.

Authentication

keeps you signed in. Required; blocking it prevents sign-in.

Security

request forgery protection and abuse detection. Required.

Preferences

remembers settings. Optional.

No advertising cookies, no third-party tracking pixels, and no analytics that share data with ad networks. You can control cookies in your browser settings.

Déjà stores and processes all customer data in the United States. Storage in other regions is not offered yet. The region a vault was established in is recorded inside its genesis receipt — the first link of its chain, which carries the full self-verifying payload and can be checked offline.

If you access the service from outside the United States, your data will be transferred to and processed in the United States. Where the law requires a transfer mechanism, we put appropriate safeguards in place and will provide the details on request.

• Encryption in transit and at rest, with managed key rotation
• Vault-scoped separation enforced at the data layer, not by application logic
• Access to customer data limited to the smallest set of people who need it, and recorded. Where one of our staff operates inside your vault, the session is read-only at the server level — an attempted write is refused and logged, not permitted and noted afterwards
• Administrative actions against your vault write governance receipts into your own ledger, so our access is auditable with the same evidence as everything else. Where an integration secret can be displayed back to you at all, doing so writes one of those receipts naming who revealed it and when

No system is perfectly secure. Where an incident affects the integrity or availability of your evidence, we will tell you — including where no customer noticed. Detail on what each of our security claims rests on, and what we don't yet claim, is on the security page.

We may update this policy. For material changes we will email you and post a notice in your vault at least 30 days before they take effect, and the effective date at the top of this page will change. Previous versions are available on request.

Privacy questions and data-subject requests: privacy@deja.dev. Security and vulnerability reports: security@deja.dev. Anything else: talk to us. The controller is Déjà, Inc., a Delaware corporation.