Privacy
Last updated 11 August 2026. This describes what melt-peer-review actually does today. Where the design intends more than the code currently does, it says so.
What this service is
An agent running on someone’s own machine edits their documents, then submits the list of changes here so a human can review them. The document itself never leaves that machine as a file — we receive text over the API, and we never write a document, apply a change, or assemble a new version. Accepting and rejecting is feedback sent back to the agent; the agent does the editing.
What the agent sends us
- The full before and after text of every file it edited — used once, at ingest, and then discarded (see below).
- A list of changes: the before text, the after text, and whatever optional metadata the agent supplies — a location label such as “§12.1 Governing Law”, a reason, which of your instructions caused it, a category, and the agent’s own risk estimate.
- The instructions you gave the agent, verbatim, if it includes them, and a title it generated for the review.
- Identifiers for the agent installation: a machine hint and an unverified user hint, usually a git email address. Unverified means exactly that — we never check it and it proves nothing.
What we keep, and what we throw away
The full document text is not retained. On submission, it is used to derive two things and is then dropped — it is never written to the database:
- a window of surrounding context for each change, roughly 1,500 characters on each side, snapped to paragraph boundaries;
- a one-way hash of each paragraph (truncated SHA-256), which lets us later notice that a file changed outside the review loop without keeping anything the text can be recovered from.
What we do store, for as long as the review exists: the change list (before and after text of each change), those context windows, the paragraph hashes, file paths, the instructions and title, every accept/reject decision and its timestamp, the derived verdict, any overall comment, and the name a reviewer types when submitting.
The honest version of the claim: discarding the full text meaningfully reduces how much of your document we hold — for a long document with a handful of changes it is a small fraction of it. It does not make what remains insensitive. The regions we keep are the edited ones, which are usually the parts that matter most.
What a reviewer’s browser tells us
Reviewers are never asked for a name, and there is nothing to sign in to. We set exactly one cookie of our own, described below, and load no third-party scripts, analytics, or advertising trackers on any page of this service.
Reviewer sessions: because there are no accounts, a review carries no proof of who did it. The design records a reviewer session alongside each review, holding four things and nothing beyond them: the IP address the request came from, the browser’s user agent string, an approximate location derived from that IP (city or country level, not a position), and a random first-party browser id kept in your browser so the same device is recognisable across visits. This is evidence, not identity: it records whether a review was opened from the same device as before and how many distinct devices touched it, never who you are. Nobody types a name, so nobody can claim to be someone else.
We will not do canvas fingerprinting or use any third-party fingerprinting service. IP address and approximate location are personal data, which is why they are disclosed here rather than mentioned in passing.
Separately from anything we record, our hosting and database providers (Vercel and Neon) keep their own request and connection logs, which include IP addresses, under their own retention policies.
We never train on your content
We do not use your documents, changes, comments, or review activity to train or fine-tune any machine-learning model, and we do not sell, rent, or share them with anyone else for that or any other purpose.
This service sends no part of your content to any model provider. It calls no AI API at all. The agent that produced the changes runs on your machine, under your control and its own provider’s terms — what that provider does with what you show it is between you and them, and outside what this page can speak to.
Who can see a review
The link is the grant. There are no accounts and no permissions in this version: anyone holding a review link can open the review, accept and reject changes, and submit it. Treat a link like a password and send it only to people you mean to have it.
- Links are random 256-bit tokens, scoped to a single review, and are stored only as hashes — we cannot reconstruct a link from our database. They expire 7 days after they are minted; the agent can mint a fresh one.
- The agent installation that submitted a review can read its own reviews and their feedback back, using a bearer token issued to it at registration. That token is also stored only as a hash.
- We can. Operators with database access can read everything described above in plaintext.
How long we keep it, and how to delete it
- Nothing is deleted automatically yet. A retention period has not been set, so a review stays until it is deleted deliberately. When a default retention window is chosen, it will be stated here.
- Deleting a review is immediate and unrecoverable. It removes the review and everything under it — revisions, changes, stored context, paragraph hashes, links, and any reviewer sessions. There is no soft-delete and no undo.
- The agent that created a review can delete it with an authenticated
DELETE /api/reviews/:idcall. The connector does not expose this as a tool yet, so today it is a direct HTTP request rather than something you can ask your agent for in chat. - Deleted rows may persist for a while in our database provider’s backups before those backups age out.
Security, stated accurately
- All traffic is over HTTPS.
- Data lives in Neon Postgres and is encrypted at rest to the extent Neon does that by default. We have added no application-level or per-column encryption of our own and hold no separate keys, so the content we store is readable by anyone with database access. If you need encryption where we cannot read the content, this version does not give you that.
- Agent tokens and review link tokens are stored as SHA-256 hashes, never in plaintext.
- The audit trail is a log, not an attestation. It records faithfully what happened — which changes were accepted or rejected, when, and the name the reviewer gave — and it is good enough to answer whether anyone actually reviewed something. It is not designed to resist someone deliberately faking a review, and it should not be relied on as evidence that a particular person reviewed a particular document.
Who processes the data
The application is hosted on Vercel and the database is Neon Postgres. Both process the data described above on our behalf. There are no other processors: no analytics vendor, no error-tracking vendor, no email provider, no AI provider.
Changes to this page
When what we collect or keep changes, this page changes with it, and the date at the top moves. It is meant to stay accurate rather than comprehensive — if something here reads as vague, assume the vague reading is the one we would be held to.
Contact
Questions about this page, or a request to delete something we hold: support@meltstudio.co.
If you are the person whose agent opened a review, you can delete it yourself at any time — ask your agent, or call DELETE /api/reviews/:id with its token. You do not need to email anyone to have a review removed.