| name | ors-rebuttal |
| description | Use when responding to an Operations Research (OR) decision letter — writing the point-by-point response, closing proof gaps, adding baselines/instances, and passing the ORJournal code/data reproducibility review across a revision cycle. Drafts the revision and response; it does not parse the decision in the first place (ors-review-process) or run the final preflight (ors-submission). |
Revision & Response (ors-rebuttal)
When to trigger
- You have a major/minor revision decision from the handling Area Editor and must respond.
- A reviewer found a proof gap, a missing baseline, or a reproducibility shortfall.
- You are preparing the code/data deposit for the ORJournal pull-request review.
The OR response letter
Operations Research revisions are technical. Reviewers expect the mathematics and
computation to actually change, not just the prose. Structure the response so every
point is traceable:
- Point-by-point, verbatim. Quote each reviewer/editor comment, then give your
response and the exact location of the change (section, theorem, table, e-companion).
- Honor the editor's synthesis first. Address the binding points the Area/Associate
Editor emphasized before optional reviewer suggestions.
- Be precise about what changed. "We now prove Theorem 3 without Assumption 2; see
the new Lemma 4 and Appendix B" beats "we revised the proof."
Closing the common technical asks
| Reviewer ask | Substantive response |
|---|
| "Proof gap / assumption smuggled in" | Repair the proof; state where each assumption is used; add a lemma if needed |
| "Assumption too strong" | Weaken it (relaxation/counterexample) or justify necessity with a counterexample |
| "Bound not tight" | Prove tightness with a matching instance, or reframe as best-known |
| "Missing baseline / weak instances" | Add the closest prior method and recognized benchmark instances; rerun |
| "Stochastic results unreliable" | Add confidence intervals, more replications, CRN, fixed seeds |
| "Not reproducible" | Provide the ORJournal repo: README/LICENSE, structure, runnable scripts |
Reproducibility review (ORJournal)
If accepted in principle, code/data go through the ORJournal GitHub pull-request
process: a structured repository with README/LICENSE, the prescribed directory
structure, and documented hardware/software/data/installation/run steps so a
reviewer can regenerate the results. Pin versions and seeds. If data are
confidential/licensed/non-public or the paper is purely methodological, ensure the
exemption (requested in the cover letter, decided by the Area Editor with EiC
authority) is in place. Respond promptly to reproducibility comments on the PR.
Length & format discipline through revision
- Keep the introduction equation-free; new long proofs go to the e-companion
(which must not be longer than the manuscript).
- Stay within the page tier for your manuscript type; move ablations/extra tables to
the e-companion rather than bloating the main text.
- Maintain author-year citations and consistent notation across new material.
Anti-patterns
- A defensive letter that argues instead of fixing a genuine proof gap.
- Claiming a change without pointing to where it appears.
- Adding experiments but no confidence intervals or seeds.
- Blowing past the page tier or the e-companion length rule to answer reviewers.
- Ignoring the editor's synthesis to chase every minor reviewer remark.
Output format
【Response letter】point-by-point, verbatim quotes + change locations?
【Editor synthesis】binding points addressed first?
【Technical fixes】proofs / assumptions / bounds / baselines / stochastic care
【Reproducibility】ORJournal repo ready / exemption in place?
【Format】equation-free intro; within page tier; e-companion ≤ manuscript
【Next step】resubmit → ors-review-process (next round) or ors-submission (final checks)
