△This is an explainable governance signal, not a legal or personal judgement. Public location evidence does not establish nationality, residence, sanctions status, malicious intent, repository permissions, or individual trustworthiness. A maintainer can request correction when upstream data or place matching is wrong.
## Why the design serves the public interest
Jurisdiction-risk controls are often available only through opaque enterprise
databases and private scoring models. inspect.software takes a different
approach: the evidence boundary, country scope, multipliers, score ceiling, and
limitations are public and versioned. Commercial relationships cannot alter a
published result.
That transparency protects both sides of the ecosystem. Dependency consumers
receive a usable governance signal; maintainers can see exactly what was
measured, what was not inferred, and how to challenge incorrect evidence. The
objective is disciplined open-source risk review—not suspicion by association.
Related: [Security](/wiki/security) · [Security posture](/wiki/security-posture)
· [methodology](/methodology) · [signals, not warranties](/wiki/signals-not-warranties)
---
# Growth Authenticity
> How inspect.software reads a repository's day-by-day star and fork history for growth that organic attention does not produce, and what the Inorganic Growth Policy does about it.
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](/wiki/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 6.8% 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](/wiki/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](/wiki/popularity) ·
[community & adoption](/wiki/community-adoption) ·
[signals, not warranties](/wiki/signals-not-warranties)
---
# Organization assessment
> How inspect.software assesses GitHub organizations — portfolio activity, community reach, and profile completeness on the same 1–100 scale and bands.
Beyond individual repositories, inspect.software assesses **GitHub
organizations** — the entities that steward software portfolios. An
organization assessment answers a procurement-grade question: *is this a
maintained, accountable, clearly presented steward,* independent of any
single repository it owns.
Organization values use the same 1–100 scale and the same
[rating bands](/wiki/scoring-bands) as repositories, computed under the same
versioned methodology.
## Categories and metrics
| Category | Weight | Metrics (weight within category) |
| -------- | ------ | -------------------------------- |
| **Activity & Reach** | 75% | [portfolio activity](/wiki/portfolio-activity) (60%), [community reach](/wiki/community-reach) (40%) |
| **Governance & Profile** | 25% | [profile completeness](/wiki/profile-completeness) (100%) |
**Activity & Reach** asks whether the repository portfolio is maintained and
whether the organization has traction. **Governance & Profile** asks whether
the organization is accountable and clearly presented — the same identity
evidence that feeds a repository's [stewardship](/wiki/stewardship) metric.
## How portfolio facts are computed
Portfolio measurements are computed over a sample of up to **100 public
repositories** (the API page cap), ordered by most recent push. For
organizations above that size, the sample favors the actively maintained end
of the portfolio — stated here because honest methodology includes its
sampling rules.
## How organization and repository assessments relate
- A repository report embeds its owning account's public profile, which
drives the repository's [stewardship](/wiki/stewardship) metric — so
organization quality already influences repository values where it should.
- An organization assessment is the aggregate view: one number for the
steward across everything it maintains.
- The same missing-data discipline applies throughout: unavailable facts are
excluded and weights renormalized, never counted as zero (see
[the health index](/wiki/health-index)).
## Improving an organization's assessment
- Keep the portfolio honest: archive repositories that are no longer
maintained rather than letting them decay in place — see
[portfolio activity](/wiki/portfolio-activity).
- Complete the organization profile and verify its domain — see
[profile completeness](/wiki/profile-completeness).
Related: [stewardship](/wiki/stewardship) ·
[methodology versions](/wiki/methodology-versions)
---
# Portfolio activity
> How inspect.software measures an organization's portfolio activity — recently active repos, yearly activity, portfolio size, and original work. 45% of the org index.
**Portfolio activity** measures whether an organization's repository
portfolio is actually maintained. Organizations accumulate repositories the
way attics accumulate boxes; what distinguishes a working steward from a
graveyard is the share of the portfolio that still moves.
- **Assessment:** [organization](/wiki/organization-assessment), Activity & Reach category (60% within category)
- **Weight in organization overall:** 45%
- **Metric key:** `portfolio_activity`
## How the value is computed
Computed over a sample of up to 100 public repositories, most recently
pushed first:
| Component | Weight | Criteria |
| --------- | ------ | -------- |
| Recently active repositories | 50 | share of sampled repositories pushed within the last 90 days |
| Yearly active repositories | 25 | share pushed within the last year |
| Portfolio size | 15 | log-scaled; ~100 repositories saturates |
| Original work | 10 | share of sampled repositories that are not forks |
## Why shares, not counts
Ratios make organizations of different sizes comparable: an organization
with 8 of 10 repositories active outreads one with 30 of 300. Size still
earns its own (smaller, log-scaled) component, because a substantial
portfolio is real evidence of capacity — it just cannot compensate for a
portfolio that is mostly dormant. The original-work component keeps a wall
of forks from impersonating a development organization.
## Reading the result
- **Archiving is good hygiene, and the metric rewards it.** GitHub excludes
archived repositories from the default listing, so an organization that
archives finished work concentrates its sample on what it actively
maintains. Honest labeling improves the measurement — by making the
measurement more accurate.
- The 90-day component dominates: this metric describes the present, with
the yearly component as its trailing context.
## Improving the value
- Archive repositories that are done or abandoned — the single most
effective action, and it also serves the organization's users.
- Keep maintained repositories visibly maintained: dependency updates and
fixes count as pushes.
Related: [community reach](/wiki/community-reach) ·
[organization assessment](/wiki/organization-assessment)
---
# Community reach
> How inspect.software measures an organization's community reach — followers and portfolio-wide stars on logarithmic scales. 30% of the organization index.
**Community reach** measures an organization's traction: the audience that
follows it and the attention its portfolio has earned. Reach matters for the
same reason a repository's [popularity](/wiki/popularity) does — widely
watched software has more eyes available to notice problems — aggregated to
the level of the steward.
- **Assessment:** [organization](/wiki/organization-assessment), Activity & Reach category (40% within category)
- **Weight in organization overall:** 30%
- **Metric key:** `community_reach`
## How the value is computed
| Component | Weight | Criteria |
| --------- | ------ | -------- |
| Followers | 50 | log-scaled; ~1,000 saturates |
| Stars across repositories | 50 | summed over the sampled portfolio, log-scaled; ~10,000 saturates |
Both components are logarithmic for the same reason popularity is: each
order of magnitude counts roughly equally, so the metric differentiates
across the whole range instead of only flattering giants. Portfolio stars
are computed over the same sample (up to 100 most recently pushed public
repositories) as [portfolio activity](/wiki/portfolio-activity).
## Reading the result
- **Reach is attention, not use.** It is the weaker cousin of adoption
evidence — kept at a moderate weight and paired with activity, which is
harder to accumulate passively.
- **Followers and stars measure different things.** Followers attach to the
organization itself (people watching the steward); stars attach to its
work. An organization famous for one repository and followed by no one
reads differently from an institution people track as such.
- Saturation points mean mega-organizations stop gaining: beyond ~1,000
followers and ~10,000 portfolio stars the question is answered.
## Improving the value
There is no direct lever, deliberately. Reach follows the durable levers
measured elsewhere: maintained portfolios
([portfolio activity](/wiki/portfolio-activity)), complete public identity
([profile completeness](/wiki/profile-completeness)), and repositories that
are easy to adopt ([community health](/wiki/community-health)).
Related: [popularity](/wiki/popularity) ·
[organization assessment](/wiki/organization-assessment)
---
# Profile completeness
> How inspect.software measures organization profile completeness — verified domain, description, homepage, contact, and identity fields. 25% of the org index.
**Profile completeness** measures whether an organization is accountable and
clearly presented: a verified real-world identity, a stated purpose, and
working ways to reach it. For anyone deciding whether to depend on an
organization's software, the profile is the difference between an
institution and an anonymous namespace.
- **Assessment:** [organization](/wiki/organization-assessment), Governance & Profile category (100% within category)
- **Weight in organization overall:** 25%
- **Metric key:** `profile_completeness`
## How the value is computed
| Component | Weight | Evidence |
| --------- | ------ | -------- |
| Verified domain | 25 | domain verification completed on GitHub |
| Description | 20 | the organization's description field |
| Homepage | 15 | a working website URL |
| Display name | 10 | a human-readable name beyond the login |
| Location | 10 | a stated location |
| Contact email | 10 | a public contact address |
| Social profile | 10 | at least one linked social account |
## Why a profile is governance evidence
- **Domain verification is the anchor — and the heaviest component.** It
cryptographically ties the GitHub organization to a real-world domain,
which is genuine supply-chain evidence: it forecloses a whole class of
namespace-impersonation attacks. The same signal feeds each repository's
[stewardship](/wiki/stewardship) metric.
- **Description, homepage, and name** establish what the organization is
and where its canonical presence lives.
- **Location, email, and social links** are accountability surface: routes
by which a security researcher, a packager, or a legal team can actually
make contact.
## Reading the result
- This is the most directly actionable metric in the organization
assessment — every component is a settings field, and the whole checklist
can be completed in under an hour.
- An incomplete profile on an otherwise strong organization usually
indicates neglect rather than concealment — but the record can only
publish what is visible, and the metric reads accordingly.
## Improving the value
- Verify the organization's domain in GitHub settings — the single largest
component.
- Fill every profile field: description, homepage, display name, location,
public email, and at least one social profile.
Related: [stewardship](/wiki/stewardship) ·
[organization assessment](/wiki/organization-assessment)
