/ase-writing-style

name: ase-writing-style
description: Use when shaping the prose and structure of an ASE (IEEE/ACM Automated Software Engineering) research paper, covering the automation-first first-page arc, stating the automated task precisely, keeping the tool runnable and the model-swap test in mind, threats-as-argument, and the 10+2 page discipline on the ACM acmart template.

ASE Writing Style

Write the paper so an automated-SE reviewer sees, on the first page, **what task you automate, how you automate it, and that it runs on real subjects**. ASE rewards a clearly stated automation with evidence proportional to the claim — not a systems win, not a leaderboard, and not a broad finding that would read better at FSE. The worked example in `resources/worked-examples/01-introduction.md` shows the arc before → after.

The ASE first-page arc

Lead with the automation, in this order:

1. **The automatable task** — a software-engineering task the reader recognizes (detect X, generate Y, repair Z, comprehend W), named precisely enough that a reviewer knows what "success" is. 2. **Why current automation (or manual practice) is inadequate** — what existing tools do *not* do, stated as a gap, not a literature tour. 3. **The contribution as an automation design** — the technique (analysis, generator, synthesizer, repair, learned model) and, ideally, the **tool** that embodies it. 4. **Evidence on real subjects** — real systems, credible *tool* baselines, and the metric that matches the task (not a proxy). 5. **What it automates for practice + threats posture** — the payoff, with the central threat named where it lives, not deferred to a closing paragraph.

Put the automation and the first evidence within the first three pages; the early-rejection gate means a weak opening can end the process before rebuttal.

State the automated task precisely

• Name the **input**, the **output**, and the **success criterion** of the automation. "We improve

code quality" is not a task; "given a flaky test, synthesize a patch that makes it deterministic without weakening its assertions" is.

• Say what the tool **takes as input** in practice (source? bytecode? traces? a repository?) and

what it **produces** — reviewers map this straight to feasibility.

Keep the model-swap test in view

If a learned component is involved, write so the **automation design is the contribution**, not the model. Report an **ablation** that isolates the learned part from the analysis/oracle, and phrase claims so the software-engineering lesson survives a model swap. A paper whose lesson evaporates when the model changes reads as an ML re-route (see `ase-topic-selection`).

Evidence proportional to the claim

• A **detection** claim needs precision/recall on real defects with a defined ground truth.
• A **generation/synthesis** claim needs validity of the generated artifact (does it compile, pass,

hold the property?), not just similarity to a reference.

• A **repair** claim needs verified behavior change (re-run, oracle), not a classification score.
• A **speed/scalability** claim needs real-system sizes and a fair baseline configuration.

Pair every claim in the abstract with a table or figure it points to. Match evidence to claim shape; see `ase-experiments`.

Threats as argument, not boilerplate

Argue construct, internal, and external validity where they arise. For automated-SE tools the usual suspects: the **oracle** (how do you know a "repair" is correct?), **subject selection** (are the systems representative or self-selected?), **baseline fairness** (equal budgets/tuning?), and **overfitting** to the evaluation set. Name the residual threat plainly and bound it (an audited subsample, a held-out subject set) rather than reciting a checklist.

Page-budget discipline (10 + 2)

• **10 pages** for everything readable — text, figures, tables, appendices — **plus 2** for

references only. The mandatory **Data Availability Statement** after Conclusions counts inside the 10 pages.

• Recover space **editorially**, not by shrinking the template. Move reproducible detail (full

configs, extra tables, proofs) to the artifact, but nothing that *decides acceptance* may live outside the body (see `ase-supplementary`).

• Figures earn their space by carrying an argument (the automation's pipeline, a

per-root-cause breakdown), not by decorating it.

Prose conventions

• Present tense for what the tool does; past tense for what you did in the study.
• Name the tool once, early, and use it consistently (anonymized at submission).
• Prefer concrete verbs of automation — *detects, synthesizes, localizes, repairs, infers* — over

vague ones like *leverages* or *explores*.

• Third-person self-citation throughout, for double-anonymity.

Common ASE writing failures

| Failure | Why it hurts at ASE | Fix | |---|---|---| | Model/leaderboard framing | Reads as ML, not automated SE | Foreground the automation design; add the ablation | | Vague task statement | Reviewer cannot judge success | Give input/output/success criterion in ¶1 | | Proxy-metric evaluation | Evidence does not match a repair/synthesis claim | Verify the produced artifact directly (re-run/oracle) | | Threats as a closing recital | Construct/oracle validity never engaged | Argue each threat where it arises; bound it | | Body over 10 pages | Desk-reject-grade | Move reproducible detail to the artifact |

Output format

[Task] input -> output -> success criterion (one sentence, on page 1?)
[Automation-first arc] task / inadequacy / technique+tool / real-subject evidence / payoff+threats — all present?
[Model-swap] ablation isolating the learned component present? lesson survives a model swap?
[Evidence-claim pairing] each abstract claim -> a table/figure with a matching metric
[Budget] content pages / reference pages / Data Availability inside 10pp?