Your robot data, handled plainly.

Detection runs where you start the CLI. Choose what reaches your workspace per machine under Settings, Robots, or per run with a flag. The report can include cited log and source excerpts. History has three levels: off, incident (the minute around each finding) and full (also a trend and a 10 Hz history of every channel that moved). Machine state has off, code (commit and commit subjects and configuration file hashes, without file contents in the state attachment) and full (also parameter, launch and URDF files).

The recording itself (bag, MCAP, CSV) is never uploaded unless you switch that on for a machine or use --upload-raw. It is off by default.

--no-push skips the run upload. It does not disable model requests or account access checks. Upload settings and model processing are separate choices.

An investigation can send measurements, logs, source and configuration excerpts, and tool results to its configured model endpoint. Managed interpretation currently uses external model providers. With your own provider key, the model request goes directly from the machine running TrialONE to that provider; the resulting explanation can still appear in a report uploaded to your workspace.

Your team can configure a model endpoint on its own network. For a diagnosis without model interpretation, use --no-explain. Use --no-push separately to skip the workspace upload. See model settings and data controls for the setup.

The current pilot watcher can keep a limited recent buffer of supported camera frames on the robot and send selected frames to the configured model during an investigation. Camera context is enabled by default; disable it under Settings, Robots or with --no-camera when it is not appropriate for your pilot.

This feature does not separately store or upload frames with the run. A raw recording can still contain images if you enable its upload. Review both choices if cameras can show people or sensitive work areas.

TrialONE is available by request; every team is approved by hand before it can use the workspace or run the command line tool. A workspace sees only its own runs, issues and settings: every request of the website is filtered by the workspace, and the tables for runs and keys carry row level security policies in the database as well.

Inside a team, owners and admins manage members, robots and connections; members work with issues and runs. Deleting a run is for owners and admins.

A robot pushes with a CLI key; a coding agent reads findings with a separate agent key. Both are shown once and stored only as a SHA-256 hash, so whoever reads the database cannot sign in with what they find. Each key is revoked on its own, and a revoked key is refused on its next request.

From version 0.4.16, trialone login signs a terminal in through the browser with a short code that you type yourself: the page never takes the code from a link, attempts are rate limited, and each approval produces exactly one key. The tool refuses to send a key over plain http to anything but this machine.

You sign in to the website with email and password, Google or GitHub. “Sign out everywhere” under Settings, Profile ends every browser session at once.

The website and its API are served over HTTPS only, with HTTP Strict Transport Security, a content security policy that allows scripts only from this site and a short list of named services, and a policy that forbids embedding these pages elsewhere.

Uploaded history is deleted after the retention period of your workspace, 90 days unless you set another, by a daily cleanup. Runs stay until you delete them.

Under Settings, Profile, “Your data”, you download everything your workspace has with us as one file and delete your account; a single run is deleted from its own page together with its stored files.

What each one receives is listed in the privacy policy.

Write to hello@trialone.infowith “Security” in the subject, and please give us time to fix a problem before you publish it. The same address is in security.txt.