Wearables built around your protocol

Quick answer: Wearables built around your protocol start with raw PPG you can audit, then lock sensors and sample rates before enrollment, put streams into your app through an SDK or API, and run remote monitoring with program rules your operators actually act on. Sensor Bio is that Capture → Build → Act stack for research and product teams.

Closed consumer wearables are easy to demo and hard to own. You get a proprietary score (call it "74") while the raw optical signal stays locked. Your protocol did not ask for that score. Your protocol asked for a defined capture window, a sample rate you can defend, and a path into software you control.

This piece walks the stack that replaces that default: capture the signal, configure the device to the playbook, put data inside your product, then act with remote monitoring and Signal Studio rules. One short note of context: we shared this narrative at Plug and Play Batch 6 in Frisco on October 20. The article is the education layer, not a recap.

Closed wearables force someone else's playbook

Most wrist and ring products optimize for a fixed consumer experience. Battery life, a polished recovery number, and a brand app that owns the relationship. That is fine when the wearer is the customer.

It breaks when the customer is a research program, a specialty clinic ops team, or a health product that must stay the system of record. Then the vendor playbook becomes a constraint:

• You cannot reopen the waveform after last enrollment.
• Sample rate and duty cycle follow their firmware story, not your protocol.
• Alerts live in their dashboard, so coaches and site staff bounce between tools.
• Private-label packaging does not fix a closed data path.

Protocol ownership is not a slogan. It is a pre-enrollment decision: what is collected, how often, where it lands, and who gets notified when a program rule trips. If those answers live in a consumer cloud you cannot configure, you are renting a score.

Capture: raw PPG and what you can derive

Start upstream. Photoplethysmography (PPG) is the optical pulse signal at the wrist. When partners enable it, Sensor Bio can expose the raw waveform rather than only a smoothed heart-rate line. That matters when your team needs to review quality, mark movement artifact, or feed models with the same amplitudes the device saw.

Multi-wavelength context is part of that capture story. Red and infrared channels support SpO2-related derived outputs when those channels are on. Motion from an accelerometer gives operators a reason a segment looks noisy. None of that replaces protocol design. It gives the protocol something honest to work with.

From a clean capture window you can derive the metrics most programs already know how to read:

• Heart rate
• Inter-beat or pulse intervals (IBI)
• Respiratory rate
• SpO2 (when optical channels and quality allow)

Treat those as derived wellness and research-program outputs. They are not diagnostic labels. If your roadmap includes model training, remember the blunt version: models learn from what you feed them. Feed locked scores and you inherit someone else's features. Feed auditable signal and your pipeline can grow without rewriting enrollment.

Deep dives elsewhere on Signal: raw PPG access for partners and photoplethysmography (PPG). Continuous autonomic work often sits on the interval layer: how researchers use continuous HRV.

Build: configure the device to the protocol

Capture without configuration is still a consumer default with nicer marketing. The Build layer is where the playbook becomes a device profile.

Teams typically decide four things before first kit ships.

Which sensors are on

PPG for optical pulse. Accelerometer for motion and activity context. Skin temperature where the program uses it. Where available, higher-rate ECG-oriented options (for example 500 Hz configuration paths) belong in the same profile conversation as optical sample rate. Turn on only what the protocol needs. Extra channels cost power, storage, and review time.

Sample rate and when collection runs

Optical capture on Sensor Bio organizations is commonly configured at 25, 50, or 100 Hz (default 50 Hz). A pitch-friendly research example is PPG at 100 Hz when waveform detail is in scope. Lower rates fit lighter monitoring. Cadence (how often data leaves the device path) can range from live through multi-minute batches depending on coaching versus overnight population work.

Write the on-switch for raw export into onboarding. Raw capture is not useful if it stays off for the whole cohort. Changing profiles mid-study breaks comparability; lock first, then enroll.

Sensor Bio documents 100+ platform configurations you can set once for the organization so every device shares the same data model. The dedicated how-to lives here: how to configure a research wearable.

Where athletes, patients in studies, or partners experience it

Same hardware stack, different surfaces:

• A private-label app under the partner brand
• Your existing product via SDK and API
• Operator views on a remote monitoring platform

Brand and UX can stay yours. The physiological data model stays explicit.

Put physiological data inside your product

Software is the reason infrastructure wearables exist. If the only place to see the signal is a third-party consumer app, you do not have a product. You have a referral.

Sensor Bio's Connect and Build paths put streams into stacks partners already run. Practical shapes:

1. Mobile SDK for device-adjacent sync on iOS and Android when the phone sits inside your trust boundary.
2. Cloud API (REST) for server-side jobs, warehouses, and operator tools.
3. Batch export when analysis windows matter more than live UX.

Confirm field names and auth on the Developers hub before you freeze a connector. Editorial architecture for builders: wearable API for health products. Endpoint reference stays on docs, not in this article.

Before a demo, run one short capture from device through sync into your schema. If that path is unclear, configuration slides will not save the integration.

Act: remote monitoring and Signal Studio rules

Once signal is flowing, operators need a roster, not a scavenger hunt across consumer dashboards. The Remote Monitoring Platform view in the pitch narrative surfaces program metrics such as recovery, sleep, activity, steps, calories, HRV, resting heart rate, and respiration. Treat those as operational columns for wellness and research programs. They are not clinical reference ranges.

Program rules, not diagnosis

Signal Studio is where teams encode triggers they will actually act on. A concrete example from the pitch:

If resting heart rate is above 90 bpm for two nights, notify the coach (push or email today; text or AI call on the roadmap).

That number is a program threshold the team chose, not a medical cutoff and not a clinical judgment about the wearer. Soften any adherence UI language the same way. Prefer "needs a look" or "off track on wear time" over labels that sound like clinical triage.

Good rules share three traits:

1. They use a metric your capture profile actually collects.
2. They fire to a human role that owns the next step.
3. They leave an audit trail your ops team can explain.

Adherence belongs in the same Act layer. Wear-time and real signal quality tell you whether the cohort is producing usable nights. A perfect config with empty nights is still an empty study.

Endpoint and digital-measure framing for research programs: digital biomarkers.

Private label when the brand must stay yours

Some partners need the full surface under their mark: device, packaging, app, and monitoring. Private label is the pitch's answer when the relationship with the wearer cannot look like a Sensor Bio consumer product.

Keep expectations honest. Private label is packaging and experience ownership on top of the same Capture → Build → Act infrastructure. It is not a license to invent diagnostic claims. V2 remains a general wellness device, not FDA cleared for diagnosis, under your brand or ours.

We do not paste logo walls here. If a named partnership is approved for public pages in product-marketing, use that list. Until then, describe the capability without inventing customers.

A practical path from pitch to first cohort

Treat this as a working checklist, not a ceremony.

1. Write the playbook in one page. What must be true after four weeks: metrics, windows, who acts on a rule.
2. Lock Capture. Raw on or off, wavelengths, motion, SpO2-related channels if needed.
3. Lock Build. Sample rate, cadence, sensor toggles, org-wide profile. Apply once across devices.
4. Choose the surface. Private-label app, your app via SDK/API, or both.
5. Validate one device end to end. Wrist → sync → your schema or monitoring roster.
6. Add Act rules last. Signal Studio triggers only after the signal path is trusted.
7. Define adherence. What "needs a look" means for wear time and quality, in plain language.
8. Document claims language. Wellness and research program copy only unless legal unlocks more.

When you are ready to map that page to a live stack, start at Get Started or the Developers hub.

Related reading

• How to configure a research wearable
• Wearable API for health products
• Raw PPG access for partners
• Digital biomarkers
• How researchers use continuous HRV
• Photoplethysmography (PPG)

Quiet next step: Get Started when you want to map a playbook to Capture, Build, and Act.