From 568b312ef70dbdba80e7264947c49feffa599e2b Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Tue, 6 Oct 2026 21:05:24 +0000 Subject: [PATCH 1/3] =?UTF-8?q?docs(blog):=20Thu=20=E2=80=94=20deprecation?= =?UTF-8?q?=20and=20revocation=20leave=20the=20contract=20in=20place?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the October 8 explainer and three long-tail Q&As on exact pins, host status signals, and how an agent should treat a revoked version at discover time. Wire them into the blog index, questions index, and llms.txt without changing the published embedder pin. Co-authored-by: Enrico Piovesan --- public/llms.txt | 7 +- src/pages/blog/index.astro | 1 + ...you-dont-edit-a-published-capability.astro | 160 ++++++++++++++++++ ...a-revoked-capability-during-discover.astro | 46 +++++ src/pages/questions/index.astro | 3 + ...gnal-on-an-exact-pin-mean-for-a-host.astro | 48 ++++++ ...when-a-capability-version-is-revoked.astro | 4 + ...een-an-exact-pin-and-a-version-range.astro | 44 +++++ 8 files changed, 311 insertions(+), 2 deletions(-) create mode 100644 src/pages/blog/you-dont-edit-a-published-capability.astro create mode 100644 src/pages/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.astro create mode 100644 src/pages/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.astro create mode 100644 src/pages/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.astro diff --git a/public/llms.txt b/public/llms.txt index 9088940..c4b4cd3 100644 --- a/public/llms.txt +++ b/public/llms.txt @@ -44,7 +44,10 @@ Current packages: crates.io at 0.14.0 (pin `traverse-registry` at `=0.25.0` if y - [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; per spec 005 + decision 127 exact pins still resolve with a status signal and the runtime decides (fail closed); crate alignment registry#631, Traverse runtime handling traverse#1598. +- [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; per spec 005 + decision 127 exact pins still resolve with a status signal and the runtime decides (fail closed); crate alignment registry#631, Traverse runtime handling traverse#1598. 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, under spec 005 and decision 127, still resolves with a status. Published `traverse-registry` 0.25.0 skips deprecated only and has no revoked type; registry main exact lookup returns nothing for a non-active record (registry#631, open). +- [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). 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/Kotlin/.NET in-tree only. +- [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 on registry main skips revoked versions. Public `catalog.json` keeps the row with `revoked`. `/discover` skips `deprecated` only. No `revoked.json` on registry main yet. The agent proposes; the runtime decides — and that refusal is traverse#1598, not shipped. - [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. @@ -73,7 +76,7 @@ Current packages: crates.io at 0.14.0 (pin `traverse-registry` at `=0.25.0` if y ## Optional -- [Blog](https://traverse-framework.com/blog.html): engineering write-ups, dated — treat as historical snapshots, not current-state claims. Latest: [Model rights are data, not a README](https://traverse-framework.com/blog/model-rights-are-data.html) (AI model rights from contract to host; publish checks on main, signed registry spec 026 record, host trust roots; runtime enforcement #1598 and prod signing #1567 still open). Also: [Signed model. Exact pin. Bit-identical hosts.](https://traverse-framework.com/blog/signed-exact-ref-digits.html) (v0.14.0 weekly demo; Browser+Node; test-only key). Also: [Domain packs are in scope: print-support](https://traverse-framework.com/blog/print-support-domain-pack.html) (capability pack; none published yet). Also: [v0.14.0: what changed for embedders](https://traverse-framework.com/blog/traverse-0-14-0-what-changed-for-embedders.html) (signed Spec 138; native+web+Swift ExactModelHost exact-ref; test-only digits-mlp key). Also: [Where business logic lives (hosts stay thin)](https://traverse-framework.com/blog/where-business-logic-lives.html). Weekly demo: [Same WASM. Browser and Node match. Agent still can’t freestyle.](https://traverse-framework.com/blog/same-wasm-multi-host.html) (v0.13.0 multi-host). Prior: [agent freestyle → blocked](https://traverse-framework.com/blog/agent-freestyle-blocked.html). Authoring: [You don't need Rust to publish a capability](https://traverse-framework.com/blog/you-dont-need-rust-to-publish-a-capability.html). +- [Blog](https://traverse-framework.com/blog.html): engineering write-ups, dated — treat as historical snapshots, not current-state claims. Latest: [You don't edit a published capability. You mark it.](https://traverse-framework.com/blog/you-dont-edit-a-published-capability.html) (deprecation and revocation leave the contract in place; ranges skip the marker; exact pins still resolve under spec 005 and decision 127 with a status the runtime is supposed to refuse; that refusal is traverse#1598, not shipped; crate alignment registry#631; crates.io `traverse-registry` still 0.25.0). Also: [Model rights are data, not a README](https://traverse-framework.com/blog/model-rights-are-data.html) (AI model rights from contract to host; publish checks on main, signed registry spec 026 record, host trust roots; runtime enforcement #1598 and prod signing #1567 still open). Also: [Signed model. Exact pin. Bit-identical hosts.](https://traverse-framework.com/blog/signed-exact-ref-digits.html) (v0.14.0 weekly demo; Browser+Node; test-only key). Also: [Domain packs are in scope: print-support](https://traverse-framework.com/blog/print-support-domain-pack.html) (capability pack; none published yet). Also: [v0.14.0: what changed for embedders](https://traverse-framework.com/blog/traverse-0-14-0-what-changed-for-embedders.html) (signed Spec 138; native+web+Swift ExactModelHost exact-ref; test-only digits-mlp key). Also: [Where business logic lives (hosts stay thin)](https://traverse-framework.com/blog/where-business-logic-lives.html). Weekly demo: [Same WASM. Browser and Node match. Agent still can’t freestyle.](https://traverse-framework.com/blog/same-wasm-multi-host.html) (v0.13.0 multi-host). Prior: [agent freestyle → blocked](https://traverse-framework.com/blog/agent-freestyle-blocked.html). Authoring: [You don't need Rust to publish a capability](https://traverse-framework.com/blog/you-dont-need-rust-to-publish-a-capability.html). - [Discover](https://traverse-framework.com/discover.html): a live browser demo that pulls the public registry and executes a reviewed plan locally. Read [what it proves](https://traverse-framework.com/blog/what-discover-proves.html) before quoting it. - [Compare: vs microservices](https://traverse-framework.com/compare/vs-microservices.html), [vs serverless](https://traverse-framework.com/compare/vs-serverless.html), [vs function calling](https://traverse-framework.com/compare/vs-function-calling.html), [vs agent runtimes](https://traverse-framework.com/compare/vs-agent-runtimes.html), [vs WASM runtimes](https://traverse-framework.com/compare/vs-wasm-runtimes.html), [vs cross-platform frameworks](https://traverse-framework.com/compare/vs-cross-platform-frameworks.html) - [About](https://traverse-framework.com/about.html): project history and motivation. diff --git a/src/pages/blog/index.astro b/src/pages/blog/index.astro index 334849e..0e1473f 100644 --- a/src/pages/blog/index.astro +++ b/src/pages/blog/index.astro @@ -2,6 +2,7 @@ import SubpageLayout from '@layouts/SubpageLayout.astro'; const posts = [ + { href: '/blog/you-dont-edit-a-published-capability.html', title: "You don't edit a published capability. You mark it.", desc: 'Featured · Oct 8 · Deprecation and revocation leave the contract in place. Ranges skip the marker; exact pins still resolve under spec 005 and decision 127. Runtime refusal is traverse#1598, not shipped. Crate alignment is registry#631.' }, { href: '/blog/model-rights-are-data.html', title: 'Model rights are data, not a README', desc: 'Featured · Oct 6 · AI model rights from contract to host: offline publish checks, signed registry rights record, host trust roots, and what is still open.' }, { href: '/blog/signed-exact-ref-digits.html', title: 'Signed model. Exact pin. Bit-identical hosts.', desc: 'Featured · Weekly demo: signed digits-mlp-1.0.0 exact-ref package, same bytes on Browser + Node via ExactModelBrowserHost; tamper fail-closed (digest_mismatch). Traverse v0.14.0. Test-only key.' }, { href: '/blog/print-support-domain-pack.html', title: 'Domain packs are in scope: print-support without an app rewrite', desc: 'Featured · Manufacturing-shaped capability pack under discover→execute→trace; apps-not-ready ≠ no domain packs; hosts stay thin; none of the print.* capabilities published yet. registry#596 · #597–#604 · Discussion #1540.' }, diff --git a/src/pages/blog/you-dont-edit-a-published-capability.astro b/src/pages/blog/you-dont-edit-a-published-capability.astro new file mode 100644 index 0000000..0b4fbf8 --- /dev/null +++ b/src/pages/blog/you-dont-edit-a-published-capability.astro @@ -0,0 +1,160 @@ +--- +import SubpageLayout from '@layouts/SubpageLayout.astro'; + +const _body = ` +
+
+
+ ← Blog + October 8, 2026 + Registry + Lifecycle + Honesty +
+

You don't edit a published capability. You mark it.

+
+ By Enrico Piovesan + 7 min read +
+
+
+ +
+
+ +
+ +

An agent finds a versioned capability, proposes a call, and the runtime either runs that known artifact or refuses. That is the loop: discover → execute → trace. The agent proposes; the runtime decides. Deprecation and revocation are how the registry tells that loop a published version should stop being the one new callers land on, without rewriting the bytes that already shipped.

+ +
+ Authors still don't write the artifact by hand. The usual path is skill-first, via traverse-capability-author: interview, registry check, contract, WASM, human-reviewed pull request. Under the hood it is still Rust compiled to WASM. Marking a version later is a registry change, not a new language and not a second runtime. Browser, native, CLI, and MCP are clients of one shared runtime.wasm. +
+ +

Discover: a range walks past the marker

+ +

A version range such as ^1.2.0 means the highest active version that satisfies it. Registry spec 005 (005-yank-deprecation) says range resolution skips a deprecated version. Decision-log entry 127, question 11, says the same for revocation: range resolution skips a revoked version. If nothing active matches, resolution fails instead of handing back the marked one.

+ +

That is the discover rule an agent should follow. Propose a version the range still treats as active. Leave a revoked row out of the plan even though the contract text is still in the tree. The longer answer is how an agent should react to a revoked capability during discover.

+ +

Two surfaces already skip something, and they are not the same skip:

+
    +
  • On registry main, the traverse-registry workspace (0.27.0, not the crates.io release) skips both deprecated and revoked records during range resolution. When every match is marked, the error says only deprecated or revoked versions satisfy the range.
    • +
  • The public /discover page builds its snapshot from live catalog.json and drops rows whose deprecated flag is true. It does not read the catalog's revoked flag. That flag is on every catalog entry, and it was false on all of them when this was checked. The page has not demonstrated a revoked skip.
    • +
+ +

The marker is a sibling file

+ +

A published contract.json and its artifact are immutable. Spec 005 says a yank adds deprecated.json beside the contract and does not modify contract.json. The file carries deprecated, a short reason, and deprecated_at. The index build sets deprecated: true. The public catalog copies that flag.

+ +

Revocation is the stronger marker, from registry spec 026 and decision 127. It adds revoked.json with reason, evidence_url, and revoked_at. The contract and the artifact stay untouched. The index keeps the entry with status: "revoked", the revocation record, and the full rights record, and it must not present that version as active. The public catalog projects the same fact as revoked: true plus a revocation object.

+ +

Deprecation is already in use. Forty versions on registry main have a deprecated.json, including placeholder stubs and fixed-output fixtures replaced by a later version. There is no revoked.json in the tree. The shape is specified, and the index and catalog builders know how to project it. No published version has been revoked.

+ +

An exact pin is a different question

+ +

Spec 005 is explicit about deprecation: exact-pin resolution ignores the flag and succeeds if the version exists. Decision 127 keeps that guarantee for revocation. An exact pin still resolves, and it carries a machine-readable do-not-run signal. The registry is not supposed to make a pinned consumer disappear. The runtime decides whether to execute. The spec 026 consumer doc says the runtime should refuse. See exact pin versus version range and what that status signal means for a host.

+ +

That is the spec. It is not what the crate does today.

+ +

The published traverse-registry on crates.io is 0.25.0 (29 September 2026). Traverse pins =0.25.0. That release skips deprecated records on both range and exact lookup, and it has no revoked type. Spec 026's status and revocation fields landed later, on registry main, in the unpublished 0.27.0 workspace.

+ +

On that main branch, exact lookup returns only an active record. A deprecated or revoked exact pin comes back as nothing. The test resolution_never_selects_a_revoked_record asserts that. It contradicts spec 005 and decision 127. Returning the record with its status, then publishing the crate, is registry#631. It is open.

+ +

Execute: the runtime is supposed to refuse

+ +

Once a host actually holds a revoked record, the decision is not the agent's. Hosts are clients. traverse-embedder-web (JS/TS), traverse-embedder (Rust), and traverse-mcp call the same runtime.wasm. Python has no SDK; a Python program shells out to traverse-cli capability-package execute. Swift, Kotlin, and .NET embedders exist in-tree and are not published packages.

+ +

Decision 127 leaves enforcement with Traverse: the pin resolves, the signal says do not run, and the runtime decides. Refusing the run — fail closed, rather than executing a revoked artifact — is traverse#1598. It is open. It is not in the v0.14.0 release. Until it ships, do not describe the runtime as already refusing a revoked pin.

+ +

Trace

+ +

A trace is the record of what the runtime decided. There is no shipped trace for "this pin was revoked, so the run was refused," because the runtime does not honor revoked yet. When #1598 lands, that refusal belongs in the trace the same way any other deny does. It is not a field to cite today.

+ +

What is shipped (checked 6 October 2026)

+ +

Shipped, in the registry repo:

+
    +
  • deprecated.json, the index deprecated flag, and real yanked versions on main.
    • +
  • The revoked.json shape, index status, and catalog revoked / revocation fields. No version is revoked yet.
    • +
  • Range resolution on registry main that skips deprecated and revoked records.
    • +
+ +

Open:

+
    +
  • Exact pins returning the record plus its status, and the next traverse-registry publish. registry#631. crates.io is still 0.25.0.
    • +
  • The runtime and traverse-cli honoring revoked. traverse#1598. Not shipped.
    • +
+ +

The short version for an agent: at discover time, do not propose a deprecated or revoked version as if it were active. At execute time, the runtime is the one that is supposed to refuse, and that part is still an open ticket. The citeable page this post walks through is what happens when a capability version is deprecated or revoked.

+ +
+ + + +
+
+ +`; +--- + + + + 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 new file mode 100644 index 0000000..f6d2050 --- /dev/null +++ b/src/pages/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.astro @@ -0,0 +1,46 @@ +--- +import QuestionLayout from '@layouts/QuestionLayout.astro'; + +const jsonLd = JSON.stringify({ + '@context': 'https://schema.org', + '@type': 'FAQPage', + mainEntity: [{ + '@type': 'Question', + 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 on registry main 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 exists on registry main today. The runtime refusal on an exact pin is traverse#1598 and is not shipped. The agent proposes; the runtime decides.', + }, + }], +}); + +const relatedLinks = [ + { href: '/blog/you-dont-edit-a-published-capability.html', label: "You don't edit a published capability. You mark it." }, + { href: '/questions/what-happens-when-a-capability-version-is-revoked.html', label: 'What happens when a capability version is deprecated or revoked?' }, + { href: '/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.html', label: 'Exact pin vs version range' }, + { href: '/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.html', label: 'What does a status signal on an exact pin mean for a host?' }, + { href: '/questions/what-does-discover-execute-trace-mean.html', label: 'What does discover → execute → trace mean?' }, + { href: '/questions/what-does-agent-proposes-runtime-decides-mean.html', label: 'What does “the agent proposes; the runtime decides” mean?' }, +]; +--- + +

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. On registry main the workspace resolver already 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.

+

The published traverse-registry 0.25.0, which Traverse pins, has no revoked type. It skips deprecated ranges only. Do not describe today's published crate as already filtering revoked versions.

+ +

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. No revoked.json exists on registry main, and the live catalog's revoked flag was false on every entry when this was checked, 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.

+

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/index.astro b/src/pages/questions/index.astro index 329d7df..8819d1d 100644 --- a/src/pages/questions/index.astro +++ b/src/pages/questions/index.astro @@ -35,6 +35,9 @@ const groups = [ ['does-capability-publish-validate-model-attribution.html', 'Does capability publish validate model attribution before the registry write?'], ['does-the-registry-record-model-rights.html', 'Does the Traverse registry record model licenses and usage rights?'], ['what-happens-when-a-capability-version-is-revoked.html', 'What happens when a registry capability version is deprecated or revoked?'], + ['what-is-the-difference-between-an-exact-pin-and-a-version-range.html', 'What is the difference between an exact capability pin and a version range?'], + ['what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.html', 'What does a status signal on an exact pin mean for a host?'], + ['how-should-an-agent-react-to-a-revoked-capability-during-discover.html', 'How should an agent react to a revoked capability during discover?'], ['what-does-human-review-mean-for-a-capability-pr.html', 'What does human review mean for a capability PR?'], ['how-do-i-verify-a-signed-capability-artifact.html', 'How do I verify a signed Traverse capability artifact?'], ['how-do-i-review-a-capability-pr-as-a-maintainer.html', 'How do I review a capability PR as a maintainer?'], diff --git a/src/pages/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.astro b/src/pages/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.astro new file mode 100644 index 0000000..822445d --- /dev/null +++ b/src/pages/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.astro @@ -0,0 +1,48 @@ +--- +import QuestionLayout from '@layouts/QuestionLayout.astro'; + +const jsonLd = JSON.stringify({ + '@context': 'https://schema.org', + '@type': 'FAQPage', + mainEntity: [{ + '@type': 'Question', + name: 'What does a status signal on an exact pin mean for a host?', + acceptedAnswer: { + '@type': 'Answer', + text: 'It is a lifecycle fact the shared runtime is supposed to read before it runs the artifact. Index status is active, deprecated, or revoked. A revoked exact pin, under decision 127, still resolves and carries a machine-readable do-not-run signal; the runtime should refuse (fail closed). That refusal is traverse#1598 and is not shipped. The published traverse-registry 0.25.0 has no revoked type. Registry main returns nothing from exact lookup for a non-active record (registry#631). Hosts are clients of one runtime.wasm, not separate runtimes.', + }, + }], +}); + +const relatedLinks = [ + { href: '/blog/you-dont-edit-a-published-capability.html', label: "You don't edit a published capability. You mark it." }, + { href: '/questions/what-happens-when-a-capability-version-is-revoked.html', label: 'What happens when a capability version is deprecated or revoked?' }, + { href: '/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.html', label: 'Exact pin vs version range' }, + { href: '/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.html', label: 'How should an agent react to a revoked capability during discover?' }, + { href: '/questions/what-is-one-shared-runtime-wasm.html', label: 'What is one shared runtime.wasm?' }, +]; +--- + +

Short answer: it is a lifecycle fact the runtime is supposed to read before it runs the artifact. It is not a second runtime, and the Traverse runtime does not honor it yet.

+ +

What the signal is

+

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 embedders are in-tree only, not published packages. The agent can propose the pin. The runtime is supposed to decide.

+ +

What a host can observe today

+
    +
  • Published crate 0.25.0 (what Traverse pins): no status or revocation type. Exact lookup of a deprecated version returns nothing.
    • +
  • Registry main, workspace 0.27.0, not published: records can carry status and revocation, but exact lookup still returns nothing unless the record is active. That is the drift in registry#631.
    • +
  • Runtime refusal: traverse#1598 is open. It is not in v0.14.0.
    • +
+

A host must not assume that an exact pin of a revoked version comes back today as a record plus a deny. That is the approved contract. The crate and the runtime do not implement it yet. Background: you don't edit a published capability.

+ 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 1c096fe..8677c7f 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 @@ -15,6 +15,10 @@ const jsonLd = JSON.stringify({ }); const relatedLinks = [ + { href: '/blog/you-dont-edit-a-published-capability.html', label: "You don't edit a published capability. You mark it." }, + { href: '/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.html', label: 'What is the difference between an exact pin and a version range?' }, + { href: '/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.html', label: 'What does a status signal on an exact pin mean for a host?' }, + { href: '/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.html', label: 'How should an agent react to a revoked capability during discover?' }, { href: '/questions/what-is-contract-versioning.html', label: 'What is contract versioning in Traverse?' }, { href: '/questions/does-the-registry-record-model-rights.html', label: 'Does the registry record model licenses and usage rights?' }, { href: '/questions/what-is-the-capability-registry.html', label: 'What is the capability registry?' }, 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 new file mode 100644 index 0000000..9f9d53a --- /dev/null +++ b/src/pages/questions/what-is-the-difference-between-an-exact-pin-and-a-version-range.astro @@ -0,0 +1,44 @@ +--- +import QuestionLayout from '@layouts/QuestionLayout.astro'; + +const jsonLd = JSON.stringify({ + '@context': 'https://schema.org', + '@type': 'FAQPage', + mainEntity: [{ + '@type': 'Question', + 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. The published traverse-registry 0.25.0 skips deprecated on both paths and has no revoked type. Registry main (workspace 0.27.0, not published) also returns nothing for an exact pin to a deprecated or revoked record. That exact-pin drift is registry#631, open.', + }, + }], +}); + +const relatedLinks = [ + { href: '/blog/you-dont-edit-a-published-capability.html', label: "You don't edit a published capability. You mark it." }, + { href: '/questions/what-happens-when-a-capability-version-is-revoked.html', label: 'What happens when a capability version is deprecated or revoked?' }, + { href: '/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.html', label: 'What does a status signal on an exact pin mean for a host?' }, + { href: '/questions/how-should-an-agent-react-to-a-revoked-capability-during-discover.html', label: 'How should an agent react to a revoked capability during discover?' }, + { href: '/questions/what-is-contract-versioning.html', label: 'What is contract versioning in Traverse?' }, +]; +--- + +

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. On registry main, the workspace resolver (0.27.0, not published) does both. If every match is deprecated or revoked, it errors instead of returning one. The published traverse-registry 0.25.0, which Traverse pins with =0.25.0, skips deprecated only. That release 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.

+

On registry main the exact lookup returns only an active record, so a deprecated or revoked pin comes back empty. That contradicts the spec. The fix and the next crate publish are registry#631, still open. crates.io is still 0.25.0.

+ +

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.

+ From 671a5dffedc88a04e0c4d9513de6f07553f19f32 Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Thu, 8 Oct 2026 21:59:27 +0000 Subject: [PATCH 2/3] docs(site): truth-pass Thu lifecycle post to traverse-registry 0.27.0 registry#631 is closed (fix registry#632). Exact pins in published traverse-registry 0.27.0 return lifecycle status; range resolution still skips deprecated and revoked. Runtime refusal stays open on traverse#1598, and v0.14.0 still pins =0.25.0. Native embedders match the published Maven, nuget, and swift-host package facts. Co-authored-by: Enrico Piovesan --- public/llms.txt | 16 +++++----- src/pages/blog/index.astro | 4 +-- ...se-0-14-0-what-changed-for-embedders.astro | 4 +-- .../blog/what-is-real-today-start-here.astro | 2 +- ...you-dont-edit-a-published-capability.astro | 30 +++++++++---------- src/pages/changelog.astro | 2 +- src/pages/faq.astro | 2 +- src/pages/index.astro | 6 ++-- ...r-dotnet-embedders-run-exact-ref-yet.astro | 6 ++-- .../does-traverse-have-a-python-sdk.astro | 2 +- ...a-revoked-capability-during-discover.astro | 8 ++--- ...gnal-on-an-exact-pin-mean-for-a-host.astro | 14 ++++----- .../what-does-traverse-not-claim-yet.astro | 6 ++-- ...when-a-capability-version-is-revoked.astro | 14 ++++----- .../what-is-exact-ref-model-execution.astro | 2 +- .../what-is-one-shared-runtime-wasm.astro | 6 ++-- ...een-an-exact-pin-and-a-version-range.astro | 8 ++--- ...ch-hosts-run-signed-exact-ref-models.astro | 4 +-- src/pages/what-is-real-today.astro | 2 +- 19 files changed, 68 insertions(+), 70 deletions(-) diff --git a/public/llms.txt b/public/llms.txt index 9b24788..f640787 100644 --- a/public/llms.txt +++ b/public/llms.txt @@ -1,6 +1,6 @@ # Traverse -> Traverse is a governed capability runtime for portable business logic. Value loop: **discover → execute → trace**. Usual authoring is skill-first plain English via `traverse-capability-author` (contract → WASM → human-reviewed PR); manual authoring still uses Rust→WASM — you do **not** need to write Rust for the usual path. One shared `runtime.wasm`; browser, native desktop, CLI, and MCP are clients/embedders, not different Traverse runtimes. Shipped consumers today: JS/TS (`traverse-embedder-web`), Rust (`traverse-embedder`), agents via `traverse-mcp`; Python shells out to `traverse-cli capability-package execute` (**no Python SDK**). Swift/Kotlin/.NET are in-tree only (not certified public packages); edge is planned; cloud placement is an explicit non-goal for v0.1 — see /platforms.html and /what-is-real-today.html. Apache 2.0, pre-1.0 (v0.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**). 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. - Start here (narrative): https://traverse-framework.com/blog/what-is-real-today-start-here.html - How do I start with Traverse as an agent?: https://traverse-framework.com/questions/how-do-i-start-with-traverse-as-an-agent.html - What does Traverse not claim yet?: https://traverse-framework.com/questions/what-does-traverse-not-claim-yet.html @@ -9,7 +9,7 @@ Traverse is not a web framework, an agent-orchestration framework, or a general microservices platform. It governs one thing well: a single piece of business logic that must behave identically and auditably on every host where it actually ships. Specs and registry catalog size are governance hygiene, not the pitch. -Current packages: crates.io at 0.14.0 (pin `traverse-registry` at `=0.25.0` if you consume it directly); npm `traverse-embedder-web@0.14.0`. +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. ## Required reading (agents) @@ -25,7 +25,7 @@ Current packages: crates.io at 0.14.0 (pin `traverse-registry` at `=0.25.0` if y - [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. - [Same WASM. Browser and Node match. Agent still can’t freestyle.](https://traverse-framework.com/blog/same-wasm-multi-host.html): v0.13.0 multi-host — identical `core.authorize@1.2.0` bytes on Browser + Node; agent treasury cheat still denied. - Weekly demos (public write-ups; repo still private): [signed exact-ref digits](https://traverse-framework.com/blog/signed-exact-ref-digits.html) · [same-wasm multi-host](https://traverse-framework.com/blog/same-wasm-multi-host.html) · [agent freestyle → blocked](https://traverse-framework.com/blog/agent-freestyle-blocked.html) · [How do I run the deny demo?](https://traverse-framework.com/questions/how-do-i-run-the-agent-blocked-weekly-demo.html). Note: `traverse-framework/weekly-demos` is **not publicly cloneable yet** (tracked in [.github#30](https://github.com/traverse-framework/.github/issues/30)) — prefer the blogs until that lands. Access-only tree for this week: `weekly-demos/2026-10-02-signed-exact-ref`. -- [Platforms](https://traverse-framework.com/platforms.html): native + browser shipped; Swift/Kotlin/.NET in progress (not packaged); edge planned; cloud non-goal. +- [Platforms](https://traverse-framework.com/platforms.html): native + browser shipped; Swift/Kotlin/.NET published, pre-1.0, In progress (not Certified); edge planned; cloud non-goal. ## Start here @@ -44,10 +44,10 @@ Current packages: crates.io at 0.14.0 (pin `traverse-registry` at `=0.25.0` if y - [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; per spec 005 + decision 127 exact pins still resolve with a status signal and the runtime decides (fail closed); crate alignment registry#631, Traverse runtime handling traverse#1598. 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, under spec 005 and decision 127, still resolves with a status. Published `traverse-registry` 0.25.0 skips deprecated only and has no revoked type; registry main exact lookup returns nothing for a non-active record (registry#631, open). -- [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). 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/Kotlin/.NET in-tree only. -- [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 on registry main skips revoked versions. Public `catalog.json` keeps the row with `revoked`. `/discover` skips `deprecated` only. No `revoked.json` on registry main yet. The agent proposes; the runtime decides — and that refusal 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. - [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. @@ -77,7 +77,7 @@ Current packages: crates.io at 0.14.0 (pin `traverse-registry` at `=0.25.0` if y ## Optional -- [Blog](https://traverse-framework.com/blog.html): engineering write-ups, dated — treat as historical snapshots, not current-state claims. Latest: [You don't edit a published capability. You mark it.](https://traverse-framework.com/blog/you-dont-edit-a-published-capability.html) (deprecation and revocation leave the contract in place; ranges skip the marker; exact pins still resolve under spec 005 and decision 127 with a status the runtime is supposed to refuse; that refusal is traverse#1598, not shipped; crate alignment registry#631; crates.io `traverse-registry` still 0.25.0). Also: [Model rights are data, not a README](https://traverse-framework.com/blog/model-rights-are-data.html) (AI model rights from contract to host; publish checks on main, signed registry spec 026 record, host trust roots; runtime enforcement #1598 and prod signing #1567 still open). Also: [Signed model. Exact pin. Bit-identical hosts.](https://traverse-framework.com/blog/signed-exact-ref-digits.html) (v0.14.0 weekly demo; Browser+Node; test-only key). Also: [Domain packs are in scope: print-support](https://traverse-framework.com/blog/print-support-domain-pack.html) (capability pack; none published yet). Also: [v0.14.0: what changed for embedders](https://traverse-framework.com/blog/traverse-0-14-0-what-changed-for-embedders.html) (signed Spec 138; native+web+Swift ExactModelHost exact-ref; test-only digits-mlp key). Also: [Where business logic lives (hosts stay thin)](https://traverse-framework.com/blog/where-business-logic-lives.html). Weekly demo: [Same WASM. Browser and Node match. Agent still can’t freestyle.](https://traverse-framework.com/blog/same-wasm-multi-host.html) (v0.13.0 multi-host). Prior: [agent freestyle → blocked](https://traverse-framework.com/blog/agent-freestyle-blocked.html). Authoring: [You don't need Rust to publish a capability](https://traverse-framework.com/blog/you-dont-need-rust-to-publish-a-capability.html). +- [Blog](https://traverse-framework.com/blog.html): engineering write-ups, dated — treat as historical snapshots, not current-state claims. Latest: [You don't edit a published capability. You mark it.](https://traverse-framework.com/blog/you-dont-edit-a-published-capability.html) (deprecation and revocation leave the contract in place; ranges skip the marker; exact pins in `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). Also: [Model rights are data, not a README](https://traverse-framework.com/blog/model-rights-are-data.html) (AI model rights from contract to host; publish checks on main, signed registry spec 026 record, host trust roots; runtime enforcement #1598 and prod signing #1567 still open). Also: [Signed model. Exact pin. Bit-identical hosts.](https://traverse-framework.com/blog/signed-exact-ref-digits.html) (v0.14.0 weekly demo; Browser+Node; test-only key). Also: [Domain packs are in scope: print-support](https://traverse-framework.com/blog/print-support-domain-pack.html) (capability pack; none published yet). Also: [v0.14.0: what changed for embedders](https://traverse-framework.com/blog/traverse-0-14-0-what-changed-for-embedders.html) (signed Spec 138; native+web+Swift ExactModelHost exact-ref; test-only digits-mlp key). Also: [Where business logic lives (hosts stay thin)](https://traverse-framework.com/blog/where-business-logic-lives.html). Weekly demo: [Same WASM. Browser and Node match. Agent still can’t freestyle.](https://traverse-framework.com/blog/same-wasm-multi-host.html) (v0.13.0 multi-host). Prior: [agent freestyle → blocked](https://traverse-framework.com/blog/agent-freestyle-blocked.html). Authoring: [You don't need Rust to publish a capability](https://traverse-framework.com/blog/you-dont-need-rust-to-publish-a-capability.html). - [Discover](https://traverse-framework.com/discover.html): a live browser demo that pulls the public registry and executes a reviewed plan locally. Read [what it proves](https://traverse-framework.com/blog/what-discover-proves.html) before quoting it. - [Compare: vs microservices](https://traverse-framework.com/compare/vs-microservices.html), [vs serverless](https://traverse-framework.com/compare/vs-serverless.html), [vs function calling](https://traverse-framework.com/compare/vs-function-calling.html), [vs agent runtimes](https://traverse-framework.com/compare/vs-agent-runtimes.html), [vs WASM runtimes](https://traverse-framework.com/compare/vs-wasm-runtimes.html), [vs cross-platform frameworks](https://traverse-framework.com/compare/vs-cross-platform-frameworks.html) - [About](https://traverse-framework.com/about.html): project history and motivation. diff --git a/src/pages/blog/index.astro b/src/pages/blog/index.astro index 0e1473f..fbc4f2d 100644 --- a/src/pages/blog/index.astro +++ b/src/pages/blog/index.astro @@ -2,11 +2,11 @@ import SubpageLayout from '@layouts/SubpageLayout.astro'; const posts = [ - { href: '/blog/you-dont-edit-a-published-capability.html', title: "You don't edit a published capability. You mark it.", desc: 'Featured · Oct 8 · Deprecation and revocation leave the contract in place. Ranges skip the marker; exact pins still resolve under spec 005 and decision 127. Runtime refusal is traverse#1598, not shipped. Crate alignment is registry#631.' }, + { href: '/blog/you-dont-edit-a-published-capability.html', title: "You don't edit a published capability. You mark it.", desc: 'Featured · Oct 8 · Deprecation and revocation leave the contract in place. Ranges skip the marker. Exact pins in traverse-registry 0.27.0 still resolve with lifecycle status (registry#632). Runtime refusal is traverse#1598, not shipped in v0.14.0.' }, { href: '/blog/model-rights-are-data.html', title: 'Model rights are data, not a README', desc: 'Featured · Oct 6 · AI model rights from contract to host: offline publish checks, signed registry rights record, host trust roots, and what is still open.' }, { href: '/blog/signed-exact-ref-digits.html', title: 'Signed model. Exact pin. Bit-identical hosts.', desc: 'Featured · Weekly demo: signed digits-mlp-1.0.0 exact-ref package, same bytes on Browser + Node via ExactModelBrowserHost; tamper fail-closed (digest_mismatch). Traverse v0.14.0. Test-only key.' }, { href: '/blog/print-support-domain-pack.html', title: 'Domain packs are in scope: print-support without an app rewrite', desc: 'Featured · Manufacturing-shaped capability pack under discover→execute→trace; apps-not-ready ≠ no domain packs; hosts stay thin; none of the print.* capabilities published yet. registry#596 · #597–#604 · Discussion #1540.' }, - { href: '/blog/traverse-0-14-0-what-changed-for-embedders.html', title: 'v0.14.0: what changed for embedders', desc: 'Featured · Signed Spec 138 (schema 2.0.0 + model.sig.json), host-owned trust, registerPackage, digits-mlp-1.0.0 (test-only key). Native + web + Swift ExactModelHost execute; Kotlin/.NET do not yet. crates/npm 0.14.0; registry 0.25.0.' }, + { href: '/blog/traverse-0-14-0-what-changed-for-embedders.html', title: 'v0.14.0: what changed for embedders', desc: 'Featured · Signed Spec 138 (schema 2.0.0 + model.sig.json), host-owned trust, registerPackage, digits-mlp-1.0.0 (test-only key). Native + web + Swift ExactModelHost execute; Kotlin/.NET do not execute exact-ref yet. crates/npm 0.14.0; that release pins registry 0.25.0.' }, { href: '/blog/same-wasm-multi-host.html', title: 'Same WASM. Browser and Node match. Agent still can’t freestyle.', desc: 'Featured · Weekly demo: identical core.authorize@1.2.0 bytes on Browser + Node deny junior_analyst $2.4M wire; allow treasury_ops + MFA/dual-control. Traverse v0.13.0 multi-host.' }, { href: '/blog/where-business-logic-lives.html', title: 'Where business logic lives (hosts stay thin)', desc: 'Featured · Narrative companion to the where-logic Q&A: capabilities hold non-UI domain rules; hosts = UI + I/O; utilities ≠ ceiling; apps-not-ready ≠ leave logic in the host.' }, { href: '/blog/what-is-real-today-start-here.html', title: 'Start here: what is real in Traverse today', desc: 'Featured · Narrative companion to /what-is-real-today: discover→execute→trace, skill-first authoring, one shared runtime.wasm, honest consumers, pre-1.0.' }, diff --git a/src/pages/blog/traverse-0-14-0-what-changed-for-embedders.astro b/src/pages/blog/traverse-0-14-0-what-changed-for-embedders.astro index acb6165..1b701da 100644 --- a/src/pages/blog/traverse-0-14-0-what-changed-for-embedders.astro +++ b/src/pages/blog/traverse-0-14-0-what-changed-for-embedders.astro @@ -52,14 +52,14 @@ const _body = `
  • Rust native + web — exact-ref execute shipped in the v0.14.0 product cut.
  • Swift — ExactModelHost executes signed exact-ref via the published TraverseSwiftHost xcframework (swift-host-v0.14.0-1) and the in-repo Package.swift binary pin. Still not a CocoaPods / Swift Package Index first-class package; distribution is GitHub Release + SPM binary target.
    • -
  • Kotlin / .NET — in-tree embedders continue; they do not execute exact-ref models yet.
    • +
  • Kotlin / .NET — published packages (Maven Central com.traverse-framework:traverse-embedder 0.14.0, nuget.org TraverseEmbedder 0.14.0); they do not execute exact-ref models yet.

SDKs, MCP, and CLI are embedders and clients of the same orchestrator — not different Traverse runtimes.

Pins

-

crates.io lockstep at 0.14.0 with traverse-embedder-web@0.14.0. Pin traverse-registry =0.25.0 if you consume the registry crate directly.

+

crates.io lockstep at 0.14.0 with traverse-embedder-web@0.14.0. This release pins traverse-registry at =0.25.0. crates.io has since published traverse-registry 0.27.0.

Upgrade

diff --git a/src/pages/blog/what-is-real-today-start-here.astro b/src/pages/blog/what-is-real-today-start-here.astro index e9ed531..4d3a012 100644 --- a/src/pages/blog/what-is-real-today-start-here.astro +++ b/src/pages/blog/what-is-real-today-start-here.astro @@ -61,7 +61,7 @@ const _body = `
  • Rust — crates.io traverse-embedder (published)
  • Agents — traverse-mcp (published; stdio bootstrap today)
  • Python — CLI only: shell out to traverse-cli capability-package execute. No Python SDK.
    • -
  • Swift / Kotlin / .NET — in-tree and usable for experiments; not first-class public packages yet
    • +
  • Swift / Kotlin / .NET — published, pre-1.0, 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

    • Check platforms before assuming a host is shipped. See also Does Traverse have a Python SDK?.

    diff --git a/src/pages/blog/you-dont-edit-a-published-capability.astro b/src/pages/blog/you-dont-edit-a-published-capability.astro index 0b4fbf8..af8b989 100644 --- a/src/pages/blog/you-dont-edit-a-published-capability.astro +++ b/src/pages/blog/you-dont-edit-a-published-capability.astro @@ -38,8 +38,8 @@ const _body = `

    Two surfaces already skip something, and they are not the same skip:

      -
    • On registry main, the traverse-registry workspace (0.27.0, not the crates.io release) skips both deprecated and revoked records during range resolution. When every match is marked, the error says only deprecated or revoked versions satisfy the range.
      • -
    • The public /discover page builds its snapshot from live catalog.json and drops rows whose deprecated flag is true. It does not read the catalog's revoked flag. That flag is on every catalog entry, and it was false on all of them when this was checked. The page has not demonstrated a revoked skip.
      • +
    • Published traverse-registry 0.27.0 skips both deprecated and revoked records during range resolution. When every match is marked, resolution fails instead of returning one. A revoked-only range still fails with OnlyDeprecatedVersions.
      • +
    • The public /discover page builds its snapshot from live catalog.json and drops rows whose deprecated flag is true. It does not read the catalog's revoked flag. On 8 October 2026 that flag was present on all 227 catalog entries and true on none of them; 38 entries were deprecated: true. The page has not demonstrated a revoked skip.

    The marker is a sibling file

    @@ -48,21 +48,19 @@ const _body = `

    Revocation is the stronger marker, from registry spec 026 and decision 127. It adds revoked.json with reason, evidence_url, and revoked_at. The contract and the artifact stay untouched. The index keeps the entry with status: "revoked", the revocation record, and the full rights record, and it must not present that version as active. The public catalog projects the same fact as revoked: true plus a revocation object.

    -

    Deprecation is already in use. Forty versions on registry main have a deprecated.json, including placeholder stubs and fixed-output fixtures replaced by a later version. There is no revoked.json in the tree. The shape is specified, and the index and catalog builders know how to project it. No published version has been revoked.

    +

    Deprecation is already in use. Forty deprecated.json files are on registry main (counted 8 October 2026), including placeholder stubs and fixed-output fixtures replaced by a later version. There is no revoked.json in that tree. The shape is specified, and the index and catalog builders know how to project it. No published version has been revoked.

    An exact pin is a different question

    Spec 005 is explicit about deprecation: exact-pin resolution ignores the flag and succeeds if the version exists. Decision 127 keeps that guarantee for revocation. An exact pin still resolves, and it carries a machine-readable do-not-run signal. The registry is not supposed to make a pinned consumer disappear. The runtime decides whether to execute. The spec 026 consumer doc says the runtime should refuse. See exact pin versus version range and what that status signal means for a host.

    -

    That is the spec. It is not what the crate does today.

    +

    Published traverse-registry 0.27.0 does the registry half of that. Exact-pin resolution returns deprecated and revoked records with lifecycle status (lifecycle_status()) and, when the record is revoked, revocation, so the consumer can fail closed. Range resolution still skips both. That is spec 005 FR-004 and decision 127, question 11. The fix merged as registry#632. registry#631 is closed. crates.io shows 0.27.0, published 8 October 2026, tag v0.27.0.

    -

    The published traverse-registry on crates.io is 0.25.0 (29 September 2026). Traverse pins =0.25.0. That release skips deprecated records on both range and exact lookup, and it has no revoked type. Spec 026's status and revocation fields landed later, on registry main, in the unpublished 0.27.0 workspace.

    - -

    On that main branch, exact lookup returns only an active record. A deprecated or revoked exact pin comes back as nothing. The test resolution_never_selects_a_revoked_record asserts that. It contradicts spec 005 and decision 127. Returning the record with its status, then publishing the crate, is registry#631. It is open.

    +

    Traverse v0.14.0 still pins =0.25.0. That older crate skips deprecated records on both range and exact lookup, and it has no revoked type. The comment on traverse#1598 says the consumer slice can leave =0.25.0 now that 0.27.0 is published. Moving the pin is not the same as the runtime refusing a revoked artifact.

    Execute: the runtime is supposed to refuse

    -

    Once a host actually holds a revoked record, the decision is not the agent's. Hosts are clients. traverse-embedder-web (JS/TS), traverse-embedder (Rust), and traverse-mcp call the same runtime.wasm. Python has no SDK; a Python program shells out to traverse-cli capability-package execute. Swift, Kotlin, and .NET embedders exist in-tree and are not published packages.

    +

    Once a host actually holds a revoked record, the decision is not the agent's. Hosts are clients. traverse-embedder-web (JS/TS), traverse-embedder (Rust), and traverse-mcp call the same runtime.wasm. Python has no SDK; a Python program shells out to traverse-cli capability-package execute. Swift, Kotlin, and .NET are published clients of that same runtime, not separate runtimes. Swift ships a wasmi xcframework on swift-host-v* host tags (Platforms currently lists swift-host-v0.14.0-4). Kotlin is com.traverse-framework:traverse-embedder 0.14.0 on Maven Central. .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.

    Decision 127 leaves enforcement with Traverse: the pin resolves, the signal says do not run, and the runtime decides. Refusing the run — fail closed, rather than executing a revoked artifact — is traverse#1598. It is open. It is not in the v0.14.0 release. Until it ships, do not describe the runtime as already refusing a revoked pin.

    @@ -70,19 +68,19 @@ const _body = `

    A trace is the record of what the runtime decided. There is no shipped trace for "this pin was revoked, so the run was refused," because the runtime does not honor revoked yet. When #1598 lands, that refusal belongs in the trace the same way any other deny does. It is not a field to cite today.

    -

    What is shipped (checked 6 October 2026)

    +

    What is shipped (checked 8 October 2026)

    -

    Shipped, in the registry repo:

    +

    Shipped, in the registry:

      -
    • deprecated.json, the index deprecated flag, and real yanked versions on main.
      • -
    • The revoked.json shape, index status, and catalog revoked / revocation fields. No version is revoked yet.
      • -
    • Range resolution on registry main that skips deprecated and revoked records.
      • +
    • deprecated.json, the index deprecated flag, and real yanked versions on main. Forty deprecated.json files; the live catalog marks 38 entries deprecated.
      • +
    • The revoked.json shape, index status, and catalog revoked / revocation fields. No revoked.json is in the tree, and no catalog entry is revoked.
      • +
    • Range resolution in published traverse-registry 0.27.0 that skips deprecated and revoked records.
      • +
    • Exact-pin resolution in 0.27.0 that returns the record with lifecycle status and revocation. registry#632 merged; registry#631 is closed. Tag v0.27.0.

    Open:

      -
    • Exact pins returning the record plus its status, and the next traverse-registry publish. registry#631. crates.io is still 0.25.0.
      • -
    • The runtime and traverse-cli honoring revoked. traverse#1598. Not shipped.
      • +
    • The runtime and traverse-cli honoring revoked (refuse, fail closed). traverse#1598. Not shipped in v0.14.0. That release still pins traverse-registry at =0.25.0; the consumer slice can leave the pin.

    The short version for an agent: at discover time, do not propose a deprecated or revoked version as if it were active. At execute time, the runtime is the one that is supposed to refuse, and that part is still an open ticket. The citeable page this post walks through is what happens when a capability version is deprecated or revoked.

    @@ -125,7 +123,7 @@ const _body = ` --- diff --git a/src/pages/changelog.astro b/src/pages/changelog.astro index 43e784d..3b1c21b 100644 --- a/src/pages/changelog.astro +++ b/src/pages/changelog.astro @@ -7,7 +7,7 @@ import SubpageLayout from '@layouts/SubpageLayout.astro';
    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). Exact-ref execute is native + web + Swift ExactModelHost (xcframework swift-host-v0.14.0-1 / Package.swift pin; #1579 closed 2026-09-30) — Kotlin/.NET do not execute exact-ref yet. Pin crates/npm at 0.14.0 and traverse-registry at =0.25.0. Product Release: Traverse v0.14.0.

    +

    Signed exact-ref models + digits-mlp

    v0.14.0 is a minor lockstep crate + npm release with breaking Spec 138 exact-ref surface changes (0.x minor convention). Model manifests move to schema 2.0.0 with detached Ed25519 model.sig.json; host-owned trust roots; first trained digits-mlp-1.0.0 (test-only key; production signing tracked separately). Exact-ref execute is native + web + Swift ExactModelHost (xcframework swift-host-v0.14.0-1 / Package.swift pin; #1579 closed 2026-09-30) — Kotlin/.NET do not execute exact-ref yet. 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/faq.astro b/src/pages/faq.astro index acd9931..f4350dc 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 / .NET embedders exist in-tree but are not first-class public packages yet. There are no invented customers on this site. If your use case maps to what is shipping now, you can build on it — check What is real today, Platforms, and the roadmap.

    \n
    \n
    \n\n
    \n \n
    \n

    Right now: natively via the Rust runtime and embedders, and in the browser via the Web/TypeScript embedder SDK — the same WASM binary either way. An MCP-connected AI agent calls into one of those two targets rather than running in a separate placement of its own.

    \n

    Swift/iOS, Kotlin/Android, and .NET embedders are in progress — usable in-tree, not certified public package releases. Edge is planned. Cloud placement is an explicit non-goal for the current milestone. Do not assume a target works without checking Platforms and What is real today.

    \n
    \n
    \n\n
    \n
    \n\n \n
    \n
    Technical
    \n
    \n\n
    \n \n
    \n

    Microservices separate deployment. Traverse separates the capability from the runtime entirely. Your pricing logic does not care whether it runs in a browser or on a server. A microservice always runs where you deployed it.

    \n

    There is also no network call when a capability runs close to the user. The WASM binary runs in-process. That changes the latency profile completely.

    \n
    \n
    \n\n
    \n \n
    \n

    Serverless functions are tied to a cloud provider and a specific execution model. You write a function for AWS Lambda or Cloudflare Workers and it runs there. Traverse capabilities are not tied to any provider or platform.

    \n

    The contract system is also different. Serverless functions have no formal contract. Traverse validates inputs and outputs every time, which means it can catch integration errors before they reach production.

    \n
    \n
    \n\n
    \n \n
    \n

    WASM runs near-native. The contract validation adds a fixed overhead per call, not per computation unit. For most business logic workloads this is noise. A formal benchmarks page is planned for v0.11.x.

    \n

    The bigger win is usually latency, not throughput. Running capability logic in the browser or at the edge cuts the round-trip entirely.

    \n
    \n
    \n\n
    \n \n
    \n

    Every capability has a contract file that declares what inputs it accepts, what outputs it produces, which placement targets it supports, and what constraints apply. The runtime reads this file before execution.

    \n

    If you try to call a capability with the wrong inputs, the runtime rejects it before the WASM even runs. The trace artifact records the full decision. Specs and CI gates are how we stay honest — they are governance hygiene, not the product identity or the pitch. See What is real today.

    \n
    \n
    \n\n
    \n \n
    \n

    WASM is how portability works. The contract system and the trace mechanism exist independent of WASM, but the cross-environment execution story depends on it.

    \n

    If you only need server-side execution, you could use the Rust crate directly. But you lose the placement portability that is the main point.

    \n
    \n
    \n\n
    \n \n
    \n

    The runtime catches the failure, records it in the trace artifact with a timestamp and the failing contract clause, and returns a structured error. Nothing silent or ambiguous.

    \n

    Contract violations fail before execution. Runtime errors fail during execution. Both produce a trace. You always know exactly where the failure happened and what the runtime saw at that point.

    \n
    \n
    \n\n
    \n \n
    \n

    Start with the trace artifact from the failed call. It records input values, contract checks, execution steps, and output values. Most problems are visible there without any additional tooling.

    \n

    The CLI includes a trace subcommand for inspecting trace files. The MCP server exposes trace querying to AI agents. Expanded trace querying is planned for v0.11.x.

    \n
    \n
    \n\n
    \n \n
    \n

    JavaScript and TypeScript work today via the published Web embedder — npm traverse-embedder-web. You load a bundle, digest-verify the WASM, and execute in the browser. The React integration guide shows the shape.

    \n

    Python has no shipped SDK. The honest today-path is a stdlib subprocess call to traverse-cli capability-package execute <manifest> <request.json> against a checked-in package. That is the real CLI verb — not a fake capability run. See Can I use Traverse with Python? and What is real today.

    \n
    \n
    \n\n
    \n \n
    \n

    A trace is a structured record produced after every capability execution. It captures the inputs the runtime received, which contract clauses were checked, the execution path taken, and the outputs produced.

    \n

    This matters for two reasons. First, it makes debugging fast. Second, it makes auditing possible. If a pricing rule applied a discount you did not expect, the trace shows you exactly why. That kind of explainability is hard to add after the fact.

    \n
    \n
    \n\n
    \n
    \n\n \n
    \n
    Licensing & Maintenance
    \n
    \n\n
    \n \n
    \n

    Apache 2.0 is a permissive open source license. You can use Traverse commercially, modify it, distribute it, and build closed-source products on top of it. You need to include the original license notice.

    \n

    There are no royalties and no restrictions on commercial use. If you are evaluating this for a company, legal counsel can confirm, but Apache 2.0 is one of the most business-friendly open source licenses available.

    \n
    \n
    \n\n
    \n \n
    \n

    Enrico Piovesan. One person. This is not a VC-funded team with a support contract. It is research engineering built over years of real product work, published as open source.

    \n

    The upside is that the design is intentional and consistent. The tradeoff is that response times on issues depend on one person's capacity. Community contributions are welcome and encouraged.

    \n
    \n
    \n\n
    \n
    \n\n \n
    \n
    AI and MCP
    \n
    \n\n
    \n \n
    \n

    The MCP server exposes Traverse capabilities as tools that AI agents can call. The agent reads the capability contract to understand what the tool does, what inputs it takes, and what it returns. No custom glue code needed.

    \n

    Because every call produces a trace, the agent can inspect what actually happened. The agent proposes; the runtime decides. That direction is clearest in the deny demo: The agent freestyled a $2.4M wire. The runtime said no. Prefer the blog write-up; weekly-demos is not publicly cloneable yet (tracked in .github#30). See also Agents and What is real today.

    \n
    \n
    \n\n
    \n \n
    \n

    Function calling gives an agent a schema and an endpoint. The agent calls the function and gets a response. There is no contract enforcement, no placement logic, and no trace.

    \n

    With Traverse, the agent is working with governed capabilities. Inputs are validated before execution. Bad calls can be denied before they run. The result includes a trace. The contract tells the agent exactly what the capability is allowed to do. That is a different level of trust and observability — agent proposes, runtime decides. Read the deny demo.

    \n
    \n
    \n\n
    \n \n
    \n

    Contract-Driven AI Development, or C-DAD, is a methodology that asks AI agents to navigate systems that have machine-readable contracts rather than undocumented code. If your capabilities have contracts, an AI agent can read them and reason about the system correctly.

    \n

    Without contracts, AI agents are guessing based on naming conventions and comments. With contracts, they have a precise definition of what each capability does, what it accepts, and what constraints apply. Enrico published the C-DAD whitepaper as the theoretical foundation for this approach.

    \n
    \n
    \n\n
    \n \n
    \n

    Universal Microservices Architecture, or UMA, is the architectural pattern Traverse implements. The core idea is that business capabilities should be portable across every runtime, not tied to the environment they were first deployed in.

    \n

    The UMA book on Amazon covers the theory in 13 chapters with runnable Rust and WASM examples. Traverse is the production runtime that makes those ideas executable. More at universalmicroservices.com.

    \n
    \n
    \n\n
    \n
    \n\n \n
    \n
    Community
    \n
    \n\n
    \n \n
    \n

    Start from labeled help wanted / good-first-issue tickets, or open an issue on GitHub. For a new capability in plain English, use the official Claude skill traverse-capability-author in claude-skills — it checks the registry, authors the contract + WASM, and opens a human-reviewed PR. More on Contribute.

    \n

    One rule: nothing ships without a governing spec (docs and examples marked no-spec-needed are the exception). If you want to add a runtime feature, the spec comes first.

    \n
    \n
    \n\n
    \n
    \n\n
    \n
    \n
    \n\n
    \n
    \n
    \n
    Ready to build?
    \n

    The quickstart gets you to a running capability in under 10 minutes. No account required.

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

    Your questions, answered.

    \n

    Everything you want to know before you write a single line of code. If something is missing, open an issue on GitHub.

    \n
    \n
    \n\n
    \n
    \n\n \n\n
    \n\n \n
    \n
    Getting Started
    \n
    \n\n
    \n \n
    \n

    Traverse is a contract-driven runtime for portable business capabilities. The useful loop is discover → execute → trace: find a governed capability, run known behavior, read the receipt. An agent may propose a call; the runtime decides — validate, execute or deny, and leave a trace.

    \n

    Usual authoring is plain English via the Claude skill traverse-capability-author (contract → WASM → human-reviewed PR). Under the hood the executable is still Rust compiled to WASM; that is how, not the product identity. Embedders, CLI, and MCP are clients of one shared runtime.wasm.

    \n

    Citeable snapshot: What is real today. Direction demo: agent freestyle → blocked.

    \n
    \n
    \n\n
    \n \n
    \n

    No — not for the usual paths. Author a new capability in plain English with the official Claude skill traverse-capability-author in traverse-framework/claude-skills. It interviews you one question at a time, checks the public (and any private) registry so you do not reinvent something that already exists, writes the contract, produces executable WASM, and opens a human-reviewed PR. You describe the business rule; you do not have to write the Rust yourself. Under the hood the implementation is still Rust→WASM — that is what gives you determinism, sandboxing, and portability.

    \n

    Manual path: if you write capabilities yourself in the repo, that still expects Rust (compile to wasm32-wasip1).

    \n

    Consume path: no Rust needed. JavaScript and TypeScript call through the published npm package traverse-embedder-web. Python can consume today by shelling out to traverse-cli with the real verb capability-package execute (stdlib subprocess) — there is no shipped Python SDK. See What is real today and Do I need Rust?.

    \n
    \n
    \n\n \n
    \n \n
    \n

    Start with What is real today and the deny demo The agent freestyled a $2.4M wire. The runtime said no. (blog write-up is the public path; weekly-demos is not publicly cloneable yet — tracked in .github#30). Then Agents and llms.txt.

    \n

    Do not invent a Python SDK, do not assume every platform is shipped, and do not treat governing-spec counts as the value. Skill-first authoring via traverse-capability-author; one shared runtime.wasm; published consumers are JS/TS, Rust, and MCP; Python is CLI-only today.

    \n
    \n
    \n\n
    \n \n
    \n

    Traverse is pre-1.0 (v0.14.0). The discover → execute → trace loop works today on the shipped local and browser paths. The core runtime, CLI, MCP server, and the published Rust and Web embedder SDKs work. Specs and CI gates keep that honest — they are not the headline.

    \n

    Some advanced executor targets are still planned. Native Swift, Kotlin, 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
    "; --- \n
    \n
    \n
    \n \n v0.14.0 · Apache 2.0 · Open source\n
    \n

    \n Governed capability runtime.
    Discover → execute → trace.\n

    \n

    \n Skill-first via traverse-capability-author — not “must write Rust.” One shared runtime.wasm; browser, native desktop, CLI, and MCP are the shipped clients today (not packaged mobile/.NET; no edge; cloud is a non-goal). The agent proposes; the runtime decides.\n

    \n

    \n Non-UI business logic lives in capabilities (WASM + contract) — pricing, eligibility, codecs, scorers, gates. Hosts and clients do UI and I/O only. “Apps not ready” is product/help-wanted sequencing, not “leave domain rules in the host forever.” Where does business logic live?\n

    \n
    \n What is real today →\n Deny demo →\n Quickstart\n
    \n
    \n\n\n\n
    \n
    \n
    \n \n
    \n
    \n
    \n
    \n pricing.toml\n
    \n
    \n 
    [capability]\nname    = \"calculate-price\"\nversion = \"1.2.0\"\nwasm    = \"pricing.wasm\"\n\n[governing_spec]\ntitle   = \"Pricing Policy v3\"\nsource  = \"docs/pricing-policy.md\"\n\n[input]\ntype = \"object\"\nproperties.sku      = \"string\"\nproperties.quantity = \"integer\"\nproperties.region   = \"string\"\nrequired = [\"sku\", \"quantity\"]\n\n[output]\ntype = \"object\"\nproperties.total    = \"number\"\nproperties.currency = \"string\"\nrequired = [\"total\", \"currency\"]
    \n
    \n
    \n
    \n
    \n
    \n
    \n terminal\n
    \n
    \n
    $traverse run pricing --input '{\"sku\":\"PRO\",\"quantity\":5}'
    \n
    ✓ Contract validated
    \n
    ✓ WASM executed (2.1ms)
    \n
    → {\"total\": 249.95, \"currency\": \"USD\"}
    \n
    \n
    \n
    \n
    \n\n \n
    \n
    How Traverse works
    \n

    \n Write a contract.
    Ship a capability.\n

    \n

    \n Three steps from idea to a portable, contract-governed piece of business logic — on hosts that have actually shipped (see Platforms).\n

    \n
    \n
    \n
    01
    \n
    \n

    Define the contract

    \n

    Write a TOML file with your capability name, the WASM binary path, and JSON Schema definitions for inputs and outputs. Link it to the governing spec document your team actually works from.

    \n
    \n
    \n
    \n
    02
    \n
    \n

    Author → WASM

    \n

    Usual path: plain English via the Claude skill traverse-capability-author (contract → WASM → human-reviewed PR). Manual path is still Rust→wasm32-wasip1. Same artifact on every embedder.

    \n
    \n
    \n
    \n
    03
    \n
    \n

    Register and run

    \n

    Add the capability to the registry with traverse add. Call it from the CLI, from an AI agent via MCP, or from your app directly. Every call is validated and traced.

    \n
    \n
    \n
    \n
    \n
    \n
    \n
    \n\n\n
    \n
    \n
    \n
    Features
    \n

    Everything business logic needs

    \n

    From contract validation to AI agent discovery, Traverse handles the entire lifecycle.

    \n
    \n
    \n
    \n
    \n \n
    \n

    Contract-first validation

    \n

    Every capability call validates inputs against a JSON Schema precondition before execution. Postconditions validate the output. Bad data never reaches your logic.

    \n
    \n
    \n
    \n \n
    \n

    WASM sandbox isolation

    \n

    Each capability runs in its own Wasmtime WASM instance with linear memory isolation. A capability cannot access host resources it was not explicitly granted.

    \n
    \n
    \n
    \n \n
    \n

    AI agent integration

    \n

    Expose your entire capability registry to AI agents via the MCP stdio server. Claude, GPT-4, and any MCP-compatible agent can discover and call capabilities safely.

    \n
    \n
    \n
    \n \n
    \n

    Honest host surface

    \n

    Shipped today: native (Linux/macOS/Windows) and browser via traverse-embedder-web. Swift/Kotlin/.NET exist in-tree, not as certified public packages. Edge is planned; cloud placement is an explicit non-goal for v0.1. See Platforms.

    \n
    \n
    \n
    \n \n
    \n

    Trace artifacts

    \n

    Every execution produces a trace artifact: the input, the output, the contract version, and a timestamp. Audit any past run without re-executing anything.

    \n
    \n
    \n
    \n \n
    \n

    Policy paper trail

    \n

    Every contract can link to the policy document it implements. Specs are honesty hygiene for the codebase — not the product pitch, and not a count to advertise.

    \n
    \n
    \n
    \n
    \n\n\n
    \n
    \n

    Watch a workflow get composed, live.

    \n

    Your browser fetches the real capability registry and a client-side heuristic -- not a hosted AI model -- chains matching capabilities into a workflow. No fixtures, no precomputed data.

    \n Watch the live demo →\n
    \n
    \n\n\n
    \n
    \n
    \n
    Runtime shape
    \n

    One runtime.wasm. Clients on shipped hosts.

    \n
    \n
    \n
    \n
    1
    \n
    Shared runtime.wasm orchestrator — embedders are clients. Placement targets that have actually shipped: see Platforms.
    \n
    \n
    \n
    0
    \n
    Logic rewrites between hosts that share the same runtime.wasm. Same contract, same binary, same behavior on those shipped surfaces — not a claim about mobile packages, edge, or cloud.
    \n
    \n
    \n
    2ms
    \n
    Typical contract execution time on the local target. WASM startup is fast. Contract validation adds negligible overhead.
    \n
    \n
    \n
    \n
    \n\n\n
    \n
    \n
    \n
    Use cases
    \n

    Built for real business logic

    \n

    Pricing rules, eligibility checks, compliance logic — deterministic computation that must behave the same on every host where Traverse actually ships.

    \n
    \n
    \n
    \n
    \n \n
    \n

    Pricing and discount logic

    \n

    Encode complex pricing rules as a contract with a link to your pricing policy document. The same capability runs via the published Web embedder, native/CLI hosts, and MCP agents with identical results — where those surfaces are shipped.

    \n Learn more →\n
    \n
    \n
    \n \n
    \n

    Eligibility and access rules

    \n

    Run eligibility logic as a sandboxed WASM capability so an AI agent can check a user's eligibility for a product, service, or feature without risk of hallucinating the answer.

    \n Learn more →\n
    \n
    \n
    \n \n
    \n

    Compliance and audit logic

    \n

    Capture regulatory and compliance rules in versioned contracts with governing spec links. Every execution is traced. Auditors can replay any historical decision from the trace artifact.

    \n Learn more →\n
    \n
    \n
    \n \n
    \n

    AI agent guardrails

    \n

    Give your AI agents a set of contract-governed capabilities to call. The agent cannot exceed the contract's boundaries. Postcondition checks block invalid outputs before they propagate.

    \n Learn more →\n
    \n
    \n
    \n
    \n\n\n
    \n
    \n
    \n

    Start building with Traverse

    \n

    Install the CLI, write your first contract, and run it in under five minutes.

    \n
    \n Get started →\n View on GitHub\n
    \n
    \n
    \n\n"; -const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"SoftwareApplication\",\"name\":\"Traverse\",\"description\":\"A governed capability runtime: discover → execute → trace. Skill-first authoring via traverse-capability-author; one shared runtime.wasm; shipped clients are browser, native desktop, CLI, and MCP. The agent proposes; the runtime decides.\",\"url\":\"https://traverse-framework.com\",\"author\":{\"@type\":\"Person\",\"name\":\"Enrico Piovesan\"},\"license\":\"https://www.apache.org/licenses/LICENSE-2.0\",\"applicationCategory\":\"DeveloperApplication\",\"softwareVersion\":\"0.13.0\",\"codeRepository\":\"https://github.com/traverse-framework/traverse\"}"; +const _body = "\n
    \n
    \n
    \n
    \n \n v0.14.0 · Apache 2.0 · Open source\n
    \n

    \n Governed capability runtime.
    Discover → execute → trace.\n

    \n

    \n Skill-first via traverse-capability-author — not “must write Rust.” One shared runtime.wasm; browser, native desktop, CLI, and MCP are 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\"}"; --- -

    Short answer: no for Kotlin and .NET exact-ref execute today. They remain in-tree embedders, not first-class published packages with Spec 138 parity.

    +

    Short answer: no for Kotlin and .NET exact-ref execute today. The packages are published — Kotlin com.traverse-framework:traverse-embedder 0.14.0 on Maven Central, .NET TraverseEmbedder 0.14.0 on nuget.org — and they do not have Spec 138 exact-ref parity yet.

    What works instead

    Native Rust and the web embedder execute signed exact-ref in the v0.14.0 cut. Swift ExactModelHost reached parity via swift-host-v0.14.0-1 (#1579) — GitHub Release + SPM binary target, not a CocoaPods claim. Full matrix: Which hosts run signed exact-ref models?.

    diff --git a/src/pages/questions/does-traverse-have-a-python-sdk.astro b/src/pages/questions/does-traverse-have-a-python-sdk.astro index 6a09494..5a3df48 100644 --- a/src/pages/questions/does-traverse-have-a-python-sdk.astro +++ b/src/pages/questions/does-traverse-have-a-python-sdk.astro @@ -52,7 +52,7 @@ const relatedLinks = [

    If a page, README, or example does not show it, it is not shipped. Prefer citing what is real today and platforms over inventing a consumer.

    How this fits the rest of the surface

    -

    There is one shared runtime.wasm. Language SDKs, MCP, and the CLI are embedders or clients — not separate runtimes. Shipped consumers today: JS/TS via traverse-embedder-web, Rust via the Rust embedder, and agents via traverse-mcp. Python is CLI-only. Native Swift, Kotlin, and .NET exist in-tree but are not first-class public packages yet. See What is one shared runtime.wasm?.

    +

    There is one shared runtime.wasm. Language SDKs, MCP, and the CLI are embedders or clients — not separate runtimes. Shipped consumers today: JS/TS via traverse-embedder-web, Rust via the Rust embedder, and agents via traverse-mcp. Python is CLI-only. Swift, Kotlin, and .NET packages are published, pre-1.0, and not Certified. See What is one shared runtime.wasm?.

    Traverse is pre-1.0. Host honesty stays on platforms and what is real today.

    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 f6d2050..860d173 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 on registry main 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 exists on registry main today. The runtime refusal on an exact pin is traverse#1598 and is not shipped. The agent proposes; the runtime decides.', + 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.', }, }], }); @@ -34,11 +34,11 @@ 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. On registry main the workspace resolver already 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.

    -

    The published traverse-registry 0.25.0, which Traverse pins, has no revoked type. It skips deprecated ranges only. Do not describe today's published crate as already filtering revoked versions.

    +

    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.

    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. No revoked.json exists on registry main, and the live catalog's revoked flag was false on every entry when this was checked, so that page is not a demonstration of revoked handling.

    +

    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.

    diff --git a/src/pages/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.astro b/src/pages/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.astro index 822445d..4d5d314 100644 --- a/src/pages/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.astro +++ b/src/pages/questions/what-does-a-status-signal-on-an-exact-pin-mean-for-a-host.astro @@ -9,7 +9,7 @@ const jsonLd = JSON.stringify({ name: 'What does a status signal on an exact pin mean for a host?', acceptedAnswer: { '@type': 'Answer', - text: 'It is a lifecycle fact the shared runtime is supposed to read before it runs the artifact. Index status is active, deprecated, or revoked. A revoked exact pin, under decision 127, still resolves and carries a machine-readable do-not-run signal; the runtime should refuse (fail closed). That refusal is traverse#1598 and is not shipped. The published traverse-registry 0.25.0 has no revoked type. Registry main returns nothing from exact lookup for a non-active record (registry#631). Hosts are clients of one runtime.wasm, not separate runtimes.', + text: 'It is a lifecycle fact the shared runtime is supposed to read before it runs the artifact. Index status is active, deprecated, or revoked. A revoked exact pin, under decision 127, still resolves and carries a machine-readable do-not-run signal; the runtime should refuse (fail closed). That refusal is traverse#1598 and is not shipped in v0.14.0. Published traverse-registry 0.27.0 returns the deprecated or revoked record with lifecycle status and revocation so the consumer can fail closed (registry#632; registry#631 is closed). Range resolution still skips both. Hosts are clients of one runtime.wasm, not separate runtimes.', }, }], }); @@ -24,7 +24,7 @@ const relatedLinks = [ --- 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 embedders are in-tree only, not published packages. 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-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.

    -

    What a host can observe today

    +

    What a host can observe today (8 October 2026)

      -
    • Published crate 0.25.0 (what Traverse pins): no status or revocation type. Exact lookup of a deprecated version returns nothing.
      • -
    • Registry main, workspace 0.27.0, not published: records can carry status and revocation, but exact lookup still returns nothing unless the record is active. That is the drift in registry#631.
      • +
    • 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.
    -

    A host must not assume that an exact pin of a revoked version comes back today as a record plus a deny. That is the approved contract. The crate and the runtime do not implement it yet. 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.27.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 25e02e3..6a72216 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; first-class public Swift/Kotlin/.NET packages; 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. 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 Swift/Kotlin/.NET hosts are Certified; that Kotlin or .NET execute exact-ref yet; 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. 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.', }, }], }); @@ -26,7 +26,7 @@ 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 exist in-tree for experimentation. They are not first-class public package releases yet.
      • +
    • Swift / Kotlin / .NET packages 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. No host is Certified. Kotlin and .NET do not execute exact-ref yet.
    • Edge is planned; cloud placement is an explicit non-goal for v0.1.
    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 8677c7f..21d1231 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. Under the approved specs, an exact pin still resolves and returns the record with its status, so a pinned consumer never silently breaks and the runtime decides whether to run it. Traverse runtime handling of revoked is tracked in traverse#1598, and the registry crate is being brought in line with the exact-pin rule in registry#631.', + 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.', }, }], }); @@ -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, but a consumer that pinned it exactly still gets it back, along with a status that says what happened.

    +

    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.

    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.

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

    Registry spec 026 adds a sibling revoked.json with a reason, an evidence_url and a revoked_at time. It's meant for cases like a model whose rights turned out to be wrong. The index keeps the entry with status: "revoked", its revocation record and its full rights record, and it must never be presented as active.

    The decision behind it (registry decision-log entry 127) keeps the same pin guarantee: range resolution skips revoked versions, and an exact pin still resolves but carries a machine-readable do-not-run signal. The registry doesn't silently break your build; the runtime decides whether to execute, and it is expected to fail closed.

    -

    Where this stands today (October 5, 2026)

    +

    Where this stands today (8 October 2026)

      -
    • Registry side: the revoked.json marker, index status, and the crate types have landed on the registry's main branch. The published traverse-registry crate on crates.io is still 0.25.0.
      • -
    • Exact-pin alignment: the crate's current exact lookup skips deprecated and revoked records, which doesn't match the rule above. That fix and the next crate publish are tracked in registry#631.
      • -
    • Traverse side: honoring revoked in the runtime and showing lifecycle status in traverse-cli is traverse#1598, not shipped yet.
      • +
    • 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.
      • +
    • 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.

    Related

    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 e7a734f..cce8e03 100644 --- a/src/pages/questions/what-is-exact-ref-model-execution.astro +++ b/src/pages/questions/what-is-exact-ref-model-execution.astro @@ -50,7 +50,7 @@ const relatedLinks = [

    What landed in v0.14.0

    Spec 138 first shipped in v0.12.0 (see the historical v0.12.0 write-up). v0.14.0 adds signed packages, host-owned trust, machine-readable rights, and the first trained model digits-mlp-1.0.0 (64→32→10 MLP on UCI digits, CC BY 4.0, 96.10% held-out, bit-identical trainer / native / browser). That package is signed with the test-only key; production model signing is #1567.

    -

    Host honesty: exact-ref execute is implemented in the Rust native runtime, the web embedder, and Swift ExactModelHost (published xcframework swift-host-v0.14.0-1; Package.swift binary pin; digits conformance byte-identical). Kotlin and .NET do not execute exact-ref yet. Pin crates.io and npm at 0.14.0 (and traverse-registry at =0.25.0 if you consume it directly).

    +

    Host honesty: exact-ref execute is implemented in the Rust native runtime, the web embedder, and Swift ExactModelHost (published xcframework swift-host-v0.14.0-1; Package.swift binary pin; digits conformance byte-identical). Kotlin and .NET do not execute exact-ref yet. 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 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 Kotlin/.NET already execute exact-ref.

    diff --git a/src/pages/questions/what-is-one-shared-runtime-wasm.astro b/src/pages/questions/what-is-one-shared-runtime-wasm.astro index 9461a79..2eab086 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.wasm orchestrator. Browser, native desktop, CLI, and MCP are embedders and clients — not different Traverse runtimes per language. Published consumers today include JS/TS (traverse-embedder-web), Rust (traverse-embedder), and agents via traverse-mcp. Python shells out to traverse-cli; Swift, Kotlin, and .NET exist in-tree but are not first-class public packages yet.', + text: 'Traverse uses one shared runtime.wasm orchestrator. Browser, native desktop, CLI, and MCP are embedders and clients — not different Traverse runtimes per language. Published consumers today include JS/TS (traverse-embedder-web), Rust (traverse-embedder), and agents via traverse-mcp. Python shells out to traverse-cli. 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.', }, }], }); @@ -26,7 +26,7 @@ const relatedLinks = [ --- Rust — published crates.io traverse-embedder@0.14.0
  • AI agents — published traverse-mcp (stdio bootstrap)
  • Python — works by shelling out to traverse-cli capability-package execute. There is no Python SDK.
    • -
  • Swift / Kotlin / .NET — exist in-tree and are usable for experimentation; they are not first-class public package releases yet.
    • +
  • 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.

    • 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 9f9d53a..69c2fbc 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. The published traverse-registry 0.25.0 skips deprecated on both paths and has no revoked type. Registry main (workspace 0.27.0, not published) also returns nothing for an exact pin to a deprecated or revoked record. That exact-pin drift is registry#631, open.', + 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.', }, }], }); @@ -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. On registry main, the workspace resolver (0.27.0, not published) does both. If every match is deprecated or revoked, it errors instead of returning one. The published traverse-registry 0.25.0, which Traverse pins with =0.25.0, skips deprecated only. That release 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.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.

    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.

    -

    On registry main the exact lookup returns only an active record, so a deprecated or revoked pin comes back empty. That contradicts the spec. The fix and the next crate publish are registry#631, still open. crates.io is still 0.25.0.

    +

    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).

    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.

    diff --git a/src/pages/questions/which-hosts-run-signed-exact-ref-models.astro b/src/pages/questions/which-hosts-run-signed-exact-ref-models.astro index 3a2bca9..d343a70 100644 --- a/src/pages/questions/which-hosts-run-signed-exact-ref-models.astro +++ b/src/pages/questions/which-hosts-run-signed-exact-ref-models.astro @@ -39,8 +39,8 @@ const relatedLinks = [
  • Native Rust — exact-ref execute shipped in the v0.14.0 product cut.
  • Web — traverse-embedder-web@0.14.0 executes exact-ref.
  • Swift — ExactModelHost via published xcframework swift-host-v0.14.0-1 and in-repo Package.swift binary pin (#1579). Distribution is GitHub Release + SPM binary target — not a CocoaPods / Swift Package Index first-class package claim.
    • -
  • Kotlin — in-tree only; no exact-ref execute yet (#1580).
    • -
  • .NET — in-tree only; no exact-ref execute yet (#1602).
    • +
  • Kotlin — published com.traverse-framework:traverse-embedder 0.14.0 on Maven Central; no exact-ref execute yet (#1580).
    • +
  • .NET — published TraverseEmbedder 0.14.0 on nuget.org; no exact-ref execute yet (#1602).

    • Signing honesty

    diff --git a/src/pages/what-is-real-today.astro b/src/pages/what-is-real-today.astro index c0816b9..f2215dc 100644 --- a/src/pages/what-is-real-today.astro +++ b/src/pages/what-is-real-today.astro @@ -110,7 +110,7 @@ const _body = `

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

    -

    Native Swift / Kotlin / .NET embedders exist in-tree and are usable for experimentation. They are not first-class public package releases yet. 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-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.

    From 289cb7da56f4c5b51948e6c707277f440a27fa0c Mon Sep 17 00:00:00 2001 From: Cursor Agent Date: Thu, 8 Oct 2026 21:59:38 +0000 Subject: [PATCH 3/3] docs(questions): call native embedders published packages The shared-logic answer still described mobile hosts as in-tree only. Co-authored-by: Enrico Piovesan --- ...do-i-avoid-rewriting-business-logic-for-every-platform.astro | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/pages/questions/how-do-i-avoid-rewriting-business-logic-for-every-platform.astro b/src/pages/questions/how-do-i-avoid-rewriting-business-logic-for-every-platform.astro index 1696e6f..bb1d8d0 100644 --- a/src/pages/questions/how-do-i-avoid-rewriting-business-logic-for-every-platform.astro +++ b/src/pages/questions/how-do-i-avoid-rewriting-business-logic-for-every-platform.astro @@ -36,7 +36,7 @@ const relatedLinks = [

    What that looks like concretely

    WebAssembly is the format that makes this practical: it's a binary instruction format any conformant runtime can execute, independent of the language it was compiled from or the host it runs in. Traverse adds the two pieces raw WASM doesn't give you — a contract (what the capability needs, what it guarantees, what must be true before and after it runs) and a runtime that enforces that contract on every single execution, not just the first one someone tested.

    -

    Concretely: author the rule once as a Traverse capability — usual path plain English via traverse-capability-author, or manual Rust→WASM — and register it. Under the hood the artifact is still Rust→WASM. From then on, your web app (traverse-embedder-web), your backend/CLI (traverse-embedder / traverse-cli), your mobile app where an in-tree embedder exists, and an AI agent over traverse-mcp all call the same binary through the same runtime.wasm semantics. There's no second implementation to drift, because there's no second implementation.

    +

    Concretely: author the rule once as a Traverse capability — usual path plain English via traverse-capability-author, or manual Rust→WASM — and register it. Under the hood the artifact is still Rust→WASM. From then on, your web app (traverse-embedder-web), your backend/CLI (traverse-embedder / traverse-cli), your mobile app through a published native embedder, and an AI agent over traverse-mcp all call the same binary through the same runtime.wasm semantics. There's no second implementation to drift, because there's no second implementation.

    What this doesn't solve

    It doesn't remove the need for platform-specific UI — you still build a native-feeling frontend for each platform if that's what your product needs. And it isn't free: writing a contract and thinking through preconditions and postconditions is more upfront work than just calling a function. It's worth it specifically for the logic that's genuinely shared, genuinely important, and genuinely getting reimplemented right now. If a rule only ever lives in one place, none of this applies — see why I stopped writing the same business logic four times for the fuller version of this argument.