Privacy Policy

Who we are and what this covers

This Privacy Policy describes how AI4Kanban ("AI4Kanban," "we," "us") handles personal information when you use the website at ai4kanban.dev, the AI4Kanban desktop app and the akb command, and AI4Kanban Cloud (together, the "Service").

AI4Kanban is operated by NULLREACH LTD, a private limited company registered in England and Wales, with a registered office at Suite 11615, 61 Bridge Street, Kington, United Kingdom, HR5 3DJ. NULLREACH LTD is the data controller for personal information processed through the Service for the purposes of UK, EU, and Swiss data protection law. Our data protection contact is Tao Wu, reachable at [email protected].

Use of the Service is also governed by our Terms of Service.

The three parts of the Service handle data very differently, so the three sections that follow answer them one at a time: the site you are reading, the app you install, and the Cloud preview a board's events can be relayed through. The rights and boilerplate sections after them apply to all three.

Visiting the site

ai4kanban.dev is a static website. Every page is a file built ahead of time and served by Cloudflare Pages; there is no application server behind it and no database.

• We count page loads and download presses, and nothing else. There is no analytics product on this site — no third-party script, no session recorder, no dashboard. The counter is a few lines of our own that post to t.ai4kanban.dev, the endpoint the app reports to, and the whole of what it sends is the table below. It answers one question: of the people who reach a page with a download button, how many press it.
• No cookies. The site sets no cookies of any kind, essential or otherwise, and stores nothing in your browser — no local storage, no identifier. There is no cookie banner because there is nothing to consent to.
• No advertising or tracking pixels. There are no ad networks, no data brokers, no retargeting tags, and no third-party trackers embedded in any page.
• No accounts. There is nothing to sign up for on this site, and no form that asks for your email address.

What the site counts

Two events, and this is the whole of what each holds:

Both also carry the calendar date your own browser's clock saw, and the country worked out from the address the request arrived from — the address itself is not stored, exactly as it is not for the app.

Neither carries an identifier of anything. No install id, no visitor id, no session, and nothing derived from your browser or your machine. Two loads of the same page are two events with nothing in common, so we cannot tell your second visit from somebody else's first, and the number we get is a rate per visit rather than per person. A click that leaves this site for GitHub is what counts as a press; a click that stays on the site is not.

Nothing you see waits on it. The count is sent once the page is usable, and a download starts whether the count was sent, blocked, refused, or slow. A count that fails is dropped rather than retried or queued — there is nowhere in your browser we would keep it.

The raw events are kept 90 days and then deleted; the daily totals worked out from them hold nothing about any one visit and are kept indefinitely. There is no id to quote and nothing stored that could be yours, so there is nothing here to request or delete. A content blocker that stops the request is the whole of the opt-out, and it costs you nothing else on this site.

The one thing we do not control is the delivery itself. Cloudflare, as our hosting and content delivery provider, processes the technical request data that any web server sees — your IP address, the page requested, your user agent, and a timestamp — to route the request and protect the site from abuse. That processing is Cloudflare's own, under their published privacy documentation, and we do not receive, keep, or query those logs. Cloud's API is a different system with a log of its own, described below.

Pages on the site link out to other places, including GitHub. Once you follow a link, the site you land on is governed by its own privacy policy, not this one.

Using the app

The AI4Kanban desktop app and the akb command run on your own machine. A board is a folder of Markdown files inside your own repository, and the app reads and writes those files locally.

For a local board — one you have not turned Cloud on for — no part of your board, your project, your prompts, or your work is sent to us. Anonymous usage reporting, described below, is the one thing that reaches us from a local board, and it carries none of those.

• No account and no sign-in are needed to install or use the app on a local board.
• Anonymous usage reporting is on unless you turn it off. It says which features are used and which of them fail. It carries no part of your board and nothing that identifies you, and the whole of what it does carry is listed under "What usage reporting sends" below.
• The other network request the app makes on its own is to api.github.com, once, to ask which release of AI4Kanban is newest, so it can tell you when a newer build is out. That request is unauthenticated, carries no identifier of yours, and sends nothing about your board or your machine. If it fails, the app carries on without a notice. GitHub sees the request as it would see any anonymous visitor: your IP address, a static user agent, and a timestamp. Turning usage reporting off does not stop it — it is the app telling you something, not a report about you.

Turning Cloud on for a board is what changes that, and it reaches two destinations rather than one. Neither is contacted for a board you have not turned Cloud on for:

• api.ai4kanban.dev — where the app and akb send that board's events, the board's name, and the machine record of the computer running it. The next section says what each of those holds.
• The Supabase project behind sign-in — where the app signs you in through your own browser, refreshes that sign-in, and holds a live socket open so a decision you press elsewhere reaches the machine in seconds.

The coding agent you point at your board is separate software with its own account, its own model provider, and its own privacy policy. It runs on your machine under your control, and what it sends to its provider is governed by that provider's terms — not by this policy.

That agent's traffic and usage reporting are not the same thing, and it is worth saying which is which. Asking an agent to work on a card sends your prompt, and as much of your code as the agent decides it needs, to that agent's model provider — because that is the work you asked for. Usage reporting sends us none of it: not a prompt, not a line of code, not a card's text, not a file path, not a project name. It sends the names of things that happened, and the fields listed below.

What usage reporting sends

Reporting is on when you have not answered, in the app and in the akb command. It goes to t.ai4kanban.dev, an endpoint we run on Cloudflare, and to nowhere else. There is no third-party analytics product anywhere in the app.

Every event carries the same seven fields and nothing more:

The events are the whole list, and what each adds to those seven:

What it never carries, on any event: a card id, title or body; a file path; a repository, folder or project name; a branch name or commit message; your goal text; anything you or an agent typed; a model prompt or response; your name, email address or GitHub handle; your IP address; and the machine identifier a Cloud board registers.

Your IP address reaches the endpoint the way it reaches any web server. It is used for two things and then discarded: the country above, and an hourly request count kept against a one-way hash of the address, in memory, so that one script cannot spend a day's capacity. The address itself is never written to the database.

Events are queued on your own machine and sent in batches, at most one batch a day, at a time of day your install picks for itself. An offline machine loses nothing and never waits on the network; a machine that stays offline simply never sends, and the queue is capped rather than allowed to grow.

How long it is kept, and how to have it deleted

• The events themselves are kept for 90 days in the database and then deleted.
• A daily archive of those same events is kept indefinitely. Before the 90-day deletion, one day's raw events are written as a single file to Cloudflare object storage we run. The file carries everything the events did, including the install id, so a question asked years later can still be answered.
• Daily totals worked out from them are kept indefinitely. They carry no install id and nothing about any one machine.

To have your install's events deleted, email [email protected] with your install id. You can read it in the app under Configuration → General → Privacy, or by running akb telemetry status. We delete the database rows, and rewrite every archive file your install appears in without your events. A machine that has never sent anything has no install id, and there is nothing to delete.

Turning usage reporting off

Three places, all the same setting, held on your machine outside every repository so one answer covers every project you open and every terminal on it:

• The Help improve AI4Kanban step the app shows you once, before your first board opens.
• Configuration → General → Privacy, at any time afterwards.
• akb telemetry off, which needs no app and never prompts.

Turning it off stops reporting immediately, deletes anything queued on your machine and not yet sent, and forgets the install id. Turning it back on makes a new install id; the old one is not brought back, and we cannot connect the two. Events already sent are deleted on request, as above.

Using AI4Kanban Cloud

AI4Kanban Cloud is an invite-only preview. It relays the task events a board raises — a review to approve, a question to answer — and the decisions made on them, so you can act on a board without being at the machine it runs on. It can also hold the board itself, in a workspace — a choice you make board by board, and never the default. The repository around a board, and the agent that works on it, stay on your machine either way.

What Cloud is, and what this release does not ship, is described on /cloud. This section says only what it does with your information.

Using it is a deliberate choice: you install the app on a local board, sign in, and turn Cloud on for a board afterwards. If you never do, nothing in this section applies to you.

A workspace can hold more than one person; everything else belongs to one account. A workspace answers the people an owner has added to it, in one of two roles — an owner, who runs its name, its members and its machines, and a member, who does everything else on the board. Every other record described below — your account, your admission, your invite request, your Slack and Lark connections, and the boards and events of the 0.8.0 relay — belongs to one signed-in account, and Cloud answers that account alone.

What the other people in a workspace can see. Everyone in it reads the whole board — every card, every memory file, every release and the whole history — and the workspace's record of who did what, which carries each person's GitHub handle beside every change. Adding somebody to a workspace shows them your handle and everything you have done in it. Nobody outside it sees any of it.

What an event holds

Turning Cloud on for a board sends Cloud one event per task that needs a person: a task that reaches ready, or one that raises a question only you can answer. An event holds that task's number, title, release, and current revision, the decision it asks for, and — when it is a question — each question with its options and the board's recommendation.

It also holds enough of the card to review it away from your machine: the card's opening paragraph and its review notes — the sections a card writes under Worth noting — shortened before they are sent. Approving a build off a title alone is not a review, and the machine that raised the event may be switched off when you read it.

Those are your own words leaving your machine, stored as you wrote them. Everything else stays behind: not the plan, not the todo list, not the rest of the body, not your memory files, not your releases, and not the board's configuration. Treat a card's opening paragraph the way you would treat a line in a shared document.

Once you act on an event, Cloud also holds the decision you made and the answers you gave, and how the run it started ended. Where the event was delivered — a Slack or Lark message, say — is recorded against it too.

An event is kept while it is unresolved, and deleted 30 days after it reaches a final outcome — completed, failed, cancelled, interrupted, or retired because the task stopped needing you. An event no machine ever reports on reaches no final outcome, so it is kept rather than swept. Deleting it takes its answers, its outcome, and any message it was delivered as with it.

Which message in a chat is the card's

A task keeps one message in each chat you connected, and its events are logged in the thread under it. So Cloud holds which message that is: the board, the task number, the chat you connected, and the chat's own identifier for that message. It holds none of the message's words, and nothing about who read it or replied to it. It is deleted when the task's last event is, and it goes with the board and the account it belongs to.

What a board is registered as

A board on Cloud is an identifier that means nothing outside Cloud, and a name — the name of the folder the board sits in. The app reads that name rather than asking you for one, so a folder named after a client names that client on Cloud. The path the board sits at is never sent, only that last part of it. If a folder's name would say something you would not put in a shared document, rename it before you turn Cloud on.

What a board's machine record holds

A board runs its work on a computer, so that computer registers itself with Cloud — otherwise an approval you press in Slack or Lark has nowhere to run. A workspace holds one record for each machine the people in it open it from, and the record names the account that registered it, so everyone in the workspace can tell one machine from another. The record holds two things and no more:

• A machine identifier the computer generated for itself. It is tied to no account and to nothing about your hardware, and it means nothing outside Cloud.
• The name that computer calls itself — its hostname, so you can tell one of your machines from another. Never an address.

Which coding agent and which model a board runs is never sent. It stays in your repository and on your computer.

Nothing in the preview deletes this record. Turning Cloud off for a board stops that machine reaching Cloud and forgets the board on the machine; the record stays. Moving the board to another machine retires the old computer's record rather than deleting it, so a job that machine started and never finished can still be accounted for. Every machine record a board ever registered is kept until we remove it by hand — see Removing your Cloud records below.

What never reaches Cloud

Cloud relays a board's events. It does not run your project, and the following never leave your machine:

• Your source code, your repository, your working tree, your branches, your commits, and your merges.
• Your board itself — your cards in full, your memory files, your releases, and the board's configuration. Cloud sees the part of a card an event carries, and nothing else.
• Your credentials — Git remotes, SSH keys, tokens, and anything in your environment.
• Your model provider keys and accounts. Your coding agent runs locally, under your own account with your own provider. The board's machine record names which agent and model a computer runs — the names alone, never anything you sign in with.
• Agent transcripts and prompts. A run happens on your machine; Cloud sees the event it produced, not the conversation that produced it.

No AI model is ever run over your board content. We do not send an event, or anything else your board publishes, to an AI provider, and we do not use your board content to train any model, ours or anyone else's.

What signing in stores about you

You sign in to Cloud with a GitHub account, through Supabase Auth's GitHub provider. Our GitHub OAuth app requests user:email and nothing else, so a sign-in reads your profile and the email address GitHub has verified for you, and cannot reach a private repository even if everything else went wrong. We ask for the address because it is where we answer an invite request, so nothing about asking for one has to be typed.

Signing in creates two separate records, and removing one does not remove the other:

• A sign-in record, held by Supabase Auth on our behalf. It holds your GitHub login and public profile as GitHub returns it at sign-in — your username, your numeric GitHub id, your display name, and your avatar URL — any email address Supabase Auth records with that account, and sign-in timestamps with the identity provider behind the account, which is github for everyone.
• A Cloud account row, in our own database. It holds your GitHub handle, your display name, and your avatar URL, and it is what every other Cloud record — a board, an event, a machine record, a Slack or Lark connection — belongs to.

If we have admitted you to the preview, we also hold an admission: the GitHub handle we let in, when we let it in, and a short note of our own saying who you are, so whoever reads the list later can tell. When we admitted you by approving a request, it also holds the sign-in it was written for, so that renaming your GitHub account cannot take your place in the preview away.

We do not ask you to type an address, we have no mailing list, and we send nothing to it but the answer to an invite request and the preview notice below. You can ask us to remove any of these records at [email protected].

Asking for an invite, and the answer

Cloud is invite-only, so there is one record behind getting in, and it holds your email address:

• An invite request — written when you press Request an invite in the app. It holds your GitHub handle, the email address GitHub has verified for your account, and when you asked. You type none of it: it is read from what the identity provider attested at sign-in. Once we approve it, the same record holds that we answered it and when, and whether the message telling you so has gone out.

Approving is the whole of it: it admits your account and there is nothing for you to paste back. We email you once, to that address, from [email protected] with [email protected] to reply to. A request also sends us a notice at [email protected] carrying your handle and address, so we can answer you by replying.

Beyond that loop, the preview sends one other email: a notice about the preview itself — that it is ending, or that these pages have changed materially. It goes by hand from [email protected] to the address GitHub verified for your account. It is the one mail the preview sends that you did not ask for, and there is no way to switch it off. That is the whole of the email the preview sends: no mailing list, no announcement, and no marketing.

If you asked and we never admitted you, we still hold your records. Your invite request — your GitHub handle, the address GitHub verified for you, and when you asked — and your sign-in record both stay. No sweep reaches them and there is no action you can take that does; we remove them by hand when you write to [email protected]. Nothing on this page or in the Terms ties how long those records are kept to your being admitted.

That mail goes through Resend, and the [email protected] mailbox is run for us too. Both are subprocessors and both appear in the table below. Resend keeps 30 days of sending logs under its own policy.

Where it runs, and who can read it

• The database is a Supabase Postgres project in eu-central-1 (Frankfurt, Germany), inside the EU. It holds Cloud's records and nothing else.
• The API runs on Cloudflare Workers at api.ai4kanban.dev.
• Every record answers the account it belongs to, or the workspace it is in. A Cloud route is called with your own verified sign-in — or, for a decision pressed in Slack or Lark, with a callback that chat signs. A workspace answers only the people an owner has added to it, and a workspace that was deleted and one you were never in are refused identically, so nothing says whether a workspace exists. Everything outside a workspace refuses a record belonging to anyone else. There is no way into another account's records, no public link, and no read-only web view.
• The database is not a client API. Only the service can reach it: its tables are closed to every role, the project serves only the small set of functions the service calls, and its keys never leave the service.
• We can technically reach the database, as the operator of any hosted service can. We access an account's records only when it is necessary to run the Service, to investigate a fault, or where the law requires it — not to read your board.
• The API keeps a request log of its own. Cloudflare retains it, and we can query it while it lasts — unlike the static site's delivery logs above, which we never receive. What the API writes to that log is a status, a database error code, the kind of mail attempted, and an internal reference: no board content, no GitHub handle, and no email address.

Subprocessors

Four subprocessors and one identity provider, across the whole Service — the Cloud preview, and the usage reporting a local install does. There is no separate subprocessors page, because this is the whole list:

Each processes data on our behalf under its published data processing agreement. If we add or replace a subprocessor, this table changes with it and the effective date at the top of the page moves.

Slack, Lark, and anywhere else you choose to send board content

You can connect Slack or Lark — which is 飞书 in China and Lark internationally — so that a question or a review request is posted into a channel, a group, or a direct message you already read, and decided from there. One connection per chat belongs to your account, and every board you turn Cloud on for shares it. You can connect both at once. You connect each one and you disconnect it; nobody else can.

When Cloud posts, the content of that message — the card's title, its opening paragraph, its review notes, the question being asked, and a link back into the app — leaves Cloud and goes to that chat on your own instruction. Anyone who can see that conversation can read it.

We do not present either chat as infrastructure AI4Kanban runs on: you install our app into your own Slack workspace or your own Lark organisation, choose the one conversation it posts to, and can disconnect it at any time. Once a message is in Slack or Lark, it is governed by that workspace's or organisation's own settings and retention policy, not by ours. The same is true of anything else you choose to point a board at.

What we hold for a Slack connection is the Slack workspace, the conversation you picked, the Slack account you connected as — which is what makes a decision you press there yours — and the token Slack issued us for posting. Disconnecting deletes the connection and that token at once.

What we hold for a Lark connection is which of the two clouds it is, the Lark organisation that installed the app, the chat you picked, the Lark account you connected as, and the short-lived token Lark issues us for posting into that organisation. Disconnecting deletes the connection at once; the posting token is issued to the app rather than to your account, and uninstalling AI4Kanban in Lark is what ends that.

A decision pressed in either chat comes back as a callback that chat signs and the service verifies before it counts for anything. We never read a message in either, including our own, and we ask for no permission that would let us.

Removing your Cloud records

Disconnecting Slack or Lark is the only removal you can make for yourself. It deletes that connection at once.

Nothing else in the app deletes anything. Signing out stops that machine reaching Cloud and removes no record. Turning Cloud off for a board, or moving the board to another machine, removes no record either.

Everything else we remove by hand, on a request to [email protected]. What that removes is your whole account and everything under it: your Cloud account row and your admission, your board rows with their names, every machine record those boards registered, every event with its questions, decisions, answers and outcomes, which message in a chat each task is, your Slack and Lark connections, your invite request, and your membership of every workspace you are in. Your sign-in record goes alongside them, as its own step in Supabase rather than by the same operation.

What it does not remove is a workspace, or your name on what you did in one. A workspace you are in belongs to the people in it, so removing your account takes your membership and your machines out of it and leaves the workspace and its board where they are. The workspace's record of what happened keeps the GitHub handle you had at the time, written into each line as it happened, so the people still in it can read their own history. If you own a workspace, we cannot remove your account until you have made somebody else an owner or deleted it — otherwise a board a whole team is using would go with you.

It is all of it or none of it. The service has no way to remove one board's record and leave the account behind it, so asking us to forget a board ends your place in the preview. If that is not what you meant, tell us what you need and we will say what we can do.

The one thing that removes itself is finished event history, 30 days after an event reaches a final outcome.

What losing Cloud would cost you

The preview keeps no backups of its own, so nothing is restored if a record is lost, and no copy survives anywhere for us to hand over or be compelled to produce.

What you would lose is your event history and the decisions recorded against it — which task asked what, what you answered, and how the run ended.

A Local board is not at risk. Its cards, memory files, releases and configuration are Markdown in your own repository, on your own machine, and they are the same files whether Cloud is on or off.

A Cloud board is, and the export is what answers that. Its cards, memory, releases and history live in the workspace, so losing the workspace would lose them. Export it whenever you want a copy: the app writes the whole board — the archive and the finished work included — as Markdown into a folder you choose, and that folder opens as a Local board. The preview keeps no backups of its own, so that export is the only copy anybody can restore from. Leaving Cloud writes the board back into docs/kanban/ and takes the pointer off for that checkout, and deleting the workspace removes it and everything in it for everybody in it — an owner's move. Both are in the app, under Configuration → Workspace. A copy of what Cloud holds about you is a data request — see Your rights and choices.

Making a data request about Cloud

Write to [email protected] for anything in this section: a copy of what Cloud holds about you, a correction, the removal of your records, or a question about how any of it works.

How we use information

We use information to:

• Run the Service — serve the site, tell the app whether a newer release exists, and relay a board's events and the decisions made on them, to and from the account they belong to.
• Understand whether the product works — count how the app and the akb command are used and where they fail, and how many people who reach a page with a download button press it, from the anonymous reports described above, so we can decide what to build and what to fix. We read these as totals, never as one machine's or one visitor's story, and we do not attempt to work out who an install id belongs to.
• Keep the Service safe — verify a sign-in, check that a record belongs to the account asking for it, detect abuse, and stay inside the capacity the preview runs on.
• Send you a service notice — the answer to the invite request you made, and a notice about the preview itself: that it is ending, or that these pages have changed materially. Both go to the email address GitHub verified for your account.
• Answer you — handle a support message or a data request you send us.
• Comply with legal obligations that apply to us.

We do not use your information for advertising, profiling, or scoring, and we do not use your board content to train AI models.

For users in the EU, the UK, and Switzerland, the legal bases we rely on are:

• Contract — running the Service you asked for, including holding the Cloud records of the account that turned Cloud on, and answering the invite request you made.
• Legitimate interests — keeping the Service secure and working, preventing abuse, telling an account in the preview that the preview is ending or that these pages have materially changed, understanding how the app is used from anonymous usage reporting, which you can turn off at any time and which we disclose before your first board opens, and the two counts this site keeps, which carry no identifier and so are about no one in particular.
• Legal obligation — when a law applies to us.

We rely on consent for nothing today: there is no marketing email, no non-essential cookie, and nothing the site stores in your browser to consent to. Anonymous usage reporting is optional and disclosed before your first board opens, and it rests on legitimate interests rather than on consent, so turning it off is the choice you make and we do not ask you for one again.

How we share information

We do not sell or share your personal information for cross-context behavioral advertising, as those terms are defined under the CCPA / CPRA and similar laws. We have never had a contractual relationship with an ad network or a data broker for that purpose.

We share information only in these limited cases:

• Service providers (processors) — the subprocessors named above, who run parts of the Service on our behalf. They process data only to perform the service we asked for, under written data processing agreements.
• Legal and safety — when required by law, by valid legal process, or to protect the rights, property, or safety of AI4Kanban, our users, or the public.
• Business transfers — if AI4Kanban is involved in a merger, acquisition, financing, or asset sale, information may form part of that transaction. We will give notice before any personal information becomes subject to a different privacy policy.
• With your direction — when you ask us to send something somewhere, such as the Slack or Lark conversation you connected.

Cookies and tracking

The site sets no cookies and stores nothing in your browser. The two things it counts are described above, and neither carries an identifier of any kind.

Cloud's sign-in is not a browser cookie either. Signing in happens once per machine and the session is stored locally by the app, kept out of your repository, and used by both the app and the akb command. Signing out removes it.

We do not use tracking pixels, fingerprinting, or cross-site identifiers anywhere in the Service. The install id that anonymous usage reporting carries is none of those: it is a random value your own machine makes, it is used on no website, and turning reporting off deletes it.

Data retention

We keep personal information only as long as we need it for the purposes described in this Policy:

• Site visits — the two counts described above are kept for 90 days and then deleted, and the daily totals worked out from them are kept indefinitely. Neither holds an identifier, so nothing in them is about a particular person. Cloudflare's own delivery logs are kept under Cloudflare's policy and are not ours to query.
• Usage reporting events — kept for 90 days in the database and then deleted. A daily archive file of those same raw events, install id and all, is written to object storage before that deletion and kept indefinitely. The daily totals worked out from them carry no install id and are kept indefinitely. Turning reporting off deletes what is still queued on your machine and forgets your install id; the events already with us are deleted on request, quoting that id.
• The rest of app use — nothing is retained, because nothing else is collected. Apart from usage reporting, a board you have not turned Cloud on for sends us nothing to retain.
• Your sign-in record — held by Supabase Auth, kept while your account can sign in. Only a request to [email protected] removes it, and removing it is its own step: it does not go with your Cloud records automatically.
• Your Cloud account row and your admission — kept until we remove them by hand on a request to [email protected].
• Your invite request — kept until we remove it by hand, whether or not we admitted you. A request we never approved stays until you ask us to delete it. Resend's own sending logs are kept for 30 days under Resend's policy.
• A board's Cloud id and its name — kept until we remove them by hand. Turning Cloud off for a board, moving it to another machine, and signing out delete nothing.
• Events and actions — kept while the event is unresolved, then deleted 30 days after it reaches a final outcome, together with the decision recorded against it, its answers, its outcome, and any message it was delivered as.
• Which message in a chat is a task's — the board, the task number, the chat, and the chat's own identifier for that message. Kept while the task has any event on Cloud, and deleted with the last of them.
• A board's machine record — the machine identifier and the hostname described above, kept until we remove them by hand. Every machine a board registered keeps its record, including one the board has moved away from.
• Your Slack and Lark connections — kept until you disconnect them, which deletes each one at once, or until we remove your records.
• The API's own request log — retained by Cloudflare under Cloudflare's policy. It carries no board content, no handle, and no email address.
• Email correspondence — kept for as long as needed to handle the conversation and any follow-up, then deleted.

We may keep limited information longer where we need it to comply with a legal obligation, resolve a dispute, or enforce our agreements.

Security

We use reasonable administrative and technical safeguards to protect personal information:

• Encryption — an account's Cloud records are encrypted at rest by our database provider, and every connection to the Service uses TLS 1.2 or later.
• A closed database — the database denies every caller but the service, exposes only the functions the service calls, and its keys are held in the service's secret store and never in our source code.
• Asymmetric sign-in tokens — the service verifies a session against the project's published signing keys, so there is no shared signing secret for anyone to hold or leak.
• A minimal-scope OAuth app — the GitHub app behind sign-in asks for user:email and nothing more, so a compromised session still cannot read a private repository.
• Least privilege — access to production systems is limited to the people who need it.

No system is perfectly secure. If we experience a breach that materially affects you, we will notify you in line with applicable law.

Because this is a free preview running on free infrastructure tiers with no backups, do not treat Cloud as the only copy of anything you cannot lose. Your board is not at risk — it is Markdown in your own repository — but the event history Cloud holds is kept nowhere else.

Your rights and choices

Depending on where you live, you may have the right to:

• Access the personal information we hold about you.
• Correct information that is inaccurate or incomplete.
• Delete personal information.
• Receive a portable copy of your information.
• Object to or restrict certain processing.
• Withdraw consent where we rely on it.
• Lodge a complaint with your data protection authority.

To exercise any of these rights, email [email protected]. We will respond within the time applicable law requires — typically within 30 days, with one extension permitted under the GDPR. We may need to verify your identity before acting on a request. We will not discriminate against you for exercising any of these rights.

Three things you can do without asking us: turn anonymous usage reporting off, which stops it at once and deletes what is queued on your machine; disconnect Slack or Lark, which deletes that connection at once; and turn Cloud off for a board, which stops it sending anything more. A copy, a correction, or a removal of what we already hold is a request to us.

United Kingdom and European Economic Area

If you are in the UK or the EEA, NULLREACH LTD is the controller and you have the rights above under the UK GDPR and the GDPR. You may complain to the UK Information Commissioner's Office (ICO) or to your local supervisory authority in the EEA.

Switzerland

If you are in Switzerland, you have equivalent rights under the Swiss Federal Act on Data Protection (revFADP), and you may complain to the Federal Data Protection and Information Commissioner (FDPIC).

California residents (CCPA / CPRA)

California residents have additional rights, including the right to know what categories of personal information we collect, the right to delete, the right to correct, the right to opt out of the sale or sharing of personal information for cross-context behavioral advertising (we do neither), the right to limit the use of sensitive personal information (we do not collect sensitive personal information), and the right not to be discriminated against for exercising these rights. You may use an authorized agent to make a request.

In the past 12 months, the categories of personal information we have collected, as defined by the CCPA, are:

• Identifiers — a GitHub username and numeric id, a display name, an avatar URL, and an email address where the sign-in returns one; and, for a board on Cloud, the name of the folder that board sits in, the identifier the computer running it generated for itself, and that computer's hostname.
• Internet or network activity — the site's two counts and the app's anonymous usage reporting, neither of which identifies a person; what our subprocessors log to deliver a request; and the API's own request log described above.
• Other information you choose to provide — the part of a card an event carries (its title, its opening paragraph, its review notes, and its questions), the decisions and answers you record against it, and anything you write to us in an email.

We collect no commercial information, no geolocation, no biometric data, and we draw no inferences about you. We share these categories only with the service providers described above.

International data transfers

An account's Cloud records are stored in Frankfurt, Germany, inside the EU. An EU account's records therefore stay in the EU at rest.

Two transfers can still happen, and we would rather name them than leave them implied:

• The API runs on Cloudflare's global network. A request is handled close to where it was made, so an account working outside the EEA has their request processed in that region in transit before it reaches the database in Frankfurt.
• Our subprocessors are US companies. Cloudflare, Supabase, Resend, Spaceship, and GitHub may access data from the United States for support and operations, under their own commitments. Resend sends from the United States, so an answer to an EU address is processed there in transit, and Spaceship processes the [email protected] mailbox in the United States, so a data request you send us and a preview notice we send you pass through there too.

Where personal information is transferred out of the UK, the EEA, or Switzerland, we rely on the European Commission's Standard Contractual Clauses, the UK's International Data Transfer Agreement or Addendum, the EU–US and UK–US Data Privacy Framework where a recipient is certified, or another safeguard recognized under applicable law. Copies of these safeguards are available on request.

Children

The Service is not directed to children under 16, and we do not knowingly collect personal information from them. If you believe a child has given us personal information, contact us and we will delete it.

Changes to this policy

We will update this Policy as the Service evolves. When we do, we will change the effective date at the top of this page.

For a material change we send a notice by hand, from [email protected] to the email address GitHub verified for your account. That is the route: the preview delivers no notice inside the app and none in a connected Slack or Lark chat. A post on ai4kanban.dev may accompany the email, but never stands in for it.

That email reaches Cloud accounts, because a signed-in account is the only address we have. If you have never signed in to Cloud, this page is your notice — we hold no way to reach you — so the effective date at the top is what to check. The one thing the app tells you itself is the usage-reporting disclosure, shown once before your first board opens.

Contact

For privacy questions or requests, email Tao Wu at [email protected]. We try to reply within a few business days.

You can also write to us at:

NULLREACH LTD
Suite 11615, 61 Bridge Street
Kington, United Kingdom, HR5 3DJ