Attested Results
Why a cloud measurement carries origin and attested, and what those two fields do and do not prove.
Every measurement carries two fields that say who computed the numbers:
{
"origin": "cloud" | "on_device",
"attested": true | false
}origin | attested | Who computed the numbers | |
|---|---|---|---|
| Cloud measurement | "cloud" | true | Our inference service |
| On-device measurement | "on_device" | false | The client, which then submitted the result |
Why the difference is real
In the on-device tier the whole pipeline runs on the user's phone or in their
browser, and the finished result is submitted to
POST /sdk/v1/measurements over a signed request.
The signature proves the submission came from someone holding your key. It proves
nothing about the numbers: whoever controls the client can send any JSON that
passes validation. That is not a flaw in the signature — it is inherent to
computing on a device you do not control.
In the cloud tier the client sends frames, not metrics. Pulse recovery, heart rate, HRV, breathing rate, stress, blood pressure and SpO2 are all computed on our servers, from the pixels we received, and the result is written to the database by the inference service over an internal service channel. The client never gets to state a value. It receives the number; it cannot choose it.
That is what attested: true means: this measurement was produced by
neccessory from data received during a session bound to your key, not asserted
by a client.
Where the fields appear
- In the
finalevent of a streaming session. - In the result of a batch job.
- On every record returned by the REST API and shown in the console.
They are server-owned. The SDK strips them from anything you submit, in the
same way it strips id, keyId and createdAt — a client cannot set
attested: true on a measurement it computed itself. If you write your own
client, do not send them; they will be ignored.
What attestation does not prove
Attestation is about computation, not identity
attested: true says the metrics were computed by us from the frames the session
received. It does not prove who was in front of the camera, that a live human
was in front of the camera at all, that the frames were captured just now, or
that they came from a camera rather than from a file. There is no identity
verification, no liveness check, and no anti-spoofing in this contract.
If your use case needs identity or liveness, you have to add it — attestation sits underneath that, not instead of it. What it does remove is the most common and cheapest attack: a user editing the numbers on the way out.
Reading it in your application
m.onResult((result) => {
if (result.attested) {
// computed by neccessory — safe to treat as a measurement of record
} else {
// computed on the client — treat as self-reported
}
});Do not branch on origin for display logic; the two tiers produce the same
measurement result with the same units and the
same signal-quality rules. Branch on attested only
where the trust level actually matters — screening, insurance, compliance
records, anything a user has an incentive to influence.
An attested measurement is still a wellness estimate. Attestation says the number was computed honestly, not that it is clinically accurate — see the disclaimer.
Next: Limits & errors.