This policy explains what personal data seRevel, Inc. ("Serevel", "we", "us") handles when you use serevel.ai, our product at app.serevel.ai and {workspace}.serevel.ai, and the prospect evaluation sites we host for our customers.

It is written to be accurate rather than reassuring: where our systems do something a reader might not expect, we say so. If any other page on serevel.ai contradicts this policy, this policy is the one to rely on.

Contact for anything in this policy: privacy@serevel.ai

If a vendor invited you into an evaluation site, read this first

You are on a site like something.serevel.ai because a company that wants to sell your employer a product invited you to try it. This policy calls you a prospect. We know that is a seller's word; we use it because the product uses it. You did not sign up for Serevel and you have no contract with us.

Five things to know, each expanded later:

The vendor decides what happens to your evaluation data, not us. We hold it for them. For a narrow set of things — our server logs, our anti-abuse counters, the record that you were shown our Terms and continued — we are responsible directly (section 1).
Nothing you do on an evaluation site is anonymous to the vendor. Sign-ins, which use cases you opened, what you downloaded, your ratings and every word of your feedback are attached to your email address (section 2.4).
Your messages to your sales engineer may be processed by an AI model, sometimes automatically the moment you post them, and in some configurations by a third party in the United States (section 10.5).
Deletion is handled by hand. There is no self-service button that removes one participant — ask us or the vendor and we will do it (sections 7 and 9).
Write to privacy@serevel.ai with the web address you used and we will tell you which vendor invited you and what we hold.

1. Who we are, and which hat we are wearing

Serevel is a business tool. Vendor sales-engineering teams ("customers") use it to run structured product evaluations with the companies they are selling to ("prospects"). That creates two very different relationships, and your rights depend on which one you are in.

Who we are. seRevel, Inc. is a corporation incorporated in the State of Delaware, United States. Our registered address is 131 Continental Drive, Suite 305, Newark, Delaware 19713, USA. We have not designated a data protection officer; privacy questions go to privacy@serevel.ai, and we answer them.

We are the controller — we decide what is collected and why — for:

accounts and sign-in for our customers' staff;
signup requests submitted on serevel.ai;
billing contacts for paying customers;
visitors to the serevel.ai website;
product-usage telemetry from the employee portal;
bug reports and product ideas submitted inside the product;
our own security and operations logs, our anti-abuse counters, and the record that a person was shown our Terms and continued — including for prospects.

We are a processor — we act on our customer's instructions and hold their data for them — for everything our customers put into the product about their prospects: prospect contact details and accounts, evaluation content, plans, sign-offs, prospect↔engineer conversations, feedback, uploaded documents, and any material synced in from the customer's own Confluence or Slack.

Two honest qualifications to that second role. First, we do not yet have a data processing agreement, a documented sub-processor programme, or an API that lets a customer instruct us to export or erase a specific person's data — deletion and export are manual today (section 9). Second, three things we do with customer content are our decision and not the customer's instruction, and we set them out rather than bury them: our choice of AI backend in section 10.3, and the cross-workspace visibility of the Ideas & bugs board in section 5.

If you are a prospect — invited into an evaluation site by a vendor, or someone who entered an email address on such a site and asked for access, whether or not it was granted — then the vendor is the controller of the evaluation and everything in it: your account, your messages, your feedback, your sign-offs, your progress. For the narrow set of things listed above that we decide ourselves, we are the controller even for prospects, and you can raise those with us directly. Section 9 explains how.

One further caveat: for the accounts of our customers' own staff, both roles are arguably in play. Your employer decides who gets an account and what is in it; we decide how authentication, security logging and our own product analytics work. If you are a customer's employee and want to exercise a right, contacting either your workspace administrator or us will work — we will tell you which of us can actually do the thing you asked for.

2. What we process

2.1 Customer staff (employees of our customers)

Account record: email address, display name, role, region, products, an optional meeting/booking link you set yourself, a password hash (Argon2id), whether the account is disabled, last sign-in time, and interface preferences.
Single sign-on: if your employer enables SSO, we store the identifier your identity provider gives us (sub), plus the email address and display name from the sign-in token.
Sessions: a server-side session record (an opaque id, the account it belongs to, and an expiry). We do not store your IP address or user agent in session records.
Password reset, invite and sign-in handoff tokens: stored only as SHA-256 hashes.
Invitations and join requests: email address, role, status, and the IP address the request came from.
API keys: if you create one, we store its prefix and a keyed hash, never the key itself — it is shown to you once. Keys authenticate as you, and disabling an account revokes them.
Product usage telemetry: see section 8.
Bug reports and product ideas you submit in the product: the kind, title, body, the page you were on, and — only if you tick the boxes — your name and company. See section 5 for two limits on those boxes.

2.2 People who sign up on serevel.ai

Company name, chosen workspace name, the admin email address, a password hash, the plan requested, the version of the Terms accepted, and the IP address the signup came from. The password hash is deleted as soon as the request is approved or rejected. The rest of the record is kept (see section 7). Every signup is also screened by an AI model before a person decides on it — see section 3 and section 10.2.

2.3 Billing contacts

For paying workspaces: the email address of the administrator who starts checkout, the company name, and identifiers linking the workspace to Stripe. Stripe collects the payment card, billing address and any tax id on its own hosted page — card details never reach our systems. We store the full raw event objects Stripe sends us, which for some events include the payer's name, email and billing address.

2.4 Prospects (our customers' customers)

Account: email address, a role you type in yourself on first sign-in, the evaluation you belong to, last sign-in, and the fact that the sign-in page showed you our Terms and you continued — recorded each time you sign in. Your account itself has no name field and no password: you sign in with a code we email you. Your name is commonly stored elsewhere in the same evaluation (see the contact directory and sign-off entries below).
Login codes: a six-digit code we email you, stored only as a one-way hash — nobody, including us, can read a live code out of the database. It works once and stops working after 10 minutes. If you cannot receive the e-mail, staff at the vendor who own or manage your evaluation can send you a fresh code; that action is recorded and never reveals the existing one. The stored record is removed when a new code is requested for your address, or when the evaluation is deleted.
Sessions and, optionally, passkeys (a credential id, public key and usage counter — no biometric data ever leaves your device).
Access requests: if you enter an email address from a domain the vendor has not allow-listed, your email address and its domain are stored so the vendor can approve or refuse you. The record is kept whether they approve or refuse, and it is removed only when the whole evaluation is deleted. If you asked for access and were refused, or asked by mistake, write to privacy@serevel.ai with the web address you used and we will identify the vendor and pass on a deletion request.
What you do in the evaluation: which use cases you viewed or completed, ratings, free-text feedback, use cases you suggest, extension and re-open requests, colleagues you invite (their email addresses), and an activity log of your logins, views, downloads and messages. To be plain about what that means: nothing you do on an evaluation site is anonymous to the vendor. Their team can see a timeline of when you signed in, which use cases you opened and completed, what you downloaded, how you rated things, and every word of feedback you wrote — all attached to your email address. We keep no record of which of their staff looked at it.
Conversations with your sales engineer: the full message text, kept indefinitely, with no edit or delete function on either side.
Research derived from your messages: when you post a message, we store a shortened copy of it together with search terms derived from it and links to matching internal material, so your sales engineer can answer you. This record is for the vendor's side only and is never shown to you. Where the vendor has connected an issue tracker, the derived search terms may be sent to it as a search query. An AI model may also be used to expand those terms (section 10.5).
Plan sign-offs: your first name, last name, email address, role, any comment you write, and any purchase-intent statement. We do not capture an IP address or user agent with a sign-off.
Contact directory: names, roles, phone numbers and email addresses that the vendor records for both sides of the evaluation — including for people who never log in.
Meeting bookings (not yet live — see section 12): your email address, name, chosen time and the agenda note you type.

2.5 Content our customers write about prospects

Customers write discovery notes, problem statements, MEDDIC entries, named decision makers and economic buyers, demo scripts, plans and win/loss commentary. This is free text about identifiable people at the prospect company. We hold it; we do not curate it.

2.6 Material synced from a customer's own tools

If a customer connects Confluence or Slack, we copy page bodies and message threads into our database to ground the AI features. Slack threads are stored with the author's display name inline in the text (never Slack email addresses). Whatever personal data those pages and messages contain is copied with them. We also keep a record of each sync run: who triggered it, when, how many items were read or written, and any errors.

2.7 Technical and security data

Application logs. Every HTTP request is logged with the client IP address, the full request URL (which includes the workspace subdomain and evaluation identifiers), the response status and timing. Some application log lines also carry a user id or an email address (for example, a refused break-glass attempt). There is no redaction configured.
Rate-limit counters held only in server memory, keyed on IP addresses and email addresses. They are never written to disk, are not shared between servers, and are lost on restart.
Anti-abuse checks: where the challenge is configured, your IP address is sent to Cloudflare Turnstile when you submit the signup form.

2.8 Notifications and queued events

In-product notifications and the queue we use to deliver them. The message text and the queued event can contain a prospect's email address, a use-case title or a quoted piece of feedback; one security event (an emergency SSO recovery) carries an administrator's email address and IP address. Queued event records are not linked to an evaluation, so deleting the evaluation does not remove them (section 7).

2.9 Files

Logos, hero images, product images, custom fonts and use-case attachments uploaded by customer staff. These are stored on our application server's disk. Prospects cannot upload files.

2.10 Evaluation-environment telemetry

If a customer uses the enterprise feature that stands up evaluation infrastructure in their own cloud, an agent they install there reports back to us: their cloud account identifier, region, agent version, deployment events, stack outputs and log text. Log text is free-form and can contain whatever the customer's systems write into it.

2.11 AI job records

For each AI request we keep a record of the job type, who started it, which evaluation it belonged to, timestamps, which model answered and any error. The content submitted and the model's output are erased on the schedule in section 7; this metadata record is kept.

2.12 Where we got your data, if you never gave it to us

Some of the personal data in the product was not given to us by the person it is about. If you appear in Serevel as a contact on an evaluation, as a named decision maker or economic buyer in a vendor's discovery notes, as a colleague someone invited, or because you are named in a Confluence page or Slack message a customer synced into their workspace, the source is our customer — the vendor running the evaluation — or their own tools, not you. The categories held about you are the ones listed in sections 2.4, 2.5 and 2.6. Because the vendor is the controller of that data, they, not we, are responsible for telling you it exists; you can also write to privacy@serevel.ai and we will tell you what we hold and put you in touch with them.

3. Why we process it, and our legal basis

Where the GDPR or UK GDPR applies, these are the bases we rely on for the processing we decide ourselves. For the evaluation data our customers put into the product about their prospects we act on their instructions, so the basis is theirs to choose and to tell you about, not ours — the row below marked that way is there so you know where to ask, not because we claim a basis for it.

What	Why	Basis
Accounts, sign-in, sessions, password reset, invites, API keys	To provide the service the customer contracted for	Contract; legitimate interests (for staff who are not themselves our contracting party)
Prospect accounts, login codes, evaluation content, conversations	To run the evaluation the vendor set up	The vendor chooses the basis and must tell you what it is — typically their legitimate interest in running a sales evaluation. Ask the vendor; if you do not know who they are, ask us and we will tell you
Prospect IP addresses in our logs, our anti-abuse counters, sign-in enumeration defences, your Terms-acceptance record	Keeping the service available, stopping brute force and flooding, and recording that our Terms were shown to you	Our own legitimate interests in security, and our own agreement with you for the Terms record
Billing contact and subscription data	To take payment and manage the subscription	Contract; legal obligation (tax and accounting records)
Signup requests, including IP address and AI screening	To provision workspaces and to screen applications for abuse and eligibility before a person approves	Steps prior to a contract; legitimate interests (abuse prevention)
IP addresses in logs, rate limiting, Turnstile, invite/join records	To keep the service up and to stop brute force, flooding and automated abuse	Legitimate interests (security)
Product telemetry from the employee portal	Understanding which parts of the portal are actually used so we can prioritise engineering work on a small team	Legitimate interests. We have assessed this against the interests of the people it is about — our customers' employees, who did not choose it and cannot switch it off themselves — and narrowed the collection accordingly (pseudonymous identifier, route templates instead of real URLs, an allow-list that drops anything unnamed, no session recording). You can ask for a summary of that assessment, and you can object, at privacy@serevel.ai. See section 8
Website analytics on serevel.ai	Audience measurement	Legitimate interests. In the EEA and UK, cookie-based analytics normally requires consent, which we do not currently collect — see section 11
AI features	To generate drafts, handouts and suggestions inside the product	Performance of the contract with the customer; the customer decides whether AI is on

We do not sell personal data, and we do not use it for advertising or for any purpose unrelated to running this product.

Is providing this data required?

For customer staff, an account record (an email address and a credential) is necessary for us to provide the service your employer contracted for — without it we cannot give you access. For prospects, an email address is necessary to sign in to an evaluation site; there is no other way in, and if you do not provide one you cannot take part in the evaluation. For signups, a company name, an admin email address and a password are necessary to create a workspace, and we capture the IP address of the request for abuse control; without these we cannot provision a workspace. None of this is required by statute. Everything else described in this policy — a display name, a meeting link, a phone number in a contact directory, a free-text comment — is optional, and not providing it only means the corresponding feature is less useful.

What you have to give us

What we have to ask for is small, and it is contractual rather than statutory — no law compels you to give it to us, but we cannot provide the service without it. To create a workspace we need an email address, a password and a workspace name (a company name too, unless we can derive one from your email domain). To take part in an evaluation you have been invited to, we need only your email address — that is how the sign-in code reaches you. Everything beyond that is optional: a display name, a role, a meeting link, a photo, a company name on a bug report. Leaving those blank costs you nothing but a little polish in the interface.

Automated screening of signups, and automated decision-making

When you submit the signup form, an AI model is given your company name, the workspace name you chose, the domain part of your email address (never the full address), the plan you asked for, and the public homepage at that domain, and returns an advisory verdict on whether the application needs a closer look, together with the evidence it relied on. That verdict is shown to a person, who approves or rejects the request. No signup is approved or rejected automatically, and we make no decision about you that is based solely on automated processing and that produces legal effects or similarly significantly affects you. If your signup is rejected and you want to know why, write to privacy@serevel.ai and a person will answer.

4. Who we share it with

Recipients used in our current production configuration

Some recipients below are switched on by configuration rather than by code. We check which are actually running before each publication of this policy and remove any that are not; the list is current as at the date at the top.

Recipient	What they get	Why
Our hosting provider (STRATO)	Everything: the application, the database, uploaded files, logs and configuration all sit on rented server infrastructure.	Production hosting
Cloudflare	DNS for serevel.ai; TLS and edge proxying for our hosts; hosting of the marketing site; the signup anti-bot check (including your IP address); and a first-party path that forwards portal analytics to PostHog.	Infrastructure, bot protection
Let's Encrypt	Certificate requests only. No personal data.	TLS certificates
Google (Google Analytics 4)	Visits to the serevel.ai marketing site: page URL, referrer, device and browser, approximate location from your IP address, and a persistent visitor id in cookies.	Website analytics
PostHog (US)	Employee-portal telemetry: a pseudonymous id of the form `workspace:user-id`, role and plan, the workspace's real company name, page templates, PostHog's own device and session properties, and the viewer's IP address. No email addresses, no names, no real URLs. See section 8.	Product analytics
An AI model backend	See section 10. Either a model server we run on our own hardware, or Anthropic. Used for every workspace unless its administrator has turned AI off.	AI features
ProductBoard (our own workspace)	Product ideas and bug reports submitted in the product: kind, title, body, and your company name only if you ticked that box. Never your email address.	Our product backlog
STRATO (email)	The recipient's address and a plain-text message: prospect login codes, password-reset links, invite links, notification emails. Sent from our own mail domain through our hosting provider's mail service.	Sending email
Operational alerting (ntfy, backup dead-man ping)	Service-health messages. These name no individual, but subscription alerts do carry a workspace name, its plan, its payment status and a Stripe invoice reference. Nothing a prospect or a customer's employee writes in the product is ever sent here.	Knowing when something breaks

Only if the customer chooses it

Recipient	What they get	Why
Stripe	The billing administrator's email address, the company name, workspace identifiers; and, on Stripe's own pages, the payment card, billing address and tax id.	Only for workspaces that subscribe to a paid plan
Atlassian Jira	Evaluation requests pushed as issues: title, description, impact, the evaluation name, the prospect company name, product and dates. Status and assignee names come back. Search terms derived from a prospect's message may also be sent as a search query.	Customer-configured connector
Atlassian Confluence	Nothing is sent. We read page content into our database.	Customer-configured connector
Slack	Read: selected public channel threads and member display names. Written: alert messages that can contain a prospect's email address, use-case titles and quoted feedback.	Customer-configured connector
Microsoft Teams	Alert messages only, same content as Slack. Nothing is read back.	Customer-configured connector
ProductBoard / Aha! (the customer's own)	Evaluation requests, same field set as Jira.	Customer-configured connector
Salesforce, Gong, Zendesk	Today: nothing but a connection test. Storing these credentials does not currently pull opportunities, call recordings or create tickets, whatever the connector description suggests.	Customer-configured connector
Any HTTPS endpoint the customer configures (webhooks)	Signed event payloads that can include prospect email addresses, message and feedback snippets, and — for one security event — an administrator's email address and IP address.	Customer-configured connector
Google or Microsoft (calendar)	See section 12. Not live yet.	Team plan, plus per-person opt-in
The customer's own cloud account (evaluation environment agent)	Direction is reversed: an agent the customer installs in their own cloud polls us outbound. We hold no cloud credentials and open no inbound connection. What comes back to us is deployment telemetry, stack events and log text.	Enterprise feature

We do not currently have a data processing agreement or a documented sub-processor programme with any of the recipients listed above, and we do not maintain a separate sub-processor page or a mechanism for notifying customers when this list changes. The list in this section is, today, the sub-processor disclosure. If your organisation requires a signed DPA, a change-notice commitment, or an audit right before personal data enters the product, contact privacy@serevel.ai and we will tell you plainly what we can and cannot sign.

5. The Ideas & bugs board is shared

The in-product Ideas & bugs board is readable across workspaces. The title and body of anything posted there can be read by users of other customers' workspaces. Only your name and company are opt-in. Do not paste confidential customer detail into it.

6. International transfers

We are a US company.

Our application and database run on a single rented server operated by the hosting provider STRATO. We do not make a data-residency commitment: we do not offer a choice of region, and we may move the server. If where your data sits matters to your organisation, ask us at privacy@serevel.ai before personal data is loaded into the product and we will tell you where it is today.
Cloudflare, Google, PostHog, Stripe and Anthropic are US companies, and data reaching them is processed in the United States or on global infrastructure.
AI inference either stays on hardware we operate ourselves, or goes to Anthropic in the United States — see section 10.
Where a customer configures a connector, data goes wherever that customer's own system is.

We do not currently have standard contractual clauses, transfer impact assessments, or any other Article 46 transfer safeguard in place with the recipients listed above, and we do not rely on an adequacy decision. Transfers out of the EEA and UK today rest on the necessity of the transfer for performing our contract with the customer (Article 49(1)(b)) and, for transfers a customer initiates through a connector they configured, on that customer's own arrangements. If your organisation requires a specific transfer mechanism before personal data enters the product, contact privacy@serevel.ai first and we will tell you what we can put in place.

7. How long we keep things

This is the section most likely to differ from what you expect, so it is written literally.

There is no general retention schedule. Most records are kept until someone deletes the thing they belong to.

What actually happens:

Deleting an evaluation is the real erasure tool. When a customer deletes an evaluation, the database removes with it: the prospect accounts on it, their sessions, passkeys, login codes, access requests, invitations, progress, ratings, feedback, submissions, conversations and messages, contacts, sign-offs, the activity log, the completion record, and any meeting bookings.
What deleting an evaluation does not reach: queued notification records — some of which contain prospect email addresses and are not linked to the evaluation, so the deletion does not cascade to them; webhook delivery records, which can contain prospect email addresses and quoted text; the bytes of any uploaded file; our application logs; our database backup copies; and anything already delivered to the vendor's own Jira, Slack, Teams or webhook endpoint. Those are governed by the rest of this section and by the vendor's own systems, not by the deletion.
Deleting one prospect is a manual request. The product has no self-service control for it; we carry it out in the database on the vendor's instruction. Deleting the whole evaluation removes everyone on it at once.
Customer staff accounts are disabled rather than deleted in the product — that blocks sign-in, revokes API keys and ends live sessions. Full deletion is a manual request; some records stay where evaluation history refers to them.
Workspaces are suspended rather than purged by the product. On request we remove a departing customer’s data by hand.
Signup requests are kept indefinitely, including rejected ones, and including the applicant's email address and IP address. Only the password hash is deleted, at the moment the request is decided.
Invitation and join-request records are kept indefinitely, including the requester's IP address.
Raw billing events from Stripe are kept indefinitely, including whatever payer details Stripe put in them.
Webhook delivery records are kept indefinitely, including prospect email addresses and quoted text inside them.
Uploaded file contents are not removed automatically when their record is deleted; removing them is a manual step.
Application logs, which contain IP addresses and full request URLs, rotate by size (roughly the last 50 MB per service), not by age. We cannot remove one person's entries from them.
Notifications, queued events, sync-run records, evaluation-environment telemetry and AI job metadata are kept; nothing prunes them.

What does expire automatically:

AI job content: the submitted content and the model output are erased 7 days after the job finishes, and immediately when a user accepts or rejects the result. The metadata record described in section 2.11 is kept.
Prospect login codes: usable for 10 minutes and once only. The stored record is deleted when you use it, and replaced when a new code is requested for the same address. An unused code that is never replaced stops working on time; the record that remains holds the address and a one-way hash, never a usable code.
Prospect sessions: 24 hours, and expired records are actually swept from the database.
Employee sessions: valid for 7 days. Expired session records are never physically removed — they simply stop working.
Password-reset tokens (60 minutes) and sign-in handoff codes (60 seconds) stop working on time, but the used records are not deleted.
Synced Slack threads leave our index when they fall outside the look-back window a customer configured. Confluence pages leave when they are deleted, restricted, or moved out of the synced scope.

What "indefinitely" means. Where we say "indefinitely" above, we mean there is currently no automated deletion and no fixed period — not that we intend to keep it forever. The criteria we apply when we review these records by hand are: whether the record is still needed to run or bill a live workspace; whether it is needed to investigate abuse or a security incident; and whether we are required to keep it for tax or accounting purposes (financial records: seven years). We are working towards automatic deletion for signup requests, invitation records and webhook deliveries, and this section will state a period as soon as one is enforced in the product rather than promised here.

Backups. The database is backed up off-site every night, and continuously between those runs, to a third-party object store. Uploaded files are backed up off-site nightly as well. Both are encrypted on our server before they are uploaded, so the storage provider holds only ciphertext, and the keys are held separately from the server. Backups are retained on a rolling basis. A deletion in the live system does not reach the backups immediately — it takes effect there when the older copies age out. Separately, our engineering team sometimes pulls a copy of the database to a workstation for debugging; those copies are anonymised before use, and they are not part of the backup strategy.

When a customer leaves. We have no automated way to return or destroy a workspace's data at the end of a contract. If you ask us to, we will export what we can and delete what the database structurally permits, by hand, and we will tell you in writing what we could not delete and why. Copies inside backups are not deleted on request; they age out as described above. Until a customer asks, a suspended workspace's data stays in the database indefinitely.

8. Product analytics

We collect usage telemetry from the employee portal only. Prospect evaluation sites carry no analytics of any kind.

What is sent to PostHog: a pseudonymous person id of the form workspace-name:user-id, your role and the workspace's plan, the workspace's real company name as a group property, page views recorded as route templates (/pocs/:id/discovery, never the real URL, query string or referrer), every non-GET API call recorded as method + route + status, and six named product events (evaluation created, lifecycle transition, library authored, AI job submitted, AI job reviewed, connector configured).

PostHog's own technical properties are also kept: a device id, a session id, your browser and operating system and their versions, your device type, screen and window size, and your timezone. Everything not on that list is dropped before the event leaves your browser — an allow-list, so a vendor SDK update cannot start collecting something new. Autocapture, session recording and surveys are off, and text and element attributes are masked. The identifier is stored in your browser's local storage, not a cookie.

It is on by default for every workspace, and switching it off is a request rather than a setting: a workspace administrator who does not want it emails privacy@serevel.ai and we turn it off for that workspace. Turning it off is prospective — it does not remove what was already sent.

Your IP address reaches PostHog with each request. Our configuration asks PostHog to discard client IPs, but that is a setting in their dashboard and not something we can prove from our own systems, so we will not claim your IP is never stored there. We also cannot state PostHog's retention period; it is set in that product, not ours.

9. Your rights

If you are in the EEA or the UK you have the right to ask for a copy of your personal data (access), to have it corrected, to have it deleted, to have its processing restricted, to receive data you gave us in a portable form, and to object to processing we base on our legitimate interests. No processing described in this policy relies on your consent, so there is currently no consent to withdraw; if that changes we will say so here and you will be able to withdraw it at any time without affecting processing done before you did.

We will honour these rights, and where something has to be done by hand rather than by a button we will say so.

Your right to object

You have the right to object, at any time and on grounds relating to your particular situation, to any processing we base on legitimate interests — in particular the product telemetry described in section 8 and our security and operations logs. Email privacy@serevel.ai with the word "object". We will stop that processing unless we can show compelling legitimate grounds that override your interests, and we will tell you which it is.

How to ask

Email privacy@serevel.ai from the address the account uses, or tell us which address the request concerns and we will verify you before acting — we will not hand over an account's data on the strength of an unverified email. We will respond within one month. If the request is complex or you have made several, we may take up to two further months, and we will tell you within the first month if we do. Requests are free; we may charge a reasonable fee, or decline, only if a request is manifestly unfounded or excessive, and we will explain why.

If you are a prospect

The vendor who invited you is the controller of your evaluation data. Ask them first: they decide what the evaluation is for and whether it continues to exist. One practical note: there is no self-service control that removes a single participant. The vendor can correct your details, stop inviting you, or delete the whole evaluation; a narrower deletion we carry out by hand on their instruction, and we will tell you in writing what was removed.

You can always write to us as well. For the things we decide ourselves — our logs, our anti-abuse counters, the Terms-acceptance record, an access request you made — we act directly. For everything else we will tell you what we hold, identify the vendor if you do not know who they are, and pass the request on.

If you are a customer's employee

Your workspace administrator can disable your account and edit your details. Full deletion is a manual request — ask us and we will carry it out, and tell you if anything has to stay because evaluation history refers to it.

If you are in California or another US state with a privacy law

You have the right to know what personal information we collect about you and where it came from, to get a copy of it, to have it corrected, to have it deleted, and not to be treated worse for exercising any of these. The categories we collect, the sources, and the purposes are set out in sections 2, 3 and 4; how long we keep each is in section 7. We do not sell personal information and we do not share it for cross-context behavioural advertising. We do not use or disclose sensitive personal information for any purpose that would trigger a right to limit it. To make a request, email privacy@serevel.ai or write to us at the postal address in section 1; an authorised agent may act for you if you give them written permission and we can verify it. We will verify your identity against the email address on the account before acting.

Practical limits

We have no self-service export or download of personal data, for anyone. A subject-access request is served by hand.
We have no erasure endpoint. Deletion is manual, and in some places structurally impossible without deleting other people's records too.
We cannot remove your data from backups on demand; it ages out.
We cannot remove entries from application logs.
We cannot retract anything already sent to an AI provider.
Uploaded file contents are not removed by any deletion we perform today.

If you are not happy with how we handle your request, you can complain to your local data protection authority (in the EEA or UK) or your state attorney general (in the US). We would rather you told us first.

10. AI processing

10.1 When AI runs

AI features are available on every plan, including the free Individual tier, subject to a monthly allowance of AI assists (50 on Individual, 500 on Starter, 2,000 on Team, unlimited on Enterprise). They are on by default for every workspace. A workspace administrator can turn AI off entirely for the workspace. There is no partial setting, and no setting that restricts which backend is used (section 10.3).

10.2 What is sent, and for which features

Features that send content to a model: extracting use cases from an uploaded document, improving a use case, generating a discovery handout, generating a demo script, suggesting a reply to a prospect message, analysing stalled evaluations, the in-product assistant, extracting branding from a website, expanding search terms from a prospect's question, and screening new signup requests.

Depending on the feature, what is sent includes: the text of uploaded evaluation documents; use-case titles and content; discovery notes including free-text fields that in practice name the technical decision maker and economic buyer; the prospect company name, product and problem statement; the message text of prospect↔engineer conversations; excerpts from the customer's Confluence pages and Slack threads (including Slack authors' display names); and the assistant chat you type.

Two calls out of the ordinary:

When a prospect posts a message and our deterministic search finds too little, an AI call is made automatically to expand the search terms for the sales engineer. No employee clicks anything, and the prospect is not shown that this happened.
When someone submits the signup form on serevel.ai, we send the company name, the chosen workspace name, the domain part of the admin email address (never the full address), the plan requested and the company homepage URL derived from that domain to the same model backend, to flag applications that need a closer look before a person approves them. The result is advisory only — it never approves or rejects a workspace by itself.

Uploaded document files are converted to text on our server and the original file is discarded — only the extracted text is sent.

10.3 Where it goes

There are exactly two backends, and no others:

A model server we run ourselves. This is the default. It is a machine we operate — not a datacentre, and not managed hosting: a computer on our own premises, reached by the job runner over an outbound-only connection. Content sent to it is processed locally and is not forwarded onward by us. We instruct ourselves to keep request and chat logging disabled on that model server, but that is an operating instruction rather than something enforced in software, and we have not had the machine's physical security independently assessed.
Anthropic, in the United States. When a job is routed there, the full prompt — which is to say the content listed above — goes to Anthropic.

Which backend is used is our decision, not the customer's. It is set per model, per workspace or platform-wide by us. There is no setting that lets a customer require local-only processing; the only customer control is turning AI off.

If you would rather no evaluation content reached a third party at all, turn AI off for the workspace, or ask us in writing to route your workspace to the self-hosted backend only, and we will.

10.4 What we do and do not do

We do not train any model on your data. We cannot make that promise on Anthropic's behalf for content routed to them.
Each AI call is stateless. On the Anthropic path the tool is run with an empty, temporary home directory, no session persistence, no file, shell, web or tool access, and the directory is deleted afterwards. Prompt and output text is never written to our job-runner logs.
Content retrieved from a customer's Confluence or Slack is fenced as data, and model output is re-validated before anything is applied.
Submitted content and output are erased 7 days after a job finishes, or immediately on accept/reject. The metadata record in section 2.11 is kept.
We do not offer an AI analytics product that reads across your workspace, whatever a teaser page may suggest, and we do not analyse infrastructure templates with AI. Those are not built.

10.5 If you are a prospect

Your messages to your sales engineer are part of what these features process. When you post a message, a search-term expansion may run automatically, with no employee action and no indication to you. When the engineer asks for a suggested reply, the text of your conversation is included in what is sent. Depending on routing that we set — not the vendor — that content is processed either on hardware we operate ourselves, where it does not leave that machine, or by Anthropic in the United States.

You cannot switch this off, and the vendor cannot exclude you individually; the only available control is the vendor turning AI off for the whole workspace. If you want to object, tell the vendor and tell us — that workspace-level switch is the only remedy either of us can offer.

11. Cookies and similar technologies

In the product (app.serevel.ai and workspace subdomains)

Name	Purpose	Set by	Lifetime
`serevel_session` (`__Host-` prefixed and Secure in production)	Employee sign-in. Strictly necessary. HttpOnly, SameSite=Lax.	Serevel	Until you close your browser (no expiry is set; the server-side session lasts 7 days)
`serevel_prospect_session` (`__Host-` prefixed and Secure in production)	Prospect sign-in on evaluation sites. Strictly necessary. HttpOnly, SameSite=Lax.	Serevel	Until you close your browser (the server-side session lasts 24 hours)
`serevel_prospect_webauthn`	Carries one passkey sign-in challenge on evaluation sites. Passkeys are available to prospects only; employee sign-in does not use them.	Serevel	5 minutes

Browser local storage. We store interface preferences (a dismissed banner, a chosen filter) in your browser's local storage — these are yours alone and never sent to us. We also store the product-analytics identifier described in section 8 there. Local storage is not a cookie, but the rules on storing information on your device treat it the same way, and we do not currently ask for your consent before setting the analytics identifier — see section 8 for how to have analytics switched off for your workspace.

No advertising or cross-site tracking cookies are used in the product.

On the marketing site (serevel.ai)

The marketing site loads Google Analytics 4 on every page — including this one — and sets first-party analytics cookies (_ga and _ga_<property id>, both lasting up to two years) as soon as the page loads, before you have read this. We have not enabled IP anonymisation, Google Consent Mode, or any regional gating, so GA4 collects what it collects by default: page URL and path, referrer, device and browser, approximate location derived from your IP address, and a persistent visitor identifier. Google processes this both on our behalf and for its own purposes under its own terms; we cannot tell you Google's retention period from our own systems.

There is no cookie banner and no consent gate. Those cookies are set before you are asked, because we do not ask. There is no in-site opt-out, and we do not currently act on Do Not Track or Global Privacy Control signals. In the EEA and UK this is not what the rules expect, and we are working on it. Until then, the ways to refuse are your browser's cookie controls, a content blocker, or Google's own analytics opt-out.

Fonts on the marketing site are self-hosted; no request goes to Google Fonts.

12. Calendar booking

An optional feature lets a prospect book a real meeting slot with their sales engineer. It works like this:

It is optional three times over: the feature is only available on our Team plan and above; a workspace administrator must then register the workspace's own Google or Microsoft OAuth application; and each engineer must personally connect their own calendar. Administrators cannot connect a colleague's calendar or see the grant.
We use busy intervals only — we never read or store event titles, attendees or locations. On Google this is enforced by the permission itself, which cannot return anything more. On Microsoft the availability response can contain more than we use; our code reads only whether a period is busy and its start and end time, discards the rest, and stores none of it. Busy information is used within the request to compute available slots and then dropped.
One asymmetry we will not gloss over: Microsoft does not offer a free/busy-only permission, so the Outlook consent screen grants broader calendar access than the feature uses. The restriction is enforced by our code, not by the permission itself.
When a slot is booked we create an event on the engineer's calendar with the prospect as an attendee; the calendar provider — not us — sends the invitation.
We store the booking: the prospect's email address and name, the time, and the agenda note they typed. The booking record deliberately outlives the prospect account and the calendar connection; it is removed when the evaluation is deleted.
Access tokens are stored encrypted. Disconnecting revokes with the provider where possible and deletes the stored grant; Microsoft offers no revocation endpoint, so there you should also remove the app in your Microsoft account.
Because offered slots are the exact complement of busy time inside published working hours, someone booking can infer when the engineer is busy within those hours. Engineers control this by turning booking off or shortening the booking horizon.

13. Email — we do not read it

Serevel holds no mailbox permissions of any kind, for anyone. There is no Gmail, Outlook, IMAP or other mail access in the product; we do not read or ingest anyone's mail, and we do not send mail on anyone's behalf. The only email involved is our own transactional mail: your login code, invitations, password resets and notifications. If this ever changes, we will update this policy before the feature ships.

14. Security

These are measures we have actually implemented. We hold no security certifications, and we are not claiming any.

Tenant isolation is enforced in the database itself: every workspace table has row-level security with default-deny policies, composite primary and foreign keys so a cross-workspace reference is a constraint violation, and the application connects as a non-superuser role. A test suite replays every identifier-bearing route as one workspace against another workspace's identifiers.
Passwords are hashed with Argon2id and never stored or logged in plain text. Reset tokens, invite tokens and handoff codes are stored only as SHA-256 hashes; API keys are stored as keyed hashes.
Sessions are opaque database identifiers in HttpOnly, SameSite=Lax cookies, Secure and host-locked (__Host-) in production. Disabling an account or resetting a password removes its sessions immediately, including live event streams, and revokes that user's API keys.
Sign-in defences: identical responses and equalised timing for unknown accounts, wrong passwords and passwordless accounts; a neutral page for unrecognised prospect domains so identities cannot be enumerated; constant-time comparison of prospect login codes; sliding-window rate limits on every credential surface, held in the server's memory and reset when it restarts; and, where it is configured, a Cloudflare Turnstile challenge on signup that refuses the request rather than letting it through if the check cannot be completed.
Secrets you give us — connector credentials, OAuth grants, webhook signing secrets, SSO client secrets and (when it ships) calendar grants — are encrypted with AES-256-GCM, bound to your workspace so a ciphertext cannot be replayed into another one, with key rotation support. Routes fail closed if the key is missing. No API ever returns a stored secret.
Outbound calls to your systems go through a guard that blocks non-HTTPS targets, private and metadata addresses, and does not follow redirects; webhook delivery re-validates at send time and connects to the pre-validated address.
Payments: card data is entered on Stripe's hosted pages and never touches our systems. Stripe webhooks are signature-verified against the raw body.
Transport: HTTPS everywhere, with certificates from Let's Encrypt and Cloudflare in front.
Backups are encrypted on our server before they are uploaded, and the tooling refuses to run rather than upload anything unencrypted.

We do not hold a SOC 2 or ISO 27001 attestation, and we do not claim one. If your organisation needs to assess our controls before personal data enters the product, write to privacy@serevel.ai and we will answer your questionnaire in writing.

Breach notification. If we become aware of a personal data breach we will notify the affected customer without undue delay and, where the law requires it, the relevant supervisory authority within 72 hours and the individuals affected — and we will do so from the facts, not from a template. Report a suspected security problem to privacy@serevel.ai.

15. Children

Serevel is a business product sold to companies. It is not intended for anyone under 18, we do not knowingly collect data from children, and there is no consumer sign-up path. If you believe a child's data is in the product, write to privacy@serevel.ai and we will remove what we can.

16. Changes to this policy

We will post changes on this page and update the version number and effective date shown under the title. We do not yet keep a public archive of previous versions; if you need the version that was in force on a particular date, ask privacy@serevel.ai and we will send it to you. If we ever want to use personal data we already hold for a new and different purpose, we will update this policy and tell affected customers before we do.

We do not currently have a reliable way to email every affected person about a change, so please check back if this matters to you.

17. Contact, where to find this policy, and complaints

Questions, requests and complaints: privacy@serevel.ai, or the postal address in section 1. Tell us which category you fall into — staff of a customer company, billing contact, prospect (someone a vendor invited into an evaluation site), or website visitor — and we will get to the right answer faster.

If you are a prospect and you are not sure which vendor invited you, the workspace name in the web address of the site you used will tell us; send that.

Where you can find this policy. It is published at serevel.ai/privacy. It is linked from the foot of every page on serevel.ai. If you were invited into an evaluation and want a copy, the address above always has the current version, and privacy@serevel.ai will send it to you.

If we do not resolve your concern, you may complain to your data protection authority in the EEA or UK, or to your state attorney general in the US.

Privacy Policy