SenSys Workflow

A SenSys campaign is governed by two facts the calendar imposes: SenSys runs two submission deadlines per cycle, and its evidence is physical, so the schedule is dominated by wall-clock time you cannot compress — a 47-day deployment takes 47 days. This skill turns the cycle into a backward schedule that leaves room for the measurements and, if needed, the resubmission.

Anchor the calendar first

Before scheduling anything, pin down against the live CFP and HotCRP /deadlines page:

• Which deadline you are targeting (first or second) and which edition it feeds. As of 2026-07-09 the open gate is SenSys 2027 (New York, May 10-13, 2027), with a first-round deadline of June 6, AoE; the second-round deadline is 待核实.
• The AoE cutoff, converted per coauthor.
• Whether an abstract-registration step precedes the paper upload this edition.

Treat the numbers here as a 2026-27 snapshot; the live page controls.

Backward schedule from the deadline

Deployment and energy campaigns, not writing, are the long pole. Schedule from T-0 (paper cutoff) backward:

The overlap is deliberate: writing starts while later deployment runs finish, because you cannot begin the 6-week deployment at T-4.

Budget for the two-deadline reality

The two-deadline model changes planning in a way a single-deadline venue does not:

If targeting the FIRST deadline:
  - A reject can resubmit at the SECOND deadline — but only WITH a substantive revision.
  - Reserve testbed time AFTER the first notification for the new measurements a revision needs.

If targeting the SECOND deadline as a resubmission of a first-deadline reject:
  - The revision + Response to Reviewers is REQUIRED, not optional (sensys-author-response).
  - Back-schedule the new deployment/energy runs against the second cutoff BEFORE you commit.

A blocking reviewer objection that needs a fresh energy-harvesting deployment cannot be answered in two weeks — decide at notification whether the resubmission is feasible on the calendar, not after you have already missed the window to start the runs (sensys-review-process).

Sequence the whole cycle

1. Fit          → sensys-topic-selection (is it SenSys after the merger?)
2. Build        → hardware + instrumentation; reserve the testbed
3. Measure      → sensys-experiments + sensys-reproducibility (traces captured live)
4. Write        → sensys-writing-style + sensys-supplementary + sensys-related-work
5. Submit       → sensys-submission (audit the exact PDF; HotCRP fields verbatim)
6. Notification → sensys-review-process (classify), then:
     accept     → sensys-artifact-evaluation + sensys-camera-ready
     resubmit   → sensys-author-response, back-scheduled to the next deadline

Standing risks to track

• Testbed contention — shared hardware is the schedule's single point of failure; reserve early.
• Deployment failures — a node dying mid-run is normal; build slack for a re-run.
• Provenance loss — capture energy method and ground truth before teardown, not after.
• Edition drift — re-confirm which edition your deadline feeds each cycle; it can shift.

Output format

[Target]   which deadline + which edition it feeds + AoE cutoff in local time
[Longpole] the deployment/energy campaign duration and its start-by date
[Schedule] backward plan T-0 → T-16wk with the freeze and audit points
[Resub]    if a reject, is a next-deadline resubmission feasible on the calendar? Y/N
[Open]     the scheduling risk most likely to break the plan