Every metric the platform reports comes from a trace, and every trace was produced by a patient under a setup that was either clean or not. Reviewing a trial before you trust its numbers is a two-minute habit that catches the handful of curves that would otherwise skew a patient's history. This article is the overview: how to read a single trial, how to move between trials in a session, and how to decide what to do. The two follow-on articles cover the mechanics of the two edits you can make.
Reading a single trial
Open a session and look at the curve first, then the numbers. The order matters, because the curve tells you whether the numbers mean anything.
The curve. A trustworthy trial starts from a quiet baseline, rises off it cleanly at a single identifiable onset, and behaves the way its contraction type should: a sustained plateau for an MVIC, a fast rise and fall for an RTD effort, a steady band for a submaximal hold. The onset marker, the plateau shading, and the rate-of-development windows are drawn on the curve so you can see exactly which samples each metric was computed from. If the onset marker is not where the real climb begins, every time-referenced metric below it is suspect until you fix it.
The metric tiles. Each tile carries a short definition on its info icon and, where relevant, a confidence badge. A badge on the rate-of-development tiles reflects how many real samples fell inside the short early window, which is a function of your device's sample rate. A badge on the steadiness tiles reflects how finely the device resolved force during the plateau. These badges do not mean a value is wrong. They mean the value was computed from a signal that limits its precision, and it should be read with that in mind.
The warnings. If the detector saw a countermovement dip before the rise, or baseline drift consistent with the device needing a re-tare, it says so in the warnings on the session. Those are the two most common reasons an otherwise normal-looking peak sits on top of an untrustworthy rise.
Moving between trials
A session holds every trial you captured for that limb, joint, and action. Step through them rather than looking only at the first. A patient who produced one clean effort and two messy ones should have the messy ones handled, not averaged in silently. Trials that carry notes are flagged as you move through them, so a reminder you left during capture ("strap slipped on this one") is visible at review time.
Reviewing the set as a whole also tells you something a single trial cannot: whether the patient's efforts were consistent. Three trials that agree are a stronger number than three that scatter, and a scattered set is usually a cue to look at setup rather than at the patient.
Deciding what a trial needs
Once you have read a trial, it falls into one of four outcomes.
Keep it. The curve is clean and the onset is right. Most trials on a good setup land here. Do nothing.
Fix the onset. The curve is real but the onset marker is in the wrong place, sitting late on the steep part of a rise that started earlier, or early on a false start before the real effort. The peak and plateau are still fine, but the rate-of-development windows are anchored wrong. A single click on the chart resets the onset and recomputes every downstream metric, and the original detection is preserved for audit. The mechanics are in Correcting the auto-detected onset.
Exclude it. The effort itself does not represent the patient: a countermovement you cannot cleanly correct, a plateau that drifts because the patient could not hold, a submaximal effort where a maximum was asked for. Excluding pulls the trial out of the patient's aggregates and symmetry calculations but keeps it on the record, so the history still shows that the trial happened and why it did not count.
Delete it. The trial is not a record of the patient at all: a test pull while you set up, a bumped strap, a device glitch. Deleting removes it from the session. The line between exclude and delete is whether the trial is a real but unrepresentative effort (exclude) or not an effort at all (delete), and it is worth getting right because excluded trials stay auditable while deleted ones do not. When to exclude a trial, and when to delete instead walks through the common cases.
What to do next
- Make trial review a fixed step after every capture, before you generate a report or read a trend. It is faster than re-testing later when a number looks wrong.
- When a trial is borderline, prefer correcting the onset over excluding, and prefer excluding over deleting. Each step keeps more information on the record than the next.
- If a whole set scatters, treat it as a setup signal and re-run rather than editing your way to a clean average.