Privacy Notice

1. Who we are

The Pharen platform (pharen.ai) is operated by Pharen, a trade name of Lucubra LLC, a Washington (USA) limited liability company. For everything this notice covers, Lucubra LLC is the data controller. Reach us at hello@pharen.ai or by mail at Lucubra LLC, 522 W Riverside Ave, Ste N, Spokane, WA 99201-0581, USA.

2. What this notice covers

This notice covers personal data we process about:

• visitors to pharen.ai;
• people who contact us — about an organization or an account, support, security reports, or anything else;
• people who hold an individual account under our Account Terms, including as the Owner of an organization that no customer has yet been approved for;
• the people on a customer’s team who operate its organization on Pharen (the console, the CLI, and control-plane APIs), the people who apply for an organization or are invited to join one, the people who accept our Terms for a customer, and the people a customer names to receive its organization’s notices;
• a customer who is an individual, such as a sole proprietor, for the contract and notice data we keep about them, including where someone else accepted our Terms or set up their organization for them;
• the people whose devices run an app after its developer’s agreement with us has ended, for the requests Section 3 describes.

3. What we collect

What you send us. When you email us — organization or account questions, support, security reports — we receive your email address and whatever you choose to include. We suggest what’s useful to include; you decide what to send.

Account data. You sign in to the console and CLI with GitHub or GitLab, or with a passkey, described below. We never see a password: GitHub and GitLab check theirs, and a passkey has none. With GitHub or GitLab, from your profile we keep two things: your username and your numeric account ID — and, if you choose one, the email address described next. If a customer adds you to its organization by your username, we look up your numeric account ID in that provider’s public user directory. Beyond that, the one-hour offers described next and, when you apply for an organization, the addresses described under “Applying for an organization”, the sign-in keeps nothing — not your avatar. The access token the provider issues is used only during sign-in, to read what this section names, and then discarded — it is never stored. Your role, and the customer organizations you belong to, are held in our membership records and deployment configuration, not in a profile we build about you.

Passkeys. A passkey is a sign-in key that your device, security key or password manager makes and keeps. Your device unlocks it with your fingerprint, face, PIN or screen lock. That check happens on your device: your fingerprint, face and PIN never reach us, and we receive only your device’s signed answer. For each passkey we keep its public key (we never receive the private half, which stays with your device or password manager), its credential ID, a counter your device reports with each use, the ways it can connect (such as USB or Bluetooth), whether it can be and has been backed up or synced, the kind of authenticator holding it (the model identifier your device or password manager reports, where it reports one: the same identifier for every authenticator of that model, not one unique to yours), the name you give the passkey when you make it, if you give one (up to 64 characters, shown only to you), and when it was made and last used. Your passkeys belong to a random identifier we create for you, which names no address, person or organization, apart from a tag for the region it was created in; we keep no email address with your passkeys, and none of the names you give organizations (for an individual account we keep a contact address, described below). Your passkey page lists your passkeys, when each was added, and the ones you removed in the last 90 days. When you join an organization with a passkey, at the start page or from an invitation, you give the name that organization shows you by: in its member list, its membership history and the mail its owners receive about you, the place a GitHub username takes. We keep that name with that membership or application, not with your passkeys, so you can give a different one in each organization. When you make your first passkey from one of our links, we pass your device the email address the link went to and the name you gave, if you gave one, so the passkey is saved under them and you can tell your passkeys apart; that label is kept by your device or password manager, not by us. A second passkey made in the same step is saved under that name alone, and one you add later from your passkey page under a general label.

Email links for passkeys. Your first passkey starts with an email address: “Continue with email” on the start page, an invitation that offers a passkey, or a request to set up an individual account. We email that address a link that works once, for 30 minutes. It opens a page with a button, and only pressing the button uses the link, in the browser where you press it. We keep the link as a one-way fingerprint of its secret, and the address it went to encrypted, for no more than 7 days; for an individual account, the address is then kept as the account’s contact address, described below. An invitation sent to an email address sends its link only to that address. On an open invitation link, the address you type waits for an owner of the organization to approve it before the membership opens. If you apply for an organization at the start page, the address the link proved is kept with your application until it is approved or declined, or the application lapses; on approval it becomes the address of your owner membership, described below. The record of a confirmation sent to it is kept longer, as described under “Applying for an organization”. Each of these emails offers “stop these emails”: once you confirm on the page it opens, for 30 days we send that address no more links that anyone asks for from the start or invitation pages, or by a request to set up an individual account. That stop does not withhold the check and reset links described next, which go only to an address already confirmed on a membership. To limit how often an address and its email domain are mailed, to apply that stop, and to limit how many applications an address may have open or recently approved, and how many organizations it may set up through individual accounts, we keep fingerprints of the address and of its domain, made with a key only we hold, so they cannot be read back to the address without it. They are kept for about 30 days after they were last used, or, for an application, 30 days after it is decided, or, for an individual account, while the organization it set up awaits approval and for 30 days after that organization is approved, or until it is closed if it is closed before approval. We use the ones kept for an individual account only to apply these limits, never to find an account or a person. We treat them as personal data.

The periodic address check. A membership you hold with a passkey re-proves its email address from time to time: every 30 days, or more often if the organization sets a shorter interval, though never more often than every 7 days. When it is due, the next time you use that membership we email its address a link, which works for 30 minutes, and its page asks for your passkey as well, so a link pressed by anyone else confirms nothing. You have 7 days to confirm, and longer if our mail cannot be sent. After that, the membership is paused, not removed: you are offered the link again, and the membership opens as soon as you confirm. The check exists so that when you lose the mailbox, for example when an employer closes a work address, your access to that organization ends with it, while your other memberships carry on. For each such membership we keep when its address was last confirmed or re-proved, when its 7 days began, and when its current link was sent and expires, for as long as the membership lasts. There is no periodic check on a GitHub or GitLab membership, or on a passkey membership that the organization has linked to its own sign-in service, which checks you each time you sign in through it. On a passkey membership, a new address you confirm takes effect only once an owner of the organization other than you approves it; owners other than you are told a change is waiting, and a change no one approves lapses 7 days after you asked for it, taking the new address with it. If you are the organization’s only owner, the change completes 7 days after you asked for it instead, unless one of the organization’s notice contacts refuses it first; those contacts are told the email domains of the old and new address, never the addresses themselves. If our mail cannot be sent when those 7 days would end, the change waits until 7 days after sending resumes. A refused change, with its new address, stays visible to you and the owners until you ask for another address and its link is sent, enter your current address again, your passkey sign-in there is reset, or the membership ends.

Resets. If you lose every passkey, an owner of an organization can reset your passkey membership there. The reset signs you out of that organization and emails its address a link to make a passkey or use one you already have. Your access returns only when an owner enters a short code your device shows you, which you give them outside your mailbox. We keep a fingerprint of that code, never the code, for at most 7 days after the latest link. You and the other owners are told when the reset completes. A reset in one organization never changes your passkeys or your other memberships, and a GitHub or GitLab membership is never reset.

The CLI with a passkey. Signing in to the CLI with a passkey opens your browser, where you approve it for one organization with your passkey, within about ten minutes. While it waits, we keep the request: the local address and port on your own computer that the browser hands the result back to, one-way fingerprints of its one-time codes, and, once approved, which passkey sign-in and membership approved it. The session it opens lasts up to 90 days, as a CLI session does.

Individual accounts. Where we offer one, you can set up an individual account for yourself under our Account Terms, from an email link and a passkey, as described above. When you accept the Account Terms, we keep a record of it: the random identifier your passkeys belong to, the version of the terms and the exact words you were offered and agreed to, when you agreed, and when the account was set up. That record holds no email address, network address or browser details. We also keep whether the account is open, suspended or closed. Setting up the account creates an organization that no customer has yet been approved for, with you as its Owner. It has an identifier we create, its membership and history records, and the apps you register in it, each with the identifier and name you give it. We do not ask for your employer, its name or its address. The email address your set-up link went to becomes the account’s contact address. We use it to send you notices about the account, including legal notices and notice of a cleanup; to confirm a request you make about your data, by sending a link to it; and to send a recovery link if you lose every way to sign in, which completes only after a waiting period during which it can be refused from any sign-in to the account that is still active. It is never a way to sign in, we do not look you up by it, and we do not send marketing to it. If you link a GitHub or GitLab account to your individual account as a second way to sign in, we keep what we keep for any GitHub or GitLab sign-in, described under Account data above. Setting up an account does not sign you up for any mail.

Your email address as a member. Signing in — to the console, the CLI or an invitation, or linking GitHub to an individual account where we offer it — asks GitHub for nothing more than your username and numeric ID, and reads no email address — except accepting an invitation sent to an email address, described below, which asks to read your email addresses to check the invited one is yours. Signing in to apply for an organization asks for nothing more either, unless we send application confirmations, described further below. Otherwise, only when you choose to take an address from GitHub, with the “Choose an address from GitHub” button on your address page, does that sign-in ask GitHub for read access to your email addresses (the user:email permission), and nothing more — it cannot read a repository or a GitHub organization. We read your addresses then and offer you the ones GitHub has verified. Choosing an address from GitLab reads the primary address, private or not, that GitLab returns under the read_user permission its sign-in asks for, with the date GitLab confirmed it, and we offer it only when GitLab has confirmed it; GitLab’s profile answer carries that address in every sign-in, and we keep it only when you asked, or when you apply, as described further below. You can decline at the provider, or decline what is offered, and type an address instead; you stay signed in either way.

You choose one address for each customer organization you are a member of, or type one and we send a link to confirm it. We keep the address you choose for that membership alone, with when and how it was confirmed. Addresses we offered that you did not choose are kept for at most one hour, and only you can see them. We use your address for mail about your own access to that organization: a new sign-in, or a session switched in from another organization, in your name; a change to your role; a change to how the organization requires you to sign in; your removal; confirming the address itself; and, for a passkey membership, the periodic check, a reset of your sign-in, and a passkey added to or removed from your sign-in while you were signed in to that organization. If you are an owner, we also use it to tell you that another member’s change of address waits for your approval, and that another member’s sign-in has been reset. We never use it for marketing, for the notices a customer’s contract requires (those go to the contacts the organization names), or for alerts. A link we send it is never enough on its own to sign in to a membership you already hold: the periodic check also needs your passkey, and a reset needs an owner’s check outside your mailbox. We never use your address to find you in another organization or to link your accounts. This mail is not optional mail, so the “stop optional mail” link below does not stop it. We ask every member to have an address. When you join an organization, the console and the CLI ask for one before anything else, and the organization opens to you as soon as it is confirmed, or, for a passkey membership joined from an open invitation link, once an owner approves it, as described under “Email links for passkeys”. Nothing is revoked, and a new member who signs in with GitHub or GitLab is not held back for want of an address while our mail cannot be sent at all. A passkey membership always needs a confirmed address before it opens.

A member with the owner role in an organization may also invite you by email address. We send that address one invitation with a link, and keep the address on the invitation only while it is open; the organization’s owners see it there. The invitation is accepted only by a GitHub or GitLab account that lists that address as verified when you sign in with it, or with a passkey made or used from a link we send to that address, and your membership then holds that address, confirmed. Holding the link is not enough, and the page it opens does not show the address. Once the invitation is accepted, withdrawn or lapsed, we keep only the fingerprint described below. The invitation offers “I didn’t ask for this”, which withdraws it and works as described under Mail preferences.

Within the organization, your address is visible to you and to the organization’s owners, in its member list; no other member sees it. You can change it at any time in the console. The old address keeps receiving mail until the new one is confirmed, and is told of the change. It is removed when you leave the organization or are removed from it; to have it erased at any other time, write to hello@pharen.ai, and the organization then asks you for an address again, as above. We keep it for as long as you are a member of that organization, except that an address you typed and have not confirmed lapses after seven days. Once a link to confirm an address, or an invitation, is used, replaced, withdrawn or lapsed, we keep only a one-way fingerprint of the address it went to, for thirty days, to limit how often an address is mailed; the fingerprint is used to apply those mailing limits and is not treated as anonymous data. The records of the mail we send to it are kept as Section 9 describes for records of every other message, and the address in them is erased when you ask us to erase yours.

Applying for an organization. When you submit an application at the start page, we may email you to say we received it, with a link to the page that shows where your application stands; that page says whether we did. Anyone who has that link can read the application, so share it only with people who should see it. We send that email only to an address your sign-in proved is yours: the address a passkey link proved, or one your GitHub or GitLab account has verified. While we send these emails to GitHub and GitLab applicants, signing in with GitHub at the start page also asks for read access to your email addresses (the user:emailpermission), on the same screen as the sign-in, and we read the ones GitHub has verified; with GitLab, we read the primary address its sign-in returns, when GitLab has confirmed it. We keep those addresses with your application until you submit it, and for no more than 14 days if you don’t. The email goes to the business email or notice address you give us when it is one of them, one email to each if both are, and otherwise to the first of them, which for GitHub is your primary address when it is verified. An address you typed that no sign-in proved is never sent this email; it first hears from us when we approve the application. If your provider gives us no verified address, you can still apply: we send no email, and your application’s page says so. We keep a record of each of these emails, with the address it went to, as part of the acceptance record described next.

Contract and notice data. When a customer accepts our Terms, we keep the customer’s name and jurisdiction, the name, title and business email of the person who accepted, and the notice address they gave. As evidence of the acceptance we also keep when it was made, the network addresses and browser it came from, and, where the person signed in to accept, their sign-in username and numeric account ID, or, for a passkey, the name they gave and the random identifier described above. While we review a customer’s organization, before we approve it, a business identifier may also be given for the customer, such as a D-U-N-S number. Giving one is optional; it can be changed until we approve the organization, and corrected on request after that (Section 10). We use it to verify the customer’s identity during that review, and if we later verify it under our Terms. A customer may name further contacts to receive notices about its organization (billing, security, operations). We send each new address a link to confirm it before it receives any notice, except the contract’s own address, which receives notices from the start. We keep a record of each notice we send: what it was, the address it went to, when, and whether it was delivered. When the only owner of an organization asks to change the address their passkey membership is checked by, we send a security notice to its notice contacts, and to any contact removed or replaced in the 30 days before, so that any of them can refuse the change.

Mail preferences. If you mark one of our emails as spam and your mail provider tells us so, or you use the email’s “stop optional mail” link or your mail app’s unsubscribe button, we record your address, that reason and the date, and send that address no optional mail again. After a spam report we also send it none of the passkey links described above, including a periodic check, so a membership that depends on them can pause; mail that cannot be switched off, such as the notices a customer’s contract requires, remains eligible for delivery. If you tell us from an email asking to confirm an address, or from an invitation, that you did not ask to receive it, we record that the same way and send that address no more requests to confirm it and no more invitations, from any customer organization where it is not confirmed already; if it is a contract’s own notice address, the contract’s notices remain eligible for delivery. Delivery can still fail; contractual receipt and held periods follow Terms Section 20. Each record covers every customer organization and names none of them. You lift either one yourself, from the page an email asking to confirm an address links to. For the first, a member with the owner role in the customer’s organization can send you a new email asking to confirm an address; for the second, write to us, and we send a link to that address.

Operational data. Operating the console, CLI, or APIs generates logs — IP address, user agent, timestamps, and the actions taken — kept for security, audit, and troubleshooting. Administrative actions on a customer organization are recorded with the acting identity. After a customer’s agreement ends, devices running its app may still contact the Service to learn that they are no longer served, and the app then deletes the data our software held on the device. For these requests we keep only counts — by app, environment, app version and software version, with no network address or device identifier — and the short-lived server logs our systems write, which record neither. Each request reaches the Service through our hosting provider, which receives the device’s network address, as it does for any request (Section 7). We process these requests on our legitimate interest in ending the service cleanly and having that data deleted from the device.

Site data. pharen.ai is a static site served through a content-delivery network; standard server logs (IP address, user agent, pages requested) exist at that layer for security and delivery (Section 7).

Billing data. For paid plans, we keep billing contact details and plan and invoice records. Payment-card details go directly to our payment processor, Stripe — full card numbers never touch our systems. At checkout, Stripe also collects your billing contact details, billing address and any tax ID you give. We give Stripe your organization’s confirmed billing contact address, or its primary contact address where it has none that is confirmed and deliverable, so that Stripe’s receipts reach that contact, and update it when those contacts change; where neither holds a deliverable address, the record keeps the address checkout collected.

4. What we don’t do

• No analytics scripts, no trackers, no advertising pixels on this site. pharen.ai loads no analytics, tracking or advertising scripts.
• We do not sell personal data, and we do not share it for advertising — ours or anyone else’s. Browser signals like Global Privacy Control are honored.
• No marketing lists. We email you about the Service and about things you asked us about. Tell us to stop and we stop. If a customer named you to receive its organization’s notices, stopping our optional mail leaves the notices that cannot be switched off; to stop those too, ask us to remove you from the customer’s contacts (Section 10). The mail about your own access to an organization (Section 3) is not optional either, and stops when your address is removed. Nor are the notices about an individual account sent to its contact address (Section 3), while the account exists.
• No automated decisions. We do not make decisions about you by automated means that produce legal or similarly significant effects, and we do not profile you.

5. Cookies

This website sets no cookies. The console sets two, both strictly necessary and neither used for analytics or advertising: a sign-in cookie that lasts up to 30 days and is cleared when you sign out, and a ten-minute cookie that protects the sign-in exchange against cross-site request forgery. That second cookie is set by api.pharen.ai and sent only to its sign-in addresses, and holds a single-use random value, the console page to return to, and a code your sign-in provider is asked to match. When you sign in to start an organization, accept an invitation, or check an application, it lasts up to 30 minutes instead, and when you start an organization or accept an invitation it also holds the organization identifier you typed on the start page or the invitation you opened, so the sign-in finishes what you began. The sign-in cookie is scoped to pharen.ai, so your browser also sends it to this site — this site sets nothing, but the cookie travels with the domain. Passkey sign-in adds three more, each strictly necessary and short-lived. On the console, a link’s page sets a ten-minute cookie, sent only to that page and the stop page beneath it, which holds the step the link started, with the email address and organization the page shows, so a reload carries on rather than starting again. On the start page, “Continue with email” sets a cookie for up to an hour holding the organization identifier you typed, so the link finishes in the browser where you began, and its link’s page sets one for up to fifteen minutes holding the step the link started. On the pages where you ask for a passkey link (the start page, an invitation page and, where we offer individual accounts, the page where you ask to set one up), the bot check described in Section 7 runs from Cloudflare, which may set its own strictly necessary cookies or browser storage for that check. Our content-delivery network may set short-lived, strictly necessary security cookies (such as bot mitigation). We use no analytics or advertising cookies anywhere, which is why we do not use a site-wide cookie banner.

Hosted report pages offer a separate, optional choice to remember your email on this browser. Only choosing “Send and remember my email” saves it in a cookie for one year, scoped to that report page, so it can prefill your next report. Choosing “Forget saved email” clears it without sending a report; this does not delete an address already sent with a report. Sending a report without remembering still works and clears any saved email. Clearing the email field and sending also clears it; a page that no longer asks for an email clears it when visited. Cookies saved without that explicit choice are not used to prefill the form and are cleared when the page is visited. This browser choice does not change whose notice governs the report and its reply address, as Section 2 explains.

6. Purposes & legal bases

7. When we share information

We share personal data only with: service providers that host, deliver and help us run the Service and this site, under contracts that govern what they do for us — Render (hosting), Cloudflare (DNS, content delivery, storage, and the bot check described below), GitHub and GitLab as sign-in identity providers, Amazon Web Services (Amazon SES, for the email we send about a customer’s organization, the passkey links and application confirmations described in Section 3, and the notices, links confirming a request about your data, and recovery links sent to an individual account’s contact address, under terms that let it store and scan that email to detect abuse of its service), Google (Workspace, for our own email), and Stripe for payment processing, which also uses what it collects as its own controller — for fraud prevention, anti-money-laundering and know-your-customer checks, its choice of banks and payment networks, and its licensed services — under Stripe’s privacy policy (the vendors that process Customer Data are listed separately in the Subprocessor Register); authorities, where a law, legal process, or protection of rights and safety genuinely requires it — narrowly, and with notice to you where lawful; and a successor in a merger, acquisition, or sale of the business, bound to honor the commitments in this notice. No one else.

Connection data. Requests covered by this notice — to this site, from the console or CLI, or from an App device, including after its developer’s agreement with us ends — reach our hosting and delivery providers. Render and Cloudflare receive connection metadata for requests they handle: network address, routing, timing, protocol, status and service-performance information. Their terms reserve separate roles for some of that processing. Render distinguishes its Usage Data from processing solely on a customer’s behalf; Cloudflare distinguishes traffic and Network Data from Customer Logs and Customer Content. See Render’s DPA, Render’s privacy policy, Cloudflare’s agreement, and Cloudflare’s privacy policy.

We recognize these separate roles for ordinary metadata reasonably necessary for lawful hosting, delivery, network security, abuse prevention, troubleshooting, maintenance and optimization of the contracted infrastructure, or applicable legal obligations. This is not permission to use Customer Data or End-User personal data, including identifiable connection metadata, for sale or rental, advertising, or model training. It does not authorize unrelated profiling or personal-health inference. Customer payloads and health-revealing URL components are outside that ordinary-metadata permission. We never share personal data for advertising, ours or anyone else’s. The DPA and applicable law continue to govern Processing on our Customers’ behalf; provider role labels do not remove statutory protections or supply a lawful basis. Updating this notice does not supply consent where the law requires it.

The bot check. Before we email a passkey link that someone asks for without being signed in, from “Continue with email” on the start page, from an invitation page or, where we offer individual accounts, from the page where you ask to set one up, the page runs Cloudflare’s Turnstile check, which tells a person from an automated script. It reads signals from your browser and connection, such as your network address, browser details and the page it runs on. We then send Cloudflare the check’s result token and your network address to confirm it. We do not send Cloudflare the email address you type. If the check does not pass, or cannot be reached, we send no link. Cloudflare runs the check for us, and its Turnstile privacy terms say it also uses those signals, as its own controller, to improve its bot detection; see Cloudflare’s Turnstile privacy terms.

8. Where data is processed

We are based in the United States and process data there, except that requests cross our content-delivery network’s global edge in transit, the bot check in Section 7 runs on that network, which may be outside the U.S., and our email, which Google Workspace holds, may be stored in Google’s data centers in other countries, under Google’s data processing terms. If you are in the European Economic Area, the United Kingdom, or Switzerland, data you send us is transferred to the U.S.; where such transfers require safeguards, we rely on the European Commission’s Standard Contractual Clauses (and their UK and Swiss equivalents) with our vendors — email hello@pharen.ai to request a copy of the safeguards we rely on. Pharen is not certified under the EU–U.S. Data Privacy Framework; the Standard Contractual Clauses are the operative mechanism.

9. Retention

Per category: what you send us (correspondence) is kept for the life of the relationship it belongs to, then as legal obligations require; account data is kept while you are a member of a customer’s organization on Pharen — when your membership ends, we keep its record (including your numeric account ID, username and role, or for a passkey membership the name you gave and the random identifier your passkeys belong to, and who granted and ended it) as an audit record for the life of the customer’s agreement and afterward only as reasonably necessary to comply with a legal obligation or establish, exercise, or defend a legal claim, subject to applicable deletion rights. We periodically review that necessity and delete or de-identify records no longer needed, and we remove your username from that record if you ask; your numeric account ID and username also stay, for the same period, in the organization’s membership history and in the records of the memberships you granted or ended, which that request does not reach — plus the other audit records needed to evidence the relationship for as long as law and good records practice require, and your member email address, and the addresses we read when you apply, follow Section 3; operational data (logs) rotates on short, fixed schedules — console sign-in sessions expire within 30 days and CLI sign-in sessions within 90 days, and logs are kept for security and troubleshooting, not archives; site data (delivery-layer logs) and the connection data our hosting and content-delivery providers receive (Section 7) are kept by those providers for security and operations, as their terms provide; billing records are kept as long as tax and accounting law requires.

Passkeys are kept while you keep them. A passkey you remove loses its public key at once, so it can never be used again, and the rest of its record is deleted 90 days after you removed it. Your passkeys belong to no one organization, so leaving or being removed from one does not delete them while you belong to another, and your passkey page removes any but your last. Once you belong to no organization, any account you created with us is closed, and you have no application or reset of your sign-in under way, your passkeys are deleted 30 days later. You can ask us to delete them sooner: email the address in Section 10 from the email address you used with us, since we find your passkeys from it, through the mail we sent it and the records of your memberships and of any application you made. We then delete every passkey we can tie to that address, end every session signed in with them, and delete the short-lived sign-in records that name them. If we cannot find some or all of your passkeys from your email address, we tell you. We do not look an individual account up by its contact address, so a passkey used only for one cannot be found this way; to have it deleted, follow Section 10 instead. If you still belong to an organization, have an account you created with us that is not closed, or have an application under way, deleting your passkeys leaves that membership, account or application with no way to sign in, and withdraws the application. A passkey link’s encrypted address, the link’s other records, which hold only fingerprints, and a single-use sign-in challenge are each kept for no more than 7 days, except that the address a set-up link proved for an individual account is then kept as the account’s contact address, as described below. An applicant’s proven address is kept until the application is decided or lapses, apart from the record of a confirmation sent to it, kept with the acceptance record below. The fingerprints that apply the mailing limits, the stop and the limits on applications and on organizations set up through individual accounts are kept for about 30 days after their last use, or 30 days after the application they count is decided, or, for an individual account, while its organization awaits approval and 30 days after it is approved, or until it is closed if it is closed before approval. A periodic check’s dates are kept for as long as the membership. A waiting or refused change of address keeps the new address as Section 3 describes, and the record that a change happened, without the address, for no longer than the life of the organization and 90 days after. A reset’s fingerprint is kept for at most 7 days after its latest link, and a CLI’s pending passkey sign-in for no more than 7 days. Passkey sign-in sessions expire as other sessions do: within 30 days in the console and 90 days in the CLI.

Individual accounts. The record of your acceptance of the Account Terms is kept while your account exists and for six years after it is closed, as evidence of what you agreed to, and longer only while a legal claim or obligation requires it. Whether the account is open, suspended or closed is kept with that record. An organization awaiting approval, with the apps registered in it, is kept for as long as it awaits approval, with no deadline; a customer application for it that we decline or archive does not close it. Once a customer is approved for it, it is that customer’s organization, and the rest of this section applies to it. When it is closed before approval, by you or by us under the Account Terms, your membership in it ends, and its apps and everything else set up in it are deleted 90 days after it is closed, except the organization’s own record, your ended membership and that membership’s history, which are kept with the record of your acceptance, which names them, for as long as that record is kept. We may close an account that has gone 15 months without a sign-in, once it no longer holds an organization awaiting approval or any membership. The account’s contact address is kept while the account exists and deleted 90 days after it is closed, or sooner if you ask us to erase what we keep about the account; that we sent a notice, and when, without the address, is kept with the record of your acceptance.

Contract and notice data, including a business identifier given while we review an organization, which is never part of the acceptance record, is kept while the customer’s organization on Pharen exists, except for four kinds of record. The acceptance record, with the record of each email confirming the application it made, is kept for the life of the customer’s agreement and the period in which a claim under it can be brought. Notice records of the notices the contract requires, and of the few others about the organization’s standing that we treat the same way (such as a usage limit reached or a trial paused), are kept for the life of the customer’s agreement and seven years after, as evidence that the notice was given. Records of every other message, optional notices and emails asking to confirm an address among them, are kept for the life of the organization and 90 days after, or, where one is part of the evidence that a longer-kept notice was received, for as long as that notice. Notice contacts, the addresses a customer names to receive its notices, are kept for the life of the organization and 90 days after, or until any amount owed under the agreement is paid or written off, if that is later. Mail preferences are kept until you lift them. When a customer relationship ends, Customer Data follows the deletion windows in the DPA; a customer’s deletion instruction under the DPA does not reach contract and notice data, which we hold as controller. For a period measured by the life or end of a customer’s organization, the organization ends on the effective date the customer’s agreement ends, however it ends, even if we retain its database record, and each period measured from its end starts on that date. An organization we never approve ends when we decline or archive it, or when it, or the account that started it, is closed. An organization an individual account set up ends, while no customer has been approved for it, only when it, or that account, is closed; a customer application for it that we decline or archive does not end it (see Individual accounts above).

10. Your rights

You may have rights to access, correct, or delete your personal data, to receive it in a portable form, to restrict or object to processing, and to withdraw consent where processing rests on it. We honor these rights for everyone, voluntarily, wherever you live. They cover the data this notice describes — data Pharen controls (Section 3). For data an app built with Pharen collected about you, Section 2 applies: the app’s developer is the controller. If a customer named you to receive its organization’s notices, you may ask us to remove you; we keep the records of notices already sent to you, as Section 9 describes. You may also ask us to erase the email address you hold as a member of an organization (Section 3), or to remove your username, or the name you gave with a passkey, from the record of a membership that has ended (Section 9). You can remove a passkey yourself from your passkey page, except your last one; to have your last passkey, or all of them, erased, write to us, as Section 9 describes. If you hold an individual account, you may ask us to erase only its passkeys, which leaves the account with no way to sign in, or to close the account and erase what we keep about it. For a closure and erasure we do not wait the 90 days Section 9 gives a closed organization, but we keep the record of your acceptance of the Account Terms and the organization and membership records it names, with that membership’s history, as Section 9 describes. You can make that request even if you can no longer sign in: tell us the name of the organization the account set up and of the apps registered in it. That helps us find the account but proves nothing on its own, since such names are not secret: we confirm the request by sending a link to the account’s contact address, and before we give you a copy of your data we may ask for more. We do not find an individual account by an email address. If we cannot identify the account, or confirm that it is yours, we will say so.

To exercise a right, email hello@pharen.ai. We respond within the period the applicable law allows: one month where the GDPR or UK GDPR applies (extendable by two further months for complex requests, with notice), and 45 days under U.S. state privacy laws (extendable once by a further 45 days, with notice). We may need to verify that you control the email address or account the request concerns; an authorized agent may act for you with proof of authority. We will not discriminate against you for exercising rights. If we decline a request, we will say why within that period, and you may appeal by replying; the appeal gets a fresh review and an answer within 45 days, and if we deny it we will point you to the complaint route available where you live (in U.S. states with privacy laws, your state Attorney General). In the EEA or UK you may also lodge a complaint with your supervisory authority at any time — though we’d appreciate the chance to address it first.

11. Children

Neither this site nor the Service is directed to children under 16, and we do not knowingly collect their personal data. If you believe a child has provided us personal data, contact us and we will delete it. (For our customers’ own apps, the AUP applies a separate, stricter rule: no data of children under 13 without our prior written agreement — different subjects, deliberately different lines.)

12. Security

Data in transit is encrypted with TLS; data at rest is encrypted by our hosting providers; access is limited, credentialed, and logged; and customer data is isolated per organization by construction — every record is scoped, and unscoped access fails closed. The DPA’s security annex describes the measures in detail, and the architecture page explains the design. To report a vulnerability, email security@pharen.ai.

13. Changes & contact

When this notice changes, we update it on this page and identify its version and effective date. For a change that materially reduces protections, we give advance notice to organization contacts and, at the account’s contact address, to the holder of an individual account, and any additional notice to affected individuals that applicable law requires. We obtain any consent required by law before starting a new use; updating this page or notifying an organization is not that consent. Questions, requests, complaints: hello@pharen.ai, or write to us at the address below.