1. Roles
You are the controller. Arbiter is the processor. We process candidate personal data only on your documented instructions, which are the Terms of Service, this agreement, and your use of the product.
This allocation matters: the lawful basis for assessing a candidate is yours, not ours, and we cannot supply one on your behalf.
2. What we process
Candidate name and email address. CV text you submit. Code and files the candidate writes. A record of commands run and files saved during the session, where you have enabled it. Assessment scores and the reasoning behind them.
3. Sub-processors
We use the following. You are notified before any is added or replaced.
- E2B — cloud sandboxes in which candidate code is executed.
- Anthropic — three purposes, and they are listed separately because they
- involve different data:
- (a) routing an assessment to a suitable challenge, and adapting the wording
- of a task to a candidate's background — candidate CV text is sent;
- (b) preparing interview questions for your reviewer after an assessment is
- graded — the code the candidate wrote is sent;
- (c) nothing else. No model scores a candidate, and no model makes or
- recommends a hiring decision.
- Resend — transactional email delivery.
- Supabase / PostgreSQL hosting — data at rest.
4. Security
Data is isolated per workspace by row-level security enforced in the database, not by application code alone. Grading runs in a sandbox with no outbound network access. Assessment content that would reveal answers is held in a schema no application role can read.
5. Retention, deletion, and offboarding
Retention periods are configured per workspace. During the contract, CV-derived data is deleted after your CV retention window (90 days unless you set otherwise) and candidate code, with everything derived from it, after your code retention window (180 days unless you set otherwise).
On termination, or 60 days after an expired licence goes unpaid, the workspace is offboarded and we delete — completely and irreversibly:
- all candidate personal data: names, email addresses, ATS identifiers, and
- the CV-derived analysis;
- all candidate-authored code: patches, repositories, and the AI-drafted
- interview guides that quote them;
- all behavioural session records and integrity signals;
- your team's personal data: member names and email addresses;
- recruiter and reviewer notes.
One category of data survives offboarding, and we state it here rather than in a definition: anonymised, aggregated performance metadata — which challenge was attempted, the score, the band, and the time to completion, with every identifier above removed. After offboarding these records cannot be connected to any person or, beyond the workspace's internal identifier, to any of your candidates. We retain them for exactly one purpose: keeping the global calibration of our challenge library honest — knowing that a task's pass rate or completion time has drifted requires history. They are not sold, not shared, and not used to profile any person.
Evidence of legal acceptances is retained separately and for longer, because it is the record that we met our obligations to the candidate.
6. International transfers
Where personal data leaves its region of origin, transfers rely on Standard Contractual Clauses with each sub-processor.
7. Assistance
We will assist you in responding to data subject requests, and in any data protection impact assessment you carry out for your use of the product.