Testing & Validating Outputs

DSP outputs are only useful if you can trust them. This guide covers the practical tools the platform exposes for validating feature series - both built-in and custom.

Reading the quality mask

Every feature value carries a qmask byte. The mask is the platform's view of how trustworthy that value is:

A common pattern when reporting aggregates:

function meanHR(series: FeatureSeries): number {
  const clean = series.values.filter((_, i) => series.qmask[i] === 0);
  return clean.reduce((a, b) => a + b, 0) / clean.length;
}

For real-time UI, you might still display suspect values but de-emphasize them visually. For clinical aggregations and exports, drop bad values and flag suspect ones.

Comparing against reference

If you have a reference signal for the same subject (e.g., a clinical-grade ECG monitor running alongside a wearable), the platform makes side-by-side comparison straightforward:

1. Capture both streams in the same session.
2. Each stream produces its own feature series under a unique streamId.
3. Query both, align on the nanosecond timestamps in ts_ns, and compute the metric of interest (mean error, Bland-Altman, etc.).

Because timestamps are nanosecond-aligned with the source stream's clock, the only step you need is to interpolate to a common cadence if the two streams have different rates.

Synthetic streams

For testing without a wearable on a subject, the platform accepts pre-recorded waveform data submitted through the same ingest path as a live device. Common use cases:

• Replay a known-good ECG against the pipeline to verify HR and HRV outputs match expected values.
• Inject a noisy waveform and confirm the quality mask flags the bad regions.
• Stress-test downstream consumers with high-cadence feature series before deploying.

Reach out if you need help setting up a synthetic stream for your project - we have validated test fixtures (ECG strips with annotated R-peaks, PPG segments with known HR) that we share with design-partner customers.

Validating a custom algorithm

If you're running a custom algorithm against your streams (see Custom Algorithms), the same tools apply: query the feature series the algorithm produces, compare against reference data, and inspect the quality mask. The method_code field on every output value identifies the algorithm and version that produced it, so you can run multiple algorithm versions in parallel and compare their outputs apples-to-apples.

Reproducibility

Algorithm versions are immutable. When an algorithm is updated, existing observations keep their original method_code and the new version emits under a new code (e.g., algorithm:ecg_v1 to algorithm:ecg_v2). This means historical analyses always run against the same algorithm version that produced the original output - the platform doesn't silently re-run features under a newer algorithm.

If you need to reanalyze historical data under a newer algorithm, the platform supports explicit reprocessing. Contact us for the API surface; this is currently a managed operation rather than self-service.