How we research and review the catalog

Published September 29, 2026

We want readers to understand what a robot or robotics project enables, what it takes to use it and what evidence supports its claims. We can research a useful profile before testing the project ourselves. We make that distinction explicit.

Selection

We consider physical robots and robotics projects relevant to building, running, modifying or reproducing robotics work. We identify the upstream project and check for duplicates before collecting details. Different suppliers' kits normally belong to the same robot entry; materially different designs may deserve separate entries.

An entry needs identifiable source artifacts and an explanation of its openness. We can include partially open or restricted source-available projects with a visible breakdown. Unresolved cases remain in research; a vendor's “open” description alone does not establish inclusion. We do not use repository popularity as a substitute for suitability or reliability.

Research and attribution

We start with upstream documentation, repositories, releases, design files, licenses and bills of materials. Vendor pages support that vendor's price and availability. Secondary reporting is identified as such. We inspect the source supporting a claim rather than treating a search snippet as verification.

Each sourced claim records its source, check date and relevant version or location. Public references identify the publisher or author when established, link to the material and show when it was accessed. Automated retrieval and editorial checking are separate events. API-derived information retains its provider and field provenance, with a usable public commit or release link where available.

We summarize in our own words. Reused media needs its own creator credit and documented reuse basis; a source citation alone does not establish permission. Missing or contradictory evidence stays visible. Estimates explain their inputs and assumptions.

What our evidence labels mean

Source researched: cited information has been checked against the identified source. This does not establish that the project works as described.

Setup reproduced: this label requires a linked experiment recording exact hardware/software, instructions followed, deviations and the result of a named task. It applies only to that configuration and task.

Performance tested: this label requires a linked test report describing the metric, equipment, conditions, repetitions, outcomes and limitations. One successful demonstration is not a general performance benchmark.

The last two labels are proposed publication standards, not automatically assigned by current catalog tooling. An entry can contain both upstream reports and our observations. We identify which is which; testing one aspect does not verify the whole entry. Reader reports remain reader reports.

Costs and compatibility

A price belongs to a specific configuration and offer. We distinguish a vendor quote, a parts estimate and our measured build expenditure. We record currency, region, quantities, inclusions, exclusions, tax/shipping treatment, availability and check date. We do not add incompatible configurations into a total or present missing costs as zero.

Compatibility needs a source and version context. A shared ecosystem tag does not establish that two projects work together. Computer requirements, paid services and required peripherals should be visible where they affect reaching a first result.

Review and automation

Automation may help collect, organize, draft and lint content. It does not establish source truth or replace accountable editorial review. Our LLM editorial review assesses usefulness, specificity, repetition and whether the supplied evidence supports the wording. It must identify uncertain or missing evidence and cannot approve publication.

Our publication requirements cover sources, scope, uncertainty, attribution, costs and wording. Current source review is Codex-assisted; structural checks and a content linter enforce the recorded publication checks. The entries are drafted with Codex assistance and checked in a separate LLM invocation against an explicit evidence packet. This is not an independent human technical review. Full editorial calibration remains in progress. Articles should add practical value beyond paraphrasing an upstream README: for example, reconcile requirements, clarify a budget or explain a documented limitation.

We record actual author and reviewer roles. We do not invent firsthand experience to make an article sound personal. Commercial relationships, sponsorships and affiliate links must be disclosed where applicable. An offer to sell parts is separate from the evidence supporting a finding; payment must not purchase a favorable conclusion.

Maintenance and corrections

Our proposed refresh targets are to review offers within 30 days of publication and project activity/compatibility within 90 days, or sooner when a significant change or credible correction arrives. These are editorial targets; no automatic monitoring service is currently enabled.

We show source-check and profile-edit dates separately. Material corrections update the affected claim and change history. Quiet repositories are not automatically abandoned, and overdue checks do not prove a project is broken.

There is no correction submission channel yet. When one is available, we intend to review source-backed submissions before changing published facts and keep community testimony distinct from our own experiments.