Why the Factory Use Case Must Come Before the Robot Platform

Humanoid robots create attention because the machine is visible. The use case is less visible, but it determines whether the project produces anything beyond a demonstration.

A platform-first process usually starts with a question such as: Where can we put this robot? That framing encourages the team to reshape a convenient task around hardware that has already been chosen. A use-case-first process asks a different question: Which operational problem is valuable enough to solve, and which architecture solves it with the least unacceptable risk?

Start with an operational symptom

A credible candidate normally has a specific trigger:

• a constrained material-flow step;
• an ergonomic or safety exposure;
• a capacity bottleneck;
• persistent staffing difficulty;
• high variation that makes dedicated automation uneconomic;
• a brownfield environment that is expensive to redesign.

The trigger is not yet a business case. It identifies where investigation may be justified.

Define the task boundary

“Handle parts” is not an application definition. A useful boundary states the start condition, expected end condition, variants, operating environment and exceptions. It also separates the robot's task from upstream and downstream responsibilities.

For example, loading one family of parts into three existing machines is materially different from “autonomous machine tending.” The bounded version can be observed, measured and tested. The broad version hides dozens of decisions.

Compare architectures honestly

Humanoid morphology may add value when locomotion and manipulation are both required in a human-designed workspace. It is less compelling when the task is fast, fixed and repetitive.

Compare at least:

The aim is not to prove that a humanoid can move. It is to determine which system produces acceptable work with supportable risk.

Define evidence before testing

Agree what would make the pilot continue, change or stop. Evidence may include task-completion rate, interventions per shift, cycle time, availability, supported variants, safe recovery and a sustained operating period.

This prevents the team from moving the goalposts after an attractive demonstration. It also gives Operations, Finance, Safety and IT a concrete basis for approval.

The practical sequence

1. Identify the valuable operational problem.
2. Bound one task and its environment.
3. Compare viable robot architectures.
4. Validate the critical assumptions.
5. Define a production pilot with written acceptance criteria.

Platform selection belongs in the process—but it belongs after the task has earned serious investigation.