- 1
Submit a repository
You paste a GitHub repository URL. The unit of analysis is a single repository; the set of dependency repositories for a project is expected to come from an external software-composition-analysis tool (for example the OSS Review Toolkit), and each repository is scored on its own.
- 2
Enrich from public sources
For each repository the pipeline pulls stable metadata (creation, default branch, archive state) and the maintenance signals it needs. Bot activity is excluded so automated noise doesn't look like maintenance.
- 3
Resolve the feature vector
The observed signals are turned into the model's features. Any signal that couldn't be resolved is imputed to the training-cohort average and flagged as missing — it then contributes no evidence and lowers evidence support.
- 4
Pick the regime
If the repository is in the staged full-history feature cache, the full-history model runs (rich reconstructed history). Otherwise the cold-start model runs on the signals available right now. Cold-start is deliberately treated as the less precise, more broadly applicable regime.
- 5
Score and calibrate
The model outputs a raw probability, which is mapped through the calibration curve learned on held-out data so the number reflects observed real-world rates rather than a raw model output.
- 6
Evidence support, margin, and bucket
Alongside the probability you get a per-repository evidence-support value (coverage, in-distribution fit, calibration support), a margin (how decisive the call is), a risk bucket, and an action level (monitor / review / replace candidate) with the evidence behind it.
Reading the result
- A high score is not proof of abandonment, and a low score is not proof of safety — it is decision support for triage, not a verdict.
- Missing data is shown explicitly and lowers evidence support rather than being hidden.
- Popularity is weak context, not primary evidence.
For what the score means given how the model performed, see Training results explained and Trust & evidence support.