Traverse.
- Contract-driven WASM runtime for portable business capabilities.
+Contract-driven WASM runtime for device-independent business capabilities.
Everything you want to know before you write a single line of code. If something is missing, open an issue on GitHub.
\nTraverse is a runtime that lets you write business logic once in Rust, compile it to WASM, and run it anywhere. Browser, edge, cloud, AI pipeline. Same binary, same behavior, no rewrite.
\nEach capability is wrapped in a machine-readable contract. The runtime checks inputs and outputs against that contract before anything runs. You get a trace artifact showing exactly what happened and why.
\nTo write new capabilities from scratch, yes. Rust compiles to WASM and gives you the control and safety the runtime expects.
\nBut you can call Traverse from JavaScript, Python, or any language with a WASM host. If someone else compiled the capability, you consume it through the SDK without touching Rust at all. The Python SDK is on the roadmap for v0.8.x.
\nv0.7.0 ships with 100% test coverage and 9 governing specs. The core runtime, CLI, browser adapter, and MCP server are all working and testable today.
\nSome advanced executor targets are still planned. If your use case maps to what is shipping now, you can build on it. Check the roadmap to see what lands when.
\nRight now: browser via the browser adapter, server-side via the Rust runtime, and AI pipelines via the MCP server. The React demo and Expedition example both run in browser.
\nEdge and cloud executor adapters are next on the roadmap. Device is further out. All of them run the same WASM binary when they ship.
\nMicroservices separate deployment. Traverse separates the capability from the runtime entirely. Your pricing logic does not care whether it runs in a browser or on a server. A microservice always runs where you deployed it.
\nThere is also no network call when a capability runs close to the user. The WASM binary runs in-process. That changes the latency profile completely.
\nServerless functions are tied to a cloud provider and a specific execution model. You write a function for AWS Lambda or Cloudflare Workers and it runs there. Traverse capabilities are not tied to any provider or platform.
\nThe contract system is also different. Serverless functions have no formal contract. Traverse validates inputs and outputs every time, which means it can catch integration errors before they reach production.
\nWASM runs near-native. The contract validation adds a fixed overhead per call, not per computation unit. For most business logic workloads this is noise. A formal benchmarks page is planned for v0.8.x.
\nThe bigger win is usually latency, not throughput. Running capability logic in the browser or at the edge cuts the round-trip entirely.
\nEvery capability has a contract file that declares what inputs it accepts, what outputs it produces, which placement targets it supports, and what constraints apply. The runtime reads this file before execution.
\nIf you try to call a capability with the wrong inputs, the runtime rejects it before the WASM even runs. The trace artifact records the full decision. Nothing executes without a passing contract check.
\nWASM is how portability works. The contract system and the trace mechanism exist independent of WASM, but the cross-environment execution story depends on it.
\nIf you only need server-side execution, you could use the Rust crate directly. But you lose the placement portability that is the main point.
\nThe runtime catches the failure, records it in the trace artifact with a timestamp and the failing contract clause, and returns a structured error. Nothing silent or ambiguous.
\nContract violations fail before execution. Runtime errors fail during execution. Both produce a trace. You always know exactly where the failure happened and what the runtime saw at that point.
\nStart with the trace artifact from the failed call. It records input values, contract checks, execution steps, and output values. Most problems are visible there without any additional tooling.
\nThe CLI includes a trace subcommand for inspecting trace files. The MCP server exposes trace querying to AI agents. Expanded trace querying is planned for v0.8.x.
JavaScript works today via the browser adapter. You load the WASM module and call capabilities through the JS bindings. The React demo shows exactly how this looks.
\nPython SDK is experimental and on the roadmap for v0.8.x. Other language bindings depend on community interest and WASM host availability in that ecosystem.
\nA trace is a structured record produced after every capability execution. It captures the inputs the runtime received, which contract clauses were checked, the execution path taken, and the outputs produced.
\nThis matters for two reasons. First, it makes debugging fast. Second, it makes auditing possible. If a pricing rule applied a discount you did not expect, the trace shows you exactly why. That kind of explainability is hard to add after the fact.
\nApache 2.0 is a permissive open source license. You can use Traverse commercially, modify it, distribute it, and build closed-source products on top of it. You need to include the original license notice.
\nThere are no royalties and no restrictions on commercial use. If you are evaluating this for a company, legal counsel can confirm, but Apache 2.0 is one of the most business-friendly open source licenses available.
\nEnrico Piovesan. One person. This is not a VC-funded team with a support contract. It is research engineering built over years of real product work, published as open source.
\nThe upside is that the design is intentional and consistent. The tradeoff is that response times on issues depend on one person's capacity. Community contributions are welcome and encouraged.
\nThe MCP server exposes Traverse capabilities as tools that AI agents can call. The agent reads the capability contract to understand what the tool does, what inputs it takes, and what it returns. No custom glue code needed.
\nBecause every call produces a trace, the agent can inspect what actually happened and reason about it. This turns capabilities into auditable building blocks for AI workflows, not just function calls that return an opaque result.
\nFunction calling gives an agent a schema and an endpoint. The agent calls the function and gets a response. There is no contract enforcement, no placement logic, and no trace.
\nWith Traverse, the agent is working with governed capabilities. Inputs are validated before execution. The result includes a trace. The contract tells the agent exactly what the capability is allowed to do. That is a different level of trust and observability.
\nContract-Driven AI Development, or C-DAD, is a methodology that asks AI agents to navigate systems that have machine-readable contracts rather than undocumented code. If your capabilities have contracts, an AI agent can read them and reason about the system correctly.
\nWithout contracts, AI agents are guessing based on naming conventions and comments. With contracts, they have a precise definition of what each capability does, what it accepts, and what constraints apply. Enrico published the C-DAD whitepaper as the theoretical foundation for this approach.
\nUniversal Microservices Architecture, or UMA, is the architectural pattern Traverse implements. The core idea is that business capabilities should be portable across every runtime, not tied to the environment they were first deployed in.
\nThe UMA book on Amazon covers the theory in 13 chapters with runnable Rust and WASM examples. Traverse is the production runtime that makes those ideas executable. More at universalmicroservices.com.
\nOpen an issue or a pull request on GitHub. Issues are the best place to start for new capability ideas, bug reports, or questions that are not answered here.
\nOne rule: nothing ships without a governing spec. If you want to add a feature, the spec comes first. This keeps the codebase navigable and the intent documented regardless of who makes a change.
\nThe quickstart gets you to a running capability in under 10 minutes. No account required.
\n \nEverything you want to know before you write a single line of code. If something is missing, open an issue on GitHub.
\nTraverse is a runtime that lets you write a business capability once in Rust and compile it to WASM. The binary is device-independent and runs on any client without modification, executing locally by default. If the client decides to, based on its own heuristics, it can delegate a subset of the capability to the server. Same binary, same behavior, no rewrite.
\nEach capability is wrapped in a machine-readable contract. The runtime checks inputs and outputs against that contract before anything runs. You get a trace artifact showing exactly what happened and why.
\nTo write new capabilities from scratch, yes. Rust compiles to WASM and gives you the control and safety the runtime expects.
\nBut you can call Traverse from JavaScript, Python, or any language with a WASM host. If someone else compiled the capability, you consume it through the SDK without touching Rust at all. The Python SDK is on the roadmap for v0.8.x.
\nv0.7.0 ships with 100% test coverage and 9 governing specs. The core runtime, CLI, browser adapter, and MCP server are all working and testable today.
\nSome advanced executor targets are still planned. If your use case maps to what is shipping now, you can build on it. Check the roadmap to see what lands when.
\nRight now: browser via the browser adapter, server-side via the Rust runtime, and AI pipelines via the MCP server. The React demo and Expedition example both run in browser.
\nEdge and cloud executor adapters are next on the roadmap. Device is further out. All of them run the same WASM binary when they ship.
\nMicroservices separate deployment. Traverse separates the capability from the runtime entirely. Your pricing logic does not care whether it runs in a browser or on a server. A microservice always runs where you deployed it.
\nThere is also no network call when a capability runs close to the user. The WASM binary runs in-process. That changes the latency profile completely.
\nServerless functions are tied to a cloud provider and a specific execution model. You write a function for AWS Lambda or Cloudflare Workers and it runs there. Traverse capabilities are not tied to any provider or platform.
\nThe contract system is also different. Serverless functions have no formal contract. Traverse validates inputs and outputs every time, which means it can catch integration errors before they reach production.
\nWASM runs near-native. The contract validation adds a fixed overhead per call, not per computation unit. For most business logic workloads this is noise. A formal benchmarks page is planned for v0.8.x.
\nThe bigger win is usually latency, not throughput. Running capability logic in the browser or at the edge cuts the round-trip entirely.
\nEvery capability has a contract file that declares what inputs it accepts, what outputs it produces, which placement targets it supports, and what constraints apply. The runtime reads this file before execution.
\nIf you try to call a capability with the wrong inputs, the runtime rejects it before the WASM even runs. The trace artifact records the full decision. Nothing executes without a passing contract check.
\nWASM is how portability works. The contract system and the trace mechanism exist independent of WASM, but the cross-environment execution story depends on it.
\nIf you only need server-side execution, you could use the Rust crate directly. But you lose the placement portability that is the main point.
\nThe runtime catches the failure, records it in the trace artifact with a timestamp and the failing contract clause, and returns a structured error. Nothing silent or ambiguous.
\nContract violations fail before execution. Runtime errors fail during execution. Both produce a trace. You always know exactly where the failure happened and what the runtime saw at that point.
\nStart with the trace artifact from the failed call. It records input values, contract checks, execution steps, and output values. Most problems are visible there without any additional tooling.
\nThe CLI includes a trace subcommand for inspecting trace files. The MCP server exposes trace querying to AI agents. Expanded trace querying is planned for v0.8.x.
JavaScript works today via the browser adapter. You load the WASM module and call capabilities through the JS bindings. The React demo shows exactly how this looks.
\nPython SDK is experimental and on the roadmap for v0.8.x. Other language bindings depend on community interest and WASM host availability in that ecosystem.
\nA trace is a structured record produced after every capability execution. It captures the inputs the runtime received, which contract clauses were checked, the execution path taken, and the outputs produced.
\nThis matters for two reasons. First, it makes debugging fast. Second, it makes auditing possible. If a pricing rule applied a discount you did not expect, the trace shows you exactly why. That kind of explainability is hard to add after the fact.
\nApache 2.0 is a permissive open source license. You can use Traverse commercially, modify it, distribute it, and build closed-source products on top of it. You need to include the original license notice.
\nThere are no royalties and no restrictions on commercial use. If you are evaluating this for a company, legal counsel can confirm, but Apache 2.0 is one of the most business-friendly open source licenses available.
\nEnrico Piovesan. One person. This is not a VC-funded team with a support contract. It is research engineering built over years of real product work, published as open source.
\nThe upside is that the design is intentional and consistent. The tradeoff is that response times on issues depend on one person's capacity. Community contributions are welcome and encouraged.
\nThe MCP server exposes Traverse capabilities as tools that AI agents can call. The agent reads the capability contract to understand what the tool does, what inputs it takes, and what it returns. No custom glue code needed.
\nBecause every call produces a trace, the agent can inspect what actually happened and reason about it. This turns capabilities into auditable building blocks for AI workflows, not just function calls that return an opaque result.
\nFunction calling gives an agent a schema and an endpoint. The agent calls the function and gets a response. There is no contract enforcement, no placement logic, and no trace.
\nWith Traverse, the agent is working with governed capabilities. Inputs are validated before execution. The result includes a trace. The contract tells the agent exactly what the capability is allowed to do. That is a different level of trust and observability.
\nContract-Driven AI Development, or C-DAD, is a methodology that asks AI agents to navigate systems that have machine-readable contracts rather than undocumented code. If your capabilities have contracts, an AI agent can read them and reason about the system correctly.
\nWithout contracts, AI agents are guessing based on naming conventions and comments. With contracts, they have a precise definition of what each capability does, what it accepts, and what constraints apply. Enrico published the C-DAD whitepaper as the theoretical foundation for this approach.
\nUniversal Microservices Architecture, or UMA, is the architectural pattern Traverse implements. The core idea is that business capabilities should be portable across every runtime, not tied to the environment they were first deployed in.
\nThe UMA book on Amazon covers the theory in 13 chapters with runnable Rust and WASM examples. Traverse is the production runtime that makes those ideas executable. More at universalmicroservices.com.
\nOpen an issue or a pull request on GitHub. Issues are the best place to start for new capability ideas, bug reports, or questions that are not answered here.
\nOne rule: nothing ships without a governing spec. If you want to add a feature, the spec comes first. This keeps the codebase navigable and the intent documented regardless of who makes a change.
\nThe quickstart gets you to a running capability in under 10 minutes. No account required.
\n \n