ICDE Writing Style
Use this when revising the main paper. ICDE papers must state, compactly, what
data-engineering primitive is new and give a builder enough to reconstruct it, all inside a
tight IEEE two-column budget.
Revision rules
- Put the data-engineering contribution on the first page: the bottleneck, why current
systems fall short, the mechanism, the measured evidence, and who can build on it.
- Name the bottleneck and the operating point. A systems claim without a workload,
hardware, and cost metric is unfalsifiable and reads as marketing to an ICDE reviewer.
- Make the mechanism reconstructable. The reader should be able to rebuild the core idea
from the body; "a novel structure" is not a mechanism.
- Pair every performance claim with a figure, table, or measured crossover, and disclose
the cost of every gain — ICDE reviewers distrust a win with no accounting.
- Use a running example (one concrete workload) introduced early and reused; it carries
intuition through the paper more efficiently than repeated abstraction.
- Because ICDE is single-blind, write in natural first person and cite your own prior work
directly — do not perform the anonymity contortions a double-blind venue requires.
Mechanism-presentation discipline
- State the one idea in a single sentence before the details ("move ordering off the write
path"). Everything else is elaboration.
- Give the algorithm as pseudocode or a labeled figure, then walk it on the running example;
builders read the walk, not the prose.
- Keep problem-dependent costs visible — write amplification, memory overhead, tail
latency; silently omitting the cost of a mechanism is a standing ICDE complaint.
- Define notation and system parameters once, in one place; two-column pages punish redundant
redefinition.
- Separate what is measured from what is argued; label conjecture as conjecture.
Sentence-level rewrites
| Draft pattern |
ICDE-safe rewrite |
| "Our system is much faster..." |
"sustains 1.2M inserts/s where the LSM baseline stalls above 0.9M (Fig. 4)" |
| "Under realistic workloads..." |
"On the fleet-telemetry trace and a swept append-to-scan generator..." |
| "A novel index structure..." |
"A two-tier index that defers ordering to read time" |
| "Achieves state-of-the-art..." |
Claim scoped to the workloads and hardware actually tested |
| "With negligible overhead..." |
"at a memory cost of X and a median read-latency factor of Y (Table 3)" |
Vignette: compressing into 12 IEEE two-column pages
A draft with a full protocol, six figures, and a sprawling related-work section: keep the
mechanism, the pseudocode, the two decision-critical figures (the throughput plot and the
cost/crossover plot), and the ablation that isolates the mechanism. Compress related work into
contrast sentences, and move secondary sweeps, full trace documentation, and extra baselines to
the supplement with explicit forward references. The test of a good cut: a reviewer can
reconstruct the system and believe the headline number without opening the supplement.
Output format
[Writing diagnosis] clear / under-specified / overclaimed / overloaded
[First-page fix] <new framing: bottleneck -> mechanism -> evidence>
[Claim discipline] <claim -> figure/table/crossover, with cost disclosed>
[Mechanism clarity] <is the one idea reconstructable? gap if not>
[Compression cuts] <move / delete / merge to fit 12 pages>
1---2name: icde-writing-style3description: Use when revising an IEEE ICDE paper for the first-page data-engineering contract, a reconstructable mechanism description, the running-example device, performance claims scoped to the workloads actually run, single-blind first-person phrasing, and 12-page IEEE two-column compression that survives a builder-heavy program committee.4---56# ICDE Writing Style78Use this when revising the main paper. ICDE papers must state, compactly, what9data-engineering primitive is new and give a builder enough to reconstruct it, all inside a10tight IEEE two-column budget.1112## Revision rules1314- Put the **data-engineering contribution on the first page**: the bottleneck, why current15 systems fall short, the mechanism, the measured evidence, and who can build on it.16- Name the **bottleneck and the operating point**. A systems claim without a workload,17 hardware, and cost metric is unfalsifiable and reads as marketing to an ICDE reviewer.18- Make the **mechanism reconstructable**. The reader should be able to rebuild the core idea19 from the body; "a novel structure" is not a mechanism.20- Pair every performance claim with a **figure, table, or measured crossover**, and disclose21 the **cost** of every gain — ICDE reviewers distrust a win with no accounting.22- Use a **running example** (one concrete workload) introduced early and reused; it carries23 intuition through the paper more efficiently than repeated abstraction.24- Because ICDE is **single-blind**, write in natural first person and cite your own prior work25 directly — do not perform the anonymity contortions a double-blind venue requires.2627## Mechanism-presentation discipline2829- State the **one idea** in a single sentence before the details ("move ordering off the write30 path"). Everything else is elaboration.31- Give the algorithm as pseudocode or a labeled figure, then walk it on the running example;32 builders read the walk, not the prose.33- Keep **problem-dependent costs visible** — write amplification, memory overhead, tail34 latency; silently omitting the cost of a mechanism is a standing ICDE complaint.35- Define notation and system parameters once, in one place; two-column pages punish redundant36 redefinition.37- Separate **what is measured** from **what is argued**; label conjecture as conjecture.3839## Sentence-level rewrites4041| Draft pattern | ICDE-safe rewrite |42|---|---|43| "Our system is much faster..." | "sustains 1.2M inserts/s where the LSM baseline stalls above 0.9M (Fig. 4)" |44| "Under realistic workloads..." | "On the fleet-telemetry trace and a swept append-to-scan generator..." |45| "A novel index structure..." | "A two-tier index that defers ordering to read time" |46| "Achieves state-of-the-art..." | Claim scoped to the workloads and hardware actually tested |47| "With negligible overhead..." | "at a memory cost of X and a median read-latency factor of Y (Table 3)" |4849## Vignette: compressing into 12 IEEE two-column pages5051A draft with a full protocol, six figures, and a sprawling related-work section: keep the52mechanism, the pseudocode, the two decision-critical figures (the throughput plot and the53cost/crossover plot), and the ablation that isolates the mechanism. Compress related work into54contrast sentences, and move secondary sweeps, full trace documentation, and extra baselines to55the supplement with explicit forward references. The test of a good cut: a reviewer can56reconstruct the system and believe the headline number without opening the supplement.5758## Output format5960```text61[Writing diagnosis] clear / under-specified / overclaimed / overloaded62[First-page fix] <new framing: bottleneck -> mechanism -> evidence>63[Claim discipline] <claim -> figure/table/crossover, with cost disclosed>64[Mechanism clarity] <is the one idea reconstructable? gap if not>65[Compression cuts] <move / delete / merge to fit 12 pages>66```
brycewang-stanford