The SenSys resubmission is a contract, not a rebuttal debate. Because the two-deadline model lets a rejected paper return at the next deadline only with a substantive revision and a Response to Reviewers, the response's job is to prove that each concern the reviewers raised has been closed in the revised paper — most often with a new measurement, not an argument. A response that argues instead of measures is the most common way a resubmission fails again.
For every reviewer point, produce a row: the concern, the change you made, and where in the revised paper it now lives. This is the artifact reviewers actually read.
R2-a "Energy claim not measured; datasheet current used."
→ Change: measured average draw with a shunt at 10 kHz across a full duty cycle.
→ Where: §4.2 rewritten; Fig. 4 new power trace; Table 2 updated with measured energy.
→ Status: CLOSED with new measurement.
R1-c "Ground truth for accuracy is unclear."
→ Change: documented the reference-instrument protocol and its own error.
→ Where: App. A new; §4.3 now cites it.
→ Status: CLOSED.
R3-b "Suggest testing at 100 nodes."
→ Change: added a 40-node run (largest testbed available); discussed scaling limit.
→ Where: §4.4; limitation stated in §6.
→ Status: PARTIALLY addressed — scope noted honestly.
A systems revision usually needs new data, and energy/testbed measurements have lead time. As
soon as the reviews land, sort the blocking points (sensys-review-process) and schedule the
runs against the next deadline (sensys-workflow): a new deployment or harvesting campaign may
need weeks of wall-clock time you cannot compress. Write the response around results you will
actually have, not results you hope to have.
Not every reviewer comment earns the same response. Triage first, then spend the revision budget where it changes the verdict.
| Point type | What it needs | Response move |
|---|---|---|
| Blocking (disbelieved claim) | New measurement on real hardware | Run it; row marked CLOSED with the figure/table |
| Fixable gap | A bench run or clearer figure | Address and point to the location |
| Framing misread | Rewriting, no new data | Clarify in the paper; note the change |
| Wishlist (out of scope) | A brief, honest scoping reply | Acknowledge; do not spend the budget here |
Professional and specific. Thank reviewers once, briefly, then get to the change-map. Avoid defensiveness and avoid flattery; a SenSys committee is persuaded by measurements and honest scoping, not by rhetoric.
[ ] Every blocking concern has a row: concern → change → location → status.
[ ] Each "CLOSED" row's change is actually present in the revised PDF.
[ ] New measurements were run on real hardware, not asserted.
[ ] Partial closes are stated honestly with the scope limit named.
[ ] Response is anonymous and within the CFP's stated form/length.
[ ] The revised paper's abstract/intro reflect the strengthened evidence.
[ ] Blocking points prioritized over wishlist items in the revision budget.
[Map] the change-map: each reviewer point → change → location → status
[New data] which blocking points required new measurement, and whether it exists yet
[Schedule] can the required runs finish before the next deadline? (link to workflow)
[Honesty] partial closes named with their scope limits
[Open] any concern still unclosed and the risk it carries into the next round