A successful run shows that a robot completed a task at least once. A failed run can show the condition a builder has not solved. I want a build report to include both, with enough context to compare them.
Describe a failure without theatre
Give the starting condition, the command, and the observed result. If you know the cause, show the check that supports it. If you do not, label the explanation as a hypothesis. Readers can use an unresolved failure when the observation is precise.
Keep the original clip long enough to include the setup and the stop. Add timestamps in the article so the reader can find the event. Avoid editing away the reset and then reporting the remaining sequence as continuous operation.
Give the next builder a test
Include the procedure you will use to judge a revision. A claim of improvement needs the same task and a stated measure. If the revised mechanism changes the test conditions, explain the change instead of treating the two runs as a direct comparison.
A build log does not need a successful ending to deserve publication. It needs a record someone else can inspect. I would rather read a clear account of a grip that slipped than a polished paragraph claiming reliability without a trial count.
Have a correction or a different result? Write to the editor.
