1. Overview
HeadsDown is a routing-decision and agent-run governance service. Users set standing rules and connected tools use those rules to decide whether work should continue, narrow, ask, queue, wrap, or resume.
Our core privacy line is: HeadsDown learns from outcomes, not your code.
Implemented agent-run event and outcome-reporting surfaces, plus the routing-decision query spec when shipped, are designed as metadata-only paths. These surfaces use categories, counts, buckets, booleans, opaque identifiers, copy keys, action keys, call keys, validation status, and outcome metadata instead of prompts, source code, file contents, file paths, repository names, branch names, terminal output, logs, PR bodies, commit messages, calendar event details, or message contents.
This policy also needs to cover existing account, user-state, billing, support, device, public profile, task proposal, integration, and operational data. Some older or user-entered product surfaces may store descriptions, source references, account settings, notes, or other text that you or an integration choose to submit. Do not describe the entire product as “never storing task descriptions” unless those legacy surfaces change.
TODO: Counsel to align this overview with final product scope, DPA, and launch pages.
2. Scope
This policy applies to HeadsDown websites, web and mobile apps, APIs, SDKs, command-line tools, public pages, agent integrations, support interactions, and related services.
It does not govern third-party tools you connect to HeadsDown except for the data those tools send to HeadsDown or receive from HeadsDown. The integration that holds prompts, code, diffs, logs, messages, or other work content is responsible for that content under its own terms and policies.
3. Data we collect
| Category | Examples | Purpose | Current posture |
|---|---|---|---|
| Account data | Name, email address, authentication identifiers, account settings, confirmation state | Create and secure accounts, authenticate users, provide support | Live |
| Subscription and payment data | Plan, subscription status, billing identifiers, limited payment metadata from payment processors | Billing, fraud prevention, account management | Live where billing is enabled. Payment card details are processed by payment providers, not stored directly by HeadsDown |
| User state and standing rules | Work windows, mode, presets, focus rules, integration preferences, public handle settings, timezone, notification preferences | Route decisions, render user settings, apply standing rules | Live for consumer app features |
| Connected integration data | Connected-client metadata, API key prefixes and hashes, token metadata, device-flow state, client kind/name/version | Connect tools, authorize API access, revoke integrations, troubleshoot | Live for supported auth/API-key/device-flow surfaces. Final partner OAuth terms are in development |
| Agent-run event metadata | Event type, schema version, occurred/received timestamps, run id, workspace ref when server-issued or unknown, client, actor, source, privacy mode, idempotency key, proposal ref, payload fields | Decision feed, intervention replay, outcome learning, value evidence, debugging | Live for agent-run event submission path with metadata-only validation |
| Agent-run payload metadata | Task category, task size bucket, call key, action key, reason codes, validation status, validation kind, duration, tool counts, file-count buckets, queue ids, continuation ids, deferred-decision metadata, value-evidence refs | Explain calls, queue/defer decisions, replay interventions, improve recommendations | Live for documented event types, constrained by validation |
| Outcome metadata | Outcome, validation status, error category, duration, counts, buckets, feedback key, data quality score, value evidence refs | Learn which calls worked, compute evidence-backed value metrics, improve cold-start recommendations | Partially live through calibration and agent-run outcome paths. Privacy controls and final outcome-learning policy are in development |
| Task proposals and legacy steering records | Agent ref, model/framework fields, user or integration-provided description, source ref, estimates, scope summary, verdict, reason, confidence, snapshots | Operate older proposal/verdict flows and action handling | Live legacy surface. Do not claim this surface is metadata-only until migration or validation changes land |
| Public profile and handle data | Public handle, visibility settings, user-selected public page fields | Render public pages and handle routes according to privacy settings | Live for public profile features |
| Calendar and connected service state | OAuth connection state, calendar sync metadata, free/busy or work-window signals, sync status | Populate state and support routing decisions | Live for supported calendar features. Avoid storing calendar titles/details in agent-run metadata |
| Device and notification data | Mobile device tokens, push subscription metadata, notification preferences | Deliver notifications and manage devices | Live |
| Support and communications | Support messages you send, issue reports, feedback, email preferences | Provide support, debug, improve the service, honor preferences | Live when users contact HeadsDown |
| Security and operational data | IP address, request metadata, auth events, error diagnostics, rejection reason codes, rate-limit metadata, internal access logs | Secure the service, detect abuse, debug reliability, comply with law | Live in operational systems. Do not include rejected payload contents in rejection logs |
TODO: Counsel and security to verify all categories, processors, lawful bases, and retention before publication.
4. Data not accepted in metadata-only agent surfaces
Implemented HeadsDown agent-run event and outcome-reporting surfaces, plus the routing-decision query spec when shipped, are designed not to store:
- Prompts or model responses.
- Source code, diffs, patches, file contents, snippets, stack traces, or tracebacks.
- File paths, directory paths, repository names, remote URLs, branch names, commit messages, PR bodies, issue bodies, ticket bodies, or ticket descriptions.
- Terminal output, stdout, stderr, test logs, build logs, compiler logs, screenshots, or screen recordings.
- Calendar event titles, descriptions, attendees, locations, conferencing links, or exact private schedule details beyond routing-safe state.
- Slack messages, email bodies, chat messages, notification bodies, direct-message content, or other human message contents.
- Secrets, API keys, access tokens, passwords, cookies, environment variables, or credential values.
The agent-run event submission path includes server-side schema allowlists, prohibited-field validation for the implemented validator list, and unsafe string validation before storage. Rejected submissions store privacy-safe rejection metadata, such as reason code and field path, 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 exclusion list is about metadata-only agent-run, outcome, and routing-decision surfaces. It does not mean that HeadsDown cannot store any text you deliberately type into an account setting, support message, old proposal surface, or future separately consented product surface.
5. How we use data
HeadsDown uses data to:
- Create, authenticate, and secure accounts.
- Apply user state and standing rules to HeadsDown calls.
- Let connected tools ask for routing decisions and report outcomes.
- Record privacy-safe agent-run events, decision feed entries, intervention receipts, deferred decisions, continuation state, and value evidence.
- Improve recommendation quality through metadata-only outcomes and data quality scoring where enabled or allowed.
- Provide customer support and troubleshoot reliability, abuse, privacy-boundary, and integration issues.
- Send transactional emails, product communications where permitted, push notifications, and security notices.
- Process payments, manage subscriptions, and prevent fraud where billing is enabled.
- Comply with legal obligations, enforce terms, and protect users, HeadsDown, integrations, and the public.
TODO: Product/legal to decide whether outcome learning is automatically enabled for each customer tier and how opt-out affects historical metadata.
6. Legal bases for processing
For GDPR/UK GDPR purposes, possible legal bases include:
- Contract: to provide HeadsDown services you request, including account access, connected integrations, routing decisions, and support.
- Legitimate interests: to secure the service, prevent abuse, improve reliability, debug integrations, and improve metadata-only recommendations in ways that are not overridden by individual rights.
- Consent: where required for optional analytics, optional marketing, optional mobile permissions, optional integrations, or any future separately consented content-processing feature.
- Legal obligations: to comply with tax, accounting, sanctions, lawful requests, and other legal requirements.
TODO: Counsel to assign final legal bases per data category and jurisdiction.
7. How we share data
HeadsDown may share data with:
- Service providers and subprocessors that host, secure, operate, support, bill, email, monitor, or deliver the service.
- Integrations you connect, as needed for that integration to function and only according to the product surface and authorization flow.
- Organization admins where a team or business account uses admin features that are actually implemented and disclosed.
- Professional advisors, auditors, counsel, and insurers.
- Authorities or third parties when required by law, to protect rights and safety, to enforce terms, or to respond to lawful requests.
- Successors in a merger, acquisition, financing, or sale of assets, subject to appropriate protections.
HeadsDown does not sell prompts, code, message content, or other work content because metadata-only agent-run surfaces are not designed to receive that content. TODO: Counsel to confirm CCPA/CPRA sale/share posture, targeted advertising posture, and optional analytics posture.
8. Subprocessors
Current subprocessor categories may include hosting, email, payment processing, error tracking, push notification gateways, analytics if enabled, and operational tooling.
TODO: Do not publish a named subprocessor list until product/security verifies vendors, purposes, locations, and data processed. If verification is incomplete, use conservative “current list available on request” language on public trust pages.
9. International transfers
HeadsDown may process data in the United States and other locations where HeadsDown or its subprocessors operate.
TODO: Counsel to insert final international transfer mechanism, including SCC module choices, UK addendum, DPF posture if applicable, transfer impact assessment process, and subprocessor transfer obligations.
10. Retention
HeadsDown retains account state, standing rules, integration metadata, events, outcomes, operational logs, and support records for as long as needed to provide the service, comply with law, resolve disputes, enforce agreements, protect security, maintain decision feed and calibration functions, and support legitimate business needs.
No final public retention period is asserted in this draft. Do not say “deleted after 90 days,” “customer-managed retention is available,” or “automatic deletion is live” until enforcement and policy are verified.
Rejected metadata submissions retain rejection metadata only, not the rejected payload contents.
TODO: Confirm retention periods for account data, agent-run events, outcome metadata, value evidence, task proposals, support records, internal access logs, Sentry/error metadata, backups, billing records, and anonymized/aggregated calibration data.
11. Deletion and export
Users may request access, correction, export, deletion, or other privacy rights as required by applicable law. Account deletion behavior must match the implemented product and backend behavior.
Current docs describe a deletion intent where account state and standing rules are removed from active processing and historical decision logs/events may be de-identified and aged out according to retention policy. The precise deletion SLA, backup purge timing, hard-deletion behavior, and export workflow are not finalized in this draft.
Do not claim customer-managed deletion, user-facing audit export, or configurable retention controls are live unless the implementation proves they are live.
TODO: Counsel/security/product to confirm deletion/export behavior, DPA interactions, legal holds, backup retention, and data subject request workflow.
12. Privacy rights
Depending on where you live, you may have rights to access, correct, delete, port, restrict, object to, or opt out of certain processing of personal data. You may also have the right to lodge a complaint with a regulator.
California residents may have rights under CCPA/CPRA, including rights to know, delete, correct, opt out of sale/share, limit certain sensitive personal information uses, and non-discrimination. TODO: Counsel to confirm which rights apply and how to describe sale/share posture.
To exercise rights, contact TODO. Current product contact is [email protected].
13. Enterprise and admin controls
Some privacy, learning, aggregation, retention, admin-consent, revocation, audit-export, and organization policy controls are planned or in development. Do not describe these as live controls until the corresponding product surfaces and backend enforcement exist.
Where a product surface gives organization admins a control, admins may be able to manage members, integrations, settings, or billing according to their role. TODO: Confirm exact admin controls before publication.
14. Cookies and analytics
HeadsDown uses essential cookies and similar technologies needed for authentication, security, session management, CSRF protection, preferences, and service operation. Optional analytics or preference cookies require a confirmed analytics/cookie audit before publication.
See the Cookie Policy draft for details.
15. Security
HeadsDown applies security controls appropriate for sensitive metadata, including authentication, authorization, API key hashing, server-side validation for metadata-only agent-run surfaces, TLS in transit, and operational monitoring.
Do not claim SOC 2, specific incident response SLAs, immutable audit storage, customer-managed data residency, hardened tenant isolation, or full enterprise readiness unless those controls are implemented and approved for publication.
TODO: Security review to verify encryption at rest wording, internal access logging wording, tenant isolation wording, rate-limit wording, and incident response wording.
16. Children’s privacy
HeadsDown is not intended for children under TODO age threshold. TODO: Counsel to confirm COPPA/age wording and whether users under 18 are allowed.
17. Changes to this policy
HeadsDown may update this policy from time to time. The updated version will be posted with a new effective date. If changes materially affect your rights, HeadsDown will provide notice as required by law or applicable agreement.
TODO: Counsel to confirm notice process.
18. Contact
Questions or requests about this policy should be sent to TODO. Current product contact is [email protected].