Where Traverse is going.

This is the public roadmap. It is honest about what ships now, what is next, and what is further out. Nothing moves to planned without an approved governing spec.

Track live progress on the GitHub Projects board →

Shipping now

v0.7.0
Core runtime
Contract validation, WASM execution, trace production. The engine everything else runs on.
CLI
Build, run, validate, and inspect capabilities from the command line.
MCP server
Exposes capabilities as tools for AI agents. Contracts are machine-readable. Traces are queryable.
Browser adapter
Run WASM capabilities in the browser with JavaScript bindings. No round-trip for business logic.
React demo
Working example of browser-side capabilities in a React app.
Expedition example
End-to-end example domain showing contract governance, execution, and tracing in a real scenario.
9 governing specs
Every shipped component has a machine-readable spec. The codebase is navigable by humans and AI agents.
100% coverage on core crates
traverse-contracts, traverse-registry, and traverse-runtime are coverage-gated in CI. The CLI's HTTP surface and the MCP server are not yet gated — see the security audit.

Next

v0.8.x
Edge executor adapter
planned

Run capabilities at the edge. Same WASM binary, same contract. Cloudflare Workers and similar targets in scope.

executor / edge
Python SDK (experimental)
planned

Call Traverse capabilities from Python. Useful for data pipelines, ML workflows, and teams that do not write Rust.

sdk / python
Expanded trace querying
planned

More expressive queries against trace artifacts. Filter by capability, outcome, contract clause, and time range. CLI and MCP both benefit.

tracing / cli
Performance benchmarks page
planned

Real numbers for real workloads. Contract validation overhead, execution latency by environment, and comparisons against baseline approaches.

docs / perf
Additional example domains
planned

More working examples beyond Expedition. Pricing rules, eligibility checks, validation pipelines. Each one governed by a spec and fully tested.

examples

Later

exploring
Cloud executor adapter
exploring

Native cloud deployment for capabilities. AWS Lambda and similar targets. The same binary that runs in browser or at edge, now in cloud.

executor / cloud
AI-pipeline placement target
exploring

First-class support for capabilities that run inside AI pipelines as governed tools. Builds on the MCP foundation with richer placement declarations.

ai / placement
Multi-agent orchestration
exploring

Coordinate multiple agents calling governed capabilities. Conflict prevention via contract constraints. No two agents can violate the same rule in the same execution.

ai / orchestration
Governance dashboard
exploring

Visual interface for exploring capabilities, their contracts, and trace history. Designed for teams that need to audit what ran and why.

observability
Extended SBOM tooling
exploring

Software bill of materials for capabilities. Know exactly what is in each WASM binary, what contracts govern it, and what versions are in production.

security / sbom
Device executor
exploring

Run capabilities on-device. Mobile and embedded targets. The portability story extends all the way to the hardware layer.

executor / device
Principles that govern this roadmap
01
Spec before code. Every item on this roadmap requires an approved governing spec before any implementation starts. The spec defines what the feature does, what inputs it takes, what constraints apply, and how it integrates with the rest of the system.
02
No feature ships without test coverage. The 100% coverage bar is not a target. It is a floor. Anything that ships must maintain it.
03
Community input is welcome. Have a use case that is not covered? Open an issue on GitHub. Feature requests that come with a clear problem statement and a proposed spec have the best chance of moving forward.
04
Honest sequencing. Items in "exploring" are not commitments. They are directions worth thinking about. If circumstances change, the roadmap changes too.
Have a feature request?

Open an issue on GitHub. A clear problem statement and a proposed spec is the fastest path to getting something on the roadmap.

Open an issue Read the docs