Signal Quality

Every measurement carries a required quality object. It is the single reliability signal you react to — it tells you how much to trust the whole capture, before you show any metric to the user.

The quality object

quality is always present and never null:

"quality": {
  "level": "good",   // "good" | "fair" | "poor"
  "score": 0.82,     // number 0..1, two decimals
  "usable": true     // boolean — true for good/fair, false for poor
}

How to read it

• good — a clean capture. Present the metrics normally.
• fair — usable, but noisier. Consider a subtle "measurement was a bit noisy" hint and prefer a re-measure for critical use.
• poor — the capture is not usable. Ask the user to re-measure. Metric values may be null in this case (see below).

The recommended gate is quality.usable:

if (!result.quality.usable) {
  showRetryPrompt();        // poor capture — don't present numbers
} else {
  renderMetrics(result);    // good or fair
}

Null-out-below-floor

neccessory does not fabricate numbers. Any metric whose contributing signal fell below the reliability floor is returned as null (the field is always present, the value is null) rather than a guessed value. When quality.level is poor, all numeric metric values may be null.

Always handle null: hide or dim the field rather than rendering a blank or a zero.

Per-metric confidence

Some metrics also carry their own confidence (0..1) — today heart rate, blood pressure, and SpO2. Where the SDK has no per-metric confidence signal, that field is simply omitted; the metric still inherits trust from the top-level quality.

Show live feedback

During a measurement, the SDK surfaces the current quality level so you can guide the user in real time — a low level usually means an actionable problem (motion, poor lighting, or distance). Pair it with the guidance in Requirements to tell the user what to fix.

See the measurement result for the full JSON shape.