KG-Commit: A Dynamic Knowledge Graph for Online Just-in-Time Software Defect Prediction

1. Introduction

• Commit-level approaches can overlook project context, while reconstructing that context for every incoming commit may be costly.The open question is whether project-specific context can be maintained at a cost compatible with the pace of incoming commits.Source: §1 · p. 2

1.1. Motivating Example

• A file move can look harmless yet break an untouched file that still imports the old package, making the defect invisible from the commit alone.The example motivates using project context surrounding a change to label commits reliably.Source: §1.1 · pp. 2–3, Figure 1 · p. 3

1.2. Contributions

• KG-Commit incrementally represents repository entities, within-file AST structure, and commit-message and code-change semantics in a Neo4j graph.Its AST-delta mechanism records added, removed, updated, and moved AST nodes to maintain fine-grained structure as files evolve.Source: §1.2 · p. 3
• KG-Commit achieves the highest aggregate Macro-F1 (0.704), G-Mean (0.706), and AUC across 11 projects, outperforming each baseline on at least 9 projects in Macro-F1.Its aggregate differences are statistically significant against all baselines, and each commit takes approximately 1.33 s to process on CPU while cost remains stable as the graph grows.Source: §1.2 · p. 3

2.1. Just-in-Time Software Defect Prediction

• JIT-SDP developed from change-level metrics toward learned commit representations, online learning, and finer-grained prediction, while balancing prediction cost and performance.Prior work also studies online streams with delayed labels and drift, and represents developer-file relationships or code-change semantics.Source: §2.1 · pp. 3–4

2.2. Software Defect Prediction and Code Representation

• Code-representation work spans hand-crafted metrics, learned AST and token features, pretrained encoders, and graph-based models, but generally lacks project-wide context under JIT-SDP constraints.The paper positions its approach as shifting from developer-file relationships to changed code and broader project context represented in an evolving knowledge graph.Source: §2.2 · pp. 4–5, §2.1 · p. 4

2.3. Knowledge Graphs and Their Applications

• Knowledge graphs support relational representation and have broad applications, but software-engineering uses mainly organize artifacts, and prior work had not applied them to project-wide context in JIT-SDP.Dynamic knowledge graphs model evolving entities and relations; software examples cited include API and library organization.Source: §2.3 · p. 5

3.1. Motivation; 3.2. Problem Formulation

• Each commit represents a project-state transition and may add, remove, modify, or rename files; the target is to predict defect risk as each commit arrives.Existing commit metrics omit repository context, while KG-Commit maintains affected graph neighborhoods for prediction-time queries.Source: §3.1 · pp. 5–6, §3.2 · p. 6

3.2.2. Operational Constraints; 3.2.3. Online Predictive Objective; 3.2.1. Defect Modeling

• Online prediction starts after warm-up t, uses labels resolved only through commit j−g−1, and estimates whether target commit j is bug-inducing from the current project state.A commit is bug-inducing when it introduces a defect that requires a subsequent fix; the experiments use ApacheJIT labels identified with an SZZ-style algorithm.Source: §3.2.2 · p. 6, §3.2.3 · p. 6, §3.2.1 · p. 6

3.2.4. Knowledge Graph State Representation and Evolution

• The graph state K(j) is updated when a commit arrives, incorporates the newly available historical label after the gap window, and preserves project history for later queries.Cypher queries retrieve information from the accumulated graph state.Source: §3.2.4 · p. 6

3.3. KG-Commit

• KG-Commit uses a three-layer graph for repository context: Core entities and relations, AST structure with incremental deltas, and commit-message and code-change semantics in the CSTG.Commits are processed chronologically, and only information available at prediction time is queried; inference uses a compact projection of selected graph context.Source: §3.3 · pp. 6–7

3.3.1. Cypher Queries; 3.3.2. Layer 1: Core Components

• Cypher operations upsert graph entities and batch-create relationships; the Core layer links commits to authors, parents, issues, and changed files, and tracks cross-file imports.File-change edges distinguish added, modified, deleted, and renamed files; historical and current dependencies remain represented.Source: §3.3.2 · p. 7, §3.3.1 · p. 7, Figure 3 · p. 8

3.3.3. Layer 2: Within-File AST Subgraph

• The AST layer parses Java files into deterministic subgraphs, attaching each file to its AST and encoding parent–child relations and child positions.Node records include syntax type, category, and compact values; ordered children retain their order and unordered containers are canonically sorted.Source: §3.3.3 · p. 7
• AST matching builds a partial correspondence using subtree fingerprints, parent propagation, and unique type-and-location matches; unmatched or changed nodes define the delta.Equal fingerprints identify candidate identical subtrees, with larger candidates processed first and source position breaking ties.Source: §3.3.3 · pp. 7–8
• For each tracked file, KG-Commit updates live AST relations in place and records ADDS, REMOVES, UPDATES, and MOVES on the commit, keeping update and storage costs tied to syntactic change.Matched nodes retain identifiers, inserted nodes receive new ones, removed nodes remain queryable as inactive, and deleted files have live nodes marked inactive.Source: §3.3.3 · pp. 8–9, Figure 5 · p. 9

Alternative within-file representations.

• CFG, DFG, and PDG are evaluated alongside AST using the same delta vocabulary, with graph-specific ordinal matching for the alternatives.The alternatives are within-file representations mapped to ADDS, REMOVES, UPDATES, and MOVES.Source: Alternative within-file representations · p. 9

3.3.4. Layer 3: Commit Semantic-Text Graph (CSTG)

• CSTG builds commit term graphs from messages and changed-line tokens, linking terms to commits and associated terms across the history.Terms are assigned code, bug, action, error, or natural-language types; code terms can also link to matching live AST leaves, subject to a cap.Source: §3.3.4 · pp. 9–10
• CSTG weights terms using within-commit centrality and corpus rarity, then propagates smoothed defect risk over retained NPMI term associations.The resulting textual-risk prior combines term weights across the five term types.Source: §3.3.4 · p. 10, Figure 7 · p. 10

3.3.5. Inference over KG-Commit

• Inference uses five graph-based channels—RN, PPR, LP, DW, and KGE—plus a feature-based channel derived from CSTG statistics.The graph methods are Relational Neighbor, Personalized PageRank, clamped Label Propagation, DeepWalk matrix factorization, and DistMult knowledge-graph embedding.Source: §3.3.5 · p. 10

3.3.6. Projection for Lightweight Graph Inference

• Graph inference runs on a compact weighted bipartite projection, while cached TGC features retain selected full-graph context omitted from that projection.TGC summarizes changed files, their importers and importees, same-package files, and dependency-graph position.Source: §3.3.6 · p. 11
• Logistic-regression stacking combines selected graph-channel scores with CSTG and, optionally, TGC features.The paper distinguishes graph-only F, F+G, and F+G+T configurations.Source: §3.3.6 · p. 11

4.1. Research Questions •

• The four research questions assess prediction, online efficiency and scalability, representation choices, and inference-channel performance.The overall objective is to determine whether KG-Commit makes rich, project-wide context practically usable for online JIT-SDP.Source: §4 · p. 11, §4.1 · p. 11

4.2. Dataset

• The evaluation covers 11 ApacheJIT projects and 78,206 commits, including 22,740 bug-inducing commits and an overall bug-inducing rate of approximately 29.1%.Labels use SZZ with issue-report linking and trivial-edit filtering; commits are described by twelve change metrics and identifying fields.Source: §4.2 · p. 11, Table 4 · p. 12

4.3. Baselines

• Six baselines span change-metric classifiers, a single added-lines feature, and models using commit text or diff tokens.They are LR, HGB, RF, LApredict, DeepJIT, and JITLine; DeepJIT and JITLine are adapted to the online setting.Source: §4.3 · pp. 11–12

4.4. Experimental Protocol

• The online protocol predicts each commit using only information then available, with labels entering historical state after a 50-commit gap.A 5% warm-up initializes the graph; models refit every 200 commits when needed, and the operating threshold is periodically re-estimated from past predictions.Source: §4.4 · p. 12
• The primary configuration is Fov+G+T, with Fov alone used for the first 200 evaluated commits after warm-up before switching to Fov+G.The switch addresses CSTG's history-dependent cold start and is distinct from the periodic 200-commit refit interval.Source: §4.4 · p. 12

4.6. Evaluation Metrics

• Macro-F1, AUC, and G-Mean provide class-balanced evaluation, supplemented by normalized Popt and ACC@20%LOC for inspection effort.Runtime and lifecycle measurements include means, standard deviations, medians, and selected percentiles; DeepJIT uses separate GPU hardware, so its runtime is not hardware-matched.Source: §4.6 · p. 13, §4.5 · p. 13

5.1. RQ1: Predictive Performance against Baselines

• KG-Commit leads aggregate Macro-F1, G-Mean, and AUC; Macro-F1 is 0.704 versus 0.649 RF, 0.637 LApredict, 0.636 HGB, 0.618 DeepJIT, 0.579 LR, and 0.674 JITLine-online.Macro-F1 differences are statistically significant against all six baselines; project-level wins/ties/losses are 11/0/0 against RF, HGB, DeepJIT, and LR, 10/0/1 against LApredict, and 9/0/2 against JITLine-online.Source: §5.1 · pp. 13–14, Table 7 · p. 15
• KG-Commit records Macro-Avg Popt of 0.889 versus 0.878 and ACC@20%LOC of 0.653 versus 0.633 against JITLine-online.The paired differences are significant for Popt (p = .004) and ACC@20%LOC (p = .002).Source: §5.1 · p. 14, Table 8 · p. 16

5.2. RQ2: Efficiency and Scalability

• Routine processing takes a median of approximately 1.33 s per commit, dominated by graph ingestion, while Fov inference has a median latency of 0.325 ms.The final fifth of Camel's history has median ingest time of approximately 1.16 s, and per-commit work does not increase with graph growth.Source: §5.2 · p. 16

5.3. RQ3: Contribution of KG-Commit Layers to Predictive Performance

• With inference fixed at Fov, adding CSTG raises median Macro-F1 from 0.552 for Core to 0.644, while AST adds little benefit.Layer-2 alternatives perform similarly and change ordering across projects; AST is selected for its canonical-subtree-hashing delta.Source: §5.3 · pp. 16–17

5.4. RQ4: Inference Channels and Fusion

• PPR has the strongest single-channel Macro-F1 at .643, while the best fusion reaches 0.653; Fov scores 0.641 with 0.325 ms median inference cost.Fov+G reaches mean Macro-F1 0.676, S@200 reaches 0.681, and adding T raises it to 0.704.Source: §5.4 · p. 17

6.1. On the Necessity of Realistic Online Evaluation

• Online evaluation shows that block-based time-aware evaluation underestimates performance because fixed train/test blocks prevent continual refitting and adaptation.Block-based evaluation also does not reproduce per-commit maintenance or label-verification delays, leaving challenges such as concept drift and possible catastrophic forgetting unexamined.Source: §6.1 · p. 18, Table 13 · p. 18

6.2. Per-Commit Cost Relative to Commit Arrival Time

• 1.33 s per commit is compatible with observed arrival rates, including a shortest lower-tail interval of 8.0 s on Cassandra.For the other projects, the corresponding lower-tail intervals range from 25 s to more than 27 min; median spacing ranges from 1.20 h on Camel to 45.55 h on Zookeeper.Source: §6.2 · p. 20, Table 14 · p. 20

6.3. S@200 Switching and Cold-Start Improvement

• On Spark and Zookeeper, S@200 avoids weaker early performance of F+G and stays ahead through much of the later stream.The policy uses Fov for the first 200 commits after warm-up, then adds G; sparse early vocabulary can make G unstable, and noisy scores can carry into later updates.Source: §6.3 · p. 20, Figure 14 · p. 20

6.4. Sensitivity of the Online Protocol to Operational Constraints and Hyperparameters

• Macro-F1 is mostly stable across K, g, and M, while moving S from 0 to 200 raises it by 0.012 on Spark and 0.044 on Zookeeper.K=0.05 permits prediction after 5% of project history but trails the best tested K by 0.064 on Spark and 0.117 on Zookeeper. M=200 reduces refitting but lowers Macro-F1 relative to M=25 by 0.168 on Zeppelin, 0.089 on Zookeeper, and 0.057 on Spark.Source: §6.4 · pp. 20–21, Figure 15 · p. 21

6.5. Online Threshold Adaptation

• After 300 evaluated commits, KG-Commit retunes its threshold every 150; final thresholds range from 0.251 on Hive to 0.748 on Flink.Thresholds remain near 0.5 on Cassandra and HBase, move higher on Camel, Flink, and Groovy, and settle lower on Hive, Kafka, Spark, Zeppelin, and Zookeeper.Source: §6.5 · p. 21, Figure 16 · p. 21

6.6. Limitations and Future Work

• CPU-only generic inference leaves fine-grained AST and richer typed or higher-order patterns underused; the implementation is also limited to Java and single-repository histories.Future work includes richer inference and graph projections, GPU-based inference subject to online processing costs, and additional relations such as caller/callee links.Source: §6.6 · pp. 21–22

7.1. Internal Validity

• Temporal leakage is the main internal concern; the protocol restricts labels and learned components to information available at prediction time, though baseline adaptations may differ in implementation.The authors mitigate risks through a common stream, fixed settings, and sensitivity analyses.Source: §7.1 · p. 22

7.2. External Validity

• The Apache open-source evaluation may not transfer to projects with different development processes or defect distributions.The authors identify industrial and other open-source repositories as needed for broader generalizability.Source: §7.2 · p. 22

7.3. Construct Validity

• Construct validity is bounded by possible SZZ label errors, heuristic AST and CSTG choices, and environment-dependent execution timings.AST node alignment is heuristic, while CSTG uses rule-based extraction, intent assignment, and term grounding.Source: §7.3 · p. 22

• Across 11 Apache projects, Fov+G+T achieves the highest aggregate Macro-F1 (0.704), G-Mean (0.706), and AUC (0.809).Under the realistic online protocol, it exceeds LR, HGB, RF, and DeepJIT on all 11 projects in Macro-F1, LApredict on 10, and JITLine-online on 9, with significant aggregate paired differences against each.Source: §8 · p. 22
• 1.33 s per commit on CPU remains stable as project history and graph size grow, and is well below observed intervals between consecutive commits.Graph ingestion accounts for most of the per-commit cost.Source: §8 · p. 22
• The reported results use lightweight CPU-only inference and are a conservative estimate, not an upper bound, on what KG-Commit’s representation can support.The authors identify richer inference as a way to better exploit the maintained global structural and relational information.Source: §8 · p. 22

9.1. Funding

• The research received no external funding.Source: §9.1 · p. 23

9.2. Ethical approval

• Ethical approval was not applicable.Source: §9.2 · p. 23

9.3. Informed consent

• Informed consent was not applicable.Source: §9.3 · p. 23

9.4. Data Availability Statement

• The authors state that generated or analyzed datasets are available through Graph Dumps and the ApacheJIT Dataset, with a code repository also listed.Source: §9.4 · p. 23

9.5. Conflict of Interest

• The authors declare no conflict of interest.Source: §9.5 · p. 23

9.6. Clinical trial number

• The clinical trial number is not applicable.Source: §9.6 · p. 23

Appendix A. Alternative Within-File Representations

• The appendix compares CFG, DFG, and PDG representations, using a shared matcher and downstream delta interface despite their different encoded structures.Their builders produce execution order and branching, definition-use flow, and control/data dependencies, respectively; the matcher aligns same-type nodes and emits additions, removals, updates, or moves.Source: Appendix A · p. 27

Appendix B. Layer-Wise Results for Individual Inference Channels

• Representation gains can change in magnitude and sometimes ordering across inference channels and projects, so the main analysis holds inference fixed at Fov.Table B.16 reports layer-wise evaluation for the five individual graph-inference channels.Source: Appendix B · p. 27

Appendix C. Commit–Hub Projection and Graph-Based Inference

• A weighted bipartite projection links commits to shared file, developer, change-token, and CSTG-term hubs that connect commits with related context.A change token pairs an AST structural edit operation with the affected node type; its AST-delta representation is a multiset.Source: Appendix C · p. 27
• Figure A.17 contrasts source, CFG, DFG, and PDG representations; in the PDG, solid edges are control dependencies and dashed edges are data dependencies.Table A.15 covers construction and delta extraction for alternative within-file representations.Source: Figure A.17 · p. 28, Table A.15 · p. 28
• Table B.16 reports layer-wise online performance for five graph-inference channels across 11 projects, underlining each row’s best representation.The table caption does not provide the performance values.Source: Table B.16 · p. 29
• A commit-to-commit hop traverses two bipartite edges, while AST_CHILD, ancestry, COOCCURS, and file-to-file IMPORTS relations are outside the projection.Table C.17 summarizes the inference scope of the five graph-based channels.Source: Appendix C · p. 30, Table C.17 · p. 30
• Hub weights use occurrence counts in the current commit and logarithmic discounting based on their frequency among gap-resolved past commits.Only labels available under the gap constraint are used during inference.Source: Appendix C · p. 30
• RN, LP, and PPR propagate labels over shared-hub paths, while DW and KGE learn representations that capture patterns beyond a single shared hub.LP uses three commit–hub–commit rounds; PPR uses 40 bipartite edges, while DW applies truncated SVD and KGE learns DistMult embeddings from typed triples.Source: Appendix C · p. 30

Appendix D. CSTG Semantic Channel Features

• The CSTG semantic channel combines textual risk, term types, intent, structural consistency, and hashed text into a feature vector for a commit-level defect probability.A class-balanced logistic-regression model is fitted on currently available gap-resolved commits.Source: Appendix D · pp. 30–31
• Five semantic-mass features represent CSTG mass assigned to term types, while intent uses indicators for fix, feat, refactor, test, docs, perf, and revert.A commit assigned another intent receives an all-zero intent vector.Source: Appendix D · p. 30
• Intent-realization features compare the stated commit intent with the size and structure of its actual change.Table D.18 summarizes the seven features and identifies the structural-delta size and addition and removal counts used in them.Source: Appendix D · pp. 30–31, Table D.18 · p. 31
• Typed CSTG terms are feature-hashed into 218 positions, with CSTG term weights carried into the sparse text representation.Higher-weight terms contribute more strongly.Source: Appendix D · p. 31

Appendix E. Traversal and Global-Context Features

• TGC adds selected dependency and package context that the commit–hub projection omits, without applying graph inference directly to the full knowledge graph.Its information is cached, so online scoring reads feature values rather than running a Neo4j traversal.Source: Appendix E · pp. 31–32
• Starting from touched files, TGC keeps one-hop imported-file and importer neighborhoods separate, bringing untouched dependency neighbors into commit context.The import direction determines whether an untouched file is imported by a changed file or imports one.Source: Appendix E · p. 31
• Package context covers untouched files sharing a package with a changed file, while PageRank and k-core characterize files’ positions in the dependency graph.The package signal can apply even without a direct IMPORTS relation between files.Source: Appendix E · pp. 31–32
• TGC features are supplied in raw and project-standardized forms, then augment graph and semantic scores in the F + G + T configuration.The TGC-augmented stacking head uses gap-resolved commits and standardized, class-balanced logistic regression with an L1 penalty; Table E.19 summarizes the feature groups.Source: Appendix E · p. 32, Table E.19 · p. 32