Scores are claims. Receipts are proof.

Scoring model

Every entity is scored on the same four dimensions, each on a 0–10 scale. Higher scores indicate more predatory behavior or greater user harm. The overall score is the unweighted average of the four dimensions, rounded to one decimal place.

Scores are editorial judgments informed by receipts. They are not measurements of harm, and they are not legal findings. A dimension can be scored even when receipt collection is still in progress; the receipts section will say so explicitly.

Working rules

• Scores reflect observed practice, not intent or reputation.
• A high score requires evidence; absence of evidence is recorded as a gap, not a clean bill of health.
• When evidence is thin, the dimension summary states the uncertainty.
• Scores are comparable across entities because the scale and bands are fixed.

Dimension definitions

The four dimensions are deliberately broad so that different kinds of products can be compared without forcing every concern into one bucket.

Evidence requirements

A receipt is a falsifiable claim with a way to check it. Every receipt should be specific enough that a reviewer could confirm or refute it without inside access.

Required

• A non-empty claim: a concrete, observable statement.
• Claims must be about the product or service, not about a category in the abstract.

Expected whenever possible

• url: the primary source — policy, documentation, store listing, filing, or reproducible observation.
• archiveUrl: a Wayback or equivalent snapshot for mutable pages.
• date: when the evidence was observed or captured.
• snippet: a short excerpt that gives the claim context.

Quality bar

• Prefer primary sources over summaries or news coverage.
• Distinguish observation from inference in summaries.
• Do not mix marketing language into claims; describe what was observed.
• All entries are real products with primary-source evidence. No mock or demo content.

How PR validation works

Proposed changes to entity data or site code run through the checks defined in .github/workflows/validate-pr.yml. The goal is to keep the index structurally valid, sourced, and buildable.

1. Schema & template validation. node scripts/process/validate-data.mjs checks that every entity file matches the schema: required fields, slug/filename agreement, score ranges, and http(s) URLs.
2. URL alive check. node scripts/process/check-urls.mjs verifies that URLs in changed entity files return reachable responses.
3. Content guardrail. node scripts/process/llm-guardrail.mjs runs heuristic checks for biased or non-neutral language, with an optional LLM review hook when provider credentials are configured.
4. Build. npm run build confirms the static site still generates correctly.

Data-only changes should pass the same bar as code changes. If a URL cannot be archived, say so in the PR description and include the observation date.

New entities usually start with the research CLI: npm run research -- "Product Name". It fetches official pages and produces a draft scorecard with receipts for review before a PR. See docs/RESEARCH.md for the command reference and evidence rules.

Limitations & corrections

This is a work in progress. Coverage is uneven, products change frequently, and scores reflect the evidence available at the time of the last update.

• A low score is not an endorsement; it means the observed practice was absent, bounded, or easy to avoid.
• A high score is a prompt to look at the receipts, not a verdict.
• Missing receipts are gaps. A dimension with no receipts may still carry a score, but the summary should say so.
• To challenge a score or receipt, open a pull request with a better source.