From 1cc7a21e51ab67b0f36eb374dfe5b14b0d503315 Mon Sep 17 00:00:00 2001 From: Enrico Piovesan Date: Tue, 29 Sep 2026 15:02:30 -0600 Subject: [PATCH 1/3] docs(site): v0.14.0 truth-pass (llms, exact-ref, current pins) Bump current-state package pins to crates/npm 0.14.0 and registry =0.25.0; refresh exact-ref Q&A for signed schema 2.0.0, host-owned trust, digits-mlp test-key caveat, and native+web-only execute. Leave historical v0.13.0 blog facts and weekly-demos blog-first note. --- package.json | 2 +- public/llms.txt | 6 ++--- src/components/Footer.astro | 2 +- src/pages/about.astro | 2 +- src/pages/changelog.astro | 5 ++-- src/pages/docs/concepts.astro | 2 +- src/pages/docs/quickstart.astro | 4 ++-- src/pages/faq.astro | 2 +- src/pages/index.astro | 2 +- src/pages/platforms.astro | 2 +- .../is-traverse-production-ready.astro | 6 ++--- .../what-is-exact-ref-model-execution.astro | 24 +++++++++---------- .../what-is-one-shared-runtime-wasm.astro | 4 ++-- src/pages/questions/what-is-traverse.astro | 4 ++-- src/pages/roadmap.astro | 2 +- src/pages/system.astro | 2 +- src/pages/what-is-real-today.astro | 4 ++-- 17 files changed, 38 insertions(+), 37 deletions(-) diff --git a/package.json b/package.json index 2c7b1dd..ad37603 100644 --- a/package.json +++ b/package.json @@ -13,7 +13,7 @@ }, "dependencies": { "astro": "7.3.4", - "traverse-embedder-web": "^0.13.0" + "traverse-embedder-web": "^0.14.0" }, "devDependencies": { "@playwright/test": "^1.63.0" diff --git a/public/llms.txt b/public/llms.txt index af987a8..597d81a 100644 --- a/public/llms.txt +++ b/public/llms.txt @@ -1,6 +1,6 @@ # Traverse -> Traverse is a governed capability runtime for portable business logic. Value loop: **discover → execute → trace**. Usual authoring is skill-first plain English via `traverse-capability-author` (contract → WASM → human-reviewed PR); manual authoring still uses Rust→WASM — you do **not** need to write Rust for the usual path. One shared `runtime.wasm`; browser, native desktop, CLI, and MCP are clients/embedders, not different Traverse runtimes. Shipped consumers today: JS/TS (`traverse-embedder-web`), Rust (`traverse-embedder`), agents via `traverse-mcp`; Python shells out to `traverse-cli capability-package execute` (**no Python SDK**). Swift/Kotlin/.NET are in-tree only (not certified public packages); edge is planned; cloud placement is an explicit non-goal for v0.1 — see /platforms.html and /what-is-real-today.html. Apache 2.0, pre-1.0 (v0.13.0). The agent proposes; the runtime decides. +> Traverse is a governed capability runtime for portable business logic. Value loop: **discover → execute → trace**. Usual authoring is skill-first plain English via `traverse-capability-author` (contract → WASM → human-reviewed PR); manual authoring still uses Rust→WASM — you do **not** need to write Rust for the usual path. One shared `runtime.wasm`; browser, native desktop, CLI, and MCP are clients/embedders, not different Traverse runtimes. Shipped consumers today: JS/TS (`traverse-embedder-web`), Rust (`traverse-embedder`), agents via `traverse-mcp`; Python shells out to `traverse-cli capability-package execute` (**no Python SDK**). Swift/Kotlin/.NET are in-tree only (not certified public packages); edge is planned; cloud placement is an explicit non-goal for v0.1 — see /platforms.html and /what-is-real-today.html. Apache 2.0, pre-1.0 (v0.14.0). The agent proposes; the runtime decides. - Start here (narrative): https://traverse-framework.com/blog/what-is-real-today-start-here.html - How do I start with Traverse as an agent?: https://traverse-framework.com/questions/how-do-i-start-with-traverse-as-an-agent.html - What does Traverse not claim yet?: https://traverse-framework.com/questions/what-does-traverse-not-claim-yet.html @@ -9,7 +9,7 @@ Traverse is not a web framework, an agent-orchestration framework, or a general microservices platform. It governs one thing well: a single piece of business logic that must behave identically and auditably on every host where it actually ships. Specs and registry catalog size are governance hygiene, not the pitch. -Current packages: crates.io at 0.13.0 (pin `traverse-registry` at `=0.24.0` if you consume it directly); npm `traverse-embedder-web@0.13.0`. +Current packages: crates.io at 0.14.0 (pin `traverse-registry` at `=0.25.0` if you consume it directly); npm `traverse-embedder-web@0.14.0`. ## Required reading (agents) @@ -57,7 +57,7 @@ Current packages: crates.io at 0.13.0 (pin `traverse-registry` at `=0.24.0` if y - [Changelog](https://traverse-framework.com/changelog.html): release-by-release history. - [Security & Permanence Audit](https://traverse-framework.com/security-audit.html): every known finding, its GitHub ticket, and its real status — not a marketing page. - [FAQ](https://traverse-framework.com/faq.html) and [Questions](https://traverse-framework.com/questions.html): 70+ specific Q&A pages, mostly long-tail but accurate. -- [What is exact-ref model execution?](https://traverse-framework.com/questions/what-is-exact-ref-model-execution.html): app manifests pin digest/signature, never a naked URL; Spec 137 `model.execute` envelopes; ships in published v0.12.0. +- [What is exact-ref model execution?](https://traverse-framework.com/questions/what-is-exact-ref-model-execution.html): signed schema `2.0.0` + `model.sig.json`; host-owned trust; `digits-mlp-1.0.0` (test-only key; prod signing #1567); native+web execute only in v0.14.0 (first landed in v0.12.0). - [How does Traverse complement Hugging Face?](https://traverse-framework.com/questions/how-does-traverse-complement-hugging-face.html): Hub = provenance; Traverse = pinned signed client-first capability; not Transformers.js/Hub replacement; no defer promise until a second executor exists. ## Optional diff --git a/src/components/Footer.astro b/src/components/Footer.astro index 83eb1e3..fb6ba54 100644 --- a/src/components/Footer.astro +++ b/src/components/Footer.astro @@ -11,7 +11,7 @@

Contract-driven WASM runtime for device-independent business capabilities.

- v0.13.0 + v0.14.0 Apache 2.0
diff --git a/src/pages/about.astro b/src/pages/about.astro index 7dab352..40fdacf 100644 --- a/src/pages/about.astro +++ b/src/pages/about.astro @@ -1,7 +1,7 @@ --- import SubpageLayout from '@layouts/SubpageLayout.astro'; -const _body = "
\n
\n About\n

Built from real problems.
Not from a whiteboard.

\n

Traverse is personal research turned into a runtime. It exists because the same engineering wall kept appearing in different companies, different industries, different codebases. This is the answer to that wall.

\n
\n\n
\n
\n\n
\n
The engineer behind it
\n

Years building products that kept hitting the same wall.

\n

Enrico Piovesan has spent years shipping products across travel platforms, payments infrastructure, automotive software, and design tools at global scale. The companies were different. The tech stacks were different. The wall was always the same.

\n

Business logic gets written once for the environment it needs to work in right now. Then the next environment comes. A mobile app. An edge deployment. An AI pipeline. The same logic gets rewritten. Sometimes by the same team. Often not. The second version drifts from the first. The third is unrecognizable.

\n

Teams that were there at the start could navigate it. Teams that arrived later could not. People left. The codebase became archaeology.

\n

Traverse is what happens when you get tired of watching that pattern repeat.

\n
\n\n
\n
Philosophy
\n
\n

Software should work for users, not for the runtime it happens to run on.

\n Enrico Piovesan\n
\n
\n\n
\n
A body of work
\n

The questions came first. The runtime came last.

\n

Traverse did not start as a runtime idea. It started as a series of questions that each had to be answered before the next one could be asked. Each question became a published piece of work. The runtime is where those answers become executable.

\n\n
\n\n
\n
2023
\n
\n
Client-Side Microservices Architecture
\n

Asked why the browser was treated as a thin presentation layer when it was already a capable execution environment. Showed how microservice patterns could work entirely client-side, without a server in the loop for business logic.

\n
\n
\n\n
\n
2024
\n
\n
Universal Microservices Architecture (UMA)
\n

Asked why business logic had to be rewritten for every runtime. Defined the architectural pattern for capabilities that run anywhere. Published as a book on Amazon: 13 chapters, with runnable Rust and WASM examples throughout.

\n Read on Amazon →\n ·\n universalmicroservices.com →\n
\n
\n\n
\n
2025
\n
\n
Contract-Driven AI Development (C-DAD)
\n

Asked why AI agents struggled to navigate codebases that had no contracts. Defined a methodology where every capability exposes a machine-readable contract that agents can read and reason about. Published as a whitepaper.

\n Read the whitepaper →\n
\n
\n\n
\n
2025
\n
\n
Traverse
\n

The runtime where the answers to those questions become executable. WASM-based, contract-governed, trace-producing. Runs business logic natively and in the browser today, without rewriting it as new placements ship. Open source, Apache 2.0.

\n View on GitHub →\n
\n
\n\n
\n
\n\n
\n
Current status
\n

Shipping. Honest about what is not done yet.

\n

v0.13.0 is out. The useful loop is discover a governed capability, execute known behavior, and read the trace. Core runtime, CLI, MCP, and the published Rust and Web embedders work today. Specs and CI gates are how we stay honest — not the product pitch.

\n

Some executor targets are planned but not yet shipped. Edge and cloud adapters are next. There is no Python SDK — Python consumes today by shelling out to traverse-cli capability-package execute. The public roadmap is honest about what is shipping now and what comes later.

\n

This is one person building something real. Not a startup with a deck. Not a proof of concept that will never ship. The code is there. You can run the discover → execute → trace loop yourself.

\n
\n\n
\n\n \n \n
\n
"; +const _body = "
\n
\n About\n

Built from real problems.
Not from a whiteboard.

\n

Traverse is personal research turned into a runtime. It exists because the same engineering wall kept appearing in different companies, different industries, different codebases. This is the answer to that wall.

\n
\n\n
\n
\n\n
\n
The engineer behind it
\n

Years building products that kept hitting the same wall.

\n

Enrico Piovesan has spent years shipping products across travel platforms, payments infrastructure, automotive software, and design tools at global scale. The companies were different. The tech stacks were different. The wall was always the same.

\n

Business logic gets written once for the environment it needs to work in right now. Then the next environment comes. A mobile app. An edge deployment. An AI pipeline. The same logic gets rewritten. Sometimes by the same team. Often not. The second version drifts from the first. The third is unrecognizable.

\n

Teams that were there at the start could navigate it. Teams that arrived later could not. People left. The codebase became archaeology.

\n

Traverse is what happens when you get tired of watching that pattern repeat.

\n
\n\n
\n
Philosophy
\n
\n

Software should work for users, not for the runtime it happens to run on.

\n Enrico Piovesan\n
\n
\n\n
\n
A body of work
\n

The questions came first. The runtime came last.

\n

Traverse did not start as a runtime idea. It started as a series of questions that each had to be answered before the next one could be asked. Each question became a published piece of work. The runtime is where those answers become executable.

\n\n
\n\n
\n
2023
\n
\n
Client-Side Microservices Architecture
\n

Asked why the browser was treated as a thin presentation layer when it was already a capable execution environment. Showed how microservice patterns could work entirely client-side, without a server in the loop for business logic.

\n
\n
\n\n
\n
2024
\n
\n
Universal Microservices Architecture (UMA)
\n

Asked why business logic had to be rewritten for every runtime. Defined the architectural pattern for capabilities that run anywhere. Published as a book on Amazon: 13 chapters, with runnable Rust and WASM examples throughout.

\n Read on Amazon →\n ·\n universalmicroservices.com →\n
\n
\n\n
\n
2025
\n
\n
Contract-Driven AI Development (C-DAD)
\n

Asked why AI agents struggled to navigate codebases that had no contracts. Defined a methodology where every capability exposes a machine-readable contract that agents can read and reason about. Published as a whitepaper.

\n Read the whitepaper →\n
\n
\n\n
\n
2025
\n
\n
Traverse
\n

The runtime where the answers to those questions become executable. WASM-based, contract-governed, trace-producing. Runs business logic natively and in the browser today, without rewriting it as new placements ship. Open source, Apache 2.0.

\n View on GitHub →\n
\n
\n\n
\n
\n\n
\n
Current status
\n

Shipping. Honest about what is not done yet.

\n

v0.14.0 is out. The useful loop is discover a governed capability, execute known behavior, and read the trace. Core runtime, CLI, MCP, and the published Rust and Web embedders work today. Specs and CI gates are how we stay honest — not the product pitch.

\n

Some executor targets are planned but not yet shipped. Edge and cloud adapters are next. There is no Python SDK — Python consumes today by shelling out to traverse-cli capability-package execute. The public roadmap is honest about what is shipping now and what comes later.

\n

This is one person building something real. Not a startup with a deck. Not a proof of concept that will never ship. The code is there. You can run the discover → execute → trace loop yourself.

\n
\n\n
\n\n \n \n
\n
"; --- +
Changelog

Release history

What shipped in Traverse. Each release is backed by versioned, reviewable work.

View all releases on GitHub →

-

App state machine and target-neutral host authorities

v0.13.0 is a minor lockstep crate + npm release. Its throughline is the discover → execute → trace loop for governed, standalone embedder apps: Spec 139-embedder-app-state-machine-execution lands the app command state machine that drives that loop end to end, and Spec 140-host-authority-wit-adapters gives it target-neutral host authorities — including a real audio-input capability. crates.io and npm packages are at 0.13.0.

  • App state machine (Spec 139): app_command envelopes (embedder-api 1.1.0) and the state machine driver across Swift, Kotlin, .NET, and web, validated against one shared cross-host golden event log. Decision 99: invoke.input_from resolves host_connector_result.<field> at runtime; app validate rejects an unreachable reference.
  • Host authorities and audio-input (Spec 140): WIT host-adapter interfaces make host authorities target-neutral and runtime-owned (Decision 97), landing first for traverse.audio-input. Real adapters: Apple AVAudioEngine (verified on physical microphone hardware) and browser capture / permission. Bounded artifact staging shared by runtime, web, and Swift.
  • Native publish pipelines: automated release workflows for Maven Central, nuget.org, and the Swift TraverseSwiftHost.xcframework; Kotlin TraverseEmbedder at embedder-api 1.1.0 parity.
  • Security hardening (Decision 100): RuntimeWasmHost runs under explicit fuel and memory limits and fails closed on an out-of-bounds guest response; backup restore bounds decompressed archive-member size.
  • Web fixes: event order under reentrant subscriptions, pinned and zero-major registry version ranges, non-string IndexedDB state keys rejected, accurate browser planner truncation, matching JSON types required in browser plans.

Upgrade note: pin traverse-embedder-web@0.13.0 with crates at 0.13.0 (lockstep). Apps using invoke.input_from with host_connector_result.<field> need Spec 139 0.2.0 / Spec 138 0.3.0 or later. Swift consumers: TraverseSwiftHost now resolves from the swift-host-v0.13.0 release — there is no GitHub Release object for v0.13.0 (immutable-releases policy). The certified runtime.wasm digest changes in this cut (sha256:a254c161…).

Read the v0.13.0 release notes → · Announcement

+

Signed exact-ref models + digits-mlp

v0.14.0 is a minor lockstep crate + npm release with breaking Spec 138 exact-ref surface changes (0.x minor convention). Model manifests move to schema 2.0.0 with detached Ed25519 model.sig.json; host-owned trust roots; first trained digits-mlp-1.0.0 (test-only key; production signing tracked separately). Exact-ref execute is native + web only — Swift/Kotlin/.NET do not execute exact-ref yet. Pin crates/npm at 0.14.0 and traverse-registry at =0.25.0. Product Release: Traverse v0.14.0.

+

App state machine and target-neutral host authorities

v0.13.0 is a minor lockstep crate + npm release. Its throughline is the discover → execute → trace loop for governed, standalone embedder apps: Spec 139-embedder-app-state-machine-execution lands the app command state machine that drives that loop end to end, and Spec 140-host-authority-wit-adapters gives it target-neutral host authorities — including a real audio-input capability. crates.io and npm packages are at 0.13.0.

  • App state machine (Spec 139): app_command envelopes (embedder-api 1.1.0) and the state machine driver across Swift, Kotlin, .NET, and web, validated against one shared cross-host golden event log. Decision 99: invoke.input_from resolves host_connector_result.<field> at runtime; app validate rejects an unreachable reference.
  • Host authorities and audio-input (Spec 140): WIT host-adapter interfaces make host authorities target-neutral and runtime-owned (Decision 97), landing first for traverse.audio-input. Real adapters: Apple AVAudioEngine (verified on physical microphone hardware) and browser capture / permission. Bounded artifact staging shared by runtime, web, and Swift.
  • Native publish pipelines: automated release workflows for Maven Central, nuget.org, and the Swift TraverseSwiftHost.xcframework; Kotlin TraverseEmbedder at embedder-api 1.1.0 parity.
  • Security hardening (Decision 100): RuntimeWasmHost runs under explicit fuel and memory limits and fails closed on an out-of-bounds guest response; backup restore bounds decompressed archive-member size.
  • Web fixes: event order under reentrant subscriptions, pinned and zero-major registry version ranges, non-string IndexedDB state keys rejected, accurate browser planner truncation, matching JSON types required in browser plans.

Upgrade note: pin traverse-embedder-web@0.13.0 with crates at 0.13.0 (lockstep). Apps using invoke.input_from with host_connector_result.<field> need Spec 139 0.2.0 / Spec 138 0.3.0 or later. Swift consumers: TraverseSwiftHost now resolves from the swift-host-v0.13.0 release — there is no GitHub Release object for v0.13.0 (immutable-releases policy). The certified runtime.wasm digest changes in this cut (sha256:a254c161…).

Read the v0.13.0 release notes → · Announcement

Exact-ref governed model.execute

v0.12.0 is a minor lockstep crate + npm release. Spec 138-governed-exact-model-execution / ADR-0074 lands host-staged traverse.model-runtime / model.execute for exact pinned WASM model packages on native and browser wasm-cpu. crates.io and npm packages are at 0.12.0.

  • Host-owned package store, single-consume staged I/O refs, and fail-closed policy / pin / digest checks behind Spec 137 model.execute.
  • CPU-WASM guest ABI with the echo fixture under fixtures/models/fixture-echo-1.0.0/; connector contract traverse.model-runtime 2.0.0.
  • traverse-embedder-web exports matching stage / execute / read helpers so browser hosts share the same envelope contract as native ExactModelHostConnector.

Upgrade note: apps that want local exact-ref models must declare exact_model_dependencies and use matching model_ref digests — provider authority fields on model.execute payloads fail closed. Pin traverse-embedder-web@0.12.0 with crates at 0.12.0. Pin traverse-registry =0.22.0 if you consume it directly. Certified runtime.wasm digest is unchanged from 0.11.0.

Read the v0.12.0 release notes →

One real runtime.wasm across native and browser

v0.11.0 is a minor lockstep crate + npm release. Native hosts and traverse-embedder-web drive the same nested-wasmi capability executor inside an application-owned runtime.wasm, instead of a canned WAT fixture or a hand-rolled TypeScript WASI/emit_event path. Spec 1402 is complete. crates.io and npm packages are at 0.11.0.

  • Nested-wasmi executor in traverse-runtime-wasm; shared engine-agnostic emit_event and placement validation in traverse-contracts.
  • Production RuntimeWasmHost driver; Swift/wasmi, Kotlin/Chicory, and .NET/Wasmtime conform against the real artifact; digest published via the native runtime artifact registry.
  • Browser BundleEmbedder and composedWorkflow load digest-verified runtime/runtime.wasm from the app bundle and retire the interim TypeScript executor.

Upgrade note: app bundles must include runtime/runtime.wasm and runtime/runtime.wasm.sha256. Bundles without them fail closed at init. Pin traverse-registry =0.21.0 if you consume it directly.

Read the v0.11.0 release notes →

Verified Registry prep, Mode A/B MCP, and host connectors

v0.10.2 is a compatibility-preserving patch for the public runtime, embedders, MCP hosts, and CLI. It ships the work that landed on main after the v0.10.1 compatibility fixes. Rust crate APIs and the traverse-cli binary name are unchanged for existing local-execution callers. crates.io packages are at 0.10.2; npm traverse-embedder-web@0.10.2 is published and aligned with this cut.

  • Hosts prepare an active signed Registry release into a host-owned cache under digest keys. app validate, app register, and app activate consume prepared evidence only — no fetch-at-activate, no version substitution.
  • Mode A verified-registry MCP host over host-owned public metadata; Mode B via traverse-mcp prepare-cache then traverse-mcp stdio --cache for discover/validate/execute/report from that cache alone.
  • Public app-runtime port for manifest-selected, explicitly activated host connector commands (audio.capture first; model.execute on the same envelopes).
  • component-wit-v1 host-capability activation; persisted capability hydration for serve; app availability status; ArtifactRouter WASI diagnosis; default WASM linear memory raised to 32 MiB.
  • Browser-local deterministic planning and offline composed-workflow execution (Rust embedder and traverse-embedder-web). Plan-then-seal is the default; adaptive composition is opt-in.

Upgrade note: Registry-backed app validate/register/activate require a prepared host-owned cache. Legacy serve registrations without a persisted state_machine need an explicit app register refresh. Pin traverse-registry =0.20.0 if you consume it directly.

Read the v0.10.2 release notes →
diff --git a/src/pages/docs/concepts.astro b/src/pages/docs/concepts.astro index 2fca983..2673fd2 100644 --- a/src/pages/docs/concepts.astro +++ b/src/pages/docs/concepts.astro @@ -3,7 +3,7 @@ import SubpageLayout from '@layouts/SubpageLayout.astro'; import DocsSidebar from '@components/DocsSidebar.astro'; const _docsBefore = "
\n \n "; -const _docsAfter = "
\n
\n
Core Concepts
\n

How Traverse works

\n

The key ideas behind contracts, registries, runtime execution, placement, traces, and workflows.

\n
\n\n \n
\n

Capability Contracts

\n

Every capability in Traverse is governed by a machine-readable contract. The contract is the source of truth. It declares what the capability does, what inputs it requires, what outputs it guarantees, and where it can run.

\n

Nothing executes without a verified contract. The runtime reads the contract before placement, validates inputs against its schema before execution, and validates outputs against its schema after — that gating is real and runtime-evaluated. Declared preconditions and postconditions are documentation for reviewers today, not yet a separate runtime-evaluated check.

\n
\n
contract.json: anatomy
\n
\n
{\n  // Identity\n  \"id\": \"namespace.name\",          // e.g. \"pricing.eligibility-check\"\n  \"version\": \"MAJOR.MINOR.PATCH\",\n\n  // Lifecycle: draft | active | deprecated | retired | archived\n  \"lifecycle\": \"active\",\n\n  // What must be true before it runs, and what it guarantees after\n  \"preconditions\": [{ \"id\": \"...\", \"description\": \"...\" }],\n  \"postconditions\": [{ \"id\": \"...\", \"description\": \"...\" }],\n\n  // Execution\n  \"execution\": {\n    \"binary_format\": \"wasm\",\n    \"entrypoint\": { \"kind\": \"wasi-command\", \"command\": \"run\" },\n    \"preferred_targets\": [\"edge\", \"cloud\"],\n    \"constraints\": {\n      \"host_api_access\": \"none\",       // none | exception_required\n      \"network_access\": \"forbidden\",   // forbidden | required\n      \"filesystem_access\": \"none\"     // none | sandbox_only\n    }\n  },\n\n  // Input/output schemas (JSON Schema, nested under \"schema\")\n  \"inputs\": { \"schema\": { /* JSON Schema */ } },\n  \"outputs\": { \"schema\": { /* JSON Schema */ } },\n\n  // Events this capability emits or reacts to\n  \"emits\": [\"event-id-1\"],\n  \"consumes\": [\"event-id-2\"]\n}
\n
\n
\n

Event contracts follow the same pattern: identity, payload schema, publishers, subscribers, and compatibility policy.

\n
\n\n \n
\n

Registry

\n

The registry is the single source of truth for what the system can do. It holds capability contracts, event contracts, and workflow definitions. All of them are indexed and queryable at runtime.

\n

Capabilities are loaded into the registry via registry bundles — manifests that group related capabilities, events, and workflows into a deployable unit. The CLI validates bundles before they are registered.

\n
\n
bundle structure
\n
\n
registry-bundle/
\n
manifest.json
\n
capabilities/
\n
plan-expedition/contract.json
\n
interpret-intent/contract.json
\n
events/
\n
expedition-plan-assembled/contract.json
\n
workflows/
\n
plan-expedition/definition.json
\n
\n
\n

AI agents and orchestrators query the registry to discover capabilities by contract. Composition follows declared contracts — not inferred APIs or guesswork.

\n
\n\n \n
\n

Runtime & Execution Model

\n

The Traverse runtime is a state machine. Each execution follows a deterministic path from idle to completed (or error). Every state transition is recorded in the trace.

\n
\n
idle
\n
→
\n
loading_registry
\n
→
\n
ready
\n
→
\n
discovering
\n
→
\n
evaluating_constraints
\n
→
\n
selecting
\n
→
\n
executing
\n
→
\n
emitting_events
\n
→
\n
completed
\n
/
\n
error
\n
\n

The runtime resolves the correct capability from the registry, validates inputs against the contract, executes the WASM binary, validates outputs, emits declared events, and writes the trace. Same inputs always produce the same path.

\n
\n

Core crates

\n
\n
traverse-runtimeCore execution engine
\n
traverse-contractsContract parsing & validation
\n
traverse-registryCapability & event registries
\n
traverse-clibundle · app · capability · workflow
\n
traverse-mcpMCP stdio server
\n
\n
\n
\n\n \n
\n

Placement Targets

\n

Placement is a client decision, not a fixed deployment target. A capability is device-independent — the same WASM binary runs on any client without modification, and executes locally by default. The contract declares which environments a capability is allowed to run in; the client evaluates that against its own context (resource constraints, latency, connectivity) and decides, heuristically, whether to run locally or delegate a subset of the capability to the server.

\n
\n
\n
browser
\n
Executes inside the user's browser via the local adapter. No network required.
\n
\n
\n
edge
\n
Runs at the network edge. Low latency, close to the user.
\n
\n
\n
cloud
\n
Standard cloud execution. Used as fallback when edge is unavailable.
\n
\n
\n
ai-pipeline
\n
Embedded in an AI agent workflow. Governed and contract-validated.
\n
\n
\n
local
\n
Local machine execution. The default executor on native hosts as of v0.13.0.
\n
\n
\n
device
\n
On-device execution for edge hardware scenarios.
\n
\n
\n

Currently, local (native) and browser are the only targets with a real, shipped executor — see Platforms for the full, evidence-linked status. Other targets are specified in contracts and will be resolved as executor adapters ship.

\n
\n\n \n
\n

Trace Artifacts

\n

Every execution produces a structured trace artifact. The trace records every decision the runtime made: which capability was discovered, why it was selected, what inputs were validated, what events were emitted, and what the final output was.

\n

Traces are queryable and auditable. For AI pipelines they are the compliance record. Proof that every action was governed by a contract.

\n
\n
trace artifact
\n
\n
{\n  \"trace_id\": \"trv_8f2a1c...\",\n  \"capability\": \"expedition.planning.plan-expedition\",\n  \"version\": \"1.0.0\",\n  \"status\": \"completed\",\n  \"placement\": \"local\",\n  \"discovery\": {\n    \"candidates\": 1,\n    \"selected\": \"plan-expedition\",\n    \"reason\": \"contract match · preferred target\"\n  },\n  \"execution\": {\n    \"steps\": 5,\n    \"events_emitted\": 5,\n    \"duration_ms\": 142\n  },\n  \"inputs_valid\": true,\n  \"outputs_valid\": true\n}
\n
\n
\n
\n\n \n
\n

Workflow Composition

\n

Workflows compose multiple capabilities into a deterministic execution graph. Each node names one governed capability and how data flows to and from it; each edge names the trigger that advances traversal to the next node. The runtime traverses the graph in order. Same inputs, same path, every time.

\n

Workflow definitions declare: the nodes (each a capability, reading fields via from_workflow_input and writing them via to_workflow_state into the workflow's accumulated state — not just its original input), the edges connecting them, a start_node, and the terminal_nodes where traversal ends. The runtime validates the composition before any execution begins.

\n
\n
workflow definition (excerpt)
\n
\n
{\n  \"kind\": \"workflow_definition\",\n  \"id\": \"expedition.planning.plan-expedition\",\n  \"version\": \"1.0.0\",\n  \"nodes\": [\n    {\n      \"node_id\": \"capture_objective\",\n      \"capability_id\": \"expedition.planning.capture-expedition-objective\",\n      \"input\": { \"from_workflow_input\": [\"destination\"] },\n      \"output\": { \"to_workflow_state\": [\"objective\"] }\n    },\n    {\n      \"node_id\": \"interpret_intent\",\n      \"capability_id\": \"expedition.planning.interpret-expedition-intent\",\n      \"input\": { \"from_workflow_input\": [\"objective\"] },\n      \"output\": { \"to_workflow_state\": [\"interpreted_intent\"] }\n    }\n  ],\n  \"edges\": [\n    { \"from\": \"capture_objective\", \"to\": \"interpret_intent\", \"trigger\": \"direct\" }\n  ],\n  \"start_node\": \"capture_objective\",\n  \"terminal_nodes\": [\"assemble_plan\"]\n}
\n
\n
\n
\n\n \n
\n

Spec-Driven Development

\n

Traverse is built spec-first. Every component has an approved, versioned specification before implementation begins. The spec is the source of truth. The code is the proof.

\n

152 governing specs are approved as of v0.13.0, covering everything from the foundation, capability and event contracts, and the registries through runtime execution, placement routing, the embedder SDKs, the durable event journal, and the example domains. The first nine — foundation, capability contracts, event contracts, the spec alignment gate, the capability registry, runtime request execution, workflow registry traversal, and the expedition domain and artifacts — remain the core of the system.

\n
\n

CI gates — every PR must pass

\n
\n
Spec alignment gate — code matches approved spec
\n
100% test coverage for core logic
\n
No unsafe code (#![forbid(unsafe_code)])
\n
No unwrap / panic / TODO in production code
\n
Formatting, linting, dependency checks
\n
SBOM generation (CycloneDX)
\n
\n
\n
\n
\n
\n\n"; +const _docsAfter = "
\n
\n
Core Concepts
\n

How Traverse works

\n

The key ideas behind contracts, registries, runtime execution, placement, traces, and workflows.

\n
\n\n \n
\n

Capability Contracts

\n

Every capability in Traverse is governed by a machine-readable contract. The contract is the source of truth. It declares what the capability does, what inputs it requires, what outputs it guarantees, and where it can run.

\n

Nothing executes without a verified contract. The runtime reads the contract before placement, validates inputs against its schema before execution, and validates outputs against its schema after — that gating is real and runtime-evaluated. Declared preconditions and postconditions are documentation for reviewers today, not yet a separate runtime-evaluated check.

\n
\n
contract.json: anatomy
\n
\n
{\n  // Identity\n  \"id\": \"namespace.name\",          // e.g. \"pricing.eligibility-check\"\n  \"version\": \"MAJOR.MINOR.PATCH\",\n\n  // Lifecycle: draft | active | deprecated | retired | archived\n  \"lifecycle\": \"active\",\n\n  // What must be true before it runs, and what it guarantees after\n  \"preconditions\": [{ \"id\": \"...\", \"description\": \"...\" }],\n  \"postconditions\": [{ \"id\": \"...\", \"description\": \"...\" }],\n\n  // Execution\n  \"execution\": {\n    \"binary_format\": \"wasm\",\n    \"entrypoint\": { \"kind\": \"wasi-command\", \"command\": \"run\" },\n    \"preferred_targets\": [\"edge\", \"cloud\"],\n    \"constraints\": {\n      \"host_api_access\": \"none\",       // none | exception_required\n      \"network_access\": \"forbidden\",   // forbidden | required\n      \"filesystem_access\": \"none\"     // none | sandbox_only\n    }\n  },\n\n  // Input/output schemas (JSON Schema, nested under \"schema\")\n  \"inputs\": { \"schema\": { /* JSON Schema */ } },\n  \"outputs\": { \"schema\": { /* JSON Schema */ } },\n\n  // Events this capability emits or reacts to\n  \"emits\": [\"event-id-1\"],\n  \"consumes\": [\"event-id-2\"]\n}
\n
\n
\n

Event contracts follow the same pattern: identity, payload schema, publishers, subscribers, and compatibility policy.

\n
\n\n \n
\n

Registry

\n

The registry is the single source of truth for what the system can do. It holds capability contracts, event contracts, and workflow definitions. All of them are indexed and queryable at runtime.

\n

Capabilities are loaded into the registry via registry bundles — manifests that group related capabilities, events, and workflows into a deployable unit. The CLI validates bundles before they are registered.

\n
\n
bundle structure
\n
\n
registry-bundle/
\n
manifest.json
\n
capabilities/
\n
plan-expedition/contract.json
\n
interpret-intent/contract.json
\n
events/
\n
expedition-plan-assembled/contract.json
\n
workflows/
\n
plan-expedition/definition.json
\n
\n
\n

AI agents and orchestrators query the registry to discover capabilities by contract. Composition follows declared contracts — not inferred APIs or guesswork.

\n
\n\n \n
\n

Runtime & Execution Model

\n

The Traverse runtime is a state machine. Each execution follows a deterministic path from idle to completed (or error). Every state transition is recorded in the trace.

\n
\n
idle
\n
→
\n
loading_registry
\n
→
\n
ready
\n
→
\n
discovering
\n
→
\n
evaluating_constraints
\n
→
\n
selecting
\n
→
\n
executing
\n
→
\n
emitting_events
\n
→
\n
completed
\n
/
\n
error
\n
\n

The runtime resolves the correct capability from the registry, validates inputs against the contract, executes the WASM binary, validates outputs, emits declared events, and writes the trace. Same inputs always produce the same path.

\n
\n

Core crates

\n
\n
traverse-runtimeCore execution engine
\n
traverse-contractsContract parsing & validation
\n
traverse-registryCapability & event registries
\n
traverse-clibundle · app · capability · workflow
\n
traverse-mcpMCP stdio server
\n
\n
\n
\n\n \n
\n

Placement Targets

\n

Placement is a client decision, not a fixed deployment target. A capability is device-independent — the same WASM binary runs on any client without modification, and executes locally by default. The contract declares which environments a capability is allowed to run in; the client evaluates that against its own context (resource constraints, latency, connectivity) and decides, heuristically, whether to run locally or delegate a subset of the capability to the server.

\n
\n
\n
browser
\n
Executes inside the user's browser via the local adapter. No network required.
\n
\n
\n
edge
\n
Runs at the network edge. Low latency, close to the user.
\n
\n
\n
cloud
\n
Standard cloud execution. Used as fallback when edge is unavailable.
\n
\n
\n
ai-pipeline
\n
Embedded in an AI agent workflow. Governed and contract-validated.
\n
\n
\n
local
\n
Local machine execution. The default executor on native hosts as of v0.14.0.
\n
\n
\n
device
\n
On-device execution for edge hardware scenarios.
\n
\n
\n

Currently, local (native) and browser are the only targets with a real, shipped executor — see Platforms for the full, evidence-linked status. Other targets are specified in contracts and will be resolved as executor adapters ship.

\n
\n\n \n
\n

Trace Artifacts

\n

Every execution produces a structured trace artifact. The trace records every decision the runtime made: which capability was discovered, why it was selected, what inputs were validated, what events were emitted, and what the final output was.

\n

Traces are queryable and auditable. For AI pipelines they are the compliance record. Proof that every action was governed by a contract.

\n
\n
trace artifact
\n
\n
{\n  \"trace_id\": \"trv_8f2a1c...\",\n  \"capability\": \"expedition.planning.plan-expedition\",\n  \"version\": \"1.0.0\",\n  \"status\": \"completed\",\n  \"placement\": \"local\",\n  \"discovery\": {\n    \"candidates\": 1,\n    \"selected\": \"plan-expedition\",\n    \"reason\": \"contract match · preferred target\"\n  },\n  \"execution\": {\n    \"steps\": 5,\n    \"events_emitted\": 5,\n    \"duration_ms\": 142\n  },\n  \"inputs_valid\": true,\n  \"outputs_valid\": true\n}
\n
\n
\n
\n\n \n
\n

Workflow Composition

\n

Workflows compose multiple capabilities into a deterministic execution graph. Each node names one governed capability and how data flows to and from it; each edge names the trigger that advances traversal to the next node. The runtime traverses the graph in order. Same inputs, same path, every time.

\n

Workflow definitions declare: the nodes (each a capability, reading fields via from_workflow_input and writing them via to_workflow_state into the workflow's accumulated state — not just its original input), the edges connecting them, a start_node, and the terminal_nodes where traversal ends. The runtime validates the composition before any execution begins.

\n
\n
workflow definition (excerpt)
\n
\n
{\n  \"kind\": \"workflow_definition\",\n  \"id\": \"expedition.planning.plan-expedition\",\n  \"version\": \"1.0.0\",\n  \"nodes\": [\n    {\n      \"node_id\": \"capture_objective\",\n      \"capability_id\": \"expedition.planning.capture-expedition-objective\",\n      \"input\": { \"from_workflow_input\": [\"destination\"] },\n      \"output\": { \"to_workflow_state\": [\"objective\"] }\n    },\n    {\n      \"node_id\": \"interpret_intent\",\n      \"capability_id\": \"expedition.planning.interpret-expedition-intent\",\n      \"input\": { \"from_workflow_input\": [\"objective\"] },\n      \"output\": { \"to_workflow_state\": [\"interpreted_intent\"] }\n    }\n  ],\n  \"edges\": [\n    { \"from\": \"capture_objective\", \"to\": \"interpret_intent\", \"trigger\": \"direct\" }\n  ],\n  \"start_node\": \"capture_objective\",\n  \"terminal_nodes\": [\"assemble_plan\"]\n}
\n
\n
\n
\n\n \n
\n

Spec-Driven Development

\n

Traverse is built spec-first. Every component has an approved, versioned specification before implementation begins. The spec is the source of truth. The code is the proof.

\n

152 governing specs are approved as of v0.14.0, covering everything from the foundation, capability and event contracts, and the registries through runtime execution, placement routing, the embedder SDKs, the durable event journal, and the example domains. The first nine — foundation, capability contracts, event contracts, the spec alignment gate, the capability registry, runtime request execution, workflow registry traversal, and the expedition domain and artifacts — remain the core of the system.

\n
\n

CI gates — every PR must pass

\n
\n
Spec alignment gate — code matches approved spec
\n
100% test coverage for core logic
\n
No unsafe code (#![forbid(unsafe_code)])
\n
No unwrap / panic / TODO in production code
\n
Formatting, linting, dependency checks
\n
SBOM generation (CycloneDX)
\n
\n
\n
\n
\n
\n\n"; --- +
Getting started

Quickstart

-

Build the current runtime and inspect a governed bundle. This path works with Traverse v0.13.0 and Rust 1.94 or later.

+

Build the current runtime and inspect a governed bundle. This path works with Traverse v0.14.0 and Rust 1.94 or later.

git clone https://github.com/traverse-framework/traverse.git
 cd traverse
 cargo build
diff --git a/src/pages/faq.astro b/src/pages/faq.astro
index 5ef9093..acd9931 100644
--- a/src/pages/faq.astro
+++ b/src/pages/faq.astro
@@ -1,7 +1,7 @@
 ---
 import SubpageLayout from '@layouts/SubpageLayout.astro';
 
-const _body = "
\n  
\n    FAQ\n    
Your questions, answered.
\n    
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.
\n              
Citeable snapshot: What is real today. Direction demo: agent freestyle → blocked.
\n            
\n          
\n\n          
\n            \n            
\n
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?.
\n            
\n          
\n\n          \n          
\n            \n            
\n              
Start with What is real today and the deny demo The agent freestyled a $2.4M wire. The runtime said no. (blog write-up is the public path; weekly-demos is not publicly cloneable yet — tracked in .github#30). Then Agents and llms.txt.
\n              
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.
\n    \n  
\n
";
+const _body = "
\n  
\n    FAQ\n    
Your questions, answered.
\n    
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.
\n              
Citeable snapshot: What is real today. Direction demo: agent freestyle → blocked.
\n            
\n          
\n\n          
\n            \n            
\n
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?.
\n            
\n          
\n\n          \n          
\n            \n            
\n              
Start with What is real today and the deny demo The agent freestyled a $2.4M wire. The runtime said no. (blog write-up is the public path; weekly-demos is not publicly cloneable yet — tracked in .github#30). Then Agents and llms.txt.
\n              
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    \n  
\n
";
 ---
 \n  
\n  
\n    
\n      \n      v0.13.0 · Apache 2.0 · Open source\n    
\n    
\n      Governed capability runtime.
Discover → execute → trace.\n    
\n    
\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    
\n    
\n      What is real today →\n      Deny demo →\n      Quickstart\n    
\n  
\n\n\n\n
\n  
\n    
\n      \n      
\n        
\n          
\n            
\n            pricing.toml\n          
\n          
\n            
[capability]\nname    = \"calculate-price\"\nversion = \"1.2.0\"\nwasm    = \"pricing.wasm\"\n\n[governing_spec]\ntitle   = \"Pricing Policy v3\"\nsource  = \"docs/pricing-policy.md\"\n\n[input]\ntype = \"object\"\nproperties.sku      = \"string\"\nproperties.quantity = \"integer\"\nproperties.region   = \"string\"\nrequired = [\"sku\", \"quantity\"]\n\n[output]\ntype = \"object\"\nproperties.total    = \"number\"\nproperties.currency = \"string\"\nrequired = [\"total\", \"currency\"]
\n          
\n        
\n        
\n          
\n            
\n              
\n              terminal\n            
\n            
\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.
\n    Watch the live demo →\n  
\n
\n\n\n
\n  
\n    
\n      
Runtime shape
\n      
One runtime.wasm. Clients on shipped hosts.
\n    
\n    
\n      
\n        
1
\n        
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.
\n        Learn more →\n      
\n      
\n        
\n          \n        
\n        
Eligibility and access rules
\n        
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.
\n        Learn more →\n      
\n      
\n        
\n          \n        
\n        
Compliance and audit logic
\n        
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.
\n        Learn more →\n      
\n      
\n        
\n          \n        
\n        
AI agent guardrails
\n        
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        Learn more →\n      
\n    
\n  
\n
\n\n\n
\n  
\n  
\n    
Start building with Traverse
\n    
Install the CLI, write your first contract, and run it in under five minutes.
\n    
\n      Get started →\n      View on GitHub\n    
\n  
\n
\n\n";
+const _body = "\n
\n  
\n  
\n    
\n      \n      v0.14.0 · Apache 2.0 · Open source\n    
\n    
\n      Governed capability runtime.
Discover → execute → trace.\n    
\n    
\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    
\n    
\n      What is real today →\n      Deny demo →\n      Quickstart\n    
\n  
\n
\n\n\n
\n  
\n    
\n      \n      
\n        
\n          
\n            
\n            pricing.toml\n          
\n          
\n            
[capability]\nname    = \"calculate-price\"\nversion = \"1.2.0\"\nwasm    = \"pricing.wasm\"\n\n[governing_spec]\ntitle   = \"Pricing Policy v3\"\nsource  = \"docs/pricing-policy.md\"\n\n[input]\ntype = \"object\"\nproperties.sku      = \"string\"\nproperties.quantity = \"integer\"\nproperties.region   = \"string\"\nrequired = [\"sku\", \"quantity\"]\n\n[output]\ntype = \"object\"\nproperties.total    = \"number\"\nproperties.currency = \"string\"\nrequired = [\"total\", \"currency\"]
\n          
\n        
\n        
\n          
\n            
\n              
\n              terminal\n            
\n            
\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.
\n    Watch the live demo →\n  
\n
\n\n\n
\n  
\n    
\n      
Runtime shape
\n      
One runtime.wasm. Clients on shipped hosts.
\n    
\n    
\n      
\n        
1
\n        
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.
\n        Learn more →\n      
\n      
\n        
\n          \n        
\n        
Eligibility and access rules
\n        
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.
\n        Learn more →\n      
\n      
\n        
\n          \n        
\n        
Compliance and audit logic
\n        
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.
\n        Learn more →\n      
\n      
\n        
\n          \n        
\n        
AI agent guardrails
\n        
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        Learn more →\n      
\n    
\n  
\n
\n\n\n
\n  
\n  
\n    
Start building with Traverse
\n    
Install the CLI, write your first contract, and run it in under five minutes.
\n    
\n      Get started →\n      View on GitHub\n    
\n  
\n
\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.

Web embedder SDK README → Verified entrypoint execution spec (115) → diff --git a/src/pages/questions/is-traverse-production-ready.astro b/src/pages/questions/is-traverse-production-ready.astro index 325005b..695e4bf 100644 --- a/src/pages/questions/is-traverse-production-ready.astro +++ b/src/pages/questions/is-traverse-production-ready.astro @@ -2,12 +2,12 @@ import QuestionLayout from '@layouts/QuestionLayout.astro'; const relatedLinks = []; -const _body = "

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.

 diff --git a/src/pages/questions/what-is-one-shared-runtime-wasm.astro b/src/pages/questions/what-is-one-shared-runtime-wasm.astro index 07de9bf..9461a79 100644 --- a/src/pages/questions/what-is-one-shared-runtime-wasm.astro +++ b/src/pages/questions/what-is-one-shared-runtime-wasm.astro @@ -39,8 +39,8 @@ const relatedLinks = [

Honest consumers today

    -
  • JS/TS — published npm traverse-embedder-web@0.13.0
    • -
  • Rust — published crates.io traverse-embedder@0.13.0
    • +
  • JS/TS — published npm traverse-embedder-web@0.14.0
    • +
  • Rust — published crates.io traverse-embedder@0.14.0
  • AI agents — published traverse-mcp (stdio bootstrap)
  • Python — works by shelling out to traverse-cli capability-package execute. There is no Python SDK.
  • Swift / Kotlin / .NET — exist in-tree and are usable for experimentation; they are not first-class public package releases yet.
    • diff --git a/src/pages/questions/what-is-traverse.astro b/src/pages/questions/what-is-traverse.astro index 5b74072..3e9cef7 100644 --- a/src/pages/questions/what-is-traverse.astro +++ b/src/pages/questions/what-is-traverse.astro @@ -2,8 +2,8 @@ import QuestionLayout from '@layouts/QuestionLayout.astro'; const relatedLinks = []; -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.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.

    \n

    Track live progress on the GitHub Projects board →

    \n
    \n Shipped\n Next\n Blocked\n Exploring\n Per-platform breakdown lives on Platforms →\n
    \n
    \n\n
    \n\n \n
    \n
    \n ✓\n

    Shipping now

    \n v0.13.0\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
    \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.

\n \n
\n
"; +const _body = "
\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 Shipped\n Next\n Blocked\n Exploring\n Per-platform breakdown lives on Platforms →\n
\n
\n\n
\n\n \n
\n
\n ✓\n

Shipping now

\n v0.14.0\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
\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.

\n \n
\n
"; ---

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.

- v0.13.0 + v0.14.0 pre-1.0 Apache 2.0
diff --git a/src/pages/what-is-real-today.astro b/src/pages/what-is-real-today.astro index 4841bf6..c0816b9 100644 --- a/src/pages/what-is-real-today.astro +++ b/src/pages/what-is-real-today.astro @@ -8,7 +8,7 @@ const _body = `

What is real today.

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.0 pre-1.0 Apache 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.

From 9342fdc0e79a3559e1003b3cbd4fa48c236489a4 Mon Sep 17 00:00:00 2001 From: Enrico Piovesan Date: Tue, 29 Sep 2026 15:03:21 -0600 Subject: [PATCH 2/3] chore(deps): pin traverse-embedder-web@0.14.0 in lockfile --- package-lock.json | 111 ++-------------------------------------------- 1 file changed, 4 insertions(+), 107 deletions(-) diff --git a/package-lock.json b/package-lock.json index 4d4c574..89ce90d 100644 --- a/package-lock.json +++ b/package-lock.json @@ -9,7 +9,7 @@ "version": "0.1.0", "dependencies": { "astro": "7.3.4", - "traverse-embedder-web": "^0.13.0" + "traverse-embedder-web": "^0.14.0" }, "devDependencies": { "@playwright/test": "^1.63.0" @@ -74,9 +74,6 @@ "cpu": [ "arm64" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -93,9 +90,6 @@ "cpu": [ "arm64" ], - "libc": [ - "musl" - ], "license": "MIT", "optional": true, "os": [ @@ -112,9 +106,6 @@ "cpu": [ "x64" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -131,9 +122,6 @@ "cpu": [ "x64" ], - "libc": [ - "musl" - ], "license": "MIT", "optional": true, "os": [ @@ -337,9 +325,6 @@ "cpu": [ "arm64" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -353,9 +338,6 @@ "cpu": [ "arm64" ], - "libc": [ - "musl" - ], "license": "MIT", "optional": true, "os": [ @@ -369,9 +351,6 @@ "cpu": [ "x64" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -385,9 +364,6 @@ "cpu": [ "x64" ], - "libc": [ - "musl" - ], "license": "MIT", "optional": true, "os": [ @@ -1070,9 +1046,6 @@ "cpu": [ "arm" ], - "libc": [ - "glibc" - ], "license": "LGPL-3.0-or-later", "optional": true, "os": [ @@ -1089,9 +1062,6 @@ "cpu": [ "arm64" ], - "libc": [ - "glibc" - ], "license": "LGPL-3.0-or-later", "optional": true, "os": [ @@ -1108,9 +1078,6 @@ "cpu": [ "ppc64" ], - "libc": [ - "glibc" - ], "license": "LGPL-3.0-or-later", "optional": true, "os": [ @@ -1127,9 +1094,6 @@ "cpu": [ "riscv64" ], - "libc": [ - "glibc" - ], "license": "LGPL-3.0-or-later", "optional": true, "os": [ @@ -1146,9 +1110,6 @@ "cpu": [ "s390x" ], - "libc": [ - "glibc" - ], "license": "LGPL-3.0-or-later", "optional": true, "os": [ @@ -1165,9 +1126,6 @@ "cpu": [ "x64" ], - "libc": [ - "glibc" - ], "license": "LGPL-3.0-or-later", "optional": true, "os": [ @@ -1184,9 +1142,6 @@ "cpu": [ "arm64" ], - "libc": [ - "musl" - ], "license": "LGPL-3.0-or-later", "optional": true, "os": [ @@ -1203,9 +1158,6 @@ "cpu": [ "x64" ], - "libc": [ - "musl" - ], "license": "LGPL-3.0-or-later", "optional": true, "os": [ @@ -1222,9 +1174,6 @@ "cpu": [ "arm" ], - "libc": [ - "glibc" - ], "license": "Apache-2.0", "optional": true, "os": [ @@ -1247,9 +1196,6 @@ "cpu": [ "arm64" ], - "libc": [ - "glibc" - ], "license": "Apache-2.0", "optional": true, "os": [ @@ -1272,9 +1218,6 @@ "cpu": [ "ppc64" ], - "libc": [ - "glibc" - ], "license": "Apache-2.0", "optional": true, "os": [ @@ -1297,9 +1240,6 @@ "cpu": [ "riscv64" ], - "libc": [ - "glibc" - ], "license": "Apache-2.0", "optional": true, "os": [ @@ -1322,9 +1262,6 @@ "cpu": [ "s390x" ], - "libc": [ - "glibc" - ], "license": "Apache-2.0", "optional": true, "os": [ @@ -1347,9 +1284,6 @@ "cpu": [ "x64" ], - "libc": [ - "glibc" - ], "license": "Apache-2.0", "optional": true, "os": [ @@ -1372,9 +1306,6 @@ "cpu": [ "arm64" ], - "libc": [ - "musl" - ], "license": "Apache-2.0", "optional": true, "os": [ @@ -1397,9 +1328,6 @@ "cpu": [ "x64" ], - "libc": [ - "musl" - ], "license": "Apache-2.0", "optional": true, "os": [ @@ -1668,9 +1596,6 @@ "cpu": [ "arm64" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -1687,9 +1612,6 @@ "cpu": [ "arm64" ], - "libc": [ - "musl" - ], "license": "MIT", "optional": true, "os": [ @@ -1706,9 +1628,6 @@ "cpu": [ "ppc64" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -1725,9 +1644,6 @@ "cpu": [ "s390x" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -1744,9 +1660,6 @@ "cpu": [ "x64" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -1763,9 +1676,6 @@ "cpu": [ "x64" ], - "libc": [ - "musl" - ], "license": "MIT", "optional": true, "os": [ @@ -2936,9 +2846,6 @@ "cpu": [ "arm64" ], - "libc": [ - "glibc" - ], "license": "MPL-2.0", "optional": true, "os": [ @@ -2959,9 +2866,6 @@ "cpu": [ "arm64" ], - "libc": [ - "musl" - ], "license": "MPL-2.0", "optional": true, "os": [ @@ -2982,9 +2886,6 @@ "cpu": [ "x64" ], - "libc": [ - "glibc" - ], "license": "MPL-2.0", "optional": true, "os": [ @@ -3005,9 +2906,6 @@ "cpu": [ "x64" ], - "libc": [ - "musl" - ], "license": "MPL-2.0", "optional": true, "os": [ @@ -3823,10 +3721,9 @@ } }, "node_modules/traverse-embedder-web": { - "version": "0.13.0", - "resolved": "https://registry.npmjs.org/traverse-embedder-web/-/traverse-embedder-web-0.13.0.tgz", - "integrity": "sha512-JhwgFxabLzbQEA2rqjB/u3sukwUAoTFUw+JHsged94T8H0WDjmkJQNoesJg2gzioZSYIK/YADfJO5TD2XgKjnQ==", - "license": "Apache-2.0" + "version": "0.14.0", + "resolved": "https://registry.npmjs.org/traverse-embedder-web/-/traverse-embedder-web-0.14.0.tgz", + "integrity": "sha512-GpqQLapHM0xVdAyR2A3OIzDKfsR3Ncfg8wsu42wyiCluhLsRKJ3LqQujt/ffLEiRMc3BUx0Wnv6VmQ96oNwPAw==" }, "node_modules/trim-lines": { "version": "3.0.1", From 7154f14456e19393349f47748a75be5a9102757a Mon Sep 17 00:00:00 2001 From: Enrico Piovesan Date: Tue, 29 Sep 2026 15:04:19 -0600 Subject: [PATCH 3/3] chore(deps): keep site on traverse-embedder-web@0.13.0 0.14.0 ExactModelBrowserHost requires signed schema 2.0.0 pins / host trust roots; discover-generate fixture is not migrated yet. Docs still honestly advertise published packages at 0.14.0. --- package-lock.json | 8 ++++---- package.json | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/package-lock.json b/package-lock.json index 89ce90d..ad657b5 100644 --- a/package-lock.json +++ b/package-lock.json @@ -9,7 +9,7 @@ "version": "0.1.0", "dependencies": { "astro": "7.3.4", - "traverse-embedder-web": "^0.14.0" + "traverse-embedder-web": "^0.13.0" }, "devDependencies": { "@playwright/test": "^1.63.0" @@ -3721,9 +3721,9 @@ } }, "node_modules/traverse-embedder-web": { - "version": "0.14.0", - "resolved": "https://registry.npmjs.org/traverse-embedder-web/-/traverse-embedder-web-0.14.0.tgz", - "integrity": "sha512-GpqQLapHM0xVdAyR2A3OIzDKfsR3Ncfg8wsu42wyiCluhLsRKJ3LqQujt/ffLEiRMc3BUx0Wnv6VmQ96oNwPAw==" + "version": "0.13.0", + "resolved": "https://registry.npmjs.org/traverse-embedder-web/-/traverse-embedder-web-0.13.0.tgz", + "integrity": "sha512-JhwgFxabLzbQEA2rqjB/u3sukwUAoTFUw+JHsged94T8H0WDjmkJQNoesJg2gzioZSYIK/YADfJO5TD2XgKjnQ==" }, "node_modules/trim-lines": { "version": "3.0.1", diff --git a/package.json b/package.json index ad37603..2c7b1dd 100644 --- a/package.json +++ b/package.json @@ -13,7 +13,7 @@ }, "dependencies": { "astro": "7.3.4", - "traverse-embedder-web": "^0.14.0" + "traverse-embedder-web": "^0.13.0" }, "devDependencies": { "@playwright/test": "^1.63.0"