{"id":"97fa316c-1083-4ed5-bf95-f7636447c4a7","arxiv_id":"2411.11267","paper_version":2,"verdict":"REJECT","confidence":"MODERATE","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Infomap detects three nested levels of delivery clusters in Shenzhen (5, 30, 56 communities) and Beijing (26, 92, 123), but no evidence shows these clusters improve logistics.","lead":"A logistics study applies the Infomap community detection algorithm to map on-demand food delivery flows in Shenzhen and Beijing, identifying three nested levels of delivery clusters. If these clusters reflect real delivery zones, they could guide hub placement and routing, but the paper does not test whether they actually improve delivery performance.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The abstract and conclusion claim that the framework optimizes delivery resource allocation, but no optimization metric, baseline, or evaluation is presented anywhere in Section IV; the paper demonstrates clusters, not optimization.","rationale":"The descriptive part of the paper, that Infomap recovers nested spatial clusters in the two delivery networks, is plausible and not the core issue: Infomap is an established algorithm, and the construction of a weighted directed graph from origin-destination flows is standard. The load-bearing problem is the gap between what is computed and what is concluded. The abstract and Section V assert that the findings demonstrate effectiveness in optimizing resource allocation and delivery strategies, but Section IV contains no optimization objective, no decision variable, no delivery performance metric, and no comparison condition. An outside reader cannot verify or falsify the optimization claim; it is simply unsupported. The missing baseline also means the reported Level 1/2/3 counts cannot be interpreted as useful rather than arbitrary. I agree with the reader that the paper should be rejected as a demonstration of optimization, while noting the depth_level stability issue as a secondary reproducibility problem. The reader's formal weakest_assumption singles out depth_level stability, whereas my main concern is the undemonstrated optimization claim; however, the no-baseline issue does appear in the reader's rationale, so the agreement is partial. My proposed check is the minimal experiment that would turn the optimization claim into a testable one: compare the detected hierarchy against simple planning baselines on quantitative logistics proxies. If the authors narrow the claim to descriptive spatial analysis, a conditional acceptance path would exist, but as written the verdict stays unchanged: REJECT.","tokens_in":7737,"tokens_out":5475,"duration_ms":65618,"concrete_test":"Use the same Shenzhen and Beijing networks and evaluate three operational proxies: (a) average order-weighted delivery distance within Level-3 communities; (b) fraction of orders crossing community boundaries; (c) Gini coefficient of community workload. Compare the Infomap three-level partition against three baselines: administrative districts, grid cells assigned randomly to equal-size groups, and flat Louvain partitions. If the Infomap hierarchy does not strictly improve at least one proxy while not degrading the others, the 'optimizing resource allocation and delivery strategies' claim should be removed or downgraded to 'may inform planning.'","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central stated contribution, in the Abstract, Section I-B, and Section V, is a framework that supports multi-level optimization of delivery management. The experiments in Section IV contain only descriptive outputs: number of communities per level, average grid units per community, and map/Sankey visualizations. There is no delivery performance metric (delivery time, distance, order-to-rider allocation), no comparison against administrative districts or flat partitions, and no optimization step. Therefore the phrase 'optimizing resource allocation and delivery strategies' is an unsupported inference, not an empirically demonstrated result. A secondary reproducibility issue: Section IV-B says depth_level reached stability at 3 without defining the stability criterion or reporting sensitivity, so the specific three-level structure is partly a modeling choice. Both issues are fixable, but the strongest claim currently overreaches the evidence.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper applies Infomap-based hierarchical community detection to on-demand delivery flow networks constructed from Ele.me datasets for Shenzhen and Beijing. It reports a three-level community hierarchy for each city, discusses the cluster sizes and nesting relationships, and claims that this framework supports multi-level optimization of resource allocation and delivery strategies. The experiments are descriptive: they report community counts, average grid units per community, and Sankey/visual maps, but no operational performance metric is evaluated.","tokens_in":7837,"tokens_out":3575,"duration_ms":33506,"significance":"If the descriptive analysis is sound, the paper offers a potentially useful exploratory tool for urban logistics planning by revealing spatial hierarchies of delivery demand. The use of two large real-world datasets is a strength, and the hierarchical visualization is a clear way to communicate urban structure. However, the central claimed contribution—optimization of delivery management—is not demonstrated by the experiments, and key methodological details (depth_level stability, correct map equation, robustness) are missing. The paper's value as a descriptive case study is real but modest; its value as an optimization framework is unsubstantiated.","major_comments":[{"comment":"The claim that 'the depth_level parameter reached stability at a value of 3' is not substantiated: no stability criterion is defined, and no sensitivity analysis is provided. Because depth_level is a user-selected parameter that controls the number of hierarchical levels, the reported three-level structure for both cities may be an artifact of this choice rather than an intrinsic property of the networks. Please define the stability measure, report its values across a range of depth_level, and show that the cluster counts and memberships are robust to reasonable variations.","section":"Section IV-B"},{"comment":"The abstract and Section V state that the framework 'optimizes resource allocation and delivery strategies,' but Section IV contains no optimization step and no delivery-performance metric (e.g., delivery time, distance, order-to-rider allocation). The experiments report only community counts and average sizes. To support the central claim, the authors should either (i) add an evaluation showing that community-based routing or dispatch improves a concrete operational objective over baselines (e.g., administrative districts or flat partitions), or (ii) reframe the contribution as a descriptive/exploratory analysis of hierarchical delivery structure. As written, the optimization claim is unsupported.","section":"Abstract and Section V"},{"comment":"The map equation in Eq. (2) is garbled: the formula as typeset is unreadable, and the symbols q, H, p, and ζ are not defined in the surrounding text. Since the entire method rests on minimizing this description length, please provide the correct equation (e.g., L(M) = q H(Q) + Σ_i p_i H(P_i)) and define every term. Without this, the method cannot be reproduced or checked.","section":"Section III-B, Eq. (2)"},{"comment":"The Shenzhen and Beijing networks are constructed with different spatial resolutions (approximately 1 km Voronoi polygons versus 500 m grid cells) and different edge definitions. The comparison of 'cohesive' (Shenzhen) versus 'fragmented' (Beijing) community structure may therefore reflect the underlying spatial resolution rather than true urban differences. Please either use a common spatial unit or include a resolution-sensitivity analysis, and temper the cross-city comparison accordingly.","section":"Section IV-A"},{"comment":"Infomap's search can depend on random seeds, but the paper does not report results from multiple runs. The community counts and memberships at each level may be a single draw from a stochastic algorithm. Please report results from repeated runs (e.g., mean and standard deviation of community counts, or a consensus partition) to establish that the reported structure is stable.","section":"Section IV"}],"minor_comments":[{"comment":"The section title 'Abbreviations and Acronyms' is misleading; the section actually describes the Infomap algorithm and its steps. Consider retitling it to 'Infomap Overview' or similar.","section":"Section III-B"},{"comment":"The row containing '√√ × × ×' is ambiguous because it is not clear which columns the symbols correspond to. Please replace the symbols with explicit 'yes/no' entries for each algorithm.","section":"Table I"},{"comment":"The sentence 'The experiment was conducted to large scale on-demand delivery datasets' is grammatically incorrect; it should be 'conducted on large-scale on-demand delivery datasets.'","section":"Abstract"},{"comment":"The discussion of future work would benefit from an explicit acknowledgment of the limitations of the current static analysis, such as the absence of temporal dynamics and the lack of validation against operational outcomes.","section":"Section V"},{"comment":"Reference [24] is missing volume, page, and year information; please complete the bibliographic details.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"The manuscript reads as an exploratory case study with a promising real-world dataset, but the stated contribution of 'optimization' is a significant overreach that is not supported by the experiments. The descriptive clustering results could be publishable after major revision if the authors either add a proper optimization evaluation or honestly reframe the paper as a descriptive analysis. The garbled Eq. (2) and undefined stability criterion are also load-bearing issues. The lack of any performance evaluation makes the current version unsuitable for acceptance, but the problems are fixable within the manuscript's scope."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a straightforward application of Infomap to food-delivery flow networks in Shenzhen and Beijing. The descriptive parts are probably fine — building weighted directed grids, running Infomap, and reporting the nested community counts. What is new here is empirical: the specific hierarchical partitions for these two cities on this type of data. I don't see a new method or a new management principle.\n\nThe paper does some things well. The network construction is reasonable for a large-scale descriptive study, the maps give a clear visual sense of the multi-level structure, and the comparison between Shenzhen's more cohesive clusters and Beijing's more fragmented ones is a legitimate observation. The choice of Infomap over other hierarchical methods is justified well enough in the related-work table.\n\nThe soft spots are in the gap between what is demonstrated and what is claimed. The abstract, introduction, and conclusion all say the framework 'optimizes resource allocation and delivery strategies.' Nothing in Section IV tests that. There is no delivery performance metric, no baseline against administrative districts or flat partitions, no sensitivity analysis, and no evaluation of whether the detected clusters actually improve dispatch or hub placement. The clusters are descriptive outputs; the optimization is an inference drawn by the authors. That's a load-bearing overreach.\n\nThere are also two smaller issues. The depth_level parameter is said to 'reach stability at 3' but the stability criterion is never defined, and no sensitivity analysis is shown. Since the number of hierarchical levels is the paper's central output, this matters. And the map equation in Eq. (2) is garbled in the text; the notation doesn't parse. That's easily fixed but makes the method section look sloppy.\n\nThe citation list is fine — the related work is relevant, and the self-citation to the first author's earlier paper is not a problem by itself.\n\nWho gets value from this? Someone wanting a worked example of Infomap on platform delivery data, or a descriptive baseline for urban hierarchy studies. It is not a contribution to optimization or management science as claimed.\n\nIf I were the editor, I'd send it to review only if the authors agree to either remove the optimization claims or add a real evaluation. The descriptive part is not wrong, just oversold. Given the data are new and the topic is timely, a serious referee could help bring the framing in line with the evidence. So I'd say it deserves referee time, but with a clear mandate: revise the claims or provide evidence.","headline":"Routine Infomap application to new delivery data with an unsupported optimization claim; the descriptive clusters are plausible, but the paper's central claim needs major revision or removal.","tokens_in":8349,"tokens_out":2996,"would_cite":false,"duration_ms":28142,"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 paper claims that applying Infomap's hierarchical community detection to on-demand delivery networks in Shenzhen and Beijing reveals a stable three-level nesting of delivery clusters, and that this hierarchy can guide hub placement…","keywords":["on-demand delivery","hierarchical community detection","Infomap","map equation","spatial network","urban logistics","Shenzhen","Beijing"],"falsifier":"Re-run Infomap on the same two datasets while sweeping depth_level from 1 to 5 and record the number of communities and the map-equation description length at each level. If the partition keeps changing beyond depth 3, or if a coarser or finer resolution of the spatial units changes the number of levels, the claim of a stable optimal three-level structure would be refuted.","tokens_in":7475,"feed_emoji":"🚚","tokens_out":5189,"duration_ms":48366,"temperature":0.7,"pith_summary":"The paper tries to show that hierarchical community detection, specifically Infomap's map-equation method, can uncover a nested three-level structure in the flow of on-demand delivery orders in two large Chinese cities. It builds weighted directed graphs from delivery data, with nodes as spatial grid units and edges as order counts, and runs Infomap to find communities at multiple scales. The reported result is that both Shenzhen and Beijing stabilize at three hierarchical levels, with Shenzhen showing five large regional clusters that subdivide into 30 and then 56 smaller zones, while Beijing shows 26, 92, and 123 clusters. The intended payoff is practical: if these clusters reflect real spatial dependencies, logistics planners could place hubs, assign routes, and allocate resources differently at each level. The paper argues the method is scalable and adaptable for data-driven urban logistics, though the optimization benefits are stated as implications rather than measured.","feed_headline":"Three nested delivery clusters organize Shenzhen and Beijing","feed_subtitle":"Infomap splits both cities' order flows into three scales of delivery zones, from regional hubs to neighborhood last-mile areas.","key_machinery":"The load-bearing object is Infomap's map equation $L(M)$, the expected description length of a random walk on the network when module boundaries are encoded with prefix and suffix codes. Infomap minimizes $L(M)$ to partition the network, then recurses inside each module to produce nested communities, with transition probabilities $P_{ij}=w_{ij}/\\sum_{k}w_{ik}$ so that edge weights (order counts) directly shape the detected hierarchy. The depth_level parameter controls how many hierarchical levels are extracted, and the paper sets it to 3 because it reached stability at that value. The recursive minimization continues until no further improvement in $L(M)$ is possible, which is what makes the hierarchy emerge naturally from the flow structure.","core_discovery":"On its own terms, the paper's central claim is that the map-equation hierarchy of a directed, weighted delivery network is not flat: when Infomap is allowed to recurse, both Shenzhen and Beijing settle at a depth of three, and the resulting nested communities differ between the cities in a way that mirrors their urban form. Shenzhen's Level 1 has 5 broad communities, Beijing's has 26; the finer levels also fragment differently, with Beijing producing more numerous, smaller communities. The paper interprets this as evidence that delivery flows are organized in a nested spatial hierarchy, and that this hierarchy can be used to coordinate macro-level regional hubs with micro-level last-mile delivery zones.","pith_inferences":["The paper's 'optimization' conclusion is not tested: no delivery-cost or travel-time metric is computed before and after using the hierarchy. A direct test would assign orders to clusters and compare intra-cluster versus cross-cluster route lengths or courier idle time against a random or administrative partition.","The two datasets use different spatial units (about 1 km Voronoi polygons in Shenzhen, 500 m grids in Beijing), so the cross-city difference in cluster counts could partly reflect resolution rather than urban structure. Controlling spatial resolution would test that.","The depth_level 'stability' criterion is never defined; one could scan depth levels 2 through 5 with a defined resolution measure and see whether the three-level structure persists.","The hierarchy could be connected to temporal demand rhythms: detecting communities separately for peak and off-peak hours might reveal whether the three-level structure is stable in time or shifts with delivery demand."],"forward_implications":["If the three-level structure is real, delivery management can be organized at three matching scales: broad regional flow regions, intermediate urban sub-regions, and fine neighborhood zones, with different route and resource strategies at each level.","The different cluster counts and sizes in Shenzhen versus Beijing imply that delivery-network planning should be city-specific rather than one-size-fits-all; Beijing's finer fragmentation suggests more localized last-mile management, while Shenzhen's broad clusters support hub-based regional coordination.","The method provides a data-driven way to define hierarchical service areas directly from order flows, which could complement traditional administrative boundaries or shipping-zone maps.","Since Infomap handles large directed and weighted networks efficiently, the same workflow can be rerun as orders accumulate, making the detected hierarchy a candidate basis for adaptive resource allocation over time."],"supporting_citations":[{"why":"Supplies the Infomap algorithm and the map-equation framework that the paper applies to delivery networks.","marker":"[16]"},{"why":"Provides prior evidence that urban freight flows have hierarchical community structure, which the paper extends to on-demand delivery.","marker":"[10]"},{"why":"Source of the Shenzhen RL-Dispatch dataset used for the first case study.","marker":"[23]"},{"why":"Demonstrates hierarchical community detection for urban functional areas, motivating the multi-level logistics framework.","marker":"[21]"},{"why":"Introduces a hierarchical mobility structure estimation that the paper contrasts with its own adaptive spatial clustering approach.","marker":"[22]"},{"why":"Connects community logistics to last-mile delivery and dynamic community partitioning, forming the application background for the proposed framework.","marker":"[7]"}],"fun_headline_variants":["Delivery networks split into 3 nested scales in two megacities","Infomap finds 3-level hierarchy in Shenzhen and Beijing deliveries","Shenzhen and Beijing show 3-tier delivery community structure","Nested delivery communities: 5 zones in Shenzhen, 26 in Beijing","Three-scale delivery hierarchy emerges from urban order flows"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole three-level result rests on the assumption that the parameter controlling how many levels to extract is best set to three because it 'reached stability' at that value, but the stability criterion is never defined and no sensitivity analysis is shown.","fun_headline_variants_meta":{"raw":{"variants":["Delivery networks split into 3 nested scales in two megacities","Infomap finds 3-level hierarchy in Shenzhen and Beijing deliveries","Shenzhen and Beijing show 3-tier delivery community structure","Nested delivery communities: 5 zones in Shenzhen, 26 in Beijing","Three-scale delivery hierarchy emerges from urban order flows"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001066,"raw_usage":{"total_tokens":4395,"prompt_tokens":801,"completion_tokens":3594,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":417,"completion_tokens_details":{"reasoning_tokens":3504}},"tokens_in":417,"tokens_out":3594,"duration_ms":24357,"temperature":1.0,"reasoning_tokens":3504,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T18:43:19.209377+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Re-run Infomap on the same two datasets while sweeping depth_level from 1 to 5 and record the number of communities and the map-equation description length at each level. If the partition keeps changing beyond depth 3, or if a coarser or finer resolution of the spatial units changes the number of levels, the claim of a stable optimal three-level structure would be refuted.","supporting_citations":[{"cited_title":"ACity-WideCrowdsourcingDeliverySystemwith ReinforcementLearning,","cited_arxiv_id":null,"evidence_quote":"Source of the Shenzhen RL-Dispatch dataset used for the first case study."},{"cited_title":"Communitylogistics anddynamiccommunitypartitioning:Anewapproachforsolvinge- commercelastmiledelivery,","cited_arxiv_id":null,"evidence_quote":"Connects community logistics to last-mile delivery and dynamic community partitioning, forming the application background for the proposed framework."}],"review_version":1}