Task Redefinition
Changing what a system is asked to do so that it becomes tractable, which is how most successful automation actually happened.
When not to use it
- As a criticism. Redefinition is legitimate engineering and usually the reason a system exists at all.
- To describe all engineering, which would make the term uninformative. The test is whether a specific sub-task or tolerance was changed, not whether the solution differs from the naive one.
- Where the specification genuinely did not move, in which case the capability claim stands as made.
Reach for something else instead
- Capability improvement — meet the original specification, which is what the research frontier attempts and what deployment rarely waits for.
- Human-machine division — assign the non-negotiable part to a person, which is teleoperation and shared autonomy.
Further reading
- International Federation of Robotics, World Robotics 2025 — the installed base that environment engineering produced.
- Kusano et al. (2025), Comparison of Waymo Rider-Only crash rates by crash type to human benchmarks at 56.7 million miles — domain narrowing, and a benchmark correctly adjusted to it.
Primary sources, listed so you can check the claims on this page rather than take them on trust.
Where people go wrong
- Reading a deployment as evidence for the original, harder task.
- Treating disclosure of redefinition as a weakness rather than as the information needed to interpret the result.
- Assuming a redefinition available in one domain transfers to another; breeding a crop has no analogue in most settings.
At a glance
Where this sits
A starting point. Nothing needs to come before it.
Computed from the prerequisite graph, not assigned. How this works