Everything you want to know before you write a single line of code. If something is missing, open an issue on GitHub.
\n
\n
\n\n
\n
\n\n \n\n
\n\n \n \n
Getting Started
\n
\n\n
\n \n
\n
Traverse is a contract-driven runtime for portable business capabilities. The useful loop is discover → execute → trace: find a governed capability, run known behavior, read the receipt. An agent may propose a call; the runtime decides — validate, execute or deny, and leave a trace.
\n
Usual authoring is plain English via the Claude skill traverse-capability-author (contract → WASM → human-reviewed PR). Under the hood the executable is still Rust compiled to WASM; that is how, not the product identity. Embedders, CLI, and MCP are clients of one shared runtime.wasm.
No — not for the usual paths. Author a new capability in plain English with the official Claude skill traverse-capability-author in traverse-framework/claude-skills. It interviews you one question at a time, checks the public (and any private) registry so you do not reinvent something that already exists, writes the contract, produces executable WASM, and opens a human-reviewed PR. You describe the business rule; you do not have to write the Rust yourself. Under the hood the implementation is still Rust→WASM — that is what gives you determinism, sandboxing, and portability.
\n
Manual path: if you write capabilities yourself in the repo, that still expects Rust (compile to wasm32-wasip1).
\n
Consume path: no Rust needed. JavaScript and TypeScript call through the published npm package traverse-embedder-web. Python can consume today by shelling out to traverse-cli with the real verb capability-package execute (stdlib subprocess) — there is no shipped Python SDK. See What is real today and Do I need Rust?.
Do not invent a Python SDK, do not assume every platform is shipped, and do not treat governing-spec counts as the value. Skill-first authoring via traverse-capability-author; one shared runtime.wasm; published consumers are JS/TS, Rust, and MCP; Python is CLI-only today.
\n
\n
\n\n
\n \n
\n
Traverse is pre-1.0 (v0.13.0). The discover → execute → trace loop works today on the shipped local and browser paths. The core runtime, CLI, MCP server, and the published Rust and Web embedder SDKs work. Specs and CI gates keep that honest — they are not the headline.
\n
Some advanced executor targets are still planned. Native Swift / Kotlin / .NET embedders exist in-tree but are not first-class public packages yet. There are no invented customers on this site. If your use case maps to what is shipping now, you can build on it — check What is real today, Platforms, and the roadmap.
\n
\n
\n\n
\n \n
\n
Right now: natively via the Rust runtime and embedders, and in the browser via the Web/TypeScript embedder SDK — the same WASM binary either way. An MCP-connected AI agent calls into one of those two targets rather than running in a separate placement of its own.
\n
Swift/iOS, Kotlin/Android, and .NET embedders are in progress — usable in-tree, not certified public package releases. Edge is planned. Cloud placement is an explicit non-goal for the current milestone. Do not assume a target works without checking Platforms and What is real today.
\n
\n
\n\n
\n \n\n \n \n
Technical
\n
\n\n
\n \n
\n
Microservices 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.
\n
There 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.
\n
\n
\n\n
\n \n
\n
Serverless 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.
\n
The 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.
\n
\n
\n\n
\n \n
\n
WASM 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.11.x.
\n
The bigger win is usually latency, not throughput. Running capability logic in the browser or at the edge cuts the round-trip entirely.
\n
\n
\n\n
\n \n
\n
Every 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.
\n
If 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. Specs and CI gates are how we stay honest — they are governance hygiene, not the product identity or the pitch. See What is real today.
\n
\n
\n\n
\n \n
\n
WASM is how portability works. The contract system and the trace mechanism exist independent of WASM, but the cross-environment execution story depends on it.
\n
If you only need server-side execution, you could use the Rust crate directly. But you lose the placement portability that is the main point.
\n
\n
\n\n
\n \n
\n
The 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.
\n
Contract 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.
\n
\n
\n\n
\n \n
\n
Start 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.
\n
The 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.11.x.
\n
\n
\n\n
\n \n
\n
JavaScript and TypeScript work today via the published Web embedder — npm traverse-embedder-web. You load a bundle, digest-verify the WASM, and execute in the browser. The React integration guide shows the shape.
\n
Python has no shipped SDK. The honest today-path is a stdlib subprocess call to traverse-cli capability-package execute <manifest> <request.json> against a checked-in package. That is the real CLI verb — not a fake capability run. See Can I use Traverse with Python? and What is real today.
\n
\n
\n\n
\n \n
\n
A 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.
\n
This 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.
\n
\n
\n\n
\n \n\n \n \n
Licensing & Maintenance
\n
\n\n
\n \n
\n
Apache 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.
\n
There 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.
\n
\n
\n\n
\n \n
\n
Enrico 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.
\n
The 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.
\n
\n
\n\n
\n \n\n \n \n
AI and MCP
\n
\n\n
\n \n
\n
The 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.
\n
Because every call produces a trace, the agent can inspect what actually happened. The agent proposes; the runtime decides. That direction is clearest in the deny demo: The agent freestyled a $2.4M wire. The runtime said no. Prefer the blog write-up; weekly-demos is not publicly cloneable yet (tracked in .github#30). See also Agents and What is real today.
\n
\n
\n\n
\n \n
\n
Function 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.
\n
With Traverse, the agent is working with governed capabilities. Inputs are validated before execution. Bad calls can be denied before they run. 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 — agent proposes, runtime decides. Read the deny demo.
\n
\n
\n\n
\n \n
\n
Contract-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.
\n
Without 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.
\n
\n
\n\n
\n \n
\n
Universal 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.
\n
The 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.
\n
\n
\n\n
\n \n\n \n \n
Community
\n
\n\n
\n \n
\n
Start from labeled help wanted / good-first-issue tickets, or open an issue on GitHub. For a new capability in plain English, use the official Claude skill traverse-capability-author in claude-skills — it checks the registry, authors the contract + WASM, and opens a human-reviewed PR. More on Contribute.
\n
One rule: nothing ships without a governing spec (docs and examples marked no-spec-needed are the exception). If you want to add a runtime feature, the spec comes first.
\n
\n
\n\n
\n \n\n
\n
\n
\n\n
\n \n
\n
Ready to build?
\n
The quickstart gets you to a running capability in under 10 minutes. No account required.
Everything you want to know before you write a single line of code. If something is missing, open an issue on GitHub.
\n
\n
\n\n
\n
\n\n \n\n
\n\n \n \n
Getting Started
\n
\n\n
\n \n
\n
Traverse is a contract-driven runtime for portable business capabilities. The useful loop is discover → execute → trace: find a governed capability, run known behavior, read the receipt. An agent may propose a call; the runtime decides — validate, execute or deny, and leave a trace.
\n
Usual authoring is plain English via the Claude skill traverse-capability-author (contract → WASM → human-reviewed PR). Under the hood the executable is still Rust compiled to WASM; that is how, not the product identity. Embedders, CLI, and MCP are clients of one shared runtime.wasm.
No — not for the usual paths. Author a new capability in plain English with the official Claude skill traverse-capability-author in traverse-framework/claude-skills. It interviews you one question at a time, checks the public (and any private) registry so you do not reinvent something that already exists, writes the contract, produces executable WASM, and opens a human-reviewed PR. You describe the business rule; you do not have to write the Rust yourself. Under the hood the implementation is still Rust→WASM — that is what gives you determinism, sandboxing, and portability.
\n
Manual path: if you write capabilities yourself in the repo, that still expects Rust (compile to wasm32-wasip1).
\n
Consume path: no Rust needed. JavaScript and TypeScript call through the published npm package traverse-embedder-web. Python can consume today by shelling out to traverse-cli with the real verb capability-package execute (stdlib subprocess) — there is no shipped Python SDK. See What is real today and Do I need Rust?.
Do not invent a Python SDK, do not assume every platform is shipped, and do not treat governing-spec counts as the value. Skill-first authoring via traverse-capability-author; one shared runtime.wasm; published consumers are JS/TS, Rust, and MCP; Python is CLI-only today.
\n
\n
\n\n
\n \n
\n
Traverse is pre-1.0 (v0.14.0). The discover → execute → trace loop works today on the shipped local and browser paths. The core runtime, CLI, MCP server, and the published Rust and Web embedder SDKs work. Specs and CI gates keep that honest — they are not the headline.
\n
Some advanced executor targets are still planned. Native Swift / Kotlin / .NET embedders exist in-tree but are not first-class public packages yet. There are no invented customers on this site. If your use case maps to what is shipping now, you can build on it — check What is real today, Platforms, and the roadmap.
\n
\n
\n\n
\n \n
\n
Right now: natively via the Rust runtime and embedders, and in the browser via the Web/TypeScript embedder SDK — the same WASM binary either way. An MCP-connected AI agent calls into one of those two targets rather than running in a separate placement of its own.
\n
Swift/iOS, Kotlin/Android, and .NET embedders are in progress — usable in-tree, not certified public package releases. Edge is planned. Cloud placement is an explicit non-goal for the current milestone. Do not assume a target works without checking Platforms and What is real today.
\n
\n
\n\n
\n \n\n \n \n
Technical
\n
\n\n
\n \n
\n
Microservices 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.
\n
There 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.
\n
\n
\n\n
\n \n
\n
Serverless 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.
\n
The 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.
\n
\n
\n\n
\n \n
\n
WASM 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.11.x.
\n
The bigger win is usually latency, not throughput. Running capability logic in the browser or at the edge cuts the round-trip entirely.
\n
\n
\n\n
\n \n
\n
Every 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.
\n
If 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. Specs and CI gates are how we stay honest — they are governance hygiene, not the product identity or the pitch. See What is real today.
\n
\n
\n\n
\n \n
\n
WASM is how portability works. The contract system and the trace mechanism exist independent of WASM, but the cross-environment execution story depends on it.
\n
If you only need server-side execution, you could use the Rust crate directly. But you lose the placement portability that is the main point.
\n
\n
\n\n
\n \n
\n
The 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.
\n
Contract 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.
\n
\n
\n\n
\n \n
\n
Start 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.
\n
The 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.11.x.
\n
\n
\n\n
\n \n
\n
JavaScript and TypeScript work today via the published Web embedder — npm traverse-embedder-web. You load a bundle, digest-verify the WASM, and execute in the browser. The React integration guide shows the shape.
\n
Python has no shipped SDK. The honest today-path is a stdlib subprocess call to traverse-cli capability-package execute <manifest> <request.json> against a checked-in package. That is the real CLI verb — not a fake capability run. See Can I use Traverse with Python? and What is real today.
\n
\n
\n\n
\n \n
\n
A 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.
\n
This 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.
\n
\n
\n\n
\n \n\n \n \n
Licensing & Maintenance
\n
\n\n
\n \n
\n
Apache 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.
\n
There 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.
\n
\n
\n\n
\n \n
\n
Enrico 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.
\n
The 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.
\n
\n
\n\n
\n \n\n \n \n
AI and MCP
\n
\n\n
\n \n
\n
The 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.
\n
Because every call produces a trace, the agent can inspect what actually happened. The agent proposes; the runtime decides. That direction is clearest in the deny demo: The agent freestyled a $2.4M wire. The runtime said no. Prefer the blog write-up; weekly-demos is not publicly cloneable yet (tracked in .github#30). See also Agents and What is real today.
\n
\n
\n\n
\n \n
\n
Function 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.
\n
With Traverse, the agent is working with governed capabilities. Inputs are validated before execution. Bad calls can be denied before they run. 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 — agent proposes, runtime decides. Read the deny demo.
\n
\n
\n\n
\n \n
\n
Contract-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.
\n
Without 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.
\n
\n
\n\n
\n \n
\n
Universal 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.
\n
The 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.
\n
\n
\n\n
\n \n\n \n \n
Community
\n
\n\n
\n \n
\n
Start from labeled help wanted / good-first-issue tickets, or open an issue on GitHub. For a new capability in plain English, use the official Claude skill traverse-capability-author in claude-skills — it checks the registry, authors the contract + WASM, and opens a human-reviewed PR. More on Contribute.
\n
One rule: nothing ships without a governing spec (docs and examples marked no-spec-needed are the exception). If you want to add a runtime feature, the spec comes first.
\n
\n
\n\n
\n \n\n
\n
\n
\n\n
\n \n
\n
Ready to build?
\n
The quickstart gets you to a running capability in under 10 minutes. No account required.
\n Skill-first via traverse-capability-author — not “must write Rust.” One shared runtime.wasm; browser, native desktop, CLI, and MCP are the shipped clients today (not packaged mobile/.NET; no edge; cloud is a non-goal). The agent proposes; the runtime decides.\n
\n
\n Non-UI business logic lives in capabilities (WASM + contract) — pricing, eligibility, codecs, scorers, gates. Hosts and clients do UI and I/O only. “Apps not ready” is product/help-wanted sequencing, not “leave domain rules in the host forever.” Where does business logic live?\n
$traverse run pricing --input '{\"sku\":\"PRO\",\"quantity\":5}'
\n
✓ Contract validated
\n
✓ WASM executed (2.1ms)
\n
→ {\"total\": 249.95, \"currency\": \"USD\"}
\n
\n
\n
\n
\n\n \n
\n
How Traverse works
\n
\n Write a contract. Ship a capability.\n
\n
\n Three steps from idea to a portable, contract-governed piece of business logic — on hosts that have actually shipped (see Platforms).\n
\n
\n
\n
01
\n
\n
Define the contract
\n
Write a TOML file with your capability name, the WASM binary path, and JSON Schema definitions for inputs and outputs. Link it to the governing spec document your team actually works from.
\n
\n
\n
\n
02
\n
\n
Author → WASM
\n
Usual path: plain English via the Claude skill traverse-capability-author (contract → WASM → human-reviewed PR). Manual path is still Rust→wasm32-wasip1. Same artifact on every embedder.
\n
\n
\n
\n
03
\n
\n
Register and run
\n
Add the capability to the registry with traverse add. Call it from the CLI, from an AI agent via MCP, or from your app directly. Every call is validated and traced.
\n
\n
\n
\n
\n
\n
\n\n\n\n\n
\n
\n
Features
\n
Everything business logic needs
\n
From contract validation to AI agent discovery, Traverse handles the entire lifecycle.
\n
\n
\n
\n
\n \n
\n
Contract-first validation
\n
Every capability call validates inputs against a JSON Schema precondition before execution. Postconditions validate the output. Bad data never reaches your logic.
\n
\n
\n
\n \n
\n
WASM sandbox isolation
\n
Each capability runs in its own Wasmtime WASM instance with linear memory isolation. A capability cannot access host resources it was not explicitly granted.
\n
\n
\n
\n \n
\n
AI agent integration
\n
Expose your entire capability registry to AI agents via the MCP stdio server. Claude, GPT-4, and any MCP-compatible agent can discover and call capabilities safely.
\n
\n
\n
\n \n
\n
Honest host surface
\n
Shipped today: native (Linux/macOS/Windows) and browser via traverse-embedder-web. Swift/Kotlin/.NET exist in-tree, not as certified public packages. Edge is planned; cloud placement is an explicit non-goal for v0.1. See Platforms.
\n
\n
\n
\n \n
\n
Trace artifacts
\n
Every execution produces a trace artifact: the input, the output, the contract version, and a timestamp. Audit any past run without re-executing anything.
\n
\n
\n
\n \n
\n
Policy paper trail
\n
Every contract can link to the policy document it implements. Specs are honesty hygiene for the codebase — not the product pitch, and not a count to advertise.
\n
\n
\n
\n\n\n\n\n
\n
Watch a workflow get composed, live.
\n
Your browser fetches the real capability registry and a client-side heuristic -- not a hosted AI model -- chains matching capabilities into a workflow. No fixtures, no precomputed data.
Shared runtime.wasm orchestrator — embedders are clients. Placement targets that have actually shipped: see Platforms.
\n
\n
\n
0
\n
Logic rewrites between hosts that share the same runtime.wasm. Same contract, same binary, same behavior on those shipped surfaces — not a claim about mobile packages, edge, or cloud.
\n
\n
\n
2ms
\n
Typical contract execution time on the local target. WASM startup is fast. Contract validation adds negligible overhead.
\n
\n
\n
\n\n\n\n\n
\n
\n
Use cases
\n
Built for real business logic
\n
Pricing rules, eligibility checks, compliance logic — deterministic computation that must behave the same on every host where Traverse actually ships.
\n
\n
\n
\n
\n \n
\n
Pricing and discount logic
\n
Encode complex pricing rules as a contract with a link to your pricing policy document. The same capability runs via the published Web embedder, native/CLI hosts, and MCP agents with identical results — where those surfaces are shipped.
Run eligibility logic as a sandboxed WASM capability so an AI agent can check a user's eligibility for a product, service, or feature without risk of hallucinating the answer.
Capture regulatory and compliance rules in versioned contracts with governing spec links. Every execution is traced. Auditors can replay any historical decision from the trace artifact.
Give your AI agents a set of contract-governed capabilities to call. The agent cannot exceed the contract's boundaries. Postcondition checks block invalid outputs before they propagate.
\n Skill-first via traverse-capability-author — not “must write Rust.” One shared runtime.wasm; browser, native desktop, CLI, and MCP are the shipped clients today (not packaged mobile/.NET; no edge; cloud is a non-goal). The agent proposes; the runtime decides.\n
\n
\n Non-UI business logic lives in capabilities (WASM + contract) — pricing, eligibility, codecs, scorers, gates. Hosts and clients do UI and I/O only. “Apps not ready” is product/help-wanted sequencing, not “leave domain rules in the host forever.” Where does business logic live?\n
$traverse run pricing --input '{\"sku\":\"PRO\",\"quantity\":5}'
\n
✓ Contract validated
\n
✓ WASM executed (2.1ms)
\n
→ {\"total\": 249.95, \"currency\": \"USD\"}
\n
\n
\n
\n
\n\n \n
\n
How Traverse works
\n
\n Write a contract. Ship a capability.\n
\n
\n Three steps from idea to a portable, contract-governed piece of business logic — on hosts that have actually shipped (see Platforms).\n
\n
\n
\n
01
\n
\n
Define the contract
\n
Write a TOML file with your capability name, the WASM binary path, and JSON Schema definitions for inputs and outputs. Link it to the governing spec document your team actually works from.
\n
\n
\n
\n
02
\n
\n
Author → WASM
\n
Usual path: plain English via the Claude skill traverse-capability-author (contract → WASM → human-reviewed PR). Manual path is still Rust→wasm32-wasip1. Same artifact on every embedder.
\n
\n
\n
\n
03
\n
\n
Register and run
\n
Add the capability to the registry with traverse add. Call it from the CLI, from an AI agent via MCP, or from your app directly. Every call is validated and traced.
\n
\n
\n
\n
\n
\n
\n\n\n\n\n
\n
\n
Features
\n
Everything business logic needs
\n
From contract validation to AI agent discovery, Traverse handles the entire lifecycle.
\n
\n
\n
\n
\n \n
\n
Contract-first validation
\n
Every capability call validates inputs against a JSON Schema precondition before execution. Postconditions validate the output. Bad data never reaches your logic.
\n
\n
\n
\n \n
\n
WASM sandbox isolation
\n
Each capability runs in its own Wasmtime WASM instance with linear memory isolation. A capability cannot access host resources it was not explicitly granted.
\n
\n
\n
\n \n
\n
AI agent integration
\n
Expose your entire capability registry to AI agents via the MCP stdio server. Claude, GPT-4, and any MCP-compatible agent can discover and call capabilities safely.
\n
\n
\n
\n \n
\n
Honest host surface
\n
Shipped today: native (Linux/macOS/Windows) and browser via traverse-embedder-web. Swift/Kotlin/.NET exist in-tree, not as certified public packages. Edge is planned; cloud placement is an explicit non-goal for v0.1. See Platforms.
\n
\n
\n
\n \n
\n
Trace artifacts
\n
Every execution produces a trace artifact: the input, the output, the contract version, and a timestamp. Audit any past run without re-executing anything.
\n
\n
\n
\n \n
\n
Policy paper trail
\n
Every contract can link to the policy document it implements. Specs are honesty hygiene for the codebase — not the product pitch, and not a count to advertise.
\n
\n
\n
\n\n\n\n\n
\n
Watch a workflow get composed, live.
\n
Your browser fetches the real capability registry and a client-side heuristic -- not a hosted AI model -- chains matching capabilities into a workflow. No fixtures, no precomputed data.
Shared runtime.wasm orchestrator — embedders are clients. Placement targets that have actually shipped: see Platforms.
\n
\n
\n
0
\n
Logic rewrites between hosts that share the same runtime.wasm. Same contract, same binary, same behavior on those shipped surfaces — not a claim about mobile packages, edge, or cloud.
\n
\n
\n
2ms
\n
Typical contract execution time on the local target. WASM startup is fast. Contract validation adds negligible overhead.
\n
\n
\n
\n\n\n\n\n
\n
\n
Use cases
\n
Built for real business logic
\n
Pricing rules, eligibility checks, compliance logic — deterministic computation that must behave the same on every host where Traverse actually ships.
\n
\n
\n
\n
\n \n
\n
Pricing and discount logic
\n
Encode complex pricing rules as a contract with a link to your pricing policy document. The same capability runs via the published Web embedder, native/CLI hosts, and MCP agents with identical results — where those surfaces are shipped.
Run eligibility logic as a sandboxed WASM capability so an AI agent can check a user's eligibility for a product, service, or feature without risk of hallucinating the answer.
Capture regulatory and compliance rules in versioned contracts with governing spec links. Every execution is traced. Auditors can replay any historical decision from the trace artifact.
Give your AI agents a set of contract-governed capabilities to call. The agent cannot exceed the contract's boundaries. Postcondition checks block invalid outputs before they propagate.
\n\n";
const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"SoftwareApplication\",\"name\":\"Traverse\",\"description\":\"A governed capability runtime: discover → execute → trace. Skill-first authoring via traverse-capability-author; one shared runtime.wasm; shipped clients are browser, native desktop, CLI, and MCP. The agent proposes; the runtime decides.\",\"url\":\"https://traverse-framework.com\",\"author\":{\"@type\":\"Person\",\"name\":\"Enrico Piovesan\"},\"license\":\"https://www.apache.org/licenses/LICENSE-2.0\",\"applicationCategory\":\"DeveloperApplication\",\"softwareVersion\":\"0.13.0\",\"codeRepository\":\"https://github.com/traverse-framework/traverse\"}";
---
Shipped
Three things are true here, all shipped. First, the runtime core builds for wasm32-unknown-unknown with native adapters excluded — contracts, registry resolution, routing, traces, and events all run in a browser or edge-WASM guest with your own executor behind CapabilityExecutor. Second: the public Web/TypeScript embedder SDK (traverse-embedder-web), shipped in v0.8.0, loads a bundle, digest-verifies every WASM capability, and executes it directly in the browser's native WebAssembly host through a minimal WASI preview1 shim — no nested engine, no server sidecar. Third, added in v0.10.0: a governed browser-hosted path for executing a single verified capability by exact id and version, either through traverse-cli serve's verified-entrypoint endpoint or along the validated execute_entrypoint flow, returning a result plus a redacted trace receipt (specs 023, 115).
-
Scope it honestly: in-browser workflow execution via the embedder SDK is limited to linear, direct-triggered pipelines — event-driven and conditional edges are rejected at init — and the verified-entrypoint path runs one pre-published capability at a time against already-synced registry state rather than an arbitrary live-registry lookup. traverse-embedder-web@0.13.0 is published to npm (aligned with the v0.13.0 cut). The runtime's requested_target placement router still resolves only local; browser execution is reached through these SDKs and endpoints, not by requesting a browser target.
+
Scope it honestly: in-browser workflow execution via the embedder SDK is limited to linear, direct-triggered pipelines — event-driven and conditional edges are rejected at init — and the verified-entrypoint path runs one pre-published capability at a time against already-synced registry state rather than an arbitrary live-registry lookup. traverse-embedder-web@0.14.0 is published to npm (aligned with the v0.14.0 cut). The runtime's requested_target placement router still resolves only local; browser execution is reached through these SDKs and endpoints, not by requesting a browser target.
Traverse v0.13.0 is functionally stable for the local placement target, but a security and permanence audit found dangerous defaults that mean the framework should be treated as pre-production for anything network-facing. The local runtime and contract validation are solid. The CLI's HTTP server and the MCP server currently have real authentication gaps. The project is also pre-1.0, so minor version bumps can include breaking API changes. Pin your version and read the changelog before upgrading.
\n\n
What is stable today
\n
\n
Local placement target — runs WASM capabilities in the local process
\n
Contract validation — input and output checked against the contract's JSON Schema (declared preconditions/postconditions are documentation for reviewers today, not a separate runtime-evaluated check)
\n
The traverse CLI — capability registration, invocation, and trace inspection (local use; the HTTP serve mode has known gaps, see below)
\n
The MCP server (traverse-mcp, its own stdio protocol rather than the plain tools/list/tools/call pair) for AI agent integration, trusted as a local IDE child process only by default (see below)
\n
Trace artifacts — every execution is recorded and inspectable
\n
The governing spec model — linking contracts to source documents
\n
\n\n
What is still maturing
\n
\n
Browser embedding (traverse-embedder-web@0.13.0) is published on npm; edge is planned but not started; cloud placement is an explicit non-goal for v0.1 — see Platforms for the honest breakdown
\n
Hosted registry — not yet available
\n
Language SDKs for Python, TypeScript, Go — planned
\n
Streaming output — not yet supported
\n
JWT verification, Sigstore verification, and MCP authentication — implemented as insecure defaults or stubs today, not yet real. Ed25519 artifact signing does work.
\n
\n\n
Known security gaps
\n
A framework-wide audit (July 2026) found the following before recommending any network exposure:
\n
\n
The HTTP server defaults to Development mode and never forces Production; unsigned artifacts are allowed to run.
\n
JWT identity is parsed from the base64 payload only — there is no signature or JWKS verification, so a forged token is accepted.
\n
The MCP stdio server has no authentication by default (local_trust mode) — anything that can write to its stdin can execute capabilities and read full execution traces. An operator can require a bearer token on execution commands via TRAVERSE_MCP_STDIO_BEARER_TOKEN, but that's opt-in, not the default.
\n
Sigstore artifact verification is currently a stub — it always fails closed with sigstore_unreachable rather than performing real verification, so a capability whose contract specifies the Sigstore scheme cannot successfully run today (Ed25519-signed artifacts are unaffected).
\n
\n
None of this affects the local runtime itself — WASM sandboxing and contract validation are unaffected. It affects anything that exposes the HTTP API or the MCP server beyond a fully trusted local process. Read the full security audit for severity, file locations, and the remediation roadmap.
\n\n
How to evaluate readiness for your use case
\n
If you need the local target only — running contracts on one machine, exposing capabilities to an AI agent via MCP — then Traverse is ready for that today. The core execution model is solid. The things still in progress are around the broader deployment surface, not the fundamental runtime behavior.
\n
If you need to deploy capabilities to the browser or cloud, or if you need a hosted registry your team can share, those features are not there yet. You would be building ahead of the stable surface and accepting more churn.
\n\n
The pre-1.0 caveat
\n
Pre-1.0 means Enrico can change APIs between minor versions if the design requires it. In practice, the contract format and core runtime behavior have been stable across recent releases. The parts that change are the edges — new placement targets bring new APIs, and those settle as the targets mature. Follow the changelog and the roadmap to stay informed.
";
-const _jsonLd = "{\"@context\": \"https://schema.org\", \"@type\": \"FAQPage\", \"mainEntity\": [{\"@type\": \"Question\", \"name\": \"Is Traverse production ready?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Traverse v0.13.0's local runtime and contract validation are stable, but a security audit found the HTTP server defaults to an insecure Development mode and the MCP server has no authentication. Treat network-facing surfaces as pre-production until those gaps close. Native and browser embedding have shipped; edge is planned but not started; cloud placement is an explicit non-goal for v0.1, not a gap still closing. The project is pre-1.0, meaning APIs can change between minor versions.\"}}]}";
+const _body = "
Traverse v0.14.0 is functionally stable for the local placement target, but a security and permanence audit found dangerous defaults that mean the framework should be treated as pre-production for anything network-facing. The local runtime and contract validation are solid. The CLI's HTTP server and the MCP server currently have real authentication gaps. The project is also pre-1.0, so minor version bumps can include breaking API changes. Pin your version and read the changelog before upgrading.
\n\n
What is stable today
\n
\n
Local placement target — runs WASM capabilities in the local process
\n
Contract validation — input and output checked against the contract's JSON Schema (declared preconditions/postconditions are documentation for reviewers today, not a separate runtime-evaluated check)
\n
The traverse CLI — capability registration, invocation, and trace inspection (local use; the HTTP serve mode has known gaps, see below)
\n
The MCP server (traverse-mcp, its own stdio protocol rather than the plain tools/list/tools/call pair) for AI agent integration, trusted as a local IDE child process only by default (see below)
\n
Trace artifacts — every execution is recorded and inspectable
\n
The governing spec model — linking contracts to source documents
\n
\n\n
What is still maturing
\n
\n
Browser embedding (traverse-embedder-web@0.13.0) is published on npm; edge is planned but not started; cloud placement is an explicit non-goal for v0.1 — see Platforms for the honest breakdown
\n
Hosted registry — not yet available
\n
Language SDKs for Python, TypeScript, Go — planned
\n
Streaming output — not yet supported
\n
JWT verification, Sigstore verification, and MCP authentication — implemented as insecure defaults or stubs today, not yet real. Ed25519 artifact signing does work.
\n
\n\n
Known security gaps
\n
A framework-wide audit (July 2026) found the following before recommending any network exposure:
\n
\n
The HTTP server defaults to Development mode and never forces Production; unsigned artifacts are allowed to run.
\n
JWT identity is parsed from the base64 payload only — there is no signature or JWKS verification, so a forged token is accepted.
\n
The MCP stdio server has no authentication by default (local_trust mode) — anything that can write to its stdin can execute capabilities and read full execution traces. An operator can require a bearer token on execution commands via TRAVERSE_MCP_STDIO_BEARER_TOKEN, but that's opt-in, not the default.
\n
Sigstore artifact verification is currently a stub — it always fails closed with sigstore_unreachable rather than performing real verification, so a capability whose contract specifies the Sigstore scheme cannot successfully run today (Ed25519-signed artifacts are unaffected).
\n
\n
None of this affects the local runtime itself — WASM sandboxing and contract validation are unaffected. It affects anything that exposes the HTTP API or the MCP server beyond a fully trusted local process. Read the full security audit for severity, file locations, and the remediation roadmap.
\n\n
How to evaluate readiness for your use case
\n
If you need the local target only — running contracts on one machine, exposing capabilities to an AI agent via MCP — then Traverse is ready for that today. The core execution model is solid. The things still in progress are around the broader deployment surface, not the fundamental runtime behavior.
\n
If you need to deploy capabilities to the browser or cloud, or if you need a hosted registry your team can share, those features are not there yet. You would be building ahead of the stable surface and accepting more churn.
\n\n
The pre-1.0 caveat
\n
Pre-1.0 means Enrico can change APIs between minor versions if the design requires it. In practice, the contract format and core runtime behavior have been stable across recent releases. The parts that change are the edges — new placement targets bring new APIs, and those settle as the targets mature. Follow the changelog and the roadmap to stay informed.
";
+const _jsonLd = "{\"@context\": \"https://schema.org\", \"@type\": \"FAQPage\", \"mainEntity\": [{\"@type\": \"Question\", \"name\": \"Is Traverse production ready?\", \"acceptedAnswer\": {\"@type\": \"Answer\", \"text\": \"Traverse v0.14.0's local runtime and contract validation are stable, but a security audit found the HTTP server defaults to an insecure Development mode and the MCP server has no authentication. Treat network-facing surfaces as pre-production until those gaps close. Native and browser embedding have shipped; edge is planned but not started; cloud placement is an explicit non-goal for v0.1, not a gap still closing. The project is pre-1.0, meaning APIs can change between minor versions.\"}}]}";
---
Most model stacks treat a URL or a vendor SDK as identity: fetch whatever is at that path and hope the bytes match what you tested. Exact-ref model execution is the opposite habit. The app names a specific model package — digest, signature, sidecar metadata — and the runtime either runs that package or it fails closed. A naked URL is never the name of the thing that ran.
Pin the package, not a path
-
Traverse app manifests declare exact model references. The package carries a sidecar: digest, license, ABI, schemas, resource limits. If the bytes do not match the pin, they do not run. You cannot “upgrade” a model by swapping the file behind a URL.
+
Traverse app manifests declare exact model references. As of v0.14.0, manifests use schema 2.0.0 and every package ships a detached Ed25519 model.sig.json over the exact model.manifest.json bytes. An application's exact_model_dependencies pin binds the SHA-256 of those manifest bytes and declares target, expected rights, and an optional signer key_id. You cannot “upgrade” a model by swapping the file behind a URL.
-
One envelope, any host
-
The call surface is the existing Spec 137 model.execute host-connector command — not a new public guest import, and not Spec 045’s candidate/LLM resolution track. Request and response are versioned. Inputs and outputs travel as opaque input_ref / output_ref handles; the host stages binary tensors in and reads them back out. Browser and native use the same envelopes. Placement is metadata, not a second API.
+
Host-owned trust
+
Trust roots are host-owned (TrustedModelKeys on Rust, trustedPublicKeysHex on web). Apps can never add trust. Packages enter the cache only through register_package / registerPackage, which verifies the signature and trusted key, the digest against exactly one pin, and the manifest schema (unknown fields fail closed), rights, target, and limits. Every execute re-hashes the cached bytes. Failures keep model_unavailable / model_incompatible and add a stable reason.
-
Resolve, cache, or say no
-
The runtime resolves the pin through the registry into a content-addressed cache. If the package is already provisioned and the manifest allows it, execute can stay offline. A cache miss is a stable model_unavailable, not a silent download of something adjacent. Unknown fields, bad digests, and bad signatures fail closed. Traces stay redacted: no tensors, no secrets, no credentials.
+
One envelope, any host that implements it
+
The call surface is the existing Spec 137 model.execute host-connector command — not a new public guest import, and not Spec 045’s candidate/LLM resolution track. Request and response are versioned. Inputs and outputs travel as opaque input_ref / output_ref handles. Browser and native use the same envelopes when both implement execute.
-
What landed, and what has not
-
Spec 138 (138-governed-exact-model-execution) and ADR-0074 landed on main on 16 September 2026 via traverse#1438, closing the governance/native/browser tickets #1435–#1437. First conformance is wasm-cpu, with deny-by-default filesystem and network for the model guest. Later acceleration adapters have to keep the public envelopes.
-
Spec 138 ships in Traverse v0.12.0: crates.io packages and npm traverse-embedder-web@0.12.0 are published and aligned. Longer release write-up: Traverse v0.12.0: exact-ref model.execute. This page is not a claim that every host already ships a certified public model-runtime package beyond the published Spec 138 wasm-cpu path.
+
What landed in v0.14.0
+
Spec 138 first shipped in v0.12.0 (see the historical v0.12.0 write-up). v0.14.0 adds signed packages, host-owned trust, machine-readable rights, and the first trained model digits-mlp-1.0.0 (64→32→10 MLP on UCI digits, CC BY 4.0, 96.10% held-out, bit-identical trainer / native / browser). That package is signed with the test-only key; production model signing is #1567.
+
Host honesty: exact-ref execute is implemented in the Rust native runtime and the web embedder today. The Swift, Kotlin, and .NET embedders do not execute exact-ref models yet. Pin crates.io and npm at 0.14.0 (and traverse-registry at =0.25.0 if you consume it directly).
What it is not
-
It is not “the model is in charge.” It is not Spec 045. It is not a guest model_invoke import — that stays out of scope for Spec 138 v1. And it is not permission to treat a URL as a model identity.
+
It is not “the model is in charge.” It is not Spec 045. It is not a guest model_invoke import — that stays out of scope for Spec 138 v1. And it is not permission to treat a URL as a model identity, or to assume every native embedder language already executes exact-ref.
Traverse is a contract-driven WASM runtime for portable business 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 define the logic once as a capability with a machine-readable contract and a WASM artifact (authored in plain English via the Claude skill, or written in Rust on the manual path). 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.13.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-cli — terminal interface for inspecting and running
\n
traverse-mcp — Model Context Protocol integration for AI pipelines
\n
traverse-embedder — public Rust embedder SDK for host applications
\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 WASM runtime for portable business 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.13.0 under the Apache 2.0 license.\"}}]}";
+const _body = "
Traverse is a contract-driven WASM runtime for portable business 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 define the logic once as a capability with a machine-readable contract and a WASM artifact (authored in plain English via the Claude skill, or written in Rust on the manual path). 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.14.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-cli — terminal interface for inspecting and running
\n
traverse-mcp — Model Context Protocol integration for AI pipelines
\n
traverse-embedder — public Rust embedder SDK for host applications
\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 WASM runtime for portable business 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.14.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.
Contract validation, WASM execution, trace production. The engine everything else runs on.
\n
\n
\n
\n
\n \n
\n
\n
CLI
\n
Build, run, validate, and inspect capabilities from the command line.
\n
\n
\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
\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
\n
\n
React demo
\n
Working example of browser-side capabilities in a React app.
\n
\n
\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
\n
\n
145 approved governing specs
\n
Every shipped component has a machine-readable, immutable spec, enforced as a CI merge gate. The codebase is navigable by humans and AI agents.
\n
\n
\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
Next
\n v0.11.x\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
Native Python SDK
\n further\n
\n
Not shipped and not a near-term committed deliverable. Today Python calls traverse-cli capability-package execute via subprocess. JS/TS already has published traverse-embedder-web; agents use traverse-mcp.
\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
Later
\n exploring\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
05
\n
v1.0 has ten explicit gates, not a vibe. Every crate published on crates.io, a five-platform CI stress matrix, an MCP library surface (not just the stdio subprocess), 100% coverage on governed paths, and zero open P0/P1 bugs \u2014 among others. None are met as a full set yet. Read the v1.0 milestone gates \u2192
\n
\n
\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.
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.
Contract validation, WASM execution, trace production. The engine everything else runs on.
\n
\n
\n
\n
\n \n
\n
\n
CLI
\n
Build, run, validate, and inspect capabilities from the command line.
\n
\n
\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
\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
\n
\n
React demo
\n
Working example of browser-side capabilities in a React app.
\n
\n
\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
\n
\n
145 approved governing specs
\n
Every shipped component has a machine-readable, immutable spec, enforced as a CI merge gate. The codebase is navigable by humans and AI agents.
\n
\n
\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
Next
\n v0.11.x\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
Native Python SDK
\n further\n
\n
Not shipped and not a near-term committed deliverable. Today Python calls traverse-cli capability-package execute via subprocess. JS/TS already has published traverse-embedder-web; agents use traverse-mcp.
\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
Later
\n exploring\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
05
\n
v1.0 has ten explicit gates, not a vibe. Every crate published on crates.io, a five-platform CI stress matrix, an MCP library surface (not just the stdio subprocess), 100% coverage on governed paths, and zero open P0/P1 bugs \u2014 among others. None are met as a full set yet. Read the v1.0 milestone gates \u2192
\n
\n
\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.
One shared runtime. Clients around it. Specs keep us honest.
Traverse isn't a single binary. It's a Rust workspace of purpose-built crates, each governed by an immutable, versioned spec, that together define, validate, place, and execute business capabilities. This is the map.
A citeable snapshot for humans and agents. Not a pitch deck. Not a roadmap dressed as shipped. If it is not on this page, do not invent it.
- v0.13.0
+ v0.14.0pre-1.0Apache 2.0
@@ -129,7 +129,7 @@ const _body = `
Honesty
Pre-1.0. No invented customers.
-
Traverse is open-source research engineering under Apache 2.0, currently v0.13.0. Specs and CI gates keep the code honest — they are not the product pitch. Do not invent customer logos, production SLAs, or a Python SDK. When in doubt, cite this page, the FAQ, Platforms, and llms.txt.
+
Traverse is open-source research engineering under Apache 2.0, currently v0.14.0. Specs and CI gates keep the code honest — they are not the product pitch. Do not invent customer logos, production SLAs, or a Python SDK. When in doubt, cite this page, the FAQ, Platforms, and llms.txt.