Does Traverse support streaming?
Not in v0.7.0. Traverse currently uses a request-response model: you call a capability with an input, the WASM binary runs to completion, and you get back a complete output. There is no incremental or streaming output in this version.
Why the current model is request-response
The contract model is designed around complete, validated inputs and outputs. Preconditions validate the full input before execution starts. Postconditions validate the full output after execution completes. Streaming complicates both of these — you cannot validate a partial output against a schema that expects a complete document.
For most business logic use cases — pricing calculations, eligibility checks, rule evaluations — request-response is the right model anyway. The computation finishes in milliseconds and you want the validated result.
Where streaming matters
Streaming becomes relevant for the AI pipeline placement target. When a capability is generating text or processing large datasets and feeding results incrementally to an AI agent, waiting for the full output before returning anything adds unnecessary latency. The roadmap includes streaming support specifically for this context.
What streaming in Traverse would look like
The design challenge is handling postconditions on streamed output. One approach is to validate each chunk against a chunk schema rather than a document schema. Another is to run postconditions on the complete assembled output after the stream ends. The exact design has not been finalized. If you have a use case that needs streaming, open a GitHub issue — real-world requirements help shape the design.
Events as an alternative
Traverse does support emitting events during capability execution via the emitting_events state. Events are not the same as streaming output, but they can communicate progress or intermediate results back to the caller without blocking on full completion. See how Traverse handles events for more.
See the roadmap for the current status of streaming support.