{"id":"1b591de4-a643-4be3-9560-11dc0f1b1a24","arxiv_id":"2411.19487","paper_version":1,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"HE2C is an edge-cloud scheduler that combines feasibility checks, a linear-regression energy-accuracy trade-off handler, and a rescue module to improve on-time completion, battery life, and accuracy for latency-sensitive AI tasks.","lead":"This paper proposes HE2C, a resource management framework that decides whether each AI task runs on a battery-powered edge device or in the cloud, with a rescue module for dropping or offloading tasks under tight deadlines. It reports throughput and battery-life gains in a simulated wearable-assistive setting, but gives little detail on the central decision model and no public code or data.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The rescue module advertised as approximate-computing accuracy/latency trading is specified in Algorithm 4 only as a warm-start admission/drop check; the claimed throughput mechanism is absent and untested.","rationale":"The reader rejected HE2C because the linear-regression energy-accuracy trade-off handler in Section III-C is unspecified. That is a real gap, but I find a more load-bearing problem in the rescue module, because it is not merely under-specified: its only presented algorithm contradicts the mechanism named in the abstract. The paper's headline throughput result is attributed to approximate computing in the Abstract and to the rescue module in Section IV.D, yet Algorithm 4's decision space contains no approximation operation and no accuracy input. A warm-start admission/drop rule can change completion statistics through admission control, but it cannot demonstrate the 'trade accuracy for latency' behavior that is asserted and that is needed for the claimed holistic contribution. This is an internal inconsistency between claimed mechanism and provided specification, not a disagreement with any community consensus. The reader's regression concern remains valid and is related, so I mark partial agreement rather than agreement. Both concerns point to a manuscript in which the mechanisms central to the headline results cannot be checked from the text. No adjustment to the reader's REJECT verdict is needed.","tokens_in":7632,"tokens_out":6291,"duration_ms":54986,"concrete_test":"Analytical check: instantiate Algorithm 4 and enumerate its decision space. Its guards are δ_i > c_i, ϵ_e_i ≤ E, and warm-start status; every accepted task uses the existing edge model, and every rejected task is dropped. There is no branch that selects a lower-accuracy, lower-latency approximate model, so the algorithm cannot implement the claimed accuracy-latency trade. To settle the empirical side, rerun the Fig. 4 workload with this verbatim rescue module and with the module disabled, logging any approximate-inference call. If the ~95% completion curve is reproduced without any approximate call, the reported benefit is attributable to warm-start admission, not approximate computing; if it is not reproduced, the experiments used an unspecified mechanism that must be disclosed.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim credits the rescue module with improving on-time completion by 'leveraging approximate computing to trade accuracy for latency when necessary' (Abstract), and Section IV.D attributes roughly a 4-5 percentage-point completion-rate gain to that module. However, the rescue module's only specification, Algorithm 4, makes decisions solely from deadline δ_i, warm-start completion time c_i, edge energy ϵ_e_i, and battery E; no accuracy input appears, and no quantized, distilled, downsampled, or otherwise approximate inference is described anywhere in Section III. Section III.D's prose likewise only distinguishes dispatching to edge or dropping the task. Consequently the abstract's key throughput mechanism is not implemented in the presented algorithm. The Fig. 4 comparison can therefore only measure an admission-control difference, not an accuracy-latency trade. Either the experiments used an approximate-computing rescue that is absent from the paper, or they used Algorithm 4, in which case the abstract misdescribes the contribution; neither reading supports the claim as written.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes HE2C, a framework for allocating latency-sensitive deep learning tasks between edge and cloud resources. It comprises three components: a feasibility-check module for cloud and edge execution, a resource allocator with an energy-accuracy trade-off handler, and a rescue module described as using approximate computing to trade accuracy for latency. The evaluation uses the E2C simulator with four DL applications and reports that HE2C improves on-time task completion rates while preserving battery and accuracy. The central claim is that HE2C significantly improves throughput under strict latency and energy constraints.","tokens_in":7868,"tokens_out":4835,"duration_ms":41504,"significance":"If fully specified and verified, HE2C would be a useful holistic scheduler for latency-sensitive AI workloads in edge-cloud systems. The feasibility-check algorithms are simple and plausible, and the choice of four diverse DL applications is appropriate. However, the two most distinctive components—the energy-accuracy trade-off handler and the approximate-computing rescue module—are either unspecified or not implemented as described, and the evaluation currently provides insufficient evidence for the reported gains. The work is at the stage of a promising architecture rather than a validated system.","major_comments":[{"comment":"The energy-accuracy trade-off handler is the central decision component when both edge and cloud are feasible, but it is not specified: the text says it is based on a linear regression model [14] and lists candidate inputs (task type, estimated cloud/edge energy, cloud/edge accuracy), yet no regression equation, feature encoding, training data, fitted coefficients, or decision threshold is given. Because Section IV.C attributes the method's advantage to this handler, the reader cannot reproduce the placement decisions or assess generalization to tasks outside the training distribution. The authors must provide the full model specification and validation.","section":"Section III-C, Algorithm 3"},{"comment":"The Abstract and Section III.D present the rescue module as enhancing throughput by leveraging approximate computing to trade accuracy for latency, but Algorithm 4 contains only a warm-start admission check based on deadline, warm-start completion time, energy, and warm-start status; no accuracy input and no approximate inference variant (quantization, distillation, downsampling, or similar) appear anywhere in the paper. The completion-rate gain attributed to this module in Section IV.D (about 95% vs 90-91%) is therefore a test of admission control/dropping, not of the advertised accuracy-latency trade. Either implement and evaluate the approximate-computing mechanism or revise the contribution claims accordingly.","section":"Section III-D, Algorithm 4; Abstract"},{"comment":"The evaluation section reports only prose summaries and figure captions; no actual plots are included in the version under review, and the text gives no number of runs, error bars, confidence intervals, or statistical tests. Without these, claims such as \"consistently achieving around 95% task completion\" (Section IV.B) and \"significant advantage\" (Section IV.D) cannot be verified, and it is impossible to tell whether the reported differences (e.g., 95% vs 90-92%) are within run-to-run variability. The authors should include the figures with error bars, state the number of repetitions, and report per-condition means and variances.","section":"Section IV, Figs. 2-4"},{"comment":"There is a potential circularity risk in the evaluation: the energy-accuracy trade-off handler is a fitted regression model, and the experiments use the authors' own E2C simulator with workload traces that are not described in detail. If the same workload data were used to fit the regression and then to compare handlers, the comparison favors the fitted model by construction. The paper should specify how the regression was trained, which workloads were held out, and whether the reported results include out-of-sample tasks.","section":"Section IV.A, Section III.C"}],"minor_comments":[{"comment":"The text says the energy-accuracy handler achieves \"low latency (approximately 1-2 J)\" and later \"moderate latency (around 2-3 ms),\" mixing energy units (J) with latency units (ms); this should be corrected.","section":"Section IV.C, Fig. 3"},{"comment":"The phrase \"maximize system prolong battery lifespan\" is ungrammatical and should be rephrased.","section":"Abstract"},{"comment":"Algorithm 4 uses strict inequalities (δ_i > c_i and ϵ_e_i ≤ E), so tasks whose deadline equals warm-start completion time or whose energy consumption equals remaining battery are dropped; clarify whether equality should be feasible.","section":"Section III-D, Algorithm 4"},{"comment":"Several listed references, including [8], [10], [11], and [12], are not cited in the text; either cite them or remove them from the bibliography.","section":"References"},{"comment":"The paper would benefit from a table summarizing the workload parameters (deadline distributions, task types, model sizes, accuracy values) used in the E2C simulator, since the current description is too high-level to reproduce.","section":"Section IV.A"}],"recommendation":"major_revision","confidential_remarks":"The paper's core idea is reasonable, but the gap between the abstract and the implemented algorithms is large. I recommend treating the missing regression specification and the absent approximate-computing path as requirements, not optional polish. The version also lacks figures; if the missing figures are an artifact of the submission format, the authors should still be required to add error bars and run counts. I do not see a basis for rejection on novelty grounds, but the current evidence base is too thin for acceptance."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nI read HE2C and agree with the skeptical take. The paper's central claim about a rescue module that trades accuracy for latency via approximate computing is not backed by any algorithm or experiment in the text. Algorithm 4 does nothing but admit warm-start tasks to the edge if they meet deadline and battery checks; there is no quantization, distillation, or approximate inference anywhere. So the abstract overstates the contribution, and the 4-5 point completion-rate gain in Fig. 4 can only be attributed to warm-start admission, not accuracy-latency trading.\n\nWhat's new is limited. The paper combines known pieces: feasibility checks, offloading, and a regression-based handler. The integration is plausibly useful, but the handler is a black box: a linear regression with features listed but no coefficients, training data, or validation. The whole advantage of HE2C over simpler policies rests on this unspecified model, so the evaluation cannot be reproduced or checked.\n\nThe paper does have some strengths. Algorithms 1 and 2 are simple and clearly specified. The experimental setup is described reasonably, and the comparison of feasibility checkers versus a single-factor latency checker is a sensible experiment, even if only reported as a one-line percentage. The related work is appropriate and honest.\n\nThe soft spots are proportional. The evaluation lacks error bars, run counts, and public artifacts, so we can't judge statistical significance. The figure caption in Section IV.C mixes units (Joules and milliseconds), which is sloppy. And the rescue module description is a genuine internal contradiction with the abstract. That is not a minor omission; it's the paper's claimed key throughput mechanism.\n\nWho is this for? Someone working on edge-cloud scheduling might find the architecture a starting point, but as written it's not a complete contribution. A serious referee would need the missing model details, the rescue module implementation, and the simulator code before the claims can be evaluated. I would desk reject it and invite a resubmission with the missing information.\n\nBest.","headline":"The paper's central rescue module claim is absent from the algorithms, and the regression-based handler is unspecified, so the evaluation cannot support the headline results.","tokens_in":8357,"tokens_out":3051,"would_cite":false,"duration_ms":25767,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"HE2C claims that combining deadline-energy-memory feasibility checks, an energy-accuracy trade-off handler, and a rescue module raises on-time completion of latency-sensitive deep-learning tasks to about 95% while preserving battery and…","keywords":["edge-cloud continuum","latency-sensitive AI tasks","resource allocation","energy-accuracy trade-off","feasibility check","rescue module","approximate computing","deep learning inference scheduling"],"falsifier":"Train the energy-accuracy trade-off handler on one workload distribution, then run HE2C on a different distribution of latency-sensitive tasks (for example, larger models or very tight deadlines) and compare placements against an oracle that always chooses the site with the true lower energy cost at equal accuracy; if the handler's choices match the oracle no better than a simple 'pick cloud whenever its estimated latency is lower' rule, the claimed holistic advantage would not hold for unseen tasks.","tokens_in":7439,"feed_emoji":"⚡","tokens_out":4414,"duration_ms":34543,"temperature":0.7,"pith_summary":"The paper proposes HE2C, a task-allocation framework for deep-learning inference jobs that must finish by a deadline while running on battery-powered edge devices with cloud backup. HE2C's claim is that by checking deadline, energy, and memory feasibility on both edge and cloud before deciding, then applying an energy-accuracy trade-off model when both sites are feasible, and finally using a rescue module that trades a little accuracy for lower latency under load, a system can complete far more tasks on time without draining the wearable's battery or degrading prediction quality. The authors test this on face, text, and image recognition workloads and report on-time completion around 95%, up from roughly 90-92% without the multi-factor feasibility check or the rescue module. A sympathetic reader would take the central claim to be that holistic multi-metric admission control beats optimizing any single metric.","feed_headline":"Three-module AI scheduler keeps 95% of tasks on time","feed_subtitle":"Feasibility checks, an energy-accuracy trade-off, and a rescue module protect battery and meet deadlines.","key_machinery":"The central object is the three-stage admission-and-allocation pipeline. The load-bearing pieces are the feasibility checkers (Algorithms 1 and 2) that compare estimated end-to-end latency, energy, and memory against the task deadline and the device's remaining battery and memory; the energy-accuracy trade-off handler (Algorithm 3), a linear-regression model that scores whether cloud or edge better satisfies a task's energy and accuracy priorities when both pass feasibility; and the rescue module (Algorithm 4), which drops a task only when even a warm-start edge execution misses its deadline or would overdraw the battery. Together they convert a single-metric scheduling decision into a three-gate admission decision, and that gating is what the paper credits for the higher on-time completion rate.","core_discovery":"HE2C is a holistic edge-to-cloud scheduler for latency-sensitive deep-learning tasks. It consists of three cooperating pieces: a feasibility-check module that rejects a placement if the deadline, battery energy, or edge memory is insufficient; a resource allocator whose energy-accuracy trade-off handler uses linear regression over task type, estimated edge/cloud energy, and edge/cloud accuracy to pick the site when both are feasible; and a rescue module that, when edge resources are critically low, runs the task on the edge with a warm-start model rather than dropping it. The authors' central discovery is that this combination sustains roughly 95% on-time task completion across increasing workload volumes, preserves battery, and keeps inference accuracy near 94-97% with low latency, whereas single-metric baselines fluctuate around 90-92% completion or sacrifice one of the metrics.","pith_inferences":["The feasibility-check logic is task-agnostic and could be applied to other deadline-constrained inference workloads, including LLM-based assistants on phones or AR glasses, by swapping the per-task latency and energy estimators.","The rescue module's warm-start edge assumption implies a model-caching policy; one testable extension is to have HE2C decide which DL models to keep warm in edge memory based on predicted task mix, rather than assuming warm-start availability.","The paper's distinction between urgent and best-effort tasks (in its future-work section) suggests a natural extension: priority-aware admission control where the feasibility checkers treat deadlines as soft for best-effort tasks and hard for urgent ones.","Because the trade-off handler's regression is unspecified, a concrete follow-up is to publish the feature set and coefficients, or replace the regression with an online bandit, so the placement decision can be validated and adapted per device."],"forward_implications":["If HE2C's feasibility-check module is correct, then multi-factor admission control (deadline plus energy plus memory) should keep on-time completion near 95% even as task volume grows, where a latency-only checker degrades to roughly 90-92%.","If the energy-accuracy trade-off handler works as described, then tasks feasible on both edge and cloud can be placed by a learned score that balances energy and accuracy, sustaining accuracy around 94-97%.","If the rescue module is correct, then under resource pressure, executing warm-start edge inference instead of dropping tasks raises on-time completion from about 90-91% to about 95%.","If all three modules operate together, HE2C should extend edge battery lifespan while meeting latency constraints, which is its stated objective for wearable assistive systems."],"supporting_citations":[{"why":"Supplies the linear-regression method used by the energy-accuracy trade-off handler.","marker":"[14]"},{"why":"Provides the E2C simulator used to generate realistic edge-to-cloud execution scenarios and evaluate HE2C.","marker":"[15]"},{"why":"Edge-MultiAI is the multi-tenant latency-sensitive baseline whose approach HE2C extends with energy and accuracy awareness.","marker":"[1]"},{"why":"Performance-driven serverless load balancing baseline that HE2C extends toward a holistic latency-energy-memory view.","marker":"[2]"},{"why":"CODA is the DNN resource-contention framework contrasted with HE2C's suitability for latency-sensitive IoT.","marker":"[9]"},{"why":"FELARE is the energy-aware scheduling baseline that HE2C builds on by adding accuracy and throughput.","marker":"[13]"}],"fun_headline_variants":["Holistic edge-cloud scheduler hits 95% on-time tasks","HE2C: one scheduler, all metrics, 95% on time","Edge-cloud AI scheduler keeps 95% deadlines, saves battery","Three-part scheduler: battery, accuracy, on-time tasks","Holistic AI task allocation: 95% on time across edge-cloud"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The energy-accuracy trade-off handler is a linear regression over task type, estimated energy on each site, and accuracy on each site, but the paper does not specify the regression's features, training data, or coefficients; HE2C's reported advantage over other handlers assumes this fitted model makes correct placement choices for tasks outside its training distribution.","fun_headline_variants_meta":{"raw":{"variants":["Holistic edge-cloud scheduler hits 95% on-time tasks","HE2C: one scheduler, all metrics, 95% on time","Edge-cloud AI scheduler keeps 95% deadlines, saves battery","Three-part scheduler: battery, accuracy, on-time tasks","Holistic AI task allocation: 95% on time across edge-cloud"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000318,"raw_usage":{"total_tokens":1805,"prompt_tokens":962,"completion_tokens":843,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":578,"completion_tokens_details":{"reasoning_tokens":753}},"tokens_in":578,"tokens_out":843,"duration_ms":5900,"temperature":1.0,"reasoning_tokens":753,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T10:07:54.622021+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Train the energy-accuracy trade-off handler on one workload distribution, then run HE2C on a different distribution of latency-sensitive tasks (for example, larger models or very tight deadlines) and compare placements against an oracle that always chooses the site with the true lower energy cost at equal accuracy; if the handler's choices match the oracle no better than a simple 'pick cloud whenever its estimated latency is lower' rule, the claimed holistic advantage would not hold for unseen tasks.","supporting_citations":[{"cited_title":"Peck, and G","cited_arxiv_id":null,"evidence_quote":"Supplies the linear-regression method used by the energy-accuracy trade-off handler."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Provides the E2C simulator used to generate realistic edge-to-cloud execution scenarios and evaluate HE2C."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Edge-MultiAI is the multi-tenant latency-sensitive baseline whose approach HE2C extends with energy and accuracy awareness."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Performance-driven serverless load balancing baseline that HE2C extends toward a holistic latency-energy-memory view."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"CODA is the DNN resource-contention framework contrasted with HE2C's suitability for latency-sensitive IoT."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"FELARE is the energy-aware scheduling baseline that HE2C builds on by adding accuracy and throughput."}],"review_version":1}