Custom Algorithms

Most applications get what they need from the built-in modality extractors - HR, HRV, PRV, plus the discrete biosignals in the catalog. For applications that need something specific (a custom feature, a proprietary algorithm, an FDA-cleared metric from a partner), the platform supports running custom DSP algorithms as part of the pipeline.

Two ways custom algorithms reach your stream

There are two paths a custom algorithm reaches your application:

1. Algorithm marketplace. Algorithms published by AnyBio's algorithm partners. You opt your organization in via an entitlement; from then on, the algorithm runs against your matching streams alongside the built-in extractors. Outputs surface as feature series and observations like everything else. See Algorithm Marketplace (gated availability).

2. Direct authoring. For applications building proprietary signal-processing logic, the platform supports authoring and running your own algorithms scoped to your organization. This is currently available to design-partner customers. Contact us if you have a custom algorithm in mind.

What runs the algorithm

Custom algorithms run inside a sandboxed runtime on the AnyBio platform - not on the device, not in the browser. This keeps clients lightweight and ensures the algorithm has access to the full stream history (filters that need a few seconds of warm-up, rolling windows that span minutes, etc.).

Algorithms declare:

• Input signals - which biosignals from the catalog they consume (e.g., ECG, PPG, or a combination).
• Sampling rate - the rate at which the algorithm expects input samples.
• Output signals - the feature series the algorithm produces, with names, units, and cadences.

The platform routes a stream to a custom algorithm whenever the stream contains the algorithm's declared input signals. Outputs land on the same /streams/{streamId}/features endpoint as built-in features.

Provenance and traceability

Outputs from custom algorithms are tagged with a method_code identifying the algorithm and its version, the same way built-in algorithms are tagged:

{
  "biosignal_id": 12,
  "value": 32,
  "unit": "ms",
  "method_code": "algorithm:partner_hrv_v2"
}

This gives downstream consumers (clinical reviewers, compliance audits, research workflows) a clear record of which algorithm produced each value. Versions advance when the algorithm is updated; historical values keep their original method code so prior analyses remain reproducible.

Verification

For algorithms published through the marketplace, the platform exposes a public-key endpoint that lets entitled customers verify the algorithm binary they're executing matches what the publisher signed:

GET /api/v1/algorithms/{algorithmId}/public-key

Returns the public key in PEM form. Combined with the algorithm's signature metadata, this gives external auditors a way to confirm that the algorithm bytes haven't been altered between the publisher and the runtime.

See Algorithm Marketplace for the full verification flow.

Limits and constraints

Custom algorithms are subject to runtime, memory, and latency budgets to keep the pipeline responsive across all subjects. For most signal-processing logic these limits are comfortable; for heavier workloads (model inference on long windows, multi-stream fusion at high rates), contact us to discuss the right execution path.

Quality and validation

Whether the algorithm is built-in or custom, the platform applies the same quality-mask propagation: outputs carry a qmask reflecting both per-sample QA events from ingest and any window-level checks the algorithm itself emits. This means a custom algorithm doesn't have to reinvent quality tracking - it inherits the platform's signal-quality view.