Privacy policy

Bloombot ("the service") is operated by Bloombot ("we", "us"). It answers students' course questions on Discord and on the web, and gives instructors a panel for the courses behind that. This policy explains what personal data the service handles, who sees it, and — just as importantly — what it does not yet let you do about it.

What we record

Instructor accounts. Your email address and display name. Signing in is by a link emailed to you, or with Google — in which case Google tells us your email address, name and profile picture. We never see a password, because the service has none.

Student identities. A student reaches the service through Discord or through an emailed invitation, and we record what is needed to recognise them again: a Discord account id and username, an email address where one was supplied, and the courses they belong to. Instructors import rosters, so some of this arrives from your institution rather than from the student.

Conversations. Every question a student asks and every answer the service gives is stored, in full, and kept. That includes messages sent in Discord and messages sent through the web chat, along with which course and which channel they belong to, and when they were sent. This is the heart of what the service holds, and it is the part worth reading twice: these are students' own words, kept indefinitely.

Course material. Instructions, prompts and files instructors attach to a course, which the service uses to answer questions.

Usage and cost. Token counts and a computed cost for each model call, so that spending caps can be applied and an instructor can see what a course is costing.

Technical records. Ordinary server logs — request paths, timestamps, error traces — and an access log described below.

Who can see a conversation

An instructor can read their own students' conversations in full. The control panel has a transcripts screen for exactly this, with filtering by student and by date, and an export. If you are a student using this service, assume your instructor can read everything you asked it.

Two things are true of a transcript read through the control panel, and both are real:

• Every transcript read and export is written to an access log — who looked, at whose transcript, and when.
• That access log is itself readable only by an organization's owner, not by every instructor in it.

Both describe reads made through the panel. Neither constrains anyone holding the server or the database itself, as the next section explains.

Platform administrators — a short, named list configured by the operator — can reach an administration console covering the whole platform. It shows the organizations on it; the projects and courses inside them, including each course's settings, instructions and the material attached to it; and the people on the platform — instructors and students alike — with their names, email addresses, the courses they belong to, the Discord or web accounts they have been recognised by, and what each has cost to serve. Running the service means knowing who is on it, what it is doing and what it is spending, and that console is where an operator reads it.

That console is part of actively developed software, and what it covers changes as the platform does.

Behind it, the people who build and run the service hold the server it runs on and the database file that stores everything described on this page. That access is what makes it possible to deploy a change, restore a backup, or work out why something broke — and it reaches every record the service keeps, students' conversations included. No part of the software limits it, and this policy makes no promise of privacy from the people who operate the service, for any data it holds. What a console screen happens to show changes what is convenient to look at; it does not change what is reachable.

The practical assumption for anyone using this service is the one this page has already asked a student to make: what you type here is stored, and the people responsible for the service can read it.

AI processing

Answering a question means sending text to a model provider (OpenAI, in the deployment this platform ships for). What is sent is the question itself, the course's own instructions and attached material, and enough of the conversation for the answer to make sense.

A student's question is their own words, and it is sent as written. We do not strip names or other identifying details from it beforehand, because we cannot reliably tell what inside a question is identifying. Anything a student types is liable to reach the model provider, and their terms — not ours — govern what they do with it in transit.

Sharing

We do not sell this data, and we do not use it for advertising or behavioural profiling. It leaves the service in exactly three directions: to the model provider as described above, to Discord (because that is where the conversation is happening), and to the mail relay that carries this service's own email — sign-in links, and operational notices to the operator such as telling them a new course is waiting to be approved.

Google account data

If you sign in with Google, this is the complete account of what that gives us and what we do with it.

What we receive. Signing in with Google hands us your email address, your name and your profile picture — nothing more. We never receive a password, because Google's sign-in flow does not send us one; there is no password of yours for this service to hold or to lose.

What we use it for. Only to create your instructor account the first time you sign in, and to recognise you and sign you back in on every visit after that. It plays no other role anywhere in the service.

What we do not do with it. Your Google account data is not sold, and it is not shared with any third party beyond what the Sharing section above already names. It is not used for advertising or profiling, and it is never a factor in a credit decision. It is never sent to the model provider, and it is never used to train any AI or machine-learning model, generalized or otherwise — the "AI processing" section above describes exactly what does reach the model provider (a question, a course's own material, and the conversation around it), and your Google account data is not part of that and never has been.

Retention and deletion. Like every other account record, your Google account data is kept for as long as the service runs, under the same "How long we keep it" rule below. There is no button that deletes only your account or only its Google-derived data — but there is one concrete, manual path an operator can take on request: write to privacy@wonkledge.com and ask for your whole organization to be deleted. That is the same tenant-level deletion this policy describes below as the platform's only real deletion capability, not a finer-grained one invented for this section — and it removes your Google account data along with everything else in the organization, at the cost of removing everything else in the organization too.

How long we keep it, and how it is deleted

We keep what you give us until it is deleted. Nothing expires on its own: a conversation, an account or a course stays until somebody deletes it, or until the service stops running. What changed is that deleting is now something you can actually do.

What can be deleted, and by whom. A person can delete their own conversation history in a course, from that course's chat screen. An account holder can delete their own account. An organization's owner can delete the organization, a project or a course. A platform administrator can delete any of these. Each is offered in a "Danger zone" on that thing's own screen, and each asks you to confirm before anything happens.

What deleting does, and when it becomes permanent. Deleting removes the thing from the service immediately: it disappears from every screen, answers nothing, and is not readable by anyone — instructors and operators included. For a short window it is recoverable, so that a mis-click is not a catastrophe; that window is 30 days. After it passes, a scheduled process permanently erases the records and the files behind them, including the copies held by the AI provider, and they cannot be recovered by us or by anyone else. Deleting a thing deletes what belongs to it: deleting a course deletes its conversations, its attached material and its knowledge files.

One limit is worth stating rather than leaving you to discover it. Where a person has ever asked the service a question, the record naming them — their name, and the Discord or email address they were recognised by — is tied to the usage and cost record that question created, which is one of the event records described below. Their conversations and messages are erased on the schedule above; that naming record is not, and stays until we can remove it without destroying the accounting it is attached to. We would rather say so than let "deleted" mean two different things on one page.

What survives a deletion, and why. A few records are accounts of events rather than content, and those are kept: that a tenant's data was deleted, that a course was deleted, that a transcript was read, that an instructor acknowledged what a roster upload means, and the totals in the usage and cost ledger. They name what happened and when. They are kept precisely because a record of an action cannot be erasable by the person who took it.

Asking us to delete something. If what you need deleted is not something the screens let you delete yourself, write to privacy@wonkledge.com and say what it is. We will do it or tell you plainly why we cannot. Depending on where you live you may have statutory rights of access, correction, portability or erasure; those rights are not diminished by anything on this page, and this paragraph is not a substitute for them.

If any of this is unacceptable for your course, the right time to decide that is before students start using the service. Nothing on this page, and nothing in the Terms & conditions, is a consent given on behalf of a student under FERPA — that consent can only be given by the student, in writing, to their own institution. Whether this service is appropriate for your students' records is your institution's decision to make; the terms say what we do and do not represent about it.

Security

Every connection to the service, including sign-in and every request the Google sign-in flow makes, is encrypted in transit (HTTPS/TLS) — the operator terminates TLS in front of the service, and a plain HTTP request is redirected to HTTPS rather than answered directly. Sign-in links are single-use bearer credentials, stored hashed and short-lived. Session cookies are signed. Credentials the service needs live in server-side configuration and are never sent to a browser. Every request that reads or changes something checks that the account making it is allowed to.

These measures guard the service against people outside it. They are not, and are not offered as, protection against the people who run it — see "Who can see a conversation" above.

The service runs on a single server with a single database file, encrypted at rest to the extent the underlying server disk is. Backups are the operator's responsibility and their existence is a deployment choice, not a guarantee this policy makes.

No system is perfectly secure, and we do not claim otherwise. This is an actively developed platform, not a mature product.

Children

The service is built for higher education and is not directed at children. We do not knowingly create accounts for anyone under 16.

Changes

We will update this page as the service changes, and the date above says when it last changed. As the platform grows the deletion and retention behaviour described here is expected to improve; this page will be updated when it does, rather than in advance of it.

Contact

Bloombot privacy@wonkledge.com