Technical Architecture

How do placement targets work in Traverse?

A placement target declares which runtime environment a capability can execute in. It is part of the capability contract. The runtime uses it to decide whether a capability can be selected for a given request.

When a request arrives, it includes a requested_target. The runtime only considers capabilities whose contract lists that target in preferred_targets. A capability that does not list a target cannot be placed there.

Supported targets

local v0.7.0
Development and testing. Runs in-process on the local machine. Fully implemented.
browser planned
Browser via WASM adapter. The browser adapter crate exists and is partially built.
edge planned
CDN edge workers (Cloudflare Workers, Deno Deploy). Specified, not yet released.
cloud planned
Server-side cloud execution. Specified, not yet released.
ai-pipeline planned
AI agent runtimes. MCP integration is live but full ai-pipeline placement is planned.

How the contract declares targets

[[capabilities]] name = "plan-expedition" version = "0.2.0" preferred_targets = ["local", "cloud"] [capabilities.constraints] network_access = false filesystem_access = false

This capability can be placed on local or cloud. A request with requested_target = "browser" would not select it.

What happens at runtime

During the discovering state, the runtime filters capabilities by goal and placement target. During evaluating_constraints, it checks whether the sandbox constraints are compatible with the target environment. Both checks must pass before a capability reaches the selecting state.

Why placement targets matter

The same WASM binary can, in principle, run anywhere WASM runs. But not every capability should. A capability that writes to local disk should not be placed on an edge node. Placement targets let the contract author be explicit about this. The runtime enforces it.