Remembering earlier incidents

TrialONE 0.4.21 and later keep a local case history for named robots. It can show whether similar evidence appeared before, what your team reported changing and how the follow-up turned out. This helps avoid repeating a repair that already failed.

Use a stable robot name

Pass the same --machine name for every diagnosis of this robot, or set TRIALONE_MACHINE. Different robots analysed on the same laptop should have different names.

$ trialone diagnose ./before.mcap --machine amr-01 --json ./before.json

Record the change you actually made

After applying a change, record it against the finding. repair stores your description; it does not modify code or hardware. When a diagnosis has several findings, select the finding ID from its JSON.

$ trialone repair ./before.json --finding <finding-id> --change "Changed the subscriber QoS configuration" --project ./robot_ws

Attach the follow-up

Use the repair ID printed by the previous command to link a fresh recording to this attempt. Keep the same healthy reference and false-alarm settings if you used them for the original diagnosis.

$ trialone verify ./before.json ./after.mcap --attempt <repair-id> --json ./verification.json$ trialone cases --machine amr-01

What the history establishes

The history preserves reported changes and passing, failing or inconclusive follow-ups. A repeated symptom is a lead for the next investigation, not proof of an identical cause. An applied change is your team's report; a checkout or commit alone is not independent deployment evidence.

This history is stored locally in TRIALONE_HOME, normally ~/.trialone, and has no separate cloud sync. Related metadata can be included when a diagnosis is uploaded to your workspace. It is separate from model training and from the workspace issue list. See Data and model processing.