Applied Soft Computing Submission Guide: How to Submit to ASOC (Elsevier)

Applied Soft Computing publishes Research Articles and Review Articles in the soft-computing space, plus occasional special-issue contributions. The article type you choose drives the expectations that apply, but the required submission items are constant.

Highlights are mandatory at submission. You provide 3 to 5 bullet points, each capped at 85 characters including spaces, summarizing the novel contribution. Editors read these alongside the abstract, so vague highlights ("a new algorithm is proposed") waste the strongest first-impression real estate the journal gives you.

Research Articles run under Elsevier's free-format model with no rigid page ceiling, but length is governed by completeness rather than a hard cap. In practice, accepted soft-computing Research Articles run long, commonly 8,000 to 12,000 words across roughly 25 to 40 pages with 8 to 15 figures plus parameter and results tables, because they carry a method description, a benchmark suite, a real-world case study, and a statistical comparison.

The abstract caps at around 250 words per Elsevier convention. An over-long manuscript is judged on whether every experiment earns its space, not on a word count.

For declarations, every submission needs a declaration of interest statement (select "I have nothing to declare" if none apply), a CRediT author contributions statement, and a funding disclosure identifying any financial support and the role of the sponsor. A data availability statement is expected, and for a journal that publishes applied methods, reproducibility artifacts (parameter tables, code, and data) are increasingly part of what reviewers expect to see rather than an optional extra.

Before the experiments and declarations are locked, an Applied Soft Computing baseline and reproducibility check can confirm whether your comparison is fair and your parameter reporting is complete enough to survive review.

Applied Soft Computing assigns submissions to a handling editor who manages them through Editorial Manager. This is not a fast journal: community-reported data puts the first review round at roughly six to seven months, with about three reports per round and an unusually high number of revision rounds, often four or more, before a final decision. Treat the stages below as planning ranges, not commitments.

• Day 0: Submission and completeness check. Editorial Manager ingests your files. Editorial staff confirm the highlights, the declaration of interest, the CRediT statement, and the funding disclosure are present. A missing required item is flagged here before an editor sees the science.

• Days 1 to 14: Editorial screening. A handling editor checks scope fit and novelty.

The fastest returns happen in this window: a method with no apparent novelty over existing metaheuristics, a benchmark-only study with no real application, or work that is really pure machine learning or operations research rarely reaches external review.

• Days 14 to 45: Reviewer assignment. Finding reviewers willing to evaluate a soft-computing manuscript at a high-volume journal is itself a bottleneck, and this stage is a common source of the long waits authors report.

Papers with weak baselines or no statistical testing are frequently returned here rather than sent out.

• Days 45 to 200: First peer-review round. Reviewers return reports, typically around three per round, on a multi-month cadence; community data puts a first round near six to seven months.

Reviewers in this field scrutinize the fairness of the comparison and the honesty of the statistical claims closely, so a paper that reports raw better-than-baseline numbers without significance tests draws hard questions.

• Months 7 to 14: Revision rounds. Major revision is the norm, and Applied Soft Computing is known for multiple rounds, frequently four or more, each requiring a response letter addressing every reviewer point.

Plan for this: a single round is the exception, not the rule.

• Months 12 and beyond: Final decision and rolling publication. Once accepted, the journal publishes on a rolling basis, so the article appears quickly after acceptance, but total handling time to that point routinely exceeds a year.

In our pre-submission review work with Applied Soft Computing manuscripts, four patterns generate the most consistent early returns. None of them are about the soft-computing method being broken. They are about novelty, honest comparison, real application, and reproducibility, the four things this journal screens for before and during peer review.

In our review of soft-computing manuscripts, each of these is a named rejection pattern you can check your own draft against, and each reflects an editorial triage pattern specific to how handling editors at Applied Soft Computing read submissions. The application-first editorial value raises the stakes on every one of these, because there is no methodological elegance argument that survives a paper with no real problem behind it.

Editors consistently screen for these before sending a manuscript out for review.

Applied Soft Computing guide for authors and Elsevier policies define the mechanics below; the patterns describe how manuscripts coming through pre-submission review for this journal most often fall short of them. Across the 5 community reviews logged for this journal on SciRev, authors report a first review round near six months, about three reports per submission, and an unusually high count of revision rounds, which is consistent with what we see: reviewers here are demanding, and most attrition happens because the novelty or the comparison cannot withstand that scrutiny.

A new metaheuristic with no genuine novelty over existing algorithms. This is the single most common stall we see, and it is specific to this field. The manuscript proposes "yet another nature-inspired algorithm," named after some animal, weather pattern, or social behavior, but strip away the metaphor and the operators are a relabeled particle swarm, differential evolution, or genetic algorithm with a new vocabulary.

The metaphor-based metaheuristic problem is well documented in the optimization literature, and editors at a soft-computing journal have seen the pattern hundreds of times. When the contribution is a new metaphor rather than a new search behavior, and the paper does not show what the algorithm does that an existing metaheuristic provably cannot, it reads as a renaming exercise.

The fix is to state the genuine algorithmic difference in operator terms, not in metaphor terms, and to show it matters.

Check whether your Applied Soft Computing algorithm shows novelty beyond an existing metaheuristic →

Results reported without statistical significance testing or fair baselines. The parallel failure is a results section that claims an algorithm "outperforms" competitors using mean values alone, with no significance test (a Wilcoxon signed-rank test or a Friedman test with a post-hoc procedure is the field standard) and baselines that are either outdated or left at default parameters while the proposed method is carefully tuned.

Reviewers in soft computing treat unfair comparison as a fatal flaw, not a presentation issue. A table of better averages with no statistical analysis, no report of standard deviation across runs, and competitors that were not tuned with the same effort reads as a result that has not actually been demonstrated.

The experiments section is where this is decided: if the comparison is not fair and the significance is not tested, the manuscript is not yet ready for this journal regardless of how good the headline numbers look.

Check if your Applied Soft Computing experiments use fair baselines and significance tests →

A benchmark-only study with no real-world application. Applied Soft Computing has "applied" in its name, and a recurring desk return is a paper that validates a method only on standard benchmark functions (the CEC suites, classic test functions) and never demonstrates it on a real problem. The manuscript is structurally a methods paper submitted to an applications journal.

Benchmark functions are fine as a sanity check, but this journal wants the method deployed on something real, an engineering design problem, a scheduling task, a forecasting application, a classification problem on real data, with a measurable outcome that matters to a practitioner. When the entire validation is synthetic benchmarks, the scope mismatch is visible immediately, and the natural home is a methods-focused venue instead.

Check whether your Applied Soft Computing manuscript demonstrates a real-world application →

Missing reproducibility: no parameter settings, no code, no shared data. The fourth pattern is a manuscript that cannot be reproduced from what it reports. The algorithm's control parameters are not fully specified, the number of independent runs is left unreported, the random-seed handling is unclear, and neither code nor data is available.

For an applied soft-computing method, this is increasingly disqualifying: a reviewer cannot verify a claimed improvement they cannot reproduce, and a practitioner cannot adopt a method whose parameters are hidden. The methods and supplementary sections are where this is decided. A complete parameter table, a stated run count, and a code-and-data availability statement convert a paper from "trust me" to "check me," and reviewers at this journal increasingly expect the latter.

This guide tells you what Applied Soft Computing editors look for; a Manusights review tells you whether YOUR paper passes that screen. A Manusights review checks the novelty claim, the baseline fairness, the statistical testing, the real-world application, and the reproducibility artifacts against the editorial bar this journal applies before and during peer review. Paid Manusights reviews include a 60-day money-back guarantee, and we do not train models on submitted manuscripts.

Before submitting, an Applied Soft Computing novelty and application readiness check tests whether your algorithmic novelty, fair-comparison evidence, and real-world application clear the editorial bar this journal applies before peer review.

This guide was built from the Applied Soft Computing guide for authors, Elsevier author policies, the Editorial Manager submission system, and Manusights pre-submission review patterns from soft-computing manuscripts. We checked the highlights requirement, the declarations, and the free-format submission model against Elsevier's own pages, and we cross-checked review-timing ranges against SciRev community data and Clarivate JCR metrics. The failure patterns describe what we see most often when soft-computing manuscripts come through pre-submission review for this journal, anchored in the well-documented metaphor-based-metaheuristic problem in the optimization literature.

Use this page before you upload, when the official instructions cannot answer the real question: whether your novelty claim, baseline fairness, statistical testing, real-world application, and reproducibility are already defensible. Source limitation: Elsevier updates format details, charges, and policies after this review date, so confirm administrative specifics against the journal's official pages before submission. To pressure-test the manuscript itself, run a manuscript readiness check.

• Expert Systems with Applications submission guide
• IEEE Transactions on Evolutionary Computation submission guide
• For the broader cluster, see the computer science journals overview.

Before you upload, run your manuscript through an Applied Soft Computing submission package check to catch the novelty, baseline, application, and reproducibility issues editors filter for on first read. The check is free to run (/ai-review) and takes a single upload.