Question

How do I run the Traverse expedition example?

The expedition planning example is the canonical demo. It runs 6 capabilities, 5 events, and 1 workflow entirely on your local machine. Here is the full walkthrough.

1 Clone and build

If you have not already, clone the repository and run a full build:

git clone https://github.com/traverse-framework/traverse
cd traverse
cargo build

This compiles all crates, including the WASM capability modules. The first build takes a few minutes. See the install guide for prerequisites.

2 Inspect the bundle

Verify the build by inspecting the registry bundle. This shows all 6 capabilities indexed with their contract metadata:

cargo run -p traverse-cli -- bundle inspect

You should see capability IDs, versions, placement targets, and constraint declarations printed to the terminal. If this runs without error, the runtime is healthy.

3 Start the browser adapter

The browser adapter is the local HTTP server that your frontend talks to. Start it in a terminal and leave it running:

cargo run -p traverse-cli -- browser-adapter serve --bind 127.0.0.1:4174

You should see output like Traverse browser adapter listening on 127.0.0.1:4174. The adapter loads the bundle, initializes the registry, and waits for requests.

4 Start the React demo

Open a second terminal. Start the React demo server:

node apps/react-demo/server.mjs

This serves the React frontend on a local port. Node.js is required for this step.

5 Submit a request in the browser

Open the URL printed by the React server (typically http://localhost:3000 or similar). Fill in the expedition planning form and submit. The frontend sends a request to the browser adapter, which runs the workflow through all 6 capabilities in sequence.

What to expect in the terminal

In the browser adapter terminal you will see one line per capability execution: the capability ID, the placement target used, whether preconditions passed, and whether the result passed postcondition validation. After all 6 capabilities complete, the adapter returns a JSON response to the frontend with the plan output and a full trace artifact.

The trace artifact is the structured record of the entire run. It tells you exactly what happened, in order, with every contract check logged. This is what makes Traverse auditable by design.

What you have just seen

  • The runtime discover capabilities from the registry bundle
  • Contract preconditions validated before each capability runs
  • WASM binaries executed in a sandboxed environment
  • Postconditions validated against each output
  • A trace artifact produced covering the entire workflow

From here, read the concepts documentation to understand what you just observed, or look at the capability source code in crates/traverse-expedition-wasm/ to see how capabilities are written.