Last updated 18 October 2026
Correction, 15 October 2026. Earlier versions of this page left out kinds of data the software was already storing — among them search history, follows and notifications, screening and review records, share links, webhooks, API keys, in-app feedback, the free-trial card fingerprint and subscriber-offer records — and said profile photos were visible to teammates only, when they are stored at an unlisted public address. This version describes them. For those, the software is doing nothing new; this is a fuller account of processing that was already happening, checked against every table and column that Novasieve’s own database code creates.
New in this version. It also describes five kinds of processing that begin with this update, and were not happening before it: a history of changes to a topic’s extractions and risk-of-bias appraisals; the search query and list of sources, now added to the history of changes to a topic’s definition (earlier changes to those two were not recorded); institutions you save; search history for members who hold one of a team’s paid seats, who now have the text of their keyword searches kept without a Pro subscription of their own; and digest emails to members who hold one of a team’s paid seats, who now receive them without a Pro subscription of their own, so their email address and the digest’s content now go to Mailjet. The first four are described in the table below (the search history in its “Search history” row), and the digest emails in the Mailjet row under “Who else processes your data”.
This page describes what the software actually does with your data. It was written against the source code rather than from a template, so where it makes a claim, that claim is something the system enforces.
Written from the code. Every factual claim on this page was traced to the software before it was written. It has not, however, been reviewed by a lawyer, and whether the company must register as a data controller with the Office of the Data Protection Commissioner is a separate question we have not answered here.
Novasieve is operated by SummitStrive Investments Limited, a private company registered in Kenya under company number PVT-5JUZ59X3. We are the data controller for the personal data described below.
Registered office: HH Towers, Kenyatta Avenue, Nairobi CBD, Starehe District, Nairobi County, Kenya.
Postal address: P.O. Box 13503–00100, G.P.O. Nairobi, Kenya.
For any question about this notice, or to exercise a right under the Data Protection Act, write to privacy@novasieve-lit.org.
| Data | Why | When it is collected |
|---|---|---|
| Email address and password | To create and secure your account, and to send the confirmation and password-reset messages. | When you sign up. Passwords are stored only as a hash by our authentication provider — we never see or store the password itself. |
| Saved topics — your query text, chosen sources, cadence, filters and delivery settings (including the hour digests are sent), and any review protocol you attach to a topic: a PICO question, screening rules, an extraction form and a PRISMA checklist | This is the product: it is what gets watched on your behalf. | When you create or edit a topic. Each check also leaves a short log against the topic — when it ran, how long it took, how many new papers it found and whether it failed — which is removed daily once it is more than 30 days old. Where the service computes one, a numerical representation of the topic’s search terms is kept with it, for ranking. |
| Papers surfaced for you, including papers you import from a reference file, and which ones you have already seen | So a check can show only what is new, and the same paper does not resurface. | Each time a check runs, or when you import. If you receive email digests, we also record when each digest was emailed. |
| Your decisions on papers — saved, dismissed, set aside to screen later, and any exclusion reason you type — and a history of those decisions: each one, what it replaced, and when | To keep your library and screening state, and to power the optional “prioritise by what I save” re-ranking, which is computed in your browser. The history lets a review show how its screening changed; entries in it cannot be edited or deleted one by one. | When you act on a paper. On a team topic with dual review switched on, a teammate adjudicating that topic — one who has not screened it themselves — can read your decisions and reasons on it. |
| Review records on a topic — data you extract from papers, risk-of-bias judgements and notes, a history of changes to the topic’s PICO question, screening rules, extraction form, PRISMA checklist, search query and list of sources (the old and new values, who made each change, and when), and a history of changes to the extractions and risk-of-bias appraisals recorded on it (the old and new values, who made each change, and when) | To run a systematic review, and to show how its definition changed over time. | When you fill them in, or when the topic’s protocol is edited. |
| Your library — papers you add (a copy of their bibliographic details), their reading status, your tags and folders, the topic each came from, and any extraction data you record against them | To keep your reading library and its notes in one place. | When you add or organise papers. |
| Search history (Pro) — the text of the keyword searches you run across your own papers, and whether abstracts were included | So your recent searches can be offered again. | Each time a Pro account runs one. The 50 most recent are kept and older ones are removed daily; you can remove any entry yourself. |
| Follows and notifications — papers you follow (DOI, title and the citation count last seen), researchers you follow (their OpenAlex id, name and the date you started), institutions you save (OpenAlex id, name and country — a bookmark only; nothing watches them), the notifications these, your saved papers and your teams generate, whether you have read each one and whether it was emailed, and your notification settings | To tell you when something you follow changes — new citations, a new paper, peer-reviewed publication, a retraction or correction — and about team activity. | When you follow or save something, and when a check finds a change. Notifications are shown in the app. Email for them is off unless it is turned on, and goes only to Pro accounts (your own subscription or a paid seat on a team); where both hold, they are sent to your email address and we record when each one was emailed. There is currently no setting in the app to turn it on. |
| Full-text requests — the papers you are tracking a request for (DOI and title), the status you set (wanted, requested, received or abandoned), and when you marked one requested | To keep track of manuscripts you have asked authors for. | When you use the request tracker on a paper. |
| Profile — display name, avatar image, ORCID iD, institution, and your library’s link-resolver address | So colleagues in a shared team can tell who wrote a comment, and so paywalled papers can offer a route in through your library. All are optional. | Only if you fill them in. Visible only to accepted teammates — except the photo, which is stored at a public but unlisted web address: there is no list of photos to browse, but anyone who has that exact address can open it. Replacing or removing your photo deletes the old image, and its address stops working once the image is gone. If the old image cannot be deleted, you are told so when you make the change, with a way to try again. |
| Teams — team name and field, members and their roles, pending invitations, topics shared with the team or one of its subgroups, comments, papers proposed to the team (with any note and suggested action) and the decision on them, subgroups (name, description, research area, access, members and their roles, whether each member has muted it, which anyone who can see the subgroup can also see, join requests, and who is assigned to cover it), when you last read each subgroup’s discussion, and the team’s activity list of members joining, comments posted and recommendations approved | To run shared workspaces. | If you create or join a team. |
| Public share links — a random token for each topic or paper you choose to share, an optional expiry date, and whether you have revoked it | So someone without an account can see what you shared. | When you create a link. Anyone who has the link can see what it points to: a shared topic’s search terms and its latest papers (also offered as a feed), or a single paper. No profile data is shown. |
| Subscription status and the identifiers our payment processor issues for you — plan, status, when the current period ends, whether a payment is overdue, and when you first started a free trial. For a team plan, the same for the team plus its seat count. If we grant a paid plan by hand, a short internal note saying why. | To know whether your account is on the paid tier, and to give each person one free trial. | If you subscribe. We never receive or store your card number or other card details — see “What we never store” below. |
| Free-trial card fingerprint — an opaque token that our payment processor, Stripe, derives from the card used to start a free trial. It is not the card number. | So each card gets one free trial. The fingerprint is compared with the fingerprints stored for other accounts; if the same card has already had a free trial under another account, we tell Stripe to end the new trial immediately, so normal billing starts. The subscription itself is not cancelled. | During a free trial, once Stripe can tell us which card was used. Kept after your subscription ends, because the question it answers outlives the subscription; deleted when you delete your account. |
| Subscriber offer records — if you are sent the one-time launch offer for subscribers: a hash of your single-use claim link (never the link itself), when it was issued, when it expires, whether and when you claimed it, the discount coupon applied, and when the credit was applied and the offer email sent | So the offer can be applied once, and only once. | Only if the offer is sent to you. |
| Connected-service credentials — your Zotero API key, library id and type, and the collection you choose; and a record of which papers (by DOI) you have sent to which Zotero library, with Zotero’s id for each | To send papers to your Zotero library on your instruction, without filing the same paper twice. | Only if you connect Zotero. The key is stored so it can be replayed to Zotero; you can disconnect at any time. |
| Webhooks — the https address you give, its signing secret (stored as is, because every delivery has to be signed with it), your label and payload format, and delivery state: whether it is active, recent failures, the last status code and error, when it last delivered and was last tested, and which digests have been sent to it | To send new papers from your topics to a system you run. | Only if you add a webhook. The new papers each check finds, with the topic’s search terms, are sent to that address. |
| API keys — a hash of each key (never the key itself, which is shown to you once), its first few characters so you can recognise it, your label, and when it was created, last used, expires or was revoked | So your own scripts can read your data through the API. | Only if you create a key. |
| In-app feedback — the star rating, any comment you type, and which screen asked | To learn what to improve. It is read only by us. | Only if you answer the occasional feedback prompt. |
| Rate-limiting counters — that a discipline search or API request happened, and when; for an API request, also which of your keys made it, which kind of data it asked for, and the response status | To enforce free-tier limits and stop abuse. | On those actions. No query text is recorded in these counters, and no request bodies or URLs are logged. (Search history, above, is separate.) |
What is deliberately absent. There is no table anywhere in the system that records that you viewed, opened, clicked or downloaded a paper, and no session or dwell-time tracking. (The app does record when you read a notification or a team discussion, so it can show what is unread.) Not because it was overlooked — because a product that promises not to sell reading behaviour should not be collecting the raw material for it. The consequence is that we could not build an advertising or “intent data” product on this even if we wanted to.
The relevance ranking Novasieve applies to a search or a check is the same for every reader. There is no profile of you steering it, and nothing is reordered because of who you are.
There is one exception, and it is opt-in: a setting called prioritise by what I save. When you turn it on, a small statistical model is trained in your browser from the papers you have already saved and dismissed, and it re-orders your own feed to put likely matches nearer the top.
We mention this rather than claiming a blanket “no personalisation”, because the honest statement is more useful than the simpler one.
Novasieve sets no cookies and uses no analytics or advertising scripts. Your browser’s local storage holds two kinds of thing, both on your device only:
Clearing your browser storage removes all of it and signs you out.
We use a small number of providers to run the service. Each acts on our instructions and receives only what its job requires.
| Provider | What it does | What it receives |
|---|---|---|
| Supabase | Database, authentication and server functions | Everything in the table above. This is where your account lives. |
| Cloudflare | Serves the website | Standard web-request data, including your IP address, as any web host receives. |
| Stripe | Payments, if you subscribe | Your email address and your Novasieve account id (or your team’s id, for a team plan), so a payment can be matched to the account, and the payment details you enter on Stripe’s own checkout page. Stripe returns us your subscription status, its own identifiers and, during a free trial, the card fingerprint described above. |
| Mailjet (Sinch) | Sends account email (confirmation, password reset); digest emails, which go only to Pro accounts (your own subscription or a paid seat on a team) and are sent for every such topic (there is currently no setting to turn them off); notification emails, where email for them is turned on, and only to Pro accounts; and the one-time subscriber offer email, if one is sent to you | Your email address and the message content. |
| ImprovMX (ImprovMX Incorporated, Delaware, USA) | Receives mail sent to our published addresses and forwards it to us | Anything you put in a message to privacy@novasieve-lit.org or support@novasieve-lit.org — including your own address and the content of what you write. It forwards; it does not store a mailbox for us. |
When a check runs, we query open scholarly databases using your topic’s search terms — or, for papers and researchers you follow, their public identifiers. Those requests carry no identifier for you — not your account id, not your email, not your IP — because the request is made by our server rather than by your browser.
We query OpenAlex, Crossref, Semantic Scholar, DOAJ, CORE, OpenAIRE, J-STAGE, Europe PMC, PubMed and arXiv directly. bioRxiv and medRxiv are reached through Europe PMC rather than contacted directly, so no request of ours reaches those two services. The sources also differ in what they cover and are not interchangeable; the picker in the app states each one’s scope.
Some of these databases ask API users to include a contact address so they can reach the operator about traffic. Where we do that, the address sent is ours, not yours.
Our database and server functions run in Supabase’s ap-northeast-1 region (Tokyo). Our providers are international — Supabase and Cloudflare operate globally, Stripe processes payments outside Kenya, and mail sent to our published addresses is forwarded by ImprovMX, a United States company — so data may be processed in other countries under the transfer safeguards in their own terms. If you need the specific mechanism for a compliance review, ask and we will point you at the current one.
Account deletion is self-service, in the app, under your account settings. You confirm by typing your own email address, because it cannot be undone. When you delete:
Shared team records you contributed to stay with the team. These include subgroups you created, decisions you made on teammates’ recommendations and on requests to join a subgroup, and entries in the team’s activity list.
Novasieve is operated from Kenya, and the Data Protection Act, 2019 applies to how we handle your data. It gives you the right to be informed of how your data is used, to access a copy of it, to correct it, to have it deleted, and to object to or restrict its processing. If you are in a region with its own data-protection law — the UK or the EU, for instance — you may hold equivalent or additional rights there. In practice:
If you are not satisfied with how we have handled a request, you may complain to Kenya’s Office of the Data Protection Commissioner. If you are in another country with its own data-protection authority, you may complain to that authority instead.
Novasieve is a tool for research work and is not directed at children. Do not create an account if you are under the minimum age in your country for consenting to online services.
Access to your rows is enforced in the database itself, not merely in the interface: every table carries row-level security, so a request for someone else’s data is refused by the database rather than filtered out by the app. Server-side secrets exist only in server functions and are never present in the code your browser downloads. Uploaded avatars are re-encoded before storage, which strips embedded metadata such as the GPS coordinates a phone camera may attach.
No system is perfectly secure, and we do not claim certification against any standard.
If this notice changes materially, we will update the date at the top and, where the change affects how your data is used, tell account holders by email.