⚠ Under heavy construction

As of July 11, 2026, Sorter V2 is not yet in a position to be built.

The documentation that exists is incomplete. Any given page may be accurate, inaccurate, present only as an example, or badly out of date. We do not yet recommend that anyone attempt to build Sorter.

For the most live updates on our progress, join our Discord ↗.

Research & Contributor References

Lab

The lab is where we keep durable findings from hands-on research and the contributor references the rest of the project builds on.

Research areas

Object detection research

Which detector runtimes we validated, where the canonical artifacts live, the cross-device benchmark workflow, and the Raspberry Pi 5 Hailo HEF compile path.

C-channel singulation

How the sorter separates tangled LEGO into single pieces using rotating C-shaped channels — a novel approach with no known published precedent.

Classification research

Embeddings vs classifiers, the Brickognize API, training data strategy, and why color detection avoids ML entirely.

Feeder experiments

Turntable, vibration, and chute experiments that preceded the C-channel design — what was tested, what failed, and what the data showed.

Software architecture decisions

Why the project uses a dumb-firmware / smart-host split, what alternatives were evaluated, and the design principles behind the stack.

Design system

How the SorterOS UI, Hive, and this documentation site look and are built: the rules, and the components to copy. A contributor reference, run from the repository.

What counts as lab content

The lab sits one level below the end-user-facing sections. Content lands here when:

  • it's a contributor reference the rest of the project builds on but that an operator would never need to read (the software architecture decisions);
  • it's an active research thread where we're still validating conclusions, and the findings aren't ready to be promoted into a stable hardware or SorterOS docs page (the object detection work).

Once a finding stabilizes enough to be promoted — for example, when we settle on a single accelerated deployment path and it belongs in the SorterOS setup docs — it graduates out of the lab into the appropriate top-level section.

Artifact policy

The durable rule across all lab work:

  1. Keep decisions and workflows in checked-in Markdown on these pages.
  2. Keep only the latest canonical benchmark and compile artifacts under software/sorter/backend/blob/.
  3. Regenerate reports from benchmark JSONs instead of treating every HTML file as permanent.
  4. Promote a finding out of the lab only after it has both a quality comparison against a reference and a sustained-throughput measurement.