Privacy notice

The data controller is 7Milestone SASU, Paris, France, operating re:mind under the BrightNTech brand. Its registration details are in the legal notice.

Privacy correspondence may be sent to 2 rue de la Paix, 75002 Paris, France. For data protection enquiries, use the re:mind contact form. No Data Protection Officer has been appointed.

Everything below is held because the assessment cannot be delivered, scored or defended without it. There is no advertising identifier, no third-party analytics script, no cross-site tracking and no profiling for marketing.

Account identity

Your email address, the name you give, and the timestamps of account creation, email confirmation and last sign-in (users). The name of your workspace and its data region (organizations), and your roles within it (memberships).

Credentials and sessions

Your password is never stored. What is stored is a scrypt-derived hash with its own salt and cost parameters (user_credentials). Your sign-in session is stored as a hash of the session token with its issue, expiry and revocation times (sessions) — a database dump yields no usable session. Email confirmation and password reset links are stored the same way, as digests (email_verifications, password_resets). Sign-in attempts are recorded against the identifier used, to throttle credential stuffing (auth_attempts).

Your assessment responses

What you write, choose and rank, exactly as you entered it, together with your revision history within the exercise and the exercise code, version, modality and language (exercise_attempts). Free-text answers are stored as free text: they are the evidence your profile is built from, and you can read all of them back.

Interaction telemetry

Per exercise: when it was presented, how long until your first input, how long until you submitted, how many times you revised, how many times the tab lost focus, how many times you pasted, and a coarse device class of mobile, tablet or desktop (exercise_attempts.telemetry). That is the complete list. There is no keystroke capture, no mouse tracking, no screen recording and no continuous monitoring of any kind.

Preference self-reports

A one-to-five rating on exactly three items per session (preference_responses). These are self-report, they are labelled as self-report, and they are never merged into a capability score.

Results and the working numbers behind them

Your capability scores per dimension with their confidence, your expression facets, your preference signals and your assessment integrity record (capability_results, expression_results, preference_signals, integrity_results), together with the intermediate feature values extracted from your answers (feature_vectors) and the version of every component that produced them.

Audit records

A record of material actions: what happened, when, who did it, to which resource, and whether it was allowed, denied or failed (audit_events). Audit rows carry no response content — that is enforced at the write boundary, not merely intended.

Billing

Your plan, its status, seat count, period end and the payment provider’s customer and subscription identifiers (subscriptions), plus a count of assessments started per period (usage_counters). Your card details are never seen, transmitted or stored by re:mind: they are entered directly with the payment provider, which also holds your billing address and any tax identifier you give it.

Voice

The schema contains a table for voice observations and audio retention deadlines (voice_observations), and consent has a separate opt-in for voice processing and another for retaining raw audio. Voice capture is not available in this build. The runtime refuses voice exercises rather than faking them, so no audio, transcript or speech feature is collected today, and neither voice opt-in can currently be exercised.

Performance of our contract with you (GDPR Article 6(1)(b)) — creating and maintaining your account, presenting the exercises, storing and scoring your responses, producing and publishing your result, and billing you for a paid plan. Without this data there is no assessment to deliver.

Our legitimate interests (Article 6(1)(f)) — security and abuse prevention, which is why session tokens are stored only as hashes and sign-in attempts are throttled; and the append-only audit log, which is what makes it possible to show after the fact what was done to a person’s record. We consider this proportionate because the audit log carries no response content and the security data is the minimum that makes the control work.

Your consent (Article 6(1)(a)) — the consent you give before each assessment is scored, recorded with its version against the session (assessments.consent), and the separate voice-processing and audio-retention opt-ins described above. You can withdraw consent by erasing your account; withdrawal does not undo processing that was lawful before it.

Legal obligation (Article 6(1)(c)) — invoicing and accounting records are retained for the duration of your use of the application and, after that, for the period required by applicable accounting, tax and other legal obligations.

Account access and usage limits

Email addresses and strictly necessary session cookies are retained only for as long as necessary to provide access to the application and to apply its usage limits. They are deleted or anonymised when they are no longer necessary for those purposes, unless a longer retention period is required by applicable law.

The retention sweep

A sweep deletes expired email confirmation tokens and password reset tokens once they are more than thirty days past expiry, deletes sign-in attempt records older than thirty days, and releases any stored audio whose retention deadline has passed. It is a route (POST /v1/admin/retention/sweep) rather than a hidden background timer, so that running it is itself an audited event and so that it is driven by whatever scheduler the deployment already runs. The operational schedule is not yet fixed. TO BE COMPLETED how often the retention sweep runs in production.

A general retention period for an active account’s assessment data, and for an account left dormant, has not been set. TO BE COMPLETED retention period for account and assessment data, and the dormancy policy.

Erasure, exactly as it is implemented

Erasing your account (DELETE /v1/auth/account) runs in a single transaction and does all of the following:

• deletes your password credential record outright;
• revokes every session you have open, on every device;
• replaces your email address with a non-routable placeholder derived from your internal identifier, replaces your name with “Erased account”, and stamps the record as erased;
• redacts every free-text answer you wrote, replacing the response with a skipped sentinel and emptying its revision history.

The database permits exactly that one shape of change to an answer and nothing else: the attempt table is otherwise append-only, and the erasure exception is written into the schema so that no operator can widen it by hand. An answer can be redacted once, and the redaction cannot be used as cover for an edit.

Why published results survive it

A published result is immutable at the database level, carries the version of every component that produced it, and carries a signature that lets anyone re-derive it from its own evidence and confirm it still matches. That guarantee is the reason a re:mind result is worth anything. Deleting result rows would not only remove yours: it would break the property that every other person’s result depends on, and it would leave the audit record referring to something that no longer exists.

So what survives an erasure is the score and its lineage, with nothing left that identifies you and with the text you wrote redacted. The timing telemetry survives too, because it identifies nobody on its own and the integrity record for the session must stay reproducible. We consider this the narrowest carve-out that keeps the measurement defensible; whether it is the right balance in law is exactly the kind of question this document needs reviewed. TO BE COMPLETED counsel's view on the Article 17 carve-out for immutable published results.

Under the GDPR you have the rights below. Two of them are served by a control in this product. For rectification, erasure, restriction, objection, or any other request about your personal data, use the re:mind contact form.

You may also complain to a supervisory authority. For a controller established in France that is the Commission nationale de l’informatique et des libertés (CNIL).

Three parties are involved, and no others. There is no advertising network, no third-party analytics and no font or script fetched from another origin — the interface uses only typefaces already present on your device.

Operational logs and traces are redacted at source: secrets are stripped by an explicit deny-list, and no response content is written to a log line or a trace attribute. If an external observability endpoint is ever configured, it becomes a processor and is named here. Nothing is exported: this deployment sets OTEL_ENABLED=false and configures no exporter endpoint, so traces stay in the machine’s own logs and reach no third party.

Every workspace carries a data region, recorded against it when the workspace is created and reported to you in Settings. The schema admits only European or Canadian regions. Residency selection is an Enterprise capability agreed in contract; every other workspace takes the region of the deployment it was created on.

This deployment runs in Frankfurt, Germany — recorded as eu-central — on infrastructure operated by Fly.io. Data is stored and processed there.

Fly.io, Inc. is incorporated in the United States. Choosing an EU region places the machines and the database in the EU; it does not make the provider an EU company, and US-incorporated providers can be subject to lawful access requests from US authorities. We state the arrangement rather than assert absolute EU-only processing, because that assertion would be stronger than the arrangement supports.

Its database shares a PostgreSQL cluster with other applications operated by 7Milestone. The database platform in use issues credentials whose privileges span the whole cluster rather than a single database, so re:mind’s data is not technically separated from those other applications, and theirs is not separated from re:mind’s. That is a deliberate, recorded decision for this testing deployment, not an oversight, and it is why the deployment is restricted to people who have been told about it.

A production service will not run this way: per-application database isolation is a prerequisite for offering re:mind to customers. Until then, no claim of per-application data separation is made for this deployment.

You can delete everything held about you at any time from Settings, and it is deleted from this cluster when you do.

Your responses are never used to train a model. Not ours, not anyone else’s. No response, telemetry record or result is used as training data, and no language model authors a score: every dimension, expression, preference and integrity value comes from a deterministic versioned function over features extracted from your answers.

No prohibited inference is performed. re:mind does not infer emotion, honesty, mental state, mental health, any biometric characteristic, or any protected characteristic, from your writing, your timing or anything else. This is not a setting that is switched off; no such capability exists in the system.

Your data is never sold, and never disclosed to an employer without an action by you. Self-reported preferences are reported separately and are never merged into capability.

re:mind produces a measurement, not a decision about you. It does not decide access to employment, credit, education or any service, and the API refuses to run an assessment declared for a recruitment purpose. On that basis we do not consider the service to produce a legal or similarly significant effect within the meaning of Article 22.

Every score is shown with its measurement confidence and with the evidence that produced it, and you can require a published result to be re-derived from your own answers and checked. If an organisation uses a profile to make a decision about you, that decision is theirs, our terms forbid it for employment decisions, and their obligations under Article 22 are theirs to meet.

The session cookie is HTTP-only and marked Secure, so page scripts cannot read it, and only its hash is stored server-side. Passwords are scrypt-derived with parameters that travel with each hash so cost can be raised without invalidating existing passwords. One-time links are stored as digests. A content security policy restricts the page to its own origin and the API. Every tenant-owned table carries the workspace identifier, so there is no schema-level path from one workspace’s rows to another’s.

Where a personal data breach is likely to result in a risk to the rights and freedoms of natural persons, we will notify the competent supervisory authority in accordance with GDPR Article 33. Where the breach is likely to result in a high risk to your rights and freedoms, we will communicate it to you without undue delay at the email address associated with your re:mind account, unless an exception under GDPR Article 34 applies.

EU data protection law informs the design of this system rather than being applied to it afterwards: data minimisation, retention and deletion columns in the schema, erasure that does not destroy referenced immutable results, an Article 15 and 20 export, and no sensitive payload in logs or traces.

EU AI Act alignment is in progress. That is the strongest claim this product makes, in this notice, in the API and in its documentation. No certification, conformity assessment or approval is claimed, and none should be inferred.

This notice carries the version identifier below, and it is the same identifier recorded against your acceptance at sign-up and against your consent at the start of every assessment. A material change is published under a new identifier, and acceptance is collected against it rather than assumed.