Expert Systems with Applications Response to Reviewers: How to Write a Rebuttal That Wins (2026)

Expert Systems with Applications is Elsevier's high-volume flagship for AI and machine learning applied to real domains, and its reviewer culture is unusual in three ways that change how you write a rebuttal.

Application substance, not abstract novelty

ESWA is an application venue, not a methods venue. The journal states that contributions are expected to apply expert and intelligent systems to real problems in industry, government, or research settings.

So a reviewer is rarely asking whether your idea is new in the abstract sense. They are asking whether the application is real, whether the comparison is fair, and whether the result holds up. A rebuttal that argues "our method is novel" answers a question ESWA reviewers are not asking. The winning rebuttal shows that the application is substantive, the baselines are fair, and the numbers are checkable.

Benchmarking and statistics weighted heavily

ESWA draws on a broad, interdisciplinary reviewer pool that grades methodological rigor over ideas. A reviewer often cares less about your favorite technical detail than about whether the benchmark table, methods, and statistical analysis make the conclusion independently checkable.

The most common revision request is for one of three things:

1. A fairer or more recent baseline comparison.
2. An ablation that isolates each component's contribution.
3. A significance test rather than a single point estimate.

When the abstract claims improved detection, prediction, classification, or efficiency but the comparison table includes only old methods or a single dataset, the reviewer reads the gap as the paper not yet meeting the bar.

Reproducibility, checked against downloadable artifacts

Reproducibility is increasingly explicit at ESWA because applied-AI claims are testable only when the code and evaluation splits are inspectable. A manuscript whose methods section describes evaluation splits in prose, but never provides them as a downloadable supplementary file, faces extra scrutiny on whether the reported numbers are real, and that scrutiny often extends the cycle by one full round.

The journal also runs slow, deep rounds. SciRev community data puts the first round near 5.6 months, with about 2.3 reports and 1.9 revision rounds per accepted paper.

An ESWA revision package is three files in Editorial Manager, and the response document inside it follows a fixed shape:

1. A short editor note at the top, summarizing the major changes and confirming that a full point-by-point document follows.

1. A Reviewer 1 / Reviewer 2 block, where each comment is quoted in full, then answered, with the specific manuscript revision cited by page and line.

1. Three uploaded files: the point-by-point document, the highlighted-changes manuscript, and a clean version.

Make sure every comment from every reviewer is answered. The named failure pattern at ESWA: authors who answer the friendly reviewer thoroughly and the skeptical reviewer thinly lose time, because the skeptical reviewer is usually the one whose benchmarking or reproducibility concern the handling editor weights on the soundness call.

At ESWA, the change a reviewer cannot find is the change that did not happen. For every comment, your response must point to the exact page and line where the revision appears in the revised manuscript. Write "page 9, lines 3-28," not "we have updated the manuscript."

Elsevier's own guidance is explicit on this: it is not enough to say "we changed the discussion section," you should say "we changed the discussion section on page 24, lines 7-23."

The ESWA-specific cost is the slow round. A reviewer coming back to your paper after weeks will not go hunting for an edit, and on a benchmarking or reproducibility comment, "not found" reads as "not addressed", which is exactly what triggers another revision cycle. To stay locatable:

• Cite page and line numbers of the revised file, not the original.
• Re-check those numbers after any reformatting, since pagination shifts.
• Pair every reference with the highlighted-changes manuscript so the reviewer confirms each edit at a glance.

On an ESWA thread, where each reviewer comment is graded for whether it was answered, the handling editor needs to scan reviewer voice and author voice apart at a glance. Set them off typographically rather than running them together.

A convention that works well in the point-by-point document:

• Reviewer comments in italic (or a muted color), quoted verbatim.

• Your responses in plain upright text, with the word "Response:" in bold to anchor each reply.

• Quoted revised manuscript text in an indented block, so the editor sees the actual new wording.

When reviewer and author text collapse into one undifferentiated block, the editor cannot quickly confirm that every comment was answered. On ESWA's difficult-comment reviews, that ambiguity is read as incompleteness, and it works against you.

This is the honest-friction part. A major revision at ESWA is an invitation, not an acceptance, and a rebuttal that fights the wrong battle does not just delay the paper, it can end in rejection on the next round. Most disputes are not worth contesting.

If a reviewer asks for a fairer baseline, an ablation, a significance test, or downloadable reproducibility artifacts, comply. These are exactly the benchmarking and reproducibility checks ESWA reviewers are instructed to apply, and refusing them reads as the paper failing the journal's core bar. Push back only when a request would reduce technical correctness or falls outside ESWA's application-and-soundness criteria, and even then, make a clarifying edit and propose an alternative rather than refusing flat.

When the core objection is a soundness or application-substance failure you genuinely cannot fix within one round, the realistic move is not to argue. Withdraw, fix the work properly, and transfer to a better-fit Elsevier sibling, such as Knowledge-Based Systems, Applied Soft Computing, or Engineering Applications of Artificial Intelligence, through the Article Transfer Service, where reviewer reports can travel with the manuscript.

One more honest caveat: SciRev surveys flag occasional transparency complaints at ESWA, including not all reviews being shared. If you believe a review is unfair or conflicted, the productive path is a calm, evidence-based note to the handling editor, not a combative rebuttal. Treat each revision round as scarce: spend it answering every comment in full, not on winning an argument about novelty that ESWA reviewers were never grading.

In our pre-submission review work with Expert Systems with Applications submissions and rebuttals, three patterns generate the most consistent extra revision rounds. Each is testable against your own response before you upload the revision.

Weak or stale baselines surviving into the rebuttal. The most common reason an ESWA revision stalls is that the response argues the contribution rather than fixing the baselines. Expert Systems with Applications reviewers grade benchmarking fairness, so when the abstract claims improved detection, prediction, classification, or efficiency but the benchmark table includes only old methods or a single dataset, a reviewer reads the gap as the paper not meeting the application-and-soundness bar.

Across our Expert Systems with Applications pre-submission reviews, rebuttals that add a fair, recent baseline comparison and re-run all experiments under identical conditions clear re-review; rebuttals that defend the original baselines earn another round. The fix is mechanical: add the requested benchmarks, report them in a new table, and cite the table by page and line.

Reproducibility gaps left unanswered. ESWA reviewers increasingly look for whether another engineer could rebuild the result, which makes reproducibility and code or implementation detail the second failure pattern. The sharpest version we see at Expert Systems with Applications is the manuscript that describes its evaluation dataset splits in prose but never provides them as a downloadable supplementary file, which invites scrutiny on whether the reported numbers are real and costs a full round.

In our ESWA pre-submission reviews, the rebuttals that fail here answer a reproducibility comment with prose ("the method is standard") instead of artifacts. The pattern that clears is concrete:

• Add full pseudocode or an algorithm block.
• List hyperparameters, dataset splits, and hardware in the revised methods.
• Attach the splits as a supplement, and point the reviewer to the exact location.

Application substance and statistics treated as afterthoughts. The third pattern is specific to Expert Systems with Applications as an application venue: authors defend a model result without showing that the real-world application is substantive, and they report a single number without a statistical significance test. Because ESWA weights whether the application is real and whether the result is independently checkable, an underdeveloped application case or a missing significance test is a common cause of the "concerns not properly addressed" outcome.

In our Expert Systems with Applications pre-submission reviews, we flag any rebuttal where:

• A requested ablation or significance check is acknowledged but not actually added.
• The figure a reviewer questioned is defended without revision.
• The decision setting of the application is still invisible in the abstract and introduction.

The fix is to make the application consequence visible in the main text, add the significance test the reviewer asked for, and answer every comment from both reviewers with an action verb and a page and line reference.

These three patterns are why an ESWA rebuttal is not interchangeable with a Nature or IEEE Access rebuttal. The application-first, benchmarking-heavy, reproducibility-checked, slow-round structure rewards completeness and verifiable evidence over argument, and punishes selective or defensive responses with months, not minutes.

The response that survives ESWA re-review adds fair baselines, real reproducibility artifacts, a visible application contribution, and full coverage of every reviewer. You can pressure-test a draft rebuttal with an Expert Systems with Applications reviewer-response check before you upload it.

• Every comment from every reviewer is answered with an action verb and a page and line reference to the revised manuscript.
• Benchmarking and reproducibility requests (fair baselines, ablations, significance tests, dataset splits, hyperparameters) are addressed with new manuscript content and downloadable artifacts, not prose reassurance.
• The application contribution is visible in the abstract, introduction, and results, not just the cover letter.
• The tone is firm only on soundness and fairness, never defensive on cosmetic points, and all cited DOIs in the revised reference list are clean.