Privacy Policy
What personal data Waltz collects, what it never collects, how it is used and shared, and the choices and rights you have.
Draft · Last updated
Draft for counsel's review. Not yet in effect.
1. Who we are and what this covers
[Waltz legal entity], [registered address] ("Waltz", "we") provides Engineering Intelligence software at waltz.run. This policy explains how we handle personal data.
We play two roles:
- Controller for data about our own customers and visitors: people who visit waltz.run, sign in to the console, are billing contacts, or write to us.
- Processor (or service provider) for data our customers connect to Waltz from their own systems, such as their source control, trackers and agent vendors. For that data, the customer decides what is connected and who sees it, and our Data Processing Addendum governs our handling. If you work for one of our customers and have a question about that data, contact your employer first. We will help them answer you.
2. The short version
- We read the systems a customer connects and keep derived facts, not raw content.
- Source code is never stored. It is analyzed in a short-lived runner and then deleted. A Brief may quote a short excerpt (40 lines or fewer) as evidence.
- Facts record people as hashed identities, not names or email addresses.
- We never model how skilled an individual is, never rank people, and never record who opened a Brief.
- One customer's data never appears in another customer's Brief.
- We don't sell personal data, don't show ads, and the site sets no analytics or advertising cookies.
- We don't train models on customer data.
3. Data we collect as a controller
| Category | What | Source |
|---|---|---|
| Account | Email address, name if you give one, the orgs you belong to and your role | You, or an admin who invites you |
| Sign-in | Single-use sign-in links (only a hash is stored), session tokens in cookies, sign-in times | The Service |
| Billing | Billing contact, company name, address and tax details, plan and invoice history. Card details go to Stripe and never reach us | You, through Stripe |
| Support and correspondence | What you write to support@, security@ and our other addresses, and our replies | You |
| Site and service logs | IP address, browser user agent, requested URL, time and response status. Tokens in URLs are blanked before logging | Your browser and our servers |
| Admin actions | Who changed which setting, connection, member or recipient, and when | The Service's audit log |
4. Data we process for customers
When a customer connects a system, Waltz reads only what the granted scopes allow, and keeps only what the table below lists under "Kept". The rest is processed in memory and dropped before anything is stored or logged.
| Kind of system | Kept | Never kept |
|---|---|---|
| Source control (GitHub, GitLab) | Repository and pull request metadata, review events, links. Short code excerpts a Brief cites | Source code, diffs |
| CI/CD and deployment | Run metadata, outcomes, durations | Logs, build artifacts, secrets |
| Work tracking (Jira, Linear, GitHub Issues) | Keys, types, statuses, transitions, links, and titles a Brief cites | Descriptions and comments, unless a Brief cites an excerpt |
| Incidents and errors | Ids, severity, service keys, timestamps, error type and a fingerprint hash | Event payloads, end-user data, breadcrumbs, incident timelines, chat transcripts |
| AI coding agents (e.g. Anthropic, Cursor, Copilot) | Counts, tokens, cost, session ids, commit links, model names | Prompts, responses, tool inputs and outputs, raw API bodies, commit messages, branch names |
| Security and code quality | Rule, severity, location, state, dates | Secret values, code snippets |
| Support and product analytics | Aggregate counts | Ticket text, end-customer identities, raw events |
| Chat (Slack) | Waltz's own delivery receipts and the reactions on its messages | Any other message |
| Directory | Name, email, title, level, manager, teams | Compensation, performance data, personal contact details |
| Cloud cost | Cost lines by service and vendor | Invoices, payment details |
On top of what is connected, a customer's admins give Waltz:
- The org chart: each person's name, work email, title, level, manager and teams, by CSV upload or the console's editor.
- Brief recipients: the work email addresses that receive each Brief.
- Reviews: annotations, edits and decisions that members make on Briefs. Annotations show their author's name to the org's members.
- Agent session facts uploaded by developers with the Waltz CLI, when they or their org turn this on. These are allow-listed facts (agent, model, duration, commit links), never prompts or code.
How people appear. Facts record people as hashed source identities, such as a hash of a commit email address. Waltz links these to a person in the org chart by exact email match, or when an admin confirms a suggestion. Whether a Brief names individuals is the customer's setting, per Brief type. By default, Briefs for VPs and above are team-level. Hashed identities are pseudonymous, not anonymous: [until per-org keyed hashing is in place, a hash can be matched against a known email address].
Seat counting. To bill a customer, Waltz counts the distinct people who authored commits or pull requests, or delegated agent sessions, in the last 90 days. The admin console shows who is counted and why.
5. What we never do
- We never model, score or rank how skilled, productive or engaged an individual is. Delivery metrics such as cycle time are reported as team evidence, not as a measure of a person.
- We never record who opened which Brief. Engagement is counted per Brief type, without names.
- We never import vendors' productivity scores or leaderboards.
- We never read Slack or Teams message bodies, calendars, session replays or raw analytics events.
- We never put one customer's data in another customer's Brief, and we never use one customer's text to prompt or tune a model for another.
- We never sell or share personal data for cross-context behavioural advertising.
6. How we use personal data
| Purpose | Data | Legal basis (EEA/UK) |
|---|---|---|
| Provide the Service: sign-in, analysis, Briefs, delivery, review | Account data; customer data as processor | Contract with you or your organization; for customer data, the customer's instructions |
| Bill for the Service, including seat counts | Billing data, seat counts | Contract; legal obligation (tax records) |
| Send sign-in and invitation emails | Email address | Contract |
| Send Briefs to recipients | Recipient email address | The customer's instructions |
| Secure the Service, prevent abuse, keep audit logs | Logs, audit events | Legitimate interests in a secure service |
| Answer support and security reports | Correspondence | Contract; legitimate interests |
| Improve the Service with aggregate statistics that identify no org or person | De-identified aggregates | Legitimate interests |
| Comply with law | As required | Legal obligation |
We don't make decisions with legal or similarly significant effects about anyone based solely on automated processing.
7. Language models
Waltz uses a language model to phrase Brief text from facts. By default this is a model hosted by our subprocessor Anthropic. Enterprise customers may use their own provider and key instead.
What may be sent to a model: facts (in which people appear only as hashed identities), pull request and commit titles and messages, ticket text, document excerpts, and short code excerpts. [Customers will be able to restrict these classes, for example no code excerpts.] Model calls are logged without their content. Model answers are cached per org and never shared across orgs.
We don't use customer data to train or fine-tune models. [Counsel to confirm the hosted provider's commercial terms: no training on API inputs, and its retention period for inputs and outputs.]
8. Emails
- Sign-in and invitation emails are transactional. They have no unsubscribe link, because you asked for them or an admin invited you.
- Brief emails go to the recipients a customer's admin chooses. Each carries a one-click unsubscribe link that removes your address from that Brief. Your admin can add it back.
- Our emails contain no tracking pixels, no remote images and no scripts. We don't track opens or clicks per person.
- Replies to Brief emails reach Waltz's team.
- We send no marketing email. [If that changes, it will be opt-in where the law requires.]
9. Who we share data with
- Subprocessors that run the Service for us: hosting, email, billing and the hosted model provider. They are listed, with what they receive and where, on the Subprocessors page.
- Integrations the customer connects. When a customer connects Slack, for example, Waltz sends Brief notifications there and looks up recipients by email. These systems belong to the customer; they are not our subprocessors.
- Public data services. To report end-of-life runtimes and known vulnerabilities, Waltz sends the names and versions of open-source dependencies, with no personal data, to public services such as endoflife.date, OSV.dev and deps.dev.
- Pooled benchmarks. If a customer's admin turns on contribution, the org contributes monthly aggregate metrics to anonymized benchmarks. These hold no names, facts or text, and published figures require at least 10 orgs and 100 engineers.
- Legal and safety. When the law requires it, or to protect the rights and safety of people or the Service. We push back on overbroad requests and tell the affected customer where we lawfully can.
- Corporate transactions. A successor in a merger or acquisition, under this policy's protections.
10. Where data is stored and transferred
The Service is hosted in the United States (Amazon Web Services, region us-east-1). [No EU region is offered yet.] If you are in the EEA, the UK or Switzerland, your data is transferred to the US under the European Commission's Standard Contractual Clauses, the UK Addendum and Swiss equivalents, or under the EU-US Data Privacy Framework where a recipient is certified. [Counsel to confirm whether Waltz self-certifies under the DPF.]
11. How long we keep data
| Data | Kept |
|---|---|
| Source code | Not kept. Deleted when each analysis run ends |
| Customer data (facts, snapshots, Briefs, reviews, org chart) | For the subscription, then deleted within [60] days of termination, after an export window. [Default retention periods during a subscription: not yet set; see README] |
| Account data | While you have an account, then [deleted or anonymized within 90 days] |
| Billing records | As tax law requires, typically [7] years |
| Server logs | 30 days |
| Database backups | 7 days |
| Prior versions of stored files | 30 days |
| Audit log | [For the subscription; a record of an org's deletion is kept] |
| Sign-in links | 15 minutes, single use |
| Brief links | Expire after 14 days by default |
12. Security
Data is encrypted in transit with TLS and at rest with keys in AWS KMS. Integration credentials are encrypted per org and decrypted only by the process that uses them. Analysis runs in isolated, short-lived containers with no access to our network or cloud credentials. Admin actions are recorded in an audit log. See the Data Processing Addendum, Annex 2.
13. Your rights
Depending on where you live, you may have the right to access, correct, delete, restrict or object to our processing of your personal data, to receive it in a portable format, and to withdraw consent where we rely on it. In the EEA and the UK you may also complain to your data protection authority.
California residents and residents of other US states with privacy laws have the right to know, correct and delete their personal information, and not to be discriminated against for exercising these rights. We don't sell personal information or share it for cross-context behavioural advertising, and we don't use sensitive personal information to infer characteristics.
To exercise a right, write to [privacy@waltz.run]. If your request concerns data a customer connected, we will pass it to that customer and help them answer it. We will verify your identity before acting, and answer within the time the law sets.
14. Children
The Service is for businesses. It is not directed at children, and we don't knowingly collect data from anyone under 16.
15. Changes
We will post changes here with a new date. For material changes we will notify account owners by email before they take effect.
16. Contact
[Waltz legal entity], [postal address]. Email [privacy@waltz.run]. [EU and UK representatives under GDPR Art. 27, if required: counsel to decide.] [Data protection officer, if required.]