AI & Machine Learning Research Manuscripts

Highly specialised requests are first checked for feasibility from this information. Please do not send confidential data through the public form; describe it first and agree secure transfer afterwards.

1. 01Enquiry and requirement assessment
2. 02Technical scoping and proposal
3. 03Execution
4. 04Quality review and delivery, with an agreed round of revisions

Read the full project workflow.

In depth: how the work is done

1. Describing data and splits

   The dataset section should explain source, size, collection conditions, preprocessing, labelling and class balance, as well as how data were split into training, validation and test sets. Splits must prevent leakage, for example by separating subjects, machines or time periods. We check that the description allows a reader to judge leakage risk and that any known limitations of the data are stated.

2. Baselines and fair comparison

   Claims of improvement need strong, properly tuned baselines, including simple methods. We check that comparisons use the same data, preprocessing and tuning effort, and that published results are not compared with results from different protocols without comment. Where a baseline is weak, we suggest that authors add a stronger one or soften the claim.

3. Metrics, uncertainty and statistical testing

   Accuracy alone can mislead on imbalanced data. Appropriate metrics, such as precision, recall, F1, AUC or error measures in engineering units, are reported with confidence intervals or repeated runs. Statistical tests compare methods where differences are small. We help present results in tables and plots that make the uncertainty visible.

4. Hyperparameters, training details and reproducibility

   Architecture, hyperparameters, optimisation settings, hardware, software versions and random seeds should be listed. Code and, where possible, trained models or data are shared. Where sharing is impossible because of confidentiality, the paper explains this and gives enough detail to approximate the work.

5. Interpretability, robustness and limitations

   Engineering users need to know when models fail. Sections on error analysis, robustness to noise or distribution shift and, where relevant, interpretability increase credibility. We encourage authors to show failure cases and state conditions under which the model should not be used.

6. Framing the engineering contribution

   A paper that shows a standard algorithm applied to a new dataset must explain what is learned about the engineering problem. We help articulate whether the contribution is a new method, a benchmark, a validated application or a lesson, and place it appropriately among prior work, avoiding hype and vague claims about intelligence.

Common pitfalls this service helps avoid

• Data leakage. Random splits across related samples inflate accuracy.
• Weak or untuned baselines. Improvements disappear against properly tuned simple methods.
• Reporting only the best run. Variation across seeds is part of the result.
• Overclaiming generality. Performance on one dataset does not imply performance elsewhere.

What good reporting looks like

Support for an AI manuscript is documented with a reporting checklist covering data, splits, baselines, metrics, uncertainty, training details, availability and limitations. The final deliverable is an author-approved manuscript. We do not alter data, metrics or results, and we do not suggest tuning on test data. No acceptance outcome is promised.

An illustrative scenario

Hypothetical example written for explanation. It is not a client case, a result or a testimonial.

Imagine a paper reporting 97 percent accuracy in detecting bearing faults. A review of the description shows that segments from the same recording appear in both training and test sets. The authors repeat the evaluation with recordings separated, obtaining 89 percent, and revise the paper to report this protocol, add a simple baseline and show confusion matrices. The paper becomes more modest and more credible.

Questions to settle before you begin

• How were my training and test sets separated?
• Which strong baselines should I include?
• How much do results vary across seeds?
• Under what conditions does my model fail?
• What is the engineering contribution beyond the algorithm?

Key terms

Data leakage

Information from test data influencing training.

Baseline

A reference method for comparison.

Confidence interval

A range expressing uncertainty in an estimate.

Distribution shift

A change between training and deployment data.

Ablation study

Removing components to see their effect.

Working together on Original Research Manuscripts projects

Manuscript engagements begin with an assessment of what you have: results, methods, figures, a draft and the target journals. We ask for the underlying data or analysis outputs, because every statement in the manuscript must trace to them. Drafting and editing proceed in stages, with queries to you whenever a claim, number or reference cannot be verified from the material supplied. Authors review and approve every version. We never invent data, results, citations or contributions, and we do not promise acceptance, which is decided by editors and reviewers.

Few projects need a single service in isolation. These are the services most often combined with this one.

• Original Research Article Writing

  Structured writing and editing support for original engineering research articles built on your genuine data, methods and findings: organising the scientific narrative, tightening the argument and preparing the manuscript to the conventions of the target journal.

• AI & Machine Learning for Engineering

  Machine-learning methods for engineering problems with physical data, designed around data quality, leakage-free validation and a clear account of when the model should not be trusted.

• Statistical & Methodological Reporting Review

  Independent review of statistical methods and reporting in a manuscript to catch errors, omissions and unsupported inferences before reviewers do.

• Software Papers

  Support for software papers that describe research software, its functionality, design, usage and validation, in the format specific journals expect.

• Data Papers

  Support for data papers that describe a dataset, its collection, quality and reuse potential, so that others can find, understand and reuse it.