From feb46bccca2796a87f4de7c3252ac43e22b5f972 Mon Sep 17 00:00:00 2001 From: Enrico Piovesan Date: Wed, 14 Oct 2026 16:08:57 +0000 Subject: [PATCH] docs(site): v0.15.0 truth-pass (signed models on every host, Core ML opt-in, current pins) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Update current-state copy and the website embedder pin to the published v0.15.0 line: exact-ref on every host, required model_usage, opt-in Core ML, and traverse-registry =0.28.0. Historical v0.12–v0.14 posts stay as written. Co-authored-by: Enrico Piovesan --- package-lock.json | 20 +++-------- package.json | 2 +- public/llms.txt | 36 +++++++++---------- 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 | 4 +-- src/pages/platforms.astro | 10 +++--- ...-run-traverse-capabilities-in-nodejs.astro | 8 ++--- ...e-logic-between-ios-and-android-apps.astro | 6 ++-- ...r-dotnet-embedders-run-exact-ref-yet.astro | 20 +++++------ .../can-traverse-build-mobile-apps.astro | 10 +++--- ...run-models-on-a-gpu-or-neural-engine.astro | 25 +++++++------ ...oes-the-registry-record-model-rights.astro | 6 ++-- ...t-embedder-use-the-same-runtime-wasm.astro | 14 ++++---- ...ite-use-the-latest-traverse-embedder.astro | 10 +++--- .../how-do-hosts-trust-signed-models.astro | 16 ++++----- ...d-traverse-traces-from-inside-my-app.astro | 4 +-- ...it-test-app-code-that-calls-traverse.astro | 6 ++-- ...a-revoked-capability-during-discover.astro | 8 ++--- .../is-production-model-signing-ready.astro | 8 ++--- .../is-traverse-production-ready.astro | 6 ++-- ...gnal-on-an-exact-pin-mean-for-a-host.astro | 14 ++++---- .../what-does-traverse-not-claim-yet.astro | 8 +++-- ...when-a-capability-version-is-revoked.astro | 10 +++--- .../questions/what-is-a-governing-spec.astro | 4 +-- src/pages/questions/what-is-digits-mlp.astro | 6 ++-- .../questions/what-is-exact-model-host.astro | 16 ++++----- .../what-is-exact-ref-model-execution.astro | 34 +++++++++++------- .../what-is-one-shared-runtime-wasm.astro | 10 +++--- ...een-an-exact-pin-and-a-version-range.astro | 10 +++--- src/pages/questions/what-is-traverse.astro | 4 +-- ...ch-hosts-run-signed-exact-ref-models.astro | 29 ++++++++------- src/pages/roadmap.astro | 2 +- src/pages/system.astro | 2 +- src/pages/what-is-real-today.astro | 7 ++-- src/scripts/discover-generate.js | 7 ++-- tests/discover-generate.test.mjs | 1 + 41 files changed, 204 insertions(+), 196 deletions(-) diff --git a/package-lock.json b/package-lock.json index 79e51b6..12131dd 100644 --- a/package-lock.json +++ b/package-lock.json @@ -9,7 +9,7 @@ "version": "0.1.0", "dependencies": { "astro": "7.3.5", - "traverse-embedder-web": "^0.14.0" + "traverse-embedder-web": "^0.15.0" }, "devDependencies": { "@playwright/test": "^1.63.0" @@ -91,9 +91,6 @@ "cpu": [ "arm64" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -110,9 +107,6 @@ "cpu": [ "arm64" ], - "libc": [ - "musl" - ], "license": "MIT", "optional": true, "os": [ @@ -129,9 +123,6 @@ "cpu": [ "x64" ], - "libc": [ - "glibc" - ], "license": "MIT", "optional": true, "os": [ @@ -148,9 +139,6 @@ "cpu": [ "x64" ], - "libc": [ - "musl" - ], "license": "MIT", "optional": true, "os": [ @@ -3750,9 +3738,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.15.0", + "resolved": "https://registry.npmjs.org/traverse-embedder-web/-/traverse-embedder-web-0.15.0.tgz", + "integrity": "sha512-g8GQcAvX9zRcpIuJ20qWF9GPqL6nSPVro0MSZrZVePoy/1RsqtyOQgPwDYhfWyIEYE92Z9Q8IDlz+8yvOB2oAA==", "license": "Apache-2.0" }, "node_modules/trim-lines": { diff --git a/package.json b/package.json index a888cab..e0dcaad 100644 --- a/package.json +++ b/package.json @@ -13,7 +13,7 @@ }, "dependencies": { "astro": "7.3.5", - "traverse-embedder-web": "^0.14.0" + "traverse-embedder-web": "^0.15.0" }, "devDependencies": { "@playwright/test": "^1.63.0" diff --git a/public/llms.txt b/public/llms.txt index 1324f78..9243091 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 (xcframework on `swift-host-v*` releases), Kotlin (Maven Central `com.traverse-framework:traverse-embedder` 0.14.0), and .NET (nuget.org `TraverseEmbedder` 0.14.0) are published, pre-1.0, and not Certified; 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. +> 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**). v0.15.0 headline: governed model execution on every host — signed exact-ref on native Rust, the browser, Swift, Kotlin/Android, and .NET; every host enforces model rights (`model_usage` is required); Core ML is an opt-in Apple placement (macOS cargo-test evidence plus the Decision 113 iPhone spike; governed-path iPhone evidence is traverse#1630, still open). Swift (xcframework `swift-host-v0.15.0`; `Package.swift` on main pins it), Kotlin (Maven Central `com.traverse-framework:traverse-embedder` 0.15.0), and .NET (nuget.org `TraverseEmbedder` 0.15.0) are published, pre-1.0, and not Certified; 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.15.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 Traverse at 0.14.0; npm `traverse-embedder-web@0.14.0`. `traverse-registry` **0.27.0** is published (tag `v0.27.0`; exact pins return lifecycle status). Traverse v0.14.0 still pins `=0.25.0` until the consumer slice on traverse#1598 moves. Runtime refusal of `revoked` is not shipped. +Current packages: crates.io Traverse at 0.15.0; npm `traverse-embedder-web@0.15.0`; Maven Central `com.traverse-framework:traverse-embedder` 0.15.0; nuget.org `TraverseEmbedder` 0.15.0; Swift xcframework `swift-host-v0.15.0`. `traverse-registry` **0.28.0** is published (registry#636; exact pins return lifecycle status, continuing 0.27.0 / registry#632). Traverse v0.15.0 pins `=0.28.0`. Runtime refusal of a revoked registry capability is still traverse#1598, not shipped. Host-side exact-ref `model_usage` enforcement did ship. ## Required reading (agents) @@ -22,7 +22,7 @@ Current packages: crates.io Traverse at 0.14.0; npm `traverse-embedder-web@0.14. - [What is the print-support capability pack?](https://traverse-framework.com/questions/what-is-the-print-support-capability-pack.html): living domain pack (registry#596 · #597–#604 · Discussion #1540); apps-not-ready ≠ no packs; none of the print.* capabilities published yet. Narrative: [Domain packs are in scope: print-support](https://traverse-framework.com/blog/print-support-domain-pack.html). - [What does “the agent proposes; the runtime decides” mean?](https://traverse-framework.com/questions/what-does-agent-proposes-runtime-decides-mean.html): boundary in one page — agents search/plan/suggest; runtime validates, executes or denies, leaves a trace. - [What is one shared runtime.wasm?](https://traverse-framework.com/questions/what-is-one-shared-runtime-wasm.html): embedders are clients; honest consumer list. -- [Does the Rust embedder use the same runtime.wasm?](https://traverse-framework.com/questions/does-the-rust-embedder-use-the-same-runtime-wasm.html): discover → execute → trace on one shared runtime contract/ABI; web `traverse-embedder-web@0.14.0` loads the bundle's digest-checked `runtime/runtime.wasm`; Rust `traverse-embedder@0.14.0` links `traverse-runtime` natively and ships no separate runtime-WASM artifact; capability WASM still targets that host ABI; hosts are clients (UI + I/O); JS/TS + Rust + MCP published; Python via CLI only (no Python SDK); Swift/Kotlin/.NET published pre-1.0, not Certified under Spec 529; published 0.14.0 Maven/NuGet do not include ExactModelHost. Narrative: [One shared runtime. Not one shared .wasm file on every host.](https://traverse-framework.com/blog/one-shared-runtime-two-loading-paths.html). +- [Does the Rust embedder use the same runtime.wasm?](https://traverse-framework.com/questions/does-the-rust-embedder-use-the-same-runtime-wasm.html): discover → execute → trace on one shared runtime contract/ABI; web `traverse-embedder-web@0.15.0` loads the bundle's digest-checked `runtime/runtime.wasm`; Rust `traverse-embedder@0.15.0` links `traverse-runtime` natively and ships no separate runtime-WASM artifact; capability WASM still targets that host ABI; hosts are clients (UI + I/O); JS/TS + Rust + MCP published; Python via CLI only (no Python SDK); Swift/Kotlin/.NET published pre-1.0, not Certified under Spec 529; published 0.15.0 Maven/NuGet include ExactModelHost. Narrative: [One shared runtime. Not one shared .wasm file on every host.](https://traverse-framework.com/blog/one-shared-runtime-two-loading-paths.html) (that post is a v0.14.0 snapshot). - [The agent freestyled a $2.4M wire. The runtime said no.](https://traverse-framework.com/blog/agent-freestyle-blocked.html): project direction in one scene — agent proposes, runtime decides (deny + trace). - [Agent speaks MCP. Exact pin kills the freestyle.](https://traverse-framework.com/blog/agent-mcp-exact-ref.html): v0.14.0 weekly demo — an agent calls MCP-shaped tools (façade over `ExactModelBrowserHost` under Node, not the Mode A `traverse-mcp` binary) against the signed `digits-mlp-1.0.0` package; Browser + Node bit-identical; tamper → `digest_mismatch`, empty trust → `key_untrusted`, rights lie → `rights_mismatch`; test-only key (prod signing #1567). Not catalog `model.execute`. Not Hugging Face. - [Signed model. Exact pin. Bit-identical hosts.](https://traverse-framework.com/blog/signed-exact-ref-digits.html): v0.14.0 weekly demo — signed `digits-mlp-1.0.0` exact-ref package, same bytes on Browser + Node (`ExactModelBrowserHost`); tamper → `digest_mismatch`; test-only key (prod signing #1567). Not catalog `model.execute`. Not Hugging Face. @@ -47,11 +47,11 @@ Current packages: crates.io Traverse at 0.14.0; npm `traverse-embedder-web@0.14. - [How do I author a capability in plain English?](https://traverse-framework.com/questions/how-do-i-author-a-capability-in-plain-english.html): Claude skill `traverse-capability-author` — interview → registry check → contract → WASM → human-reviewed PR; under the hood still Rust→WASM; manual Rust is secondary. - [How do I go from a skill draft to a published capability?](https://traverse-framework.com/questions/how-do-i-go-from-skill-draft-to-published-capability.html): after the skill opens the registry PR — review, CI, human merge, next catalog release; no side-door upload. - [Does capability publish validate model attribution before the registry write?](https://traverse-framework.com/questions/does-capability-publish-validate-model-attribution.html): yes for contract-decidable rules — `traverse-cli capability publish` rejects bad `ai` objects offline before any registry Git write (Decision 109 / Spec 056 v1.1.0 / #1597); keeps `ai` verbatim; evidence digests + rights drift stay registry-CI-only (no CLI network fetch). -- [Does the Traverse registry record model licenses and usage rights?](https://traverse-framework.com/questions/does-the-registry-record-model-rights.html): yes, registry-side (registry spec 026): model-backed contracts declare commercial_use/redistribution/derivatives (`unknown` rejected), LICENSE/NOTICE pinned by sha256, immutable upstream commit, derivation, contract bytes signed; index `usage_class`; signed maintainer declaration, not legal certification; Traverse CLI/runtime enforcement is traverse#1598 (not shipped). -- [What happens when a registry capability version is deprecated or revoked?](https://traverse-framework.com/questions/what-happens-when-a-capability-version-is-revoked.html): nothing is edited or deleted; `deprecated.json` / `revoked.json` siblings; range resolution skips both; exact pins in published `traverse-registry` 0.27.0 still resolve with lifecycle status (registry#632; #631 closed); runtime refusal is traverse#1598, not shipped in v0.14.0. Narrative: [You don't edit a published capability. You mark it.](https://traverse-framework.com/blog/you-dont-edit-a-published-capability.html). -- [What is the difference between an exact capability pin and a version range?](https://traverse-framework.com/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.html): a range resolves to the highest active match and skips deprecated and revoked versions; an exact pin in `traverse-registry` 0.27.0 still resolves with lifecycle status and revocation (spec 005 FR-004, decision 127 Q11, registry#632). Traverse v0.14.0 still pins `=0.25.0`. Runtime refusal is traverse#1598, not shipped. -- [What does a status signal on an exact pin mean for a host?](https://traverse-framework.com/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.html): index `status` (`active` | `deprecated` | `revoked`) is a do-not-run signal the shared `runtime.wasm` is supposed to honor (fail closed). The 0.27.0 crate returns the record and the status; the refusal is not shipped (traverse#1598). Hosts are clients: JS/TS `traverse-embedder-web`, Rust `traverse-embedder`, `traverse-mcp`; Python only via `traverse-cli capability-package execute` (no Python SDK). Swift xcframework on `swift-host-v*` tags; Kotlin Maven Central `com.traverse-framework:traverse-embedder` 0.14.0; .NET nuget.org `TraverseEmbedder` 0.14.0. Published, pre-1.0, not Certified. -- [How should an agent react to a revoked capability during discover?](https://traverse-framework.com/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.html): do not propose it as active. Range resolution in `traverse-registry` 0.27.0 skips revoked versions. Public `catalog.json` keeps the row with `revoked`. `/discover` skips `deprecated` only. No `revoked.json` on registry main (checked 8 October 2026). The agent proposes; the runtime decides — and that refusal is traverse#1598, not shipped in v0.14.0. +- [Does the Traverse registry record model licenses and usage rights?](https://traverse-framework.com/questions/does-the-registry-record-model-rights.html): yes, registry-side (registry spec 026): model-backed contracts declare commercial_use/redistribution/derivatives (`unknown` rejected), LICENSE/NOTICE pinned by sha256, immutable upstream commit, derivation, contract bytes signed; index `usage_class`; signed maintainer declaration, not legal certification; Traverse CLI inspection of that registry record is traverse#1598 (still open). Host-side exact-ref `model_usage` shipped in v0.15.0 and is a different gate. +- [What happens when a registry capability version is deprecated or revoked?](https://traverse-framework.com/questions/what-happens-when-a-capability-version-is-revoked.html): nothing is edited or deleted; `deprecated.json` / `revoked.json` siblings; range resolution skips both; exact pins in published `traverse-registry` 0.28.0 still resolve with lifecycle status (0.27.0 behavior, registry#632; #631 closed; 0.28.0 is registry#636); Traverse v0.15.0 pins `=0.28.0`; runtime refusal of a revoked capability is traverse#1598, not shipped. Narrative: [You don't edit a published capability. You mark it.](https://traverse-framework.com/blog/you-dont-edit-a-published-capability.html). +- [What is the difference between an exact capability pin and a version range?](https://traverse-framework.com/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.html): a range resolves to the highest active match and skips deprecated and revoked versions; an exact pin in `traverse-registry` 0.28.0 still resolves with lifecycle status and revocation (spec 005 FR-004, decision 127 Q11, registry#632). Traverse v0.15.0 pins `=0.28.0`. v0.14.0 pinned `=0.25.0`. Runtime refusal is traverse#1598, not shipped. +- [What does a status signal on an exact pin mean for a host?](https://traverse-framework.com/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.html): index `status` (`active` | `deprecated` | `revoked`) is a do-not-run signal the shared `runtime.wasm` is supposed to honor (fail closed). The 0.28.0 crate returns the record and the status; the refusal is not shipped (traverse#1598). Traverse v0.15.0 pins `=0.28.0`. Hosts are clients: JS/TS `traverse-embedder-web`, Rust `traverse-embedder`, `traverse-mcp`; Python only via `traverse-cli capability-package execute` (no Python SDK). Swift xcframework `swift-host-v0.15.0`; Kotlin Maven Central `com.traverse-framework:traverse-embedder` 0.15.0; .NET nuget.org `TraverseEmbedder` 0.15.0. Published, pre-1.0, not Certified. +- [How should an agent react to a revoked capability during discover?](https://traverse-framework.com/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.html): do not propose it as active. Range resolution in `traverse-registry` 0.28.0 skips revoked versions. Traverse v0.15.0 pins that crate. Public `catalog.json` keeps the row with `revoked`. `/discover` skips `deprecated` only. No `revoked.json` on registry main (checked 8 October 2026; not rechecked for this pass). The agent proposes; the runtime decides — and that refusal is traverse#1598, not shipped in v0.15.0. - [What does human review mean for a capability PR?](https://traverse-framework.com/questions/what-does-human-review-mean-for-a-capability-pr.html): a person still merges; skill drafts only; check rule fit, CI, digests, catalog fit. - [How do I verify a signed capability artifact?](https://traverse-framework.com/questions/how-do-i-verify-a-signed-capability-artifact.html): SHA-256 digest = integrity; Ed25519 signature.json = registry attestation; pin by digest, never a naked URL. - [How do I review a capability PR as a maintainer?](https://traverse-framework.com/questions/how-do-i-review-a-capability-pr-as-a-maintainer.html): contract fit, green CI (digest/coverage/authoring/licensing), fork artifact mirror before merge; signing automatic after merge; no side door. @@ -61,12 +61,12 @@ Current packages: crates.io Traverse at 0.14.0; npm `traverse-embedder-web@0.14. ## Where it runs -- [Platforms](https://traverse-framework.com/platforms.html): honest, evidence-linked status per target — native and browser are shipped; Swift/iOS (wasmi xcframework on `swift-host-v*` releases), Kotlin/Android (Maven Central `com.traverse-framework:traverse-embedder` 0.14.0), and .NET/Windows (nuget.org `TraverseEmbedder` 0.14.0) embedders are published but pre-1.0 and marked In progress; no host is Certified under Spec 529 yet; edge is planned; cloud placement is an explicit non-goal for v0.1. Do not assume a target works without checking this page first. +- [Platforms](https://traverse-framework.com/platforms.html): honest, evidence-linked status per target — native and browser are shipped; Swift/iOS (wasmi xcframework `swift-host-v0.15.0`), Kotlin/Android (Maven Central `com.traverse-framework:traverse-embedder` 0.15.0), and .NET/Windows (nuget.org `TraverseEmbedder` 0.15.0) embedders are published but pre-1.0 and marked In progress; all three include ExactModelHost; no host is Certified under Spec 529 yet; Core ML is an Apple opt-in; edge is planned; cloud placement is an explicit non-goal for v0.1. Do not assume a target works without checking this page first. - [React integration guide](https://traverse-framework.com/docs/guides/react-integration.html): using the published Web embedder SDK (`traverse-embedder-web`) from a React app. - [What happens when a capability runs out of fuel or memory?](https://traverse-framework.com/questions/what-happens-when-a-capability-runs-out-of-fuel-or-memory.html): the call fails, it doesn't run unbounded; limits are host-owned and per call (Swift status -4 `bridge_timeout` / `bridge_resource_limit`, -5 `bridge_trap`; .NET defaults 32 MiB, 10M fuel, 30 s; Kotlin 32 MiB artifact cap + per-call budget); behavior differs by engine, test each host. -- [Can I run Traverse capabilities in Node.js?](https://traverse-framework.com/questions/can-i-run-traverse-capabilities-in-nodejs.html): yes, via the same npm `traverse-embedder-web@0.14.0` with `NodeFsBundleLoader`; loads the bundle's own digest-checked `runtime/runtime.wasm` (one shared runtime, Node is a host, not a separate runtime); linear `direct` pipelines only; `platform: "web"`, placement reports `browser`; no separate Node row on Platforms, nothing Certified; Python stays CLI-only (no Python SDK). -- [How do I unit-test app code that calls Traverse without running WASM?](https://traverse-framework.com/questions/how-do-i-unit-test-app-code-that-calls-traverse.html): `EmbedderTestDouble` in `traverse-embedder-web` and Rust `traverse-embedder` 0.14.0 (scripted output/error per target, same event envelope, deterministic ids, `target_not_found` / `runtime_stopped`, trace list/get); Swift/Kotlin/.NET ship smaller `InMemoryTraverseEmbedder`; doubles test host code, not the capability; `releaseEvidence().package.version` says 0.9.0 in 0.14.0 (#1654). -- [How do I read Traverse execution traces from inside my app?](https://traverse-framework.com/questions/how-do-i-read-traverse-traces-from-inside-my-app.html): Embedded Trace API (`embedded-trace-api/1.0.0`, Spec 517) — `traceList` / `traceGet` on web + Rust embedders 0.14.0; safe projection (target, outcome, phases, placement, failure code), never inputs/outputs/caller identity/private hashes; process-local, last 100, cleared on shutdown; no HTTP sidecar; `completedAt` is logical time; not on Swift/Kotlin/.NET yet. +- [Can I run Traverse capabilities in Node.js?](https://traverse-framework.com/questions/can-i-run-traverse-capabilities-in-nodejs.html): yes, via the same npm `traverse-embedder-web@0.15.0` with `NodeFsBundleLoader`; loads the bundle's own digest-checked `runtime/runtime.wasm` (one shared runtime, Node is a host, not a separate runtime); linear `direct` pipelines only; `platform: "web"`, placement reports `browser`; no separate Node row on Platforms, nothing Certified; Python stays CLI-only (no Python SDK). The documented Node 20 run was against 0.14.0. +- [How do I unit-test app code that calls Traverse without running WASM?](https://traverse-framework.com/questions/how-do-i-unit-test-app-code-that-calls-traverse.html): `EmbedderTestDouble` in `traverse-embedder-web` and Rust `traverse-embedder` 0.15.0 (scripted output/error per target, same event envelope, deterministic ids, `target_not_found` / `runtime_stopped`, trace list/get); Swift/Kotlin/.NET ship smaller `InMemoryTraverseEmbedder`; doubles test host code, not the capability; `releaseEvidence().package.version` reported 0.9.0 in 0.14.0 and reports 0.15.0 in the published 0.15.0 package (#1654 closed). +- [How do I read Traverse execution traces from inside my app?](https://traverse-framework.com/questions/how-do-i-read-traverse-traces-from-inside-my-app.html): Embedded Trace API (`embedded-trace-api/1.0.0`, Spec 517) — `traceList` / `traceGet` on web + Rust embedders 0.15.0; safe projection (target, outcome, phases, placement, failure code), never inputs/outputs/caller identity/private hashes; process-local, last 100, cleared on shutdown; no HTTP sidecar; `completedAt` is logical time; not on Swift/Kotlin/.NET yet. - [Architecture](https://traverse-framework.com/docs/architecture.html): how the runtime, registry, and WASM sandbox fit together. ## Project status @@ -75,13 +75,13 @@ Current packages: crates.io Traverse at 0.14.0; npm `traverse-embedder-web@0.14. - [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): discover → execute → trace; one shared `runtime.wasm`; signed schema `2.0.0` + `model.sig.json`; host-owned trust; `digits-mlp-1.0.0` (test-only key; prod signing #1567); published exact-ref execute is native + web + Swift ExactModelHost (`swift-host-v0.14.0-4` / #1579); Kotlin and .NET ExactModelHost are on main (#1580, #1602 closed) and are not in Maven/NuGet 0.14.0 (next cuts #1651; first landed in v0.12.0). Embedder notes: [v0.14.0: what changed for embedders](https://traverse-framework.com/blog/traverse-0-14-0-what-changed-for-embedders.html) · [Release](https://github.com/traverse-framework/traverse/releases/tag/v0.14.0) · [Announcement #1576](https://github.com/orgs/traverse-framework/discussions/1576). -- [How do hosts trust signed models?](https://traverse-framework.com/questions/how-do-hosts-trust-signed-models.html): discover → execute → trace; one shared `runtime.wasm`; host-owned trust roots gate `register_package`; pin by digest + `model.sig.json`; test-only digits-mlp key; published exact-ref execute is native+web+Swift ExactModelHost (`swift-host-v0.14.0-4`); Kotlin and .NET ExactModelHost are on main, not in the published 0.14.0 packages (#1651) — no claimed ONNX generic runner. -- [Which hosts run signed exact-ref models?](https://traverse-framework.com/questions/which-hosts-run-signed-exact-ref-models.html) · [Is production model signing ready?](https://traverse-framework.com/questions/is-production-model-signing-ready.html) · [Can Kotlin or .NET run exact-ref yet?](https://traverse-framework.com/questions/can-kotlin-or-dotnet-embedders-run-exact-ref-yet.html): discover → execute → trace; one shared `runtime.wasm`; published exact-ref is native + web 0.14.0 + Swift `swift-host-v0.14.0-4`; Kotlin and .NET ExactModelHost are on main (#1580, #1602 closed) and not in Maven/NuGet 0.14.0 (#1651); test-only key ≠ prod (#1567). -- [What is ExactModelHost?](https://traverse-framework.com/questions/what-is-exact-model-host.html): host-side connector for governed exact-ref model packages (Spec 138). Register a signed package under host-owned trust roots, then execute under discover → execute → trace. Not a second runtime. Published: native connector + web `ExactModelBrowserHost` in 0.14.0 + Swift `ExactModelHost` on `swift-host-v0.14.0-4`. Kotlin/.NET ExactModelHost code is on main, not in Maven/NuGet 0.14.0 (#1651). Test-only digits-mlp key; prod signing #1567. Not catalog `model.execute`. Not Hugging Face. -- [Can Traverse run models on a GPU or the Apple Neural Engine?](https://traverse-framework.com/questions/can-traverse-run-models-on-a-gpu-or-neural-engine.html): not in a published release; v0.14.0 exact-ref models run on `wasm-cpu` in the one shared runtime. Unreleased on main (Decision 112, traverse#1667): host policy lists ordered placements (default `wasm-cpu`), on-device self-check against the variant's conformance vector, memory ceiling, fail-closed `placement_unavailable`, placement evidence in every result. No real accelerator adapter yet: Core ML conversion spike #1663, iPhone evidence #1630; no web/Android/desktop GPU adapter. +- [What is exact-ref model execution?](https://traverse-framework.com/questions/what-is-exact-ref-model-execution.html): discover → execute → trace; one shared `runtime.wasm`; signed schema `2.0.0` and later + `model.sig.json`; host-owned trust; **breaking** `model_usage` (`commercial` | `non_commercial`, else `usage_undeclared`); third-party ONNX via `traverse-cli model`; guest ABI v3 snapshot reuse; Core ML opt-in on Apple (macOS cargo test + Decision 113 spike; governed-path iPhone evidence traverse#1630 still open); `digits-mlp-1.0.0` (test-only key; custody #1567 still open); published exact-ref execute is native + web 0.15.0 + Swift ExactModelHost (`swift-host-v0.15.0`) + Kotlin and .NET ExactModelHost in Maven/NuGet 0.15.0 (#1651 closed; first landed in v0.12.0). No host is Certified. [Release](https://github.com/traverse-framework/traverse/releases/tag/v0.15.0) · historical embedder notes: [v0.14.0: what changed for embedders](https://traverse-framework.com/blog/traverse-0-14-0-what-changed-for-embedders.html). +- [How do hosts trust signed models?](https://traverse-framework.com/questions/how-do-hosts-trust-signed-models.html): discover → execute → trace; one shared `runtime.wasm`; host-owned trust roots gate `register_package`; pin by digest + `model.sig.json`; `model_usage` required in v0.15.0; test-only digits-mlp key (custody #1567 still open); published exact-ref execute is native + web + Swift `swift-host-v0.15.0` + Kotlin and .NET 0.15.0; third-party ONNX can be packaged and signed with `traverse-cli model`. +- [Which hosts run signed exact-ref models?](https://traverse-framework.com/questions/which-hosts-run-signed-exact-ref-models.html) · [Is production model signing ready?](https://traverse-framework.com/questions/is-production-model-signing-ready.html) · [Can Kotlin or .NET run exact-ref yet?](https://traverse-framework.com/questions/can-kotlin-or-dotnet-embedders-run-exact-ref-yet.html): discover → execute → trace; one shared `runtime.wasm`; published exact-ref is native + web 0.15.0 + Swift `swift-host-v0.15.0` + Kotlin and .NET 0.15.0 (#1651 closed); production signing custody is not finished (#1567 still open; v0.15.0 shipped key-generation tooling). +- [What is ExactModelHost?](https://traverse-framework.com/questions/what-is-exact-model-host.html): host-side connector for governed exact-ref model packages (Spec 138). Register a signed package under host-owned trust roots, then execute under discover → execute → trace. Not a second runtime. Published in 0.15.0: native connector, web `ExactModelBrowserHost`, Swift `ExactModelHost` on `swift-host-v0.15.0`, Kotlin and .NET `ExactModelHost` in Maven/NuGet 0.15.0 (#1651 closed). Test-only digits-mlp key; custody #1567 still open. Not catalog `model.execute`. Not Hugging Face. +- [Can Traverse run models on a GPU or the Apple Neural Engine?](https://traverse-framework.com/questions/can-traverse-run-models-on-a-gpu-or-neural-engine.html): Core ML is an opt-in Apple placement in v0.15.0. Default stays `wasm-cpu`. Ordered placements, on-device self-check, fail-closed `placement_unavailable`, placement evidence (Decision 112). Evidence so far is macOS cargo test plus the Decision 113 iPhone spike. Governed-path iPhone evidence is traverse#1630, still open. No web, Android, or desktop GPU adapter. No host is Certified. - [What is digits-mlp?](https://traverse-framework.com/questions/what-is-digits-mlp.html): first trained exact-ref package in v0.14.0 (UCI digits MLP, 96.10% held-out, bit-identical); test-only signing; not a general LLM. -- [Does the website use the latest traverse-embedder-web?](https://traverse-framework.com/questions/does-the-website-use-the-latest-traverse-embedder.html): site pins `^0.14.0` (matching npm) and `/discover` admits its signed demo fixture through `registerPackage`; the site can lag future releases, so product apps pin published packages, not the website demo. +- [Does the website use the latest traverse-embedder-web?](https://traverse-framework.com/questions/does-the-website-use-the-latest-traverse-embedder.html): site pins `^0.15.0` (matching npm) and `/discover` admits its signed demo fixture through `registerPackage` with `modelUsage: non_commercial`; the site can lag future releases, so product apps pin published packages, not the website demo. - [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 fb6ba54..4e55d53 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.14.0 + v0.15.0 Apache 2.0
diff --git a/src/pages/about.astro b/src/pages/about.astro index 40fdacf..56012c9 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.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
"; +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.15.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 →

-

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). Discover → execute → trace, on one shared runtime.wasm. Published exact-ref execute is native Rust and the web embedder in this cut, plus Swift ExactModelHost on xcframework swift-host-v0.14.0-4 (Package.swift pin; first on swift-host-v0.14.0-1, #1579 closed 2026-09-30). Kotlin ExactModelHost is on main (#1580) and is not in Maven Central 0.14.0. .NET ExactModelHost is on main (#1602) and is not in nuget.org TraverseEmbedder 0.14.0. Next package cuts: #1651. Pin the Traverse crates and npm at 0.14.0. That release pins traverse-registry at =0.25.0; crates.io has since published traverse-registry 0.27.0. Product Release: Traverse v0.14.0.

+

Governed model execution on every host

v0.15.0 is a minor lockstep crate + npm release with breaking Spec 138 exact-ref changes (this repo's 0.x convention uses a minor bump). Signed exact-ref packages now run on the Swift, Kotlin/Android, and .NET embedders, in addition to native Rust and the browser. Every host enforces model rights. Discover → execute → trace, on one shared runtime.wasm. No host is Certified under Spec 529.

  • ExactModelHost is published: Swift on the swift-host-v0.15.0 xcframework (Package.swift on main pins that asset, #1675; the v0.15.0 tag itself still pointed at swift-host-v0.14.0-4). Kotlin com.traverse-framework:traverse-embedder 0.15.0 on Maven Central and .NET TraverseEmbedder 0.15.0 on nuget.org include ExactModelHost (#1651, closed).
  • Breaking model_usage: an app with exact_model_dependencies must declare model_usage as commercial or non_commercial. Without it, calls fail closed with usage_undeclared.
  • Third-party ONNX: traverse-cli model can digest, sign, verify, pin, and package an ONNX model onto an audited guest.
  • Repeat inference: guest ABI v3 snapshot reuse makes a later call restore a prepared snapshot. The release describes that as faster repeat inference.
  • Core ML is opt-in on Apple hosts: a package's signed Core ML variant runs under the same policy, tolerance, and evidence rules. The default placement stays wasm-cpu. Evidence so far is macOS cargo test plus the Decision 113 iPhone spike. Governed-path iPhone evidence is still open (traverse#1630). There is no web, Android, or desktop GPU adapter.

Pins: crates.io, npm, Maven Central, and nuget.org at 0.15.0. This release pins traverse-registry at =0.28.0 (registry#636). digits-mlp-1.0.0 remains a test-only key; production custody, rotation, and revocation are still #1567. The web embedder reports its real package version (#1654).

Product Release: Traverse v0.15.0 · Release notes · Upgrade guide.

+

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). Discover → execute → trace, on one shared runtime.wasm. Published exact-ref execute is native Rust and the web embedder in this cut, plus Swift ExactModelHost on xcframework swift-host-v0.14.0-4 (Package.swift pin; first on swift-host-v0.14.0-1, #1579 closed 2026-09-30). Kotlin ExactModelHost is on main (#1580) and is not in Maven Central 0.14.0. .NET ExactModelHost is on main (#1602) and is not in nuget.org TraverseEmbedder 0.14.0. Next package cuts: #1651. Pin the Traverse crates and npm at 0.14.0. That release pins traverse-registry at =0.25.0; crates.io has since published traverse-registry 0.27.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 →
diff --git a/src/pages/docs/concepts.astro b/src/pages/docs/concepts.astro index 2673fd2..502b12f 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.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"; +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.15.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.15.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.14.0 and Rust 1.94 or later.

+

Build the current runtime and inspect a governed bundle. This path works with Traverse v0.15.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 f4350dc..5161619 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.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, and .NET embedders are published and pre-1.0 (Swift xcframework on swift-host-v* tags, Kotlin com.traverse-framework:traverse-embedder 0.14.0 on Maven Central, .NET TraverseEmbedder 0.14.0 on nuget.org). They are marked In progress, and no host is Certified. 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 published, pre-1.0, and marked In progress. No host is Certified under Spec 529. 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.15.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, and .NET embedders are published and pre-1.0 (Swift xcframework on swift-host-v* tags, Kotlin com.traverse-framework:traverse-embedder 0.15.0 on Maven Central, .NET TraverseEmbedder 0.15.0 on nuget.org). They are marked In progress, and no host is Certified. 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 published, pre-1.0, and marked In progress. No host is Certified under Spec 529. 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.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 shipped clients. Swift, Kotlin, and .NET packages are published, pre-1.0, and not Certified. 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, and .NET packages are published, pre-1.0, and not Certified. 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.14.0\",\"codeRepository\":\"https://github.com/traverse-framework/traverse\"}";
+const _body = "\n
\n  
\n  
\n    
\n      \n      v0.15.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 shipped clients. Swift, Kotlin, and .NET packages are published, pre-1.0, and not Certified. 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, and .NET packages are published, pre-1.0, and not Certified. 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.15.0\",\"codeRepository\":\"https://github.com/traverse-framework/traverse\"}";
 ---
 
           
Native — Linux, macOS, Windows

           Shipped
-

The default target and the most mature. traverse-runtime gives you full orchestration — NativeExecutor, ThreadPoolExecutor, and a Wasmtime-backed WasmExecutor for sandboxed capability execution. This is what traverse-cli runs on, and what every quickstart walks you through. Signed exact-ref execute (ExactModelHostConnector) shipped in the v0.14.0 crates. Capabilities still discover → execute → trace on one shared runtime.wasm.

+

The default target and the most mature. traverse-runtime gives you full orchestration — NativeExecutor, ThreadPoolExecutor, and a Wasmtime-backed WasmExecutor for sandboxed capability execution. This is what traverse-cli runs on, and what every quickstart walks you through. Signed exact-ref execute (ExactModelHostConnector) ships in the v0.15.0 crates, and the host enforces model_usage. Capabilities still discover → execute → trace on one shared runtime.wasm.

Quickstart → Runtime target matrix → @@ -39,7 +39,7 @@ const _body = `
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.14.0 is published to npm (aligned with the v0.14.0 cut) and executes signed exact-ref (ExactModelBrowserHost). 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.15.0 is published to npm (aligned with the v0.15.0 cut) and executes signed exact-ref (ExactModelBrowserHost, with modelUsage required when pins exist). 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) → @@ -63,7 +63,7 @@ const _body = `

Swift / iOS

In progress
-

The engine blocker recorded here as of July 19, 2026 is resolved. The wasmi feasibility spike below was adopted the next day: ADR-0014 selected the wasmi Apple runtime profile, ADR-0015 governed a production Swift wasmi C ABI, and Spec 074 (Approved) now defines the resource-control certification conditions. packages/swift/TraverseEmbedder ships a production WasmiHostBridgeClient backed by TraverseSwiftHost — a released XCFramework wrapping the wasmi interpreter behind a narrow C ABI — that enforces host-owned artifact-size, memory, fuel-per-invocation, and I/O limits on every call. The earlier WasmKit path, which never exposed those controls, has been removed from the package entirely (Decision 96, #1469); WasmKit is not supported. The xcframework ships as versioned swift-host-v* GitHub release assets (currently swift-host-v0.14.0-4), and Package.swift pins its checksum. That same published xcframework includes ExactModelHost for signed exact-ref execute (GitHub Release + SPM binary target).

+

The engine blocker recorded here as of July 19, 2026 is resolved. The wasmi feasibility spike below was adopted the next day: ADR-0014 selected the wasmi Apple runtime profile, ADR-0015 governed a production Swift wasmi C ABI, and Spec 074 (Approved) now defines the resource-control certification conditions. packages/swift/TraverseEmbedder ships a production WasmiHostBridgeClient backed by TraverseSwiftHost — a released XCFramework wrapping the wasmi interpreter behind a narrow C ABI — that enforces host-owned artifact-size, memory, fuel-per-invocation, and I/O limits on every call. The earlier WasmKit path, which never exposed those controls, has been removed from the package entirely (Decision 96, #1469); WasmKit is not supported. The xcframework ships as versioned swift-host-v* GitHub release assets. The current asset is swift-host-v0.15.0, and Package.swift on main pins that zip (#1675). The v0.15.0 tag's Package.swift still pointed at swift-host-v0.14.0-4. That published xcframework includes ExactModelHost for signed exact-ref execute (GitHub Release + SPM binary target). Apple hosts can opt in to a package's signed Core ML variant under the same policy, tolerance, and evidence rules; the default placement stays wasm-cpu. Evidence so far is macOS cargo test plus the Decision 113 iPhone spike. Governed-path iPhone evidence is still open (traverse#1630).

The iOS and macOS clients in reference-apps run embedded: in-process TraverseEmbedder loading a digest-pinned runtime.wasm, with no traverse-cli serve sidecar. What's still open: Spec 529 (approved September 13, 2026) defines one host-neutral Certified/Preview classification across Web, Linux/Rust, Apple, Android, and Windows/.NET, but the five-platform conformance runner it calls for is later work, so no host is Certified today. Treat this as real, resource-bounded, pre-1.0 execution, not a certified release.

Read the wasmi feasibility write-up → @@ -78,7 +78,7 @@ const _body = `

Kotlin / Android

In progress
-

packages/kotlin/TraverseEmbedder has a working ChicoryRuntimeBridge pinned to Chicory 1.7.5. Bundle validation, lifecycle types, and the no-sidecar Compose reference-app integration have all landed — and the package is published on Maven Central as com.traverse-framework:traverse-embedder (0.14.0, lockstep with the core release). Like every host, it's pre-1.0 and not Certified under Spec 529 yet. That published 0.14.0 AAR does not include signed exact-ref execute. ExactModelHost is on traverse main (#1580, closed) and reaches Maven Central only with the next package cut (#1651).

+

packages/kotlin/TraverseEmbedder has a working ChicoryRuntimeBridge pinned to Chicory 1.7.5. Bundle validation, lifecycle types, and the no-sidecar Compose reference-app integration have all landed — and the package is published on Maven Central as com.traverse-framework:traverse-embedder (0.15.0, lockstep with the core release; checked 2026-10-14). Like every host, it's pre-1.0 and not Certified under Spec 529 yet. The 0.15.0 AAR includes ExactModelHost for signed exact-ref execute (#1580, #1651 closed). The 0.14.0 AAR did not.

Kotlin embedder README →
@@ -89,7 +89,7 @@ const _body = `

.NET / WinUI

In progress -

packages/dotnet/TraverseEmbedder has a working WasmtimeRuntimeBridge pinned to Wasmtime .NET 44.0.0. Request marshalling, event subscriptions, evidence publication, the shared conformance suite, and the no-sidecar WinUI reference-app integration have all landed — and the package is published on nuget.org as TraverseEmbedder (0.14.0, lockstep with the core release). Like every host, it's pre-1.0 and not Certified under Spec 529 yet. That published 0.14.0 package does not include signed exact-ref execute. ExactModelHost is on traverse main (#1602, closed) and reaches nuget.org only with the next package cut (#1651).

+

packages/dotnet/TraverseEmbedder has a working WasmtimeRuntimeBridge pinned to Wasmtime .NET 44.0.0. Request marshalling, event subscriptions, evidence publication, the shared conformance suite, and the no-sidecar WinUI reference-app integration have all landed — and the package is published on nuget.org as TraverseEmbedder (0.15.0, lockstep with the core release; checked 2026-10-14). Like every host, it's pre-1.0 and not Certified under Spec 529 yet. The 0.15.0 package includes ExactModelHost for signed exact-ref execute (#1602, #1651 closed). The 0.14.0 package did not. The NuGet package ships the native engine for win-x64, win-arm64, and linux-x64.

.NET embedder README →
diff --git a/src/pages/questions/can-i-run-traverse-capabilities-in-nodejs.astro b/src/pages/questions/can-i-run-traverse-capabilities-in-nodejs.astro index 0e371b6..1bbdc1c 100644 --- a/src/pages/questions/can-i-run-traverse-capabilities-in-nodejs.astro +++ b/src/pages/questions/can-i-run-traverse-capabilities-in-nodejs.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'Can I run Traverse capabilities in Node.js?', acceptedAnswer: { '@type': 'Answer', - text: 'Yes, through the same npm package the browser uses. traverse-embedder-web@0.14.0 exports NodeFsBundleLoader, which reads your application bundle from disk instead of fetching it. The embedder loads the bundle\'s own runtime/runtime.wasm, checks its sha256 digest, and runs each capability through it, so a Node process discovers, executes, and traces against the same runtime.wasm a browser tab loads. Node is a host, not a separate Traverse runtime. Workflows are limited to linear direct-triggered pipelines today, and Node is not listed as its own target on the Platforms page.', + text: 'Yes, through the same npm package the browser uses. traverse-embedder-web@0.15.0 exports NodeFsBundleLoader, which reads your application bundle from disk instead of fetching it. The embedder loads the bundle\'s own runtime/runtime.wasm, checks its sha256 digest, and runs each capability through it, so a Node process discovers, executes, and traces against the same runtime.wasm a browser tab loads. Node is a host, not a separate Traverse runtime. Workflows are limited to linear direct-triggered pipelines today, and Node is not listed as its own target on the Platforms page.', }, }], }); @@ -47,11 +47,11 @@ const relatedLinks = [ >

Yes. There's no separate Node package. You use traverse-embedder-web, the same npm package a browser app uses, and give it a different bundle loader.

-

In the browser, FetchBundleLoader pulls the app bundle over HTTP. In Node, NodeFsBundleLoader reads the same files from disk. Both are exported from the published 0.14.0 package. Everything after loading is the same: the embedder loads the bundle's runtime/runtime.wasm, checks it against runtime/runtime.wasm.sha256, and runs your capabilities through it. So a Node script discovers, executes, and traces against the same runtime.wasm a browser tab would. Node is just another host.

+

In the browser, FetchBundleLoader pulls the app bundle over HTTP. In Node, NodeFsBundleLoader reads the same files from disk. Both are exported from the published 0.15.0 package. Everything after loading is the same: the embedder loads the bundle's runtime/runtime.wasm, checks it against runtime/runtime.wasm.sha256, and runs your capabilities through it. So a Node script discovers, executes, and traces against the same runtime.wasm a browser tab would. Node is just another host.

{nodeExample}
-

We ran this on Node 20 with traverse-embedder-web@0.14.0 from npm and the traverse-starter bundle checked into the traverse repo. The submit came back accepted, the subscriber saw capability_invoked then capability_result, and traceList returned one completed trace for traverse-starter.process. No traverse-cli serve sidecar was running.

+

We ran this shape on Node 20 with traverse-embedder-web@0.14.0 from npm and the traverse-starter bundle checked into the traverse repo. The submit came back accepted, the subscriber saw capability_invoked then capability_result, and traceList returned one completed trace for traverse-starter.process. No traverse-cli serve sidecar was running. The published package is now 0.15.0 and still exports NodeFsBundleLoader. That Node 20 run was not repeated against 0.15.0 for this page.

Where this is useful

    @@ -70,5 +70,5 @@ const relatedLinks = [
  • Python isn't covered by this. There's no Python SDK. From Python, shell out to traverse-cli capability-package execute.
-

If you need a Rust process instead, the Rust embedder is traverse-embedder@0.14.0 on crates.io. For agents, use traverse-mcp. All of them are clients of the same capability contracts. Nobody reimplements the rule.

+

If you need a Rust process instead, the Rust embedder is traverse-embedder@0.15.0 on crates.io. For agents, use traverse-mcp. All of them are clients of the same capability contracts. Nobody reimplements the rule.

diff --git a/src/pages/questions/can-i-share-logic-between-ios-and-android-apps.astro b/src/pages/questions/can-i-share-logic-between-ios-and-android-apps.astro index 883cbbb..9a0b018 100644 --- a/src/pages/questions/can-i-share-logic-between-ios-and-android-apps.astro +++ b/src/pages/questions/can-i-share-logic-between-ios-and-android-apps.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'Can I share business logic between an iOS app and an Android app with Traverse?', acceptedAnswer: { '@type': 'Answer', - text: 'Yes at the package level, with pre-1.0 caveats. The same capability and contract run through the Swift embedder (a wasmi-based host distributed as an XCFramework) on iOS and the Kotlin embedder (Chicory, published on Maven Central at 0.14.0) on Android, and both have reference clients. Neither is Certified under Spec 529 yet, and both are still marked In progress on the Platforms page.', + text: 'Yes at the package level, with pre-1.0 caveats. The same capability and contract run through the Swift embedder (a wasmi-based host distributed as an XCFramework) on iOS and the Kotlin embedder (Chicory, published on Maven Central at 0.15.0) on Android, and both have reference clients. Neither is Certified under Spec 529 yet, and both are still marked In progress on the Platforms page.', }, }], }); @@ -23,7 +23,7 @@ const relatedLinks = [ --- On iOS, packages/swift/TraverseEmbedder now ships a production runtime bridge: WasmiHostBridgeClient embeds the wasmi interpreter behind a narrow C ABI, packaged as the TraverseSwiftHost XCFramework, with host-enforced memory and fuel limits. Its resource controls follow Spec 074, governed by ADR-0014 and ADR-0015. The earlier WasmKit-based bridge has been removed from the package; WasmKit is not supported.

-

On Android, packages/kotlin/TraverseEmbedder has a working runtime bridge built on Chicory, published on Maven Central as com.traverse-framework:traverse-embedder (0.14.0). The iOS and Android clients in reference-apps run the runtime in-process, with no sidecar server.

+

On Android, packages/kotlin/TraverseEmbedder has a working runtime bridge built on Chicory, published on Maven Central as com.traverse-framework:traverse-embedder (0.15.0). The iOS and Android clients in reference-apps run the runtime in-process, with no sidecar server.

What's not done: both hosts are pre-1.0, and Spec 529's host-neutral Certified/Preview classification needs a five-platform conformance runner that's later work, so no host is Certified today.

diff --git a/src/pages/questions/can-kotlin-or-dotnet-embedders-run-exact-ref-yet.astro b/src/pages/questions/can-kotlin-or-dotnet-embedders-run-exact-ref-yet.astro index 206247d..4fd267b 100644 --- a/src/pages/questions/can-kotlin-or-dotnet-embedders-run-exact-ref-yet.astro +++ b/src/pages/questions/can-kotlin-or-dotnet-embedders-run-exact-ref-yet.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'Can Kotlin or .NET embedders run exact-ref models in Traverse yet?', acceptedAnswer: { '@type': 'Answer', - text: 'Discover → execute → trace. One shared runtime.wasm. Not from the published 0.14.0 packages. Kotlin ExactModelHost is on traverse main (#1580 closed) but Maven Central com.traverse-framework:traverse-embedder is still 0.14.0. .NET ExactModelHost is on traverse main (#1602 closed) but nuget.org TraverseEmbedder is still 0.14.0. Next package cuts: #1651. Published exact-ref execute is native Rust (v0.14.0), traverse-embedder-web@0.14.0, and Swift ExactModelHost on swift-host-v0.14.0-4.', + text: 'Yes, as of Traverse v0.15.0. Discover → execute → trace. One shared runtime.wasm. Maven Central com.traverse-framework:traverse-embedder 0.15.0 and nuget.org TraverseEmbedder 0.15.0 both include ExactModelHost. Those cuts closed #1651. The 0.14.0 packages did not. Swift ExactModelHost is on the swift-host-v0.15.0 xcframework. Native Rust and traverse-embedder-web@0.15.0 also execute. Every host enforces model_usage. No host is Certified under Spec 529.', }, }], }); @@ -18,31 +18,31 @@ const relatedLinks = [ { href: '/questions/which-hosts-run-signed-exact-ref-models.html', label: 'Which hosts run signed exact-ref models?' }, { href: '/questions/what-is-exact-ref-model-execution.html', label: 'What is exact-ref model execution?' }, { href: '/questions/how-do-hosts-trust-signed-models.html', label: 'How do hosts trust signed models?' }, - { href: '/blog/traverse-0-14-0-what-changed-for-embedders.html', label: 'v0.14.0: what changed for embedders' }, + { href: '/blog/traverse-0-14-0-what-changed-for-embedders.html', label: 'v0.14.0: what changed for embedders (historical)' }, { href: '/platforms.html', label: 'Platforms' }, { href: '/what-is-real-today.html', label: 'What is real today' }, ]; --- -

Short answer: discover → execute → trace, on one shared runtime.wasm. Not from the published packages. Kotlin com.traverse-framework:traverse-embedder 0.14.0 on Maven Central and .NET TraverseEmbedder 0.14.0 on nuget.org do not include exact-ref execute. Both ExactModelHost implementations are on traverse main. The next package cuts are #1651.

+

Short answer: yes, in Traverse v0.15.0. Discover → execute → trace, on one shared runtime.wasm. Kotlin com.traverse-framework:traverse-embedder 0.15.0 on Maven Central and .NET TraverseEmbedder 0.15.0 on nuget.org both include ExactModelHost. #1651 is closed. The published 0.14.0 packages did not include it.

What a published consumer can run

-

Native Rust and the web embedder execute signed exact-ref in the v0.14.0 cut. Swift ExactModelHost is in the published xcframework swift-host-v0.14.0-4, which Package.swift pins (first on swift-host-v0.14.0-1, #1579). Distribution is GitHub Release + SPM binary target, not a CocoaPods claim. Full matrix: Which hosts run signed exact-ref models?.

+

Native Rust and traverse-embedder-web@0.15.0 execute signed exact-ref. Swift ExactModelHost is on the swift-host-v0.15.0 xcframework, which Package.swift on main pins. Distribution is GitHub Release + SPM binary target, not a CocoaPods claim. Full matrix: Which hosts run signed exact-ref models?.

-

On main, not in the published package

+

What shipped in the 0.15.0 packages

    -
  • Kotlin ExactModelHost: #1580 closed. Maven Central still lists 0.13.0 and 0.14.0. The 0.14.0 AAR was published 2026-09-29, before the host.
    • -
  • .NET ExactModelHost: #1602 closed. nuget.org still lists 0.13.0 and 0.14.0.
    • -
  • Next cuts for both packages: #1651.
    • +
  • Kotlin ExactModelHost runs on wasmi through the traverse-android-host JNI shim (#1580). The 0.15.0 AAR is on Maven Central.
    • +
  • .NET ExactModelHost runs through two audited P/Invoke functions (#1602). nuget.org lists TraverseEmbedder 0.15.0. The package ships the native engine for win-x64, win-arm64, and linux-x64.
    • +
  • Both hosts enforce model_usage. Omitting it fails closed.

Honest consumers

-

Shipped consumers for capabilities today: JS/TS + Rust embedders + MCP; Python via CLI only. Mobile/.NET hosts: check Platforms and what is real today before quoting. Embedder notes: v0.14.0: what changed for embedders.

+

Shipped consumers for capabilities today: JS/TS + Rust embedders + MCP; Python via CLI only. Swift, Kotlin, and .NET are published, pre-1.0, and not Certified under Spec 529. Check Platforms and what is real today before quoting. The v0.14.0 embedder notes stay historical: v0.14.0: what changed for embedders.

 diff --git a/src/pages/questions/can-traverse-build-mobile-apps.astro b/src/pages/questions/can-traverse-build-mobile-apps.astro index e6820b5..d0a7637 100644 --- a/src/pages/questions/can-traverse-build-mobile-apps.astro +++ b/src/pages/questions/can-traverse-build-mobile-apps.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'Can I build a mobile app with Traverse?', acceptedAnswer: { '@type': 'Answer', - text: 'Partially. Traverse runs your business logic on mobile, not your UI. iOS has a production wasmi-based Swift host (Spec 074, ADR-0014, ADR-0015) distributed as an XCFramework, and the Android embedder (Chicory-based) is published on Maven Central at 0.14.0. Both are pre-1.0 and marked In progress on the Platforms page; no host is Certified under Spec 529 yet.', + text: 'Partially. Traverse runs your business logic on mobile, not your UI. iOS has a production wasmi-based Swift host (Spec 074, ADR-0014, ADR-0015) distributed as an XCFramework, and the Android embedder (Chicory-based) is published on Maven Central at 0.15.0. Both are pre-1.0 and marked In progress on the Platforms page; no host is Certified under Spec 529 yet.', }, }], }); @@ -23,22 +23,22 @@ const relatedLinks = [ --- -

Partially — and the status is no longer the same across both major mobile OSes, so it's worth being precise about which platform you mean. Traverse's shipped targets are native (Windows, macOS, Linux) and the browser. The Swift (iOS/macOS), Kotlin (Android), and .NET (Windows) embedders all have published packages at 0.14.0, but they're pre-1.0 and still marked In progress on the Platforms page.

+

Partially — and the status is no longer the same across both major mobile OSes, so it's worth being precise about which platform you mean. Traverse's shipped targets are native (Windows, macOS, Linux) and the browser. The Swift (iOS/macOS), Kotlin (Android), and .NET (Windows) embedders all have published packages at 0.15.0, but they're pre-1.0 and still marked In progress on the Platforms page.

iOS — a production runtime bridge

packages/swift/TraverseEmbedder now ships WasmiHostBridgeClient as its production runtime loader: it embeds the wasmi interpreter behind a narrow, audited C ABI, packaged as the TraverseSwiftHost XCFramework, and enforces host-owned memory and fuel limits on every call. Its resource controls follow Spec 074 (Swift Native Resource-Control Certification), governed by ADR-0014 (selecting wasmi for the Apple runtime profile) and ADR-0015 (the production C-ABI boundary). The earlier WasmKit-based bridge has been removed from the package; WasmKit is not supported. The original feasibility spike that unblocked this — written up here — is history at this point, not the current state.

Android — published, in progress

-

packages/kotlin/TraverseEmbedder has a working ChicoryRuntimeBridge pinned to Chicory 1.7.5, and it's published on Maven Central as com.traverse-framework:traverse-embedder (0.14.0). Android Compose clients live in reference-apps.

+

packages/kotlin/TraverseEmbedder has a working ChicoryRuntimeBridge pinned to Chicory 1.7.5, and it's published on Maven Central as com.traverse-framework:traverse-embedder (0.15.0). Android Compose clients live in reference-apps.

.NET / WinUI — published, in progress

-

The same shape as Android: packages/dotnet/TraverseEmbedder has a working bridge on Wasmtime .NET 44.0.0, published on nuget.org as TraverseEmbedder (0.14.0), with WinUI clients in reference-apps.

+

The same shape as Android: packages/dotnet/TraverseEmbedder has a working bridge on Wasmtime .NET 44.0.0, published on nuget.org as TraverseEmbedder (0.15.0), with WinUI clients in reference-apps.

If your app's core problem is mobile UI, Traverse isn't a full toolkit for that yet on either platform. If you're building a mobile app today, the embedders are real and installable, but they're pre-1.0, no host is Certified under Spec 529 yet, and each one enforces resource limits through its own engine. The contract you write now doesn't change as those hosts mature. Track live status on the Platforms page — it's the same page we link internally, not a separate marketing version.

 diff --git a/src/pages/questions/can-traverse-run-models-on-a-gpu-or-neural-engine.astro b/src/pages/questions/can-traverse-run-models-on-a-gpu-or-neural-engine.astro index 42fe02f..9b6f08f 100644 --- a/src/pages/questions/can-traverse-run-models-on-a-gpu-or-neural-engine.astro +++ b/src/pages/questions/can-traverse-run-models-on-a-gpu-or-neural-engine.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'Can Traverse run models on a GPU or the Apple Neural Engine?', acceptedAnswer: { '@type': 'Answer', - text: 'Not in a published release. In Traverse v0.14.0, governed exact-ref models run on the wasm-cpu path inside the one shared runtime. On traverse main (unreleased), the runtime now has a generic native accelerator adapter framework (Decision 112, Spec 138 FR-060 to FR-065): the host policy lists ordered placements, default wasm-cpu; a placement is chosen only if the host supports it, the signed package carries a variant for it, the variant passes an on-device self-check against its conformance vector, and it fits the host memory ceiling. If nothing qualifies, the call fails closed with placement_unavailable before the input is consumed, and the result records which placement ran. The real Core ML adapter is not landed yet: the conversion spike is #1663 and the iPhone evidence is #1630.', + text: 'Core ML is an opt-in placement on Apple hosts in Traverse v0.15.0. The default placement is still wasm-cpu inside the one shared runtime. A signed Core ML variant runs only when the host asks for it and the variant passes an on-device self-check against its conformance vector. Published evidence so far is macOS cargo test plus the Decision 113 iPhone spike. Governed-path iPhone evidence is still open (traverse#1630). There is no web, Android, or desktop GPU adapter. No host is Certified.', }, }], }); @@ -24,29 +24,28 @@ const relatedLinks = [ --- -

Short answer: not in a published release. In Traverse v0.14.0, governed exact-ref models run on the wasm-cpu path inside the one shared runtime. Hardware acceleration is being built on traverse main, and the part that has landed is the policy and evidence layer, not a working GPU or Neural Engine adapter.

+

Short answer: Apple hosts in Traverse v0.15.0 can opt in to a package's signed Core ML variant. The default placement is still wasm-cpu inside the one shared runtime. There is no web, Android, or desktop GPU adapter.

-

What is on main today (unreleased)

-

As of October 13, 2026, traverse-runtime on main has a generic native accelerator adapter framework (Decision 112, Spec 138 FR-060 to FR-065, traverse#1667). It is not in any published crate or package yet.

+

What shipped in v0.15.0

+

The accelerator adapter framework is in the published release (Decision 112, traverse#1667), together with a real ONNX to Core ML converter (#1663) and the Swift ExactModelHost Core ML path.

    -
  • The host chooses, in policy. The execution policy lists placements in order. An empty list means wasm-cpu only. An unknown or repeated placement id is policy_denied.
    • -
  • A placement has to earn its turn. The runtime takes the first listed placement that the host supports, that the signed package carries a variant for, that passed its device self-check, that fits the host memory ceiling, and that meets require_fuel_metering when the host asks for it.
    • -
  • The self-check is real. The variant's conformance vector runs on the device and is compared under the variant's declared tolerance. The result is cached per variant digest, adapter, platform version, and compute units, so an OS update re-runs it. A failed check makes that variant unavailable.
    • -
  • It fails closed. If nothing qualifies, the call fails with placement_unavailable before the input is consumed. A late adapter result after cancel or deadline is discarded.
    • -
  • The trace says where it ran. Every result carries placement evidence: the placement, the compute units, and whether fuel metering applied.
    • +
  • The host chooses, in policy. The execution policy lists placements in order. An empty list means wasm-cpu only.
    • +
  • A variant has to earn its turn. It runs only after an on-device self-check against its signed conformance vector, within the declared tolerance, and only if it fits the host memory ceiling. require_fuel_metering keeps a call on metered placements.
    • +
  • It fails closed. If nothing qualifies, the call fails with placement_unavailable. Every result carries placement evidence.
    • +
  • Core ML is opt-in. Swift's ExactModelHost gains coreML, variant files, and placements. Without that opt-in, the call stays on wasm-cpu.
-

What is not done yet

-

No real accelerator adapter has landed. The first one planned is Core ML on Apple devices, called from Rust. An earlier converter wrapped ONNX in a way Core ML could only run on the CPU, so it is being replaced through a spike-gated ONNX to Core ML route (#1663), with on-device iPhone timing evidence tracked in #1630. There is no GPU adapter for the web, Android, or desktop, and no date for one.

+

What the evidence is, and what it is not

+

Published evidence so far is macOS cargo test plus the Decision 113 iPhone spike. Governed-path iPhone evidence is still open (traverse#1630). This page does not quote spike timings as product performance. No host is Certified under Spec 529.

Why it is built this way

-

An accelerator is an implementation detail of the host, not a second runtime. The contract, the signed package, and discover → execute → trace stay the same. The adapter only runs a variant the package already signed, only after it matched the wasm-cpu reference on that device, and the trace records which path produced the answer. An agent or app can ask for speed, but the runtime decides whether the faster path is trustworthy on this hardware.

+

An accelerator is an implementation detail of the host, not a second runtime. The contract, the signed package, and discover → execute → trace stay the same. The adapter only runs a variant the package already signed, and the trace records which path produced the answer.

This is a different thing from capability placement targets (local, browser, and so on), which decide where a capability can be placed. Model placements decide which compute path runs a signed model inside a host.

 diff --git a/src/pages/questions/does-the-registry-record-model-rights.astro b/src/pages/questions/does-the-registry-record-model-rights.astro index b58c5e4..f28854a 100644 --- a/src/pages/questions/does-the-registry-record-model-rights.astro +++ b/src/pages/questions/does-the-registry-record-model-rights.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'Does the Traverse registry record model licenses and usage rights?', acceptedAnswer: { '@type': 'Answer', - text: 'Yes, on the registry side. Registry spec 026 (model rights compliance) requires every newly added model-backed contract to declare commercial_use, redistribution and derivatives for each ai.models entry, with unknown rejected. It also pins LICENSE and NOTICE files by sha256, requires an immutable upstream commit, records how shipped weights were derived, and signs the contract bytes so the rights record is authenticated. The index projects a usage_class (unrestricted, evaluation-only or conditional). The record is a signed maintainer declaration, not a legal certification. Traverse CLI inspection and runtime enforcement are tracked in traverse#1598 and are not shipped yet.', + text: 'Yes, on the registry side. Registry spec 026 (model rights compliance) requires every newly added model-backed contract to declare commercial_use, redistribution and derivatives for each ai.models entry, with unknown rejected. It also pins LICENSE and NOTICE files by sha256, requires an immutable upstream commit, records how shipped weights were derived, and signs the contract bytes so the rights record is authenticated. The index projects a usage_class (unrestricted, evaluation-only or conditional). The record is a signed maintainer declaration, not a legal certification. Traverse CLI inspection of that registry record, honoring a revoked capability, and verifying the contract signature are still traverse#1598 and are not shipped. Host-side exact-ref model_usage enforcement is a different gate and did ship in Traverse v0.15.0.', }, }], }); @@ -25,7 +25,7 @@ const relatedLinks = [ --- What is still open (as of October 5, 2026)
    -
  • Traverse-side enforcement. Showing the full rights record in traverse-cli, honoring revoked at runtime, and verifying the contract signature are tracked in traverse#1598. They are not in a published Traverse release yet.
    • +
  • Registry spec 026 on the Traverse side. Showing the full registry rights record in traverse-cli, honoring a revoked capability at runtime, and verifying the contract signature are tracked in traverse#1598. That issue is still open. It is not the same gate as exact-ref model_usage, which v0.15.0 does enforce on every published host.
  • Existing agents. Already-published versions are never judged retroactively. The five existing model-backed agents get compliant new MINOR versions under registry#623.

The publish path already checks the parts of this record that the contract alone can decide, offline: see Does capability publish validate model attribution?.

diff --git a/src/pages/questions/does-the-rust-embedder-use-the-same-runtime-wasm.astro b/src/pages/questions/does-the-rust-embedder-use-the-same-runtime-wasm.astro index 18cb428..27a89b4 100644 --- a/src/pages/questions/does-the-rust-embedder-use-the-same-runtime-wasm.astro +++ b/src/pages/questions/does-the-rust-embedder-use-the-same-runtime-wasm.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'Does the Rust embedder use the same runtime.wasm?', acceptedAnswer: { '@type': 'Answer', - text: 'Yes, at the contract. Discover, execute, and trace go through one shared runtime contract and one product runtime. One shared runtime.wasm means that orchestrator contract and ABI, not that every package ships a .wasm file you load. traverse-embedder-web@0.14.0 loads the app bundle\'s runtime/runtime.wasm, checks runtime/runtime.wasm.sha256, and runs capabilities through it. traverse-embedder@0.14.0 links traverse-runtime natively as a Cargo workspace dependency and ships no separate runtime-WASM artifact. Capability artifacts stay WASM and still target the Traverse host ABI that linked or loaded runtime supports. Hosts and embedders are clients (UI and I/O), not separate Traverse runtimes. Published consumers today are JS/TS, Rust, and MCP. Python shells out to traverse-cli. There is no Python SDK. Swift, Kotlin, and .NET are published, pre-1.0, and not Certified under Spec 529. The published 0.14.0 Maven and NuGet packages do not include ExactModelHost.', + text: 'Yes, at the contract. Discover, execute, and trace go through one shared runtime contract and one product runtime. One shared runtime.wasm means that orchestrator contract and ABI, not that every package ships a .wasm file you load. traverse-embedder-web@0.15.0 loads the app bundle\'s runtime/runtime.wasm, checks runtime/runtime.wasm.sha256, and runs capabilities through it. traverse-embedder@0.15.0 links traverse-runtime natively as a Cargo workspace dependency and ships no separate runtime-WASM artifact. Capability artifacts stay WASM and still target the Traverse host ABI that linked or loaded runtime supports. Hosts and embedders are clients (UI and I/O), not separate Traverse runtimes. Published consumers today are JS/TS, Rust, and MCP. Python shells out to traverse-cli. There is no Python SDK. Swift, Kotlin, and .NET are published, pre-1.0, and not Certified under Spec 529. The published 0.15.0 Maven and NuGet packages include ExactModelHost. The 0.14.0 packages did not.', }, }], }); @@ -36,12 +36,12 @@ const relatedLinks = [

One shared runtime.wasm means one orchestrator contract and ABI, and one product runtime. It does not mean every package literally ships a .wasm file you load.

Web loads the bundle file

-

traverse-embedder-web@0.14.0 loads runtime/runtime.wasm from the application bundle, checks it against runtime/runtime.wasm.sha256, and runs each capability through that orchestrator. The file is not inside the npm package. If either file is missing, or the digest does not match, init fails closed. The package README's Runtime-WASM execution section says BundleEmbedder digest-verifies that bundle orchestrator and drives the same host ABI native hosts use (traverse_init, traverse_submit, traverse_next_event). Node uses the same package with NodeFsBundleLoader. It still loads the bundle's own file.

+

traverse-embedder-web@0.15.0 loads runtime/runtime.wasm from the application bundle, checks it against runtime/runtime.wasm.sha256, and runs each capability through that orchestrator. The file is not inside the npm package. If either file is missing, or the digest does not match, init fails closed. The package README's Runtime-WASM execution section says BundleEmbedder digest-verifies that bundle orchestrator and drives the same host ABI native hosts use (traverse_init, traverse_submit, traverse_next_event). Node uses the same package with NodeFsBundleLoader. It still loads the bundle's own file.

The public /discover page is that web path. It executes a reviewed plan through a digest-verified nested runtime.wasm. The page cites Spec 1402 for that nested orchestrator file. Spec 1402, as the discover page uses it, names the file the browser loads. It is not a claim that the Rust crate ships the same file.

Rust links the runtime natively

-

traverse-embedder@0.14.0 on crates.io does not load a separate runtime-WASM file. Its Cargo.toml depends on traverse-runtime as a workspace dependency, so the crate links the Traverse runtime at the same workspace version. The crate README's Runtime-WASM compatibility section says the Rust package ships no separate runtime-WASM artifact.

+

traverse-embedder@0.15.0 on crates.io does not load a separate runtime-WASM file. Its Cargo.toml depends on traverse-runtime as a workspace dependency, so the crate links the Traverse runtime at the same workspace version. The crate README's Runtime-WASM compatibility section says the Rust package ships no separate runtime-WASM artifact.

Capability artifacts in the bundle are still WASM. They have to target the Traverse host ABI that linked runtime supports. An unsupported schema, a digest mismatch, or an invalid manifest is rejected at init with a stable error code. The crate does not fall back to a traverse-cli serve sidecar.

@@ -50,11 +50,11 @@ const relatedLinks = [

Honest consumers

    -
  • JS/TS — published npm traverse-embedder-web@0.14.0. Loads the bundle's runtime/runtime.wasm.
    • -
  • Rust — published crates.io traverse-embedder@0.14.0. Links traverse-runtime natively. No separate runtime-WASM artifact.
    • +
  • JS/TS — published npm traverse-embedder-web@0.15.0. Loads the bundle's runtime/runtime.wasm.
    • +
  • Rust — published crates.io traverse-embedder@0.15.0. Links traverse-runtime natively. No separate runtime-WASM artifact.
  • AI agents — published traverse-mcp (stdio bootstrap).
  • Python — shell out to traverse-cli capability-package execute. There is no Python SDK.
    • -
  • Swift / Kotlin / .NET — published, pre-1.0, and not Certified under Spec 529. Swift xcframework on swift-host-v* tags; Kotlin com.traverse-framework:traverse-embedder 0.14.0 on Maven Central; .NET TraverseEmbedder 0.14.0 on nuget.org.
    • +
  • Swift / Kotlin / .NET — published, pre-1.0, and not Certified under Spec 529. Swift xcframework on swift-host-v* tags; Kotlin com.traverse-framework:traverse-embedder 0.15.0 on Maven Central; .NET TraverseEmbedder 0.15.0 on nuget.org.
-

The published 0.14.0 Maven and NuGet packages do not include ExactModelHost. Check Platforms before treating a host as shipped. The narrative version of this page is one shared runtime, two loading paths.

+

The published 0.15.0 Maven and NuGet packages include ExactModelHost. The 0.14.0 packages did not. Check Platforms before treating a host as Certified. The narrative version of this page is one shared runtime, two loading paths (written against v0.14.0).

 diff --git a/src/pages/questions/does-the-website-use-the-latest-traverse-embedder.astro b/src/pages/questions/does-the-website-use-the-latest-traverse-embedder.astro index c6737a6..f0c3003 100644 --- a/src/pages/questions/does-the-website-use-the-latest-traverse-embedder.astro +++ b/src/pages/questions/does-the-website-use-the-latest-traverse-embedder.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'Does the Traverse website use the latest traverse-embedder-web?', acceptedAnswer: { '@type': 'Answer', - text: 'Today, yes: the website pins traverse-embedder-web at ^0.14.0, the same line npm publishes with Traverse v0.14.0, and the /discover generate panel admits its demo fixture through registerPackage(manifestBytes, wasm, signatureBytes), the 0.14 signed Spec 138 path. The demo fixture is signed with Traverse\'s published test-only key, which it trusts only for that demo. The site can still lag a future release, so treat published npm/crates versions and what-is-real-today as the product line, not the website pin.', + text: 'Today, yes: the website pins traverse-embedder-web at ^0.15.0, the same line npm publishes with Traverse v0.15.0, and the /discover generate panel admits its demo fixture through registerPackage(manifestBytes, wasm, signatureBytes) and passes modelUsage, which v0.15.0 requires. The demo fixture is signed with Traverse\'s published test-only key, which it trusts only for that demo. The site can still lag a future release, so treat published npm/crates versions and what-is-real-today as the product line, not the website pin.', }, }], }); @@ -24,7 +24,7 @@ const relatedLinks = [ --- Short answer: today, yes, but it can lag. The marketing site follows the published package line after each release. That is honesty, not a secret second runtime.

What is pinned today

-

On traverse-framework/website main, package.json depends on traverse-embedder-web at ^0.14.0. npm’s current published line for that package is also 0.14.0, lockstep with Traverse v0.14.0 crates. Cite what is real today for the consumer list apps should build against.

+

On traverse-framework/website, package.json depends on traverse-embedder-web at ^0.15.0. npm’s current published line for that package is also 0.15.0, lockstep with Traverse v0.15.0 crates. Cite what is real today for the consumer list apps should build against.

How /discover admits its demo model

-

The public /discover generate panel (discover-generate.js) constructs an ExactModelBrowserHost and admits the fixture.responder@1.0.0 conformance fixture through registerPackage(manifestBytes, wasm, signatureBytes), the 0.14 path. The Ed25519 signature over the exact model.manifest.json bytes, the pin digest, and the WASM digest are all verified before execute. The fixture is signed with Traverse's published test-only key, which the demo trusts only for that fixture. Product hosts configure their own trust roots. Earlier, the 0.13 pin used insertVerified, which 0.14 removed.

+

The public /discover generate panel (discover-generate.js) constructs an ExactModelBrowserHost and admits the fixture.responder@1.0.0 conformance fixture through registerPackage(manifestBytes, wasm, signatureBytes). v0.15.0 also requires modelUsage whenever pins exist; the demo passes non_commercial. The Ed25519 signature over the exact model.manifest.json bytes, the pin digest, and the WASM digest are all verified before execute. The fixture is signed with Traverse's published test-only key, which the demo trusts only for that fixture. Product hosts configure their own trust roots. The 0.13 pin used insertVerified, which 0.14 removed.

What you should pin

-

If you are building a product host, depend on the published npm / crates.io versions (today traverse-embedder-web@0.14.0 / traverse-embedder@0.14.0), not on whatever the website happens to ship in its demo bundle. The site is a citeable demo surface; it is not the version authority for your app.

+

If you are building a product host, depend on the published npm / crates.io versions (today traverse-embedder-web@0.15.0 / traverse-embedder@0.15.0), not on whatever the website happens to ship in its demo bundle. The site is a citeable demo surface; it is not the version authority for your app.

Related

What the page is for: What does the /discover page do?. Signed exact-ref surface: What is exact-ref model execution?. Embedder delta notes: v0.14.0: what changed for embedders.

diff --git a/src/pages/questions/how-do-hosts-trust-signed-models.astro b/src/pages/questions/how-do-hosts-trust-signed-models.astro index a72e07b..1e7c27f 100644 --- a/src/pages/questions/how-do-hosts-trust-signed-models.astro +++ b/src/pages/questions/how-do-hosts-trust-signed-models.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'How do hosts trust signed models in Traverse?', acceptedAnswer: { '@type': 'Answer', - text: 'Discover → execute → trace. One shared runtime.wasm. As of Traverse v0.14.0 (signed Spec 138), model packages use schema 2.0.0 manifests plus a detached Ed25519 model.sig.json. Host-owned trust roots gate register_package / registerPackage; apps never add trust. Pin by digest and signature, never a naked URL. The first trained package digits-mlp-1.0.0 ships with a test-only key; production signing is #1567. Published exact-ref execute is native Rust, web, and Swift ExactModelHost (swift-host-v0.14.0-4). Kotlin and .NET ExactModelHost are on traverse main and are not in the published 0.14.0 packages (#1651). ONNX as a generic runner is not shipped.', + text: 'Discover → execute → trace. One shared runtime.wasm. Model packages use schema 2.0.0 or later plus a detached Ed25519 model.sig.json. Host-owned trust roots gate register_package / registerPackage; apps never add trust. v0.15.0 also requires model_usage or the call fails closed. Pin by digest and signature, never a naked URL. Published exact-ref execute is native Rust, web, Swift ExactModelHost on swift-host-v0.15.0, and Kotlin and .NET ExactModelHost in the 0.15.0 Maven and NuGet packages. digits-mlp-1.0.0 uses a test-only key; production custody is #1567, still open. Third-party ONNX models can be packaged and signed with traverse-cli model.', }, }], }); @@ -20,7 +20,7 @@ const relatedLinks = [ { href: '/questions/does-capability-publish-validate-model-attribution.html', label: 'Does publish validate model attribution?' }, { href: '/questions/which-hosts-run-signed-exact-ref-models.html', label: 'Which hosts run signed exact-ref models?' }, { href: '/questions/what-is-exact-ref-model-execution.html', label: 'What is exact-ref model execution?' }, - { href: '/blog/traverse-0-14-0-what-changed-for-embedders.html', label: 'v0.14.0: what changed for embedders' }, + { href: '/blog/traverse-0-14-0-what-changed-for-embedders.html', label: 'v0.14.0: what changed for embedders (historical)' }, { href: '/questions/how-do-i-verify-a-signed-capability-artifact.html', label: 'How do I verify a signed capability artifact?' }, { href: '/questions/what-is-the-wasm-sandbox.html', label: 'What is the WASM sandbox?' }, { href: '/platforms.html', label: 'Platforms' }, @@ -28,7 +28,7 @@ const relatedLinks = [ ---

Short answer: the host owns the trust roots. Packages enter only through register_package / registerPackage after signature and digest checks against pins the app already declared. A naked URL is never identity.

-

Signed packages (v0.14.0)

-

Traverse v0.14.0 lands signed Spec 138: schema 2.0.0 manifests and a detached Ed25519 model.sig.json over the exact model.manifest.json bytes. App manifests pin those bytes (SHA-256), plus target, expected rights, and an optional signer key_id. Embedder notes: what changed for embedders. Announcement: Discussion #1576.

+

Signed packages

+

Traverse v0.14.0 landed signed Spec 138: schema 2.0.0 manifests and a detached Ed25519 model.sig.json over the exact model.manifest.json bytes. v0.15.0 still verifies those packages, plus schema 2.1.0 and 2.2.0. App manifests pin those bytes (SHA-256), plus target, expected rights, and an optional signer key_id. Historical embedder notes: what changed for embedders in v0.14.0.

Host-owned trust roots

-

Trust lists live on the host (TrustedModelKeys on Rust, trustedPublicKeysHex on web and Swift ExactModelHost). Applications cannot inject keys. Registration verifies the signature against a trusted key, the digest against exactly one pin, and the manifest schema (unknown fields fail closed), rights, target, and limits. Every execute re-hashes cached bytes. Failures stay typed (model_unavailable / model_incompatible) with a stable reason.

+

Trust lists live on the host (TrustedModelKeys on Rust, trustedPublicKeysHex on web and Swift ExactModelHost). Applications cannot inject keys. Registration verifies the signature against a trusted key, the digest against exactly one pin, and the manifest schema (unknown fields fail closed), rights, target, and limits. Every execute re-hashes cached bytes. v0.15.0 also requires model_usage. Without it, the call fails closed with usage_undeclared.

Test-only key vs production

-

The first trained package digits-mlp-1.0.0 is signed with a test-only key so CI and demos can exercise the path. Production model signing is tracked separately as #1567. Do not treat the test key as a production trust root.

+

The first trained package digits-mlp-1.0.0 is signed with a test-only key so CI and demos can exercise the path. v0.15.0 ships key-generation tooling and an opt-in signing workflow. Custody, distribution, rotation, and revocation are still #1567. Do not treat the test key as a production trust root.

Host honesty

-

Discover → execute → trace, on one shared runtime.wasm. Published exact-ref execute is native Rust, the web embedder, and Swift ExactModelHost (xcframework swift-host-v0.14.0-4 + Package.swift pin). Kotlin and .NET ExactModelHost are on traverse main and are not in the published 0.14.0 packages (#1651) — check Platforms. This page is about signed-model trust for Spec 138 exact-ref; it does not claim a generic ONNX runner is shipped. Deeper loop: What is exact-ref model execution?

+

Discover → execute → trace, on one shared runtime.wasm. Published exact-ref execute in v0.15.0 is native Rust, the web embedder, Swift ExactModelHost on swift-host-v0.15.0, and Kotlin and .NET ExactModelHost in the 0.15.0 Maven and NuGet packages. Third-party ONNX models can be packaged, signed, and verified with traverse-cli model. Check Platforms. Deeper loop: What is exact-ref model execution?

 diff --git a/src/pages/questions/how-do-i-read-traverse-traces-from-inside-my-app.astro b/src/pages/questions/how-do-i-read-traverse-traces-from-inside-my-app.astro index 2d313c9..519e9ef 100644 --- a/src/pages/questions/how-do-i-read-traverse-traces-from-inside-my-app.astro +++ b/src/pages/questions/how-do-i-read-traverse-traces-from-inside-my-app.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'How do I read Traverse execution traces from inside my app?', acceptedAnswer: { '@type': 'Answer', - text: 'Call the Embedded Trace API on the embedder you already have. In traverse-embedder-web and the Rust traverse-embedder crate (0.14.0), traceList(version, pageSize, cursor) pages through the current session\'s traces, newest first, and traceGet(version, traceId) opens one. Each record is a safe public projection: target id and version, outcome, execution phases, placement, and a stable failure code. It never includes raw inputs, outputs, caller identity, or private hashes. History is process-local, capped at the last 100 executions, and cleared on shutdown. No HTTP sidecar is involved. The Swift, Kotlin, and .NET packages do not expose this API yet.', + text: 'Call the Embedded Trace API on the embedder you already have. In traverse-embedder-web and the Rust traverse-embedder crate (0.15.0), traceList(version, pageSize, cursor) pages through the current session\'s traces, newest first, and traceGet(version, traceId) opens one. Each record is a safe public projection: target id and version, outcome, execution phases, placement, and a stable failure code. It never includes raw inputs, outputs, caller identity, or private hashes. History is process-local, capped at the last 100 executions, and cleared on shutdown. No HTTP sidecar is involved. The Swift, Kotlin, and .NET packages do not expose this API yet.', }, }], }); @@ -52,7 +52,7 @@ const relatedLinks = [ >

Ask the embedder your app already holds. Discover → execute → trace means every execution leaves a record. The Embedded Trace API (embedded-trace-api/1.0.0, Spec 517) is how a host reads those records back without starting traverse-cli serve or calling anything over HTTP.

-

It ships today in traverse-embedder-web@0.14.0 (browser and Node) and the Rust traverse-embedder@0.14.0 crate. There are two calls:

+

It ships today in traverse-embedder-web@0.15.0 (browser and Node) and the Rust traverse-embedder@0.15.0 crate. There are two calls:

{traceExample}
diff --git a/src/pages/questions/how-do-i-unit-test-app-code-that-calls-traverse.astro b/src/pages/questions/how-do-i-unit-test-app-code-that-calls-traverse.astro index 3bf8aa8..92c8724 100644 --- a/src/pages/questions/how-do-i-unit-test-app-code-that-calls-traverse.astro +++ b/src/pages/questions/how-do-i-unit-test-app-code-that-calls-traverse.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'How do I unit-test app code that calls Traverse without running WASM?', acceptedAnswer: { '@type': 'Answer', - text: 'Swap the real embedder for the deterministic test double that ships in the same package. traverse-embedder-web and the Rust traverse-embedder crate (both 0.14.0) export EmbedderTestDouble, which implements the same embedder API: you script an output or an error per target id, and it emits the same event envelope with deterministic ids (sess-*, req-*, evt-*), rejects unknown targets with target_not_found, and rejects calls after shutdown with runtime_stopped. Swift, Kotlin, and .NET ship a smaller InMemoryTraverseEmbedder harness. A test double never loads WASM, so it tests your host code, not the capability.', + text: 'Swap the real embedder for the deterministic test double that ships in the same package. traverse-embedder-web and the Rust traverse-embedder crate (both 0.15.0) export EmbedderTestDouble, which implements the same embedder API: you script an output or an error per target id, and it emits the same event envelope with deterministic ids (sess-*, req-*, evt-*), rejects unknown targets with target_not_found, and rejects calls after shutdown with runtime_stopped. Swift, Kotlin, and .NET ship a smaller InMemoryTraverseEmbedder harness. A test double never loads WASM, so it tests your host code, not the capability.', }, }], }); @@ -58,7 +58,7 @@ const relatedLinks = [

Swap the real embedder for the test double that ships in the same package. Your screen, handler, or job talks to the embedder API: submit, subscribe, shutdown. The double implements that same API without loading a bundle or any WASM. You tell it what each target should return, and your test checks how your code reacts.

JS/TS and Rust: EmbedderTestDouble

-

Both traverse-embedder-web@0.14.0 and the Rust traverse-embedder@0.14.0 crate export EmbedderTestDouble. For each target id you can script a success with an output, or a failure with a runtime-shaped error code and message.

+

Both traverse-embedder-web@0.15.0 and the Rust traverse-embedder@0.15.0 crate export EmbedderTestDouble. For each target id you can script a success with an output, or a failure with a runtime-shaped error code and message.

{tsExample}
@@ -83,5 +83,5 @@ const relatedLinks = [
  • One real integration test per host that loads your actual bundle with BundleEmbedder and runs discover, execute, and trace end to end. The web package's own suite does this with the checked-in traverse-starter bundle.
    • -

    One known gotcha: in traverse-embedder-web@0.14.0, releaseEvidence().package.version reports 0.9.0 because the version is hard-coded (#1654). Don't assert on that field until the fix ships.

    +

    In traverse-embedder-web@0.14.0, releaseEvidence().package.version reported 0.9.0 because the version was hard-coded (#1654). The published 0.15.0 package sets that constant to 0.15.0.

     diff --git a/src/pages/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.astro b/src/pages/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.astro index 860d173..ab83c39 100644 --- a/src/pages/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.astro +++ b/src/pages/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'How should an agent react to a revoked capability during discover?', acceptedAnswer: { '@type': 'Answer', - text: 'Do not propose it as an active candidate. Range resolution in published traverse-registry 0.27.0 skips revoked versions; if nothing active matches, resolution fails and the agent should stop or pick a different active version. The public catalog keeps the row and sets revoked. The website /discover snapshot only skips deprecated rows and does not read revoked. No revoked.json was on registry main on 8 October 2026. The runtime refusal on an exact pin is traverse#1598 and is not shipped in v0.14.0. The agent proposes; the runtime decides.', + text: 'Do not propose it as an active candidate. Range resolution in published traverse-registry 0.28.0 skips revoked versions, as 0.27.0 did; if nothing active matches, resolution fails and the agent should stop or pick a different active version. Traverse v0.15.0 pins =0.28.0. The public catalog keeps the row and sets revoked. The website /discover snapshot only skips deprecated rows and does not read revoked. No revoked.json was on registry main on 8 October 2026. The runtime refusal on an exact pin is traverse#1598 and is not shipped in v0.15.0. The agent proposes; the runtime decides.', }, }], }); @@ -34,13 +34,13 @@ const relatedLinks = [

    Short answer: do not propose it as an active candidate. Discover is where the agent looks. Execute is where the runtime decides, and that refusal is not shipped yet.

    If you are resolving a range

    -

    Decision 127 says range resolution skips revoked versions. Published traverse-registry 0.27.0 does that, and it fails when the only matches are deprecated or revoked. Propose a different active version that satisfies the range, or stop. Retrying the revoked version as if the marker were optional is the agent deciding. That is not its job.

    -

    Traverse v0.14.0 still pins traverse-registry =0.25.0. That older crate has no revoked type and skips deprecated ranges only. Do not describe the v0.14.0 pin as already filtering revoked versions. The published 0.27.0 crate does.

    +

    Decision 127 says range resolution skips revoked versions. Published traverse-registry 0.28.0 does that, as 0.27.0 did, and it fails when the only matches are deprecated or revoked. Propose a different active version that satisfies the range, or stop. Retrying the revoked version as if the marker were optional is the agent deciding. That is not its job.

    +

    Traverse v0.15.0 pins traverse-registry =0.28.0, so a current Traverse build uses that range behavior. v0.14.0 pinned =0.25.0, which has no revoked type and skips deprecated ranges only.

    If you are reading the public catalog

    catalog.json keeps the row. A revoked version is revoked: true with a revocation object. Nothing is deleted. Read those fields and leave the row out of the proposal. The website /discover snapshot only skips deprecated: true. It does not consult revoked. On 8 October 2026 there was no revoked.json on registry main, and the live catalog's revoked flag was false on all 227 entries, so that page is not a demonstration of revoked handling.

    An exact pin is not a discover miss

    -

    If a caller already pinned the version, report the pin and its status. Do not execute the artifact yourself. There is one shared runtime.wasm. traverse-embedder-web, traverse-embedder, and traverse-mcp are clients; Python only reaches it through traverse-cli capability-package execute, and there is no Python SDK. The runtime is supposed to refuse a revoked pin. That work is traverse#1598, open, not in a release.

    +

    If a caller already pinned the version, report the pin and its status. Do not execute the artifact yourself. There is one shared runtime.wasm. traverse-embedder-web, traverse-embedder, and traverse-mcp are clients; Python only reaches it through traverse-cli capability-package execute, and there is no Python SDK. The runtime is supposed to refuse a revoked capability pin. That work is traverse#1598, open, and not in v0.15.0.

    Publishing a replacement is still skill-first, via traverse-capability-author. You do not need to write Rust. Revocation is a registry marker, not a prompt to reimplement the capability. The narrative is you don't edit a published capability.

     diff --git a/src/pages/questions/is-production-model-signing-ready.astro b/src/pages/questions/is-production-model-signing-ready.astro index 9646ac8..f5ebf13 100644 --- a/src/pages/questions/is-production-model-signing-ready.astro +++ b/src/pages/questions/is-production-model-signing-ready.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'Is production model signing ready in Traverse?', acceptedAnswer: { '@type': 'Answer', - text: 'No. digits-mlp-1.0.0 is signed with a test-only key so CI and demos can exercise Spec 138. Production model-signing key custody, distribution, rotation, and revocation are tracked as traverse#1567. Do not treat the test key as a production trust root. Signed package format (schema 2.0.0 + model.sig.json) and host-owned trust roots ship in v0.14.0; production operations are separate work.', + text: 'No, not as a finished production key program. digits-mlp-1.0.0 is signed with a test-only key so CI and demos can exercise Spec 138. v0.15.0 ships key generation, an opt-in TRAVERSE_MODEL_SIGNING_KEYS path, and a dispatch-only signing workflow (Decision 103). Custody, distribution, rotation, and revocation are still traverse#1567, which is open. Do not treat the test key as a production trust root.', }, }], }); @@ -32,14 +32,14 @@ const relatedLinks = [ relatedLinks={relatedLinks} jsonLd={jsonLd} > -

    Short answer: no for production trust operations. The signed Spec 138 path exists in v0.14.0; the first trained package uses a test-only key. Production custody is open work.

    +

    Short answer: no for a finished production trust program. The signed Spec 138 path has existed since v0.14.0. v0.15.0 adds key-generation tooling. The first trained package still uses a test-only key. Custody, rotation, and revocation are open work.

    What shipped vs what did not

    -

    Traverse v0.14.0 lands schema 2.0.0 manifests, detached Ed25519 model.sig.json, and host-owned trust roots that gate register_package / registerPackage. That is the format and the host gate — not a finished production key program.

    +

    Traverse v0.14.0 landed schema 2.0.0 manifests, detached Ed25519 model.sig.json, and host-owned trust roots that gate register_package / registerPackage. v0.15.0 adds key generation, an opt-in TRAVERSE_MODEL_SIGNING_KEYS path, and a dispatch-only signing workflow (Decision 103). That is tooling. It is not a finished production key program.

    Test-only key

    digits-mlp-1.0.0 is signed with a test-only key so CI and demos can exercise the path. Do not treat that key as a production trust root. Do not ship products that depend on it as the sole signer of record.

    Tracked work

    -

    Production model-signing key custody, distribution, rotation, and revocation: traverse#1567. Trust mechanics for callers: How do hosts trust signed models?. Host matrix: Which hosts run signed exact-ref models?.

    +

    Production model-signing key custody, distribution, rotation, and revocation: traverse#1567, still open as of 2026-10-14. Trust mechanics for callers: How do hosts trust signed models?. Host matrix: Which hosts run signed exact-ref models?.

    diff --git a/src/pages/questions/is-traverse-production-ready.astro b/src/pages/questions/is-traverse-production-ready.astro index 695e4bf..cbaf2f9 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.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.\"}}]}"; +const _body = "

    Traverse v0.15.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.15.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.\"}}]}"; --- The registry index status is active, deprecated, or revoked. A revoked entry also carries the revocation record: reason, evidence_url, and revoked_at. Decision 127 calls the revoked case a machine-readable do-not-run signal. Spec 026 says the version must not be presented as active. The spec 026 consumer doc says the runtime should refuse to run it. That is fail closed: the pin still names the bytes, and the runtime declines to execute them.

    Who decides

    -

    The host does not grow its own policy engine for this. traverse-embedder-web (JS/TS), traverse-embedder (Rust), and traverse-mcp are clients of one shared runtime.wasm. Python has no SDK; it shells out to traverse-cli capability-package execute. Swift, Kotlin, and .NET are published clients of that same runtime: Swift ships a wasmi xcframework on swift-host-v* host tags, Kotlin is com.traverse-framework:traverse-embedder 0.14.0 on Maven Central, and .NET is TraverseEmbedder 0.14.0 on nuget.org. They are pre-1.0 and marked In progress. No host is Certified under Spec 529. The agent can propose the pin. The runtime is supposed to decide.

    +

    The host does not grow its own policy engine for this. traverse-embedder-web (JS/TS), traverse-embedder (Rust), and traverse-mcp are clients of one shared runtime.wasm. Python has no SDK; it shells out to traverse-cli capability-package execute. Swift, Kotlin, and .NET are published clients of that same runtime: Swift ships a wasmi xcframework on swift-host-v0.15.0, Kotlin is com.traverse-framework:traverse-embedder 0.15.0 on Maven Central, and .NET is TraverseEmbedder 0.15.0 on nuget.org. They are pre-1.0 and marked In progress. No host is Certified under Spec 529. The agent can propose the pin. The runtime is supposed to decide.

    What a host can observe today (8 October 2026)

      -
    • Published traverse-registry 0.27.0 (crates.io, tag v0.27.0): exact-pin resolution returns deprecated and revoked records with lifecycle status and, when revoked, the revocation record. Range resolution still skips both. The fix is registry#632. registry#631 is closed.
      • -
    • Traverse v0.14.0 still pins =0.25.0. That older crate has no revoked type. The consumer slice can leave the pin; that bump is not a shipped runtime refusal.
      • -
    • Runtime refusal: traverse#1598 is open. It is not in v0.14.0.
      • +
    • Published traverse-registry 0.28.0 (crates.io, registry#636): exact-pin resolution returns deprecated and revoked records with lifecycle status and, when revoked, the revocation record. That is the 0.27.0 behavior. Range resolution still skips both. The exact-pin fix is registry#632. registry#631 is closed.
      • +
    • Traverse v0.15.0 pins =0.28.0. v0.14.0 pinned =0.25.0, which has no revoked type. Moving the pin is not the same as a shipped runtime refusal.
      • +
    • Runtime refusal: traverse#1598 is open. It is not in v0.15.0.
    -

    A host must not assume that an exact pin of a revoked version comes back as a record plus a runtime deny. The 0.27.0 crate returns the record and the status. The runtime still does not refuse. Background: you don't edit a published capability.

    +

    A host must not assume that an exact pin of a revoked version comes back as a record plus a runtime deny. The 0.28.0 crate returns the record and the status. The runtime still does not refuse. Background: you don't edit a published capability.

     diff --git a/src/pages/questions/what-does-traverse-not-claim-yet.astro b/src/pages/questions/what-does-traverse-not-claim-yet.astro index 3ba4e4b..b82b473 100644 --- a/src/pages/questions/what-does-traverse-not-claim-yet.astro +++ b/src/pages/questions/what-does-traverse-not-claim-yet.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'What does Traverse not claim yet?', acceptedAnswer: { '@type': 'Answer', - text: 'Traverse does not claim a Python SDK; that Swift/Kotlin/.NET hosts are Certified; that the published Kotlin or .NET 0.14.0 packages execute exact-ref (both ExactModelHost types are on main; package cuts are #1651); that it is a general agent-orchestration framework or web framework; cloud placement as a v0.1 goal; invented customers or production SLAs; or that approved-spec counts are the product pitch. Discover → execute → trace. One shared runtime.wasm. Swift ExactModelHost is published on swift-host-v0.14.0-4. Swift, Kotlin, and .NET packages are published and pre-1.0. Shipped consumers today are JS/TS and Rust embedders plus MCP; Python is CLI-only; check platforms.html and what-is-real-today.html before assuming a host.', + text: 'Traverse does not claim a Python SDK; that any host is Certified under Spec 529; a web, Android, or desktop GPU adapter; governed-path iPhone Core ML evidence (traverse#1630 is still open); that production model-signing custody is finished (#1567 is still open); that it is a general agent-orchestration framework or web framework; cloud placement as a v0.1 goal; invented customers or production SLAs; or that approved-spec counts are the product pitch. Discover → execute → trace. One shared runtime.wasm. v0.15.0 runs signed exact-ref models on native, web, Swift swift-host-v0.15.0, Kotlin, and .NET, and model_usage is required. Swift, Kotlin, and .NET packages are published and pre-1.0. Shipped consumers today are JS/TS and Rust embedders plus MCP; Python is CLI-only.', }, }], }); @@ -37,7 +37,9 @@ const relatedLinks = [

    Consumers and packages

    • No Python SDK. Python shells out to traverse-cli capability-package execute. See Does Traverse have a Python SDK?.
      • -
    • Swift / Kotlin / .NET packages are published and pre-1.0 (Swift xcframework on swift-host-v* tags, currently swift-host-v0.14.0-4, Kotlin com.traverse-framework:traverse-embedder 0.14.0 on Maven Central, .NET TraverseEmbedder 0.14.0 on nuget.org). They are marked In progress. No host is Certified. Swift ExactModelHost on that xcframework executes exact-ref. Kotlin and .NET ExactModelHost are on traverse main and are not in those 0.14.0 packages (#1651).
      • +
    • Swift / Kotlin / .NET packages are published and pre-1.0 (Swift xcframework swift-host-v0.15.0, Kotlin com.traverse-framework:traverse-embedder 0.15.0 on Maven Central, .NET TraverseEmbedder 0.15.0 on nuget.org). They are marked In progress. No host is Certified. All three published packages include ExactModelHost. model_usage is required.
      • +
    • Core ML is an opt-in Apple placement. Default stays wasm-cpu. Governed-path iPhone evidence is still traverse#1630. There is no web, Android, or desktop GPU adapter.
      • +
    • Production model-signing custody is still #1567. digits-mlp-1.0.0 uses a test-only key.
    • Edge is planned; cloud placement is an explicit non-goal for v0.1.
    @@ -53,7 +55,7 @@ const relatedLinks = [
    • No invented customer logos, production SLAs, or “enterprise ready” claims beyond what the roadmap and security pages say.
    • Approved-spec counts and registry catalog size are governance hygiene — not the product pitch. Lead with discover → execute → trace.
      • -
    • Pre-1.0: currently v0.12.0 under Apache 2.0.
      • +
    • Pre-1.0: currently v0.15.0 under Apache 2.0.

    What is claimed

    diff --git a/src/pages/questions/what-happens-when-a-capability-version-is-revoked.astro b/src/pages/questions/what-happens-when-a-capability-version-is-revoked.astro index 21d1231..aafdfc5 100644 --- a/src/pages/questions/what-happens-when-a-capability-version-is-revoked.astro +++ b/src/pages/questions/what-happens-when-a-capability-version-is-revoked.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'What happens when a Traverse registry capability version is deprecated or revoked?', acceptedAnswer: { '@type': 'Answer', - text: 'Nothing is edited or deleted. A deprecation adds a sibling deprecated.json (registry spec 005) and a revocation adds a sibling revoked.json with a reason and evidence (registry spec 026). The index keeps the entry and marks its status. Range resolution such as ^1.2.0 skips deprecated and revoked versions. An exact pin still resolves and returns the record with its status. Published traverse-registry 0.27.0 does that (registry#632; registry#631 is closed). The runtime is supposed to fail closed, and that refusal is traverse#1598, not shipped in v0.14.0.', + text: 'Nothing is edited or deleted. A deprecation adds a sibling deprecated.json (registry spec 005) and a revocation adds a sibling revoked.json with a reason and evidence (registry spec 026). The index keeps the entry and marks its status. Range resolution such as ^1.2.0 skips deprecated and revoked versions. An exact pin still resolves and returns the record with its status. Published traverse-registry 0.28.0 does that, continuing the 0.27.0 behavior from registry#632 (registry#631 is closed; 0.28.0 is registry#636). Traverse v0.15.0 pins =0.28.0. The runtime is supposed to fail closed, and that refusal is traverse#1598, still not shipped.', }, }], }); @@ -27,13 +27,13 @@ const relatedLinks = [ --- -

    Short answer: nothing gets edited or deleted. A published contract and its artifact are immutable, so the registry marks a version with a separate file instead. That version stops being picked by version ranges. A consumer that pinned it exactly still gets the record back, along with a status. Published traverse-registry 0.27.0 does that. The runtime refusal is still open.

    +

    Short answer: nothing gets edited or deleted. A published contract and its artifact are immutable, so the registry marks a version with a separate file instead. That version stops being picked by version ranges. A consumer that pinned it exactly still gets the record back, along with a status. Published traverse-registry 0.28.0 does that. The runtime refusal is still open.

    Deprecated: the cargo-yank shape

    Registry spec 005 adds a sibling deprecated.json next to the version's contract.json. The index marks the version deprecated. Range resolution (^1.2.0 style) skips it. Exact-pin resolution ignores the flag and succeeds if the version exists. It's the same pattern most package registries use: you stop new installs from landing on a bad version without breaking anyone who already depends on it.

    @@ -45,9 +45,9 @@ const relatedLinks = [

    Where this stands today (8 October 2026)

      -
    • Registry crate: traverse-registry 0.27.0 is on crates.io (tag v0.27.0). Exact-pin resolution returns deprecated and revoked records with lifecycle status and, when revoked, the revocation record. Range resolution still skips both. registry#631 is closed. The fix merged as registry#632.
      • +
    • Registry crate: traverse-registry 0.28.0 is on crates.io (registry#636, checked 2026-10-14). Exact-pin resolution still returns deprecated and revoked records with lifecycle status and, when revoked, the revocation record — the behavior 0.27.0 shipped. Range resolution still skips both. registry#631 is closed. The exact-pin fix merged as registry#632.
    • Markers on main: the revoked.json shape and index status are in the registry tree. No revoked.json file was present when this was checked. Forty deprecated.json files were.
      • -
    • Traverse side: honoring revoked in the runtime and showing lifecycle status in traverse-cli is traverse#1598, open, and not in v0.14.0. That release still pins =0.25.0. The consumer slice can leave that pin; the refusal is not shipped.
      • +
    • Traverse side: honoring a revoked capability in the runtime and showing lifecycle status in traverse-cli is traverse#1598, still open, and not in v0.15.0. That release pins traverse-registry at =0.28.0. v0.14.0 pinned =0.25.0. Host-side exact-ref model_usage enforcement is a different gate and did ship in v0.15.0.

    Related

    diff --git a/src/pages/questions/what-is-a-governing-spec.astro b/src/pages/questions/what-is-a-governing-spec.astro index 4252491..a9c1235 100644 --- a/src/pages/questions/what-is-a-governing-spec.astro +++ b/src/pages/questions/what-is-a-governing-spec.astro @@ -2,8 +2,8 @@ import QuestionLayout from '@layouts/QuestionLayout.astro'; const relatedLinks = []; -const _body = "

    A governing spec is a design document that must be written and approved before any feature is implemented in Traverse. The spec precedes the code. Not the other way around.

    \n\n

    Every change in the Traverse codebase that adds or modifies significant behavior must be backed by an approved governing spec. You cannot open a pull request implementing a feature that does not have a corresponding approved spec. This is what \"spec-governed development\" means in practice.

    \n\n

    What a governing spec contains

    \n
      \n
    • Problem statement — what specific problem this change addresses
      • \n
    • Proposed solution — the design being implemented, in enough detail to be reviewed on its own
      • \n
    • Alternatives considered — what other approaches were evaluated and why they were not chosen
      • \n
    • Acceptance criteria — what must be true for the implementation to be considered complete
      • \n
    \n\n

    How many governing specs exist

    \n

    Traverse has 145 approved governing specs as of v0.10.0. They cover every major system component and behavior: the runtime execution model, contract validation, the registries, placement targeting, the embedder SDKs, the durable event journal, trace artifacts, the MCP integration, and the example domains.

    \n\n

    You can read them in the repository under the specs/ directory.

    \n\n

    Why this matters

    \n

    Most codebases accumulate speculative features. Someone has an idea, writes the code, and the feature exists. Without a record of why it was built, you cannot evaluate whether it is still needed, whether it conflicts with a newer direction, or what it was meant to solve.

    \n\n

    Governing specs prevent that. Every piece of Traverse has a documented reason for existing. When something changes in a future version, the spec record shows what the original intent was and what the acceptance criteria were. That is useful for contributors, for auditors, and for anyone trying to understand why a design decision was made.

    \n\n

    How it relates to contract-driven development

    \n

    Traverse applies contract-driven thinking at two levels. At the capability level, contracts govern execution. At the project level, governing specs govern implementation. Both are about making intent explicit and machine-checkable before anything runs or ships.

    \n\n

    The governing spec process is similar to an Architecture Decision Record (ADR), but it is required for all feature work, not just high-level architectural decisions. That is a higher bar, and it is intentional.

    \n\n

    For contributors

    \n

    If you want to contribute a new feature to Traverse, the first step is drafting a governing spec and opening it for discussion. See the contribution guide for details on the process.

    "; -const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What is a governing spec in Traverse?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"A governing spec is a document that must be approved before any feature is implemented in Traverse. It describes the problem, the proposed solution, alternatives considered, and acceptance criteria. The spec precedes the code. Traverse has 145 approved governing specs as of v0.10.0. This prevents speculative code and ensures every feature is intentional. It is similar to an Architecture Decision Record but required for all feature work.\"}}]}"; +const _body = "

    A governing spec is a design document that must be written and approved before any feature is implemented in Traverse. The spec precedes the code. Not the other way around.

    \n\n

    Every change in the Traverse codebase that adds or modifies significant behavior must be backed by an approved governing spec. You cannot open a pull request implementing a feature that does not have a corresponding approved spec. This is what \"spec-governed development\" means in practice.

    \n\n

    What a governing spec contains

    \n
      \n
    • Problem statement — what specific problem this change addresses
      • \n
    • Proposed solution — the design being implemented, in enough detail to be reviewed on its own
      • \n
    • Alternatives considered — what other approaches were evaluated and why they were not chosen
      • \n
    • Acceptance criteria — what must be true for the implementation to be considered complete
      • \n
    \n\n

    How many governing specs exist

    \n

    Traverse has 152 approved governing specs on main and on the v0.15.0 tag (specs/governance/approved-specs.json, checked 2026-10-14). That count is governance hygiene, not the product pitch. They cover every major system component and behavior: the runtime execution model, contract validation, the registries, placement targeting, the embedder SDKs, the durable event journal, trace artifacts, the MCP integration, and the example domains.

    \n\n

    You can read them in the repository under the specs/ directory.

    \n\n

    Why this matters

    \n

    Most codebases accumulate speculative features. Someone has an idea, writes the code, and the feature exists. Without a record of why it was built, you cannot evaluate whether it is still needed, whether it conflicts with a newer direction, or what it was meant to solve.

    \n\n

    Governing specs prevent that. Every piece of Traverse has a documented reason for existing. When something changes in a future version, the spec record shows what the original intent was and what the acceptance criteria were. That is useful for contributors, for auditors, and for anyone trying to understand why a design decision was made.

    \n\n

    How it relates to contract-driven development

    \n

    Traverse applies contract-driven thinking at two levels. At the capability level, contracts govern execution. At the project level, governing specs govern implementation. Both are about making intent explicit and machine-checkable before anything runs or ships.

    \n\n

    The governing spec process is similar to an Architecture Decision Record (ADR), but it is required for all feature work, not just high-level architectural decisions. That is a higher bar, and it is intentional.

    \n\n

    For contributors

    \n

    If you want to contribute a new feature to Traverse, the first step is drafting a governing spec and opening it for discussion. See the contribution guide for details on the process.

    "; +const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What is a governing spec in Traverse?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"A governing spec is a document that must be approved before any feature is implemented in Traverse. It describes the problem, the proposed solution, alternatives considered, and acceptance criteria. The spec precedes the code. Traverse has 152 approved governing specs on main and on the v0.15.0 tag (specs/governance/approved-specs.json, checked 2026-10-14). That count is governance hygiene, not the product pitch. This prevents speculative code and ensures every feature is intentional. It is similar to an Architecture Decision Record but required for all feature work.\"}}]}"; --- A 64→32→10 multilayer perceptron trained on the UCI Optical Recognition of Handwritten Digits dataset (CC BY 4.0). Held-out accuracy is 96.10%. The guest runs bit-identically in the trainer, on the native host, and in the browser embedder — same pinned bytes, same scores.

    How it fits the product

    -

    Exact-ref means the app pins the package by digest and signature and calls governed model.execute — never a naked URL. Discover → execute → trace, on one shared runtime.wasm. See What is exact-ref model execution?. Published hosts that execute that path: native Rust, web, and Swift ExactModelHost (swift-host-v0.14.0-4). Kotlin and .NET ExactModelHost are on traverse main and are not in the published 0.14.0 packages.

    +

    Exact-ref means the app pins the package by digest and signature and calls governed model.execute — never a naked URL. Discover → execute → trace, on one shared runtime.wasm. See What is exact-ref model execution?. As of v0.15.0 the published hosts for that path are native Rust, the web embedder, Swift ExactModelHost on swift-host-v0.15.0, and Kotlin and .NET ExactModelHost in the 0.15.0 Maven and NuGet packages. The held-out 96.10% figure above is the v0.14.0 trainer / native / browser result.

    Honest limits

     diff --git a/src/pages/questions/what-is-exact-model-host.astro b/src/pages/questions/what-is-exact-model-host.astro index b9cdd0b..50fa9a9 100644 --- a/src/pages/questions/what-is-exact-model-host.astro +++ b/src/pages/questions/what-is-exact-model-host.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'What is ExactModelHost?', acceptedAnswer: { '@type': 'Answer', - text: 'ExactModelHost is the host-side connector for governed exact-ref model packages (Spec 138). A host registers a signed package under host-owned trust roots, then executes it under discover → execute → trace. It is not a second Traverse runtime. Published in Traverse v0.14.0: the native connector and web ExactModelBrowserHost, plus Swift ExactModelHost on the xcframework swift-host-v0.14.0-4. Kotlin and .NET ExactModelHost code is on traverse main and is not in Maven Central or nuget.org 0.14.0 (#1651). digits-mlp-1.0.0 uses a test-only key; production signing is #1567. This is not catalog model.execute, and it is not a Hugging Face integration.', + text: 'ExactModelHost is the host-side connector for governed exact-ref model packages (Spec 138). A host registers a signed package under host-owned trust roots, then executes it under discover → execute → trace. It is not a second Traverse runtime. In Traverse v0.15.0 it is published on native Rust, web ExactModelBrowserHost, Swift swift-host-v0.15.0, Maven Central traverse-embedder 0.15.0, and nuget.org TraverseEmbedder 0.15.0. model_usage is required. digits-mlp-1.0.0 uses a test-only key; production signing custody is #1567. This is not catalog model.execute, and it is not a Hugging Face integration.', }, }], }); @@ -25,7 +25,7 @@ const relatedLinks = [ --- Short answer: ExactModelHost is the host-side connector for governed exact-ref model packages (Spec 138). The host registers a signed package under trust roots the host owns, then executes that package under discover → execute → trace. It is a connector on the host. It is not a second Traverse runtime.

    What the host actually does

    -

    The app names a package by digest and signature. The connector checks that pin against a key the host already trusts, caches the package, and runs it. Apps do not add trust roots. A naked URL is not the name of the model that ran. The same loop applies on every host that has shipped the connector: discover the pinned package, execute it, leave a trace.

    +

    The app names a package by digest and signature. The connector checks that pin against a key the host already trusts, caches the package, and runs it. Apps do not add trust roots. A naked URL is not the name of the model that ran. The same loop applies on every host that has shipped the connector: discover the pinned package, execute it, leave a trace. v0.15.0 requires model_usage on that path.

    What is published

      -
    • Native — the connector ships in the Traverse v0.14.0 crates (ExactModelHostConnector).
      • -
    • Web — published traverse-embedder-web@0.14.0 includes ExactModelBrowserHost.
      • -
    • Swift — ExactModelHost is on the published xcframework swift-host-v0.14.0-4.
      • -
    • Kotlin and .NET — ExactModelHost code is on traverse main. It is not in Maven Central com.traverse-framework:traverse-embedder 0.14.0 or nuget.org TraverseEmbedder 0.14.0. Those package cuts are #1651.
      • +
    • Native — the connector ships in the Traverse v0.15.0 crates (ExactModelHostConnector).
      • +
    • Web — published traverse-embedder-web@0.15.0 includes ExactModelBrowserHost.
      • +
    • Swift — ExactModelHost is on the published xcframework swift-host-v0.15.0. It can opt in to a signed Core ML variant. The default placement stays wasm-cpu.
      • +
    • Kotlin and .NET — ExactModelHost is in Maven Central com.traverse-framework:traverse-embedder 0.15.0 and nuget.org TraverseEmbedder 0.15.0 (#1651, closed). The 0.14.0 packages did not include it.
    -

    Swift, Kotlin, and .NET embedders are published, pre-1.0, and not Certified under Spec 529. Check Platforms before treating a host as able to run exact-ref.

    +

    Swift, Kotlin, and .NET embedders are published, pre-1.0, and not Certified under Spec 529. Check Platforms before treating a host as Certified.

    What this is not

    The first trained package, digits-mlp-1.0.0, is signed with a test-only key. Production custody, rotation, and revocation are #1567, still open. This connector is not catalog model.execute. The public catalog does not offer that. It is not a Hugging Face integration. The matrix of which published hosts can run a signed package is which hosts run signed exact-ref models.

    diff --git a/src/pages/questions/what-is-exact-ref-model-execution.astro b/src/pages/questions/what-is-exact-ref-model-execution.astro index d73c1fe..efe9a83 100644 --- a/src/pages/questions/what-is-exact-ref-model-execution.astro +++ b/src/pages/questions/what-is-exact-ref-model-execution.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'What is exact-ref model execution in Traverse?', acceptedAnswer: { '@type': 'Answer', - text: 'Exact-ref model execution is how Traverse runs a WASM model package that an app has pinned by digest and signature — never by a naked URL. Discover → execute → trace. One shared runtime.wasm; embedders are clients. Hosts call the Spec 137 model.execute surface with opaque input_ref / output_ref handles. As of Traverse v0.14.0, packages use schema 2.0.0 manifests plus a detached Ed25519 model.sig.json; host-owned trust roots gate register_package; the first trained digits-mlp-1.0.0 ships signed with a test-only key (production signing is separate). Published exact-ref execute: native Rust, web, and Swift ExactModelHost (Package.swift pin to swift-host-v0.14.0-4). Kotlin and .NET ExactModelHost are on traverse main and are not in the published 0.14.0 packages (#1651). First landed in v0.12.0; Swift parity closed #1579 on 2026-09-30.', + text: 'Exact-ref model execution is how Traverse runs a WASM model package that an app has pinned by digest and signature — never by a naked URL. Discover → execute → trace. One shared runtime.wasm; embedders are clients. As of Traverse v0.15.0, signed exact-ref packages run on native Rust, the browser, Swift (swift-host-v0.15.0), Kotlin/Android (Maven Central 0.15.0), and .NET (nuget.org TraverseEmbedder 0.15.0). Every host enforces model rights: model_usage must be declared or the call fails closed. Third-party ONNX models can be packaged, signed, and verified with traverse-cli model. Apple hosts can opt in to a signed Core ML variant; the default placement stays wasm-cpu. Evidence so far is macOS cargo test plus the Decision 113 iPhone spike. Governed-path iPhone evidence is still open (traverse#1630). No host is Certified. digits-mlp-1.0.0 uses a test-only key (production custody is #1567). First landed in v0.12.0.', }, }], }); @@ -21,7 +21,8 @@ const relatedLinks = [ { href: '/questions/does-capability-publish-validate-model-attribution.html', label: 'Does publish validate model attribution?' }, { href: '/questions/which-hosts-run-signed-exact-ref-models.html', label: 'Which hosts run signed exact-ref models?' }, { href: '/questions/how-do-hosts-trust-signed-models.html', label: 'How do hosts trust signed models?' }, - { href: '/blog/traverse-0-14-0-what-changed-for-embedders.html', label: 'v0.14.0: what changed for embedders' }, + { href: '/questions/can-traverse-run-models-on-a-gpu-or-neural-engine.html', label: 'Can Traverse run models on a GPU or Neural Engine?' }, + { href: '/blog/traverse-0-14-0-what-changed-for-embedders.html', label: 'v0.14.0: what changed for embedders (historical)' }, { href: '/questions/what-is-governed-composition.html', label: 'What is governed composition?' }, { href: '/questions/what-is-the-difference-between-an-ai-agent-and-the-traverse-runtime.html', label: 'Agent vs Traverse runtime' }, { href: '/questions/what-is-the-wasm-sandbox.html', label: 'What is the WASM sandbox?' }, @@ -31,7 +32,7 @@ const relatedLinks = [ --- 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. 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.

    +

    Traverse app manifests declare exact model references. Since 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. v0.15.0 still verifies schema 2.0.0, and also 2.1.0 (rights.derivation) and 2.2.0 (accelerator variants). Packages signed for v0.14.0 keep working. 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.

    -

    Host-owned trust

    -

    Trust roots are host-owned (TrustedModelKeys on Rust, trustedPublicKeysHex on web and Swift ExactModelHost). 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.

    +

    Host-owned trust, and declared usage

    +

    Trust roots are host-owned (TrustedModelKeys on Rust, trustedPublicKeysHex on web and Swift ExactModelHost). 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.

    +

    Breaking in v0.15.0: an app with exact_model_dependencies must declare model_usage as commercial or non_commercial. Rust sets ExactModelHostConnector::model_usage, the web host takes modelUsage, and Swift takes modelUsage: with no default. Without it, registration and execution fail closed with usage_undeclared. A commercial usage rejects packages whose rights say prohibited (rights_policy_denied). A host-owned package-status map blocks revoked packages. Every result carries model_evidence.

    -

    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.

    +

    One envelope, every published 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. Embedders are clients of one shared runtime.wasm. They are not separate Traverse runtimes.

    -

    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: discover → execute → trace, on one shared runtime.wasm. Published exact-ref execute is the Rust native runtime, the web embedder, and Swift ExactModelHost (published xcframework swift-host-v0.14.0-4; Package.swift binary pin). Kotlin ExactModelHost is on traverse main (#1580, closed) and is not in Maven Central com.traverse-framework:traverse-embedder 0.14.0. .NET ExactModelHost is on traverse main (#1602, closed) and is not in nuget.org TraverseEmbedder 0.14.0. Next package cuts: #1651. Pin the Traverse crates and npm at 0.14.0. That release still pins traverse-registry at =0.25.0; crates.io has since published traverse-registry 0.27.0.

    +

    What landed in v0.15.0

    +

    Spec 138 first shipped in v0.12.0. v0.14.0 added signed packages, host-owned trust, and the first trained model digits-mlp-1.0.0 (test-only key). v0.15.0 runs those signed packages on every published embedder and enforces model rights on each of them.

    +
      +
    • Native Rust and web traverse-embedder-web@0.15.0 (ExactModelBrowserHost).
      • +
    • Swift ExactModelHost on the swift-host-v0.15.0 xcframework. Package.swift on main pins that asset (#1675). The v0.15.0 tag's Package.swift still pointed at swift-host-v0.14.0-4.
      • +
    • Kotlin ExactModelHost in Maven Central com.traverse-framework:traverse-embedder 0.15.0 (#1580, #1651 closed).
      • +
    • .NET ExactModelHost in nuget.org TraverseEmbedder 0.15.0 (#1602, #1651 closed).
      • +
    +

    Third-party ONNX models can be packaged, signed, and verified with traverse-cli model. Guest ABI v3 snapshot reuse makes repeat inference faster: the host prepares once and restores that snapshot on later calls. This release pins traverse-registry at =0.28.0.

    +

    Core ML is opt-in. An Apple host can run a package's signed Core ML variant under the same policy, tolerance, and evidence rules. Without placements, every call stays on wasm-cpu. Published evidence so far is macOS cargo test plus the Decision 113 iPhone spike. Governed-path iPhone evidence is still open (traverse#1630). There is no web, Android, or desktop GPU adapter. No host is Certified under Spec 529.

    +

    digits-mlp-1.0.0 is still signed with the test-only key. v0.15.0 ships key-generation tooling and an opt-in signing workflow. Custody, rotation, and revocation remain #1567, which is still open.

    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, or to assume the published Kotlin or .NET 0.14.0 packages already execute exact-ref.

    +

    It is not “the model is in charge.” It is not Spec 045. It is not a guest model_invoke import. It is not a Python SDK. It is not permission to treat a URL as a model identity, to call any host Certified, or to quote iPhone Core ML timing beyond the Decision 113 spike.

     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 710519b..22adb3d 100644 --- a/src/pages/questions/what-is-one-shared-runtime-wasm.astro +++ b/src/pages/questions/what-is-one-shared-runtime-wasm.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'What is one shared runtime.wasm in Traverse?', acceptedAnswer: { '@type': 'Answer', - text: 'Traverse uses one shared runtime contract and host ABI. Browser, native desktop, CLI, and MCP are embedders and clients — not different Traverse runtimes per language. The web package loads the bundle’s digest-checked runtime/runtime.wasm. The Rust crate links traverse-runtime natively and does not ship a separate runtime-WASM file. Published consumers today include JS/TS (traverse-embedder-web), Rust (traverse-embedder), and agents via traverse-mcp. Python shells out to traverse-cli. There is no Python SDK. Swift (xcframework on swift-host-v* tags), Kotlin (Maven Central com.traverse-framework:traverse-embedder 0.14.0), and .NET (nuget.org TraverseEmbedder 0.14.0) are published, pre-1.0, and not Certified.', + text: 'Traverse uses one shared runtime contract and host ABI. Browser, native desktop, CLI, and MCP are embedders and clients — not different Traverse runtimes per language. The web package loads the bundle’s digest-checked runtime/runtime.wasm. The Rust crate links traverse-runtime natively and does not ship a separate runtime-WASM file. Published consumers today include JS/TS (traverse-embedder-web), Rust (traverse-embedder), and agents via traverse-mcp. Python shells out to traverse-cli. There is no Python SDK. Swift (xcframework on swift-host-v* tags), Kotlin (Maven Central com.traverse-framework:traverse-embedder 0.15.0), and .NET (nuget.org TraverseEmbedder 0.15.0) are published, pre-1.0, and not Certified.', }, }], }); @@ -38,15 +38,15 @@ const relatedLinks = [

    Embedders are clients

    The browser package, native Rust embedder, CLI, and MCP server talk to one runtime contract. They do not each reinvent a separate Traverse runtime in their language. When you call a capability from npm, crates.io, or an MCP client, you are asking that runtime to discover → execute → trace against a known contract.

    -

    Shared means the contract and the host ABI. It does not mean every package ships the same runtime.wasm bytes. traverse-embedder-web@0.14.0 loads the bundle’s digest-checked runtime/runtime.wasm. traverse-embedder@0.14.0 links traverse-runtime natively and ships no separate runtime-WASM file. The walk-through is one shared runtime, two loading paths.

    +

    Shared means the contract and the host ABI. It does not mean every package ships the same runtime.wasm bytes. traverse-embedder-web@0.15.0 loads the bundle’s digest-checked runtime/runtime.wasm. traverse-embedder@0.15.0 links traverse-runtime natively and ships no separate runtime-WASM file. The walk-through is one shared runtime, two loading paths.

    Honest consumers today

      -
    • JS/TS — published npm traverse-embedder-web@0.14.0
      • -
    • Rust — published crates.io traverse-embedder@0.14.0
      • +
    • JS/TS — published npm traverse-embedder-web@0.15.0
      • +
    • Rust — published crates.io traverse-embedder@0.15.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 — published, pre-1.0, marked In progress, not Certified. Swift xcframework on swift-host-v* tags; Kotlin com.traverse-framework:traverse-embedder 0.14.0 on Maven Central; .NET TraverseEmbedder 0.14.0 on nuget.org.
      • +
    • Swift / Kotlin / .NET — published, pre-1.0, marked In progress, not Certified. Swift xcframework on swift-host-v* tags; Kotlin com.traverse-framework:traverse-embedder 0.15.0 on Maven Central; .NET TraverseEmbedder 0.15.0 on nuget.org.

    Edge is planned. Cloud placement is an explicit non-goal for v0.1. Before assuming a host works, read Platforms and what is real today.

    diff --git a/src/pages/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.astro b/src/pages/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.astro index 69c2fbc..aff8788 100644 --- a/src/pages/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.astro +++ b/src/pages/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'What is the difference between an exact capability pin and a version range?', acceptedAnswer: { '@type': 'Answer', - text: 'A version range such as ^1.2.0 resolves to the highest active version that satisfies it and skips deprecated and revoked versions. An exact pin names one version. Under registry spec 005 and decision 127, that pin still resolves after deprecation or revocation and carries a status. Published traverse-registry 0.27.0 does both: range resolution skips deprecated and revoked versions, and exact-pin resolution returns the record with lifecycle status and revocation (registry#632; registry#631 is closed). Traverse v0.14.0 still pins =0.25.0, which does not. Runtime refusal is traverse#1598 and is not shipped.', + text: 'A version range such as ^1.2.0 resolves to the highest active version that satisfies it and skips deprecated and revoked versions. An exact pin names one version. Under registry spec 005 and decision 127, that pin still resolves after deprecation or revocation and carries a status. Published traverse-registry 0.28.0 does both, continuing the 0.27.0 behavior (registry#632; registry#631 is closed; 0.28.0 is registry#636). Traverse v0.15.0 pins =0.28.0. v0.14.0 pinned =0.25.0, which did not return revoked records. Runtime refusal is traverse#1598 and is not shipped.', }, }], }); @@ -24,7 +24,7 @@ const relatedLinks = [ --- Short answer: a range such as ^1.2.0 asks for the highest active version that satisfies it. An exact pin names one version string. Under registry spec 005 and decision 127, deprecation and revocation change the range result and leave the exact pin resolvable, with a status attached.

    What a range does

    -

    Spec 005 says range resolution skips deprecated versions. Decision-log entry 127, question 11, says range resolution skips revoked versions too. Published traverse-registry 0.27.0 does both. If every match is deprecated or revoked, it errors instead of returning one. Traverse v0.14.0 still pins =0.25.0. That older crate skips deprecated only and has no revoked type.

    +

    Spec 005 says range resolution skips deprecated versions. Decision-log entry 127, question 11, says range resolution skips revoked versions too. Published traverse-registry 0.28.0 does both, as 0.27.0 did. If every match is deprecated or revoked, it errors instead of returning one. Traverse v0.15.0 pins =0.28.0. v0.14.0 pinned =0.25.0, which skips deprecated only and has no revoked type.

    What an exact pin does

    Spec 005 says exact-pin resolution ignores the deprecated flag and succeeds if the version exists. Decision 127 says a revoked exact pin still resolves and carries a machine-readable do-not-run signal. The runtime, not the registry, is supposed to decide whether to run it.

    -

    In 0.27.0, exact-pin resolution returns the record with lifecycle status and, when revoked, the revocation record, so the consumer can fail closed. The fix merged as registry#632. registry#631 is closed. crates.io published 0.27.0 on 8 October 2026 (tag v0.27.0).

    +

    Since 0.27.0, exact-pin resolution returns the record with lifecycle status and, when revoked, the revocation record, so the consumer can fail closed. 0.28.0 keeps that. The fix merged as registry#632. registry#631 is closed. crates.io published 0.27.0 on 8 October 2026 (tag v0.27.0) and 0.28.0 on 13 October 2026 (registry#636).

    What this is not

    -

    Hosts do not keep a separate version line. traverse-embedder-web, traverse-embedder, and traverse-mcp are clients of one runtime.wasm. The pin is a registry fact. Whether the runtime refuses a revoked pin is traverse#1598, not shipped. The narrative walkthrough is you don't edit a published capability.

    +

    Hosts do not keep a separate version line. traverse-embedder-web, traverse-embedder, and traverse-mcp are clients of one runtime.wasm. The pin is a registry fact. Whether the runtime refuses a revoked capability pin is traverse#1598, still not shipped in v0.15.0. The narrative walkthrough is you don't edit a published capability.

     diff --git a/src/pages/questions/what-is-traverse.astro b/src/pages/questions/what-is-traverse.astro index 3e9cef7..e2d7770 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.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.\"}}]}"; +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.15.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.15.0 under the Apache 2.0 license.\"}}]}"; --- -

    Short answer: discover → execute → trace, on one shared runtime.wasm. Published exact-ref execute is native Rust, the web embedder, and Swift ExactModelHost. Kotlin and .NET ExactModelHost are on traverse main and are not in the published 0.14.0 packages, so Maven Central and nuget.org still cannot run exact-ref. Pin by digest and signature; never treat a naked URL as identity.

    +

    Short answer: discover → execute → trace, on one shared runtime.wasm. As of v0.15.0, published exact-ref execute is native Rust, the web embedder, Swift, Kotlin, and .NET. Pin by digest and signature. A naked URL is not identity. No host is Certified under Spec 529.

    -

    Honest matrix (checked 9 October 2026)

    +

    Honest matrix (checked 14 October 2026)

      -
    • Native Rust — exact-ref execute shipped in the v0.14.0 product cut (ExactModelHostConnector).
      • -
    • Web — published traverse-embedder-web@0.14.0 executes exact-ref (ExactModelBrowserHost).
      • -
    • Swift — ExactModelHost is in the published xcframework swift-host-v0.14.0-4, which Package.swift pins. The first ExactModelHost xcframework was swift-host-v0.14.0-1 (#1579). Distribution is GitHub Release + SPM binary target — not a CocoaPods / Swift Package Index package.
      • -
    • Kotlin — ExactModelHost is on traverse main (#1580, closed). Maven Central com.traverse-framework:traverse-embedder is still 0.14.0 (0.13.0 and 0.14.0 only; 0.14.0 published 2026-09-29, before the host). That package does not execute exact-ref.
      • -
    • .NET — ExactModelHost is on traverse main (#1602, closed). nuget.org TraverseEmbedder is still 0.14.0 (0.13.0 and 0.14.0 only). That package does not execute exact-ref.
      • -
    • Next package cuts — #1651. Until those publish, resolving the 0.14.0 Kotlin or .NET package does not run exact-ref.
      • +
    • Native Rust — ExactModelHostConnector in the v0.15.0 crates. model_usage is required.
      • +
    • Web — published traverse-embedder-web@0.15.0 executes exact-ref (ExactModelBrowserHost). Pass modelUsage whenever pins exist.
      • +
    • Swift — ExactModelHost is in the published xcframework swift-host-v0.15.0. Package.swift on main pins it (#1675). The v0.15.0 tag's Package.swift still pointed at swift-host-v0.14.0-4. Distribution is GitHub Release + SPM binary target.
      • +
    • Kotlin — Maven Central com.traverse-framework:traverse-embedder 0.15.0 includes ExactModelHost (#1580, #1651 closed). The 0.14.0 AAR did not.
      • +
    • .NET — nuget.org TraverseEmbedder 0.15.0 includes ExactModelHost (#1602, #1651 closed). The 0.14.0 package did not. Native engine RIDs in the release: win-x64, win-arm64, linux-x64.
    +

    Rights, ONNX, and Core ML

    +

    Every host enforces model rights. Declaring model_usage is breaking: omit it and the call fails closed with usage_undeclared. Third-party ONNX models can be packaged, signed, and verified with traverse-cli model. Apple hosts can opt in to a signed Core ML variant; the default placement stays wasm-cpu. Evidence so far is macOS cargo test plus the Decision 113 iPhone spike. Governed-path iPhone evidence is traverse#1630, still open.

    +

    Signing honesty

    -

    Packages use schema 2.0.0 + detached Ed25519 model.sig.json. Host-owned trust roots gate register_package / registerPackage. The first trained package digits-mlp-1.0.0 is signed with a test-only key. Production custody, rotation, and revocation are tracked as #1567 — see Is production model signing ready?.

    +

    Packages use schema 2.0.0 and later, plus detached Ed25519 model.sig.json. Host-owned trust roots gate register_package / registerPackage. The first trained package digits-mlp-1.0.0 is signed with a test-only key. Production custody, rotation, and revocation are still #1567 — see Is production model signing ready?.

    What this is not

    -

    Not a generic ONNX runner. Not a claim that every language embedder already executes exact-ref. Not Spec 026 / model-rights enforcement as shipped product. Deeper loop: What is exact-ref model execution? · Embedder notes: v0.14.0: what changed for embedders.

    +

    Not a claim that any host is Certified. Not a web, Android, or desktop GPU adapter. Not Spec 026 registry-capability revocation, which is still traverse#1598. Deeper loop: What is exact-ref model execution?.

     diff --git a/src/pages/roadmap.astro b/src/pages/roadmap.astro index e11ac03..aec64b9 100644 --- a/src/pages/roadmap.astro +++ b/src/pages/roadmap.astro @@ -1,7 +1,7 @@ --- import SubpageLayout from '@layouts/SubpageLayout.astro'; -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
    "; +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.15.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
    Immutable 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.14.0 + v0.15.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 f2215dc..f036be1 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.14.0 + v0.15.0 pre-1.0 Apache 2.0
    @@ -110,7 +110,7 @@ const _body = `

    No Python SDK. Shell out to traverse-cli capability-package execute (stdlib subprocess). See Python →

    -

    Native Swift, Kotlin, and .NET embedders are published and pre-1.0: Swift ships a wasmi xcframework on swift-host-v* host tags, Kotlin is com.traverse-framework:traverse-embedder 0.14.0 on Maven Central, and .NET is TraverseEmbedder 0.14.0 on nuget.org. They are marked In progress. No host is Certified under Spec 529. Check Platforms before assuming a target is shipped.

    +

    Native Swift, Kotlin, and .NET embedders are published and pre-1.0: Swift ships a wasmi xcframework on swift-host-v0.15.0 (Package.swift on main pins it), Kotlin is com.traverse-framework:traverse-embedder 0.15.0 on Maven Central, and .NET is TraverseEmbedder 0.15.0 on nuget.org. They are marked In progress. No host is Certified under Spec 529. Signed exact-ref models run on those hosts as well as native Rust and the browser. Check Platforms before assuming a target is shipped.

    @@ -129,7 +129,8 @@ const _body = `
    Honesty

    Pre-1.0. No invented customers.

    -

    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.

    +

    Traverse v0.15.0 runs signed exact-ref model packages on native Rust, the browser, Swift, Kotlin/Android, and .NET. Every one of those hosts enforces model rights: an app with exact_model_dependencies must declare model_usage or the call fails closed. Third-party ONNX models can be packaged, signed, and verified with traverse-cli model. Apple hosts can opt in to a signed Core ML variant; the default placement is still wasm-cpu. Evidence so far is macOS cargo test plus the Decision 113 iPhone spike. Governed-path iPhone evidence is open (traverse#1630). digits-mlp-1.0.0 is still signed with a test-only key (#1567).

    +

    Traverse is open-source research engineering under Apache 2.0, currently v0.15.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.

    diff --git a/src/scripts/discover-generate.js b/src/scripts/discover-generate.js index f8089ef..8362a0a 100644 --- a/src/scripts/discover-generate.js +++ b/src/scripts/discover-generate.js @@ -33,7 +33,8 @@ import { const FIXTURE_WASM_B64 = 'AGFzbQEAAAABCQFgBH9/f38BfwMCAQAFAwEAAgcaAgZtZW1vcnkCAA1tb2RlbF9leGVjdXRlAAAK9AEB8QEBB38gAUEMSQRAQX8PCyAAKAIIIQQgAEEMaiEFQQwgBGogAUsEQEF/DwtBACEIQQAhBgJAA0AgBkECaiAESw0BIAUgBmotAABB6ABGIAUgBkEBamotAABB6QBGcQRAQQEhCAwCCyAGQQFqIQYMAAsLIAhBAUYEQEHKuAIhCUEIIQoFQd64AiEJQQMhCgtBDCAKaiADSwRAQX8PCyACQQE7AQAgAkEEOgACIAJBAToAAyACIAo2AgQgAiAKNgIIQQAhBwJAA0AgByAKTw0BIAJBDGogB2ogCSAHai0AADoAACAHQQFqIQcMAAsLQQwgCmoLCyMDAEHAuAILAmhpAEHKuAILCGhpIHRoZXJlAEHeuAILA2htbQCUAQRuYW1lAmIBAAsABmluX3B0cgEGaW5fbGVuAgdvdXRfcHRyAwdvdXRfY2FwBAtwYXlsb2FkX2xlbgULcGF5bG9hZF9wdHIGAWkHAWoIB21hdGNoZWQJCHJlc3BfcHRyCghyZXNwX2xlbgMpAQAEAgtzZWFyY2hfZG9uZQMGc2VhcmNoBwljb3B5X2RvbmUIBGNvcHk='; // The same fixture's signed Spec 138 package files (traverse-embedder-web -// 0.14 admits packages only through registerPackage): the exact bytes of +// admits packages only through registerPackage; 0.15 also requires +// modelUsage whenever pins exist): the exact bytes of // fixtures/models/fixture-responder-1.0.0/model.manifest.json (its SHA-256 // is the pin digest) and its detached Ed25519 model.sig.json. const FIXTURE_MANIFEST_B64 = 'ewogICJzY2hlbWFfdmVyc2lvbiI6ICIyLjAuMCIsCiAgIm1vZGVsX2lkIjogImZpeHR1cmUucmVzcG9uZGVyIiwKICAidmVyc2lvbiI6ICIxLjAuMCIsCiAgIndhc21fZGlnZXN0IjogImJmMDQ3NjBiMTkzN2MyZjJiODEzYjZlMjhmMmZkYzZlMzM0ODMzYzJkZmFkYzFmN2M4NzJmM2YyOGMzNDEyOTQiLAogICJyZWdpc3RyeV9yZWYiOiAicmVnaXN0cnk6Zml4dHVyZS5yZXNwb25kZXJAMS4wLjAiLAogICJleGVjdXRhYmxlX2Zvcm1hdCI6ICJ0cmF2ZXJzZS1tb2RlbC13YXNtIiwKICAiYWJpX3ZlcnNpb24iOiAxLAogICJpbnB1dF9zY2hlbWFfcmVmIjogInNjaGVtYTpicmlkZ2VkLWdlbmVyYXRlLWluIiwKICAiaW5wdXRfc2NoZW1hX3ZlcnNpb24iOiAiMS4wLjAiLAogICJvdXRwdXRfc2NoZW1hX3JlZiI6ICJzY2hlbWE6YnJpZGdlZC1nZW5lcmF0ZS1vdXQiLAogICJvdXRwdXRfc2NoZW1hX3ZlcnNpb24iOiAiMS4wLjAiLAogICJyaWdodHMiOiB7CiAgICAibGljZW5zZV9pZCI6ICJBcGFjaGUtMi4wIiwKICAgICJhdHRyaWJ1dGlvbiI6ICJUcmF2ZXJzZSBTcGVjIDA0NS8xMzggYnJpZGdlIGNvbmZvcm1hbmNlIGZpeHR1cmUiLAogICAgInJlZGlzdHJpYnV0aW9uIjogInRlc3Qtb25seTsgbm90IGZvciBwcm9kdWN0aW9uIHJlZGlzdHJpYnV0aW9uIGNsYWltcyIsCiAgICAiY29tbWVyY2lhbF91c2UiOiAiYWxsb3dlZCIsCiAgICAic291cmNlX3VybCI6ICJodHRwczovL2dpdGh1Yi5jb20vdHJhdmVyc2UtZnJhbWV3b3JrL1RyYXZlcnNlL3RyZWUvbWFpbi9maXh0dXJlcy9tb2RlbHMvZml4dHVyZS1yZXNwb25kZXItMS4wLjAiCiAgfSwKICAic3VwcG9ydGVkX3Byb2ZpbGVzIjogWwogICAgIndhc20tY3B1IgogIF0sCiAgIm1heF9tZW1vcnlfYnl0ZXMiOiAxMzEwNzIsCiAgIm1heF9mdWVsIjogMTAwMDAwMCwKICAibWF4X2lucHV0X2J5dGVzIjogNDA5NiwKICAibWF4X291dHB1dF9ieXRlcyI6IDQwOTYsCiAgIm1heF9leGVjdXRpb25fbXMiOiA1MDAwLAogICJvZmZsaW5lX2FsbG93ZWQiOiB0cnVlCn0K'; @@ -75,7 +76,9 @@ export async function runResponderDemo(promptText) { model_id: MODEL_ID, version: MODEL_VERSION, digest, offline_allowed: true, target: PLACEMENT_WASM_CPU, rights: { license_id: 'Apache-2.0', commercial_use: 'allowed' }, }], - { trustedPublicKeysHex: [FIXTURE_TEST_KEY_HEX] }, + // v0.15.0 fails closed with usage_undeclared when pins exist and + // modelUsage is omitted. This demo is not a commercial product. + { trustedPublicKeysHex: [FIXTURE_TEST_KEY_HEX], modelUsage: 'non_commercial' }, ); // Real verification: Ed25519 signature by a trusted key over the exact // manifest bytes, pin digest, WASM digest, rights, target, and limits. diff --git a/tests/discover-generate.test.mjs b/tests/discover-generate.test.mjs index ac4053d..7c01184 100644 --- a/tests/discover-generate.test.mjs +++ b/tests/discover-generate.test.mjs @@ -35,6 +35,7 @@ test('the fixture digests match the real checked-in traverse-framework/traverse test('admission goes through registerPackage with a real signature, not the removed insertVerified', async () => { const gen = await read('src/scripts/discover-generate.js'); assert.match(gen, /registerPackage\(/); + assert.match(gen, /modelUsage:\s*'non_commercial'/); assert.doesNotMatch(gen, /insertVerified/); // The test-only fixture key is labelled as such, never presented as production trust. assert.match(gen, /TEST-ONLY public key/);