Skip to main content
Every VitalsResult carries a diagnostics object: capture and quality values recorded at the end of the reading. They exist for support and for your own analytics (for example, slicing withheld rates by device model or torch state). They are not user-facing metrics. The native VitalsDiagnostics type exposes each key as a camelCase property and serialises to the snake_case keys below (toDictionary() on iOS, toMap() on Android; the wrappers deliver the snake_case map). Store the whole object with the result; NEUROFIT support will ask for it.
Values in the “engine” group are defined by the engine and can change meaning between engine versions. Treat them as opaque unless NEUROFIT asks for them; do not build product logic on them. engine_version tells you which definitions apply. This page documents the key union and the type of each value; it does not describe how the engine computes them.
Conventions: a numeric -1 means “not available”. Keys marked optional are absent (not -1) when the step that produces them did not run. Platform column: both unless noted.

Provenance

Quality

Quality trajectory

How the signal evolved during the reading, for tuning your guidance and for support.

Capture hardware

The camera’s operating point at the end of the reading. Exposure is fixed during a reading, so this equals the reading’s settings.

Breathing

Engine

Engine-defined values. Opaque; see the note at the top. The three *_enabled keys mirror configuration flags; the rest are the engine’s own features and intermediate values, recorded so that NEUROFIT can reproduce a reading’s outcome from its diagnostics.

Cancel context

cancelled(reason, context) carries a smaller set with the same conventions, describing the moment of the cancel. CancelContext.toDictionary() (iOS) / toMap() (Android) always has these ten keys: reason (contact_lost, low_quality, low_live_signal_quality, no_low_discard_estimate, or your host string), quality_score, elapsed_s, engine, refine_mode, effective_fps, device_model, red_dc, exposure_iso and exposure_tune_steps, with -1 for an absent number; exposure_in_band is added only when it is known. red_dc is the red mean of the last frame (the attempt’s mean is red_dc_mean in the result diagnostics); exposure_tune_steps is always -1 on iOS, which runs auto-exposure. Log it if you want to understand abandoned attempts, which never produce a result.

Using diagnostics in your analytics

Useful slices, in the order they tend to pay off:
  1. Withheld rate by device_model (from your own device info) and effective_fps.
  2. Withheld rate against saturation_frac (users pressing too hard) and amplitude (cold fingers, thick cases).
  3. measured_fps, frame_interval_cv and frame_drop_compliance_error_count on devices that report frameDrop or recoverable errors.
  4. torch_active == false on completed readings, which points at a torch problem on that model.
Keep engine_version and the result’s sdkVersion with every row so definitions can be matched to a release.