How the archive selects, reviews, and corrects sources.

note 01

How resources are selected

Before a source enters the archive it must be public, legal, reputable, and genuinely useful. Official pages, primary records, standards bodies, public institutions, academic indexes, and widely trusted tools are preferred. Every entry ships with a category, description, safe use cases, a reliability score, a risk level, ethical notes, and a last-checked date. The goal is not to hoard links but to make trustworthy research easier.

note 02

What risk levels mean

• --Low: general search, official datasets, documentation, standards, public records, and security guides.
• --Medium: sources that can derive personal, social, transport, infrastructure, or account-linking context; use proportionally and with a clear purpose.
• --High: malware, dark web, sensitive tracking, or sources that demand strict authorization and a lab-controlled environment; use only with explicit authority.

note 03

How verification notes are written

Each resource's verification note describes how to confirm a signal from that source: check the date and context of the output, compare it against at least one independent second source, and note the false-positive likelihood separately. No single source ever yields a final verdict.

note 04

Broken links and aging tools

Resource URLs are checked with automated link checks and regular maintenance passes; every entry shows its last-checked date. The Resource Health desk lists access problems. A broken or redirected source is first flagged in its notes, and if the problem persists it is replaced with an alternative or removed.

note 05

Legal and ethical boundary

The archive supports only passive, legal, defensive open-source research. Sources are never listed for bypassing access controls, evading authentication, doxxing, harassment, or target hunting, and sources that mainly enable such use are rejected. Details live on the Ethics and OPSEC pages.

note 06

How corrections are accepted

If you spot a wrong description, a missing risk note, a broken link, or a better alternative, open a GitHub issue, follow the steps on the contribute page, or use the channels on the support page. Email is preferred for security-related reports. Accepted corrections are written into the resource record and the last-checked date is updated.