Privacy Policy

Who is responsible for your data

Dominique Top is the data controller for the hosted dlectroflow instance at dlectroflow.dev — an individual in the United Kingdom, running it as a personal, non-commercial hobby project. There is no company, no business and no trade behind it: nothing is charged for, nothing is sold, and there is nothing to buy.

Being the controller means I am the person legally answerable for how your data is handled here, under the UK GDPR and the Data Protection Act 2018.

Being a hobby project does not make it exempt

This is worth saying out loud, because it is the obvious thing to wonder and the obvious thing for me to try to hide behind. The UK GDPR does not apply to processing by an individual “in the course of a purely personal or household activity” (Article 2(2)(c)). That exemption does not cover this, and I am not claiming it.

Two reasons, and either on its own is enough:

• dlectroflow is offered over the public internet to other people, and it processes their data on infrastructure I control. That is not my personal or household activity, whatever my motive for building it.
• Even where someone uses it for purely personal purposes of their own, Recital 18 says the Regulation still applies to whoever provides the means for that processing. That is me.

So every obligation in this notice is a real one, and every right below is a real right. Being unpaid changes what this project can afford; it does not change what you are entitled to.

Getting hold of me

For anything to do with privacy, your data, or your rights, write to privacy@dlectroflow.dev. That address is monitored and it is the right route for every request in this policy — you do not need to find another one.

There is no data protection officer: Article 37 requires one only for public authorities, for large-scale regular monitoring of people, or for large-scale processing of special category data, and this is none of those. The person reading that inbox is the same person who wrote the code.

What this policy covers

This policy covers only the instance running at dlectroflow.dev.

dlectroflow is open source under the AGPL-3.0 licence, and it is built to be self-hosted. If you run your own copy, that instance is yours: youare its controller, your users’ data never touches anything of mine, and this policy does not apply to it. If you are using someone else’s instance, ask them for their policy — not this one.

What I collect, and why

Everything here falls into one of four groups. Nothing is bought from a third party, inferred about you, or collected in the background.

1. What you write

This is the bulk of it, and it is all typed by you or produced by using the app:

• Brain-dump items — the free text you capture, plus when you captured, triaged, snoozed, saved or completed each one.
• Tasks and steps — titles, step text, emoji, time estimates and the history of those estimates, what is done, the scheduling intent you picked, and any note you write on a task or on a single step (up to 2,000 characters each). A note you write on a capture before you triage it is kept the same way.
• Coaching conversations — the messages you send the breakdown coach and the step lists it proposed back, kept against the task so you can see how it got there.
• Shopping list— the items you type on it, whether each one is ticked off, and whether you have moved it down to “saved for later”. Only if you switch shopping-list mode on in Settings: it is off by default, and nothing is stored until you add something. Switching it off again hides the list without deleting it, so the items stay until you delete them or delete your account.
• Focus sessions — start and end times, pauses, planned and added minutes, and how the session ended.
• Focus playlists — any playlist you create and the name you give it, plus which tracks you put in it.
• Daily roll-ups— the day’s counts, and a short AI-written narrative about your day (see Sending your text to an AI provider).
• Rewards — points events, your current streak, past streak records, badges earned, and the daily quote you were shown.
• Settings — voice, typeface, appearance, timer style, focus sounds, working days and hours, reminder times, freshness thresholds.
• AI usage counters — how many breakdowns have been requested, so a fair-use cap can be applied.

2. If you use it as a guest

You can use dlectroflow with no account at all. When you first arrive, a sandbox workspace is created for you and its identifier is put in a signed cookie. There is no name, no email address, and no sign-in — the sandbox is not linked to you as a person, only to that cookie.

One extra thing is stored for guests: a salted SHA-256 hash of your IP address, used purely to count AI breakdowns against the daily guest cap and the instance’s overall cap. The address itself is never written to the database — only the hash, and only with a secret salt, so it cannot be turned back into an address or matched against a list of addresses.

3. If you have an account

Accounts are invite-only. There is no sign-up form: your identity has to be on an allowlist before sign-in will work at all. Sign-in is through GitLab, and it is the only sign-in method.

• From GitLab: your GitLab user id, your username, and your email address if GitLab returns one. The only permission requested is read_user — no repositories, no code, no groups, no ability to act as you.
• A display name, if you set one — the name you would like to be greeted by, instead of your GitLab username. Optional, and blank until you type one.
• The invitation record: the username or email address that was entered to invite you, an optional private note written by whoever invited you, and when the invitation was created and claimed. This exists before you first sign in — it is what makes the allowlist work.
• Your account state: your role, whether the account is active or revoked, your AI allowance and how much of it you have used, and when you were last seen.

4. Optional connections

• Google Tasks, if connected: an encrypted access token and refresh token, the granted scope and its expiry, plus the Google list and task identifiers for anything pushed there — so a change updates the existing task instead of creating a duplicate. Details in Connecting Google Tasks.
• Your own AI provider API key, if you save one: the key itself, encrypted, and nothing else — no account name and no billing details, because the key is all the provider needs and all the app asks for. Signed-in accounts only. Details in Sending your text to an AI provider.
• A calendar subscription URL, if you create one: a single random token, so the URL is unguessable. Nothing else — no record of which calendar app you pasted it into, and the app itself writes nothing when your calendar fetches the feed. One caveat that matters here. The token is part of the web address, not a hidden header, and the web server in front of the app records the address of every request it handles — the ordinary access log described at the end of this section. So there is a record of when the feed was fetched, and it has the token in it. Those logs are deleted after 30 days, and you can replace the token from Settings at any time, which makes every logged copy of the old one useless. Signed-in accounts only. Details in Who else is involved.
• The end-of-day round-up email, if switched on: the email address you type in. It is off by default and guests cannot set one.

What is not collected

No analytics. No tracking pixels. No advertising. No profiling. No session recording. No device fingerprinting. No third-party scripts of any kind. This is not a policy position that could quietly lapse — there is no analytics or tracking package in the codebase at all, and because the source is public you can check that for yourself rather than take my word for it.

No payment details either: the hosted instance is free and there is nothing to pay.

One honest caveat about IP addresses. The application never stores your IP address, only the salted hash described above. But the web server sitting in front of it writes ordinary access logs, and those include IP addresses, as web server logs everywhere do. They are platform logs: kept for 30 days, never joined to your account or your content, and never used for analytics.

Those logs record the web address of each requestas well, which is the same everywhere and normally says nothing much. It is worth spelling out for one feature: a calendar subscription URL carries its token in the address, so the token appears in the log for as long as the log is kept. That is why the setting lets you replace it, and why the 30-day window is stated here rather than left as “however long logs last”.

My lawful basis for each purpose

The UK GDPR requires a lawful basis for each purpose, not one blanket basis for everything. Here is the honest breakdown, purpose by purpose.

• Running the app for someone with an account — storing and showing your tasks, steps, sessions, settings and rewards.
  Contract (Article 6(1)(b)). You accepted the Terms and asked me to provide the service; it cannot be provided without storing what you type into it.
• Running a guest sandbox for someone with no account.
  Legitimate interests (Article 6(1)(f)). My interest is letting you try the app without handing over an identity first — which is the more privacy-protective option, not the less. The data is only what you type, it is tied to a random identifier rather than to you, and it deletes itself within about a day. Weighing that against your interests, a trial that asks for nothing seems to be what most people would prefer; if you disagree, you can object.
• Signing you in and keeping your workspace yours.
  Contract (Article 6(1)(b)) for authenticating you and giving you access to your own workspace, and legitimate interests(Article 6(1)(f)) for the security machinery around it — signed sessions, and making sure one workspace can never read another’s data.
• Keeping the invitation allowlist.
  Legitimate interests(Article 6(1)(f)). Being invite-only is the main control that keeps a personal project’s data closed. It costs one username or email address per invitation and nothing else. If you were invited and would rather not be on the list, ask and it comes off.
• Generating AI task breakdowns — which means sending your task text to a third-party provider.
  Contract (Article 6(1)(b)). The breakdown is the feature you asked for, and it cannot happen without sending the text. This is deliberately notcalled consent: consent has to be freely given and freely withdrawable, and “withdraw it and the feature ceases to exist” is not a real choice, so labelling it consent would dress up a necessity as an option. If you would rather your text were not sent, do not use the breakdown — capture, tasks, steps, the focus timer and the rewards all work without it.
• Connecting Google Tasks.
  Consent(Article 6(1)(a)). Genuinely optional, separately asked for through Google’s own consent screen, and withdrawable at any time in Settings — which revokes the grant and deletes the stored tokens. If your access to this instance ends before you get round to it, the grant is withdrawn for you. Nothing else in the app stops working if you never connect it.
• The end-of-day round-up email.
  Consent (Article 6(1)(a)). Off by default. You type the address and switch it on; switching it off withdraws it.
• The guest fair-use cap — the salted IP hash.
  Legitimate interests(Article 6(1)(f)). The AI endpoint costs real money and is open to anyone with a browser; without a cap, one visitor can spend a whole day’s budget in a minute. The processing is minimised to a salted hash that is never the address itself, and it is deleted after 30 days.
• Backups, security, and keeping the service running.
  Legitimate interests (Article 6(1)(f)). Article 32 requires appropriate security in any case, and a service with no backups would be a worse deal for you than one with them.
• Answering a rights request, or a lawful legal demand.
  Legal obligation (Article 6(1)(c)).

Where I rely on legitimate interests, you can ask me for the balancing reasoning in more detail, and you can object — see Your rights.

Sending your text to an AI provider

This is the most significant thing that happens to your data, so it gets its own section rather than a line in a list.

To turn “sort out the tax return” into a list of small steps, the text has to go to a large language model, and that model is not mine. Anthropic (Anthropic PBC, United States) is the provider this instance uses.

What is sent

• When you ask for a breakdown: the task’s title, the steps currently proposed (their text, emoji and time estimates), and anything you typed into the “tell Claude how to adjust” box.
• Note where the title comes from.If you break down a brain-dump item, that item’s text becomes the task title — so the words you captured are sent. Brain-dump items you have not broken down are not sent anywhere.
• Your note on the task, if you have written one. The first 600 characters of it are quoted into the request, so the steps take account of what you already knew. Notes on other tasks, and on anything you have not asked to break down, are never sent.
• When the end-of-day roll-up is written (signed-in accounts only): the text of up to five steps you finished and up to three carrying over, so the narrative can mention them.
• When you overrun a focus stepand ask for a kinder estimate (signed-in accounts only): that step’s text and its current estimate.

What is not sent

Apart from the task title, the proposed steps, your note on that task and anything you typed into the “tell Claude how to adjust” box, the context sent alongside a breakdown is numbers and flags only — small integers, booleans and one preference. No identifiers, no email addresses and no dates. That one preference is the voice you picked, so the steps come back in the same tone as the rest of the app; your email address, your GitLab identity, your Google tokens and every other setting are never sent. Neither is the text of your other captures, your other tasks’ steps, or any other task’s note. The daily quote is generated from a fixed prompt containing nothing about you.

Training, and what happens to it there

I do not use your content to train anything, and Anthropic’s commercial terms state that they do not train their models on inputs or outputs sent through their API. Where the request is made on my API key — which is the default, and the case for everyone who has not saved their own — Anthropic processes this text on my instructions, as a processor, to answer the request and for nothing else. If you have saved your own key, the request is made on yours instead; see If you bring your own API key below.

Which provider, and why it matters

The code can talk to other providers — there is an OpenAI-compatible adapter for people self-hosting against a local model or another vendor — but which one is used is a deployment setting, chosen by whoever runs the instance, not something you choose in the app. On this instance that setting is Anthropic, and this instance uses Anthropic for every request — whoever is asking, and whether or not they brought their own key. If that ever changes here, this page changes with it and the effective date at the top moves.

If you bring your own API key

If you have an account, Settings lets you save your own API key for the AI provider. It is entirely optional — everything works without one — and guests cannot save a key, because there is no account to hold it against.

What saving a key changes:

• Your breakdowns are paid for by you, not by me. The instance’s fair-use cap on AI requests stops applying to your account, because it exists to protect my bill rather than to ration yours.
• The key is encrypted at restwith AES-256-GCM, the same way the Google tokens are, with the encryption key held in the deployment’s secrets rather than in the database. It is never displayed back to you, never sent to your browser, and never shown to anyone else — there is deliberately no “reveal my key” button. You can remove it in Settings whenever you like.
• The request is then made as you, so your own agreement with the provider governs it. Your text still travels from this server to the provider exactly as described above, but authenticated with your credentials — so it lands in your account with them and is subject to whatever terms you have accepted. The processing terms and transfer safeguards I rely on cover requests made on my key; they cannot cover requests made on yours.

And the significant thing it does not change: it is a key, not a destination. A key you save is used against this instance’s configured provider — Anthropic — and nothing else. It does not let you choose a different company, a different endpoint, or a different address for the server to send your text to, and there is no field in the app for any of those. That is a deliberate security decision rather than an oversight: a per-account setting that chose which host this server connects to would let anybody with an account aim it at a machine of their own choosing. Choosing your own provider is not something dlectroflow can do today, and if it is ever built, this page changes before it ships.

What the administrator can see about this is whether you have saved a key — a yes or no in the admin panel — and never the key itself.

Because Anthropic is in the United States, this is an international transfer of your data. It is not buried in a list — see Data that leaves the UK.

Connecting Google Tasks

Connecting Google is optional. Everything else works without it, and steps can be exported as a calendar file instead.

One permission, and only one

The connection requests exactly one OAuth scope:

https://www.googleapis.com/auth/tasks

Nothing else. No Gmail, no Calendar, no Drive, no Contacts, no access to your profile or photos, no ability to read anything outside Google Tasks.

What it is used for

Creating and updating tasks in a Google Tasks list inside your own connected Google account, so that a scheduling tool which syncs from that list can find them and book time for them. What is written is a task title (built from your task and step text, with a duration), a due date, and a notes field containing any note you wrote on that task or step, a short prompt line, and a link back into the focus timer. So if you write a note and schedule the step to Google, that note is copied into your Google Tasks list.

The only thing read from your Google account is the list of your Google Tasks list names, so the right list can be found to write into. Nothing from your Google account is copied into dlectroflow beyond the list and task identifiers needed to update the right task later.

Google data and the AI provider — they never meet

dlectroflow uses an AI model to break tasks into steps, and it uses Google Tasks to schedule them. Those two things never touch, and that is a property of how the connection is built rather than a rule somebody has to remember to follow.

Nothing from your Google account is ever sent to the AI provider. The Google connection only ever writes: it creates and updates tasks in your list. The one thing it reads is the names of your task lists, so it knows which list to write into — and a list name is not something the breakdown coach is given, because the coach is only ever given the text you typed here plus counts and dates. Put plainly, there is no path by which Google data could reach the model, because no Google data is held here to send.

It follows that nothing from your Google account is used to train, improve or evaluate any AI model, by me or by anyone else. Anthropic, the provider this instance uses, does not train on what is sent through its API either — see Sending your text to an AI provider for what does get sent, and what happens to it.

Google requires an explicit statement of this, so here it is in Google’s own words:

The use of raw or derived user data received from Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements.

Whose Google account it goes into — yours

If you have an account here, you can connect your own Google account, and the tasks dlectroflow creates are written into yourGoogle Tasks. Not the administrator’s, and not a shared one. Everyone who connects Google connects their own: there is one connection per person, each independent of the others, and each connected and disconnected by the person it belongs to.

Your connection is not visible or usable to anyone else — including me, as the person who administers this instance. The stored credential is held against your account and can only ever be looked up by the account it belongs to. There is no administrative route to somebody else’s Google connection: the admin panel cannot use it, cannot show it, and does not even disclose whether you have one. That is not a promise I am asking you to take on trust — an automated check reads the source on every change and fails the build if any query for a stored credential is not tied to the account making the request.

Guests cannot connect Google. It needs an account, because the connection has to belong to somebody.

Tokens, and how to disconnect

The access and refresh tokens are encrypted at rest using AES-256-GCM. The encryption key is held in the deployment’s secrets, not in the database, so a copy of the database on its own yields no usable tokens.

Disconnecting in Settingsasks Google to revoke the grant and then deletes your stored tokens — the deletion happens whether or not Google’s revoke call succeeds, so dead tokens are never left lying around.

The same happens if your access here is withdrawn. If your account is frozen by the administrator, or it is deleted, dlectroflow asks Google to revoke the grant first and then deletes the stored tokens — the same two steps, without you having to ask for them. That is a deliberate choice: the grant only ever existed so this app could write your tasks, and a frozen account can no longer reach the Disconnect button, so leaving the grant live would hand you a permission you could not withdraw here any more. Nothing in your Google account is deleted by this. What ends is dlectroflow’s access to it.

Being straight about the limits of that. Revoking is a call to Google, and that call can fail — a network problem, or a grant Google has already expired. When it does, your tokens are still deleted at this end, so the app is left with no way to try again and the grant can stay listed in your Google account until you clear it. The same is true of any connection that was frozen or deleted before this behaviour existed.

So the route that always works, and the one that does not depend on me at all, is your own Google account’s security settings: you can withdraw dlectroflow’s access there at any time, and it takes effect immediately whatever is or is not stored at this end.

Who else is involved

A short list, and it is the whole list. Your data is not sold, rented, traded or shared for anyone’s marketing — mine included.

• Google Cloud Platform — hosting. The servers, the database and the backup storage all run here, in the UK. A processor: it holds the data but may only act on my instructions.
• Anthropic (United States) — the AI provider that generates breakdowns, roll-up narratives and re-estimates. A processor, and an international transfer.
• Google Tasks — only if you connect it, and only to write into the connected Google account.
• Whichever calendar app you subscribe from— only if you create a calendar subscription URL and paste it somewhere. That app then fetches your scheduled step titles and times on its own schedule, and stores them wherever it stores calendars, which for Google Calendar, iCloud or Outlook means that company’s servers and quite possibly outside the UK. It is not my processor and I have no contract with it: you chose it and it is yours. What the feed carries is titles and times and nothing else — no notes, no coaching conversations, nothing about your account. Anyone holding the URL can read it without signing in, which is why the page you copy it from says so and why you can regenerate it at any time, invalidating the old one immediately.
• Resend(United States) — only if you switch on the end-of-day round-up email. It receives the address you gave and the email itself, which contains the day’s counts and the AI-written narrative. A processor, and an international transfer. Leave the feature off and Resend is never contacted.
• GitLab— the identity provider for sign-in. GitLab is not my processor: it is a service you already have an account with, and when you choose to sign in, your browser goes to GitLab and GitLab tells me your id, username and email address. GitLab’s own privacy notice governs what GitLab does.

Beyond that: nobody. No advertising networks, no data brokers, no analytics vendors, no “partners”. I would also disclose data if I were legally required to — a court order or a valid demand from a public authority — and I would tell you unless I were prohibited from doing so.

Data that leaves the UK

Your stored data sits in the UK. Two flows leave it, and both are named plainly rather than folded into a list of “service providers”.

• Anthropic, United States— the task text described above. The transfer relies on the standard data protection clauses permitted by Article 46 UK GDPR: the EU standard contractual clauses together with the UK International Data Transfer Addendum, as incorporated in Anthropic’s data processing terms.
• Resend, United States — the round-up email, only if you turn it on. Same safeguard: standard contractual clauses with the UK Addendum.

Two more worth being straight about. If you connect Google Tasks, tasks are written into your own Google account; Google LLC is certified under the UK Extension to the EU–US Data Privacy Framework, and its cloud terms also carry the standard clauses and UK Addendum. And although the hosting is in the UK, Google may access it from outside the UK for support purposes under those same terms.

You are entitled to a copy of the safeguards relied on. Ask at privacy@dlectroflow.dev and I will point you at them.

Where your data is stored

The application and its Postgres database run on Google Kubernetes Engine in London, United Kingdom (GCP europe-west2). The database is backed up nightly at 02:00 UTC to Google Cloud Storage in the same region.

So your data at rest — live and backed up — is in the United Kingdom.

One exception, and it is on your own device. If a brain dump cannot reach the server — patchy coverage, a dropped connection — it is held in this browser until it saves, so that closing the tab or losing signal does not lose the words. Nothing about that changes where it ends up: it is sent to the same servers as any other capture, and it is listed under Cookies below with how long it is kept.

How long I keep it

• Guest sandboxes expire on a fixed time-to-live — about a day from the moment the sandbox is created — and a job at 03:30 UTC each night deletes the expired ones and everything inside them. Worth knowing: continuing to use it does not push the expiry back, so a guest sandbox is one day, not a rolling one. If you want to keep what you captured, you need an account.
• Guest AI counters — including the salted IP hash — are deleted after 30 days by the same nightly job.
• Account data is kept for as long as you have an account, and until you ask for it to go. Deleting your own account, or having your access revoked, freezes it straight away: you are signed out, your Google connection here ends, and nothing can be written under it again. Being honest about what happens next: the content is not deleted automatically. There is a 30-day recovery window recorded against the account, but no job acts on it — the deletion is done by hand, by me, when you ask. Email me and it will be done. That is true whether you deleted the account yourself or I revoked it.
• Google tokensare kept until you disconnect, until your access here is revoked or your account is deleted, or until the grant is revoked at Google’s end — at which point they are cleared.
• A calendar subscription URLis kept until you turn the feed off or your account is deleted. Regenerating replaces the token, and the old URL stops working on the next request rather than at some later expiry. Turning the feed off removes the row altogether. The copies of the address in the web server’s access logs age out with those logs, after 30 days. Note what I cannot delete: anything your calendar app has already copied into its own storage is that app’s to remove, not mine.
• The round-up email address is kept until you clear it or turn the feature off.
• Backups are deleted after 30 days. This is the one that matters for erasure: when something is deleted it is gone from the app immediately, and gone from the backups within 30 days. I am not going to pretend backups do not exist.
• Cookies — see the table in Cookies.

How it is protected

• Encrypted in transit. HTTPS everywhere, with HTTP redirected and HSTS set for two years including subdomains, plus a strict Content-Security-Policy.
• Encrypted at rest where it counts. OAuth tokens and any stored provider API key are encrypted with AES-256-GCM, with the key held in the deployment’s secrets rather than the database.
• IP addresses are hashed, never stored. SHA-256 with a secret salt, as described above.
• No open sign-up. Sign-in is invite-only against an allowlist, so an attacker cannot simply create an account and start looking around.
• Sessions are signed tokens in cookies marked HttpOnly, SameSite=Lax and Secure.
• Workspace isolation is enforced structurally, not promised. A check in the build pipeline reads the source and fails the build if any database query against workspace-scoped data is not constrained to a single workspace. It is not a policy anyone has to remember: a change that broke the isolation would not merge.
• What an administrator can see: counts, never content. The admin panel shows a handle, a role, a status, an AI policy and how many breakdowns an account has used. It cannot show your tasks, your steps, your notes, your email address or your stored key — and the same automated check is what keeps that true rather than my word for it.
• Automated scanning for known vulnerabilities and risky code patterns runs on every change before it can ship.

And the honest limits. This is a personal project run by one person. There has been no third-party security audit. Encryption protects tokens and keys, not the task text itself, which has to be readable by the application to work. The source is public, so you can form your own view rather than trust an assurance — and if you find something wrong, the repository has a security policy telling you how to report it.

Cookies

There are six, they are all strictly necessary, and that is the entire list.

• df_guest — identifies your guest sandbox so the app can show you your own work. Without it an anonymous visitor has no workspace and the app cannot function. About a day.
• df_owner — your signed-in session. 30 days, or until you sign out.
• gitlab_oauth_state and gitlab_pkce_verifier — protect the GitLab sign-in round trip against request forgery and code interception. Deleted the moment sign-in finishes. 10 minutes.
• google_oauth_state and google_pkce_verifier — the same protection for connecting Google Tasks. 10 minutes.

All six exist solely to deliver the service you asked for, so under the Privacy and Electronic Communications Regulations no consent is required for them — which is why there is no cookie banner. There is nothing to consent to: no analytics cookie, no tracking cookie, no advertising cookie, no profiling cookie, and no third-party cookie of any kind.

Separately, your theme choice — follow my system, light or dark — is stored in your browser’s own local storage under df-theme. It never leaves your device and is never sent to the server.

Two more things live in this browser, and unlike the theme these can hold text you typed — so they are the one place your own words are stored outside the UK servers described above:

• df-capture-queue — brain dumps that have not reached the server yet, held so a dropped connection or a closed tab cannot lose them. Each one goes as soon as a connection allows. Kept until it saves, until you discard it from the “waiting to save” strip under the capture box, or — if it can no longer be saved to any account this browser can reach — until about a day after it was captured.
• A copy of the same queue in this browser’s IndexedDB, under the same name. It exists so the words can still be saved while the app is closed, which the browser cannot do from the list above. Kept until the capture saves, or until the app next opens and finds it is no longer waiting.

Both are yours to clear: discarding from the strip removes a capture from both, and clearing this site’s data in your browser settings removes all of it. Neither is used for anything but saving your captures — no analytics, no identifiers, nothing else.

Sensitive information, and a word about ADHD

dlectroflow is built for people with ADHD, so let me be direct about what that does and does not mean.

Using this app is not a diagnosis, and I do not record why you use it. There is no health field, no diagnosis field and no questionnaire, and nothing here asks you how you are. One thing comes close and is worth naming rather than glossing: at the end of your working day a short narrative about that day is written from your own counts — how many steps you finished, how long you focused, your streak — and stored with that day’s roll-up. It is a friendly summary of what you did, and no other person using this app can see it — it appears on your own dashboard, and, only if you switch the round-up email on, in that email, which means the email provider named in Who else is involved handles it on the way to your inbox. It is not an assessment of your health or your state of mind, and nothing acts on it. Beyond that, it is a to-do app with a kind tone. Plenty of people use it who have never been near an assessment.

What I cannot control is what you type into a free-text box. If you write “phone the psychiatrist about the dose change”, that is health information, and it is treated exactly like every other task: stored, and sent to the AI provider if you ask for a breakdown of it.

And I am not going to call that consent. Nothing here asks you for health information: there is no field for it, no question that invites it, and nothing that goes looking for it in what you write. What arrives is whatever you decided to put in a box you were using for something else. Calling that explicit consent would be the same dressing-up this page refuses a few sections earlier — I never asked you, and consent nobody sought is not consent. So what I hold is held for one reason only: it is an unavoidable part of doing the thing you directed me to do with the words you typed — keep them, show them back to you, break them into steps if you press the button, and put them on your calendar or into your Google Tasks list if you ask for that. Nothing else is done with it, and you can delete the item yourself at any time, or ask me to.

A practical suggestion, not a rule:the app works just as well if you write “phone the clinic” and keep the clinical detail out of it. Nothing is lost by being vague, and it is the simplest way to keep sensitive detail out of a system you did not build.

No automated decisions about you

Nothing here makes a decision about you. The AI suggests a list of steps; you accept them, edit them, reorder them, or throw them away. There is no scoring of people, no eligibility decision, no ranking, and no automated decision producing legal or similarly significant effects — so the Article 22 rules on automated decision-making do not come into play.

Streaks, points and badges are counters of what you did, calculated automatically. They produce a number on your own dashboard and nothing else: no consequence, no judgement, nothing shared with anyone.

Your rights, and how to use them

Under the UK GDPR you have all of the following. To use any of them, email privacy@dlectroflow.dev — one address, no forms.

• Access — a copy of the personal data I hold about you, and confirmation of how it is used. Settings → Account → Export your data downloads it, straight away, without asking me.
• Rectification — correction of anything inaccurate or incomplete. Most of it you can edit yourself in the app.
• Erasure — deletion of your data. If you have an account, Settings → Account → Delete my account starts it: you are signed out, your Google connection here ends, and the 30-day recovery window described above begins. Removing the content itself is a hand operation, so ask and it goes. The instance owner’s own account is the exception — it is the only one that can administer the instance, so it cannot be deleted from the app.
• Restriction — you can ask me to stop using your data while a dispute about its accuracy or my basis for holding it is sorted out.
• Portability — your data in a structured, machine-readable form. The same export gives you one .zip holding your tasks and their steps, your brain-dump inbox, the coaching conversations, your settings, your scheduled work as a calendar file, and a lossless JSON copy of all of it. A README inside explains each file and says what is deliberately not there. Ask instead if you would rather, or if you want another format.
• Objection — you can object to anything I do on the basis of legitimate interests (the guest sandbox, the allowlist, the fair-use cap, security and backups). Tell me and I will either stop or explain the compelling grounds for continuing.
• Withdrawing consent — disconnect Google in Settings, or switch the round-up email off. Either takes effect immediately. You can also just ask me.

How that actually works here

Access and portability you can do yourself. Settings → Account → Export your data downloads everything this app holds about your account, in formats that open with no special software. That includes the records kept about your account rather than typed into it: your invitation record and any private note whoever invited you wrote on it, your AI usage count, when your calendar feed was created and last regenerated, whether the account is active or revoked, when it was last seen, when access was withdrawn if it ever was, and the account id GitLab issued for you. The invitation note is in there because it is about you, and you should not have to ask me for it.

Three things are held back, and all three are keys. The OAuth tokens for your Google connection, any LLM API key you have stored, and the secret address of your calendar feed. Putting a copy of any of them in a file you might forward to somebody would be the opposite of protecting your data, and none of them is a record of anything — so the download loses nothing by leaving them out. Your feed address is in Settings → Integrations → Calendar subscription whenever you want it, and reconnecting Google or re-entering a key takes seconds. Nothing else is held back. If you think something is missing, ask at privacy@dlectroflow.dev.

Erasure you can start yourself. Settings → Account → Delete my account ends your access straight away and starts a 30-day recovery window, so an accident can be undone. It does not delete the content — that step is done by hand today, not by a scheduled job, and it does not happen on its own when the window is up. So if you want the content gone, email me and say so. I will do it and confirm.

I will respond within one month of your request, which is the statutory deadline. If a request is genuinely complex I may extend that by up to two further months, and if I do, I will tell you why inside the first month. There is no charge, unless a request is manifestly unfounded or excessive.

I may need to check you control the GitLab identity your account is linked to, so that I do not hand your data to somebody else claiming to be you.

One real limitation, for guests.A guest sandbox has no identity attached to it — that is the point of it — so I have no way to find “your” sandbox from an email address. It will expire and be deleted on its own within about a day. The export is the exception — it works in a sandbox exactly as it does for an account, and it is the only way anything you did in one outlives it. To be rid of it sooner, clear the df_guestcookie or use a private window. If you want it deleted now and can read the sandbox identifier out of that cookie in your browser’s developer tools, send it to me and I will delete it.

Nothing in this policy or in the Terms limits your rights under UK data protection law.

Complaining to the ICO

If you think I have handled your data badly, please tell me first — I would genuinely rather fix it than have you discover I cannot be bothered. But you do not have to, and you lose nothing by going straight to the regulator.

The UK supervisory authority is the Information Commissioner’s Office:

• ico.org.uk/make-a-complaint
• Helpline: 0303 123 1113
• Information Commissioner’s Office, Wycliffe House, Water Lane, Wilmslow, Cheshire, SK9 5AF

Children

dlectroflow is not intended for children under 13. In the UK, 13 is the age at which a child can consent to an online service like this one on their own behalf.

Accounts are invite-only, so I know who has one. Guest use needs no account, which means I have no way to verify anyone’s age — so if you are a parent or carer and believe a child’s data is in here, email privacy@dlectroflow.dev and I will delete it.

Changes to this policy

The effective date at the top of this page is its version. If the substance changes, that date changes with it in the same breath.

Because this is an open-source project, the complete, timestamped history of every word on this page is public in the source repository. You can see exactly what changed and when — which is a considerably better change log than an email saying a policy has been updated.

There is no in-app notification system yet, so the effective date and that history are the reliable ways to check. If a change would materially reduce your protections and the law requires your consent, I will ask before it takes effect, not after.