Capture Commitment · capture.commitment
You commit the audio once, in ordered one second frames, under a secret salt. Later you can hand someone a single clip and prove it sat at exact offsets inside the longer recording, and say how many seconds stayed closed on each side of it. Hive never receives the audio.
Live in production
Almost nobody disputes that a clip is real audio. They dispute what was around it. You played twelve seconds. What happened in the ninety seconds before? Did you cut the part where your side agreed to something? Is this even the same call?
That argument is unwinnable today, and the reason is simple: if you hold the file, you control what gets played. Handing over the whole recording is not an answer either. It's often illegal, it's usually confidential, and it hands the other side ninety minutes of material to go fishing in.
So both options are bad. Play the clip and get accused of cutting it, or disclose everything and lose control of it. This receipt is the third option.
At recording time you hash the container, hash the decoded samples, and build a chained commitment over each one second frame under a secret salt. You send the digests. The audio never leaves your side.
The receipt fixes the frame count, the sequence digest, the chain head and the salt commitment at a stated instant, with the clock skew recomputed and bounded.
Later you reveal a single segment. Anyone can recompute the chain and see the clip lands on the committed head at an exact index, with a count of the frames that stayed closed on either side.
Five should verify. Three are attacks and should be refused at a named gate. No key, no account, nothing installed.
The verifier runs every gate in order and stops at the first failure, then tells you which
one stopped it. Three of the demo cases above are built to fail, and they each fail somewhere
specific. A recording that misdeclares its own length stops at
FRAME_COUNT_AGREEMENT. A recording relabeled to point at different audio stops at
DECODED_DIGEST_BINDING. A clip whose disclosure does not account for the whole
recording, which is what excising a section looks like from outside, stops at
SEGMENT_LENGTH_AGREEMENT.
The demo publishes the gate it expects each failing case to stop at, and the runner above compares that against what the API actually returned. If they ever diverge, the page says so instead of hiding it.
| Gate |
|---|
| CANONICAL_FORM_FIXED |
| CANONICAL_LENGTH_AGREEMENT |
| CAPTURECOMMITMENT_BOUNDARY_PRESENT |
| CAPTURE_CLASS_DECLARED |
| COMMITMENT_INSTANT_ORDERED |
| CONTAINER_DIGEST_BINDING |
| DECODED_DIGEST_BINDING |
| DIGEST_DISTINCTNESS |
| FRAME_COMMITMENT_SET_INTEGRITY |
| FRAME_COUNT_AGREEMENT |
| FRAME_SEQUENCE_DIGEST_RECOMPUTE |
| ISSUER_KEY_MATCH |
| NO_MEDIA_LEAK |
| PAYLOAD_DIGEST_VALID |
| POSSESSION_CLASS_DECLARED |
| SALT_BINDING |
| SCHEMA |
| SEGMENT_CHAIN_LANDS_ON_HEAD |
| SEGMENT_CHAIN_RECOMPUTE |
| SEGMENT_DISCLOSURE_FORM |
| SEGMENT_INDEX_RANGE |
| SEGMENT_LENGTH_AGREEMENT |
| SEGMENT_PREFIX_ANCHORED |
| SEGMENT_SUBJECT_PRESENT |
| SIGNATURE_VALID |
| SKEW_BOUND_SATISFIED |
| SKEW_RECOMPUTE |
| SOURCE_DESCRIPTOR_SANE |
Be precise about this, because it's where competing claims get sloppy. Remux the file into a new container and the container digest changes, as it should. The decoded digest, the frame chain and the chain head all stay identical, so the receipt still holds and the clip still proves its position.
A lossy re encode is different. It changes the decoded samples, so none of the digests survive, and this receipt does not claim they do. If you need a claim that survives transcoding, that's a watermark problem, and the published research on audio watermark robustness is not encouraging. This receipt is not a watermark and does not pretend to be one.
The recording is never transmitted and never decoded on our side. The receipt carries an
explicit possession class and custody role saying so, and a NO_MEDIA_LEAK gate that
refuses a receipt carrying media bytes. If we're subpoenaed, we have digests. That's the whole
point.
This is the honesty boundary carried inside every
capture.commitment receipt, verbatim from the signed body.
This receipt fixes what was committed, not what was heard. The recording was never transmitted to the recorder and the recorder never decoded it, so nothing here asserts that the committed digests belong to any particular sound, speaker, event, or file on disk. What is fixed is this: at the stated instant a holder committed a container digest, a decoded digest, and an ordered per second commitment chain over a recording of the stated length, under a secret salt whose commitment is published here. Anyone later holding the recording can recompute all three and show they match, and anyone holding a clip can show it sits at an exact position in that chain with nothing inserted, removed, or reordered around it. No digest here survives a re encode of the audio, and this receipt makes no claim that it does. It is not a detector, not a watermark, not an identification of a voice, and not a statement that the recording is authentic, consented, human, or machine made.
| Route | What it does |
|---|---|
| POST /v1/mint/capture-commitment | Issue a commitment over digests you computed locally |
| POST /v1/verify/capture-commitment | Verify a commitment receipt |
| POST /v1/verify/capture-commitment/segment | Verify that a disclosed clip lands at its claimed position |
| GET /v1/demo/capture-commitment | Eight worked cases, three of them refused |
A capture commitment fixes one recording. Put its receipt in a transparency checkpoint and you also prove the receipt was in the set at a moment an independent timestamp authority signed, so nobody can argue the pile was rebuilt later. Pair it with capability exercise when the question is whether a provider's own detector actually does what its marketing says.
Patent pending. Hive Civilization, The Hivery, Inc.