arXiv CSopen access

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

· arxiv_cs

arXiv CS · Papers · License: Open Access

software-architecture software-engineering testing

software engineering, software architecture, testing

KG-Commit: A Dynamic Knowledge Graph for Online Just-in-Time Software Defect Prediction Mohsen Hesamolhokamaa , Mohammad Sina Beyrami Aghbasha , Behnam Rohanib , Mohammadamin Fazlia , Jafar Habibia a Department of Computer Engineering, Sharif University of Technology, Tehran, Iran

arXiv:2609.06272v1 [cs.SE] 5 Sep 2026

b Department of Mathematical Sciences, Sharif University of Technology, Tehran, Iran

Abstract Just-in-time software defect prediction (JIT-SDP) aims to identify risky commits as they arrive and provide developers with timely feedback. This need for low latency has led most approaches to rely on commit-level information and overlook the broader project context in which a change occurs. Incorporating this context is challenging because it requires both efficient retrieval for incoming commits and continual maintenance as the repository evolves. We introduce KG-Commit, a dynamic knowledge graph that incrementally maintains repository history, within-file code structure, and commit semantics as the project evolves. It also uses an AST-delta mechanism to track structural changes between file edits and relies on lightweight graph inference running entirely on CPU. Our evaluation on 11 Apache software projects against six baselines shows that KG-Commit achieves the highest aggregate Macro-F1 (0.704), G-Mean (0.706), and AUC (0.809) using our selected inference pipeline. Under a realistic online protocol, it outperforms LR, HGB, RF, and DeepJIT on all 11 projects, LApredict on 10, and JITLine on 9 projects in Macro-F1, with the aggregate paired difference significant in every case. KG-Commit processes each commit in approximately 1.33 s, with a cost that remains stable as the graph grows and is compatible with commit rates observed in real-world projects. These findings show that rich project context can be efficiently maintained and exploited for online JIT-SDP. Keywords: Online Defect Prediction, Knowledge Graph, Just-in-Time, Real-time Project Evolution

1. Introduction Software underpins nearly every product and service that people rely on, and even a single defect can disrupt a critical system. Ensuring software quality is therefore a persistent concern for development teams, yet the time and resources available for testing and code review are limited. Software defect prediction (SDP) helps teams direct that effort to the right place by estimating which parts of a system are most likely to be faulty (Menzies et al., 2007; Lessmann et al., 2008; Hall et al., 2012). Traditional SDP approaches operate at the level of files, modules, or releases (Wang et al., 2016; Li et al., 2017; Zhou et al., 2022). At this granularity, predictions often arrive only after many changes have accumulated,

Email addresses: [email protected] (Mohsen Hesamolhokama), [email protected] (Mohammad Sina Beyrami Aghbash), [email protected] (Behnam Rohani), [email protected] (Mohammadamin Fazli), [email protected] (Jafar Habibi) Preprint submitted to Elsevier

making it difficult to identify the particular change that introduced a defect and to recover the context in which it was made. Just-in-time defect prediction (JIT-SDP) was introduced to close this gap (Mockus and Weiss, 2000; Kamei et al., 2013). It evaluates each commit as soon as it is submitted, so a risky change can be reviewed while its author still remembers the context. Because of this immediate feedback, JIT-SDP has become a natural fit for continuous integration and an active research topic (Zhao et al., 2023). For more than a decade, JIT-SDP has relied primarily on a compact set of hand-crafted metrics that summarize each commit. These metrics capture properties such as change size, code churn (Nagappan and Ball, 2005), the extent to which a change spans files and subsystems, and the experience of its author (Kamei et al., 2013; McIntosh and Kamei, 2018). Standard classifiers then use these summaries to estimate defect risk. As deep learning became more prominent, research gradually shifted from hand-crafted commit features to deep representation learning. Yang et al. (2015b) used September 9, 2026

a deep belief network to transform conventional metrics into richer features, while DeepJIT and CC2Vec learned representations from commit messages and code diffs (Hoang et al., 2019, 2020). Later work extended this direction with line-level defect localization (Pornprasit and Tantithamthavorn, 2021, 2023), pre-trained code encoders such as CodeBERT (Ni et al., 2022; Jiang et al., 2025), and parameter-efficient adaptation of these models (Abu Talib et al., 2024). What these models largely overlook is the broader project context in which the change occurs (Bryan and Moriano, 2023; Zhao et al., 2023). Knowledge graphs are well suited to representing such structure because they organize information as entities connected by typed relations (Hogan et al., 2021; Ji et al., 2022) and support reasoning and learning over these relations (Nickel et al., 2016). They have been applied successfully in areas such as recommendation, life sciences, and cybersecurity (Wang et al., 2019; MacLean, 2021; Zhao et al., 2024). Their use in software engineering, however, remains relatively limited and has focused mainly on organizing software artifacts such as APIs and libraries (Liu et al., 2023b). Knowledge graphs remain even less explored in software defect prediction and, to the best of our knowledge, have not been applied to JITSDP. This gap is particularly notable because a commit is inherently relational. It modifies specific files and functions, interacts with other parts of the system, is associated with an author, and carries an intent expressed through its message. Dynamic knowledge graphs provide a natural way to capture these evolving relationships (Zhang et al., 2024; Cai et al., 2024). By incorporating new events as they occur, they maintain an up-todate representation of a changing domain (Trivedi et al., 2017; Goel et al., 2020). Since software evolves incrementally through a stream of commits, this representation is especially well aligned with the online nature of JIT-SDP. In just-in-time prediction, however, accuracy is of little value if it arrives too late (Kamei et al., 2013), so richer context must be incorporated at a computational cost that remains practical for an incoming stream of commits. This creates a tension between contextual richness and per-commit processing cost. Project-level context, such as how a changed function is called elsewhere or how a file depends on others, is known to improve defect prediction (Zimmermann et al., 2009; Nam et al., 2013), but reconstructing this information from scratch for every incoming commit can be expensive. To remain efficient, many approaches mainly rely on information contained within the commit itself, such as its message and code diff (Hoang et al., 2019, 2020;

Pornprasit and Tantithamthavorn, 2021). Others pursue efficiency more aggressively through a single inexpensive feature (Zeng et al., 2021) or lightweight retrieval over historical commits (Sahar et al., 2024). The open question is whether rich, project-specific context can be maintained at a cost compatible with the pace at which commits actually arrive. Dynamic or real-time knowledge graphs offer a natural way to address this problem. Rather than reconstructing the project state from scratch, the graph is updated incrementally as each commit arrives, with each update affecting only the relevant portion of the graph (Zhao and Chen, 2023). The accumulated project context can then be queried through a graph query language such as Cypher (Francis et al., 2018; Angles et al., 2017). This replaces repeated reconstruction of project history with incremental per-commit work. Its practical suitability therefore depends on whether this processing cost remains stable as the project grows and is sufficiently small relative to the rate at which commits arrive. Building on this idea, we introduce KG-Commit, a dynamic knowledge graph that evolves with the repository and provides project-specific context at inference time. KG-Commit is maintained incrementally in Neo4j and organizes information across three layers: (1) Core layer for repository entities and their relations, (2) AST layer for within-file program structure, and (3) Commit Semantic-Text Graph (CSTG) layer for the semantics of commit messages and code changes. We combine graph-based and feature-based inference over these representations to estimate defect risk and evaluate KGCommit in terms of predictive performance, query and update cost, and suitability for online JIT-SDP. 1.1. Motivating Example Consider a commit that only moves a file, for example relocating Config.java from the com.app.utils package to com.app.core (Figure 1). Judged on its own, the commit looks harmless. It moves a file without changing its contents, so its change metrics are small and nothing inside the change points to a defect. A developer reviewing only the change, or a model that relies only on commit-level information, would therefore be likely to classify it as clean (Hoang et al., 2019; Zeng et al., 2021). The commit is nonetheless bug-inducing, because another part of the project still refers to the file through its old package. The file ApiServer.java, which this commit does not touch, still contains import com.app.utils.Config;. After the move, this import refers to a class that no longer exists in that package, causing the build to fail. This defect cannot be de2

• Strong Predictive Performance with Efficient and Scalable Deployment. KG-Commit achieves the highest aggregate Macro-F1, G-Mean, and AUC against six baselines across 11 real-world projects under a fixed online protocol. It outperforms each baseline on at least 9 out of the 11 projects in Macro-F1, with statistically significant aggregate differences against all of them. KGCommit processes each incoming commit in approximately 1.33 s on CPU. Lifecycle analysis further shows that per-commit processing remains stable as the graph grows, supporting the practical use of KG-Commit throughout project evolution.

tected from the commit in isolation. It becomes visible only when the rest of the project is taken into account. Reliably labeling such a commit therefore requires information about the project context that surrounds the change.

Commit a1b2c3d

Move Config.java into core package utils/Config.java core/Config.java

RENAMED

12 class Config { 13

static int TIMEOUT = 30;

1.3. Paper Outline

15 } // renamed only

The remainder of this paper is organized as follows. Section 2 reviews related work on JIT-SDP, code representation, and knowledge graphs. Section 3 presents KG-Commit, its layered representation, incremental maintenance, and inference methods. Section 4 describes the experimental design and online evaluation protocol. Section 5 reports predictive performance, efficiency and scalability, layer contributions, and inference-channel analysis. Section 6 discusses the main findings, deployment considerations, sensitivity to operational constraints, limitations, and future work. Section 7 addresses threats to validity, and Section 8 concludes the paper.

looks clean

ApiServer.java (elsewhere

not touched)

1 import utils.Config; 2 3 class ApiServer { 4 void start() { Config c = 5 Config.load(); 7 } 8 }

utils.Config no longer exists compile error Figure 1: A commit moves Config.java from package com.app.utils to com.app.core. The change has no effect inside the file, so it looks clean, but ApiServer.java elsewhere in the project still imports com.app.utils.Config and fails to compile. The defect is not visible from the commit alone.

2. Related Work Our work brings together three research lines: JITSDP, the representation of source code for defect prediction, and knowledge graphs. We review each line in turn and close by positioning our proposal, which represents the sequence of code changes as a dynamic knowledge graph and queries that graph to predict defects.

1.2. Contributions The main contributions of this paper are as follows: • A Practical Solution to Rich Project Context in Online JIT-SDP. KG-Commit addresses the difficulty of incorporating rich project context without sacrificing the speed required for JIT-SDP. To the best of our knowledge, it is the first knowledge graph designed for JIT-SDP. It represents repository history, code structure, and commit semantics in a Neo4j graph database.

2.1. Just-in-Time Software Defect Prediction Traditional defect prediction works at coarse levels such as the file, module, or the release (Menzies et al., 2010). This approach delays feedback and forces developers to inspect large amounts of code. More recently, Hesamolhokama et al. (2025) showed that file overlap and label persistence bias can inflate withinproject SDP performance at file granularity. JIT-SDP instead targets the individual commits, so risky changes can be reviewed as soon as they are submitted. The idea goes back to the change-level risk models of Mockus and Weiss (2000), and its modern formulation was established by the large-scale empirical study of Kamei

• Incremental Maintenance of Within-File Structure through AST Deltas. We introduce an ASTdelta mechanism that tracks how a file’s structure changes between edits by recording added, removed, updated, and moved AST nodes. This lets KG-Commit maintain fine-grained within-file structure incrementally as the project evolves. 3

et al. (2013). That study introduced a set of changelevel metrics that is now standard, covering the size, diffusion, history, and developer experience of a change, together with effort-aware evaluation that ranks changes by defect likelihood per unit of inspection effort. Training labels are commonly derived using the SZZ algorithm, which traces bug-fixing commits back to the changes that likely introduced the defect (Śliwerski et al., 2005). Early work formulated the problem as a binary classification task, predicting whether each change is clean or buggy (Kim et al., 2008). Later studies examined how such models generalize across projects (Fukushima et al., 2014; Kamei et al., 2016) and how they degrade over time, with McIntosh and Kamei (2018) showing that fix-inducing changes are a moving target. A first wave of learning-based approaches moved beyond hand-crafted metrics by learning richer representations from traditional change features. Yang et al. (2015b), for example, used a deep belief network to transform conventional metrics into higherlevel features. Later work shifted toward end-toend representation learning. DeepJIT (Hoang et al., 2019) learns from commit messages and code changes, while CC2Vec (Hoang et al., 2020) learns representations of code changes using their associated log messages. Other studies have targeted finer-grained prediction, identifying defect-prone files or lines within a commit (Pascarella et al., 2019; Pornprasit and Tantithamthavorn, 2021), while complementary work has focused on explaining predictions to developers (Pornprasit et al., 2021). More recent approaches have incorporated pretrained code models. JIT-Fine combines semantic representations from CodeBERT with expert-designed features (Ni et al., 2022), bi-modal pre-training further improves the representation of code changes (Jiang et al., 2025), and parameter-efficient tuning reduces the cost of adapting such encoders (Abu Talib et al., 2024). At the same time, several studies have questioned whether increasingly complex models are always necessary. Zeng et al. (2021) show that a simple model based on a single churn feature can match complex approaches, while other work finds benefits in combining expert knowledge with learned semantic representations (Zhou et al., 2025; Chen et al., 2023). IRJIT similarly demonstrates that a lightweight information-retrieval approach can remain competitive while offering much lower prediction cost (Sahar et al., 2024). Two practical issues have become increasingly important in JIT-SDP. One is the online nature of the task. Commits arrive as a stream, labels become available

only after a verification latency, and the class distribution drifts. Cabral and Minku (2023) study reliable online JIT-SDP under these conditions, while Tabassum et al. (2023) extend the setting to cross-project online learning. The other issue is how a code change is represented. Flat metrics and token sequences largely ignore the relational structure surrounding a change. Bryan and Moriano (2023) address this limitation by constructing contribution graphs over developers and files. The survey by Zhao et al. (2023) likewise identifies richer structural and semantic modeling as an important direction for future work, while methodological studies emphasize the need for rigorous model validation (Tantithamthavorn et al., 2017). Our work builds on this perspective but shifts the focus from developer–file relationships to the changed code itself and its broader project context, represented as an evolving knowledge graph. 2.2. Software Defect Prediction and Code Representation Defect prediction has long been studied at the file and module level. Early approaches relied on static code properties, such as size and complexity metrics (Menzies et al., 2007), while a parallel line of work showed that change and process information, including code churn and properties of the change history, can be even more predictive (Nagappan and Ball, 2005; Moser et al., 2008; Hassan, 2009). Subsequent empirical studies and benchmarks compared classifiers and datasets under common evaluation settings (Lessmann et al., 2008; Hall et al., 2012; D’Ambros et al., 2012). Another substantial body of work examined cross-project defect prediction, where models are transferred across projects when project-specific training data are limited (Zimmermann et al., 2009; Nam et al., 2013). Together, these studies established many of the features, datasets, and evaluation practices that later defect-prediction research builds upon. A second line of work learns representations from code without relying on hand-crafted metrics. This direction is motivated by the observation that source code exhibits regular and predictable patterns similar to natural language (Hindle et al., 2012), making distributed representation learning a natural fit (Mikolov et al., 2013). Wang et al. (2016) learn semantic features from token sequences derived from abstract syntax trees (ASTs) using a deep belief network, while convolutional and tree-based models capture syntactic structure (Mou et al., 2016; Li et al., 2017; Tai et al., 2015). Other approaches represent programs through AST fragments, including path-based models such as 4

code2vec (Alon et al., 2019b) and code2seq (Alon et al., 2019a), and statement-level encoders such as ASTNN (Zhang et al., 2019a). More recently, selfsupervised pre-training has become a common foundation for code representation learning. Representative models include InferCode (Bui et al., 2021), contextual code embeddings learned with large Transformers (Kanade et al., 2020), CodeBERT (Feng et al., 2020), GraphCodeBERT (Guo et al., 2021), and CodeT5 (Wang et al., 2021). Related work also augments sequence models with global relational information to better capture dependencies that are difficult to express through token order alone (Hellendoorn et al., 2020). Since trees and token sequences capture only part of a program’s structure, a growing body of work represents code as graphs and learns over them with graph neural networks (Scarselli et al., 2009; Wu et al., 2021). Allamanis et al. (2018) augment ASTs with data-flow and apply gated graph neural networks (Li et al., 2016), while Devign (Zhou et al., 2019) combines AST, control-flow, and data-flow information in a unified graph for vulnerability detection. Graphbased representations have also been adopted in defect prediction. Zhou et al. (2022) combine ASTs with class-dependency networks, Liu et al. (2023a) enrich code representations with external knowledge, and Šikić et al. (2022) apply graph neural networks over ASTs for module-level prediction. Related work further shows the value of augmenting syntax trees with flow information for code analysis tasks (Wang et al., 2020). Recent surveys reflect this broader shift toward deep and structurally informed representations in defect prediction (Zain et al., 2023). These approaches demonstrate the value of modeling program structure, but they largely remain confined to individual files or modules and do not simultaneously capture project-wide context and satisfy the online constraints of JIT-SDP.

et al., 2014), and TransR (Lin et al., 2015), which represent relations through transformations in the embedding space. Later models improve expressiveness through bilinear or complex-valued scoring functions, including DistMult (Yang et al., 2015a), ComplEx (Trouillon et al., 2016), and RotatE (Sun et al., 2019). Neural approaches extend this line further, with models such as ConvE (Dettmers et al., 2018), relational graph convolutional networks (Schlichtkrull et al., 2018), and composition-based message-passing methods (Vashishth et al., 2020) learning over multirelational graph structure. Knowledge graphs have been applied across a wide range of domains. Large general-purpose resources such as YAGO, Freebase, and Wikidata demonstrated that relational knowledge can be organized and queried at web scale (Suchanek et al., 2007; Bollacker et al., 2008; Vrandečić and Krötzsch, 2014). In recommender systems, knowledge graphs help alleviate data sparsity and support more interpretable recommendations, as illustrated by KGAT (Wang et al., 2019), RippleNet (Wang et al., 2018), and the broader literature surveyed by Guo et al. (2022). They have also been used to integrate biomedical evidence for drug discovery (MacLean, 2021), consolidate cyber-threat intelligence (Zhao et al., 2024), and incorporate structured knowledge into language models (Zhang et al., 2019b). Dynamic knowledge graphs further extend this framework by modeling how entities and relations evolve over time (Zhang et al., 2024; Cai et al., 2024; Trivedi et al., 2017; Goel et al., 2020; Jin et al., 2020; Lacroix et al., 2020). Within software engineering, knowledge graphs have mainly been used to organize and connect software artifacts such as APIs and libraries (Wang et al., 2023; Liu et al., 2023b). For example, Liu et al. (2023b) embed an API knowledge graph to recommend analogous APIs. In contrast, knowledge graphs remain largely unexplored across software defect prediction. To the best of our knowledge, no prior work has used knowledge graphs or comparable relational representations to incorporate project-wide context into JITSDP.

2.3. Knowledge Graphs and Their Applications Knowledge graphs (KGs) represent information through entities and typed relations, providing a foundation for reasoning, retrieval, and learning (Hogan et al., 2021; Ji et al., 2022; Nickel et al., 2016). Much of the literature focuses on learning continuous representations of these entities and relations so that symbolic knowledge can be incorporated into machine learning models (Ji et al., 2022; Wang et al., 2017). Early approaches include tensor-factorization methods such as RESCAL (Nickel et al., 2011) and translational models such as TransE (Bordes et al., 2013), TransH (Wang

3. Methodology 3.1. Motivation JIT-SDP must quickly provide feedback as a change is submitted (Kamei et al., 2013). Existing models therefore rely largely on features extracted from the current commit, such as code diffs and churn metrics (Kamei et al., 2013; Hoang et al., 2019; Nagappan 5

and Ball, 2005), but these features omit broader repository context, including information around changed lines, developer experience, and developer–file relationships (Kondo et al., 2020; Cho et al., 2022; Bryan and Moriano, 2023). Maintaining and efficiently integrating such context is challenging in a just-intime setting (Kondo et al., 2020; Bryan and Moriano, 2023). KG-Commit instead maintains it incrementally in Neo4j. Each commit updates only the affected graph neighborhood, so the accumulated project context is available at prediction time through bounded Cypher queries.

3.2.3. Online Predictive Objective Given a target commit c( j) , where j > t, the objective is to estimate the conditional probability ŷ( j) that the commit is bug-inducing based on the current project state s( j−1) : ŷ( j) = P̂ y( j) = 1 c( j) , s( j−1)

(2)

3.2.4. Knowledge Graph State Representation and Evolution To avoid recomputing deep repository histories on demand, the abstract project state and its evolutionary history are captured by an incrementally updated knowledge graph K ( j) . Upon the arrival of a target commit c( j) , its corresponding entities and relations are immediately updated and inserted into the graph before classification occurs. This state evolution follows a recurrence relation defined by a state transition function Φ: K ( j) = Φ K ( j−1) , c( j) , y( j−g−1) (3)

3.2. Problem Formulation Let a software project P be represented as a chronologically ordered sequence of commits C = {c(1) , c(2) , . . . , c(n) }. Each commit c(i) ∈ C represents an evolutionary step that alters the state of the project from s(i−1) to s(i) . Each commit c(i) targets a set of pre-existing (i) files Fprev = { f1 , f2 , . . . , fm } and produces a set of mod(i) ified or newly created files Fnew = { f1′ , f2′ , . . . , f p′ }. Therefore, a commit may add, remove, modify, or rename/move one or more files in the project.

where c( j) provides the immediate modifications for the incoming commit, and y( j−g−1) injects the historical ground-truth label newly exposed by the expiration of the gap window. By unrolling this recurrence, K ( j) preserves the complete history of previous project states and commits: j j j−g−1 K ( j) = Encode {s(i) }i=1 , {c(i) }i=1 , {y(i) }i=1 , (4)

3.2.1. Defect Modeling A commit c(i) is defined as bug-inducing if and only if it introduces a defect into the codebase that requires a subsequent fix. Formally, we define the ground-truth binary label y(i) ∈ {0, 1} for each commit with index i ≥ 1 as  (i)   1 if ∃ f ∈ Fnew such that f is defective (i) y = (1)  0 otherwise

in the sense that all this information can later be accessed or reconstructed. In our case, this is made possible by using appropriate Cypher queries against the graph database. Because K ( j) embeds this entire history alongside the unlabeled properties of the recent commits, the predictive objective is resolved by conditioning on the new graph state:

In our experiments, we use the labels provided by the ApacheJIT dataset (Keshavarz and Nagappan, 2022), where bug-inducing commits are identified using an SZZ-style algorithm.

ŷ( j) = P̂ y( j) = 1 K ( j)

3.2.2. Operational Constraints To simulate real-world deployment settings, the online formulation introduces two constraints: a warmup period t and a gap g (Lee et al., 2024; Song et al., 2023). The warm-up period requires t commits to be processed before evaluation begins, restricting the target commit c( j) to indices where j > t. The gap g accounts for the operational delay in defect identification (e.g., via the SZZ algorithm), meaning that when commit c( j) arrives, historical ground-truth labels are only resolved and available up to commit c( j−g−1) .

(5)

3.3. KG-Commit KG-Commit models the evolving repository as a three-layer knowledge graph whose entity and relation schema is summarized in Table 1, while the overall online workflow is illustrated in Figure 2. The Core layer captures repository-level development context, the AST layer represents within-file program structure through an AST and updates it incrementally using delta extraction, and the Commit Semantic-Text Graph 6

(c:Commit) and -[:MODIFIED]->. During construction, MERGE avoids duplicate nodes and relationships by creating them only when they are not already present, while UNWIND enables multiple relationships to be processed in a single database request. Figure 3 shows a Core-layer query that upserts a Commit node and batchcreates its MODIFIED relationships to File nodes. At prediction time, MATCH retrieves the local neighborhood required by the inference methods.

(CSTG) adds information from commit messages and diff text through graph-of-words statistics, term associations, and propagated defect risks. Commits are processed chronologically and inserted into Neo4j. The graph is updated through Cypher operations, and only information available at that point in time is queried for prediction. The resulting graph is then used by the inference channels through a compact projection, with selected context taken from the full graph, and their outputs are combined to estimate the defect risk of the current commit.

3.3.2. Layer 1: Core Components The Core layer captures the repository’s high-level entities and their basic relations (see Figure 4). Each commit becomes a Commit node, and its bug-inducing label is attached when it becomes available; it is linked to its author (AUTHORED_BY), its children (PARENT_OF), the issues referenced in its message (FIXES_ISSUE), and the files it changes, with the edge type recording the kind of change (ADDED, MODIFIED, DELETED, RENAMED_FROM, or RENAMED_TO). The layer also captures cross-file dependencies through IMPORTS. These edges are maintained over time so that both current and historical dependencies remain represented.

Table 1: Typed schema of KG-Commit. Relation

Source → Target

Description

Core layer Entities: Commit, Developer, File, Issue AUTHORED_BY PARENT_OF FIXES_ISSUE

Commit → Developer Records commit authorship. Commit → Commit Represents repository history. Commit → Issue Links a commit to an issue.

ADDED/MODIFIED/ DELETED

Commit → File

Records file-level changes.

RENAMED_FROM/ RENAMED_TO

Commit → File

IMPORTS

File → File

Records old/new paths of a rename. Plain import.

3.3.3. Layer 2: Within-File AST Subgraph The AST layer captures the syntactic structure of Java files using a deterministic AST representation. Each file is parsed with javalang, and its parse tree is traversed in pre-order to construct the corresponding subgraph. For a file with repository-relative path rel, the ith visited node is assigned the identifier rel::A[i]. Each ASTNode records its javalang type, syntactic category, and a compact value when applicable, such as an identifier, literal, or operator; non-blank string children are represented as Identifier leaves. To ensure that the same source produces the same graph across runs, ordered child containers keep their original order, whereas unordered containers are canonically sorted. The resulting AST is attached to its File through HAS_AST, while AST_CHILD relations encode the parent–child relations and child positions.

AST layer Entities: ASTNode, Package HAS_AST

File → ASTNode

AST_CHILD

ASTNode → ASTNode

ADDS/REMOVES/ UPDATES/MOVES

Commit → ASTNode

Records the structural delta.

RESOLVES_TO

ASTNode → File

Resolves a static-member import to its owning type file.

RESOLVES_TO_ PACKAGE

ASTNode → Package

CONTAINS

Package → File

Resolves a wildcard import to its package. Records files belonging to a package.

Attaches a file to its AST root. Ordered AST parent–child relation.

CSTG layer Entities: Term, Intent MENTIONS

Commit → Term

COOCCURS

Term → Term

HAS_INTENT

Commit → Intent

GROUNDS_IN

Term → ASTNode

Records terms occurring in a change. NPMI-based term association. Assigns the commit’s intent. Grounds code terms in matching AST leaves.

AST matching and delta extraction. For a modified file, let Ab and Aa be the stored and newly parsed ASTs. The matcher constructs a partial injective correspondence µ : V(Ab ) ⇀ V(Aa ) in three stages. First, each node is assigned a bottom-up fingerprint: Let u1 , . . . , uk be the ordered children of v, and define h(v) = H(ℓ(v)∥h(u1 )∥ · · · ∥h(uk )) where ℓ(v) = ast_type(v)∥value(v). Here, ∥ denotes an unambiguous concatenation and H is the MD5 message-digest algorithm (Rivest, 1992). This bottom-up construction is

3.3.1. Cypher Queries KG-Commit is stored in Neo4j and accessed through Cypher, its declarative graph query language (Francis et al., 2018). Cypher specifies graph patterns through labeled nodes and typed relationships, such as 7

Figure 2: Overview of KG-Commit’s online workflow.

commonly known as subtree hashing or syntax-tree fingerprinting (Chilowicz et al., 2009). Equal fingerprints identify candidate identical subtrees. Larger candidate subtrees are processed first, with source position used to break ties, following the general strategy of prioritizing large isomorphic subtrees in AST differencing (Falleri et al., 2014). Second, matches are propagated to unmatched parents of the same AST type until a fixpoint is reached. Third, remaining nodes are matched by (ast_type, line, column) whenever this tuple is unique. The unmatched and changed nodes define the delta:

// (1) upsert an entity node by primary key MERGE (e:Commit {id: $pk_value}) ON CREATE SET e += $props ON MATCH SET e += $props // (2) batch-create the process edges from one source node MATCH (src:Commit {id: $src_id}) UNWIND $targets AS t MERGE (tgt:File {id: t.target_id}) MERGE (src)-[r:MODIFIED]->(tgt) ON CREATE SET r += t.props

Figure 3: Core-layer Cypher query: (1) upserts a Commit node by its identifier, and (2) batch-creates MODIFIED relationships to the corresponding File nodes.

R = V(Ab ) \ dom(µ), developer

Issue File A D DE AD

FIXES ISSUE AUTHORED BY

IMPORTS

File B

IFIED MOD

Commit c

RENAM

ED FRO

NA M

PARENT OF

File D old path

ED TO

File D new path

Here, R, A, U, and M denote REMOVES, ADDS, UPDATES, and MOVES respectively. Figure 5 illustrates the resulting correspondence and edit classes.

parent commit

(6)

A = V(Aa ) \ ran(µ), (7)    ast_type(b) , ast_type(a)   U=  (b, a) ∈ µ ∨ value(b) , value(a) , (8)     par(b) ∈ dom(µ)   (9) M= . (b, a) ∈ µ ∧ µ(par(b)) , par(a)

File C

Online delta maintenance. Commits are processed in chronological order while the system preserves, for each

Figure 4: Illustration of the Core layer.

After Aa

Before Ab

*Error are preserved. Terms are assigned types in {code, bug, action, error, natural-language}. The extraction rules for these types are summarized in Table 2. Each commit yields a graph-of-words whose terms are linked to the commit through weighted MENTIONS relations. Across previously observed commits, associated terms are connected through COOCCURS, and each term receives a defect-risk estimate obtained from past observations and propagated through this term-association graph. The resulting CSTG schema is illustrated in Figure 6.

Commit

c( j)

REMOVES

UPDATES

ADDS

MOVES

Block B0

Assign A1

Block B0

Assign A2

Assign A1

Return R1

Assign A2

Return R1

Id x

Lit 1

Id y

Lit 2

Print P1

Lit 42

Id x

Id y

Lit 2

Id y BinOp Opb

Print P2

Table 2: Term types used by CSTG and their extraction rules.

BinOp Opb Id a Id a

Id b

Id x

Id b

Type

Extraction rule

error

Identifiers denoting exception or error types, including identifiers ending in Exception or Error.

code

Program identifiers recognized from camel-case, snake-case, or dotted forms.

bug

Terms belonging to a fixed defect vocabulary, including concepts such as npe, leak, race, deadlock, and regression.

action

Terms belonging to a fixed change-action vocabulary, such as add, fix, refactor, and revert.

M A = adds

R = removes

U = updates

M = moves

Figure 5: Simplified illustration of AST deltas between the before tree Ab and the after tree Aa .

tracked file, its current AST and the mapping from parse identifiers to persistent graph identifiers. Added files are materialized once, files first encountered as modifications are initialized from their parent revision, and deleted files have their live nodes marked inactive. During a modification, matched nodes keep their identifiers, inserted nodes receive new identifiers, and removed nodes remain queryable through alive= false. The live AST_CHILD relations are updated in place, while the commit stores only the resulting ADDS, REMOVES, UPDATES, and MOVES relations. Thus, storage and update costs follow the amount of syntactic change.

natural-language Remaining lexical terms, including subwords obtained by splitting compound program identifiers.

Alternative within-file representations. Besides AST, we evaluate control-flow graph (CFG), data-flow graph (DFG), and program dependence graph (PDG) as alternative within-file representations. Each representation is mapped to the same ADDS, REMOVES, UPDATES, and MOVES delta vocabulary used for AST, where CFG, DFG, and PDG use a graph-specific ordinal matcher rather than the tree-specific AST matcher (see Appendix A for details). 3.3.4. Layer 3: Commit Semantic-Text Graph (CSTG) The third layer represents the semantics of a change using its commit message and diff text. For each commit c, we concatenate the message with lexical tokens from changed lines to form xc . The text is tokenized and lower-cased, camel-case identifiers are split, and defect-relevant identifiers such as *Exception and

Figure 6: CSTG schema for a commit. Darker term nodes indicate higher propagated defect risk.

weight is mc (t) = TRc (t) log((|Ctr | + 1)/(df(t) + 1)), combining within-commit centrality with corpus-level rarity as a TextRank-based variant of graph term-weight IDF (Rousseau and Vazirgiannis, 2013). Across training commits, term associations are measured by NPMI (Church and Hanks, 1990; Bouma, 2009); a COOCCURS edge is kept only when its support is at least nmin and its NPMI is at least τT . Each term is initialized with smoothed defect risk r(0) (t) = (bugdf(t) + λȳ)/(df(t) + λ) and propagated over the row-normalized term graph as r⋆ = (1 − αT )r(0) + αT PT r⋆ , imposing smoothness over associated terms (Belkin et al., 2006). CSTG finally summarizes this information through the weighted textual-risk prior P P ρ(c) = t mc (t)r⋆ (t)/ t mc (t) and type-specific semanP tic masses Mκ (c) = type(t)=κ mc (t) for the five term types defined above. An example of the resulting global term graph is shown in Figure 7.

Commits are also linked to Intent nodes through HAS_INTENT. Each commit receives exactly one intent from {fix, feat, refactor, test, docs, perf, revert, other}. Intent is assigned by a deterministic keyword rule over the lower-cased commit message; occurrences of the keywords associated with each class are counted, the highest-scoring class is selected, and other is returned when no keyword matches. Repeated occurrences contribute repeatedly to the class score. The complete taxonomy is given in Table 3. The GROUNDS_IN relation provides the bridge from CSTG to the AST layer (Section 3.3.3). It is created only for code Term nodes and connects them to live AST leaves whose stored value exactly equals the term text. Deleted AST nodes are excluded, and the number of matching leaves is capped for highly common identifiers. Table 3: Intent taxonomy and keyword rules used by CSTG. Truncated stems such as optimi and deprecat intentionally match multiple inflected forms.

Intent

Keywords

fix

fix, bug, issue, error, fault, defect, npe, crash, fail, correct, resolve, patch, wrong, broken

feat

add, feature, implement, introduce, support, new, allow, enable, provide

refactor

refactor, cleanup, clean up, simplify, rename, reorganize, restructure, tidy, inline, extract, deprecat

test

test, junit, assert, coverage, spec

testcase,

docs

doc, documentation, readme, comment, license

javadoc,

perf

perf, performance, optimi, speed, faster, cache, latency

revert

revert, rollback, roll back, undo, back out

other

No keyword from the preceding classes occurs.

Figure 7: Example of global CSTG term graph. Edges denote retained positive NPMI associations, and node color indicates propagated term risk r⋆ (t).

3.3.5. Inference over KG-Commit We use five graph-based inference channels: Relational Neighbor (RN) (Macskassy and Provost, 2003), Personalized PageRank (PPR) (Haveliwala, 2002), clamped Label Propagation (LP) (Zhu et al., 2003), DeepWalk matrix factorization (DW) (Perozzi et al., 2014), and DistMult knowledge-graph embedding (KGE) (Yang et al., 2015a). A sixth, feature-based G channel uses the semantic statistics derived from components in Section 3.3.4 (see Appendix D for full construction details).

For each commit c, the distinct normalized terms Vc form a weighted graph-of-words in which terms co-occurring within a window of w tokens are connected (Rousseau and Vazirgiannis, 2013), preserving local dependencies that a bag-of-words model discards (Rousseau and Vazirgiannis, 2015). Each term receives a weighted TextRank score TRc (t) with damping factor d (Mihalcea and Tarau, 2004), and its MENTIONS 10

tically usable for online JIT-SDP. To achieve this objective, we formulate four main research questions as follows:

3.3.6. Projection for Lightweight Graph Inference The five graph-based inference methods operate on a compact projection of KG-Commit. At commit j, this projection summarizes the neighborhood of each commit in the full graph as a weighted bipartite graph P( j) . RN, PPR, LP, DW, and KGE operate on this smaller graph, keeping graph inference practical on CPU. The construction of the projection and the corresponding inference procedures are described in Appendix C. The projection does not include every relation in the full graph. For example, cross-file IMPORTS relations remain in K ( j) and are not part of P( j) . We therefore also derive a small traversal/global-context (TGC) vector from the full graph. For a commit c, we denote this vector by h i T(c) = T0 (c), T1,dep (c), T1,dry (c), TP (c), M1 (c) .

4.1. Research Questions • RQ1. What is the predictive performance of KGCommit in Just-in-Time Software Defect Prediction? • RQ2. How well does KG-Commit maintain computational efficiency and scalability across the real-time evolution of different software projects?

• RQ3. How do architectural choices regarding within-file subgraph representations and distinct KG-Commit layers affect the predictive performance?

The grouped vector covers the files changed by the commit (T0 (c)), their untouched importers and importees, split by direction (T1,dep (c) and T1,dry (c)), files in the same package (TP (c)), and their architectural position in the dependency graph (M1 (c)), summarized using PageRank and k-core (Brin and Page, 1998; Batagelj and Zaversnik, 2003). The extracted values are cached and used together with the projection-based inference scores. The individual TGC features and their computation are described in Appendix E.

• RQ4. How does KG-Commit’s predictive performance change across different inference channels? 4.2. Dataset We perform the evaluation on 11 software projects from ApacheJIT (Keshavarz and Nagappan, 2022). The selected projects, shown in Table 4, contain 78,206 evaluated commits, of which 22,740 are bug-inducing and 55,466 are clean, corresponding to an overall buginducing rate of approximately 29.1%. Labels are produced using the SZZ algorithm (Śliwerski et al., 2005) and refined by linking fixes to issue reports and filtering trivial edits with GumTree over abstract syntax trees, following established filtering procedures (McIntosh and Kamei, 2018). Each commit is described by fourteen fields: a commit identifier, the binary buginducing label, and twelve change metrics that follow the definitions of Kamei et al. (2013). Because these metrics are highly right-skewed, we apply a logarithmic transform.

Score fusion. We use logistic-regression stacking (Wolpert, 1992) to combine the different inference outputs. Let F ⊆ {RN, PPR, LP, DW, KGE} denote a selected set of graph-based channels, with sm (c) denoting the score of channel m. We use F for their stacked combination, G for the CSTG channel, F + G for their joint model, and F + G + T when the TGC features T(c) are also included. The full model is   X   ⊤  b y(c) = σ θ0 + θm sm (c) + θG G(c) + θT T(c) , m∈F

where θ0 is the intercept, θm and θG are the coefficients of the graph and CSTG scores, and θT contains the coefficients of the TGC features. Removing the corresponding terms gives the F and F + G variants. For deployment, a fixed overall subset Fov ⊆ F may be used across projects (see Section 4.4).

4.3. Baselines Logistic Regression (LR). It is the classical changemetric baseline used in JIT-SDP (Kamei et al., 2013). It operates on the twelve ApacheJIT change metrics after the transformations described in Section 4.2 and uses ℓ2 -regularized logistic regression with balanced class weights.

4. Experimental Design The objective of this study is to determine whether KG-Commit can make rich, project-wide context prac11

Table 4: ApacheJIT projects used in the evaluation (Keshavarz and Nagappan, 2022). Percentages give the ratio of bug-inducing commits to total evaluated commits.

Project

Bug-inducing

ActiveMQ Camel Cassandra Flink Groovy HBase Hive Kafka Spark Zeppelin Zookeeper

1,404 (23%) 4,722 6,126 3,078 (14%) 19,617 22,695 3,117 (38%) 5,042 8,159 2,811 (25%) 8,648 11,459 1,614 (20%) 6,445 8,059 3,782 (43%) 4,945 8,727 4,223 (62%) 2,619 6,842 1,115 (47%) 1,269 2,384 632 (43%) 833 1,465 622 (43%) 829 1,451 342 (41%) 497 839

Total

Clean

4.4. Experimental Protocol Evaluation follows an online protocol. For each incoming commit, a prediction is produced using only the information at that point in the stream. The labels enter the historical state only after they become available under the gap parameter g introduced in Section 3.2.2. Let K denote the warm-up fraction and t = ⌊KN⌋ for a project with N commits. Commits before t initialize the graph. The refit window M determines how often model components are refitted, while commits are still processed one by one. We use a shared setting of K = 0.05 and g = 50 for KG-Commit and baselines, and M = 200 for all learnable models that need a refit. Threshold-dependent metrics use an online operating point. The threshold is initialized at 0.5 and, after the first 300 predictions, is re-estimated every 150 commits to maximize Macro-F1 on past commits. Throughout Section 5, Fov denotes the fixed graph fusion RN, PPR ⊆ F (Section 3.3.5); the rationale for this choice is examined in Section 5.4. The primary KGCommit configuration augments Fov with the semantic CSTG channel G and the traversal/global-context feature block T , forming Fov +G+T (Section 3.3.6). Unlike the graph channels, G requires sufficient history to construct a vocabulary and is therefore unreliable during cold start. The S@200 policy addresses this problem by using Fov alone for the first 200 evaluated commits after warm-up and then switching once to Fov +G for the remainder of the stream, as discussed further in Section 6.3. The addition of T does not change the definition of this switch. S@200 continues to denote the one-time introduction of the history-dependent configuration and is distinct from the periodic refit interval M = 200. Unless an experiment explicitly performs a controlled ablation or sensitivity analysis, the reported KG-Commit result corresponds to Fov +G+T . For compactness, tables and figures may denote this configuration as F+G+T , with F = Fov .

Total

22,740 (29.1%) 55,466 78,206

Histogram Gradient Boosting (HGB). It uses the same twelve change metrics but replaces the linear decision function with a histogram-based gradient-boosting classifier. It provides a non-linear change-metric baseline while keeping the input information identical to LR. Class weighting is used to account for label imbalance. Random Forest (RF). RF uses the same twelve ApacheJIT change metrics and the same featureextraction pipeline as LR and HGB, differing only in the classifier. LApredict (Zeng et al., 2021). This baseline deliberately uses only the number of added lines. We implement it using the same class-weighted logisticregression family as LR. DeepJIT (Hoang et al., 2019). Our implementation follows the official DeepJIT architecture, with separate convolutional encoders for the commit message and changed code, a hierarchical convolution over changed code lines, concatenation of the message and code representations, a 512-unit fully connected layer, and a sigmoid output. The implementation is adapted to our online evaluation setting.

Reproducibility of Results Across Different Runs. We assessed seed sensitivity across five runs. The Fov +G backbone reproduces to numerical precision, and the added TGC extraction and liblinear stacking head are deterministic for a fixed commit stream, so T does not introduce an additional source of random variation. Graph-only fusions containing learned channels show greater run-to-run variation, as examined in Section 5.4. LR and LApredict are deterministic, HGB shows negligible variation (3.9 × 10−4 in Macro-F1), and JITLine-online is evaluated with a fixed random state. Only RF and DeepJIT exhibit noticeable seed sensitivity, with mean Macro-F1 standard deviations of

JITLine (Pornprasit and Tantithamthavorn, 2021). This method combines the twelve expert change metrics with token information extracted from the code diff and trains a random-forest classifier on the resulting representation. The implementation is adapted to our online evaluation setting. 12

0.0097 and 0.0102, respectively. Given this limited variation, Section 5 reports aggregate performance only. 4.5. Experimental Settings

Table 5: Model hyperparameters and configurations used for KGCommit and the evaluated baselines.

Table 5 summarizes the model configurations and hyperparameters used throughout the experiments, while Table 6 reports the corresponding execution environments and software stacks. The reported settings are fixed across projects, and parameters not listed in the tables keep their implementation defaults. KG-Commit and all non-neural baselines are executed in the same CPU environment. DeepJIT (Hoang et al., 2019), which requires repeated training of convolutional neural components, is implemented and executed separately in a Kaggle notebook using a single NVIDIA Tesla T4 GPU. Because DeepJIT is executed on different hardware, its runtime is reported for completeness only and should be excluded from hardware-matched runtime comparisons.

Component / Parameter KG-Commit graph inference Relational Neighbor (RN) Neighborhood depth Learned embedding Personalized PageRank (PPR) Restart probability α Power iterations Label Propagation (LP) Propagation iterations DeepWalk (DW) Matrix representation Factorization Embedding dimension DistMult (KGE) Embedding dimension Optimizer Learning rate η Epochs per refit Negative samples per positive Triple-update chunk size Classifier heads Classifier Solver Class weighting Maximum iterations

4.6. Evaluation Metrics Given the class imbalance of bug-inducing commits, √ we primarily report Macro-F1, AUC, and G-Mean = TPR · TNR as class-balanced measures. We also use two effort-aware metrics with inspection effort defined as la + ld, including the normalized Popt , which measures how closely the effort-ranked inspection order approaches the optimal buggy-first, least-effort-first ranking, and ACC@20%LOC (Kamei et al., 2013), which measures the proportion of bug-inducing commits found within the top 20% of cumulative changed lines. Average rows in Section 5 report an unweighted macro-average over projects and a micro-average over their pooled predictions. For runtime and lifecycle measurements in Section 5.2, we report the mean, standard deviation (SD), median, and selected percentiles where appropriate. P05, P50, and P95 denote the 5th, 50th, and 95th percentiles, respectively, representing the lower tail, median, and upper tail of the observed distribution.

CSTG semantic channel TextRank damping factor TextRank iterations Minimum term co-occurrence Risk-prior smoothing constant Hashed-text dimension Typed semantic-mass dimension

Value

1 hop None 0.15 40 3 PPMI Truncated SVD 64 32 SGD 0.05 3 3 2,048 Logistic Regression lbfgs balanced 1000 0.85 30 2 5 218 5

Traversal / global-context channel (TGC) Feature groups T0 , T1,dep , T1,dry , TP , M1 Dependency traversal depth 1 hop, directionseparated Architectural position PageRank, k-core Feature scaling raw and expandingwindow z-score z-score warm-up 30 commits Tier extraction once per project, cached Stacking head Logistic Regression Penalty ℓ1 , C = 0.2 Solver liblinear Class weighting balanced Feature standardization StandardScaler Baseline models Logistic Regression (LR) Penalty Class weighting Histogram Gradient Boosting (HGB) Classifier Class weighting LApredict Classifier Class weighting JITLine Classifier DeepJIT Optimizer embedding dim filter sizes num filters hidden units dropout keep prob learning rate l2 reg lambda / weight decay epochs

5. Experimental Results 5.1. RQ1: Predictive Performance against Baselines KG-Commit achieves the highest aggregate MacroF1, G-Mean, and AUC among the evaluated methods (Table 7), with their project-level distributions shown in Figure 8. It improves Macro-F1 over RF (0.649 → 0.704), LApredict (0.637 → 0.704), HGB (0.636 → 0.704), DeepJIT (0.618 → 0.704), LR (0.579 → 0.704), and JITLine-online (0.674 → 0.704). The 13

ℓ2 balanced HistGradientBoosting balanced Logistic Regression balanced Random Forest Adam 64 (1, 2, 3) 64 512 0.5 10−4 10−5 10

Table 6: Execution environments, hardware resources, and software versions used in the experiments. Value

KG-Commit execution environment Processor CPU cores / threads CPU base frequency Memory GPU usage

Intel Core i7-13620H 10 / 16 2.4 GHz 16 GB RAM None (CPU-only)

KG-Commit software stack Python Neo4j Community neo4j Python driver Git javalang NumPy SciPy scikit-learn pandas networkx

3.13.5 2026.05 6.2.0 2.45.1 0.13.0 2.2.6 1.16.2 1.7.2 2.3.2 3.5

DeepJIT execution environment Platform Accelerator GPU compute capability

Kaggle Notebook NVIDIA Tesla T4 7.5 (sm 75)

DeepJIT software stack Python PyTorch CUDA runtime

3.12.13 2.10.0+cu128 12.8

0.8

0.579 0.618 0.636 0.637 0.649 0.674 0.704

0.7

Macro-F1

Component / Resource

0.6 0.5 0.4 (a) Macro-F1.

0.568 0.633 0.641 0.655 0.660 0.686 0.706 0.75

G-Mean

pairwise Macro-F1 summary in Table 7 shows W/T/L records of 11/0/0 against RF, HGB, DeepJIT, and LR, 10/0/1 against LApredict, and 9/0/2 against JITLineonline. These differences are statistically significant across all six baselines. For G-Mean and AUC, the paired differences are also significant against the other five baselines, but not against JITLine-online (p = .116 and p = .067, respectively). The online evolution of Macro-F1 across the project streams is shown in Figure 9. The effort-aware comparison with JITLine-online also favors KG-Commit (Table 8). KG-Commit achieves a higher Macro-Avg Popt (0.889 versus 0.878) and ACC@20%LOC (0.653 versus 0.633), with W/T/L records of 9/1/1 and 10/0/1 respectively. The paired differences are statistically significant for both Popt (p = .004) and ACC@20%LOC (p = .002). At the project level, the relative performance varies across the two measures, but the aggregate results indicate that KGCommit’s predictive gains remain evident when inspection effort is taken into account.

0.60 0.45

(b) G-Mean.

0.88

0.716 0.720 0.750 0.768 0.774 0.792 0.809

AUC

0.80 0.72 0.64 0.56

LR epJIT redict De LAp

HGB

RF ITLine mmit J Co KG-

Figure 8: Project-level distributions of the performance metrics under the online protocol. Each boxplot summarizes results over the 11 ApacheJIT projects (Section 4.2). Aggregate means are annotated above the boxplots, and individual project values are overlaid to show cross-project variation.

5.2. RQ2: Efficiency and Scalability We compare the computational cost of processing each incoming commit in Table 9. For KG-Commit, routine per-commit processing includes graph ingestion, context retrieval, and prediction. For the baselines, it includes the corresponding featurization and prediction steps. Periodic model refitting is reported separately because it is triggered only every M = 200 commits. 14

Table 7: Performance of KG-Commit and baselines under the online protocol (Section 4.4) over ApacheJIT projects (Section 4.2). The best model for each metric is shown in bold within every project and aggregate row. The final rows summarize pairwise differences between KG-Commit (F+G+T ) and each baseline; W/T/L denotes project-level wins/ties/losses, and Wilcoxon p values are from two-sided paired tests over the 11 project scores. KG-Commit (F+G+T , S@200)

Project

Macro-F1 G-Mean

AUC

JITLine-online

LApredict

Macro-F1 G-Mean AUC Macro-F1 G-Mean

AUC

HGB

Macro-F1 G-Mean

AUC

DeepJIT

Macro-F1 G-Mean

AUC

Macro-F1 G-Mean

AUC

Macro-F1 G-Mean

AUC

ActiveMQ Camel Cassandra Flink Groovy HBase Hive Kafka Spark Zeppelin Zookeeper

0.712 0.685 0.713 0.758 0.700 0.743 0.666 0.789 0.624 0.648 0.707

0.730 0.698 0.724 0.754 0.736 0.743 0.603 0.791 0.621 0.650 0.714

0.816 0.832 0.799 0.852 0.820 0.815 0.818 0.869 0.721 0.755 0.802

0.689 0.663 0.714 0.723 0.666 0.673 0.648 0.740 0.639 0.628 0.630

0.720 0.703 0.728 0.777 0.731 0.671 0.580 0.741 0.636 0.622 0.640

0.793 0.790 0.808 0.849 0.795 0.794 0.805 0.861 0.758 0.745 0.717

0.644 0.627 0.694 0.697 0.619 0.681 0.635 0.705 0.570 0.635 0.636

0.677 0.669 0.708 0.747 0.676 0.681 0.561 0.705 0.557 0.634 0.647

0.757 0.758 0.792 0.815 0.739 0.785 0.805 0.833 0.760 0.736 0.731

0.661 0.612 0.671 0.714 0.613 0.679 0.488 0.675 0.616 0.700 0.583

0.700 0.655 0.686 0.730 0.688 0.680 0.345 0.676 0.614 0.693 0.587

0.762 0.691 0.778 0.805 0.724 0.767 0.737 0.807 0.747 0.702 0.728

0.625 0.631 0.680 0.663 0.575 0.669 0.645 0.720 0.565 0.601 0.626

0.682 0.685 0.695 0.726 0.664 0.667 0.573 0.722 0.560 0.594 0.636

0.756 0.756 0.790 0.809 0.730 0.795 0.814 0.842 0.731 0.709 0.718

0.626 0.594 0.691 0.667 0.627 0.675 0.631 0.719 0.493 0.521 0.558

0.681 0.679 0.706 0.705 0.693 0.675 0.561 0.717 0.463 0.513 0.567

0.747 0.747 0.776 0.773 0.759 0.764 0.729 0.800 0.639 0.624 0.566

0.613 0.605 0.670 0.687 0.598 0.566 0.566 0.679 0.532 0.466 0.384

0.633 0.615 0.684 0.699 0.648 0.551 0.468 0.677 0.513 0.413 0.352

0.696 0.715 0.750 0.770 0.718 0.716 0.753 0.812 0.718 0.613 0.613

Macro-Avg Micro-Avg

0.704 0.709

0.706 0.713

0.809 0.823

0.674 0.680

0.687 0.704

0.792 0.803

0.649 0.653

0.660 0.676

0.774 0.777

0.637 0.637

0.641 0.652

0.750 0.743

0.636 0.641

0.655 0.674

0.768 0.775

0.618 0.633

0.633 0.670

0.720 0.751

0.579 0.612

0.568 0.613

0.716 0.729

+.030 9/0/2 .005

+.020 7/0/4 .116

+.017 9/0/2 .067

+.055 11/0/0 < .001

+.046 11/0/0 < .001

+.035 10/0/1 .019

+.067 10/0/1 .010

+.065 10/0/1 .011

+.059 10/0/1 .003

+.068 11/0/0 < .001

+.051 11/0/0 < .001

+.041 10/0/1 .005

+.086 11/0/0 < .001

+.073 11/0/0 < .001

+.089 11/0/0 < .001

+.125 11/0/0 < .001

+.137 11/0/0 < .001

+.093 11/0/0 < .001

Mean ∆ W/T/L Wilcoxon p

– – –

ActiveMQ

Camel

0.8

Macro-F1

0.7

Cassandra

0.6

0.55

0.5

0.50

0.4

0.45 1000

2000

3000

4000

5000

6000

Flink

5000

10000

15000

20000

1000

0.5 0.4 2000

4000

6000

8000

0.8

0.5

0.4

0.4 2000

3000

4000

5000

6000

7000

8000

1000

Kafka

0.9

0.4

1000

2000

3000

4000

5000

6000

7000

500

1000

1500

2000

0.5 0.4 0.3 400

600

800

1000

Commit index

1200

1400

KG-Commit (RN+PPR, S@200)

6000

7000

8000

9000

600

800

1000

Commit index

1200

1400

All 11 projects (pooled)

0.80

0.8 0.7 0.6 0.5 0.4 0.3 0.2 0.1

0.6

5000

Spark

400

Zookeeper

0.7

4000

0.4

Zeppelin

0.8

3000

0.5

0.3

8000

0.6

0.6 0.5

7000

0.7

0.5

2000

0.8

0.6

6000

0.6

1000

0.7

5000

0.7

0.5

10000

Hive

4000

HBase

0.6

3000

0.8

0.7

2000

Groovy

0.8

Macro-F1

0.7

0.60

0.6

0.4

Macro-F1

0.8

0.70 0.65

0.5

Macro-F1

0.75

0.75 0.70 0.65 0.60 0.55 0.50 0.45 300

400

KG-Commit (F+G+T)

500

600

700

800

HGB

LApredict

Commit index

DeepJIT

% through each project's stream

100

JITLine-online

Figure 9: Running online Macro-F1 of KG-Commit compared with the online implementation of baselines. The rolling window is w=150 at stride 25.

Table 8: Effort-aware comparison of KG-Commit and JITLine-online. For each KG-Commit result, parentheses report the absolute difference from JITLine-online. The best value for each metric is shown in bold. The final rows summarize project-level differences, wins/ties/losses, and two-sided paired Wilcoxon tests over the 11 projects. KG-Commit(F+G+T )

Project

JITLine-online

ACC@20

Popt

ACC@20

Popt

0.857 (.010↑) 0.624 (.023↑) 0.847 0.837 (.024↑) 0.625 (.034↑) 0.813 0.914 (.000=) 0.696 (.003↑) 0.914 0.860 (.007↑) 0.591 (.005↑) 0.853 0.863 (.013↑) 0.678 (.035↑) 0.850 0.927 (.007↑) 0.716 (.010↑) 0.920 0.952 (.002↓) 0.737 (.001↓) 0.954 0.907 (.007↑) 0.632 (.008↑) 0.900 0.841 (.004↑) 0.531 (.014↑) 0.837 0.915 (.012↑) 0.682 (.028↑) 0.903 0.901 (.030↑) 0.676 (.065↑) 0.871

0.601 0.591 0.693 0.586 0.643 0.706 0.738 0.624 0.517 0.654 0.611

Macro-Avg 0.889 (.011↑) 0.653 (.020↑) 0.878 Micro-Avg 0.877 (.012↑) 0.653 (.019↑) 0.865

0.633 0.634

Mean ∆ W/T/L Wilcoxon p

+.020 10/0/1 .002

ActiveMQ Camel Cassandra Flink Groovy HBase Hive Kafka Spark Zeppelin Zookeeper

– – –

+.010 9/1/1 .004

– – –

Table 10 reports the graph scale, inference latency, and ingest cost of KG-Commit for each project. Graphinference component Fov =RN+PPR, has a median inference time of 0.325 ms and a median p95 of 0.399 ms. The overall runtime of KG-Commit is instead dominated by graph ingestion, whose median cost is approximately 1.33 s per commit. DeepWalk and KGE are faster to apply, at approximately 0.001 ms, but require periodic refitting, whereas RN and PPR operate directly on the graph. The AST delta is highly skewed: the median commit changes 282 edges, compared with 5,107 at the p95 , with a Gini coefficient of 0.78. Ingest cost is therefore driven mainly by a small number of large commits rather than the accumulated project history. Lifecycle and Scaling. Figure 10 shows how the graph and its deployment costs grow with project history. Figure 10a shows the accumulated edges, while Figure 10b and Figure 10c show that per-commit work does not increase with it. In the final fifth of Camel’s history, the median AST delta and ingest time are 0.55× and 0.86× their values in the first fifth, and median ingest time remains approximately 1.16 s. Ingest cost therefore depends mainly on the incoming change instead of the existing graph size. Figure 10d and Figure 10e show that soft deletion preserves historical structure while storage grows linearly. Figure 10f and the corresponding analyses of the other projects show the same trends. We present Camel because it is the most demanding case, with 22,695 commits, 12.4 million cumulative AST edges, and an estimated footprint of 699 MB.

KG-Commit’s routine cost is dominated by graph ingestion, with a median of approximately 1.33 s per commit. The isolated graph-retrieval and Fov = RN+PPR inference components require only 0.116 ms and 0.325 ms respectively. The added TGC values in Section 3.3.6 are cached and read as a compact feature vector ( Appendix E); they do not introduce an additional full-graph Neo4j traversal. The evaluated baselines require approximately 7.9–8.5 ms per commit before periodic refitting. KG-Commit therefore incurs higher per-commit computation in exchange for maintaining rich project-wide context. Whether this additional cost is operationally important depends on the rate at which commits arrive. As discussed in Section 6.2, the observed commit arrival time is much larger than KG-Commit’s processing time across all 11 projects.

5.3. RQ3: Contribution of KG-Commit Layers to Predictive Performance Table 11 examines the contribution of KG-Commit’s representation layers while holding inference fixed at Fov . The graph is progressively enriched from Core to AST and then CSTG, so differences in performance reflect changes in the representation itself. Layer 2 provides little benefit under Fov , whereas adding CSTG consistently improves Fov results across all projects, increasing the median Macro-F1 from 0.552 for Core to 0.644 for CSTG. The same pattern can be seen throughout the commit stream in Figure 11 and across projects in Figure 12. The limited gain from AST suggests that the generic inference methods in Section 3.3.5 do not fully exploit its fine-grained structure. CSTG, in contrast, introduces semantic entities and relations that are more accessible to RN and PPR. This result is separate from the CSTG feature channel G and the traversal/global-context feature block T , which augment the graph-based inference

Table 9: Median runtime costs across all projects. Routine processing includes the work performed for every incoming commit. Periodic refit is reported separately and amortized over M = 200 commits. Feat., retr., and pred. denote featurization, retrieval, and prediction. ∗ Includes computation of the 12 change metrics. KGCommit

HGB

LA JITLine DeepJIT predict online

Routine per-commit processing (ms/commit) Ingest 1,330 – – – Feat. – 7.912∗ 7.912∗ 7.912∗ Retr. 0.116 – – – Pred. 0.325 0.001 0.009 0.245 Total ≈1,330.44 7.913 7.921 8.157

– 7.885 – 0.001 7.886

– 7.912∗ – 0.363 8.275

– 8.213 – 0.298 8.511

53.04

9.85

Periodic refit (amortized over M = 200 commits) Refit

1.05

0.04

2.83

2.08

0.02

Table 10: Internal cost profile of KG-Commit by project. Nc is the number of commit nodes, and c/s is the processing throughput in commits per second. The inference columns isolate the five projection-based graph channels and Fov = RN+PPR (Section 3.3.6); F-p95 is the 95th-percentile latency of this graph component. The TGC block used by the final Fov +G+T configuration is cached separately ( Appendix E). Under Ingest, ms is graph-update time per commit, edges is the total AST delta (Section 3.3.3), and p50 , p95 , and Gini describe the AST-delta distribution.

Graph

Inference time (ms/commit) PPR

KGE

Fov

Fp95

ActiveMQ 6,126 3,080 0.078 0.247 Camel 22,695 740 0.362 0.989 Cassandra 8,159 1,691 0.152 0.440 Flink 11,459 1,066 0.242 0.697 Groovy 8,059 3,219 0.103 0.208 HBase 8,727 1,547 0.161 0.485 Hive 6,842 1,846 0.133 0.409 Kafka 2,384 5,855 0.046 0.124 Spark 1,465 14,022 0.017 0.054 Zeppelin 1,451 11,652 0.023 0.063 Zookeeper 839 18,494 0.015 0.039

0.027 0.100 0.046 0.069 0.038 0.049 0.041 0.016 0.010 0.011 0.008

0.001 0.002 0.001 0.001 0.001 0.001 0.001 0.001 0.001 0.001 0.001

0.001 0.001 0.001 0.001 0.000 0.001 0.001 0.001 0.001 0.001 0.001

0.325 1.352 0.591 0.938 0.311 0.646 0.542 0.171 0.071 0.086 0.054

0.399 1.509 0.775 1.078 0.367 0.796 0.677 0.336 0.088 0.116 0.062

1,277 1,163 1,519 1,330 823 1,648 2,177 2,324 1,238 1,243 1,497

Median

6,842

c/s

Ingest & per-commit AST delta

0.325

3,080

1,330

edges p50 3.27M 12.38M 11.84M 16.67M 3.61M 14.01M 12.20M 3.17M 0.82M 1.63M 0.78M

97 133 283 371 84 293 383 375 153 213 282

p95 Gini 1,848 2,044 6,438 6,515 1,464 6,578 7,621 6,083 2,310 5,107 3,917

0.80 0.78 0.78 0.75 0.83 0.81 0.79 0.74 0.76 0.79 0.72 0.78

computed directly from the graph topology and require no fitting, periodic refitting, random initialization, or seed control, unlike fusions that include learned embedding channels. Consequently, Fov is reproducible and cheap to serve with a median inference cost of 0.325 ms per commit. Figure 13 illustrates how Fov and G complement each other. Their fusion raises mean Macro-F1 to 0.676, compared with 0.641 for Fov and 0.646 for G alone. S@200 slightly improves the mean further to 0.681 and narrows the central spread, although its main benefit is during cold start, when it delays the CSTG channel until the project has accumulated 200 commits (see Section 6.3). Adding T further increases the mean MacroF1 to 0.704, giving the highest performance among the evaluated configurations.

through F+G and F+G+T , shown in Figure 11 and Figure 12. The four Layer-2 alternatives perform similarly, and their ordering varies across projects (Table 11). Among these Layer-2 candidates, we select AST because its incremental delta can be computed using canonical subtree hashing (Section 3.3.3), whereas alternative choices require an ordinal fallback matcher ( Appendix A). AST also contains more nodes and edges (Section 5.2, Figure 10a), potentially capturing richer structures that Fov may not fully exploit, a limitation we revisit in Section 6.6. Performance also varies across projects and inference methods. For example, Macro-F1 for Fov with CSTG ranges from 0.525 on Zeppelin to 0.723 on Kafka (Table 11). The results can vary across the individual inference methods, with Cassandra ranging from 0.327 for LP to 0.643 for KGE (see Appendix B). We study the differences among inference channels in Section 5.4.

6. Discussion 6.1. On the Necessity of Realistic Online Evaluation Some JIT-SDP studies use conventional crossvalidation (Qiao and Wang, 2019), which does not preserve the chronological order of commits. Accordingly, such time-agnostic splitting can allow later commits to appear in the training data when earlier commits are used for testing, potentially leading to optimistic performance estimates, as shown in Table 13. Other studies adopt time-aware evaluation (McIntosh and Kamei, 2018; Pornprasit and Tantithamthavorn, 2021; Pornprasit et al., 2021), where earlier commits are used for training and later commits for testing. Although this preserves temporal order, the model is typically fixed

5.4. RQ4: Inference Channels and Fusion PPR provides the strongest single-channel MacroF1 of .643, as shown in Table 12. Combining additional channels brings modest gains, with the best fusion reaching 0.653. We fixed Fov = RN+PPR before computing these aggregate results with the rationale of combining RN’s local neighborhood evidence with PPR’s global propagation (Section 3.3.5), hence avoiding any advantage from project-specific fusion tuning. The performance cost is small, as Fov achieves 0.641 Macro-F1, only 0.012 below the best, while remaining competitive in G-Mean and AUC. Additionally, RN and PPR are 17

Table 11: Online performance across all 11 projects under fusion Fov . Columns follow the KG-Commit hierarchy: Core (Layer 1, Section 3.3.2), four within-file graph representations (Layer 2, Section 3.3.3), and CSTG (Layer 3, Section 3.3.4). Bold values mark the best representation for each project and metric. Project

Layer 1

Layer 2: within-file subgraph +AST

Core

+CFG

Layer 3

+DFG

+PDG

+CSTG

AUC

ActiveMQ .572 Camel .579 Cassandra .552 Flink .647 Groovy .596 HBase .503 Hive .520 Kafka .619 Spark .439 Zeppelin .478 Zookeeper .543

.636 .668 .559 .637 .649 .465 .412 .618 .392 .422 .551

.697 .725 .660 .742 .721 .678 .640 .686 .630 .590 .637

.565 .595 .583 .607 .566 .593 .554 .602 .380 .450 .511

.649 .684 .591 .654 .661 .579 .456 .585 .309 .382 .499

.721 .743 .685 .753 .748 .732 .691 .712 .517 .634 .521

.558 .603 .581 .614 .593 .640 .565 .688 .490 .461 .511

.643 .689 .590 .651 .679 .638 .474 .686 .454 .412 .492

.717 .754 .681 .741 .747 .733 .689 .746 .614 .615 .584

.551 .610 .584 .606 .598 .627 .558 .661 .420 .410 .506

.637 .687 .592 .646 .678 .622 .461 .655 .357 .344 .486

.718 .764 .691 .733 .738 .735 .679 .734 .583 .608 .626

.551 .599 .580 .616 .594 .626 .581 .685 .465 .443 .503

.637 .692 .588 .653 .681 .621 .498 .684 .420 .387 .481

.718 .754 .680 .741 .747 .732 .689 .745 .602 .611 .583

.642 .637 .644 .685 .656 .679 .638 .723 .574 .525 .651

.706 .730 .658 .731 .729 .680 .573 .724 .566 .491 .661

.778 .792 .749 .818 .801 .793 .769 .809 .666 .654 .683

throughout an entire train/test block. Such an evaluation requires a sufficiently large historical training block, making it unsuitable for projects in the early-to-mid development cycle. It also does not reproduce the percommit processing and maintenance cycle of a deployed system or account for label-verification latency through the gap parameter (Tan et al., 2015; Gomes Cabral et al., 2019; Song and Minku, 2023; Cabral and Minku, 2023). Consequently, challenges such as delayed feedback and concept drift remain largely unexamined (McIntosh and Kamei, 2018; Cabral and Minku, 2023). Blockbased evaluation also cannot reveal potential catastrophic forgetting that may arise under sequential updating (Cabral and Minku, 2023; Kirkpatrick et al., 2017). In our comparison, block-based time-aware evaluation underestimates performance (Table 13) since holding the model fixed over many commits prevents continual refitting and adaptation as the project evolves. To capture this adaptation while avoiding temporal leakage, we use the online protocol described in Section 4.4, which reflects the deployment constraints in Section 3.2.2. Its small warm-up ratio of .05 also enables evaluation from the early stages of a project.

Table 12: All 31 fixed fusion combinations across the 11 projects. Each cell reports the project-level mean ± the half-width of its Student-t 95% confidence interval. The fixed overall fusion Fov = RN+PPR is highlighted in gray. Combination

Macro-F1

G-Mean

AUC

LP RN DW KGE PPR RN+LP LP+KGE RN+KGE LP+DW RN+DW PPR+LP DW+KGE PPR+KGE RN+PPR PPR+DW RN+LP+KGE RN+LP+DW LP+DW+KGE RN+DW+KGE PPR+LP+KGE RN+PPR+LP RN+PPR+KGE PPR+LP+DW PPR+DW+KGE RN+PPR+DW RN+LP+DW+KGE RN+PPR+LP+KGE PPR+LP+DW+KGE RN+PPR+LP+DW RN+PPR+DW+KGE RN+PPR+LP+DW+KGE

.446 ± .064 .410 ± .040 .600 ± .039 .609 ± .031 .643 ± .033 .553 ± .067 .578 ± .059 .572 ± .063 .605 ± .045 .599 ± .044 .632 ± .034 .623 ± .043 .648 ± .025 .641 ± .036 .649 ± .038 .575 ± .063 .609 ± .048 .619 ± .046 .615 ± .045 .635 ± .035 .640 ± .041 .640 ± .035 .644 ± .039 .651 ± .037 .652 ± .039 .617 ± .048 .640 ± .041 .646 ± .039 .650 ± .042 .653 ± .038 .652 ± .042

.433 ± .103 .383 ± .071 .619 ± .049 .623 ± .050 .652 ± .050 .562 ± .088 .587 ± .085 .579 ± .090 .627 ± .061 .621 ± .058 .651 ± .052 .635 ± .057 .661 ± .042 .659 ± .055 .663 ± .050 .582 ± .089 .629 ± .064 .634 ± .063 .631 ± .061 .651 ± .054 .656 ± .057 .656 ± .054 .664 ± .054 .663 ± .051 .670 ± .052 .631 ± .066 .652 ± .058 .662 ± .056 .667 ± .056 .670 ± .052 .667 ± .056

.632 ± .047 .593 ± .039 .691 ± .031 .688 ± .038 .758 ± .025 .695 ± .063 .698 ± .068 .685 ± .072 .712 ± .051 .706 ± .042 .744 ± .046 .707 ± .044 .744 ± .029 .756 ± .040 .739 ± .037 .708 ± .064 .718 ± .050 .722 ± .055 .723 ± .048 .745 ± .045 .754 ± .044 .754 ± .039 .748 ± .044 .744 ± .039 .754 ± .041 .729 ± .053 .754 ± .044 .750 ± .045 .756 ± .044 .756 ± .042 .758 ± .044

Table 13: Mean baseline performance across 11 projects under online, block-based time-aware, and random evaluation. Macro-F1 Model

G-Mean

AUC

On.

Off.

Rand.

On.

Off.

Rand.

On.

Off.

Rand.

LR .579 HGB .636 LApredict .637

.542 .583 .596

.655 .720 .667

.568 .655 .641

.579 .623 .643

.661 .707 .679

.716 .768 .750

.706 .747 .775

.754 .810 .769

6.2. Per-Commit Cost Relative to Commit Arrival Time The practical suitability of KG-Commit depends on whether its per-commit processing cost is compatible 18

DFG PDG

CSTG

0 0

10k

15k

104

AST delta / commit

Cumulative edges (M)

AST CFG

Median

102

Flink 0

Commit index

10k

15k

Groovy

Commit index

Camel

Active nodes Retired/delta edges

p95

104

HBase

103

0.3

0.4

0.5

0.6

0.7

0.8

ActiveMQ

0 0

10k

15k

20k

10k

15k

Hive

20k

Commit index

Zookeeper

(d) Active and retired graph structure. Kafka

600

Zeppelin

Spark

400

Core Core+AST Core+AST+CSTG (F)

200

F+G Switch to F+G at 200 F+G+T

0 0

10k

15k

20k

Figure 12: Macro-F1 score by KG-Commit representation layer across all 11 projects, together with the corresponding additional configurations in Section 3.3.6.

Commit index

(e) Estimated graph-store footprint. AST delta / commit

Cassandra

20k

(b) Rolling median, p95, and trend of the per-commit AST delta.

Count (M)

Ingest time (ms)

Trend

103

20k

(a) Cumulative edges by representation. Median

p95

Camel

103

102

100

Progress through project history (%)

(f) Rolling-median AST delta across all 11 projects. Camel is highlighted.

Figure 10: Lifecycle and scaling of KG-Commit. Figure 10a–10e report Camel, the largest project history. Figure 10f compares normalized per-commit AST deltas across all 11 projects.

0.8 0.7

0.646

0.676

0.681

0.704

Fov

Fov+G

S@200

F+G+T

0.6

0.8 0.7

Macro-F1 (online, w = 150)

0.641

0.5

0.6 0.5 0.4 0.3 0.2

Core Core+AST Core+AST+CSTG (F)

0.1 0.0

S = 200 2000

4000

Commit index

6000

Figure 13: Project-level Macro-F1 for Fov , G, Fov +G, S@200 policy, and Fov +G + T . Boxes show the interquartile range, horizontal lines the medians, diamonds the means, and points the projects; faint lines connect results from the same project.

F+G Switch@200 F+G+T 8000

Figure 11: Online Macro-F1 by representation layer on HBase. The curves compare Core, Core+AST, Core+AST+CSTG, along with the fusions Fov , Fov +G, S@200 policy, and Fov +G + T . The dotted line marks the switch point S =200.

with the rate at which commits arrive in practice. KGCommit requires approximately 1.33 s to process an incoming commit (Section 5.2), with most of this cost arising from the incremental graph update. Table 14 reports the observed intervals between consecutive commits across the projects. Even among closely spaced commits, the shortest lower-tail interval is 8.0 s on Cassandra, while the corresponding intervals for the remaining projects range from 25 s to more than 27 min. Median commit spacing is considerably larger, ranging from 1.20 h on Camel to 45.55 h on Zookeeper. These observations indicate that KG-Commit’s per-commit processing cost is compatible with the commit arrival rates observed in the evaluated projects.

Fov

Fov +G

S@200

0.8 0.7 0.6 0.5 0.4 150

400

600

800

1000

1200

(a) Spark S@200

0.8 0.7 0.6 0.5 0.4

Table 14: Commit arrival time across all 11 projects. Mean, standard deviation (SD), median, and P95 are reported in hours, while P05 is reported in seconds to expose short intervals between consecutive commits.

150

200

300

400

500

600

700

Commit index

(b) Zookeeper Project

Mean ± SD (h)

Median (h)

P05 (s)

P95 (h)

ActiveMQ Camel Cassandra Flink Groovy HBase Hive Kafka Spark Zeppelin Zookeeper

20.03 ± 44.95 4.93 ± 9.95 11.57 ± 24.93 6.77 ± 17.86 17.72 ± 37.57 12.77 ± 20.93 14.45 ± 30.73 30.18 ± 189.05 54.22 ± 377.47 38.37 ± 77.34 126.30 ± 218.03

4.23 1.20 2.88 1.32 4.59 5.34 5.21 8.67 19.19 16.08 45.55

117.2 114.0 8.0 25.0 105.0 301.2 306.0 574.7 1664.6 360.6 429.7

90.15 20.79 53.38 26.45 77.56 50.60 61.66 88.45 162.21 147.91 501.36

Figure 14: Effect of S@200 on Spark and Zookeeper. Curves report 150 rolling Macro-F1 with a stride of 25 commits; the displayed sequences therefore begin at the first complete window, at commit index 150.

6.4. Sensitivity of the Online Protocol to Operational Constraints and Hyperparameters We study KG-Commit’s sensitivity to the operational constraints of the online protocol and to the choice of refit interval M and switching point S (Section 4.4). The warm-up ratio K and verification gap g determine how much historical information is available and when labels become observable (Section 3.2.2). These sensitivity experiments use Fov +G under the S@200 policy. This isolates the effects of the online protocol and its hyperparameters from the additional traversal/global-context features in T . The selected values are subsequently used unchanged in the final Fov +G+T configuration. We test K ∈ {0.05, 0.10, 0.20, 0.30, 0.40, 0.50} and g ∈ {0, 10, 25, 50, 100, 200}. Macro-F1 remains stable across K for most projects, with the largest variation occurring in the smaller Spark, Zeppelin, and Zookeeper histories. It is even less sensitive to g, whose curves are nearly flat except for a modest change on Zookeeper. We also test M ∈ {25, 50, 100, 200} and S ∈ {0, 100, 200, 250, 300, 400, 500, 600, 750, 1K, 1.5K, 2K, 3K, ∞}, where project history permits. Most projects remain stable across M, while the larger changes at M=200 again occur in smaller projects. Performance also changes little for S between 200 and 500. Moving from S =0 to S =200, however, improves Macro-F1 by 0.012 on Spark and 0.044 on Zookeeper, consistent

6.3. S@200 Switching and Cold-Start Improvement Unlike the inference channel F, the CSTG channel G is not equally useful from the start. It learns from the vocabulary accumulated in commit messages and diffs (Section 3.3.4), so after a short warm-up, its term and co-occurrence statistics may still be too sparse for stable predictions. On the other hand, F operates on graph topology (Section 3.3.5) and does not depend on a fitted vocabulary. The two channels also capture fundamentally different patterns, which may explain why their combination performs better in Figure 13. We therefore use Fov for the first 200 commits (after warm-up) and add G when more project-specific language has accumulated. On both Spark (Figure 14a) and Zookeeper (Figure 14b), S@200 avoids the weaker early performance of F+G and stays ahead through much of the later stream, even after G is introduced, so the early choice of channel appears to shape later adaptation. Noisy G channel scores from cold start can carry over into subsequent updates, whereas starting with Fov gives later predictions a cleaner history. 20

labels available at that point (Section 4.4). The updated value is used from the next commit onward. As shown in Figure 16, the resulting operating point varies across projects. Cassandra and HBase remain close to 0.5, whereas Camel, Flink, and Groovy move toward higher thresholds. Hive, Kafka, Spark, Zeppelin, and Zookeeper instead settle below 0.5. Final thresholds range from 0.251 on Hive to 0.748 on Flink. A fixed cutoff would therefore impose different precision-recall trade-offs across projects. Periodic threshold tuning allows KG-Commit to adapt its decisions as the project’s score and class distributions evolve, without refitting the underlying scoring model.

with the effect discussed in Section 6.3. The values used in our main experiments (Section 5) were fixed before obtaining the sensitivity results in Figure 15. They were chosen for practical deployment instead of aiming to maximize performance on each project. Using K=0.05 allows KG-Commit to begin predicting after only 5% of the project history, although it trails the best tested K by 0.064 on Spark and 0.117 on Zookeeper. On most other projects, the choice of K has little effect. We similarly choose the largest refit interval, M=200, to reduce how often refitting occurs. This setting lowers Macro-F1 on some smaller projects, most clearly on Zeppelin, Zookeeper, and Spark, where performance decreases by 0.168, 0.089, and 0.057 relative to M=25. Lowering M would trigger refitting more frequently and increase its amortized Crefit /M cost. The selected setting therefore trades some performance on smaller projects for less frequent refitting, making our reported results for S@200 conservative. ActiveMQ Groovy Spark

Camel HBase Zeppelin

(a) Warm-up ratio K

Cassandra Hive Zookeeper

0.20

Decision threshold 0.50

0.70

0.90 Final 0.75 0.67 0.57 0.71 0.76 0.55 0.42 0.45 0.49 0.72 0.55

ActiveMQ Camel Cassandra Flink Groovy HBase Hive Kafka Spark Zeppelin Zookeeper

Flink Kafka Selected

(b) Verification gap g

0.8 0.7

100

Progress through evaluated stream (%)

0.6 0.5

Macro-F1

0.35

.05

.10

.20

.30

.40

.50

100

Figure 16: Online decision thresholds across the evaluated commit streams. Color indicates the threshold in force, black marks the first retuning after 300 evaluated commits, and the final threshold is reported on the right.

200

(d) Switch point S

0.8 0.7

6.6. Limitations and Future Work KG-Commit currently runs entirely on CPU. This keeps deployment inexpensive but restricts the complexity of graph inference. The evaluated inference channels use mostly generic graph projections and are not customized to consider specific node types, relations, or more informative regions for the purpose of JIT-SDP. The T channel exposes selected dependency, package, and graph-global context, but other aspects of the graph may remain unexploited, particularly finegrained AST structure and richer typed or higher-order relational patterns. Therefore, although KG-Commit outperforms all evaluated baselines in predictive performance, the reported results should be viewed as a conservative estimate of what its representation can support under the current inference design, rather than as an upper bound on KG-Commit’s inherent capability.

0.6 0.5 25

100

200

500

∞

Figure 15: Macro-F1 sensitivity of the Fov +G configuration to the warm-up ratio K, verification gap g, refit interval M, and switch point S . Dotted lines mark the selected settings K=0.05, g=50, M=200, and S =200.

6.5. Online Threshold Adaptation KG-Commit uses the default threshold of 0.5 for the first 300 evaluated commits and then re-estimates it every 150 commits by maximizing Macro-F1 over the 21

Furthermore, the current implementation is limited to Java because AST construction and delta extraction rely on javalang. Extending KG-Commit to other programming languages would require corresponding parsers and language-specific handling of source-code structure. In addition, each evaluated project is represented as a single repository. The current graph construction therefore does not model cross-repository dependencies or projects whose development history is distributed across multiple repositories. Future work can examine other inference methods such as R-GCN, CompGCN, and HGT, together with projections designed around the entities and relations most relevant to a target commit for defect prediction. GPU-based inference can also make broader graph context practical, provided that the resulting end-to-end per-commit processing cost remains compatible with the commit rates expected in online JIT-SDP. Taken together, these directions suggest that the current results capture only an initial use of KG-Commit’s representational capacity. Considerable room remains to exploit KG-Commit through richer inference and better graph projections. Beyond this, KG-Commit itself can be extended with additional information (e.g., caller/callee relations) to capture forms of project context not represented in the current design.

7.3. Construct Validity ApacheJIT uses an SZZ-based procedure to identify bug-inducing commits, and these labels may contain incorrect or missing links (Section 4.2). KG-Commit also relies on heuristic choices in both the AST (Section 3.3.3) and CSTG layers (Section 3.3.4). The AST layer uses heuristic matching to align nodes across edits, while CSTG uses rule-based term extraction, intent assignment, and term grounding. Moreover, efficiency and scalability are measured using execution time under the reported hardware and software environment, so absolute timings may differ on other systems.

8. Conclusion This paper addressed a practical limitation of online JIT-SDP by making broader project context available at a computational cost compatible with real commit streams. KG-Commit maintains this context incrementally in an evolving knowledge graph. Its three layers capture repository history, within-file code structure, and commit semantics, while AST deltas maintain fine-grained changes through file evolution. The final Fov +G+T predictor additionally incorporates traversal/global context from the full graph. Across 11 Apache projects, this configuration achieves the highest aggregate Macro-F1 (0.704), G-Mean (0.706), and AUC (0.809). Under a realistic online protocol, KGCommit outperforms LR, HGB, RF, and DeepJIT on all 11 projects, LApredict on 10, and JITLine-online on 9 projects in Macro-F1, with the aggregate paired difference statistically significant in every case. KG-Commit processes each commit in approximately 1.33 s on CPU, with graph ingestion accounting for most of this cost. Lifecycle analysis shows that this per-commit processing remains stable as project history and graph size grow. Moreover, KG-Commit’s processing time remains well below the observed time between consecutive commits. These results indicate that the computational cost of maintaining rich project context can be practical under the commit rates observed in real-world software projects. The current results are obtained using lightweight, CPU-only inference channels. Hence, they should be viewed as a conservative estimate of KG-Commit’s potential. This leaves considerable room for richer inference methods to better exploit KG-Commit’s representational capacity and make fuller use of the global structural and relational information maintained throughout project evolution.

7. Threats to Validity We discuss potential threats that may affect the credibility and generalizability of our results, grouped into internal, external, and construct validity. 7.1. Internal Validity Temporal leakage is the main internal concern. The online protocol admits the current commit’s unlabeled information but restricts labels and learned components to information available at prediction time (Section 4.4). Baselines were adapted to the same protocol which may introduce implementation differences. We mitigate these risks through a common stream, fixed settings, and the reported sensitivity analyses. 7.2. External Validity The evaluation uses projects from the Apache opensource ecosystem, so the observed performance may not transfer to projects with different development processes or defect distributions. Evaluating KG-Commit on industrial and other open-source repositories is needed to establish broader generalizability. 22

References

9. Declarations 9.1. Funding

Abu Talib, M., Bou Nassif, A., Azzeh, M., Alesh, Y., Afadar, Y., 2024. Parameter-efficient fine-tuning of pre-trained code models for justin-time defect prediction. Neural Computing and Applications 36, 16911–16940. doi:10.1007/s00521-024-09930-5. Allamanis, M., Brockschmidt, M., Khademi, M., 2018. Learning to represent programs with graphs, in: International Conference on Learning Representations (ICLR). Alon, U., Brody, S., Levy, O., Yahav, E., 2019a. code2seq: Generating sequences from structured representations of code, in: International Conference on Learning Representations (ICLR). Alon, U., Zilberstein, M., Levy, O., Yahav, E., 2019b. code2vec: Learning distributed representations of code. Proceedings of the ACM on Programming Languages 3, 1–29. doi:10.1145/329035 3. Angles, R., Arenas, M., Barceló, P., Hogan, A., Reutter, J., Vrgoč, D., 2017. Foundations of modern query languages for graph databases. ACM Computing Surveys 50, 1–40. doi:10.1145/3104031. Batagelj, V., Zaversnik, M., 2003. An o(m) algorithm for cores decomposition of networks. URL: https://arxiv.org/abs/cs /0310049, arXiv:cs/0310049. Belkin, M., Niyogi, P., Sindhwani, V., 2006. Manifold regularization: A geometric framework for learning from labeled and unlabeled examples. Journal of Machine Learning Research 7, 2399–2434. Bollacker, K., Evans, C., Paritosh, P., Sturge, T., Taylor, J., 2008. Freebase: A collaboratively created graph database for structuring human knowledge, in: Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data (SIGMOD), pp. 1247–1250. doi:10.1145/1376616.1376746. Bordes, A., Usunier, N., Garcia-Durán, A., Weston, J., Yakhnenko, O., 2013. Translating embeddings for modeling multi-relational data, in: Advances in Neural Information Processing Systems (NeurIPS), pp. 2787–2795. Bouma, G., 2009. Normalized (pointwise) mutual information in collocation extraction, in: Proceedings of the Biennial GSCL Conference 2009, pp. 31–40. Brin, S., Page, L., 1998. The anatomy of a large-scale hypertextual web search engine. Computer networks and ISDN systems 30, 107–117. Bryan, J., Moriano, P., 2023. Graph-based machine learning improves just-in-time defect prediction. PLOS ONE 18, e0284077. doi:10 .1371/journal.pone.0284077. Bui, N.D.Q., Yu, Y., Jiang, L., 2021. Infercode: Self-supervised learning of code representations by predicting subtrees, in: Proceedings of the 43rd International Conference on Software Engineering (ICSE), pp. 1186–1197. doi:10.1109/ICSE43902.2021.00109. Cabral, G.G., Minku, L.L., 2023. Towards reliable online just-intime software defect prediction. IEEE Transactions on Software Engineering 49, 1342–1358. doi:10.1109/TSE.2022.3175789. Cai, L., Mao, X., Zhou, Y., Long, Z., Wu, C., Lan, M., 2024. A survey on temporal knowledge graph: Representation learning and applications. URL: https://arxiv.org/abs/2403.04782, arXiv:2403.04782. Chen, X., Xia, H., Pei, W., Ni, C., Liu, K., 2023. Boosting multiobjective just-in-time software defect prediction by fusing expert metrics and semantic metrics. Journal of Systems and Software 206, 111853. doi:10.1016/j.jss.2023.111853. Chilowicz, M., Duris, E., Roussel, G., 2009. Syntax tree fingerprinting for source code similarity detection, in: 2009 IEEE 17th international conference on program comprehension, IEEE. pp. 243– 247. doi:10.1109/ICPC.2009.5090050. Cho, Y., Kwon, J.H., Yi, J., Ko, I.Y., 2022. Extending developer experience metrics for better effort-aware just-in-time defect prediction.

This research received no external funding. 9.2. Ethical approval Ethical approval: Not applicable. 9.3. Informed consent Informed consent: Not applicable. 9.4. Data Availability Statement The datasets generated and/or analyzed during the current study are available at: • Data repository: – Graph Dumps: https://zenodo.org/rec ords/22348686 – ApacheJIT Dataset: https://zenodo.org /records/5907002 • Code repository: https://github.com/Knowledge4Software/ kg-commit 9.5. Conflict of Interest The authors declare that they have no conflict of interest. 9.6. Clinical trial number Clinical trial number: Not applicable.

10. Declaration of generative AI and AI-assisted technologies in the manuscript preparation process During the preparation of this work, the authors used ChatGPT (OpenAI), using GPT-5.6 Sol, to improve the language, clarity, organization, and visual presentation of the manuscript, including the presentation of figures and other manuscript elements. After using this tool, the authors reviewed and edited the content as needed and take full responsibility for the content of the published article. 23

IEEE Access 10, 128218–128231. doi:10.1109/ACCESS.2022. 3227339. Church, K., Hanks, P., 1990. Word association norms, mutual information, and lexicography. Computational linguistics 16, 22–29. D’Ambros, M., Lanza, M., Robbes, R., 2012. Evaluating defect prediction approaches: a benchmark and an extensive comparison. Empirical Software Engineering 17, 531–577. doi:10.1007/s1 0664-011-9173-9. Dettmers, T., Minervini, P., Stenetorp, P., Riedel, S., 2018. Convolutional 2d knowledge graph embeddings, in: Proceedings of the 32nd AAAI Conference on Artificial Intelligence (AAAI), pp. 1811–1818. doi:10.1609/aaai.v32i1.11573. Falleri, J.R., Morandat, F., Blanc, X., Martinez, M., Monperrus, M., 2014. Fine-grained and accurate source code differencing, in: Proceedings of the 29th ACM/IEEE international conference on Automated software engineering, pp. 313–324. doi:10.1145/2642 937.2642982. Feng, Z., Guo, D., Tang, D., Duan, N., Feng, X., Gong, M., Shou, L., Qin, B., Liu, T., Jiang, D., Zhou, M., 2020. Codebert: A pretrained model for programming and natural languages, in: Findings of the Association for Computational Linguistics: EMNLP 2020, pp. 1536–1547. doi:10.18653/v1/2020.findings-emn lp.139. Francis, N., Green, A., Guagliardo, P., Libkin, L., Lindaaker, T., Marsault, V., Plantikow, S., Rydberg, M., Selmer, P., Taylor, A., 2018. Cypher: An evolving query language for property graphs, in: Proceedings of the 2018 International Conference on Management of Data (SIGMOD), pp. 1433–1445. doi:10.1145/318371 3.3190657. Fukushima, T., Kamei, Y., McIntosh, S., Yamashita, K., Ubayashi, N., 2014. An empirical study of just-in-time defect prediction using cross-project models, in: Proceedings of the 11th Working Conference on Mining Software Repositories (MSR), pp. 172–181. doi:10.1145/2597073.2597075. Goel, R., Kazemi, S.M., Brubaker, M., Poupart, P., 2020. Diachronic embedding for temporal knowledge graph completion, in: Proceedings of the 34th AAAI Conference on Artificial Intelligence (AAAI), pp. 3988–3995. doi:10.1609/aaai.v34i04.5815. Gomes Cabral, G., Minku, L., Shihab, E., Mujahid, S., 2019. Class imbalance evolution and verification latency in just-in-time software defect prediction, in: Proceedings of the 41st International Conference on Software Engineering, IEEE. pp. 666–676. doi:10 .1109/ICSE.2019.00076. Guo, D., Ren, S., Lu, S., Feng, Z., Tang, D., Liu, S., Zhou, L., Duan, N., Svyatkovskiy, A., Fu, S., Tufano, M., Deng, S.K., Clement, C., Drain, D., Sundaresan, N., Yin, J., Jiang, D., Zhou, M., 2021. Graphcodebert: Pre-training code representations with data flow, in: International Conference on Learning Representations (ICLR). Guo, Q., Zhuang, F., Qin, C., Zhu, H., Xie, X., Xiong, H., He, Q., 2022. A survey on knowledge graph-based recommender systems. IEEE Transactions on Knowledge and Data Engineering 34, 3549– 3568. doi:10.1109/TKDE.2020.3028705. Hall, T., Beecham, S., Bowes, D., Gray, D., Counsell, S., 2012. A systematic literature review on fault prediction performance in software engineering. IEEE Transactions on Software Engineering 38, 1276–1304. doi:10.1109/TSE.2011.103. Hassan, A.E., 2009. Predicting faults using the complexity of code changes, in: 2009 IEEE 31st international conference on software engineering, IEEE. pp. 78–88. doi:10.1109/ICSE.2009.5070 510. Haveliwala, T.H., 2002. Topic-sensitive pagerank, in: Proceedings of the 11th International Conference on World Wide Web, ACM. pp. 517–526. doi:10.1145/511446.511513. Hellendoorn, V.J., Sutton, C., Singh, R., Maniatis, P., Bieber, D., 2020. Global relational models of source code, in: International

Conference on Learning Representations (ICLR). Hesamolhokama, M., Rohani, B., Shafiee, A., Fazli, M., Habibi, J., 2025. From illusion to insight: Change-aware file-level software defect prediction using agentic ai. URL: https://arxiv.org/ abs/2512.23875, arXiv:2512.23875. Hindle, A., Barr, E.T., Su, Z., Gabel, M., Devanbu, P., 2012. On the naturalness of software, in: Proceedings of the 34th International Conference on Software Engineering (ICSE), pp. 837–847. Hoang, T., Dam, H.K., Kamei, Y., Lo, D., Ubayashi, N., 2019. Deepjit: An end-to-end deep learning framework for just-in-time defect prediction, in: Proceedings of the 16th International Conference on Mining Software Repositories (MSR), pp. 34–45. doi:10.110 9/MSR.2019.00016. Hoang, T., Kang, H.J., Lo, D., Lawall, J., 2020. Cc2vec: Distributed representations of code changes, in: Proceedings of the 42nd International Conference on Software Engineering (ICSE), pp. 518– 529. doi:10.1145/3377811.3380361. Hogan, A., Blomqvist, E., Cochez, M., d’Amato, C., de Melo, G., Gutierrez, C., Kirrane, S., Gayo, J.E.L., Navigli, R., Neumaier, S., Ngonga Ngomo, A.C., Polleres, A., Rashid, S.M., Rula, A., Schmelzeisen, L., Sequeda, J., Staab, S., Zimmermann, A., 2021. Knowledge graphs. ACM Computing Surveys 54, 1–37. doi:10.1 145/3447772. Ji, S., Pan, S., Cambria, E., Marttinen, P., Yu, P.S., 2022. A survey on knowledge graphs: Representation, acquisition, and applications. IEEE Transactions on Neural Networks and Learning Systems 33, 494–514. doi:10.1109/TNNLS.2021.3070843. Jiang, Y., Shen, B., Gu, X., 2025. Just-in-time software defect prediction via bi-modal change representation learning. Journal of Systems and Software 219, 112253. doi:10.1016/j.jss.2024 .112253. Jin, W., Qu, M., Jin, X., Ren, X., 2020. Recurrent event network: Autoregressive structure inference over temporal knowledge graphs, in: Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), pp. 6669– 6683. doi:10.18653/v1/2020.emnlp-main.541. Kamei, Y., Fukushima, T., McIntosh, S., Yamashita, K., Ubayashi, N., Hassan, A.E., 2016. Studying just-in-time defect prediction using cross-project models. Empirical Software Engineering 21, 2072–2106. doi:10.1007/s10664-015-9400-x. Kamei, Y., Shihab, E., Adams, B., Hassan, A.E., Mockus, A., Sinha, A., Ubayashi, N., 2013. A large-scale empirical study of just-intime quality assurance. IEEE Transactions on Software Engineering 39, 757–773. doi:10.1109/TSE.2012.70. Kanade, A., Maniatis, P., Balakrishnan, G., Shi, K., 2020. Learning and evaluating contextual embedding of source code, in: Proceedings of the 37th International Conference on Machine Learning (ICML), pp. 5110–5121. Keshavarz, H., Nagappan, M., 2022. Apachejit: a large dataset for just-in-time defect prediction, in: Proceedings of the 19th international conference on mining software repositories, pp. 191–195. doi:10.1145/3524842.3527996. Kim, S., Whitehead, E.J., Zhang, Y., 2008. Classifying software changes: Clean or buggy? IEEE Transactions on Software Engineering 34, 181–196. doi:10.1109/TSE.2007.70773. Kirkpatrick, J., Pascanu, R., Rabinowitz, N., Veness, J., Desjardins, G., Rusu, A.A., Milan, K., Quan, J., Ramalho, T., GrabskaBarwinska, A., Hassabis, D., Clopath, C., Kumaran, D., Hadsell, R., 2017. Overcoming catastrophic forgetting in neural networks. Proceedings of the National Academy of Sciences 114, 3521–3526. doi:10.1073/pnas.1611835114. Kondo, M., German, D.M., Mizuno, O., Choi, E., 2020. The impact of context metrics on just-in-time defect prediction. Empirical Software Engineering 25, 890–939. doi:10.1007/s10664-019-097 36-3.

Lacroix, T., Obozinski, G., Usunier, N., 2020. Tensor decompositions for temporal knowledge base completion, in: International Conference on Learning Representations (ICLR). Lee, G., Ju, H., Lee, S.U.J., 2024. Neurojit: Improving justin-time defect prediction using neurophysiological and empirical perceptions of modern developers, in: Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, pp. 594–605. doi:10.1145/3691620.3695056. Lessmann, S., Baesens, B., Mues, C., Pietsch, S., 2008. Benchmarking classification models for software defect prediction: A proposed framework and novel findings. IEEE Transactions on Software Engineering 34, 485–496. doi:10.1109/TSE.2008.35. Li, J., He, P., Zhu, J., Lyu, M.R., 2017. Software defect prediction via convolutional neural network, in: Proceedings of the IEEE International Conference on Software Quality, Reliability and Security (QRS), pp. 318–328. doi:10.1109/QRS.2017.42. Li, Y., Tarlow, D., Brockschmidt, M., Zemel, R., 2016. Gated graph sequence neural networks, in: International Conference on Learning Representations (ICLR). Lin, Y., Liu, Z., Sun, M., Liu, Y., Zhu, X., 2015. Learning entity and relation embeddings for knowledge graph completion, in: Proceedings of the 29th AAAI Conference on Artificial Intelligence (AAAI), pp. 2181–2187. doi:10.1609/aaai.v29i1.9491. Liu, J., Ai, J., Lu, M., Wang, J., Shi, H., 2023a. Semantic feature learning for software defect prediction from source code and external knowledge. Journal of Systems and Software 204, 111753. doi:10.1016/j.jss.2023.111753. Liu, M., Yang, Y., Lou, Y., Peng, X., Zhou, Z., Du, X., Yang, T., 2023b. Recommending analogical apis via knowledge graph embedding, in: Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), pp. 1496–1508. doi:10.1145/3611643.3616305. MacLean, F., 2021. Knowledge graphs and their applications in drug discovery. Expert Opinion on Drug Discovery 16, 1057–1069. doi:10.1080/17460441.2021.1910673. Macskassy, S.A., Provost, F., 2003. A simple relational classifier, in: Proceedings of the Second International Workshop on MultiRelational Data Mining, pp. 64–76. McIntosh, S., Kamei, Y., 2018. Are fix-inducing changes a moving target? a longitudinal case study of just-in-time defect prediction. IEEE Transactions on Software Engineering 44, 412–428. doi:10 .1109/TSE.2017.2693980. Menzies, T., Greenwald, J., Frank, A., 2007. Data mining static code attributes to learn defect predictors. IEEE Transactions on Software Engineering 33, 2–13. doi:10.1109/TSE.2007.256941. Menzies, T., Milton, Z., Turhan, B., Cukic, B., Jiang, Y., Bener, A., 2010. Defect prediction from static code features: Current results, limitations, new approaches. Automated Software Engineering 17, 375–407. doi:10.1007/s10515-010-0069-5. Mihalcea, R., Tarau, P., 2004. Textrank: Bringing order into text, in: Proceedings of the 2004 conference on empirical methods in natural language processing, pp. 404–411. Mikolov, T., Sutskever, I., Chen, K., Corrado, G.S., Dean, J., 2013. Distributed representations of words and phrases and their compositionality, in: Advances in Neural Information Processing Systems (NeurIPS), pp. 3111–3119. Mockus, A., Weiss, D.M., 2000. Predicting risk of software changes. Bell Labs Technical Journal 5, 169–180. doi:10.1002/bltj.222 9. Moser, R., Pedrycz, W., Succi, G., 2008. A comparative analysis of the efficiency of change metrics and static code attributes for defect prediction, in: Proceedings of the 30th international conference on Software engineering, pp. 181–190. doi:10.1145/1368088.13 68114.

Mou, L., Li, G., Zhang, L., Wang, T., Jin, Z., 2016. Convolutional neural networks over tree structures for programming language processing, in: Proceedings of the 30th AAAI Conference on Artificial Intelligence (AAAI), pp. 1287–1293. doi:10.1609/aaai.v 30i1.10139. Nagappan, N., Ball, T., 2005. Use of relative code churn measures to predict system defect density, in: Proceedings of the 27th international conference on Software engineering, pp. 284–292. doi:10.1145/1062455.1062514. Nam, J., Pan, S.J., Kim, S., 2013. Transfer defect learning, in: Proceedings of the 35th International Conference on Software Engineering (ICSE), pp. 382–391. doi:10.1109/ICSE.2013.660658 4. Ni, C., Wang, W., Yang, K., Xia, X., Liu, K., Lo, D., 2022. The best of both worlds: Integrating semantic features with expert features for defect prediction and localization, in: Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), pp. 672–683. doi:10.1145/3540250.3549165. Nickel, M., Murphy, K., Tresp, V., Gabrilovich, E., 2016. A review of relational machine learning for knowledge graphs. Proceedings of the IEEE 104, 11–33. doi:10.1109/JPROC.2015.2483592. Nickel, M., Tresp, V., Kriegel, H.P., 2011. A three-way model for collective learning on multi-relational data, in: Proceedings of the 28th International Conference on Machine Learning (ICML), pp. 809–816. Pascarella, L., Palomba, F., Bacchelli, A., 2019. Fine-grained justin-time defect prediction. Journal of Systems and Software 150, 22–36. doi:10.1016/j.jss.2018.12.001. Perozzi, B., Al-Rfou, R., Skiena, S., 2014. Deepwalk: Online learning of social representations, in: Proceedings of the 20th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, ACM. pp. 701–710. doi:10.1145/2623330.2623 732. Pornprasit, C., Tantithamthavorn, C., 2021. Jitline: A simpler, better, faster, finer-grained just-in-time defect prediction, in: Proceedings of the 18th International Conference on Mining Software Repositories (MSR), pp. 369–379. doi:10.1109/MSR52588.2021.00 049. Pornprasit, C., Tantithamthavorn, C., Jiarpakdee, J., Fu, M., Thongtanunam, P., 2021. Pyexplainer: Explaining the predictions of justin-time defect models, in: Proceedings of the 36th IEEE/ACM International Conference on Automated Software Engineering (ASE), pp. 407–418. doi:10.1109/ASE51524.2021.9678763. Pornprasit, C., Tantithamthavorn, C.K., 2023. Deeplinedp: Towards a deep learning approach for line-level defect prediction. IEEE Transactions on Software Engineering 49, 84–98. doi:10.1109/ TSE.2022.3144348. Qiao, L., Wang, Y., 2019. Effort-aware and just-in-time defect prediction with neural network. PLOS ONE 14, e0211359. doi:10.137 1/journal.pone.0211359. Rivest, R.L., 1992. The MD5 message-digest algorithm. Technical Report RFC 1321. Network Working Group, IETF. doi:10.17487 /RFC1321. Rousseau, F., Vazirgiannis, M., 2013. Graph-of-word and tw-idf: new approach to ad hoc ir, in: Proceedings of the 22nd ACM international conference on Information & Knowledge Management, pp. 59–68. doi:10.1145/2505515.2505671. Rousseau, F., Vazirgiannis, M., 2015. Main core retention on graph-of-words for single-document keyword extraction, in: European Conference on Information Retrieval, Springer. pp. 382–393. doi:10.1007/978-3-319-16354-3_42. Sahar, H., Bangash, A.A., Hindle, A., Barbosa, D., 2024. Irjit: A simple, online, information retrieval approach for just-in-time software defect prediction. Empirical Software Engineering 29, 131.

doi:10.1007/s10664-024-10514-z. Scarselli, F., Gori, M., Tsoi, A.C., Hagenbuchner, M., Monfardini, G., 2009. The graph neural network model. IEEE Transactions on Neural Networks 20, 61–80. doi:10.1109/TNN.2008.2005605. Schlichtkrull, M., Kipf, T.N., Bloem, P., van den Berg, R., Titov, I., Welling, M., 2018. Modeling relational data with graph convolutional networks, in: The Semantic Web – 15th International Conference (ESWC), Springer. pp. 593–607. doi:10.1007/978-3-3 19-93417-4_38. Šikić, L., Kurdija, A.S., Vladimir, K., Šilić, M., 2022. Graph neural network for source code defect prediction. IEEE access 10, 10402– 10415. doi:10.1109/ACCESS.2022.3144598. Śliwerski, J., Zimmermann, T., Zeller, A., 2005. When do changes induce fixes?, in: Proceedings of the 2005 International Workshop on Mining Software Repositories (MSR), pp. 1–5. doi:10.1145/ 1083142.1083147. Song, L., Minku, L.L., 2023. A procedure to continuously evaluate predictive performance of just-in-time software defect prediction models during software development. IEEE Transactions on Software Engineering 49, 646–666. doi:10.1109/TSE.2022.31588 31. Song, L., Minku, L.L., Yao, X., 2023. On the validity of retrospective predictive performance evaluation procedures in just-in-time software defect prediction. Empirical Software Engineering 28, 124. doi:10.1007/s10664-023-10341-8. Suchanek, F.M., Kasneci, G., Weikum, G., 2007. Yago: A core of semantic knowledge, in: Proceedings of the 16th International Conference on World Wide Web (WWW), pp. 697–706. doi:10.1145/1242572.1242667. Sun, Z., Deng, Z.H., Nie, J.Y., Tang, J., 2019. Rotate: Knowledge graph embedding by relational rotation in complex space, in: International Conference on Learning Representations (ICLR). Tabassum, S., Minku, L.L., Feng, D., 2023. Cross-project online justin-time software defect prediction. IEEE Transactions on Software Engineering 49, 268–287. doi:10.1109/TSE.2022.3150153. Tai, K.S., Socher, R., Manning, C.D., 2015. Improved semantic representations from tree-structured long short-term memory networks, in: Proceedings of the 53rd Annual Meeting of the Association for Computational Linguistics (ACL), pp. 1556–1566. doi:10.3115/v1/P15-1150. Tan, M., Tan, L., Dara, S., Mayeux, C., 2015. Online defect prediction for imbalanced data, in: Proceedings of the 37th IEEE/ACM International Conference on Software Engineering, pp. 99–108. doi:10.1109/ICSE.2015.139. Tantithamthavorn, C., McIntosh, S., Hassan, A.E., Matsumoto, K., 2017. An empirical comparison of model validation techniques for defect prediction models. IEEE Transactions on Software Engineering 43, 1–18. doi:10.1109/TSE.2016.2584050. Trivedi, R., Dai, H., Wang, Y., Song, L., 2017. Know-evolve: Deep temporal reasoning for dynamic knowledge graphs, in: Proceedings of the 34th International Conference on Machine Learning (ICML), pp. 3462–3471. Trouillon, T., Welbl, J., Riedel, S., Gaussier, E., Bouchard, G., 2016. Complex embeddings for simple link prediction, in: Proceedings of the 33rd International Conference on Machine Learning (ICML), pp. 2071–2080. Vashishth, S., Sanyal, S., Nitin, V., Talukdar, P., 2020. Compositionbased multi-relational graph convolutional networks, in: International Conference on Learning Representations (ICLR). Vrandečić, D., Krötzsch, M., 2014. Wikidata: A free collaborative knowledgebase. Communications of the ACM 57, 78–85. doi:10 .1145/2629489. Wang, H., Zhang, F., Wang, J., Zhao, M., Li, W., Xie, X., Guo, M., 2018. Ripplenet: Propagating user preferences on the knowledge graph for recommender systems, in: Proceedings of the 27th ACM

International Conference on Information and Knowledge Management (CIKM), pp. 417–426. doi:10.1145/3269206.3271739. Wang, L., Sun, C., Zhang, C., Nie, W., Huang, K., 2023. Application of knowledge graph in software engineering field: A systematic literature review. Information and Software Technology 164, 107327. Wang, Q., Mao, Z., Wang, B., Guo, L., 2017. Knowledge graph embedding: A survey of approaches and applications. IEEE Transactions on Knowledge and Data Engineering 29, 2724–2743. doi:10.1109/TKDE.2017.2754499. Wang, S., Liu, T., Tan, L., 2016. Automatically learning semantic features for defect prediction, in: Proceedings of the 38th International Conference on Software Engineering (ICSE), pp. 297–308. doi:10.1145/2884781.2884804. Wang, W., Li, G., Ma, B., Xia, X., Jin, Z., 2020. Detecting code clones with graph neural network and flow-augmented abstract syntax tree, in: Proceedings of the IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 261–271. doi:10.1109/SANER48275.2020.9054857. Wang, X., He, X., Cao, Y., Liu, M., Chua, T.S., 2019. Kgat: Knowledge graph attention network for recommendation, in: Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery and Data Mining (KDD), pp. 950–958. doi:10.1145/3292500.3330989. Wang, Y., Wang, W., Joty, S., Hoi, S.C.H., 2021. Codet5: Identifieraware unified pre-trained encoder-decoder models for code understanding and generation, in: Proceedings of the 2021 Conference on Empirical Methods in Natural Language Processing (EMNLP), pp. 8696–8708. doi:10.18653/v1/2021.emnlp-main.685. Wang, Z., Zhang, J., Feng, J., Chen, Z., 2014. Knowledge graph embedding by translating on hyperplanes, in: Proceedings of the 28th AAAI Conference on Artificial Intelligence (AAAI), pp. 1112– 1119. doi:10.1609/aaai.v28i1.8870. Weinberger, K.Q., Dasgupta, A., Langford, J., Smola, A.J., Attenberg, J., 2009. Feature hashing for large scale multitask learning, in: Proceedings of the 26th Annual International Conference on Machine Learning, pp. 1113–1120. doi:10.1145/1553374.1553516. Wolpert, D.H., 1992. Stacked generalization. Neural networks 5, 241–259. doi:10.1016/S0893-6080(05)80023-1. Wu, Z., Pan, S., Chen, F., Long, G., Zhang, C., Yu, P.S., 2021. A comprehensive survey on graph neural networks. IEEE Transactions on Neural Networks and Learning Systems 32, 4–24. doi:10.1109/TNNLS.2020.2978386. Yang, B., Yih, W.t., He, X., Gao, J., Deng, L., 2015a. Embedding entities and relations for learning and inference in knowledge bases, in: International Conference on Learning Representations (ICLR). Yang, X., Lo, D., Xia, X., Zhang, Y., Sun, J., 2015b. Deep learning for just-in-time defect prediction, in: Proceedings of the 2015 IEEE International Conference on Software Quality, Reliability and Security (QRS), IEEE. pp. 17–26. doi:10.1109/QRS.2015.14. Zain, Z.M., Sakri, S., Ismail, N.H.A., 2023. Application of deep learning in software defect prediction: systematic literature review and meta-analysis. Information and Software Technology 158, 107175. doi:10.1016/j.infsof.2023.107175. Zeng, Z., Zhang, Y., Zhang, H., Zhang, L., 2021. Deep just-in-time defect prediction: How far are we?, in: Proceedings of the 30th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), pp. 427–438. doi:10.1145/3460319.346481 9. Zhang, J., Wang, X., Zhang, H., Sun, H., Wang, K., Liu, X., 2019a. A novel neural source code representation based on abstract syntax tree, in: Proceedings of the 41st International Conference on Software Engineering (ICSE), pp. 783–794. doi:10.1109/ICSE.201 9.00086. Zhang, Y., Kong, X., Shen, Z., Li, J., Yi, Q., Shen, G., Dong, B.,

to a different predecessor type; unmatched nodes yield ADDS and REMOVES, and changed matched nodes yield UPDATES. If identity matching is unstable, the implementation provides a conservative typed-multiset fallback containing only additions and removals. Thus, CFG, DFG, and PDG differ in the program structure they encode, while their matching and downstream delta interface are held fixed. Figure A.17 illustrates the three representations.

2024. A survey on temporal knowledge graph embedding: Models and applications. Knowledge-Based Systems 304, 112454. doi:10 .1016/j.knosys.2024.112454. Zhang, Z., Han, X., Liu, Z., Jiang, X., Sun, M., Liu, Q., 2019b. Ernie: Enhanced language representation with informative entities, in: Proceedings of the 57th Annual Meeting of the Association for Computational Linguistics (ACL), pp. 1441–1451. doi:10.18653/v1/P19-1139. Zhao, X., Jiang, R., Han, Y., Li, A., Peng, Z., 2024. A survey on cybersecurity knowledge graph construction. Computers & Security 136, 103524. doi:10.1016/j.cose.2023.103524. Zhao, Y., Chen, H., 2023. Deep incremental learning of imbalanced data for just-in-time software defect prediction. URL: https: //arxiv.org/abs/2310.12289, arXiv:2310.12289. Zhao, Y., Damevski, K., Chen, H., 2023. A systematic survey of justin-time software defect prediction. ACM Computing Surveys 55, 1–35. doi:10.1145/3567550. Zhou, C., He, P., Zeng, C., Ma, J., 2022. Software defect prediction with semantic and structural information of codes based on graph neural networks. Information and Software Technology 152, 107057. doi:10.1016/j.infsof.2022.107057. Zhou, X., Han, D., Lo, D., 2025. Bridging expert knowledge with deep learning techniques for just-in-time defect prediction. Empirical Software Engineering 30, 1–34. doi:10.1007/s10664-024 -10591-0. Zhou, Y., Liu, S., Siow, J., Du, X., Liu, Y., 2019. Devign: Effective vulnerability identification by learning comprehensive program semantics via graph neural networks, in: Advances in Neural Information Processing Systems (NeurIPS). Zhu, X., Ghahramani, Z., Lafferty, J., 2003. Semi-supervised learning using gaussian fields and harmonic functions, in: Proceedings of the 20th International Conference on Machine Learning (ICML), pp. 912–919. Zimmermann, T., Nagappan, N., Gall, H., Giger, E., Murphy, B., 2009. Cross-project defect prediction: A large scale experiment on data vs. domain vs. process, in: Proceedings of the 7th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE), pp. 91–100. doi:10.1145/1595696. 1595713.

Appendix B. Layer-Wise Results for Individual Inference Channels To complement the fixed-Fov analysis in Section 5.3, we report the layer-wise evaluation for the five individual graph-inference channels in Table B.16. These results are kept separate from the main analysis because the contribution of a representation is not invariant to the inference mechanism. The magnitude, and occasionally the ordering, of layer-level gains can change across inference channels and projects. The main text therefore holds inference fixed at Fov when attributing performance changes to the representation.

Appendix C. Commit–Hub Projection and GraphBased Inference

Appendix A. Alternative Within-File Representations

The five graph-based inference channels operate on the commit–hub projection introduced in Section 3.3.6. At commit j, this projection is a weighted bipartite graph P( j) = C( j) ∪ H ( j) , E( j) , E( j) ⊆ C( j) ×H ( j) , (C.1)

CFG, DFG, and PDG are constructed independently for each Java method using CFGBuilder, DefUseBuilder, and CPGBuilder, respectively. The CFG represents execution order and branching; the DFG represents definition-use value flow, and the PDG combines control and data dependencies. Table A.15 summarizes their construction. Construct coverage therefore follows the nodes produced by the respective builder. Unlike the AST, these graphs do not have canonically ordered children or a unique parent, so subtree hashing cannot be applied directly. Their shared matcher instead ranks same-type nodes within a method by (line, id) and matches them by ordinal, with a deterministic sametype greedy pass for remaining nodes. A matched node is marked MOVES when its primary predecessor changes

where C( j) contains the commit nodes available at that point and H ( j) contains inference-level context hubs. Four hub types are used: Files, Developers, change tokens, and CSTG Terms. A hub is therefore an entity that can be shared by multiple commits and provides a path between commits with related context. A change token is a pair (r, τ), where r ∈ {ADDS, REMOVES, UPDATES, MOVES} is the structural edit operation and τ is the type of the affected ASTNode defined in Section 3.3.3. The AST delta of a commit is represented as a multiset of these tokens. For example, if a commit adds three MethodInvocation nodes, the corresponding (ADDS, MethodInvocation) token occurs three times. File and developer hubs are obtained from the Core layer, while CSTG term hubs are obtained from the semantic layer. 27

Table A.15: Construction and delta extraction for the alternative within-file representations.

Rep. Builder

Nodes / edges

Validation / cost

Matching and cycles

Two-pass ordinal matching within each method: exact (method, type, ordinal), followed by deterministic greedy same-type matching. Cycles require no special handling because matching does not recursively traverse graph edges. Same ordinal matcher as CFG. DFG DefUseBuilder Definition nodes use def_type; use nodes are typed Multiple predecessors do not require a unique tree parent; USE; edges encode move detection uses the definition–use value flow. primary predecessor. PDG CPGBuilder Nodes are typed by kind; edges Same ordinal matcher as CFG combine control and data and DFG; no canonical child dependencies. ordering is assumed. CFG CFGBuilder

if (x > 0) { y = x + 1; } else { y = 0; } print(y);

Nodes are typed by control-flow kind; directed edges encode execution successors and branches.

Entry

Built and matched only for affected methods using deterministic construction and matching.

Same deterministic procedure and scope as CFG.

Same deterministic procedure and scope as CFG/DFG.

x x>0

x>0 T

x+1

y← x+1

y←0

ϕy print(y) print(y) Exit

y← x+1

y←0

print(y)

control

data

(d) Program dependence graph. (c) Data-flow graph.

(a) Source fragment.

(b) Control-flow graph.

Figure A.17: The same conditional code fragment represented using alternative structural representations: (a) the source fragment, (b) the CFG, (c) the DFG, and (d) the PDG. In the PDG, solid edges denote control dependencies, whereas dashed edges denote data dependencies.

Table B.16: Layer-wise online performance of the five individual graph-inference channels across all 11 projects. Underlining marks the best representation within each inference row. Project

Inf.

Layer 1

Layer 2: within-file subgraph +AST

Core

AUC

ActiveMQ

.555 .704 .575 .682 .701

.433 .509 .569 .646 .349 .400 .547 .612 .527 .603

.593 .699 .606 .648 .639

.432 .508 .571 .647 .350 .402 .537 .606 .516 .592

.614 .696 .614 .636 .644

.435 .511 .573 .648 .341 .389 .544 .607 .528 .607

.592 .700 .606 .646 .653

.348 .401 .660 .702 .437 .514 .609 .665 .616 .670

.561 .778 .670 .711 .719

Camel

RN .588 .648 PPR .535 .654 LP .458 .607 DW .478 .570 KGE .464 .596

.706 .696 .664 .608 .624

.371 .524 .508 .648 .181 .245 .554 .635 .558 .661

.626 .687 .553 .697 .705

.435 .595 .522 .664 .360 .512 .514 .621 .485 .620

.663 .690 .613 .662 .645

.473 .632 .528 .665 .395 .553 .510 .612 .516 .642

.683 .693 .625 .646 .673

.433 .593 .519 .660 .360 .511 .530 .626 .506 .631

.662 .689 .613 .667 .658

.379 .533 .635 .715 .471 .634 .569 .669 .590 .689

.629 .772 .654 .718 .748

RN .389 .330 PPR .489 .481 Cassandra LP .331 .221 DW .589 .602 KGE .479 .471

.621 .635 .560 .662 .596

.396 .338 .563 .571 .327 .212 .611 .625 .597 .610

.570 .668 .505 .671 .672

.459 .434 .525 .525 .328 .214 .613 .626 .555 .562

.609 .657 .523 .667 .621

.429 .392 .532 .534 .328 .214 .572 .584 .530 .534

.609 .658 .515 .641 .592

.455 .428 .526 .526 .328 .214 .612 .626 .527 .530

.606 .657 .523 .670 .598

.405 .352 .610 .621 .327 .212 .629 .643 .643 .657

.577 .737 .599 .704 .697

Flink

RN .581 .649 PPR .646 .660 LP .459 .521 DW .555 .610 KGE .506 .568

.731 .755 .622 .658 .602

.389 .431 .622 .679 .349 .373 .590 .639 .629 .666

.546 .722 .550 .696 .721

.406 .453 .626 .682 .379 .417 .602 .645 .562 .605

.570 .715 .577 .688 .639

.406 .454 .620 .679 .367 .400 .581 .629 .506 .569

.562 .714 .573 .673 .603

.406 .454 .620 .680 .379 .417 .603 .645 .534 .593

.570 .715 .577 .689 .626

.391 .434 .715 .740 .363 .394 .578 .642 .645 .685

.554 .800 .625 .731 .759

Groovy

RN .519 .614 PPR .593 .668 LP .469 .566 DW .548 .600 KGE .487 .577

.709 .726 .698 .650 .634

.365 .445 .595 .676 .342 .414 .571 .641 .610 .678

.650 .717 .654 .688 .718

.426 .520 .596 .681 .382 .466 .558 .630 .570 .641

.651 .730 .673 .672 .679

.446 .542 .622 .686 .390 .476 .551 .618 .530 .608

.666 .729 .672 .655 .665

.420 .512 .597 .683 .388 .474 .554 .629 .543 .618

.648 .729 .672 .673 .647

.376 .458 .674 .707 .486 .589 .619 .673 .626 .672

.658 .781 .714 .731 .725

HBase

RN .381 .271 PPR .488 .445 LP .377 .268 DW .560 .544 KGE .475 .435

.619 .658 .554 .632 .604

.364 .230 .547 .522 .360 .225 .648 .650 .634 .633

.559 .676 .493 .685 .702

.452 .387 .574 .560 .363 .232 .623 .623 .578 .568

.592 .680 .518 .655 .652

.467 .409 .583 .572 .363 .232 .592 .587 .578 .567

.586 .675 .515 .620 .639

.449 .383 .579 .566 .363 .232 .619 .618 .554 .537

.590 .679 .517 .651 .629

.377 .257 .682 .684 .368 .243 .651 .654 .637 .637

.565 .764 .587 .694 .722

Hive

RN .475 .315 PPR .467 .314 LP .465 .291 DW .447 .267 KGE .403 .155

.655 .639 .638 .663 .585

.445 .258 .454 .295 .383 .049 .606 .551 .536 .426

.652 .637 .520 .671 .640

.487 .333 .444 .274 .398 .127 .565 .477 .494 .353

.676 .642 .593 .653 .606

.514 .378 .456 .298 .401 .138 .499 .365 .493 .356

.678 .644 .572 .656 .607

.508 .370 .446 .278 .399 .132 .545 .445 .486 .341

.674 .642 .593 .650 .576

.443 .252 .599 .520 .494 .342 .624 .567 .576 .490

.657 .754 .679 .677 .694

Kafka

RN .533 .494 PPR .428 .373 LP .569 .546 DW .621 .616 KGE .487 .446

.689 .644 .665 .719 .594

.464 .395 .535 .509 .438 .354 .682 .684 .591 .573

.677 .669 .595 .726 .602

.539 .500 .530 .505 .512 .463 .706 .709 .532 .503

.712 .671 .639 .729 .564

.570 .540 .528 .502 .522 .476 .687 .689 .547 .519

.711 .669 .640 .726 .604

.548 .513 .511 .478 .516 .469 .705 .708 .576 .556

.709 .673 .642 .730 .601

.465 .396 .681 .679 .652 .639 .698 .700 .664 .662

.689 .803 .753 .748 .675

Spark

RN .415 .379 PPR .402 .324 LP .375 .330 DW .432 .370 KGE .348 .254

.545 .612 .503 .564 .486

.338 .214 .361 .246 .356 .269 .488 .464 .462 .425

.581 .566 .509 .602 .599

.364 .273 .382 .283 .372 .319 .372 .285 .508 .491

.567 .573 .514 .539 .583

.365 .279 .374 .276 .371 .326 .372 .290 .429 .382

.534 .558 .499 .546 .531

.370 .285 .398 .312 .369 .314 .376 .283 .432 .387

.565 .571 .510 .546 .549

.337 .214 .540 .520 .374 .304 .490 .464 .496 .481

.589 .699 .577 .606 .593

Zeppelin

RN .535 .514 PPR .499 .471 LP .542 .519 DW .480 .472 KGE .531 .504

.569 .588 .525 .568 .597

.542 .519 .582 .572 .543 .520 .514 .509 .609 .603

.543 .648 .517 .610 .660

.542 .519 .565 .547 .542 .519 .578 .573 .549 .525

.541 .660 .519 .631 .615

.544 .522 .570 .553 .541 .518 .547 .540 .532 .500

.518 .640 .510 .606 .615

.542 .519 .566 .548 .541 .518 .581 .577 .566 .539

.540 .652 .517 .621 .658

.543 .520 .625 .619 .541 .519 .527 .514 .589 .586

.548 .688 .573 .627 .608

RN .424 .420 PPR .443 .448 Zookeeper LP .397 .382 DW .338 .254 KGE .385 .332

.567 .588 .561 .592 .512

.429 .373 .491 .492 .390 .367 .487 .475 .552 .544

.475 .560 .401 .640 .545

.456 .418 .430 .417 .393 .371 .377 .329 .503 .489

.524 .532 .429 .543 .537

.457 .420 .404 .381 .393 .371 .363 .314 .462 .436

.558 .511 .440 .523 .521

.455 .415 .416 .395 .393 .371 .375 .327 .518 .507

.520 .530 .429 .545 .572

.445 .399 .655 .665 .395 .375 .605 .616 .616 .626

.497 .756 .518 .653 .625

AUC F1

CSTG

.340 .389 .589 .663 .294 .318 .579 .629 .583 .651

AUC F1

+PDG

.675 .671 .650 .602 .624

AUC F1

Layer 3

+DFG

RN .483 .563 PPR .532 .604 LP .442 .519 DW .505 .573 KGE .530 .593

AUC F1

+CFG

AUC F1

therefore capture patterns beyond a single shared hub through their learned representations.

Two commits that share a hub are connected through the path ci → h → ck in P( j) . We call this one committo-commit hop, which corresponds to two edges in the bipartite projection. Two commit-to-commit hops therefore correspond to four bipartite edges. Relations that are present in the full knowledge graph but do not form commit–hub links, such as AST_CHILD, commit ancestry, COOCCURS, and file-to-file IMPORTS, are not edges of this projection. Only labels that have become available under the gap constraint are used during inference. As defined in Section 3.2.2, let Cpast denote these gap-resolved commits. For a commit c and hub h, let tf(c, h) denote the number of observed occurrences of h in c. The commit–hub incidence weight is ! |Cpast | , (C.2) Wch = tf(c, h) log 1 + df past (h)

Table C.17: Inference scope of the five graph-based channels on the commit–hub projection.

Explicit reach

2 edges (1 hop)

LP PPR

DW KGE

where df past (h) is the number of gap-resolved past commits connected to h. The first term reflects how strongly a hub occurs in the current commit, while the logarithmic term reduces the influence of hubs that occur in many previous commits. Let W denote the resulting weighted commit–hub incidence matrix. The adjacency matrix of the bipartite projection is " # 0 W AP = , (C.3) W⊤ 0 and its column-normalized transition matrix is † P = AP diag A⊤P 1 ,

Method Mechanism Weighted sharedhub vote Clamped label diffusion Class-seeded personalized PageRank PPMI matrix factorization DistMult over commit–hub triples

6 edges (3 hops) 40 edges (≤ 20 hops)

2 edges + global SVD 1 edge + global embedding

Appendix D. CSTG Semantic Channel Features The feature-based G channel uses the semantic information constructed by the CSTG layer in Section 3.3.4. Unlike the five graph-based channels, it does not produce its score from the commit–hub projection. Instead, it combines the textual-risk, term-type, intent, structural consistency, and hashed-text information of the current commit into a single feature vector and learns a commitlevel defect probability. For a commit c, let ρ(c) denote the propagated textual-risk prior defined in Section 3.3.4. The five semantic-mass features are M(c) = Mcode (c), Mbug (c), Maction (c), (D.1) Merror (c), Mnatural−language (c) .

(C.4)

where † denotes the element-wise reciprocal with zero entries kept at zero. Although RN, LP, PPR, DW, and KGE all use this same projection, they use it in different ways. RN performs a weighted vote from commits connected through shared hubs (Macskassy and Provost, 2003). LP performs three commit–hub–commit propagation rounds and re-clamps the labels in Cpast after every round (Zhu et al., 2003). PPR performs class-seeded propagation separately for buggy and clean commits over 40 bipartite edges (Haveliwala, 2002). DW and KGE use the same projection but learn a representation from it rather than repeatedly following explicit paths at prediction time. DW applies truncated SVD to a positive-PMI transformation of the past commit–hub incidence matrix (Perozzi et al., 2014). KGE represents projected edges as typed triples (c, r, h) and learns DistMult embeddings (Yang et al., 2015a). The relation r distinguishes structural-token, file, developer, and CSTG-term hubs. These two methods can

where each component gives the CSTG mass assigned to the corresponding term type. The intent assigned to the commit is represented by an indicator vector i(c) ∈ {0, 1}7 ,

(D.2)

whose dimensions correspond to {fix, feat, refactor, test, docs, perf, revert}. A commit assigned the other intent receives the all-zero vector. In addition to the intent label itself, we use seven features that compare the stated intent of the commit with the size and structure of its actual change. Let q(c) = [q1 (c), . . . , q7 (c)] 30

(D.3)

For a target commit c = c( j) , let F0 (c) denote the set of files touched by the commit. These are the files connected to c through the file-change relations in the Core layer, including ADDED, MODIFIED, DELETED, RENAMED_FROM, and RENAMED_TO. We use this set as the starting point for TGC. The corresponding feature block is denoted by T0 (c) and provides the reference information for the files directly involved in the change. To obtain cross-file context, consider the file-level import graph available at commit j, D( j) = F ( j) , I( j) , (E.1)

Table D.18: Intent realization and cross-modal consistency features used by the CSTG semantic channel. I[·] denotes the indicator function, |δc | is the size of the structural delta, and ac and rc denote the numbers of additions and removals, respectively. Feature

Definition

where F ( j) is the set of files and

denote this intent-realization block. The seven features are defined in Table D.18. Finally, let 18 h(c) ∈ R2 (D.4)

( fa , fb ) ∈ I( j)

IMPORTS

fa −−−−−−→ fb in K ( j) . (E.2)

The direction of this relation is important. If a touched file imports another file, the second file is an importee; if another file imports a touched file, that file is an importer. We therefore define the two one-hop sets n o F1→ (c) = f ′ < F0 (c) ∃ f ∈ F0 (c) : ( f, f ′ ) ∈ I( j) , (E.3) n o F1← (c) = f ′ < F0 (c) ∃ f ∈ F0 (c) : ( f ′ , f ) ∈ I( j) . (E.4)

denote the sparse hashed-text representation of the commit. Each typed CSTG term is converted to a tagged token and mapped to one of 218 feature positions using feature hashing (Weinberger et al., 2009). The term weights computed by CSTG are carried into this representation, so terms with greater semantic weight contribute more strongly. The complete input to the semantic channel is zc = ρ(c), M(c), i(c), q(c), h(c) .

⇐⇒

(D.5)

Thus, F1→ (c) contains untouched files imported by the changed files, whereas F1← (c) contains untouched files that import the changed files. TGC keeps these two directions separate rather than merging them into a single neighborhood. Their features form the two directionspecific blocks T1,dep (c) and T1,dry (c). This distinction allows TGC to use information that the commit–hub projection does not directly contain. Suppose, for example, that commit c changes file f , while an untouched file f ′ still imports f . The projection describes c through its file, developer, structuraltoken, and CSTG-term hubs, but it does not contain the IMPORTS edge f ′ −−−−−−→ f . The incoming dependency neighborhood therefore brings f ′ into the context of c even though f ′ itself was not changed. The same applies in the other direction when a changed file depends on an untouched file. TGC also includes package-level context. Let pkg( f ) denote the package containing file f . We define

A class-balanced logistic-regression model is fitted using the currently available commits in Cpast . The semantic-channel score is G(c) = σ β0 + β⊤ zc . (D.6) Thus, G(c) is a single commit-level probability summarizing the semantic evidence extracted by CSTG and is passed to the common score-fusion model. Appendix E. Traversal and Global-Context Features The commit–hub projection in Appendix C gives the five graph-based inference methods a compact representation of each commit. However, not every relation stored in KG-Commit appears in this projection. In particular, the file-to-file IMPORTS relations and package relationships remain in the full knowledge graph. We use a traversal/global-context (TGC) feature block to make a small part of this information available to the predictor without running the graph-based inference methods directly over the full graph.

FP (c) = f ′ < F0 (c) ∃ f ∈ F0 (c) : pkg( f ′ ) = pkg( f ) . (E.5) The corresponding block TP (c) therefore describes untouched files that belong to the same package as at least 31

one file changed by the commit. This supplies packagelevel context even when no direct IMPORTS relation exists between the two files. Finally, TGC records where the relevant files lie in the project dependency graph. We compute PageRank and k-core values on the file-level dependency graph D( j) . PageRank measures the relative centrality of a file in the import structure, while its k-core value indicates whether it belongs to a more densely connected part of that graph. These graph-position features form M1 (c). Combining the five feature groups gives

The F configuration uses the selected graph-channel scores, G evaluates the semantic channel alone, F + G combines the graph and semantic scores, and F + G + T additionally includes the TGC feature block. As with the other learned components, fitting uses only the gap-resolved commits in Cpast . The TGC-augmented stacking head uses standardized, class-balanced logistic regression with an L1 penalty, C = 0.2, and the liblinear solver. The additional context does not require a full KG traversal every time a commit is scored. The TGC information is extracted for each project and cached, and per-commit scoring reads the corresponding feature values from this cache. TGC can therefore add dependency, package, and architectural context without placing a Neo4j traversal on the online prediction path.

h i T(c) = T0 (c), T1,dep (c), T1,dry (c), TP (c), M1 (c) . (E.6) Their roles are summarized in Table E.19. Table E.19: Feature groups used by the TGC representation.

Group

Graph information used

T0 (c)

Files directly changed by the target commit. T1,dep (c), T1,dry (c) Untouched one-hop import neighbors of the changed files, with importers and importees kept as separate directions. TP (c) Untouched files in the same package as the changed files. M1 (c) Position of the file context in the project dependency graph, represented through PageRank and k-core.

Because projects differ in size and dependency structure, the same raw feature value can have a different scale from one project to another. Each scalar TGC feature is therefore supplied in both raw and standardized forms. For a feature x(c), z x (c) =

x(c) − µ(xj) σ(xj)

(E.7)

where µ(xj) and σ(xj) are the running mean and standard deviation of that feature in the current project. The model therefore sees both the original value and how large or small it is relative to the project observed so far. TGC augments the graph and semantic inference outputs rather than replacing them. Let sm (c) be the score of graph channel m and let G(c) be the semantic-channel score defined in Appendix D. The complete F + G + T model is   X   ⊤ b y(c) = σ θ0 + θm sm (c) + θG G(c) + θT T(c) . (E.8) m∈F

Record · ID 668139 · SHA-256 6e8cb74f364c0f27
Retrieved via Conceptio — every document is proof-bundled with source, license, and retrieval metadata.