{"id":"738b70e9-b0f4-4a5a-ad79-131ab318de6d","arxiv_id":"2506.07690","paper_version":2,"verdict":"REJECT","confidence":"HIGH","novelty_score":6.0,"correctness_risk":"high","formal_verification":"none","parameter_count":1,"one_line_summary":"Temporal centrality in a microservice network correlates with only 12 of 196 software metrics, and a new Centrality Change Proneness score does not affect software metrics, so it is proposed as an early degradation indicator.","lead":"This paper applies temporal network centrality metrics to seven releases of an open-source microservice benchmark and finds that centrality correlates with only a small subset of size and complexity metrics, while quality metrics show no correlation. The authors propose a new ordinal score, Centrality Change Proneness, derived from the First-Order Mover score, and claim it can serve as an early indicator of architectural degradation.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The early-indicator claim is unsupported: RQ2 uses an invalid Wilcoxon signed-rank test, and no predictive validation of CCP against actual architectural degradation is performed.","rationale":"I read the paper in good faith: the RQ1 correlation analysis is exploratory and clearly labeled, the replication package is provided, and the threats section is candid about the single benchmark and the sparse network. However, the central contribution is the claim that CCP rank is an early indicator of architectural degradation, and that claim rests on two unsupported steps. First, RQ2's Wilcoxon signed-rank test is misapplied: it treats the ordinal CCP rank and continuous software metrics as paired observations of the same variable, which cannot test whether one affects the other. Second, and more fundamentally, the paper never defines or measures architectural degradation independently of centrality; it never checks whether high CCP in early releases predicts degraded structure later. The Section 5 argument that 'centrality becomes increasingly decorrelated from software metrics' and that CCP can be computed early is not evidence of early-warning value. The conclusion in Section 7 that 'services that repetitively have high CCP rankings are most likely to undergo centrality changes' is a restatement of the definition of CCP, not a validated prediction. The reader's emphasis on FOM validity is plausible, but I see the missing predictive validation and the invalid RQ2 test as the load-bearing weaknesses; even a perfect FOM computation would not rescue the early-indicator claim. For these reasons I agree with the REJECT verdict and do not recommend changing it.","tokens_in":12220,"tokens_out":5762,"duration_ms":70124,"concrete_test":"Using the replication package, label each of the 42 services by whether it shows architectural degradation between v0.0.1 and v1.0.0 (e.g., service removed or rewritten, new dependency edges added, or known anti-patterns such as Nano/Hub-like/Mega introduced), then compute CCP ranks from the early releases (v0.0.1 through v0.2.0) and test whether high-CCP services are significantly more likely to be in the degraded set than low-CCP services (e.g., precision/recall or a Mann-Whitney U test on CCP rank by degradation label). If no such association appears, the early-indicator claim is unsupported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim (Section 5: 'the CCP rank can act as an early degradation indicator') requires showing that services with high CCP in early releases are later more architecturally degraded. The only quantitative support is RQ2 (Sections 3.3 and 4.2), which applies the Wilcoxon signed-rank test to paired values of the ordinal CCP rank and continuous software metrics. This is not a valid effect test: Wilcoxon requires paired observations of the same variable under two conditions, and 'affect' requires a regression-style or group-comparison design with CCP as the independent variable. Pairing a four-level ordinal rank with LOC or complexity has no meaningful signed difference, so the 71/1022 rejections (Table 3) cannot support the claim that CCP does not affect the metrics. Even if RQ2 were correctly analyzed, a null correlation between CCP and contemporaneous software metrics would not establish that CCP predicts future degradation; it could equally mean CCP is irrelevant. No ground-truth labels of architectural degradation (e.g., later dependency restructuring, architectural smells, fault-proneness) are used anywhere, and the paper notes in Section 3.3 that time-series methods 'failed to converge or converged to null values', so no temporal predictive analysis was actually run. The FOM-stability concern is real but secondary: even a perfectly stable FOM would not make the early-indicator conclusion valid without predictive validation against degradation outcomes.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The manuscript studies temporal centrality in seven releases of the train-ticket microservice benchmark. After reconstructing architectural networks with Code2DFD, the authors compute temporal centrality metrics (Taylor, Liu, Yin; Huang excluded) and software size/complexity/quality metrics, define a Centrality Change Proneness (CCP) rank by quartiling the First-Order Mover score, and test two research questions: RQ1 whether temporal centrality correlates with software metrics via Spearman's rho, and RQ2 whether CCP 'affects' software metrics via Wilcoxon signed-rank tests. The reported findings are that 7 size and 5 complexity metrics correlate consistently with centrality in all releases, quality metrics do not, and CCP does not affect software metrics, which the authors interpret as evidence that CCP is an early indicator of microservice architectural degradation.","tokens_in":12452,"tokens_out":4315,"duration_ms":53568,"significance":"The paper has clear strengths: it ships a replication package, applies temporal centrality measures to statically reconstructed microservice architectures, and is candid about threats such as the small sparse network, the single benchmark system, and self-implemented algorithms. If the early-indicator claim were supported, the CCP metric would be a useful addition to microservice degradation research. However, the central claim is not supported by the evidence as presented. The RQ2 analysis uses an invalid statistical test for the stated hypotheses, and no predictive validation connects CCP to any independent measure of architectural degradation. The contribution is therefore currently an exploratory metric proposal rather than an empirically established early-warning indicator.","major_comments":[{"comment":"The Wilcoxon signed-rank test is misapplied. The paper states that 'the paired data are the CCP rank and the SMs' and uses the test to assess hypotheses H14-H16 that 'CCP affects' size, complexity, and quality metrics. Wilcoxon's test requires paired observations of the same variable under two conditions (e.g., before/after), where each pair has a meaningful signed difference. Pairing a four-level ordinal CCP rank with a continuous software metric does not yield such signed differences. Consequently, the 71 rejections out of 1022 in Table 3 and the conclusion that 'CCP rank does not affect the variance of size, complexity, or quality metrics' are not established. Testing whether CCP is associated with software metrics requires a group comparison or regression-style analysis with CCP as the independent variable, not a paired signed-rank test.","section":"Section 3.3 / Section 4.2"},{"comment":"The headline claim that 'the CCP rank can act as an early degradation indicator' is not validated predictively. No ground-truth labels of architectural degradation are used anywhere in the study: there is no measure of later dependency restructuring, architectural smell occurrence, fault-proneness, or any other outcome that could confirm whether high early CCP precedes degradation. The manuscript itself notes in Section 3.3 that time-series methods 'failed to converge or converged to null values', so no temporal predictive analysis was actually run. Even if RQ2 were re-analyzed correctly, a null contemporaneous relationship between CCP and software metrics would not demonstrate predictive utility; it could equally mean that CCP is irrelevant to the metrics studied.","section":"Section 5"},{"comment":"There is a circularity concern in the interpretation of CCP. CCP is defined from the First-Order Mover (FOM) score, which by construction measures how much a node's centrality changes over time. The paper argues in Section 5 that services with high CCP 'are continuously changing their centrality along a U-shaped curve' and cites Figure 1 as corroboration, but Figure 1 plots the same temporal centrality data from which FOM/CCP is derived. Thus the observation that high-CCP services change centrality is a restatement of the metric's definition, not an independent empirical finding. What is missing is any evidence linking centrality-change proneness to architectural degradation, which is the substantive claim the paper wants to make.","section":"Sections 3.2 and 5"}],"minor_comments":[{"comment":"The metric inclusion criterion ('only those metrics that show a statistically significant correlation with at least one centrality metric across all releases') is a post-hoc filter. This is transparent, but it inflates the apparent consistency of the RQ1 results; the paper should report the full set of correlations or clearly frame the selected metrics as illustrative rather than as a systematic finding.","section":"Section 4.1"},{"comment":"The Conclusion Validity paragraph states that 'we correlated the JC and CC values computed for the temporal network at the latest release, while FOM values were computed incrementally by release.' This inconsistency should be resolved or explicitly justified, because RQ1 appears to mix latest-release centrality with incremental FOM values.","section":"Section 6"},{"comment":"Figure 5 shows CCP ranks for release v0.0.1 even though the text says FOM and CCP are undefined for the first release because the temporal network has only one snapshot. Either exclude v0.0.1 from the CCP analysis or explicitly state how the undefined values were handled.","section":"Section 4.2"},{"comment":"The sentence 'The variations in statistical significance across releases are certainly spurious' is too strong; the variation could reflect real changes in the underlying relationship, and a softer formulation would be more appropriate.","section":"Section 4.1"},{"comment":"Reference [10] is formatted inconsistently ('C., S.N., Menzies, T.'); the author name should be rendered in the same style as the other references.","section":"References"}],"recommendation":"reject","confidential_remarks":"The paper addresses a relevant topic and includes a useful replication package, but the central claim is not supported by the current analysis: the RQ2 test is statistically invalid, no predictive validation against architectural degradation is provided, and the interpretation of CCP is partly circular. These issues are load-bearing and would require either new data with external degradation labels or a substantial re-framing of the contribution as an exploratory metric rather than an early-warning indicator. Given the current scope (a single benchmark system with seven releases), I do not see how a revision within the manuscript's stated scope could establish the headline claim."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The genuinely new piece here is the first use of temporal centrality on a statically reconstructed microservice network, plus the CCP ordinal transformation of the FOM score. The RQ1 correlation analysis is run conventionally: Anderson-Darling, Spearman, multiple-testing caveats, and consistent-inclusion filtering are all stated. The authors are also refreshingly honest about limits — seven snapshots of one benchmark app, sparse networks, self-implemented algorithms, and a time-series analysis that failed to converge. That transparency plus a replication package earns real credit.\n\nThe soft spot is not subtle. RQ2 uses the Wilcoxon signed-rank test on paired CCP ranks and continuous metric values. That is not a valid effect test: paired observations of an ordinal rank and a LOC value have no meaningful signed difference, so the 71/1022 rejections do not establish that CCP does or does not affect the metrics. More importantly, even a clean null result here would not support the paper's load-bearing claim that CCP is an early degradation indicator. That claim requires showing that services with high CCP in early releases later show degradation — by dependency restructuring, smells, faults, or something independent. No such ground truth appears anywhere. CCP is built from FOM, which by definition measures centrality volatility, so a high CCP service changing centrality is true by construction. The leap from 'this service's centrality is volatile' to 'this architecture is degrading' is unsupported.\n\nThe post-hoc metric selection (only metrics significant in all releases) is a minor weakness, and the FOM numerical-stability issue is real but secondary. Even a perfectly stable FOM would not rescue the early-indicator conclusion without predictive validation.\n\nWho is this for? Researchers working on microservice network analysis and practitioners who want a lightweight health check. The exploratory RQ1 findings and the temporal-centrality pipeline are worth having in the literature; the early-indicator framing is not.\n\nRecommendation: send it to peer review with the expectation of heavy revision. The authors should reframe the contribution as exploratory, fix or remove the Wilcoxon analysis, and either drop the early-indicator claim or validate it against actual degradation outcomes. The replication package makes this work feasible to revise, not just desk-reject.","headline":"Solid exploratory correlation study whose central claim about an early degradation indicator is not supported by the evidence; the paper is worth a revision but not acceptance as-is.","tokens_in":13003,"tokens_out":981,"would_cite":false,"duration_ms":14363,"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 a microservice's centrality-change rank, computed from early releases, acts as an early indicator of architectural degradation.","keywords":["microservice architecture","architectural degradation","temporal networks","centrality metrics","Centrality Change Proneness","software metrics","architectural smells","train-ticket benchmark"],"falsifier":"Compute CCP ranks for the early releases of several microservice projects with known later architectural changes, such as services that were later refactored, split, or identified as exhibiting Hub-like or Mega smells. If low-CCP services turn out to undergo such degradation as often as high-CCP services, the claimed early-indicator property fails. A simpler check is to rerun the same analysis on a system with more releases: if FOM values flip drastically when one snapshot is added, the score is numerically unstable and the ranking carries no predictive information.","tokens_in":11994,"feed_emoji":"🚨","tokens_out":5021,"duration_ms":52195,"temperature":0.7,"pith_summary":"This paper argues that a microservice's tendency to change its network centrality across software releases—quantified by a new ordinal score called Centrality Change Proneness (CCP)—can serve as an early warning sign of architectural degradation. The authors reconstruct seven releases of the train-ticket microservice benchmark as a temporal network, compute temporal centrality metrics, and derive CCP from the First-Order Mover score. They find that temporal centrality correlates only weakly and inconsistently with code size, complexity, and quality, and that CCP does not drive those code metrics. Because CCP is computable from early releases and is independent of code metrics, the authors claim it offers a lightweight way to spot services whose dependency structure is volatile before code-level problems appear.","feed_headline":"Centrality shifts flag microservice decay before code metrics do","feed_subtitle":"A temporal-network score ranks services by volatility from the first releases, independent of code metrics.","key_machinery":"The load-bearing object is the Centrality Change Proneness (CCP) rank, derived from the First-Order Mover (FOM) score introduced in [29]. FOM measures how much a node's eigenvector centrality changes across snapshots of a temporal network; CCP maps FOM values into an ordinal quartile scale (LOW, MEDIUM-LOW, MEDIUM-HIGH, HIGH) so services can be ranked without a fixed threshold. The rank is computed incrementally by accumulating releases, making it available from the earliest versions. The paper uses it to test whether a service's tendency to change centrality affects code metrics, and finds it does not—which is exactly why it is argued to be an independent early indicator.","core_discovery":"The paper's central claim is that CCP rank can act as an early degradation indicator in microservice systems. A microservice whose centrality changes substantially across releases is likely undergoing shifts in its dependency structure, which may stem from flawed architectural decisions or improper division of responsibilities. The authors show empirically that temporal centrality becomes increasingly decoupled from software metrics as the architecture matures, which is why centrality-based signals are not redundant with code metrics. They conclude that services with persistently HIGH or MEDIUM-HIGH CCP ranks are the ones most likely to be involved in architectural decay, and that this signal is available earlier than code-metric deterioration.","pith_inferences":["A natural testable extension is to validate CCP against an external ground truth of degradation, such as developer-identified refactorings or architectural smells appearing in later releases; the paper itself does not provide such validation.","The rationale suggests a concrete prediction: services with high CCP in the first few releases should accumulate more architectural smells or dependency changes later than low-CCP services, which could be checked on a larger multi-project dataset.","The sparsity of the studied network (seven snapshots, mostly zero centralities) means the numerical behavior of FOM on small networks is a hidden variable; applying the same pipeline to a large industrial system with tens of releases would test whether the signal survives.","One implication the authors leave implicit is that CCP could be combined with change-proneness metrics at the code level, since CCP captures architectural volatility while classic change proneness captures code volatility; together they might give a two-dimensional early-warning screen."],"forward_implications":["Practitioners can monitor CCP ranks across releases to flag services that repeatedly sit in the top quartile of centrality change, before code smells or metric degradation appear.","The observed decoupling of centrality from size, complexity, and quality suggests that architecture quality and implementation quality must be assessed separately in microservice systems.","Researchers can use CCP trajectories to locate candidate services for architectural anti-patterns such as Nano, Hub-like, and Mega services.","Because FOM and CCP are computable from the first releases, the indicator fits the 'early bird' predictive heuristic already known to work for project quality.","The method transfers to any microservice system whose architecture can be reconstructed across releases, not just the studied benchmark."],"supporting_citations":[{"why":"Defines the First-Order Mover (FOM) score and the temporal eigenvector centrality measures that CCP is built on.","marker":"[29]"},{"why":"Establishes the network-centrality perspective on microservice architecture and supplies the dataset and reconstruction procedure being extended to the temporal dimension.","marker":"[5]"},{"why":"Provides the train-ticket benchmark microservice system whose seven releases are analyzed in this study.","marker":"[34]"},{"why":"Supplies the Code2DFD tool used to reconstruct the architecture of each release as a network.","marker":"[26]"},{"why":"Provides the experimentation guidelines that structure the empirical study design.","marker":"[31]"},{"why":"Supplies the interpretation thresholds for Spearman correlation strength used in answering RQ1.","marker":"[14]"},{"why":"Provides evidence that code smells make software components more change- and fault-prone, used to link centrality volatility to architectural degradation.","marker":"[22]"},{"why":"Supports the 'early bird' heuristic that early-development data can predict later project quality, motivating the use of early releases for the indicator.","marker":"[10]"}],"fun_headline_variants":["New metric catches microservice rot early via centrality volatility","Centrality change proneness predicts architectural decay in microservices","Volatile service centrality signals early architectural trouble","CCP: early warning for microservice degradation from network shifts","Temporal centrality metric exposes microservice decay risk early"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole argument rests on the assumption that the First-Order Mover score, computed from a sparse, self-implemented temporal centrality analysis of seven snapshots of a single benchmark app, is numerically stable and actually captures real architectural volatility—and the paper does not compare CCP against any external ground truth of degradation.","fun_headline_variants_meta":{"raw":{"variants":["New metric catches microservice rot early via centrality volatility","Centrality change proneness predicts architectural decay in microservices","Volatile service centrality signals early architectural trouble","CCP: early warning for microservice degradation from network shifts","Temporal centrality metric exposes microservice decay risk early"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000418,"raw_usage":{"total_tokens":2110,"prompt_tokens":855,"completion_tokens":1255,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":471,"completion_tokens_details":{"reasoning_tokens":1178}},"tokens_in":471,"tokens_out":1255,"duration_ms":11637,"temperature":1.0,"reasoning_tokens":1178,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T05:27:30.627096+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Compute CCP ranks for the early releases of several microservice projects with known later architectural changes, such as services that were later refactored, split, or identified as exhibiting Hub-like or Mega smells. If low-CCP services turn out to undergo such degradation as often as high-CCP services, the claimed early-indicator property fails. A simpler check is to rerun the same analysis on a system with more releases: if FOM values flip drastically when one snapshot is added, the score is numerically unstable and the ranking carries no predictive information.","supporting_citations":[{"cited_title":"Multiscale Modeling & Simu- lation15(1), 537–574 (2017)","cited_arxiv_id":null,"evidence_quote":"Defines the First-Order Mover (FOM) score and the temporal eigenvector centrality measures that CCP is built on."},{"cited_title":"In: 2025 IEEE 22nd International Con- ference on Software Architecture (ICSA)","cited_arxiv_id":null,"evidence_quote":"Establishes the network-centrality perspective on microservice architecture and supplies the dataset and reconstruction procedure being extended to the temporal dimension."},{"cited_title":"In: Proceedings of the 40th International Conference on Software Engineering: Companion Proceeedings","cited_arxiv_id":null,"evidence_quote":"Provides the train-ticket benchmark microservice system whose seven releases are analyzed in this study."},{"cited_title":"JSS (2023)","cited_arxiv_id":null,"evidence_quote":"Supplies the Code2DFD tool used to reconstruct the architecture of each release as a network."},{"cited_title":"Springer (2012)","cited_arxiv_id":null,"evidence_quote":"Provides the experimentation guidelines that structure the empirical study design."},{"cited_title":"Prentice Hall (2007)","cited_arxiv_id":null,"evidence_quote":"Supplies the interpretation thresholds for Spearman correlation strength used in answering RQ1."},{"cited_title":"Empirical Software Engineering23(3), 1188–1221 (Jun 2018)","cited_arxiv_id":null,"evidence_quote":"Provides evidence that code smells make software components more change- and fault-prone, used to link centrality volatility to architectural degradation."},{"cited_title":"ACM Trans","cited_arxiv_id":null,"evidence_quote":"Supports the 'early bird' heuristic that early-development data can predict later project quality, motivating the use of early releases for the indicator."}],"review_version":1}