A GitHub star is the most widely read trust signal in open source. It is also the only one with no issuer. Stars are sold openly, in bulk, for a few cents each, alongside forks, watchers and followers, and nothing in the number itself distinguishes the bought from the earned.
Every assessment that counts stars inherits that problem. Growth Authenticity is the part of the methodology that addresses it: the per-day star and fork history collected for each report is read for growth whose shape organic attention does not produce, and where such growth is confirmed, the purchasable inputs are discounted rather than believed.
The result answers a narrow question:
Does this repository's popularity history look like something that happened, or like something that was delivered?
It does not answer who did it, or whether anyone paid for it. Every finding here is a statement about the timing of public events, and nothing more.
Why the timing gives it away
Attention that a project earns arrives through people, and people are irregular. A launch, a Hacker News front page, a conference talk or a newsletter mention produces a spike that is uneven hour to hour, that brings forks along with stars because some readers open the code, and that decays over the following week as the link circulates and then stops.
Delivered attention has none of those properties. It arrives on a schedule, from accounts that never look at the repository, and it ends the moment the order is filled. The counter cannot tell the difference. The history can.
What is measured
The report first looks for spike days — days on which the repository gained both at least 25 stars and at least twelve times its own median active-day rate. Consecutive spike days are merged into one window.
A spike is never a finding on its own. Real projects spike, and a methodology that treated every burst as suspicious would flag every successful launch. A window is confirmed only when at least two independent signals corroborate it:
| Signal | What it observes |
|---|---|
| Star concentration | The five busiest days hold 80% or more of every star collected. Measured across 502 ordinary repositories, the median puts 6.9% of stars in its five busiest days and none reached 80%. It is a claim about the whole history rather than one burst, so it corroborates every window — and is only available where the whole history was collected. |
| Flat cadence | Across three or more days, the daily additions barely varied. An audience is uneven; a delivery schedule is not. |
| No fork response | The window's fork-to-star ratio fell below a quarter of the repository's own long-run ratio — attention that never touched the code. |
| No decay | The seven days after the burst totalled 5% or less of it. Real spikes have a tail; a filled order stops dead. |
| No released substance | The project has never published a release at all. Deliberately weak: plenty of legitimate projects publish nothing. An earlier form of this signal treated a burst arriving before a project's first release as evidence, and it produced every false positive in the first control measurement — publish, attract attention, release later is how ordinary projects work. |
The four states
| State | Meaning | Effect |
|---|---|---|
| Organic | The history is consistent with organic accretion. | none |
| Unverified | The collected history cannot answer the question. | none |
| Anomalous | One confirmed window. | stars and forks discounted 40% |
| Highly anomalous | Two or more confirmed windows, or one carrying three signals. | stars and forks discounted 70% |
The discount applies to the stars and forks components of popularity — the two inputs a supplier can sell. Watchers are untouched, because they are not part of what the anomaly evidences, and no other category moves at all. Popularity carries 7.2% of the overall index, so the arithmetic effect is deliberately small. The finding is the product; the adjustment only stops the report from asserting something it has reason to doubt.
There is no upward adjustment. A clean history cannot raise a score, exactly as a clean jurisdiction result cannot raise security posture.
What Unverified means, and what it does not
A repository reads unverified when it has no collected star history, when it holds fewer than 100 stars, or when the collected window spans less than 60 days. It carries no penalty of any kind.
This is the common case, and it is a limit of the evidence rather than a verdict. History collection is bounded — the report captures a recent window of star and fork events, not the whole life of a large project — so manipulation older than that window is simply invisible here. Unverified means the question was not answerable. It never means the answer was clean.
Reading the result
- A finding is about a pattern, not a person. Stars can be bought by a competitor, by a promoter, by a previous owner of the repository, or by someone the maintainers never met. Nothing in this assessment identifies who acted, and nothing in it implies the maintainers did.
- A finding does not make the software bad. It makes one piece of evidence about the software unreliable. The engineering, governance and security evidence in the rest of the report is unaffected and stands on its own.
- The absence of a finding is not a certificate. Slow, distributed purchasing across months does not spike, and this assessment will not see it.
Improving the value
Nothing can be done to a repository to improve this result, and that is the point: the assessment reads history that has already happened. A project whose growth was genuine already reads organic.
Related: popularity · community & adoption · signals, not warranties