Data processing addendum

1. Roles

You are the controller of personal data in the datasets you upload, the prompts you send to your deployments, and the people you invite to your workspace. Attempts is your processor for that data. Attempts is the controller of the account and billing information it needs to run the service and meet its legal and accounting obligations; the Privacy policy covers that.

2. Subject matter, purpose and duration

We process customer personal data only on your documented instructions — these terms and your actions in the workspace — to provide the service: storing datasets; preparing training, validation and held-out test splits; estimating, training and evaluating models; serving deployments; operating API keys and team access; billing; and support. Processing lasts for the term of the agreement and until the data is deleted as described in section 9. We will tell you if we believe an instruction breaks the law.

3. Categories of data and data subjects

• Data subjects: whoever appears in your datasets and prompts, which you decide; your workspace owner, admins and members.
• Data: dataset contents and file names; prepared splits and run records; model answers and scores from evaluations; prompts and answers passing through deployments (not stored); names, work emails and roles of workspace users; invitation emails.
• Special categories: not expected. Do not upload special categories of personal data, health records or payment card numbers unless we have agreed this with you in writing.

4. Subprocessors

You authorise the subprocessors on the Subprocessors page. We will update that page before a new subprocessor processes customer personal data; you may object on reasonable data protection grounds by emailing support@attempts.ai, and if we cannot resolve the objection you may stop using the affected part of the service. We remain responsible for our subprocessors' performance of these obligations.

5. Security measures

These are the measures in place today:

• In transit: the website, workspace, API and calls between our services and subprocessors use HTTPS (TLS). Our backend refuses non-HTTPS service addresses outside local development.
• Workspace isolation: every dataset, run, deployment, evaluation, key and billing record is stored against its workspace, and every request is checked against the signed-in workspace before data is returned. Database tables have row-level security enabled with access only for the backend's service role; database functions that change credits run in single transactions.
• Sessions: sign-in tokens are kept in HttpOnly, SameSite=Lax cookies, Secure on HTTPS, and are never exposed to page scripts. Changes to an account require a request from our own site's origin. A verified email is required before a workspace opens.
• Uploads: dataset files go straight from the browser to cloud storage through a signed link valid for 15 minutes, scoped to one file path in your workspace.
• Secrets: API keys are stored as SHA-256 hashes for verification and encrypted with a server-held key for reveal; revoked keys lose their encrypted value. Invitation tokens and credit codes are stored only as hashes. Backend service credentials are held in the cloud provider's secret manager and website credentials in server-side settings; none are sent to the browser.
• Payments: card details are entered on the payment processor's hosted page; we store only brand, last four digits and expiry. Payment notifications are accepted only with a valid signature.
• Abuse protection: sign-in, sign-up, password reset, the guided access code and the contact form are rate-limited per client. We store only a keyed hash of the client's IP address with the time of each attempt, and delete it within a day. Our pages tell browsers not to display them inside other websites.
• Logging: backend request logs record method, route, status and duration only, never request bodies, datasets, prompts or credentials.
• Training data minimisation: the held-out test split is never sent for training; validation examples are sent only if you choose validation-split evaluation; cost estimates send nothing to the training provider.
• Team access: owner, admin and member roles; members cannot see billing details or reveal or revoke other people's keys; a key stops working when its creator leaves the workspace.

We do not currently hold third-party security certifications.

6. Personnel

We give access to customer personal data only to people who need it to provide the service or support you, and who are bound to keep it confidential.

7. Personal data breaches

We will notify you without undue delay after becoming aware of a personal data breach affecting your data, at the workspace owner's email, with what we know about its nature, likely consequences and the measures taken, and we will update you as we learn more.

8. Assistance

We will help you, taking into account the nature of the processing, to respond to requests from data subjects and to meet your obligations on security, breach notification and impact assessments. Send requests to support@attempts.ai.

9. Deletion and return

On termination, or earlier at your request, we delete your workspace data within 30 days of a verified request from the workspace owner, as described in the Privacy policy: datasets and stored files, prepared splits, run records, reports, deployments, evaluations, team members and invitations, and API keys. Before deletion you can view evaluation results, and download any run report, in the workspace. We keep billing and ledger records as required for accounting. Copies held in our training provider's account are covered by the same request. Database backups roll off on our database provider's schedule.

10. Audits

We make available the information needed to show compliance with this addendum through this documentation and written answers to your reasonable questions sent to support@attempts.ai. Any further audit is by agreement, at your cost, on reasonable notice and subject to confidentiality.

11. International transfers

Our subprocessors process data in the United States where the region is known (see the Subprocessors page). The transfer mechanism that applies, such as standard contractual clauses, will be stated here once the contracting entity is finalised.