\n
\n \n v0.7.0 · Apache 2.0 · Open source\n
\n
\n Define once.
Run anywhere.\n
\n
\n Traverse is a contract-driven WASM runtime. Write business logic once with a machine-readable contract and run it identically across browser, edge, cloud, and AI pipelines.\n
\n
\n
\n
It was created by Enrico Piovesan. The project is related to Contract-Driven AI Development (C-DAD), which applies the same contract-first approach to AI agent pipelines.
\n\n Current state
\n Traverse is at v0.7.0. It ships with a working expedition planning example that demonstrates 6 capabilities, 5 events, and 1 workflow running locally. The runtime, registry, CLI, browser adapter, and MCP integration are all functional. The codebase is open source under the Apache 2.0 license at github.com/traverse-framework/traverse.
\n\n Core crates
\n \n - traverse-runtime — the execution engine
\n - traverse-contracts — contract definition and validation
\n - traverse-registry — capability discovery and indexing
\n - traverse-cli — terminal interface for inspecting and running
\n - traverse-mcp — Model Context Protocol integration for AI pipelines
\n - traverse-expedition-wasm — the canonical example capabilities
\n
\n\n If you want to see it running in under 15 minutes, start with the quickstart guide.
";
-const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What is Traverse?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Traverse is a contract-driven Rust and WASM runtime. You define business capabilities once as WebAssembly modules governed by machine-readable contracts, and run the same binary across browser, edge, cloud, and AI pipelines. The runtime validates inputs and placement before execution and produces a trace artifact for every run. It is built on Universal Microservices Architecture (UMA) by Enrico Piovesan, currently at v0.7.0 under the Apache 2.0 license.\"}}]}";
+const _body = "Traverse is a contract-driven Rust and WASM runtime for device-independent capabilities. You define a capability once, and the same WASM binary runs on any client without modification. Execution happens on the client by default. If the client decides to — based on its own heuristics, like resource constraints or latency — it can delegate a subset of that capability to run on the server instead.
\n\n The problem it solves is simple to state but hard to fix: teams write the same business logic multiple times. Pricing logic lives in the frontend, re-implemented in the backend API, and copied again into a data pipeline or AI agent. Every copy drifts. Bugs appear in one place but not another. The environments are different enough that sharing code feels impractical.
\n\n Traverse takes a different approach. You write the logic once in Rust, compile it to WebAssembly, and attach a machine-readable contract. The contract says what the capability does, what must be true before it runs, where it is allowed to run, and what constraints apply. The runtime enforces all of that. The client evaluates the contract against its own context and decides where each part of the capability runs — locally by default, with server delegation as a heuristic-driven fallback for the parts that need it, not a fixed deployment target chosen ahead of time.
\n\n What makes it different
\n Most portability solutions stop at packaging. They let you deploy the same code to multiple environments, but they do not govern how it is called. Traverse adds governance at the call layer. You cannot invoke a capability with invalid inputs. You cannot place it on a target it does not support. Every execution produces a trace artifact, a structured record of what ran, what the inputs were, which contract governed it, and what the output was.
\n\n That trace is not a log. It is a first-class artifact you can inspect, store, and reason about. It connects the AI era's demand for explainability directly to the execution layer.
\n\n Where it came from
\n Traverse is built on Universal Microservices Architecture (UMA), a design philosophy developed at universalmicroservices.com. UMA treats capabilities as portable, contract-governed units that are not tied to any single deployment environment. Traverse is the Rust and WASM implementation of that idea.
\n\n It was created by Enrico Piovesan. The project is related to Contract-Driven AI Development (C-DAD), which applies the same contract-first approach to AI agent pipelines.
\n\n Current state
\n Traverse is at v0.7.0. It ships with a working expedition planning example that demonstrates 6 capabilities, 5 events, and 1 workflow running locally. The runtime, registry, CLI, browser adapter, and MCP integration are all functional. The codebase is open source under the Apache 2.0 license at github.com/traverse-framework/traverse.
\n\n Core crates
\n \n - traverse-runtime — the execution engine
\n - traverse-contracts — contract definition and validation
\n - traverse-registry — capability discovery and indexing
\n - traverse-cli — terminal interface for inspecting and running
\n - traverse-mcp — Model Context Protocol integration for AI pipelines
\n - traverse-expedition-wasm — the canonical example capabilities
\n
\n\n If you want to see it running in under 15 minutes, start with the quickstart guide.
";
+const _jsonLd = "{\"@context\": \"https://schema.org\", \"@type\": \"FAQPage\", \"mainEntity\": [{\"@type\": \"Question\", \"name\": \"What is Traverse?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Traverse is a contract-driven Rust and WASM runtime for device-independent capabilities. You define a capability once as a WebAssembly module governed by a machine-readable contract, and the same binary runs on any client without modification. Execution happens on the client by default; the client can heuristically delegate a subset of the capability to the server when it decides to. The runtime validates inputs and placement before execution and produces a trace artifact for every run. It is built on Universal Microservices Architecture (UMA) by Enrico Piovesan, currently at v0.7.0 under the Apache 2.0 license.\"}}]}";
---
\n\n \n
Roadmap\n
Where Traverse is going.
\n
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. Nothing ships without test coverage.
\n
\n\n \n
\n \n\n
\n
\n
\n
\n
Core runtime
\n
Contract validation, WASM execution, trace production. The engine everything else runs on.
\n
\n
\n
\n
\n
\n
CLI
\n
Build, run, validate, and inspect capabilities from the command line.
\n
\n
\n
\n
\n
\n
MCP server
\n
Exposes capabilities as tools for AI agents. Contracts are machine-readable. Traces are queryable.
\n
\n
\n
\n
\n
\n
Browser adapter
\n
Run WASM capabilities in the browser with JavaScript bindings. No round-trip for business logic.
\n
\n
\n
\n
\n
\n
React demo
\n
Working example of browser-side capabilities in a React app.
\n
\n
\n
\n
\n
\n
Expedition example
\n
End-to-end example domain showing contract governance, execution, and tracing in a real scenario.
\n
\n
\n
\n
\n
\n
9 governing specs
\n
Every shipped component has a machine-readable spec. The codebase is navigable by humans and AI agents.
\n
\n
\n
\n
\n
\n
100% coverage on core crates
\n
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.
\n
\n
\n
\n
\n\n \n
\n \n\n
\n\n
\n
\n
Edge executor adapter
\n
planned\n
\n
Run capabilities at the edge. Same WASM binary, same contract. Cloudflare Workers and similar targets in scope.
\n
executor / edge\n
\n\n
\n
\n
Python SDK (experimental)
\n
planned\n
\n
Call Traverse capabilities from Python. Useful for data pipelines, ML workflows, and teams that do not write Rust.
\n
sdk / python\n
\n\n
\n
\n
Expanded trace querying
\n
planned\n
\n
More expressive queries against trace artifacts. Filter by capability, outcome, contract clause, and time range. CLI and MCP both benefit.
\n
tracing / cli\n
\n\n
\n
\n
Performance benchmarks page
\n
planned\n
\n
Real numbers for real workloads. Contract validation overhead, execution latency by environment, and comparisons against baseline approaches.
\n
docs / perf\n
\n\n
\n
\n
Additional example domains
\n
planned\n
\n
More working examples beyond Expedition. Pricing rules, eligibility checks, validation pipelines. Each one governed by a spec and fully tested.
\n
examples\n
\n\n
\n
\n\n \n
\n \n\n
\n\n
\n
\n
Cloud executor adapter
\n
exploring\n
\n
Native cloud deployment for capabilities. AWS Lambda and similar targets. The same binary that runs in browser or at edge, now in cloud.
\n
executor / cloud\n
\n\n
\n
\n
AI-pipeline placement target
\n
exploring\n
\n
First-class support for capabilities that run inside AI pipelines as governed tools. Builds on the MCP foundation with richer placement declarations.
\n
ai / placement\n
\n\n
\n
\n
Multi-agent orchestration
\n
exploring\n
\n
Coordinate multiple agents calling governed capabilities. Conflict prevention via contract constraints. No two agents can violate the same rule in the same execution.
\n
ai / orchestration\n
\n\n
\n
\n
Governance dashboard
\n
exploring\n
\n
Visual interface for exploring capabilities, their contracts, and trace history. Designed for teams that need to audit what ran and why.
\n
observability\n
\n\n
\n
\n
Extended SBOM tooling
\n
exploring\n
\n
Software bill of materials for capabilities. Know exactly what is in each WASM binary, what contracts govern it, and what versions are in production.
\n
security / sbom\n
\n\n
\n
\n
Device executor
\n
exploring\n
\n
Run capabilities on-device. Mobile and embedded targets. The portability story extends all the way to the hardware layer.
\n
executor / device\n
\n\n
\n
\n\n
\n
Principles that govern this roadmap
\n
\n
\n
01
\n
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.
\n
\n
\n
02
\n
No feature ships without test coverage. The 100% coverage bar is not a target. It is a floor. Anything that ships must maintain it.
\n
\n
\n
03
\n
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.
\n
\n
\n
04
\n
Honest sequencing. Items in \"exploring\" are not commitments. They are directions worth thinking about. If circumstances change, the roadmap changes too.
\n
\n
\n
\n
\n
\n
Have a feature request?
\n
Open an issue on GitHub. A clear problem statement and a proposed spec is the fastest path to getting something on the roadmap.
\n
\n
\n
\n\n
\n
Roadmap\n
Where Traverse is going.
\n
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.
\n
Track live progress on the GitHub Projects board →
\n
\n\n
\n\n \n
\n \n\n
\n
\n
\n
\n
Core runtime
\n
Contract validation, WASM execution, trace production. The engine everything else runs on.
\n
\n
\n
\n
\n
\n
CLI
\n
Build, run, validate, and inspect capabilities from the command line.
\n
\n
\n
\n
\n
\n
MCP server
\n
Exposes capabilities as tools for AI agents. Contracts are machine-readable. Traces are queryable.
\n
\n
\n
\n
\n
\n
Browser adapter
\n
Run WASM capabilities in the browser with JavaScript bindings. No round-trip for business logic.
\n
\n
\n
\n
\n
\n
React demo
\n
Working example of browser-side capabilities in a React app.
\n
\n
\n
\n
\n
\n
Expedition example
\n
End-to-end example domain showing contract governance, execution, and tracing in a real scenario.
\n
\n
\n
\n
\n
\n
9 governing specs
\n
Every shipped component has a machine-readable spec. The codebase is navigable by humans and AI agents.
\n
\n
\n
\n
\n
\n
100% coverage on core crates
\n
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.
\n
\n
\n
\n
\n\n \n
\n \n\n
\n\n
\n
\n
Edge executor adapter
\n
planned\n
\n
Run capabilities at the edge. Same WASM binary, same contract. Cloudflare Workers and similar targets in scope.
\n
executor / edge\n
\n\n
\n
\n
Python SDK (experimental)
\n
planned\n
\n
Call Traverse capabilities from Python. Useful for data pipelines, ML workflows, and teams that do not write Rust.
\n
sdk / python\n
\n\n
\n
\n
Expanded trace querying
\n
planned\n
\n
More expressive queries against trace artifacts. Filter by capability, outcome, contract clause, and time range. CLI and MCP both benefit.
\n
tracing / cli\n
\n\n
\n
\n
Performance benchmarks page
\n
planned\n
\n
Real numbers for real workloads. Contract validation overhead, execution latency by environment, and comparisons against baseline approaches.
\n
docs / perf\n
\n\n
\n
\n
Additional example domains
\n
planned\n
\n
More working examples beyond Expedition. Pricing rules, eligibility checks, validation pipelines. Each one governed by a spec and fully tested.
\n
examples\n
\n\n
\n
\n\n \n
\n \n\n
\n\n
\n
\n
Cloud executor adapter
\n
exploring\n
\n
Native cloud deployment for capabilities. AWS Lambda and similar targets. The same binary that runs in browser or at edge, now in cloud.
\n
executor / cloud\n
\n\n
\n
\n
AI-pipeline placement target
\n
exploring\n
\n
First-class support for capabilities that run inside AI pipelines as governed tools. Builds on the MCP foundation with richer placement declarations.
\n
ai / placement\n
\n\n
\n
\n
Multi-agent orchestration
\n
exploring\n
\n
Coordinate multiple agents calling governed capabilities. Conflict prevention via contract constraints. No two agents can violate the same rule in the same execution.
\n
ai / orchestration\n
\n\n
\n
\n
Governance dashboard
\n
exploring\n
\n
Visual interface for exploring capabilities, their contracts, and trace history. Designed for teams that need to audit what ran and why.
\n
observability\n
\n\n
\n
\n
Extended SBOM tooling
\n
exploring\n
\n
Software bill of materials for capabilities. Know exactly what is in each WASM binary, what contracts govern it, and what versions are in production.
\n
security / sbom\n
\n\n
\n
\n
Device executor
\n
exploring\n
\n
Run capabilities on-device. Mobile and embedded targets. The portability story extends all the way to the hardware layer.
\n
executor / device\n
\n\n
\n
\n\n
\n\n \n
\n
Principles that govern this roadmap
\n
\n
\n
01
\n
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.
\n
\n
\n
02
\n
No feature ships without test coverage. The 100% coverage bar is not a target. It is a floor. Anything that ships must maintain it.
\n
\n
\n
03
\n
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.
\n
\n
\n
04
\n
Honest sequencing. Items in \"exploring\" are not commitments. They are directions worth thinking about. If circumstances change, the roadmap changes too.
\n
\n
\n
\n\n
\n
\n
\n
Have a feature request?
\n
Open an issue on GitHub. A clear problem statement and a proposed spec is the fastest path to getting something on the roadmap.
\n
\n
\n