Usage and privacy policy

1. Scope

This policy states the rules for using PubCheck and what happens to submitted material. It applies to the hosted website at pubcheck.net, the local web app started with pubcheck serve, the pubcheck command line, and the journal API under /api/v1.

What PubCheck checks, and what it cannot check, is described on the About page. Journal deployments that check submitted manuscripts are additionally governed by the editorial use policy and the data-handling statement in the project repository.

2. Normative language and conformance

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in this document are to be interpreted as described in RFC 2119 when they appear in capitals.

A conforming deployment satisfies every MUST and MUST NOT requirement in this policy. A conforming journal deployment also records the items in the conformance checklist in section 13 before the first confidential submission is checked.

A SHOULD requirement may be set aside only by a documented decision of the journal or institution that operates the deployment.

3. Overview

PubCheck checks citations against public publication indexes and reads Content Credentials metadata from manuscript figures. It produces a report with a verdict and a reason for each reference.

The report is evidence for human review. PubCheck does not decide whether a manuscript should be accepted, rejected, corrected, or investigated. Those decisions belong to editors.

4. Acceptable use

4.1 Permitted uses

PubCheck MAY be used to:

• Check whether references appear in configured scholarly metadata sources.
• Compare cited metadata with matched records.
• Identify malformed identifiers.
• Report retraction or withdrawal signals when lookup metadata or a local snapshot supports that status.
• Report PubPeer activity when PubPeer lookup is configured.
• Report extraction warnings, lookup errors, figure metadata, and Content Credentials status.
• Measure deployment performance after manual adjudication.

4.2 Prohibited uses

PubCheck MUST NOT be used to:

• Reject a manuscript automatically.
• Accuse an author of fabrication or misconduct on PubCheck output alone.
• Decide whether a cited paper supports a manuscript claim. PubCheck does not read the cited paper.
• Decide whether a manuscript was written by AI.
• Declare a figure real or fake from figure metadata alone.
• Treat every NOT_FOUND reference as fabricated. New, non-indexed, and out-of-coverage references also return NOT_FOUND.
• Treat every ERROR row as an author problem. ERROR means a lookup or tool failure.
• Publish examples from rejected or unpublished submissions without the journal's permission.

A flagged reference MUST be reviewed by a person before author contact or editorial action.

5. Confidential manuscripts

A deployment that checks confidential submitted manuscripts MUST be one of: an institution-controlled machine, an institution-controlled server, a journal API deployment the journal has approved, or a reference-list-only workflow.

The hosted website MUST NOT be used for confidential unpublished files unless the journal has explicitly approved that deployment. The local web server SHOULD bind to 127.0.0.1; a shared editorial instance MUST have access controls the journal has approved.

6. Data processing

6.1 Submitted files

PubCheck parses the submitted file on the machine that runs it. For the command line and the local web app, that is the user's machine. For the hosted website and a hosted journal API, that is the hosting server.

PubCheck does not use submitted files for model training. It does not upload the file to PubMed, Crossref, OpenAlex, Europe PMC, DataCite, arXiv, PubPeer, or any other lookup service.

6.2 What is sent to lookup services

In online mode, PubCheck sends lookup terms to public publication indexes. A lookup term can be a DOI, PMID, PMCID, arXiv ID, ISBN, NCT ID, RRID, accession, URL, or citation title.

Current lookup services: PubMed and the PMC ID Converter (NCBI), Crossref, OpenAlex, Europe PMC, DataCite, arXiv, bioRxiv, medRxiv, Semantic Scholar, Open Library, Google Books, ClinicalTrials.gov, SciCrunch, RCSB PDB, PubPeer, and the servers behind cited URLs.

Title lookup can disclose part of a reference list to a lookup service. If a manuscript cites unpublished work, a title search can disclose that title. A journal that treats submissions as confidential MUST approve title lookup before it is used on unpublished manuscripts.

Each lookup service keeps its own logs and has its own retention rules and terms. PubCheck does not send citation context, surrounding manuscript text, or image bytes to lookup services.

6.3 Figures

PubCheck reads image bytes in the process that handles the upload to parse Content Credentials, then discards them. Image bytes are not returned in reports and are not written to the lookup cache. The report keeps figure metadata only: file name, page and image index when available, media type, verdict, generator, signer, validation state, and the reason.

7. Data storage

7.1 Reports

Reports include source_sha256, a SHA-256 hash of the uploaded file bytes or the trimmed pasted text. The hash identifies the checked source without storing the source file.

For the journal API, completed reports are stored as redacted JSON envelopes, with generated PDF bytes when available. The stored report removes raw citation text and citation context. After a report is persisted, PubCheck clears live source text and retained PDF bytes from the job.

The stored report still contains the source file name, identifiers, parsed citation metadata, matched record metadata, verdicts, and reasons. Stored reports MUST be kept under the same confidentiality rules as the submission record.

7.2 Server memory

Web app job records live in process memory and are lost when the server stops. PDF upload bytes stay in the job so the browser can show the page beside each citation; non-PDF bytes are not kept after extraction. In local web mode, the server SHOULD be stopped after a confidential session.

7.3 Lookup cache

PubCheck keeps a local SQLite cache of identifier lookups. The cache contains lookup keys, such as DOIs and PMIDs, and the matched records. It does not contain the uploaded file, raw citation text, or citation context. The cache file is plaintext; PubCheck does not encrypt it. Controls are listed in section 11.

7.4 Browser storage

In its default configuration the web app sets no cookies. A shared editorial instance started with an access key (PUBCHECK_ACCESS_KEY) is the one exception: after a visitor presents the key, the server sets a single HttpOnly pubcheck_access cookie that holds the access grant. It carries no personal data and no tracking identifier. The web app uses browser local storage for two things: the light-or-dark theme choice and a list of recent checks. This data remains in the user's browser. The server does not read it. Recent checks can be cleared from the History panel. The theme choice can be cleared through browser settings.

8. Hosted website

pubcheck.net is hosted on Vercel, in the United States. Vercel keeps standard request logs, including IP address, user agent, and request time, under its own retention rules.

Pages on pubcheck.net load Vercel Web Analytics. It sets no cookies. Visitors are identified by a request hash that is discarded after 24 hours. The recorded data points are page path, referrer, coarse location (country, region, city), and device, operating system, and browser. PubCheck runs no advertising and no cross-site trackers. The analytics script does not load on local deployments.

The website has no user accounts and collects no names, email addresses, or payment information. The journal API authenticates with bearer keys.

For the hosted website, the PubCheck project is the data controller for the request logs and analytics described above; Vercel processes them on the project's behalf. There is no account data to access, correct, or export. Questions about this data, including deletion requests, go to the contact in section 16.

For local and institution-hosted deployments, the operating journal or institution controls all data. The PubCheck project receives nothing from those deployments: no files, no reports, no telemetry.

9. Retention and deletion

Live job records are held in process memory. A sweep removes finished journal API jobs older than one hour by default and caps the number of retained jobs. All in-memory records are lost when the server stops.

Stored API reports are kept until an editor deletes them, through the report delete endpoint or a retention sweep (POST /api/v1/reports/retention/sweep). PubCheck does not delete stored reports on a background schedule.

Deletion receipts, editor overrides, and report events remain after a report row is deleted, unless an administrator removes them separately. They remain so the editorial record shows that a report existed and who acted on it.

Lookup cache rows are kept until deleted. Setting PUBCHECK_LOOKUP_CACHE_TTL_DAYS prunes rows older than the configured age when the cache opens.

10. Report integrity and security

Reports carry a SHA-256 digest of the report body. If a signing key is configured, reports also carry an HMAC-SHA256 signature over that digest, which makes the JSON report tamper-evident. PDF reports carry the same digest, so a deployment can verify that a JSON report and a PDF report describe the same run.

Known limits: PubCheck does not encrypt stored reports or the lookup cache. It has no user identities; journal API bearer keys map to roles, and PubCheck cannot tell which person used a shared key. A deployment that needs encrypted storage or per-user audit trails MUST provide them in the surrounding institutional system.

11. Operator controls

• Start the server with --offline to skip all outbound lookup calls.
• Restrict checks to hard identifiers when title disclosure is not approved.
• Bypass the lookup cache with --no-cache on the command line or no_cache=true in the journal API. Disable it with PUBCHECK_DISABLE_LOOKUP_CACHE=1, or move it to encrypted storage with PUBCHECK_LOOKUP_CACHE_DB.
• Disable PubPeer lookups with PUBCHECK_DISABLE_PUBPEER=1.
• Clear browser history state from the History panel.
• Delete stored journal API reports with the delete endpoint or a retention sweep.

12. Warranty and liability

PubCheck is provided as is, without warranty of any kind. The maintainers do not warrant that lookup sources are complete, that verdicts are correct, or that the hosted website is available.

Editorial decisions made from PubCheck reports, and their consequences, rest with the journal or institution that made them. The maintainers accept no liability for decisions based on report contents, for data a deployment sends to lookup services, or for how those services handle that data.

13. Conformance checklist

Before the first confidential submission is checked, the journal deployment MUST record:

• The PubCheck version or commit.
• The version of this policy in effect.
• The deployment location.
• The data-handling mode: online, offline, or hard-identifier-only.
• Whether online lookup is allowed.
• Whether title lookup is allowed.
• The cache policy and the report retention policy.
• Who can read reports, who reviews flags, and who can contact authors.
• The override labels in use and what data may leave the journal for validation.

A deployment that keeps this record and satisfies every MUST and MUST NOT requirement in this policy conforms to it.

14. Changes to this policy

Revisions are proposed on the project issue tracker and take effect when published at the canonical URL. A change to any requirement increments the version number and the effective date. Section 15 records each version, and the repository history records the full text of every revision.

15. Revision history

16. Contact

Report problems and ask questions on the project issue tracker: github.com/Alfredo-Sandoval/pubcheck/issues. For a confidential journal deployment, use the deployment's editorial contact channel instead of a public issue.