Privacy policy.

What we never see

Your vault, and how the saving works

NeuralVault exists so you stop telling an AI the same thing over and over. Doing that means it has to remember, and remembering means writing things down. Here is where they get written.

Your vault is a folder of ordinary Markdown files on storage you control. When the assistant learns something worth keeping, it saves a note into that folder, on your disk, in a format you can open in any text editor. Nothing about that saving step involves us. There is no account required for it, no upload, and no copy on a server somewhere. Uninstall NeuralVault entirely and your notes are still sitting there as readable files.

We do not receive it, we cannot read it, and we hold no copy. That covers note content, note and file names, what you asked, and what a model answered.

What leaves your machine, from the application's own notice

The section numbers in this part and the next two (3.1 to 3.9, and the "section 1", "section 4" and "section 6" mentioned inside them) are the numbering of the application's notice, PRIVACY.md, not of this page.

NeuralVault collects no analytics and uploads no crash reports automatically. We do not measure which features you use, which notes you open, how long you use the application, or whether you use it at all. That is true whatever your settings say: none of it is collected by any code path in the product.

There is exactly one other signal, it is anonymous, and it is always on. Added 2026-09-01. Earlier versions of this notice said there was no telemetry at all, which was true when written and is why this paragraph replaced it rather than being added beside it.

The application sends a daily ping of four values, at most once a day:

• a random token generated on your machine,
• the application version,
• your operating system (windows, macos, linux or other),
• your edition (free, personal or business).

The private Test and Dev builds, which only invited testers and developers run, add one more word saying which of the two they are, so their numbers are not counted as the public build's. The public build does not send it. *

*Corrected 2026-10-14: the Test and Dev builds do send that word, but the receiving service does not read or store it, and the table that holds the daily ping has no column for it. So the word does not currently keep their numbers separate from the public build's.

That is the whole daily ping. Alongside it, while the application is open, it sends small batches (about every five minutes, when something has happened) of timings, a count of which screens were opened, and a count of problems, each under a fixed name from a list built into the application, tied to the same random token. Section 3.9 lists every name. There is no account id, no email address, no vault path, no note count, no prompt, no model name and no machine identifier. The token is random rather than derived from anything about your computer, so it identifies an installation and nothing about you; a token computed from a machine id would be stable and reversible, which is an identifier wearing a disguise. It is stored in your own settings file.

It is always on, and there is no switch for it. We use it to check that every feature works and to spot sudden spikes. Remove my data deletes the token, and a new one is generated at the next launch, so the two periods cannot be joined up. It is recorded as on again each time the application starts, and that includes an installation that had it switched off before 15 October 2026.

The data is write-only from your side and from ours: there is no way to read a ping back against an installation, which is what makes the count anonymous rather than merely unlabelled.

Version 1.0 of this notice also said the application "does not phone home". That claim is withdrawn, because account-based licensing made it false. Every install, the Free edition included, is signed into an account and contacts one server, ours, to renew the licence it is running under: a full renewal about every four hours and a short keep-alive about every ten minutes while the application is open. That request carries a sign-in token, a device identifier, the application version and the build channel. It carries nothing from your vault, and it is not analytics. Section 3.6 sets out exactly what it sends, what it does not send, and what happens when you are offline.

Eight things can send data off your machine:

1. A cloud AI Model Provider you configure. Section 3.1.
2. A sync server you configure. Section 3.2.
3. A connector you explicitly connect. Section 3.3.
4. A web page the assistant fetches, to a site you have approved. Section 3.4.
5. A bug report you choose to file. Section 3.5.
6. The licence check, on every install you have signed into, the Free edition included. Section 3.6.
7. An update check, when you press the button for it. Section 3.7.
8. The anonymous usage telemetry, which is always on. Section 3.9.

The first five are things you do yourself, one at a time, and none of them happen on their own. The sixth repeats on a schedule once you have signed in, which is why it gets its own section and why the sentence about phoning home had to go. The seventh happens only when you press it. The eighth repeats on a schedule too.

Everything else stays on the device. Versions 2.2 to 2.4 of this notice listed seven, not eight, because the usage telemetry in section 3.9 was not yet running. It is now built, and it is always on.

Usage telemetry (always on)

Changed 2026-09-07. This section used to say "not yet available". It has now been built, and it ships from version 1.1. What it collects is exactly what this section already described before any of it existed, which is why the description below has not needed to change: it was written first, on purpose, so the commitment came before the code rather than being fitted to it afterwards.

It is always on, and there is no switch for it. The first-run setup screen says so in one plain sentence: NeuralVault sends anonymous app-health and usage counts so we can check every feature works and spot sudden spikes, with no conversations, notes, file names or account details, and nothing that identifies you or your machine. Settings, under Privacy, shows what is sent. It is recorded as on each time the application starts, including for an installation that had it switched off before 15 October 2026.

Version 1.0 of this notice promised there would never be telemetry at all. That promise is narrowed here, in the same way the "does not phone home" sentence was withdrawn in section 1: the honest version is not "never", it is "only what this section describes".

It has been always on since 15 October 2026. Before that date it was off until you switched it on. There is no reminder that nags, and it does not degrade the application in any way.

If you are signed in, the setting is also recorded on your account. The application sends it to your account when it records it as on, and reads your account's value each time it renews its licence (section 3.6). The application records it as on again each time it starts.

What it contains. Anonymous, aggregate product usage: which features were opened, counts and durations, the application version, the operating system family, and whether an action succeeded or failed. It is tied to a random identifier generated on your device, which Remove my data resets, and which is not derived from your account, your email, your licence or your hardware.

It is anonymous, and that is built in rather than promised. There is no user identifier of any kind in what is sent. No account identifier, no email address, no licence key, no IP address, no device fingerprint, and no hardware identifier. The only identifier is a random 32-character token generated on your own device from the operating system's random source. It is not derived from your hardware, your account or your licence, there is no link from it to any account record on our side, and Remove my data resets it. Two installations by the same person are two unrelated tokens, and we cannot tell that they are the same person.

Exactly what is sent, in full. A daily ping (the token, version, operating system and edition, at most once a day), and, while the application is open, small batches of the three kinds of thing below, about every five minutes when there is something to send. Three kinds of thing, and nothing else. (Two until 2026-10-07; the problem counts below are the third. It is always on, still fixed names only, and it adds no content and no new identifier.)

Timings. A duration in milliseconds and whether it succeeded, for each of these:

Feature counts. That one of these screens was opened, and nothing about what you did there: chat, search, notes, canvas, graph, calendar, agents, library, settings, security, wire, billing, onboarding, import, export.

Problem counts. Added 2026-10-07. That one of these things happened, and nothing about why or what you were doing. Each is a fixed name, counted once each time it happens:

An error is counted by its kind only. The kind is one of the six above, never the message, never the file, never the name of the thing that failed. We cannot tell from this what you were doing or what the action was.

Alongside each of those: the application version, the operating system family (one of four values), the edition, and your random install token. On the private Test and Dev builds there is one more word, test or dev; the receiving service does not currently store it. That is the complete list.

There is no field for anything else, so nothing else can be sent by accident. The records that are stored have no column for a note name, a file path, a folder, a search term, a prompt, a model output, an error message, or the content of anything. Every name above comes from a fixed list that is checked three times independently: by the application, by the receiving endpoint, and by a constraint on the database column itself. An unexpected value cannot be stored even if the first two checks were wrong. This was tested by deliberately sending a note title and a file path in place of valid names and confirming that nothing was stored.

Why we ask for it, and what we promise. The purpose is to find problems before you have to report them, and to fix them. That is the whole of it. It is not to build a picture of you, and it could not be used to build one even if we wanted to, for the reasons set out above.

Two of those sentences are different in kind and it is worth separating them, because one is checkable and one is not. What can be collected is a property of the database, and you or anyone else could verify it: there is no column for your content, your identity or your network address, so that data cannot arrive here whatever any future version of the app does. What we do with what we collect is a commitment from us, and you have only our word for it. That word is: we will never sell this data, we will never pass it to an advertising or attribution service, and we will never use it for anything other than making the software better. If that ever changes it will be a new opt-in, described here before it ships, and off until you turn it on.

What it cannot show us. Counts carry no ordering, no session and no sequence *, so what any one person did cannot be reconstructed from them. We can see that the search screen was opened a thousand times across everyone who opted in. We cannot see who, in what order, or what they searched for.

*Corrected 2026-10-07: that was too strong. Each record we store carries the exact time it was received, and all records from one install share its random token. Someone with access to the database could therefore put one install's records in time order, and see, for example, that an engine restart came shortly after a particular screen was opened. They still could not see what you did, because there is no content in any record, and they could not tell who you are, because the token is not linked to you. But "no ordering" was not true, and this notice now says so. Records are deleted after 30 days.

**Updated 2026-10-07, after the correction above: from the database change numbered 20261007160000, the time kept on each record is rounded down to the hour. Records from one install can still be grouped by hour, but they can no longer be put in order inside an hour, so an engine restart a minute after a screen was opened cannot be seen. The exact-time wording in the correction above describes records stored before that change is applied; older records are rounded to the hour at the same time.

What it never contains. No vault content of any kind. No note names, file names or folder paths. No prompts, no model outputs, no chat history. No agent inboxes, no audit trail entries and no permission settings. No account identifier, no email address and no licence key. No IP address retained alongside the payload: the receiving function does not read the sender's address and no table has a column for it, although, as with any request, our hosting provider can see it. If a future version needs anything outside that list, it will be a new opt-in with its own switch, described in this notice before it ships.

Where it goes. To our own infrastructure, as controller, with the same processor arrangements set out in section 6. We will not sell it, share it for advertising, or pass it to an attribution service, and no advertising or attribution SDK will be added to the application.

How long it is kept. The timings, the screen counts and the problem counts are deleted after 30 days by a nightly job, and the time on each is rounded down to the hour when it is stored. The daily ping records (token, version, operating system, edition and the exact time received) are not on that schedule, and we have not yet set a deletion period for them. They hold nothing that identifies you. The correction notes above say records are deleted after 30 days and times are rounded to the hour; that is true of the timings, screen counts and problem counts, and not of the daily ping records.

This section was rewritten in version 2.5 to say what the application sends now, rather than what it was intended to send, and the list in section 1 gained its eighth entry in the same change.

Your AI prompts: the one thing that depends on your setup

NeuralVault talks to AI models, and those models run somewhere. There are two ways to arrange that, and they have genuinely different privacy consequences. This is the most important distinction on this page, so it is not buried in a paragraph.

Our routing is not available yet. No version of NeuralVault you can install today offers it, and nothing is routed through us at present. It is described here in advance so the change is visible before it happens rather than after. When it ships, this section will state exactly what is retained and for how long, in the same change that makes it available. Bringing your own keys will remain a supported way to use the product, not a temporary concession.

Whichever you choose, sync and connectors stay off until you set them up, and the application asks before contacting a web address you have not approved. The application's own notice describes each of those.

If you run Business, with a team

Everything above still holds: the vault is on hardware you own and we receive none of it. What changes with a team is that more than one person can reach it, so it is worth saying plainly who can see what inside your own company.

Per-user accounts and role scoping are in development and are not in the application yet. Business is designed so that access is scoped per role and per folder, and checked on every read. An agent can only open a folder that its own configuration lists, that your role permissions allow, and, where a plugin is involved, that the plugin was granted. Those conditions are combined with AND, not OR, so widening one of them cannot widen the others: a permissive role setting still cannot reach a folder an agent was never given. A refused read fails and is recorded; it does not quietly return nothing.

Cortex coordinates, and is bound by the same rule. It hands work to the right agent by writing the assignment into that agent's own inbox inside your vault, and agents can pass findings to each other the same way. All of that traffic is notes in your own vault, on your own hardware. It is readable by you, it is part of the record, and none of it is sent to us.

We are not a party to any of it. We do not hold your roles, your folder permissions, your inboxes or your audit trail, and we cannot inspect, override or recover them. That also means recovery is yours: if you remove someone's access or delete a vault, we have no copy to restore it from.

What this website collects

When you use the contact form

Your name and email address, which are required, plus company name, area of interest and your message, which are optional. Used solely to reply to you. A hidden anti-spam field that real visitors never see: if it is filled in, we discard the submission.

To stop the form being used to flood us we limit submissions per connection per hour. That means recognising a repeat sender, so we store a one-way scrambled fingerprint of your IP address and a count for 24 hours, then delete it. The address itself is never stored, the fingerprint cannot be reversed, and it is never linked to what you sent.

When you report a problem

The report form on our Report a problem page asks for the kind of problem, your name and email address, what happened, and, optionally, what you expected, how to make it happen again, and your app and Windows versions. It attaches nothing from your computer. Please do not paste passwords, API keys or the contents of your notes into it.

The form sends your report through the same route as the contact form. It is saved with contact messages in our database, we are emailed a copy at our contact address, and you get an automatic receipt. The same anti-flood fingerprint described above applies. It is kept for the same time as an enquiry: see section 7.

Two other ways to report exist. A report sent from inside the app is described in the application's own notice, PRIVACY.md, and the app shows you everything it would send before anything leaves your machine. If you use the public GitHub tracker instead, anything you file there can be read by anyone, and it is covered by GitHub's privacy policy, not ours.

When you join a waiting list

Two separate lists, for Personal and Business. Each collects your first name and email address, plus company name on the Business list, which is optional. We record which list you joined so we only tell you about the product you asked about.

You get an email when the product is ready and when there is a significant update. Nothing else: no newsletter, no marketing sequence, no sharing or selling. Every email includes a way out, and you can ask us to delete you at any time without giving a reason.

When you subscribe to a newsletter

There are three separate lists: AI Proficiency Training, NeuralVault releases, and general updates. You choose which ones you want when you sign up, and you only ever receive the ones you chose. We keep your email address, which lists you picked, the date you signed up and which page you signed up from.

Nothing starts arriving until you confirm it. Signing up sends one email asking you to click a link, and until you do, your address sits in a separate pending record and receives nothing else. Ignore it and that record is deleted after seven days. This is deliberate: anyone can type anyone's address into a public form, so we ask the mailbox rather than trusting the form. The one exception is when you are signed in to an account and subscribe using that account's own confirmed email address, because that address has already been proved.

We hold your choices so that we can send you less. Every email has a link that opens a page where you can tick or untick individual lists, or stop all of them at once, without signing in or emailing us. That link identifies your row by a random token rather than your email address, so your address never travels in a URL. We do not sell or share any of it, and you can ask us to delete you entirely at any time without giving a reason.

The one exception, stated plainly: if something applies to everyone regardless of preference, such as a change to this policy or a security notice, we may send it to every subscriber. That is not marketing and it is the only case where your choices do not limit what arrives.

When you download the app

We count downloads. The link goes through our own server, which records only which edition and platform you asked for, the version we served, the site that sent you (the domain, never the full address), and the time. Nothing that identifies you: no IP address, no browser fingerprint, no cookie, no visitor id.

It is a count of files fetched, not of people. We cannot tell whether two downloads are two people or one person on two machines, and we are not trying to find out. If the counter fails, the download still works: it was built that way deliberately, so a broken statistic can never stop you getting the software.

When you buy a subscription

Stripe takes the payment as merchant of record, which means Stripe is the seller of record and handles VAT registration, collection and remittance. You enter your card details into Stripe's checkout, not ours. We never see or store your card number. We receive Stripe's references for the customer and subscription, and the order records UK tax law requires.

We hold your account in Supabase: your email address and a hash of your password. We never hold the password itself, and nobody here can read it or recover it, which is why a forgotten one has to be reset rather than looked up. You can create that account on this website or inside the app; either way it is the same single account. Alongside it: your subscription record, the devices that have run on your account, and a short-lived record of which are running right now.

Creating an account sends you one email. It contains a link that confirms the address is yours, and the account cannot be used until you click it. That is a security step rather than marketing: it stops somebody signing up with an address that is not theirs. We do not add you to any mailing list, and there is no marketing opt-in on the form because there is nothing to opt in to.

On the device identifier. A random value generated per installation. It is not a hardware serial number or a fingerprint of your machine. Its only job is to mark a session slot so the limit on simultaneous copies can be held, and those records delete themselves once a machine stops checking in. So replacing, reinstalling or losing a device costs you nothing. A hardware fingerprint would do the same job and would also identify your machine across uninstalls and to anyone else who saw it. We chose the value that does not.

Sign-in records. Our authentication provider keeps its own audit log of sign-in events, including the IP address each came from. That is how account security incidents get investigated.

The licence check

Built and running. Version 2.4 and earlier labelled this section "Not built yet". That label was true when it was written and stopped being true when the licence service shipped. This section now describes what the application does, and section 9 records the change.

It runs on every install that has been signed into, the Free edition included. Every install needs an account, so every install makes this request. Signing out stops it, and the application does not make the request while you are signed out. A request that arrives without a valid sign-in is refused by the service. There is no anonymous ping and no first-run registration.

What is sent. One HTTPS request, with a short JSON body and two sign-in headers. The body holds:

• A device identifier. A random value, generated on this installation the first time it is needed and then stored on the machine in ~/.neuralvault-device-id. It is not a hardware serial number, not a MAC address, not your Windows account name, and not your computer's name. Its only job is to tell one running copy of NeuralVault apart from another on the same account.

  We limit how many copies run at the same time, not how many machines you install on. Install on as many as you like. The identifier is what makes that possible: it marks a slot as taken while you are using that machine, and the slot is released on its own once that machine stops checking in, so nothing accumulates against you and a lost or reinstalled computer costs you nothing. We also keep a plain list of the devices that have run on your account, so support can answer "which machines is this" when you ask, and so you can see and remove them yourself.

• The application version, so that a licence is not issued to a build that cannot use it.

• The build channel the application was built as: stable, beta, test or dev. The service uses it to decide whether your account may run that build.

• On the short keep-alive request described below only, a flag saying it is a keep-alive.

The headers hold the project key that identifies our service, which is the same in every install, and your sign-in, as a short-lived access token. The application keeps your longer-lived sign-in token in the operating system's credential store (Windows Credential Manager, under the service name NeuralVault, alongside your provider API keys), and that token is not written to a plaintext file in your home directory. Before each request the application exchanges that stored token with our authentication service for the short-lived one, which is a separate request carrying the stored token and nothing else.

Our licence function does not read the IP address a request came from and does not store it in any table. As with any request across the internet, our hosting provider receives it and can see where it came from and when. Section 6 says what we keep.

What is not sent. No vault content. No note names, file names or folder paths. No prompts, no model outputs, no chat history. No list of which features you used, how often, or for how long. No usage analytics of any kind, and no crash data. The licence service cannot answer the question "what does this person use NeuralVault for", because nothing in the request tells it.

How often. While the application is open and online it asks for a full renewal about every four hours. Between renewals, about every ten minutes, it sends the shorter keep-alive request, which goes through the same sign-in and subscription checks and renews your running slot but issues no licence file. The keep-alive exists because the service holds a running slot for 30 minutes after the last check-in, and a four hour gap would otherwise let a second computer take the slot of one that is still open. A renewal or keep-alive that fails is tried again at the ten minute interval. Not on every action, and there is no connection held open between checks.

Where it goes. To our own licence service, which runs on Supabase as our processor. Nothing about the check passes through any other third party, and no advertising, analytics or attribution service is involved at any point.

What the service records. For each full renewal that issues a licence: the licence identifier, your account, the device identifier, the edition, the subscription tier, any add-on features, the build channel, when the licence expires and when it was issued. For each renewal or keep-alive: the device's entry in your list of devices, with the time it was last seen, and a running-session record that expires 30 minutes after the last check-in and is removed on its own. For every call to the function, a timing record of the function name, the status code and how long it took, with no account, no request content and no device identifier, kept for 30 days. Section 6 gives retention for the rest.

What comes back. A licence file, signed by us, valid for seven days and never longer than the period you have paid for, written to ~/.neuralvault-license.json. It names your account, the device identifier, the edition, any add-on features, the build channel and the expiry. The application then checks that signature on its own machine against a public key compiled into the build. The same response carries your account's telemetry choice, which section 3.9 describes. Using NeuralVault needs no network call for each action. Only renewing the licence does.

If you are offline. The licence you already have keeps working until its seven days run out, and any successful check at all, however brief the connection, puts a full seven days back. If you stay offline past the seven days, or the service refuses a renewal, the licence expires and the application stops running beyond its sign-in, status, update and bug report screens until a check succeeds. It deletes nothing, and your vault is untouched: your notes are your files on your disk, and no licence state can reach them. When your account has no paid subscription and a check does succeed, the service issues a Free edition licence the same way, as long as the release channel for your build is open. Versions 2.4 and earlier said that an expired licence dropped the application to the Free edition and did not lock it; that was the behaviour before builds were required to hold a signed licence to run, and it is not the behaviour now.

When you simply browse

Our host records standard technical information needed to serve and secure the site, including your IP address, pages requested and browser type. We also run cookieless analytics: see section 4. To choose which currency to show prices in (dollars, euros or pounds), the site reads the country of your IP address, which our host supplies with each request, and nothing from that lookup is stored. If you pick a currency yourself, your choice is remembered in your browser's local storage under the name pt-currency, on your device only.

Who else sees your data

We do not sell or rent personal data, and we do not share it for anyone else's marketing. It reaches these providers only because they run parts of this business.

Each processes data under its own terms. If we change a provider, we change this page in the same commit.

Cookies

This site does not use cookies to track you. We removed Google Analytics in August 2026 precisely because it set cookies and shared what it collected with Google for Google's own purposes, which we were not willing to ask you to accept just so we could count visits.

• Our analytics set no cookies. Vercel Analytics and Speed Insights count page views and measure load speed without storing anything that identifies you.
• Stripe Checkout sets cookies needed to process payment and detect fraud, on Stripe's own pages, only if you begin a purchase.
• Signing in sets cookies that keep you signed in, and only if you have an account and use it. They are strictly necessary for a service you asked for, which is the exemption the rules below describe, and they are not used to track you. They hold a short-lived session token and its refresh token, nothing else. Signing out clears them, and they expire on their own if you do not.
• Page visits, only if you accept analytics. We record the page address, the site you came from, the time, and a random number made in your browser and kept in its local storage under the name pt-visitor. No IP address, no browser details, no name or email and no link to an account, and never on sign-in, account or admin pages. Without your acceptance nothing is recorded and no number is made. Choosing no in Cookie settings in the footer stops it and removes the number from your browser.
• No advertising, profiling or cross-site tracking. None at all.

There is a cookie choice banner. Your choice is stored in your browser's local storage under the name pt-consent, on your device only. It gates the page-visit record described above, and nothing else. You can change your choice at any time with Cookie settings in the footer. The UK rules are the Information Commissioner's guidance on cookies and similar technologies.

Separately from cookies, if you choose a currency the site remembers it in your browser's local storage under the name pt-currency, on your device only. Section 2 describes it.

Our lawful basis, per purpose

Stated per purpose rather than in one lump, because that is what tells you which rights apply to which data.

Where the basis is legitimate interests you have a right to object, and section 9 says how. Where it is consent, you can withdraw at any time, and withdrawing does not affect anything sent before you did.

Where your data goes

Supabase holds the database in Ireland. Vercel, Stripe and Resend process data in the United States. Sending your data to any of them is a transfer out of the UK, the Irish one included, because the rule is about data leaving the UK rather than leaving Europe.

UK law allows a transfer like that on one of three routes: it is approved by regulations, it is covered by appropriate safeguards, or a specific exception applies. Ireland is on the first route, because the regulations approving transfers to the European Economic Area remain in force, so no extra contract is needed for it. For the United States we rely on the second: the safeguards each provider commits to in its own data processing terms, which are standard contractual clauses with the UK Addendum, or the UK Extension to the EU-US Data Privacy Framework where that provider is certified under it.

How long we keep it

• Enquiries: while we deal with your enquiry and for as long as we have an active business relationship, then deleted.
• Waiting lists: until the product ships and we have told you, or until you ask to be removed.
• Newsletters: until you unsubscribe. After that we keep the record of your address and the date you opted out, so that we can prove we honoured it and so nothing later adds you back by accident. Ask us to erase you and it goes entirely.
• Unconfirmed signups: seven days, then deleted automatically. If somebody enters an address and never confirms it, nothing is ever sent to it again and the record removes itself.
• Accounts and subscriptions: while your account exists. Closing your account starts a 30-day grace period. Everything keeps working during it, and you can cancel the closure with one click. When it ends, an automatic job that runs daily deletes the account and its device and session records, keeping only what tax law requires. Closing is refused while you own an organisation or have an active, past-due or trialling subscription: transfer the organisation or cancel the subscription first.
• Live session records: they delete themselves once a machine stops checking in.
• Order records: six years, which UK tax law requires. We cannot delete these on request within that period.
• Analytics: Vercel Analytics' default retention. Aggregate counts, not a record of you.
• Download counts: kept indefinitely as a running total. There is nothing in them to delete: no row identifies a person, so none can be traced back to you even by us.
• Page visits: thirteen months, then deleted automatically. Each record is only a page address, where you came from, a time and a random number held in your browser. If you want yours deleted sooner, send us the number stored under pt-visitor in your browser's local storage and we will delete the matching records.
• Server logs: kept short-term by our host for security and diagnostics.

How we protect it

The site is served over HTTPS. Access to enquiry data is limited to the people who need it to answer you. Card details never reach our systems at all. We ask for the minimum we need rather than everything we could get, which is the single most effective protection there is: data never collected cannot be lost.

Your account records are locked to your account at the database. Every table holding customer data has row-level security switched on, so a request carrying your sign-in can only ever return your own rows, and one carrying no sign-in returns nothing. The key published in this website's code grants no access on its own: it is designed to be public, and it is the database rules rather than the secrecy of that key that decide what anyone can read. The administrative key that would bypass those rules is not in this website, not in the app, and not in the code we publish.

Sign-in and sign-up are rate limited by our authentication provider, per address and per account, so repeated guessing is slowed rather than unlimited. Passwords are stored only as a hash. We deliberately give the same answer whether an email address has an account or not, on sign-in, sign-up and password reset alike, so that these pages cannot be used to find out who has an account with us.

Your rights

Under UK GDPR you have the right to be told what we hold and receive a copy, to have inaccurate data corrected, to have data deleted, to restrict how we use it, to receive it in a portable format, and to object to processing based on legitimate interest. Where we rely on your consent, you can also withdraw it at any time. You will never be charged for exercising these rights and we will not treat you differently for it.

To exercise any of them, email contact@perpetualtechnologies.co.uk. We aim to respond well within the one month the law allows.

If you are unhappy with how we handled your data you can complain to the Information Commissioner's Office at ico.org.uk. If you live in the European Union or the European Economic Area you can also complain to the data protection authority in the country where you live. We would ask you to raise it with us first so we have the chance to put it right.

Children, automated decisions and changes

Children

This site is aimed at businesses and is not directed at children. We do not knowingly collect personal data from anyone under 16. If you believe a child has sent us personal data, contact us and we will delete it.

Automated decision-making

Nobody is scored, ranked or profiled by a machine on this website, and we make no automated decision producing a legal or similarly significant effect about you.

Whether the licence check described in section 2 succeeds is decided automatically from your subscription status and how many copies are already running. If you stay offline past the seven days, or the service refuses a renewal, the licence expires and the application stops running beyond its sign-in, status, update and bug report screens until a check succeeds. It deletes nothing, and your vault is untouched. If you think a refusal is wrong, email us and a person will look at it.

Changes to this policy

If what we collect or who processes it changes, we update this page and the date at the top, in the same change that alters the behaviour. We do not make quiet changes.

• 14 October 2026: the NeuralVault part of this page now follows version 2.5 of the application's notice: the optional usage telemetry is built and described in full, and the licence check is described as built and running.
• 8 October 2026: named Cloudflare Turnstile and Vercel BotID in the list of who else sees your data.
• 8 October 2026: rewrote how account closure works: a 30-day grace period you can cancel, then automatic deletion, refused for organisation owners and for active subscriptions.
• 8 October 2026: added a section on reporting a problem through the website form.
• 8 October 2026: made the cookies section match whether the cookie choice banner is showing, and noted the pt-consent and pt-currency browser storage entries.
• 8 October 2026: added your right to withdraw consent and your right to complain to the data protection authority where you live, if that is in the EU or EEA.

Contact

Questions about this policy, or about anything we hold: contact@perpetualtechnologies.co.uk, or through our contact page.

Perpetual Technologies AI Ltd, company number 17330522, registered in England and Wales. Registered office: 67 High Street, Shoeburyness, Southend-on-Sea, SS3 9AW.