{"id":"da47687c-0c7b-4a49-b9f1-1f0c95b7ef3c","arxiv_id":"2502.05273","paper_version":2,"verdict":"REJECT","confidence":"HIGH","novelty_score":2.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A survey of federated learning concepts and architectures that introduces no new results and is undermined by missing algorithms and an undisclosed survey method.","lead":"This paper reviews federated learning, a technique that trains models across many devices without pooling raw data. It organizes the field into five areas and lists common architectures, but contributes no new experiments or formal results.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The abstract's central promise—a set of architectural patterns derived from a systematic survey—is never delivered: no patterns are defined and no survey methodology is described.","rationale":"The reader's verdict REJECT is appropriate, but the most load-bearing flaw is not the missing Algorithm 4 per se, although that is real and locatable. The paper's abstract makes two substantive promises: an 'elaborate explanation' across five domains, and 'a set of architectural patterns derived from the systematic survey of the literature.' The latter is the paper's own contribution; the former is largely a summary of existing surveys. On inspection, no patterns appear anywhere. Section 5 is a narrative description of known FL architecture types, with figures reproduced from [39], and Table 1 summarizes types, not patterns. A pattern in the software architecture sense (the paper cites [13], which is itself an FL pattern paper) would require a name, a context, a problem, and a solution structure. None is present. The Conclusion's phrase 'architectural principles' is similarly unsupported. The 'systematic survey' is also never operationalized; no PRISMA-style or alternative methodology is given. Because the claimed original contribution is absent, the paper fails its central claim regardless of the quality of the survey prose. The missing Algorithm 4 is a parallel verification failure in Section 4: the algorithm comparison cannot be checked. Together these are mechanical, locatable defects that justify REJECT. The reviewer's weakest_assumption identified Algorithm 4; my concern is the broader and more central absence of the patterns and methodology, so agreement is partial.","tokens_in":12665,"tokens_out":3696,"duration_ms":33852,"concrete_test":"Inspect the full manuscript for (i) any occurrence of 'pattern' that names a concrete architectural pattern with a structured definition (e.g., context, problem, solution), and (ii) any description of the systematic survey method (databases searched, inclusion/exclusion criteria, number of papers screened). If neither exists, the abstract's claims of a derived pattern set and a systematic survey are unsupported. A secondary check: confirm whether Algorithm 4 appears anywhere in the manuscript; if it does not, the Section 4 comparison is also unverifiable.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The Abstract's central promise is a 'set of architectural patterns for federated learning systems, which are derived from the systematic survey of the literature.' The manuscript never delivers these patterns. Section 5 presents Table 1, which lists architecture types (HFL, VFL, FTL, etc.) with short descriptions, but no pattern is ever defined in the sense of a named recurring problem, context, and reusable solution, and no pattern catalogue appears. The Conclusion says 'We also present architectural principles,' but no principles are enumerated. Furthermore, no methodology section describes the 'systematic survey'—there is no search strategy, inclusion/exclusion criteria, or synthesis procedure. The derivation claim is therefore unverifiable and, as written, unsupported. This is more load-bearing than the missing Algorithm 4 in Section 4: Algorithm 4 only supports the algorithm evaluation, while the missing patterns and missing survey method undermine the paper's primary stated contribution. The repeated references to Algorithm 4 ('as stated in Algorithm 4 on line 7', 'Algorithm 4 thoroughly explains FSVRG', 'We see the CO-OP pseudocode in Algorithm 4') are a concrete symptom of the same unverifiable exposition.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper is a survey-style manuscript on federated learning (FL) architectures. It introduces basic FL concepts and claims to address five key domains (system heterogeneity, data partitioning, ML models, communication protocols, privacy techniques), summarizes three FL algorithms (FedAvg, FSVRG, CO-OP), lists several FL architecture categories in a table, and states in the abstract that it provides a set of architectural patterns derived from a systematic literature survey. The conclusion additionally claims that the paper presents architectural principles.","tokens_in":12896,"tokens_out":3778,"duration_ms":38401,"significance":"If the claimed architectural patterns and the systematic survey were actually present, the paper could serve as a useful organizing resource for practitioners seeking an overview of FL architecture. The bibliography draws on relevant and sometimes authoritative prior work. However, the manuscript currently provides none of the promised artifacts: no pattern catalogue, no enumerated architectural principles, no survey methodology, and no inspectable algorithm pseudocode. Because these gaps affect the paper's primary stated contributions, the paper as submitted is not a reliable reference and its findings cannot be verified or reproduced.","major_comments":[{"comment":"Section 4 repeatedly invokes 'Algorithm 4' as the authoritative pseudocode for FedAvg, FSVRG, and CO-OP, including the statements 'as stated in Algorithm 4 on line 7', 'Algorithm 4 thoroughly explains FSVRG', and 'We see the CO-OP pseudocode in Algorithm 4'; however, no Algorithm 4, code listing, or pseudocode block appears anywhere in the manuscript, so the algorithmic details that this section depends on cannot be checked.","section":"Section 4"},{"comment":"The abstract promises 'a set of architectural patterns for federated learning systems, which are derived from the systematic survey of the literature,' but the manuscript never defines a single architectural pattern in the sense of a recurring problem, context, and reusable solution; Table 1 merely lists architecture categories with short synopses, and Section 8's assertion that 'We also present architectural principles' is not supported by any enumerated principles in the body of the paper.","section":"Abstract and Section 5"},{"comment":"No methodology for the claimed systematic survey is described anywhere in the paper: there is no search strategy, list of databases, inclusion or exclusion criteria, or synthesis procedure, so the derivation claim in the abstract is unverifiable and should either be substantiated with a methodology section or removed.","section":"Methodology (absent)"},{"comment":"Despite its heading, 'Evaluation Of The Performance Of Federated Learning Algorithms,' Section 4 only paraphrases the experimental study of reference [34]; it presents no evaluation results, metrics, or analysis of its own beyond mentioning the MNIST dataset, and the claim that FedAvg 'proves to be the most successful' is therefore not supported by evidence provided in this manuscript.","section":"Section 4"}],"minor_comments":[{"comment":"The text contains several typographical errors, including 'F ederated' in the Section 2.2.1 heading, 'T able' before Table 1, and inconsistent capitalization of 'PERFIT' versus 'PerFit'; these should be corrected.","section":"Throughout"},{"comment":"The figure references are out of order: the text refers to 'Fig. 9' before introducing 'Figure 8', and the ordering of the discussion does not match the figure numbering; the figures and cross-references should be renumbered and fixed.","section":"Section 5"},{"comment":"Reference [35] is incomplete because it lacks venue or identifier information (it appears to be an unpublished manuscript), and references [4], [5], and [44] contain literal '???' placeholders for publisher locations; these bibliographic entries need to be completed.","section":"References"}],"recommendation":"reject","confidential_remarks":"The two central defects—the missing Algorithm 4 and the absence of both the promised architectural patterns and the survey methodology—are load-bearing and cannot be fixed by minor revision. The manuscript is a compilation of summaries of prior surveys and evaluations rather than an original contribution in its current form. A substantially rewritten version that includes the missing pseudocode, a genuine pattern catalogue, and a transparent methodology section could be reconsidered."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this paper is a passable primer on FL basics, but it fails on its own central promise. It claims to offer a set of architectural patterns derived from a systematic survey, but no patterns are ever defined and no survey method is described. On top of that, Section 4 repeatedly cites 'Algorithm 4' as the source of the pseudocode for FedAvg, FSVRG, and CO-OP, and no such algorithm appears anywhere in the manuscript. That is not a cosmetic issue; it makes the algorithm comparison unverifiable.\n\nWhat it does well: the early sections give a reasonable, if basic, overview of FL concepts — data localization, aggregation, privacy techniques, communication efficiency, heterogeneity, security. Table 1 sensibly lists common FL architectures (HFL, VFL, FTL, centralized/decentralized/hierarchical, etc.) with short descriptions and example focus areas. For a reader with zero prior exposure, this summary is mostly accurate, though it relies heavily on a handful of existing surveys ([13], [39], [44], [49]) and adds little synthesis beyond a table.\n\nThe soft spots are substantial. The abstract's main contribution is the pattern language, and that is simply missing. Table 1 is a taxonomy of architecture types, not a set of reusable problem-context-solution patterns. The conclusion says 'we also present architectural principles,' but none are enumerated anywhere. The 'systematic survey' is asserted without a search strategy, inclusion criteria, or synthesis procedure, so the derivation claim is unverifiable. The missing Algorithm 4 is a concrete symptom of the same problem: the text asks the reader to trust an artifact that cannot be inspected. There are also scattered garbled passages (e.g., 'FL (also known as sample-based FL)') and figure references that don't align with the surrounding text.\n\nI agree with the stress-test note that the missing patterns and methodology are more load-bearing than the missing Algorithm 4, since they undercut the paper's stated contribution rather than just one section.\n\nBottom line: this might serve as a rough orientation for a total newcomer, but even that use is undercut by the unverifiable algorithmic claims. It is not ready for peer review as a survey; it needs a major rewrite to define the patterns, describe the survey method, and fix the mechanical errors. For now, my recommendation is desk reject. If the authors resubmit after substantive revision, it could become a useful tutorial, but not as it stands.","headline":"A thin overview of FL that claims a pattern language and a systematic survey but delivers neither, and cites a nonexistent Algorithm 4 as its algorithmic authority.","tokens_in":13419,"tokens_out":4263,"would_cite":false,"duration_ms":36363,"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":"The paper organizes federated learning architecture into five design domains and derives reusable architectural patterns from a systematic survey of the literature.","keywords":["Federated Learning","Federated Learning Architectures","System Heterogeneity","Data Partitioning","Privacy Techniques","Communication Protocols","Architectural Patterns"],"falsifier":"Inspect the cited performance evaluation [34] and the CO-OP source [35] side by side with Section 4 of this paper. If the weighting rule attributed to FedAvg, the single-iteration description of FSVRG, or the age-gap merging rule for CO-OP does not match the sources, the survey's algorithmic account is unsupported. In addition, locating 'Algorithm 4' - which the text repeatedly cites but never displays - is a necessary check: absent that pseudocode, the central algorithmic claims cannot be verified.","tokens_in":12510,"feed_emoji":"🔐","tokens_out":6289,"duration_ms":57709,"temperature":0.7,"pith_summary":"This paper is a survey that tries to establish a workable organizing view of federated learning (FL) architecture, the setting in which multiple clients train a shared model without sharing raw data. Its central claim is that any FL system can be understood through five design domains - system heterogeneity, data partitioning, machine learning models, communication protocols, and privacy techniques - and that the literature supports a catalogue of reusable architectural patterns. The authors intend this synthesis to help researchers and practitioners choose structures for FL deployments, particularly in privacy-sensitive fields like healthcare and finance. A sympathetic reader would take the paper as claiming that its taxonomy and pattern list are an accurate, systematic distillation of the surveyed work.","feed_headline":"Five design domains organize every federated learning system","feed_subtitle":"A systematic survey maps data partitioning, privacy, communication, model choice, and heterogeneity into one architecture view.","key_machinery":"The organizing mechanism is a two-part taxonomy. The first part decomposes every FL system into five domains: system heterogeneity, data partitioning, machine learning models, communication protocols, and privacy techniques. The second part is a catalogue of architectural patterns - reusable configuration choices such as centralized aggregation, peer-to-peer exchange, hierarchical aggregation, asynchronous updates, and the horizontal, vertical, and transfer split of data. Named frameworks like PERFIT, MMVLF, FADL, Blockchain-FL, and FEDF serve as concrete instances of these patterns. The taxonomy does the work of the argument: by placing each surveyed architecture into the five domains, the paper makes the case that FL's design space is finite and navigable.","core_discovery":"The article's central claim is that federated learning architecture is not a single design but a space of choices, and that the existing literature can be organized into a coherent map. It distinguishes horizontal federated learning (same features, different samples), vertical federated learning (same samples, different features), and federated transfer learning (different samples and features), and it separates topologies into centralized, decentralized, hierarchical, and asynchronous forms. It also catalogs specialized frameworks such as PERFIT, MMVLF, FADL, Blockchain-FL, and FEDF. On algorithms, it follows a cited performance study in presenting Federated Averaging (FedAvg) as the strongest baseline, with FSVRG and CO-OP as variance-reduced and asynchronous alternatives. The paper's contribution is the synthesis itself: the five-domain decomposition plus the pattern catalogue, offered as a tool for understanding and building FL systems.","pith_inferences":["A direct test of the survey's accuracy would be to reconstruct the missing 'Algorithm 4' from the cited sources and check whether the prose descriptions of FedAvg, FSVRG, and CO-OP match it; until then, the algorithm section should be read as an unverified summary.","The five-domain taxonomy could be converted into a decision procedure that maps deployment constraints to a recommended architecture, which would make the organizing claim practically falsifiable.","If the taxonomy is right, it likely extends to settings the paper does not develop, such as federated fine-tuning of large language models, where communication cost and privacy interact more sharply than in the surveyed use cases.","The zero-trust discussion suggests a testable convergence: if federated training can learn trust scores from behavior, those scores could be used to filter poisoned updates, connecting the privacy and security domains of the taxonomy."],"forward_implications":["System builders can use the five domains as a design checklist, since the survey presents each domain as a set of options that must be chosen before training begins.","The pattern catalogue gives practitioners a starting topology - centralized, decentralized, hierarchical, or asynchronous - based on whether the main constraint is a central bottleneck, latency, or stragglers.","In regulated sectors, the surveyed privacy techniques (differential privacy, homomorphic encryption, secure multi-party computation) are presented as ways to comply with data-protection law without moving raw data.","The algorithmic summary supports treating Federated Averaging as a default baseline in i.i.d. settings, with variance-reduced and asynchronous methods as alternatives when those assumptions fail."],"supporting_citations":[{"why":"Supplies the architectural-pattern concept and the stakeholder model for FL systems.","marker":"[13]"},{"why":"Source for the performance comparison of FedAvg, FSVRG, and CO-OP that Section 4 summarizes.","marker":"[34]"},{"why":"Source for the asynchronous CO-OP algorithm and its age-based model merging rule.","marker":"[35]"},{"why":"Source for many of the architecture descriptions and figures, including HFL, VFL, FTL, PerFit, and FEDF.","marker":"[39]"},{"why":"Basis for the FL topology options: centralized, distributed, hierarchical, and peer-to-peer aggregation.","marker":"[22]"},{"why":"Basis for the wireless and 5G use case and the communication-efficiency framing.","marker":"[23]"},{"why":"Source for the major types of federated learning architectures and their challenges.","marker":"[44]"},{"why":"Foundational definitions of horizontal and vertical federated learning and their privacy properties.","marker":"[47]"}],"fun_headline_variants":["Five domains define every federated learning architecture","Federated learning design: a map of five key domains","How five domains shape all federated learning systems","A survey's map of federated learning's five core domains","Federated learning architectures decoded: five domains"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The survey's usefulness depends on its claim that the five-domain decomposition and the pattern catalogue faithfully represent the cited literature, and in the algorithm section that fidelity cannot be checked because the pseudocode labeled 'Algorithm 4' is referenced but never appears in the paper.","fun_headline_variants_meta":{"raw":{"variants":["Five domains define every federated learning architecture","Federated learning design: a map of five key domains","How five domains shape all federated learning systems","A survey's map of federated learning's five core domains","Federated learning architectures decoded: five domains"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000571,"raw_usage":{"total_tokens":2673,"prompt_tokens":891,"completion_tokens":1782,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":507,"completion_tokens_details":{"reasoning_tokens":1706}},"tokens_in":507,"tokens_out":1782,"duration_ms":13120,"temperature":1.0,"reasoning_tokens":1706,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-08T19:54:50.705211+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Inspect the cited performance evaluation [34] and the CO-OP source [35] side by side with Section 4 of this paper. If the weighting rule attributed to FedAvg, the single-iteration description of FSVRG, or the age-gap merging rule for CO-OP does not match the sources, the survey's algorithmic account is unsupported. In addition, locating 'Algorithm 4' - which the text repeatedly cites but never displays - is a necessary check: absent that pseudocode, the central algorithmic claims cannot be verified.","supporting_citations":[{"cited_title":"Journal of Systems and Software 191, 111357 (2022)","cited_arxiv_id":null,"evidence_quote":"Supplies the architectural-pattern concept and the stakeholder model for FL systems."},{"cited_title":"In: Proceedings of the Second Workshop on Distributed Infrastructures for Deep Learning, pp","cited_arxiv_id":null,"evidence_quote":"Source for the performance comparison of FedAvg, FSVRG, and CO-OP that Section 4 summarizes."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Source for the asynchronous CO-OP algorithm and its age-based model merging rule."},{"cited_title":"IEEE Access8, 140699–140725 (2020)","cited_arxiv_id":null,"evidence_quote":"Source for many of the architecture descriptions and figures, including HFL, VFL, FTL, PerFit, and FEDF."},{"cited_title":"NPJ digital medicine 3(1), 1–7 (2020)","cited_arxiv_id":null,"evidence_quote":"Basis for the FL topology options: centralized, distributed, hierarchical, and peer-to-peer aggregation."},{"cited_title":"IEEE Communications Magazine 58(6), 46–51 (2020)","cited_arxiv_id":null,"evidence_quote":"Basis for the wireless and 5G use case and the communication-efficiency framing."},{"cited_title":"In: Federated Learning for IoT Applications, pp","cited_arxiv_id":null,"evidence_quote":"Source for the major types of federated learning architectures and their challenges."}],"review_version":1}