{"id":"4f0a7c77-d5b0-4a45-b49c-f4ef436588b4","arxiv_id":"2506.02003","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A state-of-practice survey that maps the edge-cloud continuum through a developer-oriented five-area conceptual framework.","lead":"A survey of edge-cloud continuum computing that organizes the field into a five-area framework and compares public and private deployment platforms. It aims to be a practical guide for developers building applications across edge and cloud layers.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Table 1's quantitative layer characteristics are presented as general facts but rest on a single EU roadmap; the practical-guide claim depends on these values.","rationale":"The reader's weakest-assumption analysis identifies precisely the concern that matters most: Table 1 presents quantitative layer characteristics as reliable, general facts, but they originate from a single European Commission roadmap with no caveat. I agree this is the load-bearing issue. The survey's strongest claim is that it is a practical guide for developers, and the quantitative layer comparison is the most concrete support for that claim. If the cost, latency, and power figures are policy-level estimates or are misinterpreted, developers using the table could select the wrong layer for their workload, directly undermining the practical-guide framing. The secondary issue noted by the reader, the absence of a documented literature-selection methodology, also weakens the auditability of the 'state-of-practice' claim, but it is less decisive than a quantitative table that is presented as comprehensive comparison. The paper is still a useful qualitative synthesis of architectures, paradigms, platforms, and tools, so the appropriate outcome is a conditional acceptance with requested revisions, matching the reader's verdict. No change to the verdict is needed.","tokens_in":32854,"tokens_out":3738,"duration_ms":34909,"concrete_test":"Obtain the European Commission roadmap [48] and trace every numeric cell in Table 1 (size, distance, latency, bandwidth, cost, power) to a specific passage, noting the roadmap's stated scope and date. Then, for a representative microservice workload, collect latency, power, and cost ranges from public provider documentation for AWS Local Zones, Azure Edge Zones, and an on-premise edge node. If Table 1 values cannot be traced to [48] or fall outside the measured provider ranges, the table must be reframed as illustrative, sourced per row, and the 'practical guide' claim should be correspondingly tempered.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is that it closes the practical-implementation gap and serves as a developer-oriented guide. For that claim to hold, the comparative information developers would actually use must be reliable. Table 1 is the main quantitative decision aid: it assigns latency, distance, cost, power consumption, and scalability ranges to the five continuum layers. Yet the entire table cites only one source, the European Commission roadmap [48], with no error bars, no scope qualifiers, and no indication that these are planning-level estimates rather than measured operational values. The text even states that 'modern cloud deployments can average around 2.9 billion euros per deployment,' which reads like a conflation of roadmap investment totals with per-deployment cost. A developer choosing between far edge and near edge on the basis of the stated 2–5 ms versus 10–20 ms latency, or the 0.5 M€ versus 10 M€ cost row, would be making decisions on numbers that are not substantiated as general properties of the layers. If [48] is a policy roadmap and not an empirical study, the table overstates its authority. This is load-bearing because the survey's differentiated value over prior surveys is practical guidance, and Table 1 is one of the few places where that guidance is quantitative.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper presents a state-of-practice survey of the edge-cloud continuum. It introduces a five-area conceptual framework (distributed architecture, paradigms/models, technologies, deployment platforms, applications/tools) and uses it to organize a broad literature review. The paper aims to close a perceived gap in prior surveys by adopting a developer-oriented perspective: it provides architectural layer taxonomies, quantitative layer characteristics (Table 1), platform comparisons including edge-specific enabling services (Table 4) and global infrastructure maps (Figure 4), technology and orchestration comparisons (Tables 2 and 3), as well as application domains, benchmarking tools, maintenance practices, open challenges, and future trends. The central claim is that the survey serves as both a practical guide for developers and a structured reference for researchers.","tokens_in":33088,"tokens_out":4288,"duration_ms":35188,"significance":"If the quantitative claims and platform comparisons are made reliable, this survey would be a useful entry point for practitioners and researchers entering the edge-cloud continuum field. The paper's strengths are its broad and well-referenced coverage (201 references), its explicit research questions, the comparative tables at the end of each section, and its attempt to bridge academic methods with industrial offerings from AWS, Azure, Google, Alibaba, Huawei, and Tencent. The framework is a classification rather than a derivation, so there is no risk of circularity. However, the practical-guide value depends critically on the credibility of Table 1 and Figure 4, which currently contain unsupported or internally inconsistent quantitative data. The survey is potentially publishable after those load-bearing data quality issues are fixed.","major_comments":[{"comment":"The quantitative layer characteristics (latency, cost, size, power) are presented as general properties of the five continuum layers, but the only source cited for distance and power is the European Commission roadmap [48], and latency and cost are asserted without any source. In particular, the sentence 'modern cloud deployments can average around 2.9 billion euros per deployment' appears to conflate the EU roadmap's aggregate investment figure with a typical per-deployment cost; such a number is not meaningful as an average cost of a cloud deployment. Because the survey's stated value proposition is developer-oriented practical guidance, and Table 1 is the main quantitative decision aid offered, these unsupported and implausible numbers undermine the central claim. Please replace the cost row with scoped, sourced estimates (e.g., per-capacity or per-datacenter costs), add error bars or ranges, and cite measured sources for the latency values.","section":"Section 4.2, Table 1"},{"comment":"There is an internal inconsistency between Table 1 and Figure 4. Table 1's Size row lists 'Cloud <10' and the accompanying text says the cloud layer operates with 'few globally distributed data centers,' but Figure 4 and the text in Section 7.1 report 36 AWS regions, 65 Azure regions, 41 Google Cloud regions, and 28 Alibaba Cloud regions. Even a single provider exceeds the <10 figure, so the Size definition must be clarified (e.g., number of data centers, number of device endpoints) and the values reconciled. As written, a reader cannot trust either the layer comparison or the platform comparison.","section":"Section 4.2 (Table 1) vs. Section 7.1 (Figure 4)"},{"comment":"The global infrastructure counts in Figure 4 are taken from a third-party map (cloudinfrastructuremap.com, updated February 2025) without caveats about the source's methodology, the definition of 'near-edge zone,' or the rapidly changing nature of provider footprints. Since the platform evaluation with geographic distribution is one of the paper's claimed contributions over prior surveys, please cross-check the counts against official provider documentation (or explicitly label them as approximate third-party data with a date and method), and state what counts as a 'near-edge zone' for each provider.","section":"Section 7.1, Figure 4"},{"comment":"Table 2 contains a duplicated 'Scalability' row with inconsistent values: the first Scalability row reports Docker Swarm as 'High' and Rancher as 'High', while the second Scalability row reports Docker Swarm as 'Small' and Rancher as 'Medium'. A comparison table that contradicts itself cannot support the paper's advertised 'comparative analysis tools' contribution. Remove the duplicate row or reconcile the values with the cited sources.","section":"Section 6.3, Table 2"}],"minor_comments":[{"comment":"The 'Size' row lacks a clear unit definition (number of devices? number of data centers?) and mixes quantities of different kinds; please define the unit and add a note about the time frame or region scope.","section":"Section 4.2, Table 1"},{"comment":"The 'Network bandwidth' row uses units like 'KBps-MBps' and 'Gbps-Tbps' without defining whether they are per-node, per-link, or aggregate; please state the measurement context.","section":"Section 4.2, Table 1"},{"comment":"Typo: 'client-sever' should be 'client-server'.","section":"Section 5.2"},{"comment":"The sentence 'particularly useful in distributed enterprise applications and IoT ecosystems where [185]' is grammatically incomplete; it should be reworded, e.g., 'particularly useful in distributed enterprise applications and IoT ecosystems, as discussed in [185].'","section":"Section 6.2, AMQP paragraph"},{"comment":"In the Google Cloud row, 'Google Coral Edge TPU' is a hardware accelerator, not a cloud service; please relabel the column header to 'Edge AI hardware/toolkit' or add a clarifying footnote.","section":"Section 7.1, Table 4"},{"comment":"Typo: 'The ELK Stack is situable' should be 'is suitable'.","section":"Section 8.3, Logging"}],"recommendation":"major_revision","confidential_remarks":"This is a broad survey with a practical orientation, and the central idea is defensible. The main risk is not the framework but the reliability of the quantitative and platform-comparison data, which currently contains a clear misreading of the EU roadmap figure and an internal inconsistency between Table 1 and Figure 4. These are fixable within the scope of the paper, so I recommend major revision rather than rejection. I also note that the duplicated Scalability row in Table 2 suggests the manuscript would benefit from a careful data-checking pass before resubmission."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nThis is a solid survey. The developer-centric angle is the real differentiator: it organizes the continuum into five areas (architecture, paradigms, technologies, platforms, applications/testing) and actually compares vendor offerings across near-edge, far-edge, on-premise, and on-device layers. The tables on FaaS frameworks, orchestrators, and cloud edge services are the most useful part—they're current, concrete, and directly actionable. The five-area framework is a reasonable organizing device, not a deep theoretical contribution, but it works.\n\nThe paper is well-cited and the qualitative descriptions match what I know of the field. It doesn't claim new experimental results, so there's no circularity burden. Self-citations appear as background references, which is fine.\n\nNow the soft spots. The stress-test note is right about Table 1. Those quantitative layer characteristics—latency, distance, cost, power—are presented as if they're general properties of the layers, but the whole table traces to one European Commission roadmap [48]. No error bars, no scope qualifiers. The text even says \"modern cloud deployments can average around 2.9 billion euros per deployment,\" which reads like a conflation of roadmap investment totals with per-deployment cost. A developer picking between far edge and near edge based on the 2–5 ms versus 10–20 ms latency rows would be making a decision on numbers with unstated provenance. That's a real weakness, but it's localized to one table and a few sentences; the rest of the survey's guidance is qualitative and well-sourced.\n\nSecond, there's no documented literature selection methodology. The paper calls itself a \"state-of-practice\" survey, but we're not told how the literature was collected or screened. That makes the coverage hard to audit and the \"gap\" claim a bit self-serving. This is a moderate concern for a survey, not a fatal one.\n\nThe Figure 4 region counts come from a third-party map of cloud infrastructure, which is okay if marked as a snapshot (it is dated Feb 2025), but those numbers will age quickly.\n\nOverall, the central argument holds: this is a useful reference for developers entering the edge-cloud space and for researchers wanting a structured map of the field. It's not groundbreaking, but it doesn't need to be. It deserves serious peer review, and the revisions are straightforward: caveat Table 1, state the selection methodology, and fix the 2.9B sentence. I'd take it.\n\nRecommendation: yes, send it to peer review. It will be a solid reference after minor revision.","headline":"A useful, well-organized survey that gives developers a practical map of the edge-cloud continuum, but its most quantitative table rests on a single policy roadmap and should be read as planning-level estimates, not measured values.","tokens_in":757,"tokens_out":1383,"would_cite":true,"duration_ms":22235,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This survey organizes the edge-cloud continuum into a five-area conceptual framework—architecture, paradigms, technologies, platforms, applications—that serves as a practical developer's guide.","keywords":["edge-cloud continuum","edge computing","cloud computing","distributed systems","service distribution","developer-centric survey","multi-layer architecture","benchmarking tools"],"falsifier":"Measure end-to-end latency, bandwidth, and deployment cost for the same workload at on-device, far-edge (e.g., AWS Wavelength), near-edge (e.g., AWS Local Zones), and cloud (e.g., a major AWS region), and compare the results against Table 1's ranges; if the observed values systematically fall outside those ranges, the layer characterization that anchors the framework's practical guidance does not hold.","tokens_in":32641,"feed_emoji":"☁️","tokens_out":7377,"duration_ms":53227,"temperature":0.7,"pith_summary":"The paper argues that the edge-cloud continuum—the multi-layer span from on-device sensors to centralized cloud data centers—has grown too fragmented for practitioners to navigate, and that existing surveys have stayed too academic to help. It sets out to establish a developer-centric, state-of-practice synthesis: a five-area conceptual framework covering distributed architecture, paradigms and models, enabling technologies, deployment platforms, and application domains. The payoff, if the framework holds, is a single structured reference a developer can use to choose layers, technologies, and platforms, and a researcher can use to locate open problems. The survey's distinctive contribution is comparative: it maps the five architectural layers to quantitative characteristics, compares orchestration and FaaS frameworks, and positions each major cloud provider's edge services across the layers.","feed_headline":"Five areas organize the edge-cloud continuum for developers","feed_subtitle":"Ties fragmented research and industry practice into one developer-oriented guide.","key_machinery":"The central object is the five-area conceptual framework (architecture; paradigms and models; technologies; deployment platforms; applications, use cases, and testing tools), anchored by a five-layer architectural model (cloud, near edge, far edge, on-premise, on-device) and quantified in Table 1. The framework works by cross-cutting each layer with performance characteristics and each platform with the continuum layers it serves, producing comparison tables (orchestration tools, FaaS frameworks, provider edge services) that turn the fragmented literature into decision points.","core_discovery":"The paper's central claim is that a coherent, practitioner-oriented view of the edge-cloud continuum is possible and has been missing. It proposes a five-layer architecture—cloud, near edge, far edge, on-premise, on-device—classified by proximity to the cloud, and populates each layer with hardware, latency, bandwidth, cost, energy, tenancy, and privacy characteristics. On top of this it layers paradigms (computational, communication, deployment), enabling technologies, public and private platforms, and application domains, with comparative tables throughout. The intended upshot is that a developer can use the framework to decide where to place computation and which platform services to adopt, while researchers get a structured map of open challenges such as interoperability, orchestration, security, energy, and standardization.","pith_inferences":["The five-layer abstraction could be tested empirically: building the same workload at two different layers and comparing observed latency, cost, and energy against Table 1 would show whether the quantitative anchors hold; the survey provides the structure but not the measurements.","Because Table 1's numbers come from a single road-mapping source, a natural extension is a community-maintained, measured version of the layer characteristics that tracks provider latency and pricing as they evolve.","The developer-centric framing exposes a tooling gap the paper only names: no unified programming abstraction yet spans the continuum, so following the practical guide may push developers toward the very standardization challenge listed as open.","The provider comparison implies a migration path—workloads built on AWS Outposts or Azure Stack Edge could move across layers as latency or sovereignty requirements change—but the paper stops short of specifying how such migrations would be engineered."],"forward_implications":["A developer can choose where to run a workload—on-device, on-premise, far edge, near edge, or cloud—by matching latency, privacy, cost, and energy requirements against Table 1's layer characteristics.","Platform choice narrows to a small set: AWS, Azure, Google Cloud, and Alibaba cover the continuum with distinct near-edge strategies, while OpenStack and OpenNebula provide private alternatives.","Serverless and containerized deployment, federated learning, and HTTP/3-style protocols converge as the default toolkit for building continuum applications.","The open challenges the survey identifies—interoperability, orchestration, security, energy, data management, standardization—define the field's research agenda.","Benchmarking and maintenance (simulators, emulators, CI/CD, monitoring) are treated as first-class concerns rather than afterthoughts."],"supporting_citations":[{"why":"Supplies the quantitative layer characteristics in Table 1: distance, latency, cost, and power consumption ranges for each continuum layer.","marker":"[48]"},{"why":"Establishes the terminological ambiguity and fragmented definitions of the cloud continuum that the survey's unified framework responds to.","marker":"[115]"},{"why":"Provides the layered architecture model and the open challenges (heterogeneity, resource management, security) that the survey organizes into its framework.","marker":"[58]"},{"why":"Contributes the orchestration taxonomy of the cloud-to-things continuum that the survey extends with deployment platforms and developer guidance.","marker":"[178]"},{"why":"Defines the edge-computing-driven IoT scope and terminology that the survey distinguishes its developer-centric perspective from.","marker":"[78]"},{"why":"Supports the resource management and orchestration open-challenge discussion in Section 9.","marker":"[167]"}],"fun_headline_variants":["Five-layer framework gives developers a practical edge-cloud map","A five-layer model maps the edge-cloud continuum for practitioners","Edge-cloud navigation: a five-layer developer's map to placement","Where to place computation: a five-layer edge-cloud guide"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The survey's practical guidance rests on the premise that the quantitative layer characteristics in Table 1 (latency, distance, cost, power consumption) are representative of real deployments, yet those numbers come from a single European Commission roadmap without supporting measurements or error ranges.","fun_headline_variants_meta":{"raw":{"variants":["Five-layer framework gives developers a practical edge-cloud map","A five-layer model maps the edge-cloud continuum for practitioners","Edge-cloud navigation: a five-layer developer's map to placement","Where to place computation: a five-layer edge-cloud guide"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000626,"raw_usage":{"total_tokens":2865,"prompt_tokens":879,"completion_tokens":1986,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":495,"completion_tokens_details":{"reasoning_tokens":1919}},"tokens_in":495,"tokens_out":1986,"duration_ms":13572,"temperature":1.0,"reasoning_tokens":1919,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T14:57:34.273925+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Measure end-to-end latency, bandwidth, and deployment cost for the same workload at on-device, far-edge (e.g., AWS Wavelength), near-edge (e.g., AWS Local Zones), and cloud (e.g., a major AWS region), and compare the results against Table 1's ranges; if the observed values systematically fall outside those ranges, the layer characterization that anchors the framework's practical guidance does not hold.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Contributes the orchestration taxonomy of the cloud-to-things continuum that the survey extends with deployment platforms and developer guidance."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supports the resource management and orchestration open-challenge discussion in Section 9."}],"review_version":1}