Before any audio reaches a worker, the coordinator slices it into 60-second fragments. Each fragment goes to a different machine. No single worker receives enough audio to reconstruct the original.
Even if a worker is compromised, it should only ever see non-adjacent slices. That makes reconstruction materially harder.
Hidden canaries and reputation scoring let HiveCompute validate output without assuming any worker is trustworthy on day one.
New workers start at zero trust. Their early output can be verified by a second independent worker before it is accepted.
The coordinator occasionally swaps in known-answer audio. Workers do not know when they are being tested, which makes gaming the system harder.
Workers build up from new to provisional to trusted to elite. Bad output lowers reputation and reduces future work.
No. Shards are short, adjacent clips are intentionally split across different workers, and a worker does not receive the merged transcript.
The worker still only has a short clip with no identifying metadata. Hidden canaries and reputation scoring make low-quality or malicious behavior easier to detect and remove.
In transit, yes. Audio and transcripts move over HTTPS. At rest, the transcript sits in the coordinator database behind your API access controls.
Not yet. The pilot is designed for teams that want lower cost and good privacy boundaries, but it is not represented as HIPAA-certified today.
The local worker code is public. You can read exactly what runs on your machine — how it polls, what it sends back, and how audio is handled.