Module score 

Available on crate feature vcs-git only.

Composite risk-score formulas.

Two scores are offered. The default weighted score is a log-scaled weighted sum with categorical multiplicative bumps; the percentile score re-ranks every signal to its position within the analyzed set and averages. Both are ordinal: only relative ranks carry meaning, never the absolute magnitude.

Literature

The term weights and thresholds are grounded in the defect- and vulnerability-prediction literature synthesised on issue #328:

• Recent churn and recent commit count carry the highest weight — Nagappan & Ball’s relative-churn measures and the just-in-time defect-prediction line both find recent change activity the strongest single signal (Firefox LinesChanged PD 85, NumChanges PD 86).
• The author factor is multiplied by an ownership-dilution term (1 - ownership_top_share): diffuse ownership predicts defects (Avelino DoA / truck-factor; Bird et al.).
• Categorical developer-count bumps encode the RHEL4 finding that files touched by ≥9 developers were ~16× more likely to harbour a vulnerability, with a softer bump at the 6-developer mark.
• A new-file bump reflects the Chromium observation that newly added features carry elevated risk.
• Bug-fix and security-fix commit counts feed a log-scaled additive term, security fixes double-weighted (Sentence-Level VFC studies; PySecDB).
• File size enters as ln1p(sloc)^2 / 100 with a full coefficient of 1.0, so it is a meaningful contributor rather than a tiny tie-breaker: ~0.33 at 300 SLOC, ~0.48 at 1k, ~0.85 at 10k, and >1.0 past ~50k SLOC. Those magnitudes are comparable to the churn terms (a recency-churn “point” is 0.30*ln1p(50) ≈ 1.18) and dwarf the entropy (≤0.15) and long-churn (≈0.27 at heavy churn) terms. Large files are only weakly correlated with defects, but the squared-log scaling keeps size a first-class additive signal across realistic file sizes.
• v2 adds two recent-window process-entropy terms (issue #330): change entropy (Hassan 2009; file-level Pearson 0.54 with defects on Apache projects) and co-change graph entropy (arXiv 2504.18511, 2025; combining the two improved AUROC in 82.5% of cases). Both enter additively, weighted below recent churn/commits but on par with the fix term — they are bounded per file and complement, rather than restate, the v1 churn/commit signals.

Bumping either formula in any way must increment RISK_SCORE_VERSION so downstream consumers can detect the change. Both the weighted sum (weighted) and the percentile blend (apply_percentile) stamp and are cache-keyed on that one constant, so it versions both — see its doc for the full contract.

Structs

ScoreInput

Raw signals consumed by the weighted formula. Decoupled from Stats so the formula is unit-testable on synthetic inputs without constructing a full stats record.

Constants

RISK_SCORE_VERSION

Version of the risk-score computation, covering both formulas. A single risk_score_version is stamped on every file’s output regardless of the active super::RiskFormula (the weighted sum or the percentile blend), and the persistent VCS cache keys reuse on it (see super::cache). Increment on any change that can alter an emitted risk_score, including:

Functions

apply_percentile

Recompute every file’s risk_score as the mean percentile rank of its signals within the analyzed set (the --risk-formula percentile mode).

weighted

Compute the weighted composite risk score for one file.