Verification you can trust

Tamper-evident by design, and honest about the edges.

It is the last night of a season. A single result decides who makes the cut, and the cut is worth something real — a ranking, a prize, a spot in a final. Somewhere out there, someone looks at that result and thinks: I could change that. Edit the clip. Re-run last week's better session as if it were tonight's. Nudge the number after the fact. This is not cynicism; it is the ordinary consequence of a score that matters. The instant a result is worth having, it is worth faking.

A verification system that only works when nobody tries is not a verification system. So the question we design the Kinetic Truth Engine™ around is not the impossible one — "can this be attacked?" — because everything can. It is the useful one: "if it is attacked, will we be able to tell?" This piece explains our answer — results are cryptographically signed at the device and tamper-evident — why we choose that word and never "unhackable," why we publish confidence instead of certainty, and where the genuine open problems still are.

How we make a result checkable

The building block is the digital signature, the idea that grew out of Diffie and Hellman's "New Directions in Cryptography" (1976). A signature binds a specific set of bytes to a key so tightly that changing any of the bytes breaks the binding. You do not have to trust that a signed record is untouched; you can check it, and the check is cheap and exact. Change one value after signing — a score, a frame, a timestamp — and the signature no longer matches. The record carries its own proof of whether it is still the thing that was signed.

The crucial engineering choice is where the signing happens. We do it at the device, at the moment of capture, using keys held in the phone's hardware-backed secure element — the Secure Enclave on one platform, the hardware-backed keystore on the other — so the signing key never leaves protected hardware. This gives us a chain of custody that starts at the lens: the session's telemetry and result are sealed at the source and remain checkable at every hand-off afterward, all the way to the leaderboard. It is the same principle behind emerging media-provenance standards like C2PA and Content Credentials — sign at creation, verify anywhere.

  SIGNED @ DEVICE

        ┌───────┐
        │       │      ┌───────────┐
     ┌──┴───────┴──┐   │ ✓ SEALED  │
     │ ▓▓▓▓▓▓▓▓▓▓▓ │   └───────────┘
     │ ▓▓▓▓ ● ▓▓▓▓ │   tamper-evident:
     │ ▓▓▓▓▓▓▓▓▓▓▓ │   any change shows
     └─────────────┘

  sealed at the source · checkable

Assume it will be attacked

The right security posture is old and unglamorous: Kerckhoffs's principle says a system should stay secure even if everything about how it works is public — security must not rest on the attacker's ignorance. We assume the design is known and that people will probe every seam. The design question becomes: where is the record most exposed, and does an attack there leave a mark?

This is exactly why signing at the device matters, and the intervention is easy to reason about. Compare two designs. In the first, the record is signed only once it reaches a server; in the second, it is signed at the phone at capture. Now imagine altering the record at each step along the way — on the device, in transit, in storage. Under server-side signing, everything before the server is an unguarded stretch of road: a change made there gets signed as if it were genuine, and no later check can see it. Under device-side signing, the seal is already in place, so a change anywhere downstream breaks the check and announces itself. The earlier you sign, the shorter the unguarded road.

There is a subtle payoff to signing in hardware worth spelling out. Because the private key that produces the seal lives in the phone's secure element and is designed never to leave it, even we — the people who built the system — cannot mint a valid signature for a session a device did not actually produce. That is deliberate. An integrity model where the operator holds a master key is one where you are ultimately trusting the operator to behave; an integrity model where the key stays on the user's device is one where the math, not our good conduct, is doing the work. We would rather be held to the math.

Tamper-evident, not tamper-proof

Notice the exact promise. The seal does not make a record impossible to change; it makes a change impossible to hide. That distinction is the whole thing, and it is why you will never hear us say unhackable, unspoofable, or impossible to fake. Those words are a tell. Any engineer who has shipped a real system knows that absolute security claims are the ones that age worst, usually in public. What a well-built integrity system honestly delivers is not the impossibility of tampering — it is the near-certain detection of it. And detection is enough to do the job: make cheating visible and attributable, and you remove most of the reason to attempt it, without lying about physics you do not control.

Why we show our work

A tamper-evident system is only as trustworthy as its verifier, which is why we lean on public, well-understood cryptographic methods rather than a private scheme of our own. This is the practical face of Kerckhoffs's principle: a result you can check with standard tools, whose integrity does not depend on keeping the mechanism secret, is one an outsider can audit without taking our word for anything. The signed record, its confidence, and any human adjudication are retained together, so a contested result can be re-examined after the fact by someone who was not in the room. "Trust us" is not an integrity model. "Here is the record; check it yourself" is.

This posture also disciplines us. A system you invite others to check is one you cannot quietly cut corners in, because the corners are inspectable. Publishing how verification actually works — in pieces like this one — is part of the same commitment: the mechanism should be able to withstand being understood, not merely being marketed.

Freshness is part of the seal

Signing proves a record was not altered after capture, but on its own it says nothing about when the capture happened — and "when" matters, because the cheapest attack on a live result is not to forge a new one but to replay a genuine old one. So the seal binds more than the pixels and the score. It binds context that makes a session hard to lift out of its moment: a device-held timestamp, a one-time value issued for that specific attempt (a nonce), and the identity of the challenge and session it belongs to. A signed clip from last week does not satisfy this week's one-time value, so it cannot be presented as this week's play. Freshness does not solve the deeper liveness problem below — whether the camera saw a real human at all — but it closes the simplest replay, and it is part of what the seal actually covers.

Publish confidence, not certainty

Integrity — is this the untouched record? — is a different question from accuracy — did the system read the moment correctly? We are careful about both, and especially careful never to claim perfection on the second, because verification is estimation under uncertainty. A camera captures a projection of the world; a model reads that projection; people resolve what the model finds ambiguous. Each stage carries irreducible uncertainty.

A system that prints a clean, perfect-sounding answer on every play is not more accurate than one that reports honest doubt — it is merely hiding the doubt, which is the most dangerous kind, because hidden doubt looks exactly like confidence until the moment it is wrong. The discipline that replaces false certainty is calibration: a confidence score is well-calibrated when things it calls "90% likely" happen about nine times in ten. Calibration is measurable — proper scoring rules like the Brier score grade a probabilistic forecast against what actually occurred — so "how honest is the confidence?" is itself something we can track and improve. What that buys in practice is control: if the system's 80%-confident calls really are right about eight times in ten, a threshold on confidence has a predictable meaning — raise it and fewer questionable results stand at the cost of more escalations, lower it and the reverse. A false "100%" offers no such dial, only an assertion, which is one more reason we prefer an honest number we can tune to a perfect one we would have to defend. The engine acts on that confidence: clear calls stand; low-confidence and genuinely close sessions escalate to CORE, our distributed network of independent event labelers, where independent reviewers resolve them (the mechanism is its own subject).

Humans stay in the loop, and we disclose it. "No human ever sees your video" is a claim some systems make; it is not one we can or want to make, because the human judgment is part of what makes the result trustworthy in the first place.

The open frontier: proving liveness

Here is the honest edge of the current design. A signature proves a record has not been altered after capture. It does not, by itself, prove that what the camera saw at capture was a live human doing the thing — rather than a high-quality screen held in front of the lens, or a genuine older clip replayed as if it were happening now. That family of attacks has a name in the security literature — presentation and replay attacks — and a whole standard devoted to defending against them, ISO/IEC 30107 on presentation-attack detection. We invest heavily in liveness and freshness signals, but we describe this as an arms race rather than a solved problem, because that is what it is.

The defenses are layered rather than singular. Freshness kills naive replay. Challenge-response — asking for a specific action the attacker could not have pre-recorded — raises the cost of presenting a canned clip. Consistency checks look for the tells of a screen-of-a-screen or an edited splice. And the confidence gate feeds the human loop: sessions that look off are exactly the ones that escalate to independent reviewers. None of these is a silver bullet, and we are careful not to describe any of them as one; together they raise the effort an attack requires, which is the honest goal. The day we claim this problem is finished is the day you should stop trusting us on it.

Other results

• Keys live in hardware, not in our reach. Because signing keys stay in the phone's secure element, a session is bound to the device that produced it in a way that even we cannot forge after the fact.
• Provenance is interoperable by design. Building on the same sign-at-creation model as open content-provenance standards means a verified session's integrity can be checked with well-understood, public methods rather than a private black box — which is the Kerckhoffs posture in practice.
• The chain of custody is auditable. The signed record, the confidence, and any human adjudication are retained together, so a result can be re-examined after the fact rather than taken on faith.
• Honesty about the human loop is a feature. Disclosing that people review the hard cases is not a caveat we bury; it is part of the integrity story, and it is legally disclosed.

What's next

Trust is not a feature you ship once; it is a discipline you keep. The near-term work is stronger liveness, a tighter chain of custody, better-calibrated confidence, and clearer ways to show a person why a result stands. The reason any of it matters is the mission underneath:

Every one of those sports has to be able to say, honestly, exactly how far the verification goes and where it stops. That is what verification you can trust means: not a perfect number, but an honest one — sealed at the source, checkable by anyone, and candid about its own edges.