Composite Stability Index (CSI) Overview

Updated 7 July 2026

Composite Stability Index (CSI) is a normalized metric that aggregates four observable dimensions (commits, issues, pull requests, engagement) to assess repository stability.
It applies control-theoretic principles with a triangular normalizer, rewarding behavior near target values and indicating recovery after disturbances.
Empirical validations refined CSI by adjusting time windows and denominators, highlighting trade-offs between sensitivity and practical application in OSS risk assessment.

Searching arXiv for papers on "Composite Stability Index" and related repository-stability work. Search query: "Composite Stability Index repository stability arXiv" Composite Stability Index (CSI) is a normalized, control-theoretic repository-stability metric proposed for open-source software repositories. In this usage, repository stability is the repository activity capacity to return to equilibrium following disturbances such as a sudden influx of bug reports, key contributor departures, or a spike in feature requests. CSI aggregates four observable dimensions—commit patterns, issue resolution, pull request processing, and community engagement—into a scalar score in $[0,1]$ intended to proxy repository health through stability rather than raw activity or popularity (Destefanis et al., 1 Apr 2025). Subsequent work empirically validated the framework on 100 highly ranked GitHub repositories and, separately, operationalized commit stability as one foundational CSI component for OSS risk and resilience assessment (Adejumo et al., 2 Aug 2025, Adejumo et al., 4 Aug 2025).

1. Conceptual foundation and repository state

The original repository-stability framework imports the language of engineering systems and control theory. It begins from a standard continuous-time system,

$\dot{x} = f(x,t),$

and recalls a Lyapunov-style stability notion,

$\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$

The adaptation is conceptual rather than fully mechanistic: instead of a physical state vector, the repository state is defined through four observable activity dimensions,

$R(t) = [c(t), i(t), p(t), a(t)]^T,$

where $c(t)$ is the commit frequency function, $i(t)$ the issue resolution rate function, $p(t)$ the pull request merge rate function, and $a(t)$ the activity engagement function (Destefanis et al., 1 Apr 2025).

This formulation treats a repository as a dynamical socio-technical system whose state evolves through development activity, issue handling, PR integration, and participation. In the empirical validation literature, equilibrium is operationalized through bounded activity patterns and threshold-based stability criteria rather than through an explicit equilibrium-state derivation. The emphasis is therefore on observable process regularity and recovery capacity after disturbances, not on a closed-form state-space model (Adejumo et al., 2 Aug 2025).

2. Indicator architecture and stability criteria

The four CSI components are defined as repository-level functions over a window $[t, t+\Delta t]$ . The commit frequency function is

$c(t) = \frac{N_c(t, t+\Delta t)}{\Delta t},$

where $\dot{x} = f(x,t),$ 0 is the number of commits in the interval. The issue resolution rate is

$\dot{x} = f(x,t),$ 1

where $\dot{x} = f(x,t),$ 2 is the number of issues closed in the interval, $\dot{x} = f(x,t),$ 3 is the total issues, and $\dot{x} = f(x,t),$ 4 is the average resolution time for issues closed in the interval. The pull request merge rate is

$\dot{x} = f(x,t),$ 5

where $\dot{x} = f(x,t),$ 6 is the number of merged PRs in the interval, $\dot{x} = f(x,t),$ 7 is the total pull requests, and $\dot{x} = f(x,t),$ 8 is the average PR review time. The activity engagement function is

$\dot{x} = f(x,t),$ 9

with $\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 0 and $\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 1 (Destefanis et al., 1 Apr 2025).

The framework defines repository stability conjunctively: all four component criteria must hold over an observation period $\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 2. Commit pattern stability is written as

$\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 3

with the intended threshold based on a coefficient-of-variation rule,

$\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 4

Issue management stability requires

$\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 5

with $\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 6 and $\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 7 days. Pull request processing stability requires

$\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 8

with $\|x(t_0)\| < \delta \implies \|x(t)\| < \epsilon,\ \forall t \ge t_0.$ 9 and $R(t) = [c(t), i(t), p(t), a(t)]^T,$ 0 days. Community engagement stability requires

$R(t) = [c(t), i(t), p(t), a(t)]^T,$ 1

with $R(t) = [c(t), i(t), p(t), a(t)]^T,$ 2 and $R(t) = [c(t), i(t), p(t), a(t)]^T,$ 3 (Destefanis et al., 1 Apr 2025).

Component	Raw function	Stability condition
Commit patterns	$R(t) = [c(t), i(t), p(t), a(t)]^T,$ 4	$R(t) = [c(t), i(t), p(t), a(t)]^T,$ 5, intended CV threshold $R(t) = [c(t), i(t), p(t), a(t)]^T,$ 6
Issue resolution	$R(t) = [c(t), i(t), p(t), a(t)]^T,$ 7	$R(t) = [c(t), i(t), p(t), a(t)]^T,$ 8 days
PR processing	$R(t) = [c(t), i(t), p(t), a(t)]^T,$ 9	$c(t)$ 0 days
Community engagement	$c(t)$ 1	$c(t)$ 2

The framework packages these thresholds as

$c(t)$ 3

3. Composite score, normalization, and formal properties

CSI is defined as a weighted sum of normalized component scores: $c(t)$ 4 The weight vector is

$c(t)$ 5

Commit pattern stability therefore receives the highest weight, issue and PR processing receive equal intermediate weights, and community engagement receives a slightly lower weight (Destefanis et al., 1 Apr 2025).

Each raw component is mapped into $c(t)$ 6 by a triangular, target-centered normalizer,

$c(t)$ 7

The original targets and tolerances are $c(t)$ 8; $c(t)$ 9; $i(t)$ 0; and $i(t)$ 1. The paper also proposes an overall repository-stability threshold of

$i(t)$ 2

By construction,

$i(t)$ 3

The framework further claims piecewise continuity within each normalization regime and long-term convergence: if each metric stabilizes so that

$i(t)$ 4

then

$i(t)$ 5

For commits, the equilibrium-seeking condition is expressed as

$i(t)$ 6

(Destefanis et al., 1 Apr 2025).

Component	$i(t)$ 7	$i(t)$ 8
Commit pattern	0.25	0.25
Issue management	0.40	0.10
Pull-request stability	0.50	0.10
Community engagement	0.35	0.10

The normalization has an important structural implication: CSI does not simply reward “more is better.” It rewards proximity to target stable behavior. This makes the index interpretable as a bounded composite of stability corridors, but it also means values far above the target may score poorly if they lie outside the admissible band. The original conceptual paper explicitly notes that the framework is at a conceptual phase and open to debate, and that thresholds and weights are initial proposed values rather than empirically calibrated constants (Destefanis et al., 1 Apr 2025).

4. Empirical validation and recalibration

The first empirical validation of CSI studied 100 GitHub repositories selected by five filters: stars $i(t)$ 9, forks $p(t)$ 0, maturity of at least 10 years, exclusion of educational repositories, and exclusion of archived repositories. All metrics were computed over a fixed five-year window, using GitHub REST endpoints for commits, issues and pull requests, and comments, with a 24-hour JSON cache and exponential back-off for transient errors (Adejumo et al., 2 Aug 2025).

The empirical result was that the original theoretical formulation was not practically feasible as written. Only 2 of 100 repositories met the original daily commit-stability criterion. Among the 90 repositories with issues enabled, 0 met the original issue-stability criterion $p(t)$ 1; the 95th percentile of the original issue rate was only 0.018. For pull requests, 0 of 100 met the original merge-rate threshold $p(t)$ 2. Community engagement thresholds were far less problematic—86% passed the activity ratio criterion and 95% passed the active-user ratio criterion—but only 3 repositories had $p(t)$ 3 under the original triangular normalizer. The practical consequence was that the original CSI produced very little variance across repositories (Adejumo et al., 2 Aug 2025).

The validation identified two principal pathologies. The first was excessive burst sensitivity in daily commit counts. The second was “denominator drag” in issues and pull requests, because $p(t)$ 4 and $p(t)$ 5 were cumulative historical totals rather than window-bounded totals. The empirical paper therefore recommended three refinements. First, commit stability should be computed on weekly rather than daily counts: $p(t)$ 6 Second, issue and PR latency summaries should use the median rather than the mean. Third, issue and PR rate denominators should be bounded to the same observation window, so that

$p(t)$ 7

and

$p(t)$ 8

These changes materially altered feasibility. Weekly aggregation raised commit-stable repositories from 2 to 29. For issues, 64 of 90 repositories had median issue resolution time within 14 days, and 22 of 90 met the refined $p(t)$ 9 threshold. For pull requests, 90% had median review time within 5 days and 34% met the refined $a(t)$ 0 threshold. The empirical paper then recalibrated the triangular normalizer using the median and scaled MAD, setting

$a(t)$ 1

for repositories already satisfying the component threshold. The resulting data-driven parameters were $a(t)$ 2; $a(t)$ 3; and $a(t)$ 4. No equally explicit revised $a(t)$ 5 was reported for commits (Adejumo et al., 2 Aug 2025).

Refined component	$a(t)$ 6	$a(t)$ 7
Issue management	0.620	0.221
Pull-request stability	0.562	0.153
Community engagement	3.7056	3.2644

The validation therefore did not reject the CSI concept. It instead showed that the original framework required empirical calibration before use in monitoring tools or comparative repository assessment.

5. Commit stability as a CSI subindex and risk signal

A subsequent paper treated CSI explicitly as a broader framework encompassing four indicators—commit history, issue resolution time, pull request merge rates, and community engagement—but empirically studied only the commit-frequency component as a foundational signal for OSS resilience and risk assessment. In that formulation, the commit frequency function is

$a(t)$ 8

and a repository is classified as stable when

$a(t)$ 9

with the intended operational rule based on a coefficient-of-variation threshold $[t, t+\Delta t]$ 0. Stability was evaluated at three temporal granularities,

$[t, t+\Delta t]$ 1

and the raw commit-stability signal was mapped into $[t, t+\Delta t]$ 2 by

$[t, t+\Delta t]$ 3

The full four-component CSI aggregation was not specified in that paper (Adejumo et al., 4 Aug 2025).

The empirical findings sharpened the temporal interpretation of commit stability. Across 100 highly ranked repositories, 2% were daily-stable, 29% weekly-stable, and 50% monthly-stable, while 50% were unstable at all three levels. Weekly and monthly CV values were almost interchangeable, with Spearman correlation $[t, t+\Delta t]$ 4. Two repositories—rust-lang/rust and NixOS/nixpkgs—were stable at all three granularities. The paper also argued that commit volume is not a proxy for stability: Rust had 29,759 commits/year and was stable across all granularities, whereas Homebrew-cask had 40,078 commits/year and was unstable across all granularities. Programming languages and compilers, as well as blockchain repositories, were comparatively stable, while front-end/UI frameworks, libraries, and data visualization or analytics repositories showed lower monthly stability (Adejumo et al., 4 Aug 2025).

This commit-only study reframed CSI as a risk and resilience instrument rather than solely a repository-health score. Stable commit rhythms were hypothesized to reflect mature governance, sustained contributors, and robust development processes. At the same time, the paper was careful not to treat commit stability as equivalent to resilience; it was presented as a proxy signal that should eventually be combined with issue resolution, PR merge rate, and community engagement to recover the intended composite scope of CSI (Adejumo et al., 4 Aug 2025).

6. Terminological ambiguity, scope, and unresolved issues

Within the OSS literature, CSI denotes Composite Stability Index. Across arXiv more broadly, however, the acronym is not standardized. In finance, “CSI” may refer simply to the CSI 300 stock index rather than any stability metric (Li et al., 2023). In ENSO research, a climate-network paper proposed the degree skewness index $[t, t+\Delta t]$ 5 as a background stability proxy, explicitly noting that it is a single network-derived scalar rather than a composite physical index (Feng et al., 2015). In cardiac monitoring, “CSI” denotes the Cardiac Stability Index, a different composite scalar in $[t, t+\Delta t]$ 6 integrating the largest Lyapunov exponent, recurrence determinism, and signal entropy via time-delay embedding (Oladunni et al., 26 Apr 2026). This suggests that Composite Stability Index is best treated as a domain-specific construct rather than a universally standardized label.

Within OSS itself, several issues remain open. The original framework is explicitly conceptual and open to debate. Its thresholds and weights were proposed by design rather than estimated from outcomes, the commit component mixes an instantaneous derivative criterion with an intended coefficient-of-variation rule, the time-window choices $[t, t+\Delta t]$ 7 and $[t, t+\Delta t]$ 8 are not fixed by theory, and the triangular normalizer may penalize “too high” values as well as too-low values. The empirical validation further showed that issue-disabled repositories weaken applicability of the issue component, and that the 100-repository dataset is biased toward large, old, highly ranked projects, limiting external validity to smaller or younger repositories (Destefanis et al., 1 Apr 2025, Adejumo et al., 2 Aug 2025).

The resulting picture is neither that CSI is fully settled nor that it failed empirical scrutiny. Rather, CSI has emerged as a repository-stability framework with a clear component architecture, explicit normalization and weighting, partial empirical validation, and identifiable calibration requirements. In that sense, the most stable part of the concept is its structure: a bounded composite intended to measure whether repository processes remain regular, sustainable, and capable of returning toward equilibrium after disturbance.