Our method / Editorial standards

A claim should come
with a way to test it.

Our standard is simple: another person should be able to understand what we did, what it cost, and whether it worked.

We’re starting this publication with an explicit method. Our first hardware test is still ahead of us. These are the standards we intend to meet, and the details readers should expect in each build report.

01. Define a useful result.

Before testing, we’ll define the task, operating conditions, trial count, and what counts as success. A selected highlight won’t stand in for a repeatability result.

02. Make the build inspectable.

We’ll record hardware revisions, software versions or commits, operating system, compute requirements, and the complete bill of materials. Setup time includes the steps that didn’t go smoothly.

03. Keep the failures.

Reports will distinguish what we observed from what a manufacturer claims and what we infer. We’ll retain unsuccessful trials, show unresolved issues, and link supporting evidence where practical.

04. Be precise about “open.”

Mechanical files, electronics, firmware, software, model weights, and datasets are separate layers. We’ll link available source files and licenses for each relevant layer, and say when something is unavailable or unverified.

05. Invite reproduction.

A report is the start of a conversation. We’ll use independent build attempts to improve the instructions, record configuration differences, and date corrections when dependencies change.

06. Let the evidence lead the shop.

Readers will be able to source their own parts. Any future bundle should clearly specify its contents, tested configuration, supported result, price, and support scope. We’ll label availability accurately.

We’ll disclose loaned or donated hardware, sponsorships, affiliate links, and our commercial interest in anything we sell. A product’s presence in our shop won’t establish that it performs well.