IPSN Writing Style
Use this when revising the main paper. IPSN papers are read by sensor-systems and
information-processing reviewers, so they need a real sensing problem on the first page and
evidence measured on real hardware against ground truth. The failure this skill prevents is a
technically fine paper that reads like an offline ML result, or a hardware report with no measured
trade-off.
Revision rules
- Lead with the sensing problem and its physical budget: the phenomenon being sensed, why current
sensing/processing is inadequate, the contribution (an estimator/inference method and/or a
platform), the real-hardware evidence, and the energy/latency/accuracy budget that makes it
deployable.
- Make the information processing load-bearing (IP track). State the estimator, inference, or
learning method precisely enough to re-implement, and tie it to a quantity that matters (error
bound, joules, bits, latency) — not just "accuracy improved."
- Make the platform reusable and measured (SPOTS track). Give the MCU/SoC, sensor, radio, and
toolchain, and justify design choices with measured power, timing, and robustness — a datasheet is
not a contribution.
- Pair every claim with proportional, real-hardware evidence — a measured energy number, a
ground-truth-referenced accuracy, a deployment yield — not adjectives.
- Report deployments honestly. Yield, synchronization error, packet loss, and energy as
measured; an idealized deployment reads as a tell.
- Respect the ≤12-page ACM two-column budget as a design constraint; a paper that only fits by
cutting the measurement setup or the limits is over-scoped.
- Maintain double-blind in self-citations, tool/testbed names, board photos, acknowledgements,
funding, and dataset links.
Sensor-systems paper skeleton
| Section |
Job it must do |
Common failure |
| Intro |
Sensing problem, inadequacy, contribution, real-hardware evidence preview, budget — first page |
Leads with a model/technology trend, not a sensing problem |
| Background |
The modality, the platform constraints, why this is hard physically |
Motivation by assertion; no physical grounding |
| Method / System |
The estimator/inference (IP) or the platform/tool (SPOTS), reproducibly |
Method too thin to re-implement; platform under-specified |
| Evaluation |
Each claim answered with measured, ground-truth evidence |
Simulation or offline accuracy standing in for on-device/in-field results |
| Energy/latency budget |
Joules, memory, timing as measured on the real platform |
"Feasible on embedded devices" with no numbers |
| Limits / threats |
Site-specificity, generalization, calibration drift, bounded |
Generic paragraph untethered from this system |
| Related work |
Delta-first against the sensing literature |
Citation catalog with no contrast |
Sentence-level rewrites
| Draft pattern |
IPSN-safe rewrite |
| "Our method significantly improves accuracy." |
"reduces localization error to X m (95% CI ...) vs on " |
| "It is energy-efficient." |
"consumes X µJ per inference on at , measured on an instrumented rail (Table 2)" |
| "We deploy it in the real world." |
"deployed nodes for ; packet yield Y%, sync error < Z µs (Fig. 4)" |
| "Runs in real time on embedded devices." |
"end-to-end latency X ms on ; fits <RAM/flash> footprint" |
| "The model detects the event well." |
"detection rate D at F false alarms/hour on hand-labeled field audio, per site" |
Energy/latency/ground-truth discipline
[Energy] joules or µJ per operation, measured (rail/shunt/instrument named), not estimated
[Latency] end-to-end timing on the real SoC/MCU at a stated clock; number of runs
[Footprint] RAM/flash used vs available; where the model/pipeline had to shrink
[Ground truth] the reference (labels, co-located instrument, surveyed positions) and its own error
[Limits] site-specificity / calibration drift / generalization -> stated next to the result
Vignette: compressing a deployment paper
A draft with a long system tour, six figures, and a thin evaluation: keep the system description at
the level needed to reproduce, the two figures that carry the energy and yield story, a per-site
false-alarm table, and a limits subsection; move the full protocol and secondary plots to the
artifact with forward references. The test of a good cut: a reviewer should be able to answer "what
was measured, on what hardware, against what ground truth, and how well did it hold up?" from the
body alone.
Output format
[Writing diagnosis] clear / under-motivated / over-claimed / evidence-mismatched / over-scoped
[First-page fix] <new framing leading with the sensing problem and its budget>
[Claim audit] <claim -> measured evidence -> on real hardware / ground truth? yes/no>
[Budget check] <energy / latency / footprint reported? where>
[Anonymity edits] <tool/testbed names / board photos / self-citations / dataset links to fix>
Source: brycewang-stanford/Awesome-Journal-Skills → IPSN-Skills/skills/ipsn-writing-style/SKILL.md
1---2name: ipsn-writing-style3description: Use when revising an IPSN-lineage paper for a real sensing problem on the first page, a load-bearing information-processing or platform contribution, ground-truth methodology, energy/latency/accuracy budgets, honest deployment reporting, double-blind wording, and disciplined use of the ≤12-page ACM two-column budget.4---567# IPSN Writing Style89Use this when revising the main paper. IPSN papers are read by sensor-systems and10information-processing reviewers, so they need a **real sensing problem on the first page** and11evidence measured on **real hardware against ground truth**. The failure this skill prevents is a12technically fine paper that reads like an offline ML result, or a hardware report with no measured13trade-off.1415## Revision rules1617- **Lead with the sensing problem and its physical budget:** the phenomenon being sensed, why current18 sensing/processing is inadequate, the contribution (an estimator/inference method and/or a19 platform), the real-hardware evidence, and the energy/latency/accuracy budget that makes it20 deployable.21- **Make the information processing load-bearing (IP track).** State the estimator, inference, or22 learning method precisely enough to re-implement, and tie it to a quantity that matters (error23 bound, joules, bits, latency) — not just "accuracy improved."24- **Make the platform reusable and measured (SPOTS track).** Give the MCU/SoC, sensor, radio, and25 toolchain, and justify design choices with measured power, timing, and robustness — a datasheet is26 not a contribution.27- **Pair every claim with proportional, real-hardware evidence** — a measured energy number, a28 ground-truth-referenced accuracy, a deployment yield — not adjectives.29- **Report deployments honestly.** Yield, synchronization error, packet loss, and energy as30 *measured*; an idealized deployment reads as a tell.31- **Respect the ≤12-page ACM two-column budget** as a design constraint; a paper that only fits by32 cutting the measurement setup or the limits is over-scoped.33- **Maintain double-blind** in self-citations, tool/testbed names, board photos, acknowledgements,34 funding, and dataset links.3536## Sensor-systems paper skeleton3738| Section | Job it must do | Common failure |39|---|---|---|40| Intro | Sensing problem, inadequacy, contribution, real-hardware evidence preview, budget — first page | Leads with a model/technology trend, not a sensing problem |41| Background | The modality, the platform constraints, why this is hard physically | Motivation by assertion; no physical grounding |42| Method / System | The estimator/inference (IP) or the platform/tool (SPOTS), reproducibly | Method too thin to re-implement; platform under-specified |43| Evaluation | Each claim answered with measured, ground-truth evidence | Simulation or offline accuracy standing in for on-device/in-field results |44| Energy/latency budget | Joules, memory, timing as measured on the real platform | "Feasible on embedded devices" with no numbers |45| Limits / threats | Site-specificity, generalization, calibration drift, bounded | Generic paragraph untethered from this system |46| Related work | Delta-first against the sensing literature | Citation catalog with no contrast |4748## Sentence-level rewrites4950| Draft pattern | IPSN-safe rewrite |51|---|---|52| "Our method significantly improves accuracy." | "reduces localization error to X m (95% CI ...) vs <baseline> on <N real traces>" |53| "It is energy-efficient." | "consumes X µJ per inference on <MCU> at <clock>, measured on an instrumented rail (Table 2)" |54| "We deploy it in the real world." | "deployed <N> nodes for <duration>; packet yield Y%, sync error < Z µs (Fig. 4)" |55| "Runs in real time on embedded devices." | "end-to-end latency X ms on <SoC>; fits <RAM/flash> footprint" |56| "The model detects the event well." | "detection rate D at F false alarms/hour on hand-labeled field audio, per site" |5758## Energy/latency/ground-truth discipline5960```text61[Energy] joules or µJ per operation, measured (rail/shunt/instrument named), not estimated62[Latency] end-to-end timing on the real SoC/MCU at a stated clock; number of runs63[Footprint] RAM/flash used vs available; where the model/pipeline had to shrink64[Ground truth] the reference (labels, co-located instrument, surveyed positions) and its own error65[Limits] site-specificity / calibration drift / generalization -> stated next to the result66```6768## Vignette: compressing a deployment paper6970A draft with a long system tour, six figures, and a thin evaluation: keep the system description at71the level needed to reproduce, the two figures that carry the energy and yield story, a per-site72false-alarm table, and a limits subsection; move the full protocol and secondary plots to the73artifact with forward references. The test of a good cut: a reviewer should be able to answer "what74was measured, on what hardware, against what ground truth, and how well did it hold up?" from the75body alone.7677## Output format7879```text80[Writing diagnosis] clear / under-motivated / over-claimed / evidence-mismatched / over-scoped81[First-page fix] <new framing leading with the sensing problem and its budget>82[Claim audit] <claim -> measured evidence -> on real hardware / ground truth? yes/no>83[Budget check] <energy / latency / footprint reported? where>84[Anonymity edits] <tool/testbed names / board photos / self-citations / dataset links to fix>85```8687---8889**Source:** [`brycewang-stanford/Awesome-Journal-Skills`](https://github.com/brycewang-stanford/Awesome-Journal-Skills) → `IPSN-Skills/skills/ipsn-writing-style/SKILL.md`
thedixitjain