The first 100 hours

On the first day of a pilot, everyone watches the robot. After a while, something more interesting happens: people begin returning to their own work. That is when the real test comes into focus. We can see how the work around the system continues, as well as what the system itself does.

“The first 100 hours” is an observation framework proposed by GappAI Review. It is not a standard, a safety certification or a sufficient test duration for every application. Nor does this article report results from a completed GappAI pilot. Its purpose is to turn a field trial into a record that supports decisions, extending evaluation beyond its most impressive moments.

Before the clock starts: what will we observe?

Define what the clock counts. We suggest tracking the total time during preselected operating windows in which the robot is expected to perform its task. Waiting and interruptions within that window remain in the record; active task time is recorded separately. Counting only the minutes that run smoothly gives an incomplete picture of the operation.

Record setup, training and development time separately as well. Distinguishing them from operating performance should not make the effort an investment requires invisible. Task definitions, test conditions, safe operating limits and authority to stop the system must be clear before the trial begins. A field pilot does not replace that preparation.

Observe the task without the robot under conditions that are as comparable as possible. Another shift, a different product group or much lower demand can create a misleading baseline. If the baseline has known gaps, disclose them when interpreting results.

Hours 0–20: meet the real task

The first observation period asks how the system meets its task and environment. Does material arrive in the expected form? Do employees know how to start a job? Is there enough space at the delivery point? Problems may arise from layout or task sequence as well as from the learning model.

Giving every attempt a task identifier helps connect the records. Link starting conditions, software version, start and finish times, outcome and any intervention to the same task. If video is used, define its purpose, access permissions and retention conditions. Selecting the information needed for a decision can be more manageable than recording everything.

Record changes to the task definition explicitly. Switching to lighter boxes or a shorter route may be the right engineering choice. Combining results under those new conditions with an earlier success rate, however, makes it harder to tell what improved.

Hours 20–60: count success and assistance separately

We suggest that the record answer at least three questions. Was the task completed to the required quality? Did completion require human intervention? Did the system remain within its defined operating limits? A task can succeed with help. That useful result belongs in a different category from unassisted completion.

The kind of help matters. A brief employee confirmation, a remote operator taking over a movement and a technician restarting the system create different workloads. Recording duration and reason alongside the number of interventions makes the next improvement easier to target.

For example, a robot that repeatedly waits for a recipient may not need more advanced grasping software. Delivery timing or the task queue may need to change. This illustrative case shows why an error record should help select the right problem, as well as count failures.

NIST's robotics programme addresses performance measurement across capabilities including grasping, perception, motion and working with people. Separating capabilities reminds us that a single overall score can conceal which skill or connection needs development. The 100-hour framework presented here is not a NIST test protocol. ^[1]

Hours 60–100: does improvement survive variation?

Retest the same task after the initial problems have been addressed. Then examine variations within operating limits that have already been assessed: permitted object positions, ordinary changes in demand or work with different authorised users. Improvising a dangerous situation to challenge the system is not a sound field experiment.

Track software versions separately rather than pooling every measurement into one average after each change. This makes it easier to see whether a new release solves one problem while introducing another. Preserve selected, repeatable tasks for comparison.

Ask employees about their experience again. As first-day novelty gives way to ordinary use, the clarity of notifications, training needs and support arrangements may become more apparent. EU-OSHA's work on digitalisation points to the importance of considering technology together with work organisation and human interaction. ^[2]

What belongs on the table at hour 100?

A short, traceable review file can show the operating conditions observed, tasks attempted, outcomes meeting the quality requirement, unassisted completions, intervention time and reasons for downtime. Show long waits alongside average duration; service-disrupting events can disappear inside an average.

Do not infer high certainty from limited observations. Seeing no problem during 100 hours does not prove that a rare event cannot occur. Even hundreds of attempts may cover only a narrow set of conditions. The report should explain what remains untested as clearly as what was observed.

The decision may be to continue, change the scope or stop the trial. If expansion is being considered, identify which conditions will remain the same and which must be verified at a new site. A result in one location is not an automatic guarantee for another building or shift.

At the end of the first 100 hours, the most valuable output may be a more capable robot or a better-defined task. Either can allow the next decision to rest on fewer assumptions. A pilot earns its value by showing the people around it what they now know.