{"id":"25a99978-66ef-4b8c-abea-ac3fbfc1918b","arxiv_id":"2411.09486","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":4.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":6,"one_line_summary":"A framework that converts construction-site mobile app logs into a directed collaborative network and mines hubs, brokers, frequent collaborator pairs, and task-level information flow rules.","lead":"This paper builds a collaborative network of a construction project automatically from mobile-app logs, then uses social network analysis and association rule mining to find key players, frequently collaborating users, and links between information flows and task severity. It is a useful but incremental application of standard methods, and the case study supports the descriptive findings while the efficiency claim goes beyond the data.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The central claim overreaches: the 226-node network is shown to be a graph of MobileCM issue forwards, but it is never validated as a complete representation of the project's collaboration, so the discovered hubs, brokers, and FCUs inherit an unmeasured sampling bias.","rationale":"The reader's weakest assumption is exactly the premise I find most load-bearing: the issue-forward records captured by MobileCM are treated as the collaboration network without evidence that they are a faithful and complete representation. The paper itself contains supporting in-scope evidence for this concern: Section 3.1 limits collection to issue-forward metadata, Section 5 states that only on-site inspection functions were updated, and Table 2 shows that 483 of 709 registered users are discarded during preprocessing without explanation or sensitivity analysis. The centrality and association-rule results are internally coherent, and the pipeline is clearly described, but the central claim—that the framework twins a construction project's collaborative network—requires construct validity that is not established. This is not an internal inconsistency or a disagreement with consensus; it is a missing validation step. The reader's CONDITIONAL verdict already reflects this concern, so my read does not change the verdict. I would keep the condition and require a representativeness check or a carefully reworded claim that limits the network to 'MobileCM-mediated issue-forward collaboration' before treating the findings as validated.","tokens_in":21391,"tokens_out":4406,"duration_ms":45314,"concrete_test":"Conduct a validation substudy on the same or a comparable project: compute the top-16 degree, closeness, and betweenness lists from the MobileCM logs. Independently collect a second source of collaboration events—targeted interviews with top-ranked users and a random sample of the 483 dropped users, plus, if permissible, WeChat/email/phone metadata over a 2–4 week window—and enumerate collaboration events not represented in MobileCM. Add those events as edges to the graph and recompute centralities and FCU groups. If the top-16 lists change by more than a few entries (e.g., more than 3 of 16) or any of the 483 dropped users enters a top-16 list, the claim that the mined network is the project's collaborative network is not supported. If the rankings are stable under this augmentation, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's core claim is that the framework 'twins' the collaborative network of a construction project and that the case study 'successfully discovered' key players, frequently collaborating users, and associations between information flows and task levels. This claim requires that the collected issue-forward records faithfully represent collaboration. Section 3.1 states that the system collects only the time, creator, sender, and receiver of each on-site inspection issue forward, and Section 5 concedes that only on-site inspection functions were instrumented. Yet the resulting 226-node, 17,068-edge graph is presented as 'the collaborative network,' and the paper does not provide any evidence about the volume or structure of collaboration occurring through face-to-face meetings, phone calls, email, paper documents, or other channels. The preprocessing also drops 483 of 709 registered users without analysis; if these users participate in collaboration outside MobileCM, the centrality rankings and FCU groups are systematically biased. The paper's internal validation is limited to consistency with workflow expectations and one leader's confirmation of user #62, which tests plausibility, not completeness. Without a representativeness check, the discovered key players are best interpreted as key players in the MobileCM forwarding network, not necessarily in the project's collaboration network.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes an integrated framework for automatically collecting, preprocessing, and analyzing collaboration data from a construction project, with the goal of 'twinning' a fine-grained collaborative network and mining it for key players, frequently collaborating users (FCUs), and association rules between information flows and task levels. The framework is implemented by instrumenting an existing mobile app (MobileCM) to log issue-forward records, cleaning and joining the records into a directed multigraph with 226 nodes and 17,068 edges, and then applying centrality measures, two newly defined frequency measures (ISF and LISF), and the Apriori algorithm. In a case study of one large project, the authors report top hubs and brokers (users #255, #62, #65), several frequently collaborating user pairs and groups, and association rules showing bidirectional issue transfers within small groups, some labeled by task severity. The paper concludes that the framework was successfully validated and that it provides decision-making insights for construction collaboration management.","tokens_in":21631,"tokens_out":4252,"duration_ms":44627,"significance":"If the central claims hold, the paper makes a practical contribution by showing how routine system logs can be turned into a fine-grained, directed, multi-edge person-to-person network without questionnaire-based data collection. The ISF and LISF measures are simple and easy to apply, and the use of Apriori on edge-level transactions is a reasonable way to discover recurring flow patterns. The data-cleaning and network-creation steps are described in enough detail to be reproduced in similar settings, which is a definite strength. However, the significance for the broader claim of 'twinning the collaborative network of a construction project' is conditional: the case study demonstrates mining of the MobileCM issue-forward network, but it does not establish that this network faithfully represents collaboration as a whole. The paper's own limitation statement in Section 5 concedes that only on-site inspection functions were instrumented.","major_comments":[{"comment":"The central claim that the framework twins the collaborative network of a construction project is not supported by the data collection design. Section 3.1 states that only the time, creator, sender, and receiver of each on-site inspection issue forward are collected, and Section 5 concedes that only on-site inspection functions were updated. Face-to-face meetings, phone calls, email, paper documents, and other communication channels are not captured. Table 2 also shows that 483 of 709 registered users are dropped after cleaning, with no analysis of whether these users participate in collaboration outside MobileCM. As a result, the centrality rankings, FCU groups, and association rules are systematically conditional on the app-usage channel. The paper should either reframe the contribution as mining the MobileCM forwarding network or provide evidence about the completeness and representativeness of the logged records relative to actual collaboration.","section":"Section 3.1 and Section 5"},{"comment":"The paper repeatedly states that the proposed framework was 'validated' in a large-scale project, but the validation is limited to consistency with workflow expectations and the anecdotal confirmation by project leaders that user #62 is a key safety engineer. No independent ground truth is provided for hubs, brokers, or FCUs, and no holdout or cross-check against another data source (e.g., interviews with a broader set of users, organizational charts, or alternative communication logs) is reported. This makes the case study a demonstration rather than a validation. The language in the abstract and conclusion should be softened to 'demonstrated' or the authors should add a formal validation step.","section":"Section 4, opening paragraph and Section 4.1"},{"comment":"There is an inconsistency between the reported average degree and the degree centrality calculations. Table 3 reports an average degree of 75.5 for a network with 226 nodes and 17,068 directed edges; if degree is counted as in-degree plus out-degree, the mean degree is 151.0. The value 75.5 appears to correspond to unique neighbors after merging parallel edges, whereas Table 4 reports degree centrality values such as 2371 for user #255, which count each directed edge separately. These are two different graph views (multigraph versus simple graph), and the paper should state which view is used for each reported statistic. Without this clarification, the network-level and node-level interpretations are ambiguous.","section":"Table 3 and Table 4"},{"comment":"The association-rule mining results depend on hand-chosen thresholds (Smin, Cmin, Lmin) and the paper provides no sensitivity analysis. For example, Table 5 sets support at 100/7250 and 60/7250, confidence at 0.75, and lift at 3, but it is not shown how the number or composition of discovered rules changes when these thresholds vary. Since the reported patterns are, by construction, those that exceed the selected thresholds, the claim that these are robust 'hidden patterns' requires either a threshold sensitivity analysis or a statistical significance assessment (e.g., permutation tests or bootstrap confidence intervals for lift).","section":"Section 3.3 and Table 5"}],"minor_comments":[{"comment":"The text states that approximately 3-3.7 issue-forward records were generated per issue, but the overall cleaned totals give 17,068 forwards / 7,250 issues ≈ 2.35, so the claimed range is not consistent with the aggregate data unless a subset of months is intended.","section":"Section 4, text near Figure 4"},{"comment":"The phrase 'the Apriori algorithm is proposed' is inaccurate; the Apriori algorithm is a well-known existing method. The contribution is in applying it to issue-forward itemsets, and the wording should be adjusted accordingly.","section":"Section 4.3 and Table 6/7"},{"comment":"The definitions of ISF and LISF in Equations (4) and (5) use a threshold inequality in the definition itself, which mixes the measure with its filtering step. It would be cleaner to define ISF and LISF as raw counts first and then introduce separate threshold parameters.","section":"Section 3.3"},{"comment":"The description of the LISF-based groups G1-G4 in Figure 9 is brief; for reproducibility, the authors should state the exact node pairs and level labels that define each group, since the figure alone is difficult to read in grayscale.","section":"Section 4.2"},{"comment":"The discussion section introduces interpretations about workload balance and network robustness that go beyond the reported data; these are reasonable conjectures but should be labeled as such rather than presented as direct findings.","section":"Section 5"}],"recommendation":"major_revision","confidential_remarks":"The paper is a reasonable applied-network-mining contribution, and the ISF/LISF idea is simple and potentially useful to practitioners. The main issue is that the authors overclaim the 'twinning' of the full collaborative network when the data are limited to one mobile app's issue-forward channel, and the validation is anecdotal. I believe this is fixable by reframing the scope and adding sensitivity/representativeness checks, so I recommend major revision rather than rejection. The average-degree inconsistency in Table 3 should also be corrected, as it may indicate confusion between the multigraph and simple-graph representations."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Dear colleague,\n\nYou should know this paper is a solid engineering demonstration, not a methodological breakthrough. The useful part is the end-to-end pipeline: updating a mobile inspection app to log issue forwards, cleaning with explicit SQL rules, building a directed multi-edge graph, then running centrality and Apriori association mining. That combination is new in construction SNA, where prior work mostly stops at simple undirected graphs built from surveys. The case study is concrete—7,250 issues, 17,068 forwards, 226 nodes—and detailed enough that the network construction could be reproduced. The labeled association rules linking task levels to back-and-forth exchanges are a genuine step beyond hub detection.\n\nThe main soft spot is load-bearing: the network is only the MobileCM issue-forward graph, not the project's collaboration network. Section 3.1 records only sender, receiver, and time for on-site inspection forwards, and Section 5 concedes no other functions were instrumented. Presenting hubs and frequent collaborator pairs as describing project collaboration therefore overreaches; they describe one communication channel. Preprocessing also drops 483 of 709 registered users without analysis, so all centrality rankings inherit an unmeasured channel and population bias. The validation is anecdotal—a leader confirming user #62 and consistency with the workflow. That tests plausibility, not completeness.\n\nTwo smaller overclaims: ISF in Eq. (4) is simply edge count (edge weight in a multi-edge graph); calling it new is generous, though LISF is a nice twist. And the \"small groups are more efficient\" conclusion has no outcome data—the paper shows recurring pairs, not better performance.\n\nThe stress-test note lands: the paper would be materially improved by a representativeness check, sensitivity analysis on the hand-chosen thresholds, and an explicit statement that this is the MobileCM collaboration network, not the whole project's.\n\nWho is this for? Construction management researchers and practitioners wanting a template for turning system logs into a fine-grained collaboration graph. The paper deserves a serious referee: it is coherent, honestly described, and potentially useful, but the central claim needs reining in. I would send it to peer review with major revisions focused on validation and scope.","headline":"A clear, reproducible pipeline for building a directed multi-edge collaboration graph from mobile inspection logs, but the 'twinning' claim runs ahead of the data because only one communication channel was logged and never validated as representative.","tokens_in":22153,"tokens_out":3839,"would_cite":true,"duration_ms":32895,"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":"An upgraded construction-management app's issue-forward logs can be turned into a directed collaboration network, and mining that network recovers hubs, brokers, frequent pairs, and task-level information-flow rules.","keywords":["social network analysis","digital twin","graph visualization","frequently collaborating users","association rules","information flow patterns","construction projects","centrality measures"],"falsifier":"Ask all 226 users in the case study to name their five most frequent project collaborators independently, and compare those names against the top pairs from ISF/LISF and the association rules; if most named collaborators are absent from the app-log network, or if the network's hub and broker rankings change when a channel-complete log (phone, face-to-face, email) is added for the same period, then the claim that the logged network is the collaboration network is falsified.","tokens_in":21169,"feed_emoji":"🏗️","tokens_out":9037,"duration_ms":79054,"temperature":0.7,"pith_summary":"This paper tries to establish that a construction project's collaboration network can be recreated and mined automatically from logs that an upgraded mobile management app already produces during normal on-site inspection work. It would matter because construction problems are often traced to missing or delayed information, and a continuously updated map of who sends issues to whom could tell managers whom to support, whom to watch, and which pairs already work well together. In a case study of roughly 7,800 issue records, the framework built a 226-user, 17,068-edge directed network and claims it successfully found key hubs and brokers, frequently collaborating user pairs, and association rules linking information flows to task severity levels. The paper also reports that collaboration concentrates in small two- or three-person groups specialized by task level, which it offers as practical guidance for organizing construction teams.","feed_headline":"One app's logs map who collaborates with whom on a project","feed_subtitle":"Issue-forward data becomes a 226-node network that ranks key players and ties working pairs to task levels.","key_machinery":"The central object is the directed multi-edge collaborative network, built by scanning each issue record, finding its forwards, creating nodes for users, and creating one directed edge per forward with the issue's timestamp, type, and severity attached. This network carries the entire argument: degree, closeness, and betweenness centralities identify hubs and brokers; information sharing frequency (ISF) and its labeled variant (LISF) count parallel edges to find frequently collaborating pairs; and Apriori, a frequent-itemset mining algorithm, treats each issue's set of directed edges as a transaction to find information-flow patterns and their link to task levels.","core_discovery":"The paper's central claim is that a fine-grained collaborative network of a construction project can be 'twinned'—reconstructed as a directed multi-edge graph—automatically by instrumenting an existing mobile management system so that every forwarded on-site issue is logged with its creator, sender, receiver, and time. In the reported case study, this produced a network with 226 user-nodes and 17,068 directed edges from 7,250 cleaned issue records, and the subsequent analysis identified hubs via degree and closeness centrality, brokers via betweenness centrality, frequently collaborating user pairs via ISF/LISF thresholds, and association rules showing that issue records are typically sent back and forth within small two- or three-person groups whose membership is tied to task severity levels.","pith_inferences":["The same pipeline should transfer to any organization whose work is tracked as issue records with sender and receiver logs, such as software bug trackers, facility help desks, or hospital task systems; its real test is whether logged-forward structure matches ground-truth collaboration in those settings.","The paper's small-group finding suggests a testable management intervention: deliberately organizing teams into stable dyads or triads for each task level should reduce information delay if the pattern is causal rather than merely descriptive.","A natural robustness check would be to compare the ISF-ranked pairs against a short interview or survey of the same 226 users; low agreement would indicate that the network captures app usage rather than collaboration as a whole.","The association-rule step could be extended to temporal process mining, predicting which user will receive an issue next based on the path so far, which the paper's confidence rules imply but do not implement."],"forward_implications":["Managers can obtain a continuously updated collaboration map without questionnaires, because the same app used for daily inspection also records the information flows.","Degree and closeness rankings point to the users who carry the most information and the coordinators who can spread it fastest, while betweenness rankings point to brokers whose absence would split communication between groups.","Setting an ISF or LISF threshold turns the dense multi-edge graph into a weighted simple graph whose heavy edges name the pairs that actually resolve issues together, by severity level.","The high-lift association rules give a predictive handle: when an issue arrives at one member of a frequent pair, it will almost certainly be sent back to the originator, and this back-and-forth is strongest within specific task levels."],"supporting_citations":[{"why":"Supplies the prior log-file-based project collaboration network and social-network-analysis detection of hubs and brokers that this work extends to directed, weighted, multiple edges.","marker":"[6]"},{"why":"Provides the closest earlier instance of a weighted directed communication network in construction change management, the level of detail this framework aims to produce automatically.","marker":"[21]"},{"why":"Exemplifies the survey/interview-based, simple-graph collaborative-network studies whose coarse data motivate the automatic data-collection strategy.","marker":"[15]"},{"why":"Describes the MobileCM app that was upgraded with the logging component, making the issue and forward records used in the case study available.","marker":"[34]"},{"why":"Supplies the graph-analysis tool used to calculate degree, closeness, and betweenness centrality and to visualize the detected communities.","marker":"[35]"},{"why":"Defines lift for association rules, which the paper uses with support and confidence thresholds to select the information-flow patterns it reports.","marker":"[37]"},{"why":"Provides the earlier Apriori-based association-mining approach that the paper adapts to information-flow edges.","marker":"[38]"}],"fun_headline_variants":["App logs auto-map 17k collaboration links in construction project","226-node network from app logs reveals construction teamwork patterns","Data-driven framework mines fine-grained collaboration from app data","Automated network twinning maps who really collaborates on projects","Small groups run construction collaboration, app-data network shows"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that every meaningful collaboration on the studied tasks flows through issue-forward records in the upgraded MobileCM app; the paper itself notes that only on-site inspection functions were instrumented, so off-app communication such as phone calls or face-to-face talks is invisible to the network.","fun_headline_variants_meta":{"raw":{"variants":["App logs auto-map 17k collaboration links in construction project","226-node network from app logs reveals construction teamwork patterns","Data-driven framework mines fine-grained collaboration from app data","Automated network twinning maps who really collaborates on projects","Small groups run construction collaboration, app-data network shows"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000746,"raw_usage":{"total_tokens":3329,"prompt_tokens":952,"completion_tokens":2377,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":568,"completion_tokens_details":{"reasoning_tokens":2311}},"tokens_in":568,"tokens_out":2377,"duration_ms":18305,"temperature":1.0,"reasoning_tokens":2311,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T20:35:14.369768+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Ask all 226 users in the case study to name their five most frequent project collaborators independently, and compare those names against the top pairs from ISF/LISF and the association rules; if most named collaborators are absent from the app-log network, or if the network's hub and broker rankings change when a channel-complete log (phone, face-to-face, email) is added for the same period, then the claim that the logged network is the collaboration network is falsified.","supporting_citations":[{"cited_title":"In this research, the meanings of TypeID, LevelID, RoleID, etc","cited_arxiv_id":null,"evidence_quote":"Supplies the prior log-file-based project collaboration network and social-network-analysis detection of hubs and brokers that this work extends to directed, weighted, multiple edges."},{"cited_title":"Golparvar-Fard, J","cited_arxiv_id":null,"evidence_quote":"Provides the closest earlier instance of a weighted directed communication network in construction change management, the level of detail this framework aims to produce automatically."},{"cited_title":"Garcia, D","cited_arxiv_id":null,"evidence_quote":"Exemplifies the survey/interview-based, simple-graph collaborative-network studies whose coarse data motivate the automatic data-collection strategy."},{"cited_title":"Borgatti, P.C","cited_arxiv_id":null,"evidence_quote":"Describes the MobileCM app that was upgraded with the logging component, making the issue and forward records used in the case study available."},{"cited_title":"De Laat, V","cited_arxiv_id":null,"evidence_quote":"Defines lift for association rules, which the paper uses with support and confidence thresholds to select the information-flow patterns it reports."},{"cited_title":"Del Monte, M.R","cited_arxiv_id":null,"evidence_quote":"Provides the earlier Apriori-based association-mining approach that the paper adapts to information-flow edges."}],"review_version":1}