What qualifies for the catalog?

Published October 17, 2026 · Selection guide for Open Spec 0.7.0-draft.5

A project earns a standalone entry by giving a reader a concrete, inspectable contribution to robotics. Repository stars, downloads, followers, academic citation counts, company size, funding and publicity do not establish eligibility. A small student project and a large laboratory release face the same questions.

This guide explains the existing scope, evidence and editorial review in Open Spec and our methodology. It does not change the record format or certify existing entries against a new checklist. Inclusion means the documented contribution is worth understanding; it does not mean we have built it, run it, verified its performance or endorsed its use.

Five questions for every candidate

Review the project at an identified revision and for a stated purpose. Record the evidence and reasoning for each answer; do not turn the answers into a popularity score or average away a missing core artifact.

Question	Evidence that supports inclusion	When the answer is insufficient
What robotics task does it enable?	A specific contribution to building, sensing, planning, controlling, simulating, learning, evaluating, repairing or operating robots; or a defined educational exercise in those activities.	Robotics appears only in marketing, a keyword list or one downstream dependency chain.
What can the reader actually inspect or use?	Accessible design files, implementation source, models or data that support the contribution being described. Inspect their contents and version, not just their filenames.	A paper, video, product page, binary installer, API endpoint or promised future release is the only evidence for the claimed contribution.
Is there a useful, bounded next step?	Enough information to inspect a design, attempt a documented workflow, reproduce an experiment, adapt a component or understand a specific limitation. State prerequisites and important gaps.	The proposed entry would repeat an announcement without helping a reader make or investigate a robotics decision.
Does it merit a separate entry?	An identifiable project or materially distinct design, implementation, interface, dataset or workflow with its own reader value.	A mirror, renamed repository, packaging-only fork, thin wrapper or starter skeleton adds no separately explainable contribution. Keep the relationship with its parent.
Can we describe its scope and rights honestly?	Sources identify the artifacts, limitations and applicable licenses or restrictions. Separate unavailable, not found, unlicensed and not applicable layers.	The central contribution or its identity cannot be established, or a useful description would depend on unsupported claims. Hold the entry rather than infer the missing facts.

A project does not need to be novel, better than alternatives, commercially supported, inexpensive, actively marketed or physically tested by us. A complete, quiet project may be useful. An experimental project may qualify for a narrow research purpose. Neither age nor recent commits establish reliability.

Hardware: the design contribution matters

Hardware entries cover complete robots, end effectors and standalone components, including actuators, controllers, sensors and teleoperation devices. The contribution must be physical: an inspectable design for a robot or a component with a documented robotics function. Name the exact configuration and say whether the entry covers a whole system, a component, an adaptation or a design reference.

Look for the artifacts appropriate to that contribution: CAD or dimensioned drawings for a mechanism; schematics and board design files for electronics; firmware source for programmable behavior; and bills of materials, fabrication, assembly, wiring and calibration information where supplied. No single file format is mandatory. A printable mesh can be useful, but is not equivalent to editable parametric CAD. A STEP component is not automatically a complete assembly. A Git LFS pointer is not the design payload.

The completeness of the claim must match the completeness of the evidence:

Complete-build scope: explain the documented path through parts, fabrication, assembly and first use. Disclose missing purchased components, instructions and configuration-specific costs. Do not call a build complete if a central dependency cannot be identified.
Component or adaptation scope: the component has a defined purpose and interface. Bought-in motors, arms or computers do not disqualify the design, but their availability and rights do not become open because the adapter is open.
Design-reference scope: real, useful design material exists, but a complete build path is unestablished. Describe what can be inspected and what is missing; do not imply buildability, fit or operation has been verified.

An SDK or URDF/MJCF simulation model alone does not establish open hardware. It may qualify as software or a model under the software criteria. A commercial robot with an open SDK is not thereby an open mechanical design. A published custom gripper for that robot may independently qualify as hardware.

A missing current price is a budget gap, not automatic rejection. A missing assembly guide may limit an entry to a useful design reference. If the actual design contribution itself cannot be inspected, keep the candidate on hold with a specific evidence request.

Software, models and datasets: a library can be a robotics project

Judge the released capability, not whether its repository is called a library, framework, tool or research project. Robot-specific inverse kinematics, motion planning, mapping, control, middleware, teleoperation, simulation and evaluation can merit standalone entries. An SDK can qualify for its inspectable robot interface even when the hardware it controls is proprietary; disclose prebuilt components and the boundary of the released implementation.

For implementation projects, identify a concrete workflow: inputs, processing or robot interaction, outputs, dependencies and the documented starting point. Inspect implementation source for the capability being profiled. Installation commands, examples or bindings around a closed core do not establish that the core is available. A useful exposed interface may be profiled narrowly, without presenting it as a released engine.

For models, identify the actual artifact, its intended robotics task, required code or runtime and access/reuse conditions. For datasets, inspect the data or a meaningful accessible sample, its schema, collection or generation context, intended robotics use and access terms. Do not imply the full dataset was inspected from a sample. Code that uses a model does not establish that its weights are available; a paper announcing a dataset does not establish released data. No single paper, benchmark or adoption threshold is required.

For simulation, state what is modeled, what task it supports and what fidelity or transfer claims are evidenced. A simulation result is not a physical robot result. For educational projects, a bounded exercise with inspectable source and a learning outcome can be sufficient; production readiness is not required.

General mathematics, graphics, networking, packaging and utility libraries do not qualify merely because a robot stack imports them. A broad tool can qualify when its own released artifacts support a substantial, identifiable robotics workflow. Human-motion reconstruction or animation can be relevant adjacent research, but a plausible future use in robotics is weaker than a documented robot-facing contribution. Keep useful dependencies linked even when they do not merit standalone pages.

Eligibility and openness are separate decisions

The catalog can describe open, partially open and restricted source-available work. We do not describe them all as fully open source. Assess mechanical designs, electronics, firmware, software, weights, datasets and documentation separately as applicable.

A license applies to identified artifacts, not automatically to every file, purchased part or linked service. Noncommercial terms, conflicting declarations and missing licenses stay visible. Public access is not permission to reuse. Unresolved rights may support a narrowly described source-available reference, but do not justify distributing its CAD, code, photographs or other media. If the uncertainty prevents an honest account of the central contribution, hold the candidate.

Full openness cannot rescue an irrelevant or empty project. A useful robotics contribution cannot excuse false claims about source access or licensing.

Record a decision, not just a yes or no

Editorial outcome	What happens next
Include for full profile review	Record the contribution, scope, supporting sources and limitations. Continue through source, schema, editorial and publication checks. Eligibility alone is not publication approval.
Include with a narrower scope	Identify the component, interface or design reference that is actually supported. Make the missing system-level evidence prominent.
Keep as a related reference	Preserve the dependency or companion link and exact fork/version where relevant. Do not create a redundant standalone profile.
Hold for evidence	State what is missing and what evidence would reopen review, such as actual CAD payloads, implementation source or a resolved identity. A failed download is not proof that no source exists.
Exclude from standalone catalog scope	Explain the substantive mismatch, such as no identifiable robotics contribution or only a promotional listing. Reconsider if the released contribution changes.

These are editorial explanations, not new record status values. In Open Spec, inclusion and openness are recorded through scope_decision, scope_rationale, the applicable source layers and the review decision. Private intake keeps the operational queue. A reference, hold or exclusion must preserve its reason; none should silently become a published profile.

Borderline examples

Candidate evidence	Decision and reason
Zero-star inverse-kinematics implementation with a documented robot example	Can qualify: inspectable robotics capability. The star count contributes nothing to the decision.
Widely used general-purpose array helper imported by a robot stack	Related reference unless its own released contribution establishes a distinct robotics workflow.
Gripper CAD, an arm interface and assembly notes, using purchased servos	Can qualify as a gripper design; do not infer that the servo hardware is open.
Humanoid SDK and visualization meshes, with no manufacturing design identified	Consider the SDK/model separately; hold the proposed hardware-design entry.
Actual mechanical drawings with no complete BOM or commissioning procedure	Can qualify as a useful design reference, not a verified complete robot build.
Fork with a documented robot-specific controller or materially different hardware support	Can qualify if the distinct contribution warrants its own explanation; preserve the parent and revision relationship.
Renamed repository or wrapper that only forwards calls to an existing project	Resolve the identity or retain as a companion reference; avoid duplicate pages.
Robot demonstration video with a promise to release source later	Hold for actual artifacts; the demonstration does not establish source availability.

Apply the guide consistently

For each decision, preserve the project/revision, intended reader, concrete robotics contribution, inspected artifacts, useful next step, duplicate/parent check, rights and limitations, outcome, reviewer, date and any reopen condition. Use the existing record sources and review rationale; this is not an automated merit score. Structural validation checks recorded evidence, not whether a project is good or whether its claims are true.

Revisit earlier entries when their scope, artifacts or evidence materially change. Publication under an earlier review does not prove that this guide has been reapplied. A change of eligibility policy that adds requirements or changes the meaning of the contract needs an explicit spec revision and migration decision; this guide documents how we explain the existing scope review.

Suggest a project or challenge a decision through contributions and corrections, with links to the artifacts and the specific criterion at issue. New evidence can change a decision; popularity cannot substitute for it.