Why reconstruct history instead of reading the GitHub API?
The GitHub API only shows a repository as it is now. To label whether a repo went inactive over a past 12-month window, and to compute features as they stood before that window, you need activity as it was at a chosen date t — not today's snapshot. GH Archiveis a public, hour-by-hour record of GitHub's public event stream, so replaying it up to tgives an honest point-in-time view and keeps future information out of the features. The GitHub API is used only for facts that don't rewrite history — creation time, default branch, fork and archive state.
The same sources, two moments
- Offline (training): full GH Archive history is downloaded and replayed to build a labeled dataset. This is where the point-in-time reconstruction happens at scale.
- Online (scoring): a live submission is enriched from the GitHub API and OpenSSF Scorecard for current signals, and matched against the staged full-history feature cache when the repo is one the offline pipeline already reconstructed.
Package registry facts come from deps.dev, which also provides the package-to-repository link so a dependency name can be resolved to the repository actually being maintained.
Provenance & honesty about gaps
- Every signal carries its source and observation time, so a score can be traced back to the evidence.
- A signal that can't be resolved is filled with the training-cohort average and flagged as missing — it adds no evidence and lowers evidence support rather than silently guessing.
- Bot accounts are excluded from commit and contributor counts so automation doesn't look like maintenance.
Next, see how these sources are turned into a leakage-controlled, labeled training table in Building the dataset.