Device Reliability

Overview

Device Reliability reports whether Junction has been receiving data consistently for each provider, source type, and resource connected to a user. A complete dataset and one missing most days each week look identical downstream. Device Reliability makes that difference visible, so you can decide how much to trust a user’s data before feeding it into a risk model or clinical workflow, and detect when a device has gone quiet. The reliability table returns the latest 30-day snapshot. An ungrouped query contains one row per user for each monitored combination of:

source_provider
source_type
resource

Each row includes coverage, gap, and recency diagnostics; a reliability_status; and the provider’s current connection_status.

Device Reliability is available only through Continuous Query. You cannot use the reliability table with the synchronous Query API, even though Reliability expressions appear in the shared Query DSL schema.

How the snapshot works

Each snapshot covers exactly 30 completed floating calendar days, including both window_start_date and window_end_date:

window_start_date = window_end_date - 29 days

The window fields are returned in every row. Use them to identify the dates represented by a result rather than assuming a particular refresh time. Creating a Device Reliability Continuous Query queues its initial snapshot. Junction then refreshes it daily. Each refresh updates the current result table; it does not append a history of earlier windows.

Available columns

Column	Type	Nullable	Meaning
`source_provider`	String	No	Provider slug, such as `oura` or `garmin`.
`source_type`	String	No	Source type associated with the provider data.
`resource`	String	No	Junction resource being monitored.
`window_start_date`	Date	No	First calendar date included in the snapshot.
`window_end_date`	Date	No	Last calendar date included in the snapshot.
`window_duration_day`	Integer	No	Number of calendar days in the snapshot. This is always `30`.
`presence_day_count`	Integer	No	Number of distinct dates with at least one normalized record or sample.
`presence_coverage`	Number	No	Present-date ratio: `presence_day_count / window_duration_day`.
`presence_gap_count`	Integer	No	Number of consecutive missing-date runs, including runs at either edge of the window.
`presence_gap_maximum_day`	Integer	No	Length of the longest consecutive missing-date run.
`presence_recency_day`	Integer	Yes	`window_end_date` minus the most recent present date, in calendar days. This is `0` when data is present on `window_end_date` and `null` when the window has no present date.
`presence_gap_mean_day`	Number	Yes	Mean calendar-day spacing between consecutive present dates; `null` with fewer than two present dates.
`presence_gap_standard_deviation_day`	Number	Yes	Population standard deviation of the calendar-day spacing between consecutive present dates; `null` with fewer than two present dates.
`reliability_status`	String	No	Data-presence classification for the row.
`connection_status`	String	No	Current provider connection status: `connected`, `disconnected`, `paused`, or `error`.

Reliability status

A combination means one source_provider, source_type, and resource for one user. Each status is a plain verdict on the current window:

reliable: Data is arriving consistently. Gaps in the data are meaningful.
degraded: Data is arriving, but with enough missing days to warrant caution in coverage-sensitive use cases.
sparse_by_pattern: Data arrives intermittently but recently. This often reflects an occasionally used device, such as a smart scale, rather than a failure.
stale: The combination produced data before and has gone quiet. Prompt the user to sync or reconnect.
insufficient_history: Data for the combination has not yet been observed.

Junction assigns reliability_status by evaluating the following rules in order. The first matching rule wins.

Order	Condition	Status
1	No observation history has been recorded for the combination.	`insufficient_history`
2	The combination was observed previously, but the current window has zero present dates.	`stale`
3	`presence_recency_day` is at least `12`.	`stale`
4	`presence_coverage` is below `0.5` and `presence_recency_day` is at most `3`.	`sparse_by_pattern`
5	`presence_coverage` is below `0.7`.	`degraded`
6	None of the preceding conditions match.	`reliable`

connection_status is reported separately and does not change reliability_status. For example, a disconnected provider can retain a reliability classification based on presence during the current window.

Create a Device Reliability query

The following example selects the complete Device Reliability snapshot and uses a customer-owned device-reliability slug.

import vitalx.aggregation as va

query = va.select(
    va.Reliability.col("source_provider"),
    va.Reliability.col("source_type"),
    va.Reliability.col("resource"),
    va.Reliability.col("window_start_date"),
    va.Reliability.col("window_end_date"),
    va.Reliability.col("window_duration_day"),
    va.Reliability.col("presence_day_count"),
    va.Reliability.col("presence_coverage"),
    va.Reliability.col("presence_gap_count"),
    va.Reliability.col("presence_gap_maximum_day"),
    va.Reliability.col("presence_recency_day"),
    va.Reliability.col("presence_gap_mean_day"),
    va.Reliability.col("presence_gap_standard_deviation_day"),
    va.Reliability.col("reliability_status"),
    va.Reliability.col("connection_status"),
).finalize()

continuous_query = {
    "slug": "device-reliability",
    "title": "Device Reliability",
    "query": query.model_dump(mode="json", exclude_none=True),
}

{
  "slug": "device-reliability",
  "title": "Device Reliability",
  "query": {
    "select": [
      { "reliability": "source_provider" },
      { "reliability": "source_type" },
      { "reliability": "resource" },
      { "reliability": "window_start_date" },
      { "reliability": "window_end_date" },
      { "reliability": "window_duration_day" },
      { "reliability": "presence_day_count" },
      { "reliability": "presence_coverage" },
      { "reliability": "presence_gap_count" },
      { "reliability": "presence_gap_maximum_day" },
      { "reliability": "presence_recency_day" },
      { "reliability": "presence_gap_mean_day" },
      { "reliability": "presence_gap_standard_deviation_day" },
      { "reliability": "reliability_status" },
      { "reliability": "connection_status" }
    ]
  }
}

Query rules

Device Reliability uses direct identity columns rather than time buckets:

An ungrouped query must directly select source_provider, source_type, and resource. It can also select any other Reliability columns.
A grouped query must group by a unique, non-empty subset of source_provider, source_type, and resource, and it must select every group key. Other selected expressions must be aggregates over Reliability columns.
A where clause can filter only source_provider, source_type, and resource.
A Reliability query cannot reference another table.

Device Reliability does not support a DateTrunc or index expression, filters over calculated values, cross-table joins, ALIGN or carry, FHIR export, provider priority overrides, configurable windows, or historical result snapshots.

Aggregate by provider

The following grouped query returns the lowest sleep coverage per provider for each user:

import vitalx.aggregation as va

query = (
    va.select(
        va.group_key("*"),
        va.Reliability.col("presence_coverage").min(),
    )
    .group_by(
        va.Reliability.col("source_provider"),
    )
    .where("resource = 'sleep'")
    .finalize()
)

{
  "select": [
    { "group_key": "*" },
    { "func": "min", "arg": { "reliability": "presence_coverage" } }
  ],
  "group_by": [
    { "reliability": "source_provider" }
  ],
  "where": "resource = 'sleep'"
}

The result contains group_key.0 for source_provider and min for the lowest presence_coverage across that provider’s source types.

Limitations

Presence means that at least one normalized record or sample exists on a date. It does not measure whether optional fields are complete, and a real numeric zero counts as present.
Reliability thresholds are cadence-agnostic. Healthy episodic, weekly, or monthly resources can therefore be classified as sparse_by_pattern, degraded, or stale.
Expected resources are determined per provider, not per device model. A provider and source-type combination may therefore show insufficient_history for resources its specific device never produces—for example, a smart scale may be listed with insufficient_history for sleep. A row leaves insufficient_history once Junction has observed that resource for the same provider and source type at least once.
Device Reliability excludes profile, device, device_legacy, workout_stream, hypnogram, and sleep_stream.

Junction Sense

Query DSL

Python SDK

Device Reliability

Overview

How the snapshot works

Available columns

Reliability status

Create a Device Reliability query

Query rules

Aggregate by provider

Limitations

​Overview

​How the snapshot works

​Available columns

​Reliability status

​Create a Device Reliability query

​Query rules

​Aggregate by provider

​Limitations

Overview

How the snapshot works

Available columns

Reliability status

Create a Device Reliability query

Query rules

Aggregate by provider

Limitations