PPR for Wearables & Human Telemetry · Patent Pending

Your AI reads a heartbeat. Can you prove it was real?

Your device is reading someone's body all day long. A heartbeat, a glucose level, a sleep score, whatever it is. Then your AI turns that reading into a claim: you're fine, you're not, take a walk, call a doctor. Here's the problem. That data is easy to grab. Anyone can pull it off the device, take it offline, change the numbers, and put it back. And once your AI has made a claim off it, you have no way to show the reading was real, came from the right person, and nobody touched it in between. That's what PPR does. It seals the reading the moment it's captured, and later anyone can check that seal on their own computer, offline. A regulator, an auditor, a court, the other side's expert. It's signed with ML-DSA-65 (FIPS 204), the government's post-quantum standard.

You keep the data. We keep the proof. We never see a heartbeat.

Here's the deal: the raw reading never leaves your device or your cloud. The sealing happens on your side. The only thing that ever comes to us is a fingerprint of the reading and a yes/no route. Never the reading itself, never the AI's output, never the secret key that unlocks it. We built it so we can't see your data even if we wanted to, and we test for that on every build. So adding proof doesn't hand you a new privacy problem.

When your product makes health claims, proof becomes a legal, compliance, and risk problem.

In about two years, the whole industry went from showing people raw numbers to handing them AI answers. The regulators noticed and came right along with it. So the day your product says something about someone's body, three teams inside your company all end up asking the same thing. Legal wants to know it'll hold up if you get sued. Compliance wants to know it'll pass an audit or an FDA review. Risk wants to know it won't blow up on you later. And the question underneath all three is identical: can you show this reading was real, came from the right person, and nobody changed it?

The claims went live

AI coaches, readiness scores, recovery numbers, arrhythmia flags, blood-pressure estimates, remote-monitoring alerts. On consumer wearables and clinical devices alike, the AI answer about the body is now the actual product. The raw number isn't.

The scrutiny arrived

Regulators aren't chasing the sensor anymore. They're chasing the claim. You can see it already: an FDA warning letter to a big wearable maker over a blood-pressure feature, and a reported product slowdown over safety and regulatory friction. This is happening everywhere.

The proof is missing

The usual device check only proves the sensor turned on. It says nothing about whether the reading behind the claim was real, on the body, from the enrolled person, and left alone. That's the gap somebody goes after, and right now nobody can close it.

Market context (public reporting): AI health-companion rollout to all members (Business Wire, Mar 2025) · FDA warning letter re a wearable blood-pressure feature (Jul 2025) · Industry response (CNBC, Jul 2025) · A major AI health-coach slowdown (Bloomberg, Feb 2026).

What PPR proves for your product

Same tool, four places it shows up, anywhere a body reading becomes an AI claim. In every one of them the device still passes its own self-check, but that's not what's on trial. The claim is. PPR is what lets you stand behind that claim without ever handing over the raw reading.

AI health companions & coaches readiness · sleep · recovery · stress
Provenance for the AI companion
The exposure

Your AI looks at someone's numbers and tells them what their sleep, readiness, or stress "means." Then someone pushes back. A member, a health plan you work with, a regulator. You've got nothing that shows the reading behind that advice was real, on the body, and left alone.

The PPR receipt on that claim shows

✓ origin: real device sensor, real capture path
✓ subject: the enrolled member, worn the whole time
✓ stream: nothing cut or reshuffled, it all lines up
✓ model: the exact coaching model and version you named
What it shuts down

"The AI made it up." The answer is tied to one specific reading. A faked one, or one off somebody else's device, fails right away.

"You only kept the good nights." If anyone cut out or reshuffled part of the stream, the seal won't line up.

"You quietly swapped in a cheaper model." The model is locked into the receipt. Switch it, and the math won't add up.

The member and the other side can both check the same receipt offline and get the same answer. You never ship the raw reading.

Medical-grade & regulated features BP · AFib · SpO₂ · medical mode
The receipt for a contested claim
The exposure

The second a feature goes from wellness into an actual health measurement, like blood pressure, arrhythmia, or oxygen, the regulator starts looking at the claim, not the sensor. And the question that won't go away is simple: for any given reading, can you show it was real, on the body, from that person, and unedited, on demand, without handing over the raw data?

The PPR receipt on that claim shows

✓ origin: real device sensor, our fresh challenge baked in
✓ subject: this person, worn without a break
✓ stream: the exact readings behind the finding
✗ any replay, faked, or edited data fails loudly
What it shuts down

Faked signal. A made-up waveform has no real capture behind it, so origin fails.

Replaying an old healthy month. Our fresh challenge from that moment isn't in it, so it won't check out.

Editing it after the fact. Change the reading later and the seal won't line back up.

A signed receipt anyone can check offline is the difference between "trust our pipeline" and "here's the math" when a regulator asks.

Health platforms & multi-source AI aggregators · OS health · third-party data
Provenance that scales to a platform
The exposure

Once your AI is pulling from your own data and outside sources like partner devices, labs, and connected apps, you don't have one device to vouch for anymore. You've got a whole web of them. And every reading coming in is one more thing somebody can dispute.

The PPR receipt at the platform edge shows

✓ origin: sealed on your side, for every source
✓ subject: tied to the enrolled account holder
✓ stream: continuous across devices and sources
✓ privacy: nothing raw ever leaves your side
Why it fits a platform

We can't hold your data. The sealing happens on your side. We never get the reading, the AI's output, or the key to unlock it. That's baked in, not a promise.

Works offline, built for the long haul. Nobody has to be online to check a receipt, and it uses ML-DSA-65 (post-quantum) from day one.

Handles outside data too. The same receipt stands behind a claim even when the reading came from an outside lab or a partner device.

This is the proof layer that lets a careful platform ship health AI it can actually stand behind.

Clinical / RPM & decentralized trials DCT · digital endpoints · RPM
Data integrity the FDA already asks for
The exposure

The FDA's rules for decentralized trials say the data has to be traceable, complete, and checked for tampering, and you have to decide up front how you'll handle missing data. So when an AI produces a trial endpoint or an RPM risk flag, the sponsor has to show the data came from the enrolled person, on the body, with no gaps quietly filled in. Right now that's something you claim, not something you can prove.

The PPR receipt behind the endpoint shows

✓ the enrolled participant, nothing cut out
✓ the exact time window behind the endpoint
✓ tamper shows up: the chain won't line up
✓ an auditor checks it offline, no raw data handed over
What it shuts down

Someone else wearing it. If the device comes off the enrolled person, the seal breaks, so a caregiver or a stand-in gets caught.

Filling gaps or padding data. Faked sample counts and clashing timestamps break the chain.

Pointing at the wrong stretch of data. Claim an endpoint from a different time window and it won't hold up.

To be clear: PPR proves where the data came from, that it wasn't touched, and that it's continuous. It does not assess the diagnosis or whether the endpoint is right. It's the chain of custody under the science, not the science itself.

Regulatory context: FDA: Conducting Clinical Trials With Decentralized Elements (final guidance, 2024) · FDA: Digital Health Technologies for Remote Data Acquisition in Clinical Investigations.

Proof that never turns into a privacy problem.

The reason most wearable teams never add proof is simple: they don't want all that body data piling up in one place where it can leak. PPR gets rid of that worry. We can't hold your data, and that's not a policy we wrote down, it's how the thing is built. We test for it on every single build.

Sealed on your side. Only fingerprints and verdicts cross over.

Your side
The raw reading, your secret keys, the AI's output

Ring, band, watch, hospital, or trial sponsor. The sealing happens right here. Nothing raw ever leaves.

▟ THE WALL ▙
only fingerprints
and verdicts cross
Our side (Hive)
We sign the fingerprints and hand back the receipt

We hold no readings. We can't open one up, because the key that unlocks it never came to us.

Not a diagnosis

Nothing here assesses whether the AI's answer is medically right. PPR proves where the reading came from, that it wasn't touched, and that it's continuous. It doesn't vouch for the conclusion.

Not face-scan ID

"On the body" just means the device didn't come off. It's not identifying you. We prove the thing was worn without a break, not who you are.

We don't hold it

We never get the raw reading, the AI's output, or the keys. Checking a receipt happens fully offline, with no calls back to us, and we test for that.

The five bindings

Here's the actual math for the engineers. Every inference lives inside a capture epoch, hash-chained. Break any single link and verification fails. The capture tier is committed into the origin binding, so it can't be relabeled or oversold.

# O binds sensor origin. The capture tier is committed IN, load-bearing.
O   = commit(capture_tier ‖ device_attest ‖ cert_chain ‖ revocation ‖ measurement
             ‖ sensor_id ‖ capture_assertion ‖ capture_assertion_sig ‖ firmware ‖ challenge)
B   = commit(subject_id ‖ on_body_presence ‖ wear_continuity ‖ enrollment)
# Sⱼ is the anti-splice chain: each interval commits to its predecessor
Sⱼ  = commit(interval_commitmentⱼ ‖ t_start ‖ t_end ‖ sample_count ‖ channels ‖ Sⱼ₋₁)
I   = commit(model_digest ‖ version ‖ quantization ‖ config ‖ interval_range ‖ output_commit ‖ ts)
# Kᵢ is recursive continuity across the epoch
Kᵢ  = commit(O ‖ B ‖ Sⱼ ‖ I ‖ Kᵢ₋₁)
Receipt = Sign_MLDSA65(O ‖ B ‖ Sⱼ ‖ I ‖ Kᵢ ‖ epoch_metadata)

interval_commitment and output_commit are computed holder-side with a holder-side salt. The salt never leaves. Hive signs commitments only.

We tell you exactly what a receipt is worth

A receipt is only as strong as the thing that vouched for the reading, so we say which one it was, right in the receipt. Nobody can dress up a weaker one as something better. Version 1 ships with one level, and we say so plainly.

Capture tierWhat the capture assertion's trust floor actually isStatus
holder-ingest-signedYour own ingest key vouches that the reading came in through the device software. This is not the chip itself vouching. It's the honest floor, and it's what version 1 ships today.v1 · shipping
secure-element-signedThe secure chip inside the device vouches for the reading, which is a hardware-level floor. Same receipt, stronger proof. This is the upgrade for hardware makers like Oura, Whoop, and Apple silicon.the upgrade

Whoever's checking (a health plan, a sponsor, a regulator) can require a minimum level and turn down anything weaker. Try to pass off a lower-level receipt as a hardware one and it fails. In the reference build, origin evidence is flagged simulated=true until it's wired to a live device feed. We never fake a receipt.

Real numbers

Measured on the box, running the real code. The ML-DSA-65 sizes match the FIPS 204 spec exactly. This holds up across a whole fleet of wearables.

413k/s
fingerprints made per second, 2.4µs each
106k/s
chunks sealed per second, 500 samples checked and chained each
8.8ms
to check one receipt (ML-DSA-65)
3,309B
signature size, public key 1,952 B, FIPS 204

All 19 tests pass in the reference build: 8 ways to cheat that get caught, a model-swap check, the clean happy path, and 9 rules we hold ourselves to (we can't hold your data, checking works offline, no faking the level, no diagnosing, and the fingerprints give nothing away).

The Hive canon: what helps you now, and what's next

PPR is one tool in a family of them. Start with PPR to prove your body readings today, and the same receipt rail reaches every other AI call your product makes. Once you've got proof on one thing, you can put it on everything.

PrimitiveWhat it provesFit for a wearable / health builderWhen
PPR, Physiological Provenance ReceiptProves an AI reading came off a real sensor on the body, from the enrolled person, with nothing cut out, read by the model you named.The core one. Proof under every AI health claim, without us ever holding the raw reading.now
SiGR, Signed Inference Guarantee ReceiptProves a specific model, set up a specific way, produced a specific output. Signed, checkable offline.Takes PPR's model lock and puts it on every AI feature you ship, health or not.now
AFiR, Attested Fragmented Inference RoutingSigns the path an inference took across different pieces and providers.Your proof holds up even when your AI hops across several models or vendors.now
R3Pv, Receipt Proof VectorBundles a pile of signed receipts into one you can still check.Roll up a member's whole month, or a trial group, into one thing an auditor can open.next
Media-Origin ReceiptSigns whether media came from a human, an AI, or both.For coaching content, video guidance, and AI-written messages to members.next
S2S, Silicon-to-SignatureTies NVIDIA GPU hardware proof to every inference that runs on it.A hardware-level floor for the model side, where the inference actually runs.next

Get PPR into your health-claim path, and that same habit (signed, checkable offline, post-quantum) reaches everything else your product figures out.

Try PPR on one health claim

Pick one AI feature. A readiness score, a blood-pressure insight, an RPM flag, a trial endpoint, whatever. We wire PPR in on your side, you keep every raw reading, and you walk out with a signed receipt a regulator or a court can check offline. Nothing raw leaves your side.

PPR, the Physiological Provenance Receipt. Patent pending. Post-quantum signed (ML-DSA-65, FIPS 204), checkable offline. Hive never sees a raw reading. You keep your data. We keep the proof.

Private by design. Hive does not store your prompts. Every request is already receipted by a one-way SHA-256 fingerprint, not the words. Proof, not surveillance.