Sensor Foundation Models: Health AI Trained on Wearable Signals

A smartwatch produces roughly a million data points a day per sensor channel: heart rate, skin temperature, movement, blood oxygen, sometimes an ECG trace. Almost none of that data is ever read by anything smarter than a threshold-and-alert script. A step counter counts steps. A heart-rate algorithm flags tachycardia above a fixed number. The raw waveform underneath — the actual shape of your pulse, the micro-patterns in how your wrist moves while you sleep — gets thrown away after a summary statistic is extracted.

Sensor foundation models are an attempt to stop throwing that data away. Instead of training a large model on text scraped from the internet, you train it on raw sensor streams — accelerometer traces, photoplethysmography (PPG) waveforms, electrocardiogram (ECG) signals — and let the model learn the underlying structure of human physiology the same way a language model learns the structure of language. The bet is that a model which has "read" billions of hours of heartbeats and movement patterns will recognize subtle, hard-to-hand-code signals of illness, fatigue, or physiological change that rule-based algorithms miss entirely.

This explainer covers how sensor foundation models are built (pretraining corpus, self-supervised objectives, tokenizing continuous signals, multi-rate fusion), why the approach is gaining ground now, what it changes for health tech teams compared with traditional supervised pipelines, and the limitations around noise, bias, interpretability, and regulation that still apply.

What a Sensor Foundation Model Actually Is

A foundation model, in the sense popularized by large language models, is a single large network pretrained on a broad, largely unlabeled corpus using a self-supervised objective, then adapted to many downstream tasks with comparatively little task-specific data. Sensor foundation models apply that same recipe to time-series signals from wearables and biosensors instead of tokens of text.

The core pieces look like this:

• Pretraining corpus: instead of web text, the input is raw or lightly processed sensor streams — accelerometer x/y/z axes, PPG optical waveforms, ECG leads, gyroscope data, sometimes skin temperature or electrodermal activity — collected continuously over long periods from large, often anonymized populations.
• Self-supervised objective: rather than predicting the next word, the model learns by predicting masked segments of a signal, reconstructing a waveform from a corrupted version, or matching representations of the same underlying physiological state across different sensor modalities (for example, aligning a PPG-derived heart rate with the corresponding ECG trace).
• Tokenization of continuous signals: sensor data is continuous and noisy, not discrete like text, so these models typically use techniques like patch-based encoding (chunking a signal into short time windows, similar to how vision transformers chunk images into patches) or learned discrete codebooks that turn waveform segments into tokens a transformer can process.
• Downstream adaptation: once pretrained, the model is fine-tuned or probed with a small labeled dataset for a specific task — detecting atrial fibrillation, estimating blood pressure, flagging early signs of infection, or predicting sleep stages — often with far less labeled data than training a model from scratch would require.

The architectural backbone is usually a transformer, the same family of model underlying GPT-style language systems, adapted to handle long, high-frequency time series rather than short sequences of discrete tokens. Some approaches borrow directly from vision transformers, treating a spectrogram or waveform image as if it were a picture. Others use specialized sequence architectures better suited to the sampling rates and noise characteristics of biosensors, which can range from 1 Hz for temperature to several hundred Hz for ECG.

One practical wrinkle that doesn't come up in text or image pretraining is multi-rate fusion. A single wearable might report accelerometer data at 50 Hz, heart rate at 1 Hz, and skin temperature at 1 sample per minute, all at once. A language model never has to reconcile a word that arrives fifty times faster than the sentence around it. Sensor foundation models generally handle this by encoding each modality into its own sequence of patches at its native rate and then fusing the resulting representations with cross-attention, rather than forcing every signal onto a single shared timeline before the model ever sees it. Getting that fusion step wrong — misaligning a heart-rate spike with the movement that actually caused it — is one of the more common failure modes in early systems.

Why Not Just Use Labeled Data and Supervised Learning?

The traditional approach to wearable health AI is supervised: collect a dataset of sensor readings paired with clinical labels (this person had AFib, this person didn't), and train a model to predict the label. That works, but it is bottlenecked by the scarcity and cost of labeled clinical data. Getting a cardiologist to annotate ECG traces at scale is expensive and slow, and it only produces a model good at the one thing it was labeled for.

Self-supervised pretraining flips the ratio. The overwhelming majority of wearable data collected in the world — billions of device-days across consumer smartwatches, rings, and patches — has no clinical label attached to it at all. It's just a healthy person going about their day. A foundation model can learn from all of that unlabeled data first, building a general representation of what normal and abnormal physiological patterns look like, and then a much smaller labeled dataset is enough to steer that general representation toward a specific diagnostic task.

Why It Matters Now

Google's SensorFM, announced in July 2026, is a concrete instance of this approach applied at scale: a foundation model pretrained directly on raw sensor streams rather than on text or images, aimed at extracting physiological and behavioral signal from wearable data that previous pipelines discarded. It sits alongside a broader shift in health tech research toward treating the wearable data stream itself as the primary object of modeling, rather than as a source of hand-engineered features fed into a conventional classifier — mirroring a similar move toward foundation models for physical and sensor domains more generally.

That shift matters for a structural reason: wearables have quietly become one of the largest continuous biometric data-collection systems ever built, and almost all of that data has been going to waste from a modeling standpoint. Most consumer wearable algorithms today are still built the way medical device software has been built for decades — a domain expert defines a feature (resting heart rate variability, step cadence, sleep latency), a supervised model or even a simple rule is trained on that feature, and the rest of the raw waveform is discarded after the feature is computed. That pipeline is reliable and explainable, but it can only ever detect the patterns someone thought to look for in advance.

A foundation model trained directly on raw signal doesn't need someone to have already hypothesized the relevant feature. It builds its own internal representation of the signal from exposure alone, the same way a language model builds an internal representation of syntax and semantics without anyone hand-coding grammar rules. That's what makes the approach interesting for early detection use cases in particular — arrhythmias, infections, or metabolic changes that might show up as a subtle, distributed pattern across a waveform rather than a single crossable threshold, feeding the same push toward treatment tailored to an individual's own physiological baseline.

Benefits of Sensor Foundation Models

The appeal of the approach is easiest to see from the point of view of a team that has built wearable features the traditional way. Most of the benefits come from reusing one learned representation across many tasks instead of starting from scratch each time.

Far less labeled data per task

Clinical labels are the most expensive part of building a wearable health feature. A pretrained backbone has already learned what typical heartbeats, movement, and sleep look like from unlabeled data, so a new detection task can often be steered with a few hundred labeled examples instead of a large annotation campaign. That changes which features are economically worth building, especially for less common conditions where labeled data is scarce.

Patterns nobody thought to engineer

Hand-engineered features only capture what an expert decided to measure in advance. A model that learns directly from raw waveforms can pick up subtle, distributed patterns across a signal, such as small changes in pulse shape or movement during sleep, that no single feature or threshold would catch. That is the main reason researchers are interested in the approach for early detection.

One backbone, many features

Once a backbone exists, adding a new capability means attaching and training a small task-specific head rather than building a new model end to end. Teams can explore several candidate features quickly, drop the ones that don't work, and invest validation effort only in the most promising, which makes the product roadmap more flexible.

Better handling of mixed devices

Models pretrained across many sensor types and sampling rates are, in principle, more robust to the variety of hardware a real programme encounters. A hospital monitoring patients with different watches, rings, and patches benefits from a model that has seen data from many devices, rather than one tuned to a single vendor's sensor.

More value from data already collected

Most wearable data is currently reduced to summaries and discarded. Foundation models give a reason to keep and use the raw stream, so organisations already collecting sensor data can extract more insight from it without new hardware, provided consent and data governance cover the new use.

Sensor Foundation Model Use Cases

Most applications are still at the research or early product stage, and any feature that makes a diagnostic claim needs clinical validation and regulatory review. These are the tasks most often cited as targets, ranging from well-established wearable features that foundation models might improve to research directions that are still unproven.

Arrhythmia detection

Detecting atrial fibrillation and other irregular rhythms from PPG or ECG is a well-studied wearable task with established supervised models. Foundation models aim to improve detection from noisy wrist-based PPG and to recognise less common arrhythmias with smaller labeled sets. Any such feature still needs comparison against clinical gold standards before it can be marketed for detection.

Sleep staging

Classifying light, deep, and REM sleep from movement and heart signals is a common wearable feature, traditionally trained against lab sleep studies. A pretrained backbone can learn from vast amounts of unlabeled overnight data and then be fine-tuned against a smaller set of lab-labelled nights, potentially improving accuracy across different people and devices.

Early signs of infection or illness

Researchers are exploring whether subtle shifts in resting heart rate, temperature, and movement can signal an oncoming infection before symptoms appear. These changes are often small and spread across several signals, which suits learned representations. This remains a research direction, and early products are more likely to offer wellness prompts than diagnostic claims.

Blood pressure estimation

Cuffless blood pressure estimation from optical signals is a long-standing goal with mixed results. Foundation models offer a new attempt at capturing the relevant waveform features, though accuracy and calibration across populations remain significant open questions that any product team would need to answer with independent data.

Remote patient monitoring

Hospital and clinic programmes that monitor patients at home could use a shared backbone to support several alerts, such as deterioration signals or adherence patterns, across mixed device fleets. Alert fatigue and clinical workflow fit matter as much as model accuracy in this setting. A model that flags too many patients will be ignored, however good its underlying representation, so thresholds need tuning with the clinical team that receives the alerts.

Practical Implications for Builders and Health Tech Teams

For teams building on top of wearable data — whether that's a digital health startup, a hospital system piloting remote patient monitoring, or a consumer device maker — sensor foundation models change the economics of building new features.

Several practical consequences follow from this:

1. Lower marginal cost per new use case. Once a foundation model backbone exists, adding a new detection task (say, dehydration risk or medication adherence signals) may require a small fine-tuning dataset rather than a full data-collection and labeling campaign.
2. Cross-device transfer becomes more plausible. A model pretrained across a wide range of sensor hardware and sampling rates is, in principle, more robust to the messy reality that a hospital's remote monitoring program will see data from several different device vendors.
3. Data infrastructure matters more than model architecture for most teams. The hard part for a health tech company adopting this approach is rarely the model itself — it's building the pipeline to collect, store, and align large volumes of raw continuous sensor data across a population, which is a very different engineering problem than storing daily step summaries.
4. Regulatory and validation burden doesn't shrink. A foundation model backbone still requires task-specific clinical validation before a downstream application can make any diagnostic claim. Pretraining reduces the labeled-data requirement; it does not reduce the evidence requirement for a regulator.
5. Vendor lock-in risk increases. If a small number of large sensor foundation models become the de facto backbone for wearable health AI, teams building on top of them inherit both the capabilities and the failure modes of those base models, similar to how the LLM ecosystem now depends heavily on a handful of foundation model providers.

What This Looks Like for a Product Team

A team building a remote cardiac monitoring feature, for example, would traditionally spend months collecting ECG traces paired with cardiologist annotations for each new detection target. With a sensor foundation model as a starting point, the workflow shifts toward: obtain or fine-tune access to a pretrained backbone, assemble a comparatively small labeled validation set for the specific condition of interest, fine-tune or attach a lightweight classification head, and then run the much longer process of clinical validation that any health-adjacent product requires regardless of how the underlying model was built.

That last step is worth dwelling on, because it's where teams most often underestimate the timeline. Fine-tuning a pretrained backbone on a few hundred labeled examples can genuinely take days instead of months. Proving to a regulator, an insurer, or a hospital's own clinical review board that the resulting feature is safe and accurate enough to influence patient care is still a months-to-years process, largely unaffected by how efficiently the underlying model was trained. The foundation-model approach compresses the model-building phase of the timeline; it does nothing to compress the trust-building phase, and for a health product the trust-building phase is usually the longer one anyway.

Common Sensor Foundation Model Mistakes

Teams excited by the shorter model-building cycle tend to make predictable errors, most of them around data and validation rather than architecture. They are easy to make because the early stages of a foundation-model project move quickly, and the problems only become visible when clinical evidence or regulatory review is required.

Discarding the raw signal

Many wearable products keep only summary statistics such as daily heart rate or step counts. A team that decides to adopt a foundation model later discovers it has no raw waveforms to fine-tune or validate on. Deciding early what raw data to retain, with appropriate consent, is a prerequisite rather than an afterthought.

Planning around fine-tuning time instead of validation time

Fine-tuning a head on a pretrained backbone can take days, which makes timelines look short. Clinical validation, regulatory review, and hospital approval still take months or years. Roadmaps built on the fine-tuning estimate slip badly when the evidence work begins.

Validating on the wrong population or devices

A backbone pretrained mostly on one demographic or device family may perform worse elsewhere, as optical sensors already have on darker skin tones. Testing only on convenient internal data hides those gaps. Validation sets need to reflect the people and hardware the product will actually serve.

Treating learned representations as self-explanatory

Clinicians need to understand why a feature raised an alert. Shipping a foundation-model output without explanation, supporting signals, or clear limits invites mistrust and makes errors harder to catch. Interpretability work has to be planned alongside accuracy.

Ignoring how updates affect clearance

Foundation models are often updated, but regulated software is usually approved as a specific version. Swapping in a new backbone without considering the validation and regulatory consequences can invalidate the evidence behind a cleared feature. Update plans need to be agreed with regulatory and quality teams before the first release, not after a vendor ships a new version.

Sensor Foundation Model Best Practices

For health tech teams evaluating the approach, these practices keep the shorter model-building cycle from turning into a longer, riskier path to a trusted product. They are deliberately weighted toward data, validation, and clinical fit, because those are the stages that decide whether a feature reaches patients, and they apply whether you build your own backbone or adapt one from a research group or vendor.

• Audit your data pipeline first. Check which raw signals you retain, at what sampling rates, under what consent, and for how long, before choosing a model.
• Pick one well-defined first task. Start with a task that has an accepted clinical reference standard, such as arrhythmia detection or sleep staging against lab studies, so results can be measured objectively and compared with existing methods.
• Design the validation study before fine-tuning. Decide the reference standard, sample size, population, devices, and success thresholds up front, and treat validation as the main project timeline.
• Test across demographics and devices. Report performance separately by skin tone, age, sex, and hardware so gaps are visible before launch rather than after.
• Keep a feature-based baseline. Compare the foundation-model feature against the existing rule-based or supervised algorithm on the same data, and adopt it only if it clearly improves results.
• Version and lock the backbone for regulated features. Record which backbone version underpins each feature and plan how updates will be revalidated.
• Use privacy-preserving training where possible. Consider approaches such as federated learning and strict retention limits, since continuous biometric data can identify individuals.
• Plan for clinician workflow and alert fatigue. Pilot alerts with clinical staff, measure false-positive burden, and adjust thresholds before scaling.
• Monitor performance after launch. Track real-world false positives, missed events, and drift as users, firmware, and devices change, and feed findings back into validation.

Real Limitations and Open Questions

The framing of "foundation models for sensors" borrows a lot of credibility from what large language models have already demonstrated, but the analogy has real limits.

• Signal-to-noise is worse than text. Text is a clean, discrete, human-curated signal. Raw sensor data from a consumer wearable is full of motion artifacts, poor skin contact, battery-driven sampling gaps, and device-specific calibration quirks. A model pretrained on noisy consumer data may learn to represent the noise as faithfully as the physiology.
• Interpretability is harder in a domain with clinical stakes. A hallucinated sentence from a chatbot is usually low-stakes and easy to spot. A learned representation that quietly misweights a physiological pattern is much harder to audit, and the consequences of getting it wrong in a health context are more serious than a bad autocomplete suggestion.
• Population and device bias. Wearable adoption skews toward certain demographics, income levels, and device ecosystems. A foundation model pretrained predominantly on that population risks encoding the same demographic blind spots that have historically affected pulse oximetry and other optical sensors, which are known to perform less accurately on darker skin tones.
• Benchmark scarcity. Language and vision foundation models benefit from decades of established benchmarks. Sensor foundation models are still assembling the equivalent: there's no widely agreed-upon "ImageNet of wearable physiology" against which competing models can be cleanly compared.
• Regulatory pathway is unsettled. It's not yet clear how bodies like the FDA will evaluate a diagnostic feature built on a general-purpose pretrained backbone that the developer didn't fully train from scratch, versus a narrowly trained, fully specified model. Continuous model updates — a routine part of the foundation-model lifecycle — sit awkwardly against a regulatory framework built around locking down a specific software version.
• Compute and data-governance costs shift, they don't disappear. Pretraining at scale on raw continuous sensor data from millions of device-days requires storage, compute, and privacy-preserving training infrastructure that is arguably harder to build responsibly than a text corpus, given that biometric data carries different legal and ethical weight in most jurisdictions.

None of this means the approach is overhyped — it means the hard engineering and validation work moves rather than disappears. The promise is fewer bespoke models per use case; the cost is a harder, more consequential validation problem concentrated in fewer, more powerful backbones.

What to Watch Next

A few signals will indicate whether sensor foundation models move from research demonstrations to production health infrastructure:

• Independent, task-specific validation studies. Watch for peer-reviewed clinical validation of foundation-model-derived features against established diagnostic gold standards, not just internal benchmark comparisons.
• Cross-vendor interoperability. Whether these backbones can genuinely generalize across different wearable hardware — a ring, a chest strap, a smartwatch — rather than being effectively tied to the device family they were pretrained on.
• Regulatory guidance specific to foundation-model-based medical software. Clarity from regulators on how continuously updated, pretrained backbones fit into existing medical device approval frameworks.
• Open weights and open benchmarks. Whether the field converges around shared, publicly evaluable benchmarks the way NLP did with GLUE and its successors, which would make it possible to compare competing sensor foundation models on equal footing.
• Real-world deployment outcomes, not just detection accuracy in a research setting — false-positive rates in daily use, alert fatigue, and whether clinicians and patients actually trust and act on the outputs.

Teams building health or wearable products who want help evaluating whether a sensor foundation model approach fits their data pipeline and validation constraints can reach out to Woyce Technologies.

FAQ

What is a sensor foundation model?

It's a large neural network, usually transformer-based, pretrained on raw sensor time-series data — accelerometer, PPG, ECG, and similar signals — using self-supervised learning, then adapted to specific downstream tasks like arrhythmia detection or sleep staging with smaller amounts of labeled data. The idea mirrors large language models: learn general structure from huge amounts of unlabeled data first, then specialize cheaply. Here the structure being learned is human physiology and movement rather than language.

How is this different from existing wearable health algorithms?

Most current wearable algorithms are built on hand-engineered features extracted from raw sensor data, such as resting heart rate or step counts, with a comparatively simple model layered on top. Sensor foundation models instead learn directly from the raw waveform, potentially capturing patterns that predefined features miss. The trade-off is explainability. A feature like resting heart rate is easy to inspect and justify to a clinician, while a learned representation is harder to audit, which matters when outputs could influence care decisions.

Does this require new hardware?

No. The approach works with the sensors already present in consumer wearables and clinical biosensors — accelerometers, optical PPG sensors, ECG leads. The change is in how the resulting data is modeled and used, not in the sensors that collect it. What may change is the data pipeline. Many products currently keep only summary statistics, while foundation models benefit from access to raw or lightly processed waveforms, which means more storage, bandwidth, and careful handling of sensitive biometric data.

Can a sensor foundation model make a medical diagnosis on its own?

Not on its own, and not without regulatory clearance for the specific claim being made. These models produce learned representations or risk signals that still require clinical validation, fine-tuning for a specific condition, and typically regulatory review before they can support a diagnostic claim in a real product. In practice, early uses are more likely to be wellness insights, triage signals, or flags that prompt a person to seek care, with a clinician making any actual diagnosis. Any feature that crosses into diagnosis needs the same evidence as other regulated medical software.

What data privacy concerns come with this approach?

Pretraining at scale requires collecting continuous, often highly personal physiological data across large populations, which raises the same de-identification, consent, and data-governance questions that apply to any large-scale health data collection effort, and arguably more acutely given how identifying continuous biometric signals can be. Gait and heartbeat patterns can act like fingerprints, so removing names isn't enough. Teams should look at consent scope, retention limits, where processing happens, and techniques such as federated learning that train models without centralizing raw data.

Is Google's SensorFM the only example of this approach?

It's a prominent one announced in 2026, but it reflects a broader research direction rather than a single product. Multiple research groups and companies working on wearable and clinical sensor data have been exploring self-supervised pretraining on raw physiological signals. Approaches differ in which signals they use, how they tokenize continuous data, and whether weights are released. For builders, the more useful question is whether a given backbone has been validated on data similar to theirs, including the same device types and populations.

Will this replace existing wearable algorithms soon?

Not immediately. Existing rule-based and feature-based algorithms are well-validated, explainable, and already deployed at scale. Sensor foundation models are more likely to first appear as an additional layer that surfaces new detection capabilities, with a longer runway before they replace the simpler, already-trusted systems underneath consumer devices. To replace them, the new models will need to meet the same validation and explainability bar those algorithms already clear.

Conclusion

Wearables collect an enormous amount of physiological data, and most of it is discarded after a summary number is computed. Sensor foundation models try to use the whole signal: pretrain on billions of hours of unlabeled accelerometer, PPG, and ECG data, then adapt that general representation to specific tasks with far less labeled data than supervised pipelines need.

For health tech teams, that changes the economics of building new features. New detection tasks can start from a shared backbone rather than a fresh labeling campaign, and cross-device generalization becomes more plausible. But the hard parts move rather than disappear. Raw consumer sensor data is noisy, wearable populations are skewed, learned representations are harder to audit, and clinical validation and regulatory review take as long as ever. Biometric data also carries heavier privacy obligations than text.

If you're considering this approach, start by checking whether your data pipeline keeps raw waveforms at all, then pick one well-defined task and plan the validation study before the fine-tuning work. For help designing the data infrastructure and validation plan for a wearable health product, talk to our healthcare AI development team.