How we review content
We separate official definitions, community project facts, and editorial interpretation so important claims can be traced to public evidence.
- 01
Prefer primary sources
Model capabilities and interfaces are checked against TypeSafe documentation, public releases, and source code. Third-party summaries are not presented as official claims.
- 02
Pin source evidence
The project radar prefers links to specific files, commits, or stable evidence. “Reviewed” means public evidence was checked; it is not a performance, safety, or commercial endorsement.
- 03
State uncertainty
Anything not confirmed by public evidence is labeled accordingly. Confidence, thresholds, and example outputs are never described as guaranteed accuracy.
- 04
Protect researched search language
Human-reviewed titles, keywords, and terminology are maintained separately and cannot be overwritten by automated translation. Locales without native review remain noindex.
- 05
Accept corrections
Corrections to ownership, licenses, data, or interpretation can be submitted with evidence through the contact page. Confirmed corrections are reflected in the page and data snapshot.
Directory size is not review depth
The directory contains 1428 records, including 349 entries marked as source reviewed and 74 projects with published detail URLs. Publication, source review and independent reproduction are different claims.
- E0 · catalogued
- A public name and link are recorded; implementation is not reviewed.
- E1 · source linked
- Public material is attached, but fixed-version review is incomplete.
- E2 · source reviewed
- Public material or source evidence was checked. For articles this means reading the original, not verifying source code. A pinned-source review requires a specific revision and scope; this is not an independent run or performance endorsement.
- E3 · independently reproduced
- This site ran a public protocol and disclosed the environment, inputs, outputs, results, and limitations. No project currently has this level.
What should a project analysis help you decide?
An analysis should explain the reader’s task, how input reaches the decision layer, how an answer becomes an action, implementation details that are easy to misread, when another approach fits better, and how to check the conclusion. Findings link to their sources; author-reported results and unexecuted instructions are identified.
Existing detail URLs are preserved. New publication requires an explicit editorial decision rather than a star, source-count or character threshold. Length is not evidence of depth, and a catalog summary is not called a complete review. Unavailable sources retain an explicit historical boundary rather than a claim of successful rechecking.
What qualifies as an independent test here?
Without API access, raw outputs, and a repeatable environment, this site will not publish invented latency, cost, or accuracy figures. A future Jev test must disclose all of the following:
- Test date, SDK version, model identifier, and runtime environment
- Downloadable inputs, question definitions, and deterministic preprocessing code
- Raw responses, failures, retries, and exclusion rules
- Latency distribution, cost calculation, human labels, and evaluation metrics
- Scope, unsupported conclusions, and reproduction steps
Current status: No independent Jev benchmark has been published by this site, so project evidence currently stops at E2. The calibration report recalculates external public outputs and does not upgrade them to E3.