sensys-topic-selection
GitHub用于判断项目是否适合投稿至SenSys会议。基于2026年合并后的范围，评估工作是否为在嵌入式约束下构建并实测的系统，而非纯算法或移动网络机制，并据此路由至MobiCom、MobiSys等合适 venue。
触发场景
安装
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill sensys-topic-selection -g -y
SKILL.md
Frontmatter
{
"name": "sensys-topic-selection",
"description": "Use when deciding whether a project belongs at SenSys after the 2026 merger absorbed IPSN and IoTDI — testing whether the contribution is a built, measured sensing\/embedded\/IoT\/on-device-AI system rather than a pure algorithm, a mobile-networking mechanism, or an offline ML result, and routing misfits to MobiCom, MobiSys, or an ML\/DSP venue."
}
SenSys Topic Selection
SenSys accepts a system you built and measured under embedded constraints. The 2026 merger of SenSys, IPSN, and IoTDI widened the mandate — low-power networked sensing, embedded systems, IoT, and on-device AI now share one venue — but it did not soften the systems bar: a strong SenSys paper still has a buildable mechanism whose value is shown in energy, latency, memory, and deployment behavior on real hardware, not in a proof or a leaderboard delta.
The fit test
Ask these in order; a "no" is a routing signal, not a verdict on the work's quality.
- Is there a system? Can you point to the artifact — firmware, a node, a protocol, a deployment — that embodies the contribution? A pure algorithm with no embedded realization is a signal-processing or ML contribution.
- Do embedded constraints bind? Does energy, memory, compute, bandwidth, or intermittent power actually shape the design? If the method would run unchanged on a workstation, the constraint is not doing work and SenSys is a weak fit.
- Is the evidence physical? Are the headline numbers measured on hardware — current draw, duty cycle, on-device latency, deployment uptime — or are they simulation/offline accuracy? SenSys reviewers discount simulation-only and single-run results.
- Is sensing or embedded computation central? SenSys is about turning physical signals into information under resource limits, or computing on constrained nodes — not about the wireless link itself (that is MobiCom) or the mobile application platform (that is MobiSys).
Routing table
| If the core contribution is... | The likely home is... | Because |
|---|---|---|
| A built sensing system measured on real hardware for energy/latency/accuracy | SenSys | The merged venue's center of mass |
| Low-power networked sensing / mote-class protocols (formerly IPSN) | SenSys (post-merger) | IPSN's community joined SenSys in 2026 |
| IoT design/implementation, edge deployments (formerly IoTDI) | SenSys (post-merger) | IoTDI's community joined SenSys in 2026 |
| An on-device / TinyML model with measured footprint on an MCU | SenSys | Embedded-AI systems are in-scope after the merger |
| A wireless link, PHY/MAC, or over-the-air networking mechanism | MobiCom | The mechanism is the radio, not the sensing system |
| A mobile-platform / smartphone systems contribution | MobiSys | The platform, not embedded sensing under energy limits |
| A new estimator/algorithm with no embedded realization | an ML or DSP venue | The contribution is the math, not a built system |
| A datacenter/OS/networking systems result | NSDI / OSDI / SIGCOMM | Not sensing/embedded and not energy-bound |
Post-merger boundary calls
The merger creates new adjacencies to reason about explicitly:
- On-device AI vs. an ML paper. If the novelty is model architecture or accuracy, it is an ML venue. If the novelty is running inference within a real MCU's RAM/flash/energy budget — quantization-for-hardware, intermittent-power inference, on-sensor compute — it is SenSys.
- IoT deployment vs. an applications paper. A deployment is SenSys when the system design or measurement methodology is the contribution, not merely that a known stack was installed.
- Sensing vs. signal processing. A new algorithm belongs at a DSP venue unless it is embodied and measured on the constrained node where it must actually run.
Fit self-check (answer before choosing SenSys):
[ ] There is a concrete built system/artifact, not only a method.
[ ] An embedded constraint (energy/memory/compute/power) shapes the design.
[ ] Headline numbers are measured on real hardware, not simulation-only.
[ ] Sensing or on-node computation — not the radio or the app platform — is central.
[ ] If on-device AI: the claim is measured footprint/latency, not offline accuracy.
When two venues both fit
Some work genuinely spans SenSys and MobiCom (e.g. a sensing system that also innovates on its link). Route by where the reviewable novelty lives: if a reviewer would spend most of their judgment on the sensing/embedded system and its energy behavior, submit to SenSys and treat the link as engineering; if the defensible novelty is the wireless mechanism, submit to MobiCom. Pick one — a paper straddling both usually reads as under-contributing to each.
Output format
[Verdict] SenSys fit: strong / plausible / weak
[System] the concrete artifact that embodies the contribution
[Constraint] which embedded limit binds the design (energy/memory/compute/power)
[Evidence] hardware-measured? or simulation/offline (a re-route risk)
[Reroute] if weak — target venue + the one sentence that would move it
[Open] any post-merger boundary ambiguity to resolve before committing
版本历史
- 9f86f09 当前 2026-07-19 17:41
