A streamed answer is the hardest kind of output to hold anyone to, because the bytes arrive over time and nothing fixes what was promised at the start.
Foretoken™ commits to a run before or at the same moment the first streamed content leaves the model. It carries an incremental digest as content flows, then seals a terminal attestation tied back to that opening commitment. The seal cannot be produced after the fact.
Post hoc receipts sign a finished body of text. That works when the response is a single object. It stops working the moment the response is delivered incrementally, because every guarantee is written after the whole thing is already known.
A signature applied at the end can only describe the bytes that survived. Anything revised, retried, or swapped before the close is invisible to it.
Holding the full response in memory to hash it defeats the point of streaming. The first token is late and the latency budget is gone.
Real streams get cancelled, time out, and fail upstream. A scheme that only produces evidence on a clean close produces nothing for the cases that matter most.
Three bindings, placed at the only three moments that carry evidentiary weight in a stream.
Before the first streamed content leaves the model, or concurrently with it, the run is committed: request identity, model and build identity, and the parameters that govern the generation. The commitment is fixed while the outcome is still unknown.
Each delta folds into a running digest as it is emitted. The full response is never buffered. Memory stays flat regardless of response length, and the hot path is not held up waiting for a hash of something that has not finished arriving.
At the close, the final seal binds the accumulated digest back to the opening pre-commitment. A verifier checks that the thing that ended is the thing that was promised, and that no separate run was substituted along the way.
Non-backfillable. The terminal attestation is only valid against a pre-commitment that already existed. There is no way to observe a finished response and then mint the opening commitment that would have covered it, because the commitment is fixed and witnessed before the content is known.
A stream that dies halfway is still an event someone may have to account for. Foretoken™ treats every ending as a sealable outcome, and records which ending occurred.
| Ending | What is sealed | Evidence state |
|---|---|---|
| Normal completion | Full accumulated digest bound to the pre-commitment, with the emitted unit count. | Sealed |
| Client cancellation | Digest of the content actually emitted up to the cancel point, plus the termination cause. | Sealed |
| Upstream error | Partial digest, the point of failure, and the error condition reported by the provider. | Sealed |
| Timeout or dropped connection | Partial digest and the last unit successfully emitted before the stream stopped. | Sealed |
In every row the pre-commitment already exists, so a truncated stream is still attributable to a specific run with specific declared parameters. A missing terminal attestation is itself meaningful: it says the stream never reached a sealed ending.
Foretoken™ is the streaming counterpart to the whole response receipt. It is one of four families filed on July 31, 2026, alongside Stipryn™, Multi-Source Divergence Detection (MSDD), and Bonded Performance Attestation (BPA).
Commits to a streamed run before the first token and seals it at the close.
Fixes the required proof level before a request is transmitted. Read
Binds asserted and separately observed values without merging them. Read
Binds a declared performance budget and the actual distribution to the same response. Read
Foretoken™ is filed work and is not yet a public endpoint. The receipt discipline underneath it is live now: canonicalize, hash, sign, verify, and check it yourself in the browser.
Foretoken™. Patent pending, filed July 31, 2026. Streamed response pre-commitment, incremental digest without full buffering, and terminal attestation bound to the opening commitment. Hive Civilization Inc.