mobisys-author-response

name	mobisys-author-response
description	Use when drafting a MobiSys rebuttal after round-2 reviews — working within the scope limit (correct factual errors, answer specific reviewer questions), adding only directly-responsive new results, promising camera-ready work honestly, staying double-blind, and giving the area chair a clean rationale for a mobile-systems accept decision.

MobiSys Author Response

Use this after MobiSys round-2 reviews are released. Reopen the current rebuttal instructions and length limit before drafting, because scope and mechanics are cycle-specific. The MobiSys rebuttal is narrow by design: it is not a revision and not a place to reargue the paper.

Scope discipline

• The rebuttal is for correcting factual errors in the reviews and answering specific questions reviewers posed. Stay inside that scope.
• New experiments are admissible only if they directly address reviewer feedback; alternatively, you may promise results expected by the camera-ready deadline — but only ones you can actually deliver.
• Keep the reply double-blind: no institution, authorship, private repository, or identity-revealing device/account detail.
• Use existing submitted evidence first: figures, appendix tables, device provenance, and the artifact — point to them precisely rather than restating them.

Triage

• Answer concerns that affect the decision: is the system real, is the on-device evidence sufficient, is the energy/latency claim defensible, is the contribution a system.
• Correct factual misreadings first (a reviewer who thinks you tested one device when you tested four), then address requests for a missing baseline, an energy boundary, or a break-condition experiment.
• One decision-critical point per reviewer beats an exhaustive reply; the AC reads for whether the central objection was actually resolved.

Drafting pattern

1. State the decision-critical correction or concession first.
2. Point to exact submitted evidence (figure, table, appendix, artifact).
3. Explain the systems consequence — what it means for the device claim.
4. Promise a camera-ready fix only if it adds no unsupported claim and you can deliver it.

Systems-reviewer pushback patterns

Pushback	What it signals	MobiSys-ready fix
"Evaluated on one device"	Generalization doubt	Point to the multi-device table, or promise the added device honestly
"Energy numbers are unconvincing"	Undefined instrument/boundary	Name the power monitor, sampling rate, and envelope already in App. A
"Only a 30-second benchmark"	Throttling hidden	Reference the sustained-load run and thermal trace, or promise one
"This is a better model, not a system"	Fit doubt	Re-anchor the contribution as the runtime/scheduling mechanism, with the ablation that isolates it

Response micro-example

Reviewer objection: the latency win might vanish once the device throttles. Reply skeleton:

1. Concede the concern is the right one to raise for sustained load.
2. Point to the 20-minute run in Fig. 1 and the thermal trace in App. A, already submitted.
3. Note the win holds to steady state on all four devices, with the numbers regenerable from the artifact.
4. Offer one camera-ready sentence making the steady-state result explicit in the body.

Output format

[Priority issue] <reviewer concern>
[Decision dimension] contribution / on-device evidence / energy-latency rigor / clarity
[Draft response] <MobiSys-ready anonymous text within scope>
[Evidence anchor] <figure/table/appendix/artifact item>
[Out-of-scope content removed] <reargument, identity leaks, undeliverable promises>