Author interview
PerfectPaper asks targeted questions about design decisions and fixed constraints before review, then carries your answers into the critique.
SOLUTIONS
How PerfectPaper keeps your manuscript out of model training: its own code trains on nothing, providers are bound by contract terms, and every processor is named.
Affiliations
Current platform
PerfectPaper now carries context from setup through research, revision, and export—without turning the paper into a generic writing prompt.
Prepare
PerfectPaper asks targeted questions about design decisions and fixed constraints before review, then carries your answers into the critique.
Search the journal catalogue, choose up to three targets, and compare compatible open-access journals before the review starts.
Brief up to three custom reviewers, declare ground truths, attach instructions, and choose standard or deep-research depth with specific tools.
Investigate
Specialist reviewers inspect the full paper in context, including figures and tables—not isolated paragraphs.
Deep-research reviewers can search the web and scholarly literature, inspect sources, and attach vetted citations to research-backed findings.
The reading room shows which review areas are working, which findings have arrived, and when a research step could not complete.
Revise
Move between each comment and its passage, read your paper as you wrote it in Word, filter feedback, and discuss any finding.
Preview suggested revisions, apply accepted changes, keep an edit history, and reverse a change without losing the review trail.
Export the revised paper and saved feedback as DOCX, annotated PDF, or print view, and prepare an anonymous copy for blinded review.
PerfectPaper never uses your content to train a model. Not the paper, not the model’s reasoning, not its reply, not the derived metadata. Three layers hold that guarantee up: PerfectPaper’s own code, which trains nothing; the contract terms binding the model providers that process your text; and a published list of every processor that receives any part of your manuscript.
That sentence is deliberately unqualified. The rest of this page explains what holds it up, because a guarantee a reader cannot inspect is only a slogan.
“Trains on your data” is four commitments wearing one sentence, and a vendor can keep one of the four while breaking the other three without writing anything false. The four are: whether your text updates model weights, whether it is kept as an evaluation or benchmark example, how long a copy survives after you delete it, and whether a person is permitted to read it.
GDPR Article 4(2) defines processing as “any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission” — one defined term covering all four operations equally. A no-training sentence answers the first of them and is silent on the other three unless the page it sits on goes on to speak.
PerfectPaper answers all four. No weights are trained or adapted. The evaluation corpus holds no customer work. Your manuscript and review stay in your account until you delete them. And human access at the model providers is governed by the contract terms described below rather than by anything in PerfectPaper’s code. The procurement checklist puts the same four questions in a form you can send to any vendor, and its fourth question — whether content is used to build evaluation or benchmark datasets — is the one most often left unanswered in a vendor reply.
It has to answer four separate questions to mean anything: whether your text updates model weights, whether it is kept as an evaluation or benchmark example, how long a copy survives after deletion, and whether a person may read it. A sentence that answers only the first is silent on the other three — read the rest of the page it sits on before trusting it.
No. A no-training promise is compatible with a person at the provider reading flagged content for abuse monitoring, with retaining your text as an evaluation example, and with a different default for a different account tier. PerfectPaper’s own answer to all three is in the layers below; a vendor’s silence on them is the gap to ask about.
No — they answer different questions. Not training means your text does not update model weights. Storage is a separate question: PerfectPaper keeps your manuscript and review in your account, encrypted at rest, until you delete them. A vendor can truthfully claim one while saying nothing about the other.
Not through PerfectPaper. PerfectPaper’s own code trains nothing, and the model providers processing your text are bound by commercial and cloud contract terms rather than by a setting. Material you have already published as a preprint is a separate exposure that no reviewing tool controls.
PerfectPaper trains no models and fine-tunes none, so no customer manuscript is training data by construction.
The evaluation corpus used to test the review engine is worth naming precisely, because this is where products most often keep customer work quietly. PerfectPaper’s corpus contains eight synthetic papers written for the test harness — six carrying deliberately planted flaws and two clean controls that test for false positives — and no customer manuscript at all. When the engine’s accuracy is measured, it is measured against papers written for that purpose.
Each of the six flawed papers is paired with a ground-truth manifest naming the flaws planted in it, the section each flaw sits in, the category the engine should file it under, and the minimum severity a correct review should assign. One manifest records a single planted defect: the methods section states that all 240 simulated datasets entered the primary analysis while the results table labels that same analysis n = 224 with no exclusions explained, expected category “consistency”, minimum severity “major revision”. The author line on every paper in the corpus reads “Anonymous for review”, because there is no author to name.
An evaluation corpus deserves that much scrutiny because it is the one place where a no-training sentence stays literally true while customer work is retained indefinitely. Keeping an interesting manuscript as a regression fixture updates no weight and trains nothing, and a team that does it can go on saying it does not train on customer data. Ask the question separately, of every vendor, including this one.
The same reasoning covers the feedback you give. The dismiss and address actions you take on a comment are product state — they change what your review looks like when you return to it. Nothing converts them into a training signal, because there is no model being trained to receive one. Fine-tuning, adapter training and preference tuning are absent for the same structural reason: PerfectPaper runs hosted models it does not modify. Custom reviewer agents are instructions you write, up to 6,000 characters each, not weights learned from your corrections — a distinction worth knowing, because “the tool learns from you” is the usual description of the opposite architecture.
No. PerfectPaper trains no models and fine-tunes none, so your manuscript cannot become training data by construction, not by omission. The evaluation corpus used to measure the review engine’s accuracy holds eight synthetic papers written for the test harness — six with planted flaws, two clean controls — and no customer manuscript at all.
No. The engine is evaluated against eight synthetic papers written for the test harness, each with a ground-truth manifest listing the flaws planted in it. Your dismiss and address actions are product state and are not converted into a training signal.
No. Dismissing or addressing a comment changes what your review looks like when you return to it; it is product state, not a training signal. PerfectPaper runs hosted models it does not modify, so there is no model on the other end of that action to learn from your correction — fine-tuning and preference tuning are both absent by construction.
PerfectPaper enforces its no-training commitment through contract terms rather than a technical switch, and that distinction is worth stating plainly rather than glossing over it.
PerfectPaper does not send a per-request do-not-train flag to model providers. The commitment rests on the commercial and cloud agreements under which those providers process the traffic. This is the ordinary state of affairs for products built on hosted models — most provider APIs do not expose such a flag in the first place — but it is rarely said out loud, and a research office is entitled to know which kind of guarantee it is being offered.
Being concrete about the missing thing helps. A do-not-train flag would be an HTTP header or a body field, set on every call, that the provider’s API documents and honours. PerfectPaper’s model adapters send an API key alongside the request body — the Anthropic adapter adds an API-version header — and no header or field in any of them asks a provider not to train. There is nothing to point at, so this page points at the contracts instead.
There is a reason no such flag exists, and knowing it is better than guessing at it. On the commercial API tier that PerfectPaper’s traffic runs on, not training is already the documented default, so there is no switch to send because there is nothing to switch off. OpenAI’s API documentation states that “data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)”. Anthropic’s policy states: “By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models.” The contracts still do the load-bearing work, because a published default describes current practice and can be revised by editing the page it sits on, whereas an agreement has a counterparty and a remedy attached.
That default is a property of the tier, not of the vendor as a whole, and the distinction catches people out. Anthropic’s consumer policy makes the contrast explicit: for Claude Free, Pro and Max, conversations are used for model improvement where “You choose to allow us to use your chats and coding sessions to improve Claude”. A researcher’s experience of a chat product’s privacy settings is therefore not a guide to what happens to a manuscript sent through a commercial API, and a colleague’s accurate answer about one tier does not answer the question about the other.
One further specific is worth naming precisely, because it is the closest thing to a real exception in this picture. PerfectPaper’s Anthropic adapter marks manuscript text with cache_control: ephemeral, Anthropic’s prompt-caching directive, so the same manuscript is not re-processed from scratch on every call inside one review. Anthropic’s default ephemeral cache TTL is five minutes, refreshed on each cache hit — a performance optimisation, not a training mechanism, and not a route into the evaluation corpus described above. It is, however, a real transient copy held at the provider during that window, and a research office asking whether any copy exists anywhere, even briefly, deserves that specific answer rather than a blanket no. Anthropic documents that the cache is partitioned by customer — “Caches are isolated between organizations. Different organizations never share caches, even if they use identical prompts” — so within that window the copy is reachable by PerfectPaper’s own subsequent calls and not by another customer’s.
Contracts are also where European data protection law puts enforcement. GDPR Article 28(3)(a) requires a processor to act “only on documented instructions from the controller, including with regard to transfers of personal data to a third country or an international organisation”. The documented instruction is the written agreement; a request header is not one, and a provider that ignored a header would be breaching nothing. Article 28(4) then carries the same obligations down the chain: where a processor engages another processor, “the same data protection obligations … shall be imposed on that other processor”, and “where that other processor fails to fulfil its data protection obligations, the initial processor shall remain fully liable to the controller for the performance of that other processor’s obligations.”
For an institutional assessment, the practical test is where the sentence is written. A no-training statement on a trust page or in a blog post describes current practice and can be revised by editing the page. The same sentence inside a data processing agreement is an obligation with a counterparty and a remedy attached. Ask which of the two you have been shown. Where your manuscript is processed answers the neighbouring question of which region each provider processes in.
Through two things: PerfectPaper’s own code, which trains on nothing, and the commercial and cloud contract terms binding the model providers that process the traffic. It is a contractual guarantee rather than a per-request switch, and PerfectPaper states that openly.
No, and few provider APIs expose one — this isn’t PerfectPaper withholding a setting that exists elsewhere. The commitment rests on contract terms rather than a per-request flag, which is also why PerfectPaper publishes the provider list on the subprocessor page rather than pointing at a toggle that would not do the enforcing.
No, and it does not need to. That setting governs your own consumer chat account. PerfectPaper’s traffic runs on the providers’ commercial API tier, where not training is the documented default rather than a toggle — OpenAI’s API documentation states that “data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)”. The two tiers carry different defaults, so an answer about one is not an answer about the other.
The contract, not a technical block. GDPR Article 28(3)(a) requires a processor to act only on documented instructions from the controller — the written agreement is that instruction, and a provider that trained anyway would be breaching it. There is no code-level lock; the enforcement is legal, and PerfectPaper says so rather than implying a technical one.
PerfectPaper names every third party that receives any part of your manuscript on its subprocessor page, along with what each one receives.
Naming them is what makes the first two layers checkable. A privacy promise attached to an unnamed supply chain cannot be verified by the reader, and an institution evaluating a vendor is right to treat one as unverified. The list also distinguishes scope: the review models receive manuscript text, the embedding service receives a title and abstract only, and the scholarly lookup services receive a title, a DOI or an author name at a time.
GDPR Article 28(2) states the rule such a list exists to satisfy: “The processor shall not engage another processor without prior specific or general written authorisation of the controller.” A published subprocessor list is how a general authorisation becomes something you can inspect rather than something you granted by signing. If your manuscript carries participant data and your institution is the controller for it, that clause is leverage rather than formality, and the list is the document your data protection officer will want first.
Each entry’s processing region is read from the configuration the application is running under rather than typed into the page, so a page claiming a region the traffic does not use would be a defect rather than a copy error.
Several components sit outside the manuscript path and are listed anyway: error monitoring and product analytics run on United States endpoints and receive no manuscript text, and product analytics are collected only with your consent. Both receive operational telemetry tied to your account. An assessment that omitted them would be incomplete, and quietly omitting the inconvenient entries is exactly the failure a published list is supposed to prevent. Secure AI review for unpublished research gathers the residency, storage and deletion answers in one place.
A commitment not to train on customer data is compatible with several things researchers usually mean to rule out. It does not by itself rule out retaining content for abuse monitoring, sampling content for human review, or applying a different default to a different account tier.
When comparing tools, read for the specific claim rather than for the phrase. Ask what is retained, for how long, who may read it, and whether the answer changes with your account tier. The procurement checklist puts those questions in a form you can send to a vendor, and is it safe to upload a manuscript to ChatGPT works through the same three checks for general-purpose chat products.
Scope is the property to compare. “We do not use customer content to train our models” leaves a provider’s other models, its subprocessors’ models, and every evaluation dataset outside the promise. “Your inputs are not used for training” says nothing about outputs, which for a review product means the review itself. The sentence at the top of this page — not the paper, not the model’s reasoning, not its reply, not the derived metadata — was written to close those four gaps by enumeration, and enumeration is the shape to compare any competing sentence against.
Human review is the commitment researchers most often assume they have and least often verify. Most hosted model providers reserve some ability for a person to read flagged content, because abuse monitoring that no human ever adjudicates is a weak control.
Microsoft’s documentation for models sold by Azure is the most explicit public description of the pattern, and it is worth quoting rather than paraphrasing. Its abuse-monitoring page acknowledges that some customers “may conclude that they don’t want or don’t have the right to permit Microsoft to store and conduct human review on their prompts and completions for abuse detection”, and offers eligible customers an application to modify abuse monitoring. For the default case it describes the access path exactly: flagged “prompts and completions can be accessed for human review only by authorized Microsoft employees via Secure Access Workstations (SAWs) with Just-In-Time (JIT) request approval granted by team managers”, and, for models deployed in the European Economic Area, “the authorized Microsoft employees are located in the European Economic Area.”
A narrower carve-out sits alongside human review and is easier to miss, because it is an exception to the training sentence itself rather than to the access one. Anthropic’s consumer policy states that conversations may be used where they “are flagged for safety review (in which case we may use or analyze them to improve our ability to detect and enforce our Usage Policy, including training models for use by our Safeguards team, consistent with Anthropic’s safety mission)”. Read that closely: content that trips a safety classifier can become training data for safety classifiers, under a policy whose headline is that model improvement is something you opt into. It is a narrow exception and a defensible one, and it is still an exception. The general lesson is that a no-training sentence usually carries a safety-shaped asterisk somewhere below it, and the useful question to put to any vendor is what theirs says rather than whether it exists.
Those passages are quoted as documentation of an industry pattern rather than as a description of PerfectPaper’s own supply chain; the subprocessor page is the authoritative statement of that. The phrase worth carrying away is “don’t have the right to permit”. A researcher handling a co-author’s unpublished data, identifiable participant data, or another author’s manuscript may genuinely lack the authority to consent to third-party human review, which is a different objection from disliking it and needs a different answer. Reviewers using AI on manuscripts covers the case where the manuscript is not yours to consent about.
No. The model providers that receive your text are bound by the commercial and cloud agreements under which the traffic runs, and each one is named on the subprocessor page along with what it receives. The review models receive manuscript text; the embedding service receives a title and abstract only; the scholarly lookup services receive a title, a DOI or an author name at a time.
No. The evaluation corpus holds eight synthetic papers written for the test harness and no customer work at all. Your manuscript and review stay in your account until you delete them, and being stored there is not a route into a training or benchmark set.
Possibly, for abuse monitoring — most hosted model providers reserve that ability, and PerfectPaper’s no-training promise does not rule it out. Microsoft’s own documentation for Azure-hosted models describes flagged content reaching human reviewers through access-controlled workstations with manager approval. Ask a vendor this question directly; a no-training answer alone does not cover it.
A no-training claim is tested by reading for scope, for the account it applies to, and for the three commitments the sentence does not make. Seven checks settle most of it, and none of them requires a meeting.
Check whose content the sentence covers, and whether outputs are included. Terms use “customer content”, “your inputs and outputs”, “prompts and completions” and “content you submit” to mean measurably different things. A promise covering inputs but not outputs leaves the generated review outside it.
Check which account the answer applies to. Training defaults are frequently set per account tier rather than per company, so a company-level answer is not an answer to your question. A colleague’s accurate description of their own account may not describe yours. The clearest instance is the split between a vendor’s consumer chat product and its commercial API, where the same company can run opt-in model improvement on one and a no-training default on the other.
Check whether evaluation and benchmarking are named. Silence here is common and is not accidental. A retained regression fixture is compatible with every no-training sentence ever written.
Check where the sentence lives. Terms of service and the data processing agreement create obligations. A trust page, a help-centre article and a launch post describe practice.
Check retention separately and in days. Ask how long a copy exists after you delete it, whether deletion is immediate or scheduled, and whether it propagates to subprocessors and backups.
Check whether “no training” also means “no transient copy.” Some providers cache request content for a few minutes to avoid reprocessing it on every call inside a session; that is a performance mechanism, not a training mechanism, but it is still a copy held somewhere. Ask for the cache or session-retention window in minutes, separately from the long-term retention window in days, and ask whether that cache is partitioned between customers.
Check the subprocessor list for scope rather than length. A flat list of company names hides the difference between a service that receives a title and one that receives the whole manuscript, and that difference usually matters more than the count.
A final check applies when a product claims local or on-device processing: “runs locally” and “does not train” are separate statements, and a locally run model can still send telemetry, crash reports or usage samples elsewhere. Ask both questions rather than letting one imply the other.
Research offices, IT security teams and data protection officers ask the no-training question in a small number of recognisable forms, and the form tells you what the questioner is worried about.
“Is customer content used to train or fine-tune models, and does the answer differ by account tier?” “Is content used to build evaluation or benchmark datasets?” “May staff at the vendor or at its subprocessors read the content, and what triggers that?” “Which subprocessors receive content, and does each receive the document or metadata only?” “Is the no-training commitment in the data processing agreement, or only on the website?” “Does deletion propagate to subprocessors and backups?” “Does a residency setting apply to data already uploaded, or only to new uploads?”
The thin answers have a recognisable shape too. “We take your privacy seriously” answers nothing. “We are aligned with leading security frameworks” describes an intention; alignment is not attestation, and the difference is the whole point of the question. “Your data is encrypted” answers a question nobody asked, because encryption at rest says nothing about who is permitted to read the decrypted text. “We do not train on your data”, offered without a processor list, asks the reader to trust a supply chain they cannot see. And “that is covered under NDA” converts a public fact into a meeting, which is itself an answer of a kind.
Reluctance to answer one specific question, in a set of answers that are otherwise open, is the signal worth acting on.
Sometimes the obvious remedy — read the terms, obtain the agreement, ask the vendor — is unavailable, and four situations account for most of the stuck cases.
Your institution has not decided. Many universities and research institutes now hold written policies on third-party AI services, and a grant’s data management commitments may constrain the answer further. One email to the research office or IT security team settles it more definitively than any vendor page, including this one, and the procurement checklist is written to be forwarded rather than read.
You are the referee, not the author. The ICMJE Recommendations state that “Manuscripts submitted to journals are privileged communications that are authors’ private, confidential property”, and that reviewers “must maintain the confidentiality of the manuscript as outlined above, which may prohibit the uploading of the manuscript to software or other AI technologies where confidentiality cannot be assured.” The ICMJE also states that reviewers “must request permission from the journal prior to using AI technology to facilitate their review.” No vendor’s training policy overrides that, because the permission is the journal’s to give. Journal AI policies for authors and referees sets out which rule applies to you.
The manuscript carries identifiable participant data. De-identify before upload, in line with your institution’s policy and the consent under which the data was collected. A training commitment is not a lawful basis and does not substitute for one. Ethics and data sharing covers what a manuscript needs to state about consent, approval and availability.
The vendor will not answer in public. Ask for the answer in writing and ask for it in the agreement rather than in an email, because an email describes practice and an agreement binds it. If the answer arrives only under an NDA, note which question required one; the list of questions a vendor will not answer publicly is usually shorter and more informative than the list it will.
PerfectPaper’s no-training commitment is contractual, and this page claims nothing technical in its place. Five boundaries are worth stating as specifications rather than as apologies.
No per-request switch exists, so there is no toggle to point at and none is implied. Encryption at rest uses provider-managed keys rather than customer-managed keys. No robots directive, crawler rule or file placed on a web server is offered as part of this guarantee, because such a directive is a request to well-behaved crawlers and not a data-protection control. And PerfectPaper makes no claim about material you have already published: if your preprint is public, a model provider’s existing training data is outside anyone’s control here, and that exposure is a property of publishing rather than of reviewing.
The ephemeral prompt-cache window described in layer two is one more boundary of the same kind: it is a performance mechanism serving the review already in progress, not an additional retention or data-protection promise, and this page does not claim it is anything more.
Stating the boundaries is the point. A page listing only strengths has to be verified twice.
If a provider changed the terms under which it processes PerfectPaper traffic, the honest response would be to change this page and the subprocessor page rather than to leave the sentence standing.
That is the maintenance commitment attached to publishing an unqualified claim. It is also why the processing details are derived from the running configuration rather than typed into a template — a page that describes its own deployment cannot drift away from it silently. Where your manuscript is processed sets out the route that mechanism reports.
AI peer review tool · AI peer review · Journal AI policies for authors and referees
Last updated September 10, 2026
Upload your paper and receive structured, sourced feedback before you submit.
Connection lost
Reconnecting…
Something went wrong on our end
Attempting to reconnect