Privacy notice
What Precision processes, why, and what you can do about it.
This notice explains what personal data Precision processes, why, on what legal basis, who receives it, how long it is kept, and what rights you have. It is written to satisfy the transparency duties in GDPR Art. 13 and Art. 14 (Regulation (EU) 2016/679) and nFADP Art. 19 (Swiss Federal Act on Data Protection, SR 235.1).
1. Who is responsible
Precision is delivered as a dedicated instance per customer — a separate deployment on a separate subdomain. Responsibility therefore splits in two.
1.1 Your employer is the controller for data inside a Precision instance
If you use Precision because your organisation gave you an account, your organisation is the controller of the data in that instance. They decided to use Precision, they decide who gets an account, what is recorded on a release, and how long the activity log is kept. Precision acts as their processor under GDPR Art. 28 / nFADP Art. 9, on their documented instructions.
Direct your access, correction and deletion requests to your organisation first. If you send one to Precision, we forward it to the controller and assist them under Art. 28(3)(e); we do not answer it on our own authority, because we are not entitled to.
1.2 Precision is the controller for its own website and mailing list
For the public website at
precisionrelease.org and for the
marketing / waiting-list mailing list, the
controller is
Sebastian Michaelsen, Bannstrasse 4,
6312 Steinhausen, Switzerland, reachable at
sebastian@michaelsen.io.
Temporary, by design
Precision is a pre-1.0 project with no incorporated legal entity yet. Sebastian Michaelsen stands in personally as controller for the scope this section covers — a public website and a waiting list whose entire exposure is one email address per subscriber. A proper legal entity is a precondition for taking on real business: it will replace this individual as controller, and as the counterparty on every processor agreement, before any customer instance goes live commercially.
No Swiss representative under nFADP Art. 14 is needed: that provision is for controllers domiciled abroad, and this controller is already domiciled in Switzerland.
2. What personal data is processed
2.1 Inside a Precision instance
| Category | Fields | Where it comes from |
|---|---|---|
| Account identity | Name, email address, avatar URL, provider user identifiers, email-verification timestamp, last-visited project. | Your identity provider, at sign-in. |
| Federated identity link | OAuth provider name, issuer and subject identifier — one row per linked provider. | Your identity provider. |
| Session | User id, IP address, user-agent string, encrypted session payload, last-activity timestamp. | Your browser. |
| API credentials | Personal access token name, hashed token, abilities, last-used and expiry timestamps. | Created by you. |
| Activity log | Who did what, to which release or event, through which channel (UI, REST, MCP or unknown), when, plus the change properties — and a SHA-256 hash chain over those rows. | Generated by your use of the product. |
| Sign-off record | Signing user reference, a snapshot of the printed signer name, the signing reason, the signing timestamp, and a hash of the signed record state. | Generated when you sign off a release. |
| External stakeholders | Name and optional email address of a person who is not a user of the instance but is recorded as a stakeholder on a release. | Entered by an instance user. |
| Attachments | Uploader reference, original filename, MIME type, size, and the file content itself. | Uploaded by instance users. |
| Free-text content | Release notes, highlights, checklist item labels, event notes. | Entered by instance users. |
On free text and attachments: Precision does not require personal data in these fields, but it cannot prevent it. What ends up there is determined by the controller's own usage policy, not by the product. Controllers should instruct their users accordingly; special-category data (GDPR Art. 9) has no place in a release record.
2.2 Error reports
Deployed instances report unhandled exceptions to GitLab Integrated Error Tracking. The payload carries the authenticated user's numeric ID only — no name and no email address — alongside the stack trace, release tag and server name. Retention there is 90 days.
2.3 On this public website
The public site is static and served from a Cloudflare Worker. It carries no analytics, no tracking scripts, no cookies and no third-party embeds. What remains is what any web server sees: the IP address, request URL, timestamp, user agent and referrer reaching Cloudflare's edge.
2.4 Webfonts inside the application UI
The authenticated application UI — as distinct
from this website — loads its webfonts from
fonts.bunny.net. Your browser
therefore contacts that third party, disclosing
your IP address and user agent to it. It is listed
in the sub-processor register.
3. Purposes and legal bases
3.1 Instance data — the controller's determination
For data inside a Precision instance the legal basis is the customer's to determine, not Precision's. In practice it is one of GDPR Art. 6(1)(b) (performance of the employment or service relationship), Art. 6(1)(c) (a legal obligation — DORA, FINMA Circular 2023/1 and BaFin BAIT all require documented, attributable change authorisation), or Art. 6(1)(f) (legitimate interest in operating and auditing ICT change management). Under Swiss law the corresponding frame is nFADP Art. 30/31: processing by a private person is lawful unless it unlawfully breaches the data subject's personality, with consent, an overriding private or public interest, or a statutory basis as grounds of justification.
Precision itself processes that data on a single basis: the controller's documented instructions under GDPR Art. 28(3)(a) / nFADP Art. 9.
3.2 Precision's own processing, as controller
| Purpose | Data | Legal basis |
|---|---|---|
| Serving and securing the public website | Edge request logs including IP address. | GDPR Art. 6(1)(f) — legitimate interest in delivering and protecting the site. nFADP Art. 31(1) — overriding private interest. Art. 31(2)(a) is not available here: a site visitor is not a contracting party. |
| Marketing / waiting-list email | Email address, opt-in timestamp. | GDPR Art. 6(1)(a) — consent. nFADP Art. 31(1) — consent. |
| Responding to an enquiry, and pre-contract contact | Name, email, message content. | GDPR Art. 6(1)(b) — pre-contractual steps. nFADP Art. 31(1) / 31(2)(a). |
| Diagnosing production errors | Numeric user ID, stack trace. | GDPR Art. 6(1)(f) — legitimate interest in a functioning, secure service. nFADP Art. 31(1). |
4. Who receives the data
Personal data is disclosed to the sub-processors listed on the compliance posture page. Precision does not sell personal data, does not use it to train models, and does not disclose it for any purpose other than delivering the service — except where disclosure is legally compelled, in which case the commitments in the processor agreement apply.
Two further disclosures are not sub-processing but do reach third parties, and are listed here rather than left out. The first is the identity provider's avatar host: once a user is signed in, the application renders their profile picture from the URL their identity provider supplied at sign-in, so their browser discloses its IP address and user agent to that host on every page load. The identity provider is the customer's own choice and does not process data on Precision's behalf, but the disclosure happens. The second is the set of channels a customer configures for themselves, below.
Personal data may leave an instance through
channels the customer themselves
configures: a digest email to project
members — the project's current members,
resolved live at send time, with no snapshotted
recipient list — a signed webhook POST to a URL
the customer supplies, or a Discord incoming
webhook. Two properties of the webhook channel
belong in this notice. Precision
does not require https
on that hop: the destination is validated as a URL
and nothing more, so an http://
receiver is accepted and the payload then crosses
the internet in cleartext. And with the
recent-activity section enabled, that payload
carries the name of each acting
user — directly identifying personal
data, not the pseudonymous identifier used for
error reports. The signature on the POST
authenticates the sender; it does not encrypt the
hop or keep the data in region. Section 11 of the
compliance
posture page sets out where these deliveries
go and what they carry.
The recipient of such a delivery is chosen by the controller, not by Precision, and Precision is not in a position to assess it. Controllers should treat each configured channel as an onward disclosure they are responsible for, transport encryption on the webhook hop included.
5. How long data is kept
Retention is set out per category in the retention statement that accompanies the processor agreement. The two headline points:
- The activity log retention window is operator-configurable. Its default is to never prune — an instance keeps its full audit history until the operator sets a positive window.
- Sign-off records are append-only. Withdrawing a sign-off does not delete the signature event; it flips the release status back and records the withdrawal. This is a deliberate audit property and it constrains what erasure can mean for that record — see section 6.
6. Your rights
Under the GDPR you have the right to:
| Article | Right |
|---|---|
| Art. 15 | Access your personal data and obtain a copy. |
| Art. 16 | Have inaccurate data rectified. |
| Art. 17 | Have data erased ("right to be forgotten"). |
| Art. 18 | Have processing restricted. |
| Art. 20 | Receive your data in a portable, machine-readable format and have it transmitted onward. |
| Art. 21 | Object to processing based on legitimate interests. |
| Art. 7(3) | Withdraw consent at any time, without affecting the lawfulness of processing before withdrawal. |
| Art. 77 | Lodge a complaint with a supervisory authority. |
Under the nFADP the corresponding rights are the right of access (Art. 25), the right to data portability (Art. 28), and the right to have incorrect personal data corrected (Art. 32(1)). Deletion of the data, and prohibition of a particular processing activity or disclosure, are claimed under Art. 32(2), which routes them through the personality-protection actions of the Civil Code rather than granting them as a direct statutory right — see 6.2.
6.1 Limits on erasure that you should know about
Two records in Precision are deliberately not erasable on request by the instance operator alone:
- The activity log is application-immutable. No code path updates or deletes a row; deletion happens only through the operator's retention window.
- Sign-off signature events are append-only and carry a printed-name snapshot.
Both exist because a regulated buyer's supervisor requires an attributable, tamper-evident record of who authorised a production change. An erasure request touching them is handled under GDPR Art. 17(3)(b) (processing necessary for compliance with a legal obligation) or Art. 17(3)(e) (establishment, exercise or defence of legal claims), as assessed by the controller — not waved away.
6.2 Complaining to a supervisory authority
Germany / EU. Under GDPR Art. 77(1) you may lodge a complaint with the supervisory authority of the EU member state of your habitual residence, your place of work, or the place of the alleged infringement. In Germany the competent authority is the data protection authority of the relevant federal state (Landesdatenschutzbehörde); the Federal Commissioner (BfDI) is competent only for federal public bodies and for telecommunications and postal providers. The BfDI publishes the list of state authorities at www.bfdi.bund.de.
No single lead authority applies here. The one-stop-shop mechanism (GDPR Art. 56) is for controllers with an establishment in the EU; the controller named in section 1.2 has none. Each data subject instead uses the individual complaint route in Art. 77(1) above — the authority of their own habitual residence, place of work, or the place of the alleged infringement.
Switzerland. The supervisory authority is the Federal Data Protection and Information Commissioner (FDPIC / EDÖB), www.edoeb.admin.ch. Note the difference from the EU regime: the FDPIC does not adjudicate individual complaints. It opens investigations on a report or of its own accord under nFADP Art. 49 and can issue orders under Art. 51. Individual data-subject claims are enforced through the civil courts under nFADP Art. 32(2).
7. Marketing and the waiting list
The waiting-list form on this site collects one field: your email address. Nothing else is required and nothing else is inferred. Signing up is a double opt-in: submitting the form sends a confirmation link, and your address is only added to the list once you click through on that link.
| Point | Commitment |
|---|---|
| What is collected | Your email address, plus the timestamp and the fact of your opt-in, kept as proof of consent under GDPR Art. 7(1). Stored in our own Cloudflare D1 database — no third-party form service ever receives it. |
| Why | To send you product-availability and closed-beta news about Precision. Nothing else. No newsletter about other products, no onward disclosure, no sale, no profiling. |
| Legal basis | Consent — GDPR Art. 6(1)(a), and consent as a ground of justification under nFADP Art. 31(1). Ticking the box on the form is the consent; the form is opt-in, unticked by default, and separate from any other agreement. |
| How to withdraw | At any time, with no reason and no disadvantage, under GDPR Art. 7(3) — using the unsubscribe link sent in the confirmation email, or by writing to the contact address in section 1.2. Withdrawal does not affect the lawfulness of mailings sent before it. |
| How long it is kept | Until you withdraw consent or ask to be removed, and no longer than 24 months after the last message you engaged with, whichever comes first. After removal the address is deleted; the record of the withdrawal itself is kept as evidence that the request was honoured. |
| Recipients | Only the mailing provider used to deliver these emails (Resend). |
8. International transfers
Some recipients in the sub-processor register are established outside the EEA and outside Switzerland — today that means US-incorporated companies.
- Transfers out of the EEA require a legal basis under GDPR Chapter V: an adequacy decision (Art. 45) or appropriate safeguards such as the Standard Contractual Clauses (Art. 46(2)(c)).
- Transfers out of Switzerland require that the destination state affords adequate protection — the list is in Annex 1 to the Swiss Data Protection Ordinance (SR 235.11) — or appropriate safeguards under nFADP Art. 16, with the narrow exceptions in Art. 17.
- Between the EEA and Switzerland, transfers are straightforward in both directions: Switzerland is recognised by the European Commission as providing an adequate level of protection under GDPR Art. 45, and the EEA states appear in Annex 1 to the Swiss ordinance.
Checked against the official Data Privacy Framework list on 16 September 2026: Cloudflare, Inc. and GitLab Inc. are both certified under the EU-U.S. DPF, the UK Extension, and the Swiss-U.S. DPF, covering EEA, UK and Swiss transfers. Resend is certified under the EU-U.S. DPF and the UK Extension only; its DPA separately incorporates the EU Standard Contractual Clauses, which cover the EEA leg independently of DPF status. The full breakdown, with participant-record links, is in section 12 of the compliance posture page.
9. Automated decision-making
Precision performs no automated decision-making producing legal or similarly significant effects within the meaning of GDPR Art. 22 or nFADP Art. 21. Every release decision the product records — planning, sign-off, completion — is taken by a named human and attributed to them.
Precision does expose an MCP server so that a user's own AI assistant can read and change release state through their credentials. Those actions are recorded in the activity log with the channel marked as MCP. The AI assistant is the user's own tool and is not operated by Precision; whatever the assistant reads is disclosed to whichever AI provider the user has chosen.
10. Security
The technical and organisational measures are maintained in the annex to the processor agreement. In summary: transport encryption, encrypted session cookies, no password storage at all (authentication is federated to the customer's identity provider), per-project role-based access control, a tamper-evident audit log, and a dedicated database per customer instance.
What is not in place is set out plainly on the compliance posture page — no certification, no external audit, no penetration test, and no documented backup or restore procedure.
11. Changes to this notice
This notice is versioned in the Precision repository alongside the code it describes. Material changes are communicated to customers under the notification terms of the processor agreement and, for the mailing list, by email to subscribers before the change takes effect.