Privacy policy & terms of use

ProofStudio (formerly Heinzelmen) — beta — policy version 2026-09-18.3, last updated 18 September 2026. Submitting a file requires ticking a box that accepts this document; the version you accepted is recorded with your job.

This is a beta release of a research service, offered free of charge. The maintainer bears the cost of running it out of goodwill and under tight resource constraints. There are no accounts, no fees and no service obligations. THE SERVICE IS PROVIDED “AS IS” AND “AS AVAILABLE”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, THE MAINTAINER ACCEPTS NO LIABILITY FOR ANY LOSS OR DAMAGE ARISING FROM USE OF, INABILITY TO USE, OR RELIANCE ON THIS SERVICE OR ITS OUTPUT. Where applicable law grants you rights that cannot be excluded by agreement, nothing here limits them.

Do not upload anything sensitive. By submitting a file you represent and warrant that it contains no personal data relating to you or to anyone else, no confidential information, no trade secrets, and nothing you are not fully entitled to share. Treat anything you upload as potentially public: parts of it may appear in published research reports, it may be processed by third-party AI providers that are not fully under the maintainer's control, and it is stored on infrastructure whose operators and their competent authorities may be able to reach it.

The licence you grant in what you upload

By submitting a file you grant the maintainer a perpetual, irrevocable, worldwide, royalty-free, transferable and sublicensable licence to store, reproduce, adapt, translate, analyse, excerpt and publish, in whole or in part, the submitted file and any output derived from it (including generated proofs), for the purposes stated below. To the maximum extent permitted by applicable law, you waive moral rights and rights of attribution and integrity in the submitted material as against the maintainer and the maintainer's licensees. You warrant that you are entitled to grant this licence. In plain words: you keep whatever rights you have, but you cannot later withdraw the service's right to keep, analyse and publish what you chose to send it. Publication is one-way — once material appears in a report it is public, copyable by anyone, and permanent.

Why information may be retained

The service reserves the right to retain submitted theories, generated proofs, email addresses supplied to the mail feature, IP-derived keys and technical logs, for these purposes:

(A) Research reporting. This is a beta release of a research project supported by public entities. The maintainer may be required to publish reports on it, and those reports may contain usage data and excerpts of submitted material and generated output.
(B) Security. A submitted theory file is executable code and is treated as hostile. The service takes containment measures, but must remain vigilant for threats those measures miss, which requires analysing usage — including retained submissions — after the fact. This protects the maintainer and other people on the Internet, not only the service.
(C) AI output monitoring. The service may use external large-language-model providers in its pipeline. The maintainer needs to be able to review what those models were sent and what they returned, to judge whether the output is useful and safe for the service and its visitors.
(D) The limits of that oversight. External AI providers are not fully under the maintainer's control. A provider that proves unsuitable can be removed from the candidate pool, but material already sent to one is thereafter governed by that provider's own terms, and the maintainer is not in a position to retrieve or delete it.

If you supply your own AI provider key

Where the service offers it, you may point the AI assistant at your own OpenAI-compatible provider by entering that provider's endpoint and your API key (“bring your own key”). If you do:

Where the operator enables it (the default when this feature is on), your key is sent to this server once and held only in the application server's memory so that refreshing this page does not ask for it again (a restart of that server forgets it). It is used solely to authenticate your requests to the endpoint you named, and is never written to our database, logs, backups or the archive. Retained access ends when you click Forget API key, when this session ends, or 100 minutes after this page stops contacting the server — whichever comes first (the assistant panel shows the times in force). Forgetting removes the server's retained access; it does not revoke the key at your provider or undo requests already sent, and it cannot guarantee that every copy is scrubbed from memory — so rotate the key at your provider after use. Where the operator has key memory switched off, the key is used only for the turn you send and is never held.
For that turn, the material the assistant would send — your source, the goal at your caret, and the Output pane — goes to the provider you chose. That provider is governed by its own terms and privacy policy, not this one, and is outside the maintainer's control.
You are responsible for the key you enter and for your right to use that provider. To the maximum extent permitted by applicable law, the maintainer accepts no liability for any loss, exposure or misuse of a key you supply. Treat a key you paste here as exposed and disable or rotate it after use.

This feature is optional and is off unless the operator has turned it on.

How long

What is reserved: up to one year, and that is a right rather than a promise. Submitted theories, generated proofs and technical records may be retained for as long as necessary for the purposes above, and in no case is any of it guaranteed to survive: the maintainer does not undertake to keep your file, your result, or anything else for any period, and may delete any of it at any time without notice. Equally, the maintainer is not obliged to delete it sooner than the year. Aggregated or anonymised data — which no longer identifies anyone — may be kept indefinitely.

Published material is permanent and public. Where submitted material or generated output is quoted in a research report, that publication is by its nature irreversible: it enters the public record, may be copied, indexed, archived and redistributed by people the maintainer has no relationship with, and may remain visible to a wide audience indefinitely. Publication cannot realistically be reversed, and a deletion request is unlikely to reach copies already made by others. Please treat anything you upload as something you are content to see published.

Why a year rather than an hour. A hostile submission is not noticed, analysed and — where it warrants it — reported to the appropriate authorities within an hour. Purpose (B) is unworkable on a timescale shorter than the incidents it exists to catch.

What is practised today is more conservative, and is described in the tables below. Current practice may move toward the reserved position without individual notice; the policy version above changes when this document does, and submitting again after a change means accepting the version then in force.

Reasonable technical and organisational measures are taken to protect what is retained. No service can promise that data held on a computer connected to the internet is safe from every attack or from every party with access to the infrastructure it runs on, and this one does not: see Where your data sits, and who else may reach it, below.

External AI providers

Submitted theories and material derived from them may be transmitted to third-party AI providers, who may process it outside the European Economic Area under their own terms. Your email address and your network address are never part of what is sent to them. Since what happens to content after it is transmitted is not fully within the maintainer's control, the practical protection is the rule above: please upload nothing personal, confidential or otherwise sensitive.

Where your data sits, and who else may reach it

This service runs on rented server infrastructure operated by third-party hosting companies. Concretely, and so that you need not deduce it from a mail header:

The service itself is hosted in Germany, on infrastructure rented from a German hosting provider. Your submission, your result and the retained records described above are processed there, inside the European Economic Area.
Email, if you choose to supply an address, is sent through a provider in Japan. That means your address, and the message we send you — which contains your result, and therefore material derived from your submission — are handled outside the EEA. Japan is the subject of an adequacy decision by the European Commission under Art. 45 GDPR, so the transfer rests on that decision and needs no further safeguard; we mention it because you are entitled to know which country your address travels to, not because it is unusual. Leaving the field blank avoids the transfer entirely, and costs you nothing but having to keep the page open.

Naming providers by country rather than by company is deliberate: the country is what determines your legal position, and it does not change when a contract does. That arrangement has consequences which are ordinary for online services but are stated here rather than left to be assumed:

Infrastructure operators have access. Whoever operates the physical machines, storage and backups is technically capable of reading what is stored on them, including copies retained in snapshots or backup systems. Measures can be taken to reduce what such access yields, and are; none of them can eliminate it, and no representation is made that they do.
Data may be disclosed under legal process. The maintainer, and independently any hosting, email or other provider involved, may be required to preserve or disclose data by a court, law-enforcement body, regulator, tax or national-security authority with jurisdiction over them. A demand of that kind may be addressed to a provider rather than to the maintainer, may be complied with without the maintainer's knowledge or involvement, and either party may be legally prohibited from disclosing that it happened. No undertaking is or can be given that you will be notified.
Jurisdictions differ. Infrastructure and providers may be located in, or subject to the laws of, countries other than your own, whose authorities may have powers of access that differ from those where you live.
Covert access cannot be excluded. Neither this service nor any comparable one is in a position to guarantee that data held on internet-connected infrastructure has not been accessed by a party with the capability and the legal authority, or the willingness to act without it.

The practical conclusion is the one stated at the top, and it is the only protection that does not depend on anyone's promises: treat material you upload as potentially readable by parties other than the maintainer, and do not upload anything personal, confidential or otherwise sensitive. Nothing in this section is unusual — it describes the normal condition of any service running on rented infrastructure — and saying it plainly is preferred here to implying a degree of protection that no operator can actually provide.

Legal bases and your rights (EU/EEA and UK visitors)

Where the GDPR or UK GDPR applies: processing tied to your submission rests on your consent (Art. 6(1)(a)), given by the tick box; abuse prevention, security analysis and service protection rest on the maintainer's legitimate interests (Art. 6(1)(f)). You have the rights of access, rectification, erasure, restriction, objection and portability, and the right to withdraw consent at any time — withdrawal does not affect processing already carried out, and is not able to retrieve material already transmitted to third-party providers. Transfers outside the EEA are covered in Where your data sits above: email is carried by a provider in Japan under the European Commission's adequacy decision for Japan (Art. 45), and material sent to external AI providers may be processed in countries determined by those providers, which is why that material never includes your email or network address. Your job's result link identifies your submission if you exercise these rights while data about it exists. You may lodge a complaint with your supervisory authority. These rights are statutory and nothing in this document limits them.

If you leave an email address (the field only appears when this deployment can send mail at all): you first prove the address is yours by typing back a six-digit code mailed to it — that code mail is a fixed sentence carrying nothing from any submission, it is the only thing an unverified address can ever receive, and the code and its ticket are discarded within minutes, used or not. The address itself is stored on the job row alone, is written nowhere else on this service, and is deleted from this service's database in the same write that records your result — before the mail is even sent. A failed send is not retried, because retrying would mean keeping the address. What survives for one day is a keyed hash of the address, so that a daily per-address cap can stop anyone using this service to flood a mailbox that is not theirs. Within this service the address reaches only the manager, which does the mailing: never the prover, the sandboxes, or any worker machine. Leaving an email also means your job keeps running when you close the page; that is its purpose.

Deleting it here does not delete it everywhere, and you should assume it is retained. Sending you a message necessarily involves at least one third-party email service, which is not fully under our control, as well as whoever provides your own mailbox. In particular:

The email service we send through — a provider in Japan, as noted above — records your address — ordinarily in its delivery logs, with a timestamp and the outcome of the delivery. Those records sit in an account that belongs to us, but under that service's arrangements and retention periods rather than ours. They may persist for an extended period, plausibly up to about a year, and we do not undertake to delete them; in practice we may be unable to.
Your own mail provider keeps the message, in your mailbox, for as long as you and they choose.

So please read our own deletion narrowly: it means that this service's database stops holding your address when your result is recorded. It does not mean the address has ceased to exist, and we would rather say so than imply otherwise. If you would prefer not to involve any of this, simply leave the address out — your result waits here either way, behind the same download link.

Current practice, in short. Your theory and its repair are held for 30 days after the job finishes and then erased from the live database, whether the job worked or not; there are no analytics, and two cookies: one counts your daily allowance, the other runs your 100 minutes session (and adds one to “Visits” the first time your browser sends it back, never merely by being issued). There are no accounts. The sections above state what the service reserves the right to do, which is broader — up to a year, and longer once anything is published. Both are true at once: the reservation is the ceiling, the tables below are today's floor, and the floor may move up to the ceiling without notice.

Every number on this page is substituted from the configuration that enforces it, so the page cannot come to disagree with the service. The tick box, the retention periods and the sign-in lifetimes are all read from the same constants the code uses.

Your theory file

The .thy file you upload is stored so the job can run and so you can download the result. It is processed inside a virtual machine of its own that is destroyed when the job ends. Thirty days after the job finishes, both your file and any repaired theory are erased from the live database — and the download link stops working well before that.

That window applies to every outcome. A search that timed out or found nothing is erased on the same clock as one that succeeded. It is current practice, not a commitment: the section above reserves up to a year, and anything published in a report is permanent.

What is recorded today, and for how long

What	Why	How long
Your theory, and the repaired one	To run the job, let you download the result, and allow later analysis of hostile submissions (purpose B)	30 days after the job ends; up to a year reserved
A number in a cookie	To tell you apart from other people on your network, so their submissions do not use up your allowance	48 hours
A key derived from your network	A floor under the daily limits, for callers who send no cookie	At most 48 hours
Daily counts	How many people came, and how many were helped, turned away or unlucky	Kept
A running total of website sessions taken up, and a start date	The “Visits” figure in the page header — sessions, not people: a refresh does not add one, a new 100 minutes session does, whether or not the box on the front page was ticked, and a robot that is given a session is counted like anyone else. A session is counted when a request from your browser arrives carrying the session cookie below, which is the only sign that the session reached you at all. Nothing is asked of the page and nothing extra is sent: if an answer of ours is lost on the way to you, the session it opened is simply never counted — the one your browser retries for is counted instead, once, when its own cookie comes back. Like the figure above it, this one is an APPROXIMATION and is meant as one: a browser that opens several tabs in the same instant is given a session for each, keeps one cookie, and can add more than one to the total before they settle. Making it exact would mean either having the tabs agree with each other through this browser's storage, or recording on every session which browser it belongs to — and neither is worth doing to a number in a page header. A browser that refuses the cookie is not counted at all	Kept as a tally per UTC day — a date, the word “visit” and a number, in the same table as the daily counts above — plus the one date the displayed total is added up from
Which sessions polled the page within the last 5 minutes	The “Online” figure in the header, an approximation: the session cookie's one-way hash and a clock reading, in the running server's memory only, so that one session with several tabs counts once	It stops counting about 5 minutes after that session's page last spoke to the service. The hash itself is dropped the next time the figure is worked out — the next visitor's poll, or anyone reading the counters; on a busy service within about a minute of that, when the leftovers are cleared in a batch — because nothing here runs on a clock of its own. On a service nobody is using it can therefore sit in memory until something happens or the service restarts. Never written down
An email address, if you give one	To send you the result	Deleted from our database when your result is recorded; retained by the email service we send through, on their terms — possibly up to about a year
A VIP token, as a one-way hash	To recognise the token without storing it	Until revoked

The cookie is a number and nothing else. Thirty-two random characters, meaning nothing, derived from nothing about you — a coat-check ticket. It exists because the daily limit used to be counted per network, which made everyone in one building a single visitor: the first person to try the service spent the whole department's allowance for the day. The cookie is what tells you apart from them. It is not read by any script, it is not sent anywhere else, and it is not joined to anything.

The network key is not your address. It is the surrounding block — a /24 for IPv4, a /64 for IPv6 — which is enough to stop one person appearing as a thousand and is not enough to pick you out of your university or your ISP. It is still kept, as a floor under the limits for callers who send no cookie back. Within 48 hours both are replaced by the only thing wanted from them: how many distinct callers there were that day.

The daily counts are numbers and nothing else: a date, a kind of event, and a total. Nothing in them points back to a person, a file or a theorem. The “Online” and “Visits” figures in the header are drawn from the same kind of number and are not a claim about unique human beings: “online” is how many sessions had their page contact the service in the last 5 minutes or so (a tab closed a moment ago may still be counted), and “visits” is how many website sessions have been taken up since the date shown — counted when a browser first sends the session cookie back, so a session that never reached anyone is never counted, and several tabs opened at once may add more than one. Both numbers are approximations. No address, fingerprint, account or theorem takes part in either.

What is not recorded

No accounts and no names. An email address exists only as described in the box above, and only if you choose to give one.
No tracking. The two cookies above do these jobs and no others: counting your own submissions against your own limit; running your session — which 100 minutes you are in, how long a job of yours may run, and which server-held API key is yours while you have one; and the two figures in the header — the session cookie's one-way hash is what “Online” counts, and sending that cookie back for the first time is what adds one to “Visits”. Neither cookie profiles you, and there is no advertising.
No analytics service and no advertising. The only third parties that can receive submitted content are the AI providers described above, when the pipeline uses them.

Your browser

These are stored in your browser, and nothing else:

hz_id, the cookie above — a random number, for 48 hours, so that your daily allowance is yours.
hz_visit, your website session — another random number, for 100 minutes, which is how long a session lasts. It is what the countdown in the menu bar counts down, what lets a job be stopped when its session ends, and, as a one-way hash, what the header's “Online” figure counts and what the “Visits” total is incremented by the first time your browser SENDS it back — not when it is issued, so a session that never reaches you is never counted. Your browser deletes it when the session ends; no script can read it.
hz_vip, and only if you use a VIP token, so a friend pastes theirs once rather than on every visit. This one never leaves your machine except when you use it.
hz_consent, and only once you tick the box on the front page: the version string of this document you accepted and the time you ticked it, in this browser's local storage, so that the box is not asked again on every visit. The tick stays valid for 180 days: after that, or after a new version of this document, it no longer restores acceptance and is removed on your next visit here (a page that is never opened again cannot remove it; clearing site data does, at once). It is a convenience, not a credential: it never leaves your machine and is not sent with any request; every request that carries or works on your source — a submission, the assistant's prover session, a synced account draft — names the version being accepted, and the server refuses it otherwise. File › Withdraw acceptance forgets it at once and locks the page again; withdrawing also stops a running check or proof search and closes the assistant's prover session.
proofstudio.entry.seen: one number — the time the short opening animation was last shown to you, read from your own computer's clock — so that it can come back on a later visit instead of never again. If it was last shown less than 24 hours ago the opening is skipped; after that, arriving fresh at this page plays it once more and replaces the stored time. A value this page cannot read as a time — the plain marker earlier versions of this page wrote, or anything else that ended up under that name — is replaced with the current time and does not bring the opening back. That number is the whole of it: no identifier, no visit count, no history, nothing about you and nothing about what you did here. It never leaves your machine, it is not sent with any request, and it is not tied to the version of this document, so a release of new features does not replay it — only a day going by does. Clearing site data removes it, and the opening plays on your next visit. If your browser refuses local storage the opening is skipped entirely rather than replayed on every visit, and it is skipped anyway if you have asked your system for reduced motion.
hz_split and hz_vsplit: where you dragged the pane dividers, so the layout you chose is the layout you get back. Two numbers, nothing more.
proofstudio.theme: which of the four colour themes you picked — one of the words light, warm, cool or dark and nothing else, so the page opens in the colours you chose. It is not tied to your account, your session, this document's version or anything you typed; it is not sent with any request; and anything else found under that name is ignored and the page opens in Light. Clearing site data removes it.
heinzelmen.draft.v1: a copy of your Source buffer, with its file name, the prover it was written for and the time, saved in this browser's local storage a moment after you stop typing, so that a closed tab or a crashed browser does not lose your work; it is offered back on your next visit here (you choose to restore or discard it) and is never sent anywhere. A blank buffer and an untouched example are not saved.
heinzelmen.resume.v1: the same Source buffer together with the prover you selected, kept so that an ordinary page refresh returns you to the same environment and text with no extra click. It is tied to this one tab (two tabs do not overwrite each other's work), stores even a blank buffer or an untouched example so those survive a refresh too, and like the draft never leaves your browser and holds no key, credential or permission. It holds a small, bounded set of records for your recent tabs, each keyed by an opaque random token for that tab so two tabs do not overwrite each other's work; a record contains your text, the prover's name, the file name shown in the header, the time it was saved, and the example's identifier if a worked example is loaded — nothing else. Restoring it sends nothing and does not tick the box for you. File › New, or Discard it next to the draft offer, clears this tab's record.

Clearing site data removes all of them. Nothing breaks if you do — you simply share a limit with your network again until a new cookie is issued, are asked to tick the box once more, and lose any draft or refresh-resume not yet downloaded. None of these is confidential against someone using the same browser profile, or against another script running on this page; browser storage is a convenience, not a guaranteed backup — download anything you must not lose.

Changes to this document

This document may change. The version string at the top changes with it, the tick box on the front page names the version being accepted, and the version accepted is recorded with each job. Submitting after a change means accepting the version in force at that moment; no earlier acceptance is stretched to cover a later text.

Removing something

While data about your job exists, the result link is enough to identify it — use it in any request under your rights above, and it is worth doing promptly, since your job's data may be held for up to a year. What is realistically beyond reach is content already transmitted to an external AI provider, or already quoted in a published report: publication is public and lasting by its nature, and a request to us is not able to recover a copy someone else has already taken.