HOW TO READ THE LABELS

Methodology

How the index is organised: four evidence labels, four categories, and one destination hierarchy per entry.

Evidence labels

official: Published by TypeSafe or by the project's own owner: launch posts, docs, SDKs, evals, status.
source-backed: A public repository, documentation page or live artifact backs the entry.
author demo: A result shown by its author: a post, video or live demo. Figures belong to that author's setup.
commentary: Roundups, analysis, explainers and press.

Figures

Numbers in an entry's notes are quoted from the source with the context it gives: task, sample size, single call or end-to-end. Who measured is visible from the label. Finance, security and autonomy demos are marked high-risk.

X reach is a dated snapshot of the public view counter, not a unique-visitor count. The By reach sort places entries without a readable counter after measured entries.

Destinations

Each card opens the project itself: live service or demo first, repository second, documentation third. The original X post sits behind a separate X button. Entries known only from a post are marked X post only.

Content

Summaries and notes are written for Jevland. Entries are added by hand in batches; see the changelog.

Media

Some entries show a reduced-size still from the original post or article, next to the attributed source. The demo gallery also includes screenshots of public demo interfaces, with the page and capture date attached. Recorded runs and independent models keep their context and evidence label. Originals stay with their authors; an image is replaced or removed on the owner's request.

Last verified

Each entry shows the date its links were last checked.

Availability & demo checks

Link reachable records an HTTP response from the displayed destination on the given date, after following redirects. It does not test a project's installation, model, API or full interface. A recognised error page is not counted as reachable.

Demo tested records a specific browser scenario performed by Jevland. Open the project record to see the scenario, method and date. Recorded replay checks cover playback of saved data; they do not verify live model inference. A screenshot alone does not qualify.

Link unavailable requires two consecutive observations of a missing destination or recognised error page. Timeouts, login requirements, bot protection and rate limits are Check inconclusive. The last successful response remains recorded. Not checked means there is no observation for that destination. Checks never remove an entry automatically.

Repository activity and GitHub metadata checks remain separate from these observations. No project receives a build-success label without a recorded build of a specific revision and environment. Use Report a problem on a project record to send a correction through our moderated form.

Four independent verification levels

HTTP availability: a dated bounded request to the destination; a reachable page can still have a broken application.
Browser demo scenario: the named interaction, method, date and result. It covers only that scenario.
Build: an actual build with a recorded revision, environment, command or method, date, result and test record.
Live API test: an actual service request with a recorded scenario, revision, environment, date, result and test record. Offline SDK transport tests do not qualify.

Each absent observation is shown as Not checked on a project page. These levels are independent of evidence labels. A CI badge, HTTP 200 or an author's assertion cannot advance a level. How to run describes a dated documentation review; it does not establish a successful installation.