Data processing addendum

This is the outline of the data processing addendum Bucker would sign with a customer, with each clause filled in only as far as the repository can support it. Where a clause depends on a commitment that does not exist yet — a named entity, a sub-processor list, a breach notification window — it says so. The trust page and the SOC 2 readiness note say the same things at greater length, and no statement here should be read as stronger than the one there.

1. Parties and roles

• Controller: you, the customer organization.
• Processor: the operating entity of Bucker, not yet named in this draft.

2. Subject matter and duration

Processing of the personal data contained in error telemetry, session replay, logs, traces, AI-application telemetry, account data and the audit trail, for as long as the customer holds an account, and thereafter for the retention windows in §8.

3. Nature and purpose

Receiving, grouping and storing error events; projecting issues for a coding agent; running proposed fixes in a sandbox; recording human approval decisions; alerting; and the compliance functions in §7. Root-cause analysis and fix authoring send scrubbed issue content to a model provider (§6).

4. Categories of data subjects

• The customer's staff and contractors who hold accounts.
• End users of the customer's applications, whose errors, sessions and console messages are captured.
• AI agents acting as principals under a human sponsor, to the extent their identifiers are personal data.

5. Categories of personal data

• Account data: email address, display name, password hash, encrypted TOTP secret, directory identity where SSO or SCIM is configured.
• Identifiers in telemetry: user ids the SDK attaches, email and IP addresses inside exception messages and request metadata, release and environment context.
• Session replay: interaction events as described in session replay and privacy, including console messages captured verbatim up to 200 characters.
• Audit rows: actor, delegation chain and client IP address for every action.

No special categories of data are sought. Card numbers and credentials are scrubbed before storage; their presence in telemetry is a customer-side defect, not a category processed on purpose.

6. Processor obligations

• Instructions. Personal data is processed to provide the service as documented and for nothing else. There is no analytics, advertising or training use.
• Confidentiality. There is no security-awareness training programme and no background check process; both are listed as not started in the readiness note.
• Security. The technical measures in Annex II. No certification, audit, penetration test or incident-response plan exists.
• Sub-processors. Annex III. None is contracted.
• Model providers. Scrubbed issue content is sent to the model provider configured for the deployment, or to the one whose key the customer supplies. No zero-data-retention agreement exists with any provider.
• Data-subject requests. Assistance is by mechanism (§7), not by a support process.
• Breach notification. No commitment or timeline exists. A written incident-response plan is listed as not started.
• Audit. No audit report is available. Every control claimed on the trust page names its file and its test, and the repository is available to a reviewer under agreement.

7. Data-subject requests

Access, portability and erasure are organization-scoped endpoints behind an administrator check (domain/src/modules/compliance/dsr.ts). The subject surface is derived from the live foreign-key graph, and a test asserts completeness against that graph. Erasure nulls nullable references, deletes leaf rows, pseudonymizes the subject row and points dependent rows at a pseudonymized tombstone; audit rows are retained, reduced to a principal id and a SHA-256 digest.

8. Deletion and return

Event data: a hot window of 7–90 days (default 30), then archival to cold storage and a DROP TABLE, then cold expiry after a further 0–730 days (default 90); hourly, enforced by a scheduler. Audit logs, spans, log records and replay segments: capped per plan at 30, 90, 180 or 365 days, deletion implemented and tested, sweep not scheduled — it runs when an administrator invokes it. Portability export is the return mechanism; there is no bulk export beyond it.

9. International transfers

All processing takes place in one region, in the United States (Fly.io dfw). No EU region is in operation, and no transfer mechanism (standard contractual clauses or otherwise) has been adopted or drafted.

10. Liability, governing law, term

Not drafted. Intentionally empty; nothing should be inferred from the absence.

Annex I — Details of processing

See §§2–5. The trust page lists the unauthenticated endpoints an outsider can check without an account.

Annex II — Technical and organizational measures

Each measure names the file that implements it; the trust page names the test.

Not present, and stated: storage-layer encryption at rest (a property of the hosting services, not documented), a written incident-response plan, periodic access review, a tested backup restore, security training, background checks.

Annex III — Sub-processors

None contracted. No data-processing agreement exists with any provider. For transparency only, the infrastructure the deployment currently runs on is listed in the privacy notice under "Who else can reach it".

Changes to this addendum

Every change to this addendum is a dated, reviewable revision, and the history is published alongside it. Material changes will be announced before they take effect.