HeadsDown

Counsel-ready draft

Data Processing Addendum draft

Draft DPA for business customers covering processing roles, instructions, data categories, subprocessors, security measures, transfers, deletion, audits, and service-provider terms.

Draft version
0.1
Effective date
Pending counsel review
Last updated
May 2, 2026

Draft publication status

This page is counsel-ready draft content, not final legal advice and not a final published policy. It must stay draft-labeled until legal, security, product, subprocessor, and cookie/analytics reviews are complete.

1. Purpose and relationship to the agreement

This Data Processing Addendum applies when HeadsDown processes personal data on behalf of a business customer under an agreement that incorporates this DPA.

This DPA supplements the main agreement, Terms of Service, order form, and Privacy Policy. If there is a conflict about personal data processing, this DPA controls to the extent of the conflict.

TODO: Counsel to define agreement precedence, execution mechanics, and whether this DPA is self-serve, order-form attached, or negotiated only.

2. Roles

For personal data processed in the customer’s use of HeadsDown business services, the customer is the controller or business, and HeadsDown is the processor or service provider, unless the parties agree otherwise in writing.

HeadsDown may act as an independent controller for limited data it processes for account administration, billing, fraud prevention, security, legal compliance, direct relationship management, and tightly scoped product analytics where lawful and not prohibited by customer settings or agreement.

TODO: Counsel to confirm controller/processor split for personal accounts, team accounts, billing, support, security logs, public profile features, calibration/aggregate learning, and any product analytics outside customer instructions. Product analytics must not use prompts, code, paths, repo names, logs, messages, or other prohibited work content.

3. Processing instructions

HeadsDown will process personal data only according to the customer’s documented instructions, including the agreement, this DPA, product settings, integration authorizations, support requests, and applicable law.

If HeadsDown believes an instruction violates applicable data protection law, HeadsDown will inform the customer unless legally prohibited.

The customer is responsible for ensuring that its instructions are lawful, that it has provided required notices and obtained required consents, and that users and integrations are authorized to submit metadata to HeadsDown.

4. Subject matter and duration

Subject matter: providing HeadsDown account, standing-rule, routing-decision, agent-run governance, integration, mobile, notification, support, and related services.

Duration: the term of the agreement plus any period required for deletion, return, backup retention, legal holds, dispute resolution, and statutory retention.

TODO: Counsel to confirm post-termination retention, deletion SLA, backup handling, and legal hold language.

5. Nature and purpose of processing

HeadsDown processes data to:

  • Create, authenticate, secure, and administer customer accounts.
  • Store user state and standing rules.
  • Let supported integrations ask for HeadsDown calls and report metadata-only outcomes.
  • Record decision feed entries, intervention receipts, deferred decisions, continuation state, and value evidence.
  • Provide support, troubleshooting, security monitoring, abuse prevention, billing, compliance, and service improvement.
  • Perform metadata-only outcome learning where enabled, permitted, or otherwise agreed.

HeadsDown learns from outcomes, not your code. Metadata-only agent-run surfaces are designed to process categories, counts, buckets, booleans, call/action keys, reason codes, validation states, outcomes, and opaque identifiers rather than prompts, source code, file contents, file paths, repository names, branch names, terminal output, logs, PR bodies, commit messages, calendar event details, or message contents.

6. Categories of personal data

Depending on customer use, personal data may include:

  • Account identifiers, contact information, authentication identifiers, membership and role data.
  • User state and standing-rule data, such as work windows, mode, timezone, notification settings, policy preferences, presets, and connected-tool settings.
  • Integration metadata, such as client kind/name/version, API key prefixes and hashes, token metadata, device-flow metadata, connected device metadata, and revocation state.
  • Agent-run metadata, such as event type, timestamps, run id, source, privacy mode, workspace ref when server-issued or unknown, proposal refs, call keys, action keys, reason codes, task categories, buckets, counts, validation status, queue/continuation identifiers, deferred-decision metadata, and outcome metadata.
  • Operational data, such as request metadata, logs, security events, rejection reason codes, rate-limit metadata, error diagnostics, and internal access logs.
  • Billing and subscription metadata where billing is enabled.
  • Support communications and customer-submitted information.
  • Legacy task proposal fields, which may include user or integration-provided descriptions and source references until migrated or separately constrained.

TODO: Counsel to confirm whether any special-category data is intentionally processed. Current product should not require special-category data by design.

7. Categories of data subjects

Data subjects may include customer users, account admins, team members, invited users, integration users, support contacts, billing contacts, and individuals whose metadata is included in customer-authorized user state or integration records.

TODO: Counsel to confirm whether external senders, calendar contacts, or public-page visitors are in scope.

8. Prohibited and restricted content

Customers and integrations must not submit prompts, source code, file contents, file paths, repository names, branch names, terminal output, logs, PR bodies, commit messages, calendar event details, message contents, secrets, access tokens, passwords, cookies, or other prohibited work content to metadata-only agent-run, outcome-reporting, or routing-decision surfaces.

HeadsDown validates agent-run event metadata at the boundary with schema allowlists, prohibited-field validation for the implemented validator list, and unsafe string validation before storage. Rejected submissions retain privacy-safe rejection metadata only, not the rejected payload contents. TODO: Before publication, reconcile the implemented validator list with the broader prohibited aliases in docs/PRIVACY_ARCHITECTURE.md or narrow public claims to the exact implemented list.

This DPA does not authorize customers to send content to metadata-only surfaces. If a future product needs content, it requires separate product terms, consent, retention, and security review.

9. Customer obligations

The customer will:

  • Provide required notices and obtain required consents from users.
  • Configure integrations and user roles lawfully.
  • Ensure integrations do not send prohibited content to metadata-only surfaces.
  • Use product settings and account controls to reflect the customer’s instructions.
  • Respond to data subject requests where the customer is the controller, with HeadsDown assistance as required by law and contract.
  • Protect account credentials, API keys, and integration tokens.

10. Confidentiality and access

HeadsDown will ensure that personnel authorized to process customer personal data are subject to appropriate confidentiality obligations. HeadsDown will limit internal access to personnel who need access for support, security, operations, compliance, or service delivery.

TODO: Security/legal to confirm internal access controls, access review cadence, support tooling scope, and audit-log statements before publication.

11. Security measures

HeadsDown will maintain technical and organizational measures designed to protect personal data against unauthorized access, loss, misuse, alteration, and disclosure.

Current draft measures to verify before publication include:

  • TLS for data in transit.
  • Encryption at rest for primary storage where provided by the hosting platform.
  • Role-based internal access controls.
  • Internal access logging for production data access.
  • API keys generated as high-entropy random tokens and stored as hashes.
  • Server-side metadata validation for agent-run event ingestion.
  • Rejection logging without storing rejected payload contents.
  • Rate limiting and abuse monitoring on relevant ingress surfaces.
  • Token revocation for supported connection/API-key surfaces.
  • Backup, restore, and incident response procedures.

Do not claim SOC 2, immutable audit logs, customer-managed keys, data residency, enterprise tenant isolation, or incident response SLAs unless implemented and approved.

TODO: Attach final security schedule after security review.

12. Subprocessors

HeadsDown may use subprocessors to provide hosting, email, payment processing, error tracking, push notifications, analytics if enabled, support, and operational tooling.

HeadsDown will maintain a subprocessor list or make it available on request. HeadsDown will provide advance notice of material subprocessor changes where required by the agreement or law and will remain responsible for subprocessor performance of data protection obligations.

TODO: Verify named subprocessors, purposes, processing locations, data processed, advance-notice method, objection process, and emergency replacement language.

13. International transfers

Where personal data is transferred internationally, HeadsDown will use appropriate transfer mechanisms as required by applicable law.

TODO: Counsel to insert SCC module choices, UK addendum, DPF posture if applicable, supplementary measures, transfer impact assessment process, and subprocessor transfer flow-down obligations.

14. Assistance with data subject rights

HeadsDown will reasonably assist the customer with data subject requests, taking into account the nature of processing and information available to HeadsDown.

The customer is responsible for verifying the request and instructing HeadsDown where the customer is the controller. HeadsDown may respond directly where it acts as an independent controller for account, billing, support, or legal-compliance data.

TODO: Confirm request intake, response SLA, export format, deletion limitations, and billing for assistance.

15. Deletion and return

Upon termination or written instruction, HeadsDown will delete, return, de-identify, or retain personal data according to the agreement, applicable law, product capabilities, backup retention, legal holds, and documented retention policy.

No final deletion SLA or customer-managed deletion commitment is made in this draft. Do not publish this section as final until deletion/export behavior is verified.

TODO: Counsel/product/security to confirm account deletion, event de-identification, backup purge, legal hold, retention horizon, and aggregate-data handling.

16. Personal data breach

HeadsDown will notify the customer without undue delay after confirming a personal data breach affecting customer personal data, as required by applicable law and agreement.

Notice will include information reasonably available to HeadsDown, such as the nature of the breach, affected data categories, likely consequences, mitigation steps, and contact point.

TODO: Counsel to insert notification deadline, cooperation scope, regulator/data-subject responsibility, and incident definition.

17. Audits

HeadsDown will provide information reasonably necessary to demonstrate compliance with this DPA, subject to confidentiality, security, operational, and customer-data protection limits.

TODO: Counsel to define audit report availability, questionnaire process, onsite audit limits, frequency, notice, cost allocation, third-party assessor rules, and protection of other customers’ data.

18. CCPA/CPRA service-provider terms

Where CCPA/CPRA applies, HeadsDown will process personal information as a service provider or contractor for business-customer personal information, as applicable, and will not sell or share that personal information except as permitted by law and the agreement.

TODO: Counsel to insert required CCPA/CPRA certifications, permitted purposes, subcontractor obligations, combination limits, audit rights, and sensitive personal information terms.

19. Outcome learning and aggregates

Outcome learning uses structured metadata such as categories, buckets, counts, validation states, call/action keys, outcomes, and data quality scores. It does not require prompts, code, file contents, file paths, repository names, branch names, terminal output, logs, PR bodies, commit messages, calendar details, or message contents in the metadata-only path.

Customer controls for disabling learning, limiting aggregation, setting retention, or exporting/deleting steering metadata are in development unless the product surface and agreement say otherwise.

TODO: Counsel/product to decide automatic contribution, opt-out semantics, historical data handling, team/global aggregate posture, and whether aggregate outputs are customer personal data.

20. Contact

DPA notices and privacy requests should be sent to TODO. Current product contact is [email protected].

Publication workflow and prior versions

Before any draft label is removed, the page needs legal review, security review of technical claims, product review for shipped-versus-planned behavior, subprocessor verification, and analytics/cookie audit where applicable.

Prior versions are archived manually in source control before publication changes: create a dated copy under `docs/legal/archive/`, record the version, effective date, last updated date, reviewer approvals, and the public route changed, then update this page in the same pull request.