{"id":"1ef36823-a6c1-4e6f-8610-eac2c49eae10","arxiv_id":"2509.04736","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":6,"one_line_summary":"WatchHAR runs a two-stage IMU-plus-audio activity recognition pipeline entirely on a smartwatch: 9.3ms event detection, 11.8ms classification, 92.3% context-wise accuracy on the SAMoSA dataset.","lead":"WatchHAR is a smartwatch-only activity recognition system that uses motion and audio data to detect and classify everyday activities in real time, with no cloud processing. It matters because it suggests privacy-preserving continuous health, safety, and behavior tracking can run on off-the-shelf watches.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Reported onset latency of 0.27s is inconsistent with the 2s moving average smoothing described in §3.1; needs clarification or correction.","rationale":"The strongest claim is that WatchHAR achieves real-time on-device performance with 9.3ms event detection and 11.8ms classification, and that it outperforms prior systems. Table 1's event-detection comparison is a key piece of evidence: it shows a 93.5% F1 and a 0.27s onset latency, faster than SAMoSA's 0.62s. The onset latency number is physically inconsistent with the described 2-second moving-average smoothing, which would require at least ~1–2s of event data to reach threshold. This is not a matter of debate over evaluation protocol; it is an internal inconsistency in the reported numbers. If the latency is wrong, the paper's 'latency issues' motivation and the real-time responsiveness argument are weakened. The reader's P-LOPO concern is legitimate but secondary: the system still shows favorable LOPO and zero-shot comparisons, and the 'over 90%' accuracy claim refers to LOPO results, not P-LOPO. Therefore, the verdict remains CONDITIONAL, but the condition should include a clarification/correction of the event-detection latency measurement and the smoothing implementation. A re-implementation test would settle the issue quickly.","tokens_in":11561,"tokens_out":9242,"duration_ms":88907,"concrete_test":"Re-implement the event detector exactly as specified in Section 3.1 on the SAMoSA dataset, including the 3s rolling window, 20ms hop, and 2s moving average on output probabilities. Inject a simulated event start at a known timestamp and measure the delay until the smoothed detection output exceeds the threshold. Compare with the reported 0.27s. Also inspect the code released by the authors to see whether the moving average is applied to output probabilities or to the input signal.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central claim of a real-time, latency-optimized on-device HAR system rests partly on the event detector's responsiveness (Table 1: onset latency 0.27s, offset 0.07s). Section 3.1 states the detector uses a 3-second rolling window with 20ms hop and applies a 2-second moving average to the output probabilities to filter spurious detections. For an event starting at time 0, the first window that contains any event data ends at 0.02s, but its 3-second context is mostly pre-event data, so the model's probability will be low. To cross a typical detection threshold after moving-average smoothing, the average over the preceding 2 seconds of probabilities (i.e., predictions from windows ending between -1.73s and 0.27s) must exceed the threshold. Since the vast majority of those windows contain zero or only a tiny fraction of the event, the probability average cannot plausibly cross a threshold at 0.27s. Even with an aggressive threshold, the 2-second moving average imposes a minimum latency of roughly 1–2 seconds after the event begins to dominate the window. A 0.27s onset latency is therefore physically implausible under the described protocol, suggesting either a misreport, a different (unstated) definition of onset, or a different smoothing mechanism (e.g., applied to input IMU data rather than output probabilities). This inconsistency undermines confidence in the event detection performance numbers, which are central to the 'real-time on-device' claim. The reader's P-LOPO concern is valid but less decisive: LOPO comparisons on Semi-Naturalistic (90.4% vs 89.7%) and zero-shot In-the-Wild (28.5 vs 26.8) already favor WatchHAR, so the outperformance claim does not rest solely on P-LOPO. The latency inconsistency is a more concrete and falsifiable flaw.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents WatchHAR, a two-stage on-device HAR system for smartwatches: a lightweight IMU-only 1D CNN event detector (3-second windows, 20 ms hop, 2-second moving average) gates a multimodal classifier that fuses IMU and audio via a trainable STFT/mel preprocessing module, a MobileNetV3 audio encoder, a ConvBoost-based IMU encoder, and gated fusion. The authors report 9.3 ms event-detection and 11.8 ms classification processing time on an Apple Watch Series 7, with 5x faster inference and 47x lower FLOPs than SAMoSA, alongside 93.5% event-detection F1 and 92.34% SAMoSA classification accuracy. Additional evaluations on the Semi-Naturalistic and In-the-Wild datasets use LOPO and P-LOPO protocols, and ablations cover audio encoders, IMU encoders, and fusion methods. The paper also includes application scenarios and a limitations section acknowledging the absence of longitudinal studies and platform constraints on microphone sampling and battery metering.","tokens_in":11974,"tokens_out":5401,"duration_ms":43960,"significance":"If the reported numbers hold, this is a meaningful systems contribution: it demonstrates that multimodal audio-plus-IMU HAR can run entirely on commodity watch hardware without offloading, which addresses real privacy and latency concerns. The direct on-watch benchmarks with named tools (PyTorch 2.1.2, coremltools 7.1, Apple Watch Series 7) and the open-source release are concrete strengths, as is the trainable STFT/mel front-end that moves audio preprocessing into the network. However, the evaluation as written has significant caveats: the P-LOPO protocol uses test-participant data during training, the reported onset/offset latencies appear inconsistent with the described 2-second moving-average smoothing, and the accuracy differences against prior work are small and unreplicated. These issues do not invalidate the engineering contribution but they materially weaken the 'outperforms state-of-the-art' and 'real-time' claims as stated.","major_comments":[{"comment":"The reported onset latency of 0.27 s and offset latency of 0.07 s appear physically inconsistent with the described detection protocol. Section 3.1 states that the event detector uses a 3-second rolling window with 20 ms hop and applies a 2-second moving average to output probabilities. At t=0.27 s after event onset, the moving average is computed over predictions from windows ending in approximately [-1.73 s, +0.27 s]; the vast majority of those windows contain no event data, so the smoothed probability cannot plausibly cross a detection threshold that quickly. Similarly, a 0.07 s offset latency is impossible with a 2-second moving average, because after the event ends the smoothed output should remain high for roughly another 2 seconds. Please clarify the exact definition of onset/offset latency, the threshold used, and whether the smoothing is applied to input IMU data rather than out","section":"Section 3.1 and Table 1"},{"comment":"The P-LOPO evaluation incorporates a subset of the test participant's own data during training ('we use personalized data from public datasets'). Because WatchHAR does not perform on-device fine-tuning, a new user in deployment would have no such personalization data. The P-LOPO results (93.8% Semi-Naturalistic, 56.7% In-the-Wild) therefore overstate the out-of-box performance that a fresh user would obtain. The claimed 'outperforms state-of-the-art' on the Bhattacharya datasets rests on these P-LOPO numbers. Please report LOPO (no personalization) as the primary protocol or clearly separate the non-personalized and personalized conditions and explain how the personalization data would be obtained in a real deployment.","section":"Section 5.2 and Table 2"},{"comment":"The headline accuracy comparisons are small and are presented without any measure of uncertainty. On the SAMoSA dataset, WatchHAR's 92.34% is only 0.14 percentage points higher than SAMoSA's 92.2%; on Semi-Naturalistic P-LOPO, WatchHAR is actually lower (93.8% vs 94.3%); and on In-the-Wild the difference is 56.7% vs 55.8%. No error bars, confidence intervals, repeated runs, or statistical tests are reported. Given that the P-LOPO protocol also includes test-user data in training, these results do not support the unqualified 'outperforms' language in the Introduction and Section 5.2. Please provide variance estimates or significance tests, or soften the claims accordingly.","section":"Table 2 and Section 5.2"},{"comment":"The event-detection F1 comparison (93.5% vs 88.0%) lacks essential evaluation details: it is not stated which dataset this comparison uses, what train/test split is applied, how the detection threshold is chosen for each model, or whether SAMoSA's detector is also smoothed with a 2-second moving average. Since F1 is threshold-dependent and the smoothing directly affects both F1 and latency, the comparison is under-specified. Please report the exact evaluation protocol, threshold, and any post-processing applied to both methods.","section":"Section 5.1, Table 1"},{"comment":"The abstract claims 'over 90% accuracy across more than 25 activity classes,' but Table 2 reports a weighted F1 of only 56.7% on the In-the-Wild dataset. The claim appears to be true only for specific datasets/protocols (e.g., SAMoSA and Semi-Naturalistic LOPO/P-LOPO), not for the unconstrained in-the-wild setting that motivates the 'unconstrained environments' framing. This overgeneralized claim should be qualified to the datasets and protocols where it actually holds.","section":"Abstract and Table 2"}],"minor_comments":[{"comment":"The text refers to 'the Appendix' for per-activity confusion matrices, but no appendix is present in the arXiv v1 manuscript. Please include the appendix or remove the reference.","section":"Section 5.2 and Appendix"},{"comment":"The 'CNN1D' IMU backbone is reported as having 246.80 M parameters, which is far larger than the other IMU encoders and seems suspiciously high. Please verify this number or clarify if it includes the audio encoder or other components.","section":"Table 4"},{"comment":"The sentence 'Our system uses a two-stage detection process to balance performance and power consumption' repeats information already given in the preceding paragraph. Consider tightening the text.","section":"Section 3.1"},{"comment":"The use of 'N/A' in the P-LOPO and LOPO columns is ambiguous. Please specify which values were not reported, which are not applicable, and which were not measured.","section":"Table 2"}],"recommendation":"major_revision","confidential_remarks":"The paper has a credible systems contribution and reproducible code, but the evaluation needs substantive revision. The most serious issues are the P-LOPO protocol's inclusion of test-user data and the likely impossible latency numbers given the described smoothing. Both are fixable within the manuscript's scope by reanalysis or careful clarification. The proximity of the authors to the SAMoSA dataset/lab warrants extra scrutiny of the comparisons, but I see no evidence of misconduct; the P-LOPO concern is the concrete point to address. I recommend major revision rather than rejection."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"WatchHAR is a solid systems paper and I largely agree with the reader's conditional verdict. What's actually new: a complete audio+IMU HAR pipeline that runs entirely on an Apple Watch, with the STFT and mel filterbank folded into the network as trainable layers. That's a real engineering step, and the on-device latency/FLOPs numbers (9.3 ms event detection, 11.8 ms classification) are measured with named tools on actual hardware, which deserves credit. The code release also helps.\n\nThe soft spots are real but mostly fixable. The sharpest one is the timing inconsistency flagged in the stress test: Section 3.1 says the event detector uses a 3-second rolling window and applies a 2-second moving average to the output probabilities (Section 5.1 confirms this), yet Table 1 reports a 0.27 s onset latency. A causal 2-second moving average at t=0.27 mixes in 1.73 s of pre-event predictions; even if the raw probability jumps to 1 immediately, the smoothed output cannot cross a realistic threshold (say 0.5) that early. Either the threshold is far lower, the smoothing is applied to the input instead of the probabilities, or the latency is measured on the raw output before smoothing. The paper needs to state the threshold and the exact quantities being averaged. This is a concrete, falsifiable flaw in a number central to the title's 'real-time' claim.\n\nThe accuracy comparisons are less worrying than the reader suggests, but still thin. The 92.34% vs 92.2% on SAMoSA is indistinguishable from noise; no error bars, no significance tests. The P-LOPO protocol does include test-user data in training, which inflates the personalized numbers, but the LOPO results (90.4% vs 89.7% on Semi-Naturalistic, 28.5 vs 26.8 in the wild) already favor WatchHAR, so the outperformance claim does not rest solely on P-LOPO. Still, the abstract's 'outperforms state-of-the-art' overstates a modest margin.\n\nMissing battery measurements are a minor complaint given the paper's own limitations section, but they matter for a system pitched as continuous on-device monitoring.\n\nOverall: this deserves a serious referee, not a desk reject. The engineering is credible and reproducible enough to justify the time. But the authors should be asked to clarify the onset latency and add confidence intervals before publication.","headline":"Genuine on-device engineering contribution, but the 0.27s onset latency looks inconsistent with the stated 2-second moving average and needs to be explained before the real-time claims can be taken at face value.","tokens_in":12529,"tokens_out":4080,"would_cite":true,"duration_ms":37081,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"A smartwatch can run a full audio-and-IMU activity recognition pipeline on-device, detecting events in 9.3 ms and classifying activities in 11.8 ms while keeping over 90% accuracy across more than 25 activity classes.","keywords":["smartwatch HAR","on-device inference","multimodal sensing","IMU-audio fusion","trainable audio preprocessing","gated fusion","activity event detection","continuous activity tracking"],"falsifier":"Run the released models on a newly recruited participant with no personalized data and compare their accuracy to the reported P-LOPO numbers; also measure continuous on-watch battery drain over a full day of real use. A large accuracy drop in the first case, or a battery life too short for daily wear in the second, would undercut the deployment claim.","tokens_in":11480,"feed_emoji":"⌚","tokens_out":6302,"duration_ms":57213,"temperature":0.7,"pith_summary":"The paper tries to establish that continuous human activity recognition does not need to leave the wrist: a commodity smartwatch can run both a lightweight IMU event detector and an audio-plus-IMU activity classifier entirely on-device. If true, this removes the privacy and latency costs of cloud offload and makes always-on activity tracking viable in disconnected settings. The authors claim system-level gains—roughly 5x faster processing, 5–47x lower FLOPs, higher event-detection F1, and equal-or-better classification accuracy than prior systems—by optimizing every stage of the pipeline, including making the audio preprocessing itself trainable.","feed_headline":"On-watch activity detection hits 93.5% F1 in 9.3 ms","feed_subtitle":"Audio+inertia classification runs fully on the watch at 11.8 ms and stays above 90% across 25+ activities.","key_machinery":"The load-bearing object is the end-to-end trainable audio preprocessing module: a Short-Time Fourier Transform represented as two 1D convolutional layers (real and imaginary), a trainable mel-filter bank initialized from triangular speech filters but left free to adapt, and a log amplitude-to-DB activation. This replaces a fixed external spectrogram pipeline, so feature extraction is co-optimized with the classifier and runs on the watch's GPU. It is paired with a two-stage gating design: a lightweight depthwise 1D CNN continuously monitors 6-axis IMU data and only triggers the heavier multimodal classifier, keeping the microphone off during idle periods. Fusion is handled by a gated mechani","core_discovery":"The central claim is that a fully on-device, two-stage multimodal HAR system is not only possible but faster and cheaper than existing offload-based systems. WatchHAR uses a depthwise 1D CNN on 3-second IMU windows as a continuously running event detector; only when it fires does the system wake the microphone and run a multimodal classifier over 1-second windows of IMU and audio. The audio front end is a differentiable STFT plus trainable mel-filter bank implemented as 1D convolutions and a log activation, so preprocessing and inference form one trained module. Classification uses a MobileNetV3 audio encoder pretrained on AudioSet, a ConvBoost-based IMU encoder, and a gated fusion layer tha","pith_inferences":["The gap between LOPO and P-LOPO numbers suggests that fresh-user accuracy—without any personalized data—will be materially lower than the headline P-LOPO figures; the paper leaves on-device fine-tuning as future work, but does not build or measure it.","Because the mel filter bank is trainable and initialized from speech-oriented filters, the same architecture could be repurposed for other on-device audio tasks such as cough detection or appliance recognition, where learned filters may transfer better than fixed speech filters.","The gating design implies a power-accuracy trade-off the paper does not quantify: the energy saved by keeping the microphone off depends on how often events occur, so users with frequent activities will approach the cost of always-on audio.","With both modalities available on the watch, the gated fusion could also be used to identify which activities are primarily audible, primarily inertial, or genuinely multimodal—an interpretability extension the paper does not explore."],"forward_implications":["Continuous HAR can run without network connectivity, so privacy-sensitive audio and motion data never need to leave the watch and notifications can be immediate in remote or disconnected settings.","The reported processing times of 9.3 ms for event detection and 11.8 ms for multimodal classification make interactive, always-on activity tracking feasible on commodity smartwatch hardware.","Keeping the microphone off until an IMU-detected event means the power cost of audio sensing is paid only during actual activity, not during idle periods.","Because the audio preprocessing is trainable, the system can learn feature representations suited to human activities rather than relying on filters designed for speech recognition.","The accuracy gains on semi-controlled data do not fully transfer to in-the-wild conditions, but WatchHAR still matches or slightly beats prior work there while using an order of magnitude fewer FLOPs."],"supporting_citations":[{"why":"Provides the SAMoSA system architecture, dataset, and event-detector baseline that WatchHAR extends and compares against.","marker":"[19]"},{"why":"Supplies the Semi-Naturalistic and In-the-Wild datasets plus the LOPO/P-LOPO baselines and evaluation protocol used for the multimodal classification comparison.","marker":"[8]"},{"why":"Supplies the method of implementing STFT and mel spectrograms as 1D convolutions, which WatchHAR adapts into its trainable audio front end.","marker":"[11]"},{"why":"Defines the MobileNetV3 architecture used as the audio encoder backbone.","marker":"[14]"},{"why":"Provides the AudioSet pretraining data for the audio encoder.","marker":"[13]"},{"why":"Introduces the gated multimodal fusion idea that WatchHAR uses to combine IMU and audio embeddings.","marker":"[7]"},{"why":"Defines the ConvBoost IMU encoder architecture used for inertial feature extraction.","marker":"[21]"},{"why":"Supplies the conversion and quantization runtime used to deploy and time the models on the Apple Watch.","marker":"[5]"}],"fun_headline_variants":["Fully on-watch HAR: 9.3ms detection, 90%+ accuracy","Audio+IMU activity recognition runs entirely on smartwatch","WatchHAR: 5x faster on-device activity tracking, no cloud","Real-time HAR on smartwatch: 9.3 ms event detection, 25+ classes","Privacy-preserving activity recognition: WatchHAR does it all on-watch"],"cache_read_input_tokens":2688,"weakest_assumption_plain":"The headline personalized accuracy figures assume that part of the new user's own labeled data is already available at training time; a first-time user without that data—and with no on-device fine-tuning—would not see the same numbers.","fun_headline_variants_meta":{"raw":{"variants":["Fully on-watch HAR: 9.3ms detection, 90%+ accuracy","Audio+IMU activity recognition runs entirely on smartwatch","WatchHAR: 5x faster on-device activity tracking, no cloud","Real-time HAR on smartwatch: 9.3 ms event detection, 25+ classes","Privacy-preserving activity recognition: WatchHAR does it all on-watch"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000182,"raw_usage":{"total_tokens":1136,"prompt_tokens":722,"completion_tokens":414,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":466,"completion_tokens_details":{"reasoning_tokens":322}},"tokens_in":466,"tokens_out":414,"duration_ms":4229,"temperature":1.0,"reasoning_tokens":322,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T05:56:14.164672+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the released models on a newly recruited participant with no personalized data and compare their accuracy to the reported P-LOPO numbers; also measure continuous on-watch battery drain over a full day of real use. A large accuracy drop in the first case, or a battery life too short for daily wear in the second, would undercut the deployment claim.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the SAMoSA system architecture, dataset, and event-detector baseline that WatchHAR extends and compares against."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the method of implementing STFT and mel spectrograms as 1D convolutions, which WatchHAR adapts into its trainable audio front end."},{"cited_title":"González","cited_arxiv_id":null,"evidence_quote":"Introduces the gated multimodal fusion idea that WatchHAR uses to combine IMU and audio embeddings."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the ConvBoost IMU encoder architecture used for inertial feature extraction."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the conversion and quantization runtime used to deploy and time the models on the Apple Watch."}],"review_version":1}