Data card
What the project holds, what it collects, and what can be reconstructed. It exists so a reader can size the dataset without asking.
This page is shared verbatim by both hubs of the survey, apart from this hub's own counts and hash.
What is held today
81 campaigns on the record. 15 were selected for extraction and 14 extracted. 54 of the 81 carry a placement on this hub; 10 of those are marked ingested, and 9 admitted at least one repository — 86 entries.
The 15 campaigns selected for extraction were picked to cover every design aspect of the taxonomy — all four shared lanes, the cross-hub duals, each hub's own categories, and one pre-standard case to demonstrate absence handling. The pick carries no quality judgment.
Ingested = the campaign's admitted ledger rows were extracted for this site; a campaign can be ingested and have admitted no repositories.
An entry is whatever a campaign's ledger admitted as evidence: tools, but also specifications, datasets, benchmarks and documentation repositories. The unit is the repository, not the product.
Entry counts preserve the ledger record rather than smooth it: name-twins of moved repositories, lineage splits, and one admitted duplicate (the duplicate's entry says so itself) are counted as recorded. A fork-parent flag is planned.
2,937 evidence-ledger rows and 7,988 screening rows across the modern campaigns. A tracking cohort of about 1,246 distinct repositories, keyed by numeric repository ID. On this site: the ingested slice — every count on the category pages states its denominator.
| Quantity | Value |
|---|---|
| Campaigns on the record | 81 |
| Campaigns selected for extraction | 15 |
| Campaigns extracted | 14 of 15 |
| Campaigns placed on this hub | 54 of 81 |
| Placed campaigns marked ingested | 10 of 54 |
| Campaigns that admitted at least one repository | 9 of 10 |
| Evidence-ledger rows | 2,937 |
| Screening rows | 7,988 |
| Tracking cohort, distinct repositories | about 1,246 |
| Entries on this hub | 86 |
| Taxonomy version | v3.3-two-hubs-four-shared-lanes |
| Campaign map generated |
Method: sealed campaign ledgers; dated, hashed API snapshot. As of 2026-08-10.
What is collected
Per entry, once weekly collection starts — append-only and hash-attested. The table below is the collection design, and the planned additions are listed after it. The standing rules: aggregate public metrics only; no stargazer or contributor identities; no maintainer profiling. Measured projects are public artifacts, and anything we publish about them follows the posting rules. The posted record is public and quotable; the collection run itself is not published.
The posting rules are Part II of the methodology: the standard.
This table is the collection design. What the site's API serves today is the snapshot fields plus provenance; the remaining fields begin with weekly collection.
| Group | Fields | Why |
|---|---|---|
| Identity | repo slug, numeric GitHub ID (survives renames), homepage, first-seen date | Numeric ID is the primary key; slugs are mutable. |
| Scout evidence | originating campaign(s), ledger disposition, evidence class, the campaign's calibrated claim, campaign date | This is selection provenance that popularity-sampled datasets do not record. |
| GitHub current state | stars, forks, watchers, language, license (SPDX), archived flag, created/pushed dates, topics | Metadata facts only — never repo-authored text. |
| Weekly deltas | change in stars, change in forks, releases since last week, pushed-since flag | Derived, but stored explicitly — recomputation assumes no snapshot is ever lost. |
| One-time backfill | per-repo star history to 2011, from an independently collected archive of the same platform's public events | Run once, early. It cross-checks the weekly star counts against that archive; the two share a source, so agreement bounds transcription error and says nothing about the platform’s own counting. |
| Provenance | snapshot date, snapshot hash, method version, link to the sealed campaign record | Matches the sealing doctrine, at almost no cost. |
Planned additions
- Open issues and pull requests, counted separately, plus contributor count.
- Release count, with the latest release tag and date.
- Weekly commit-activity capture, because the upstream window rolls.
- Fork-parent flag, so a lineage is never double-counted.
What can be backfilled
- Star history is reconstructable to February 2011 from an independently collected archive of the same platform's public events. That backfill has not run yet.
- Traffic data and fine-grained activity events expire upstream on rolling windows and can never be recovered later.
- Stargazer identities are restricted upstream. Aggregate counts remain, and identities are not collected in any case.
What is an extrapolation
The figures below are linear projections from the 2 of 81 campaign bundles ingested into the downstream registry (v1.4) — an earlier, separate pipeline from this site's own ingestion. Order-of-magnitude estimates, carried with no interval.
Every other number on this site is counted.
| Quantity | Estimated scale |
|---|---|
| Works across the modern bundles | ~2,000+ |
| Claims | ~4,000+ |
| Source records | ~15,000+ |
Snapshot in force
- Snapshot
- · retrieved UTC
- Retrieval instant (UTC)
- Entries hash (sha256, first 12)
-
40e9e9c1efa4— this hub's served data file — verifiable at /api/entries.json - Snapshot hash (sha256, first 12)
-
5029a1dd0e77— raw capture, shared by both hubs (not yet published) - Method version
- supervised beta (v3.3 taxonomy)
The snapshot is dated 2026-08-10 (local); the capture ran at 2026-08-09T18:13:56Z, and every snapshot reference on this site prints both dates rather than the label alone.
The two hashes cover two different things. The entries hash is over the exact bytes this hub serves, so it can be checked today. The snapshot sha256 covers the raw API capture shared by both hubs of this survey, and that artifact is not yet published — it is a commitment, not yet a check.
The machine layer
The same data is served as JSON. Entries are addressable two ways — by
numeric repository id and by slug; the collection, category, tag and snapshot
endpoints are documents, not id maps:
/api/entries.json, /api/entries/<id>.json,
/api/entries/by-slug/<slug>.json,
/api/categories.json, /api/tags.json and
/api/snapshot.json. Entries whose repository did not resolve
carry a null numeric id and have no id-keyed file; the by-slug pattern
addresses every entry.
FHK-/AHK- ids are hub-local display-position ids; the stable cross-hub key
is github_repo_id.
These endpoints render the same facts as the pages. Quoting with attribution is permitted; redistributing the endpoints as a dataset is not, while the licensing review is open.
Citation and corrections
Cite as: AI Founder Hub, a method-curated survey (taxonomy v3.3), 2026-08-10, https://ai-founderhub.com. Corrections are recorded as dated events in the record; a contact route arrives with the licensing review.