Physiological Provenance Receipt · PPR · Patent Pending

Prove the heartbeat was real. We never see the heartbeat.

Your device reads someone's body. Then your AI turns that reading into a claim. PPR proves that reading came from a real sensor on the body, went through the right device, came from the right person, was not cut up or edited, and was read by the model you said read it. It is signed with ML-DSA-65 (FIPS 204), the government's post-quantum signature standard, and anyone can check it offline.

You keep your data. We keep the proof.

The wall: the raw physiological signal never touches Hive. We fingerprint it on your side, inside your own systems. Only fingerprints and pass/fail results cross over to us. Never a sample, never the actual reading, never the secret key. Our automated tests check this every time we ship code.

Device attestation says valid. PPR says broken.

A real sensor turned on and passed its own check. Then someone cut out a bad night before the review. Device attestation cannot catch that. PPR can, because every time slice is linked to the one before it.

Device / SDK attestation
✅ VALID

Real sensor. Cert chain Device→Vendor→Root checks out. Firmware measurement MATCH. Revocation GOOD. The device really did turn on clean.

✓ hardware genuine
✓ cert chain valid
✓ firmware measured
Stream contents: not checked
Hive PPR
❌ BROKEN

Signal stream was cut at interval 2,847. The timestamps no longer line up next to each other, and the chain does not match when checked independently.

✓ origin healthy
✓ challenge fresh
✓ subject bound
✗ stream:chain_break@seq2847

It works the same way for every attack below. The device still "passes." PPR fails. And the same receipt fails the same way no matter who checks it, the patient or the party relying on the data.

Eight ways to fake it. PPR catches all eight.

These are our test cases and our demo, all in one. For every attack, device attestation passes and PPR fails. All 19 of 19 tests pass in the reference build.

01 · Synthetic injection

Software feeds a made-up waveform into a real pipeline. There is no valid signal from a real sensor, so the origin check fails.

02 · Proxy wear

A friend wears the band instead of you. The on-body signal has a gap, so the check that ties the reading to you fails.

03 · Stream splice

Cut out a bad night before review. The remaining time slices don't link up, and the timestamps don't match.

04 · Duplication

Copy a healthy week over a bad one. The sample counts and timestamps collide, and that breaks the chain.

05 · Replay

Show an old healthy month as if it were today. Our fresh challenge code is missing from the origin fingerprint, so it fails.

06 · Model substitution

A cheaper model actually produced the answer. The model's identity doesn't match, so the fingerprint check fails.

07 · Inference alteration

Someone edits the output after the model ran. The output fingerprint no longer matches.

08 · Wrong-interval attribution

Someone claims the answer came from a different time window. The stream doesn't match up with that claimed window.

We never see a heartbeat.

We can't hold your data, and that's built into the system, not just a promise we make. Our tests fail on purpose if any of our own code even tries to touch a raw sample, a real reading, or a secret key.

We fingerprint on your side. Only fingerprints cross the line.

Your trust boundary
Raw signal, secret keys, and the actual reading

This is the health app, hospital, or trial sponsor. We fingerprint the data here. Nothing raw ever leaves.

▟ THE WALL ▙
commitments +
verdicts only
Hive (attestor)
Signs the fingerprints and issues the receipt

We hold no signal. We can't open a fingerprint, because the secret key never crossed over to us.

Not a diagnosis

Nothing in PPR checks whether the medical answer is correct. PPR proves where the data came from, who had it, and that it wasn't broken up. It never assesses if the conclusion is right.

Not biometric identity

Checking that the sensor stayed on the body just spots gaps, it does not identify you. We prove the device kept being worn, not who is wearing it.

Not possession

Hive never holds the raw signal, the actual reading, or the secret keys. Checking a receipt happens fully offline, with zero network calls, and our tests make sure of it.

The five checks in every receipt

Every reading lives inside a time window, linked together in a chain. Break any link and the check fails. The trust level is locked into the origin check from the start, so nobody can relabel it later.

# O locks in where the sensor reading came from. The trust level is baked in here and matters a lot.
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 time slice locks in a fingerprint of the one before it.
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ᵢ links each step to the one before it across the whole time window
Kᵢ  = commit(O ‖ B ‖ Sⱼ ‖ I ‖ Kᵢ₋₁)
Receipt = Sign_MLDSA65(O ‖ B ‖ Sⱼ ‖ I ‖ Kᵢ ‖ epoch_metadata)

interval_commitment and output_commit are worked out on your side, using your own secret key. That secret key never leaves your side. Hive only signs the fingerprints.

Honest from the start

Version 1 ships with one trust level, and we say so plainly. That level is locked into the origin check, so nobody can sell it as something stronger than it is. Anyone relying on the receipt can set a minimum trust level and reject anything weaker.

Tierv1 trust floor for the capture assertionStatus
holder-ingest-signedThe holder's ingest key confirms the signal came in through the device's software, not the device's hardware chip itself. This is what version 1 ships.v1 · shipping
secure-element-signedThe device's own secure chip signs the capture proof. Same receipt format, a stronger baseline.the upgrade

Every verification banner states the trust level in plain language. If a holder-ingest receipt gets passed off as secure-element, verification fails.

Real numbers

These numbers came from running the real code, not from a marketing slide. The ML-DSA-65 sizes match the FIPS 204 spec exactly.

413k/s
commit() throughput: 2.4µs each
106k/s
interval sealing: 500 samples, checked and chained, each
8.8ms
ML-DSA-65 verify: per receipt
3,309B
signature size: public key 1,952 B, FIPS 204

All 19 of 19 tests pass: 8 attack types, a model-swap test, the normal working case, and 9 more checks (that we hold no data, offline verify works, trust levels can't be relabeled, we never diagnose, and fingerprints don't reveal the real data). The origin evidence in the reference build is flagged simulated=true until it's wired up to a live device attestation feed. We never fake a receipt.

Who needs proof they can't fake

Clinical trials

Prove wearable results came from the enrolled patient, on their body, with nothing cut out. The sponsor and the regulator can check this without ever seeing the raw signal.

Remote patient monitoring

Tie each risk reading to a real capture stream. Catch made-up data, someone else wearing the device, and after-the-fact edits before they ever reach a patient chart.

Insurance & wellness

Wearable programs that need to know the steps, sleep, and heart rate were real, without the insurer ever holding the raw data.

Pilot PPR

If you capture body sensor data and someone downstream has to trust the reading, PPR is the receipt that holds up under audit.

PPR: Physiological Provenance Receipt. Patent Pending. Signed with post-quantum ML-DSA-65 (FIPS 204), and anyone can check it offline. Hive never sees a raw physiological sample.

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.