The handling editor's framing outranks individual reviewers. At PNAS Nexus the paper was assigned to an Editorial Board member and then a handling/guest editor; that editor's letter tells you what is load-bearing. Identify:
A "reject but would consider a new submission" is an invitation gated on the deal-breaker. Don't treat it as a flat reject, but don't under-deliver either.
If the paper was transferred from flagship PNAS, prior PNAS reviews travel with it. When responding:
| Bucket | Action |
|---|---|
| Do (fair, feasible) | Make the change; show it; quote the new text/figure. |
| Do-partial | Do what's feasible; explain the boundary with evidence. |
| Defend (wrong/out of scope) | Push back respectfully, with data/citations — not assertion. |
| Defer (future work) | Acknowledge; add a sentence to the text; don't over-promise. |
Most rejections-on-revision come from silently skipping a load-bearing comment or defending when an experiment was actually needed.
For each comment:
Reviewer N, Comment k: <verbatim quote of the reviewer>
Response: <what we did / our reasoning>. <Evidence: new Fig./table, statistics.>
Changes: "<quoted new manuscript text>" (p. X, lines Y–Z; new SI Fig. Sk).
If a reviewer says the conclusion outruns the data, this is the most dangerous comment. Either add the evidence or narrow the claim in the title, Significance Statement, abstract, and last paragraph — and say you did. Because the Significance Statement is public-facing and broad, re-check it specifically for over-claiming when you narrow (link pnasnexus-significance), and re-confirm it stays within 50–120 words; re-run pnasnexus-fit if the narrowed claim weakens broad significance.
Build a separate ledger for the parts of a PNAS Nexus revision the editor can audit quickly:
| PNAS Nexus surface | What to verify before response drafting |
|---|---|
| Significance Statement | Still a broad, non-hyped contribution claim, matching the narrowed evidence, within 50–120 words? |
| Abstract / title | Public-facing claims aligned with the strongest validated result, not the original aspiration? |
| Main figures | Did each new analysis change a main-text figure, SI figure, or stated null result? |
| Supporting Information | New robustness, data-processing, and method details findable by reviewer-comment number? |
| Data / code availability | New dataset/software/accession require an updated availability statement and [dataset] citation? |
| Page budget | After additions, is the revision still within the article-type page limit, or do items move to SI? |
When reviewers ask for extra validation, prefer a response package that shows where the evidence landed: "new main Fig. 3C", "new SI Fig. S7", "new Methods paragraph", or "new Data and Code Availability sentence." Do not bury PNAS-Nexus-specific changes only in the response letter.
【Decision type】 reject / reject-resubmit / major / minor
【Editor's load-bearing concerns】 [...]
【Transferred PNAS reviews?】 N/A | yes → which carried-over concerns still apply (rigor) vs not (fit)
【Deal-breaker】 ... → plan to resolve
【Comment triage】 Do [...] / Do-partial [...] / Defend [...] / Defer [...]
【Experiment priority】 ranked by impact × feasibility
【Claim integrity】 narrowing needed? (re-check Significance Statement 50–120w + pnasnexus-fit)
【Revision ledger】 Significance Statement / SI / data-code availability / page-budget changes
【Response letter】 drafted point-by-point with quoted changes