Scene history for robot evaluation

The video still exists. The result is in the spreadsheet. But the person who set up the table remembers the detail that makes it meaningful: a camera was moved, an object was substituted, a trial was restarted after an interruption.

When that memory disappears, the record becomes harder to use. A new researcher can watch what happened without knowing enough to ask the same question again.

Prism applies version history to the physical setup. Save a condition, create a revision and keep the resulting episodes connected to both the scene and policy version.

A scene record should connect the intended arrangement with what was observed: object identities, positions, calibration reference and the conditions the task depends on. A trial should point back to that record, not merely to a folder with a familiar name.

A revision then describes a change. The cup moved. The object changed. The lighting arrangement was different. The old condition remains understandable, and the new one explains its relationship to it.

That relationship is the beginning of a useful comparison. It also makes missing information visible: a field can be unknown rather than silently assumed to match.

In a physical experiment, a difference is not just something to display. It is often the reason to run the trial. Did the new policy improve on the old failure? Did changing the object reveal a dependency the team had not noticed?

A useful history would keep the scene change, policy change and rubric change distinct. It would let someone review the evidence for the outcome and understand why a score was revised.

The scene-history walkthrough shows how revisions work using an example scene.

Software can restore bytes exactly. A workcell cannot promise the same thing about friction, wear, exposure or the fold of a cloth. Projected guidance can help restore an arrangement; observation must still establish what was achieved.

This is where the metaphor earns its limits. A scene history should not pretend to freeze the world. It should make the assumptions and tolerances of a reconstruction available for inspection.

The Prism technical brief describes re-projecting a logged condition as a route to physical regression testing. Whether a specific task can be repeated closely enough remains something to measure in that task's setup.

The destination is not a prettier archive. It is a lab where a failure remains findable, a comparison remains explainable and an old experiment can teach someone new.

That asks for more than storage. It asks for names people understand, reasons kept beside decisions, permissions appropriate to the data and a way to say “we do not know” without breaking the workflow.

Explore Prism Robotics, or tell us what your team's physical record is missing.