Start with the real situation
A useful task brief begins with why the work exists and who normally performs it. It describes the objects, tools, environment and operational sequence without quietly turning a difficult real task into an easy laboratory substitute.
The intended operator matters. A system designed for trained technicians is different from one expected to work beside members of the public. The brief should state the expected supervision, acceptable setup and any skills assumed of the operator.
Define success and exclusion
Success should be observable: an object placed within a tolerance, a tool action completed, a set of items sorted with a stated error condition. The brief should also name exclusion conditions—situations that are outside the test rather than silently removed after a poor result.
Known constraints belong in the brief. Object ranges, lighting limits, workspace access and safety rules all influence what a result means. Changing them changes the task, so revisions should remain visible.
Specify evidence and privacy
The brief should say what evidence is required: video angles, attempt logs, intervention records, configuration notes and observer comments. It should also identify information that cannot be public, such as personal data, confidential layouts or proprietary system details.
Publication permission is not assumed. A public task can still contain protected inputs. RobotBay separates the shareable method and evidence from private commercial information, and publishes only material that has been reviewed and authorized.