NeccessoryNeccessory
Cloud

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
}
originattestedWho computed the numbers
Cloud measurement"cloud"trueOur inference service
On-device measurement"on_device"falseThe 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 final event 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.