Method, evidence policy, and limitations
What this site does
Each report studies one directional research question: “is the subject a successor of, or a fork of, the object project?”. Data comes exclusively from official sources — repository metadata and README files from the GitHub REST API, package metadata from the npm registry and PyPI JSON API — collected on our own infrastructure and exported as static snapshots.
Observed facts vs. conclusions
Reports separate two layers. Observed facts are verbatim quotes, registry fields, and repository metadata with their collection times. Relationship conclusions are derived statements that require a recorded human decision bound to the exact evidence they were based on. Automated evaluation only classifies evidence as sufficient to propose a review or insufficient; it never confirms a relationship.
Upstream events and observations are kept apart in every timeline: when the source provides an event time (for example a commit date) it is shown as the event time; the time we first observed something is always shown separately. A first observation is never presented as the upstream event time.
Status model
| Status | Meaning | Indexable |
|---|---|---|
| confirmed | A human decision exists for the current evidence fingerprint, no dispute is open, both endpoints have distinct repository identities, and all necessary sources are fresh and healthy. | yes |
| disputed | An unresolved dispute exists. Refreshes and recollections cannot clear it; only an explicit recorded resolution can, and confirmation is then recomputed from current evidence. | no |
| observed | Everything else: evidence recorded but not yet decided, held or rejected candidates, stale approvals after evidence changed, insufficient data, or collection problems. Observed never means “dead” or “abandoned” — low activity is an observation, not a conclusion. | no |
Failure handling
Collection failures (timeouts, rate limits, missing responses) are recorded as failures and shown on affected reports. They never overwrite the last verified facts and never generate statements like “zero recent activity” or “project abandoned”. If a necessary source could not be collected recently, the report loses its confirmed status until a fresh, successful collection exists. Our freshness window is a product policy, currently 14 days; it is a chosen threshold, not a claim about project health.
Limitations
- Minimal stage: evidence extraction is deterministic (keyword patterns and registry fields). It can miss claims phrased unusually; misses keep a pair at observed.
- We do not compute contributor overlap, historical star growth, or full commit counts; we only sample a small recent commit window, and reports say so.
- Registry deprecation messages are free text; they are evidence, not proof of a specific successor.
- Reports without a confirmed status are excluded from search engines (noindex) and from the sitemap.
- Demo builds contain fabricated data, are marked DEMO on every page, and are never indexed.