How to read a catalog entry
Published September 29, 2026 · Open Spec v0.5.0-draft.1 · Approved pilot prerelease
Our catalog has two formats. A robot entry describes a physical device or buildable design. A robotics project entry describes software, tools, models, datasets or simulation. “Open Spec” is our working profile format, not a certification.
Start with the entry's purpose, intended user, requirements, cost scope and evidence status. The detailed specification and references explain the basis for those summaries. A researched listing does not mean we have built or tested it.
Physical robots
Robot entries cover form, capabilities, hardware and software, source availability, tools, assembly, calibration, maintenance and a route to a first task. Measurements need units and a configuration: a payload figure without reach or test conditions may not be useful for comparison.
Prices describe a particular offer or estimate. We distinguish parts, kits, assembled robots and first-working-setup budgets. Read the currency, region, quantity, included parts, exclusions and check date. An arm kit without a camera or printed parts is not directly comparable with a complete experiment setup. Unknown delivered cost stays unknown.
Robotics projects
Project entries cover the project's role, supported workflows, inputs and outputs, hardware compatibility, installation, dependencies and compute requirements. Libraries and frameworks can serve several purposes; their primary category describes the main role, with tags for other capabilities.
A software license does not imply free training, hardware or hosted services. Where we report operating costs, we identify the workload and assumptions.
Evidence and openness
Source researched means we checked cited information, not that we ran the project. Setup reproduced and Performance tested are proposed publication standards: they would require linked experiments for a named configuration and task, with measurements for performance claims. Current tooling does not automatically assign those labels. They are distinct from the status of each individual claim.
Claims are reported from a source, observed by us, inferred with an explanation, conflicting, unknown or not applicable. Sources appear beside claims and in the references. For conflicts, we explain the alternatives rather than averaging them or choosing silently.
We assess source artifacts separately: mechanical design, electronics, firmware, software, model weights, datasets and documentation, as applicable. Available files and permission to reuse those files are different questions. A repository's root license does not automatically establish the status of every component.
Entries may describe partially open or restricted source-available projects, with the limitations stated. Inclusion is not an endorsement or a claim of unrestricted reuse.
Dates, navigation and discussion
An upstream activity date describes the cited repository or artifact. A release date, profile edit date, source-check date and price-check date answer different questions. A new comment or site deployment does not make old evidence current.
Categories describe what an entry is. Capability, use-case and ecosystem tags help readers find relevant entries. Documented compatibility is distinct from suggestions to explore similar projects.
Community build and usage reports are attributed reader experiences. They do not count as our own testing. Discussion availability is shown on each entry; no activity counts are invented.
Read the methodology for how claims are reviewed and the contribution guide to prepare a correction or project suggestion. Submission and discussion services are not yet enabled.
Changes
- September 29, 2026: first public pilot using v0.5.0-draft.1, including configuration, activity scope and attribution. The spec is still a prerelease contract.
Versioned contract
The initial collection uses an approved pilot prerelease. Read 0.5.0-draft.1 for field definitions and versioning boundaries.