From 278cb6b8d889bdf85bda8d1568162b4b264cc85c Mon Sep 17 00:00:00 2001 From: Enrico Piovesan Date: Wed, 8 Jul 2026 22:24:04 -0600 Subject: [PATCH] fix: remove hero tag clutter, correct core architecture description - Removed the hero-meta badge row (Rust + WASM / MCP protocol / JSON Schema contracts / Apache 2.0) from the homepage. It duplicated "Apache 2.0" from the eyebrow pill directly above it and read as generic filler tags rather than real content. - Corrected the site's core description of how placement actually works. Previous copy framed placement as a fixed target the contract declares and the runtime resolves ahead of time ("the same binary runs in your browser, on an edge node, in a cloud function... without modification"). The real model: capabilities are device-independent and run on the client by default; the client evaluates the contract against its own context and, based on its own heuristics, can delegate a subset of the capability to the server. Updated the homepage meta description, homepage JSON-LD, the "What is Traverse?" question page (both visible body and FAQPage JSON-LD -- this is the page most likely to feed external AI summaries), and the docs concepts page's Placement Targets section. - Added a link to the live GitHub Projects board (github.com/orgs/traverse-framework/projects) from the roadmap page and the footer, so "what we're working on right now" isn't limited to the static roadmap snapshot. Co-Authored-By: Claude Sonnet 5 --- src/components/Footer.astro | 1 + src/pages/docs/concepts.astro | 2 +- src/pages/index.astro | 6 +++--- src/pages/questions/what-is-traverse.astro | 4 ++-- src/pages/roadmap.astro | 2 +- 5 files changed, 8 insertions(+), 7 deletions(-) diff --git a/src/components/Footer.astro b/src/components/Footer.astro index 634b1bd..9e2ac38 100644 --- a/src/components/Footer.astro +++ b/src/components/Footer.astro @@ -40,6 +40,7 @@
  • About
  • Blog
  • GitHub
    • +
  • Project Board
    • diff --git a/src/pages/docs/concepts.astro b/src/pages/docs/concepts.astro index 5bf8851..50468fb 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 before execution, and checks postconditions after. The contract is not documentation. It is enforcement.

    \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  // Execution\n  \"execution\": {\n    \"binary_format\": \"wasm32-wasi\",\n    \"entrypoint\": \"function_name\",\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)\n  \"inputs\": { /* JSON Schema */ },\n  \"outputs\": { /* JSON Schema */ },\n\n  // Events\n  \"events\": {\n    \"emits\": [\"event-id-1\"],\n    \"consumes\": [\"event-id-2\"]\n  }\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-cliregister · list · validate · run
    \n
    traverse-mcpMCP stdio server
    \n
    \n
    \n
    \n\n \n
    \n

    Placement Targets

    \n

    Placement is a deployment decision, not a logic decision. The capability contract declares which environments it supports, which it prefers, and what the fallback is. The runtime resolves placement before execution.

    \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 only fully implemented executor in v0.7.0.
    \n
    \n
    \n
    device
    \n
    On-device execution for edge hardware scenarios.
    \n
    \n
    \n

    Currently, only the local executor is fully implemented. 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  \"contract_validated\": true,\n  \"preconditions_met\": true,\n  \"postconditions_met\": true\n}
    \n
    \n
    \n
    \n\n \n
    \n

    Workflow Composition

    \n

    Workflows compose multiple capabilities into a deterministic execution graph. Each node is a governed capability. Each edge is a typed event. The runtime traverses the graph in order. Same inputs, same path, every time.

    \n

    Workflow definitions declare: the participating capabilities, the events each emits, the input and output shapes, and the terminal conditions. The runtime validates the composition before any execution begins.

    \n
    \n
    workflow definition (excerpt)
    \n
    \n
    {\n  \"id\": \"expedition.planning.plan-expedition\",\n  \"version\": \"1.0.0\",\n  \"graph\": {\n    \"capabilities\": [\n      \"interpret-expedition-intent\",\n      \"capture-expedition-objective\",\n      \"assess-conditions-summary\",\n      \"validate-team-readiness\",\n      \"assemble-expedition-plan\"\n    ]\n  },\n  \"terminal_conditions\": {\n    \"success\": \"expedition-plan-assembled\",\n    \"failure\": \"any-capability-error\"\n  }\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

    9 governing specs are approved as of v0.7.0, covering: foundation, capability contracts, event contracts, spec alignment gate, capability registry, runtime request execution, workflow registry traversal, expedition domain, and expedition artifacts.

    \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 before execution, and checks postconditions after. The contract is not documentation. It is enforcement.

    \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  // Execution\n  \"execution\": {\n    \"binary_format\": \"wasm32-wasi\",\n    \"entrypoint\": \"function_name\",\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)\n  \"inputs\": { /* JSON Schema */ },\n  \"outputs\": { /* JSON Schema */ },\n\n  // Events\n  \"events\": {\n    \"emits\": [\"event-id-1\"],\n    \"consumes\": [\"event-id-2\"]\n  }\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-cliregister · list · validate · run
    \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 only fully implemented executor in v0.7.0.
    \n
    \n
    \n
    device
    \n
    On-device execution for edge hardware scenarios.
    \n
    \n
    \n

    Currently, only the local executor is fully implemented. 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  \"contract_validated\": true,\n  \"preconditions_met\": true,\n  \"postconditions_met\": true\n}
    \n
    \n
    \n
    \n\n \n
    \n

    Workflow Composition

    \n

    Workflows compose multiple capabilities into a deterministic execution graph. Each node is a governed capability. Each edge is a typed event. The runtime traverses the graph in order. Same inputs, same path, every time.

    \n

    Workflow definitions declare: the participating capabilities, the events each emits, the input and output shapes, and the terminal conditions. The runtime validates the composition before any execution begins.

    \n
    \n
    workflow definition (excerpt)
    \n
    \n
    {\n  \"id\": \"expedition.planning.plan-expedition\",\n  \"version\": \"1.0.0\",\n  \"graph\": {\n    \"capabilities\": [\n      \"interpret-expedition-intent\",\n      \"capture-expedition-objective\",\n      \"assess-conditions-summary\",\n      \"validate-team-readiness\",\n      \"assemble-expedition-plan\"\n    ]\n  },\n  \"terminal_conditions\": {\n    \"success\": \"expedition-plan-assembled\",\n    \"failure\": \"any-capability-error\"\n  }\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

    9 governing specs are approved as of v0.7.0, covering: foundation, capability contracts, event contracts, spec alignment gate, capability registry, runtime request execution, workflow registry traversal, expedition domain, and expedition artifacts.

    \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"; --- \n
    \n
    \n
    \n \n v0.7.0 · Apache 2.0 · Open source\n
    \n

    \n Define once.
    Run anywhere.\n

    \n

    \n Traverse is a contract-driven WASM runtime. Write business logic once with a machine-readable contract and run it identically across browser, edge, cloud, and AI pipelines.\n

    \n
    \n Get started →\n Read the docs\n
    \n
    \n \n \n Rust + WASM\n \n \n \n MCP protocol\n \n \n \n JSON Schema contracts\n \n \n \n Apache 2.0\n \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 running in any environment.\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

    Compile to WASM

    \n

    Implement the logic in Rust and compile to wasm32-wasi. The same binary runs on every placement target without recompilation.

    \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

    Cross-platform portability

    \n

    One WASM binary runs on the local target today. The same binary will run unchanged on browser, edge, cloud, and AI pipeline targets as they ship.

    \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

    Governing specs

    \n

    Every contract links to the governing spec document it implements. When the policy changes, you update the spec and bump the contract version. The paper trail is built in.

    \n
    \n
    \n
    \n
    \n\n\n
    \n
    \n
    \n
    By the numbers
    \n

    One runtime. Any environment.

    \n
    \n
    \n
    \n
    1
    \n
    WASM binary runs identically across all placement targets — local, browser, edge, cloud, AI pipeline.
    \n
    \n
    \n
    0
    \n
    Logic rewrites when moving between environments. Same contract, same binary, same behavior everywhere.
    \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 — any deterministic computation that needs to run reliably everywhere.

    \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 in your frontend, your backend, and inside AI agent pipelines with identical results.

    \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 contract-driven Rust and WASM runtime for discovering, validating, and composing portable business capabilities.\",\"url\":\"https://traverse-framework.com\",\"author\":{\"@type\":\"Person\",\"name\":\"Enrico Piovesan\"},\"license\":\"https://www.apache.org/licenses/LICENSE-2.0\",\"applicationCategory\":\"DeveloperApplication\",\"softwareVersion\":\"0.7.0\",\"codeRepository\":\"https://github.com/traverse-framework/traverse\"}"; +const _body = "\n
    \n
    \n
    \n
    \n \n v0.7.0 · Apache 2.0 · Open source\n
    \n

    \n Define once.
    Run anywhere.\n

    \n

    \n Traverse is a contract-driven WASM runtime. Write business logic once with a machine-readable contract and run it identically across browser, edge, cloud, and AI pipelines.\n

    \n
    \n Get started →\n Read the docs\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 running in any environment.\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

    Compile to WASM

    \n

    Implement the logic in Rust and compile to wasm32-wasi. The same binary runs on every placement target without recompilation.

    \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

    Cross-platform portability

    \n

    One WASM binary runs on the local target today. The same binary will run unchanged on browser, edge, cloud, and AI pipeline targets as they ship.

    \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

    Governing specs

    \n

    Every contract links to the governing spec document it implements. When the policy changes, you update the spec and bump the contract version. The paper trail is built in.

    \n
    \n
    \n
    \n
    \n\n\n
    \n
    \n
    \n
    By the numbers
    \n

    One runtime. Any environment.

    \n
    \n
    \n
    \n
    1
    \n
    WASM binary runs identically across all placement targets — local, browser, edge, cloud, AI pipeline.
    \n
    \n
    \n
    0
    \n
    Logic rewrites when moving between environments. Same contract, same binary, same behavior everywhere.
    \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 — any deterministic computation that needs to run reliably everywhere.

    \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 in your frontend, your backend, and inside AI agent pipelines with identical results.

    \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 contract-driven Rust and WASM runtime for device-independent business capabilities. Capabilities run on any client by default; the client can heuristically delegate a subset of execution to the server when it decides to.\",\"url\":\"https://traverse-framework.com\",\"author\":{\"@type\":\"Person\",\"name\":\"Enrico Piovesan\"},\"license\":\"https://www.apache.org/licenses/LICENSE-2.0\",\"applicationCategory\":\"DeveloperApplication\",\"softwareVersion\":\"0.7.0\",\"codeRepository\":\"https://github.com/traverse-framework/traverse\"}"; --- 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.7.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-registry — capability discovery and indexing
      • \n
    • traverse-cli — terminal interface for inspecting and running
      • \n
    • traverse-mcp — Model Context Protocol integration for AI pipelines
      • \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 Rust and WASM runtime. You define business capabilities once as WebAssembly modules governed by machine-readable contracts, and run the same binary across browser, edge, cloud, and AI pipelines. 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.7.0 under the Apache 2.0 license.\"}}]}"; +const _body = "

    Traverse is a contract-driven Rust and WASM runtime for device-independent 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 write the logic once in Rust, compile it to WebAssembly, and attach a machine-readable contract. 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.7.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-registry — capability discovery and indexing
      • \n
    • traverse-cli — terminal interface for inspecting and running
      • \n
    • traverse-mcp — Model Context Protocol integration for AI pipelines
      • \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 Rust and WASM runtime for device-independent 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.7.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. Nothing ships without test coverage.

    \n
    \n\n
    \n\n \n
    \n
    \n ✓\n

    Shipping now

    \n v0.7.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
    9 governing specs
    \n
    Every shipped component has a machine-readable spec. 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.8.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
    Python SDK (experimental)
    \n planned\n
    \n

    Call Traverse capabilities from Python. Useful for data pipelines, ML workflows, and teams that do not write Rust.

    \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
    \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\n
    \n\n \n
    \n
    \n ✓\n

    Shipping now

    \n v0.7.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
    9 governing specs
    \n
    Every shipped component has a machine-readable spec. 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.8.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
    Python SDK (experimental)
    \n planned\n
    \n

    Call Traverse capabilities from Python. Useful for data pipelines, ML workflows, and teams that do not write Rust.

    \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
    \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
    "; ---