Short answer: yes, on the registry side. Some capabilities embed third-party model weights in their WASM artifact, and the registry redistributes those artifacts publicly. Registry spec 026-model-rights-compliance turns each ai.models entry into a machine-readable, signed rights record, so a consumer can tell from the contract whether a model may be used commercially, redistributed, or modified, before anything runs.
Registry CI checks every newly added contract with ai.model_backed: true. Each model entry must carry:
commercial_use, redistribution, derivatives, each allowed, forbidden or conditional. unknown fails validation, because the registry won't redistribute weights on unknown rights.{"{url, sha256}"} on registry Release assets. CI downloads them and checks the digest. NOTICE is required when attribution is required.derivation (or an explicit null) describing how the shipped weights differ from upstream, for example quantization or format conversion, with the converted digest.data_obligations for training or label data terms.CI also rejects contradictions it can decide without guessing, such as redistribution: forbidden (publishing is redistribution) or a derivation on a model marked derivatives: forbidden. It does not infer rights from an SPDX identifier.
The registry index projects a usage_class for each model reference from those three fields alone: unrestricted when all are allowed, evaluation-only when commercial use is forbidden, and conditional otherwise. The consumer guidance in the spec is deny-by-default on conditional.
New signature.json files also sign the contract itself: an Ed25519 signature over the SHA-256 of the exact committed contract.json bytes, with the same registry key that signs artifacts. That is what authenticates the rights fields, not just the WASM bytes.
The record is a maintainer-declared, signed declaration. A registry signature proves the declaration wasn't altered; it doesn't certify that the legal claim is right, and it isn't legal advice.
+ +traverse-cli, honoring revoked at runtime, and verifying the contract signature are tracked in traverse#1598. They are not in a published Traverse release yet.The publish path already checks the parts of this record that the contract alone can decide, offline: see Does capability publish validate model attribution?.
+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.
+ +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.
The registry uses this to keep consumers off old fixture versions: when real logic replaces a stub, the stub is deprecated in the same PR.
+ +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.
+ +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.revoked in the runtime and showing lifecycle status in traverse-cli is traverse#1598, not shipped yet.How versions and ranges work in general: What is contract versioning?. The rights record a revocation usually concerns: Does the registry record model licenses and usage rights?.
+Every capability registration includes a semver version string. Multiple versions of the same capability can live in the registry at once. Callers can pin to a specific version or request the latest version that satisfies a given constraint. Old versions keep working until you explicitly deprecate them.
\n\nBusiness logic changes. A pricing rule that worked last quarter might need new inputs next quarter. Without versioning, you have two choices: update all callers at once (risky), or freeze the logic forever (costly). With versioning, you register a new version and migrate callers incrementally. Nothing breaks until you choose to retire the old version.
\n\nWhen a caller requests calculate_price without pinning a version, the runtime queries the registry for all registered versions of that capability and picks the latest one that satisfies the caller's placement constraints. If the caller pins to 1.0.0, the runtime resolves only that entry.
There's no CLI command for this — the registry is a Git-backed file tree, and deprecation is a PR that adds a sibling deprecated.json file next to that version's contract.json (the original contract is never modified). Once that lands, range-based resolution (like ^1.0.0) skips the deprecated version automatically. Callers pinned to the exact version, like 1.0.0, still resolve it successfully — deprecation removes a version from discovery, not from existence. Plan migrations before deprecating versions that active callers still pin to.
See also what is the contract lifecycle for the full picture from creation to retirement.
"; const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What is contract versioning in Traverse?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"Contract versioning in Traverse means each capability registration includes a semver version string. Multiple versions of the same capability can exist in the registry simultaneously. Callers can pin to a specific version or let the runtime select the latest version that satisfies their constraints.\"}}]}"; --- diff --git a/src/pages/questions/what-is-the-capability-registry.astro b/src/pages/questions/what-is-the-capability-registry.astro index de69e3c..1435963 100644 --- a/src/pages/questions/what-is-the-capability-registry.astro +++ b/src/pages/questions/what-is-the-capability-registry.astro @@ -1,7 +1,10 @@ --- import QuestionLayout from '@layouts/QuestionLayout.astro'; -const relatedLinks = []; +const relatedLinks = [ + { href: '/questions/what-happens-when-a-capability-version-is-revoked.html', label: 'What happens when a capability version is deprecated or revoked?' }, + { href: '/questions/does-the-registry-record-model-rights.html', label: 'Does the registry record model licenses and usage rights?' }, +]; const _body = "The capability registry is the catalog Traverse uses to discover, version, and select WASM capabilities at runtime. Every capability you register gets stored alongside its contract metadata so the runtime can make informed decisions before calling anything.
\n\nEach entry in the registry holds the capability name, version, the compiled WASM binary, and the full contract definition. The contract includes input schema, output schema, preconditions, postconditions, and placement constraints. Without all of this, the runtime cannot validate a call before it happens.
\n\nWhen a caller requests a capability, the runtime enters the discovering phase. It queries the registry for matching entries. Then it moves to evaluating_constraints to check which candidates satisfy the current environment. Finally it moves to selecting to pick the best match and then executing.
This means the registry is not just a lookup table. It is the gating mechanism for every execution. If no registered capability satisfies the constraints, the runtime fails fast rather than calling the wrong thing.
\n\nMultiple versions of the same capability can coexist in a registry. A caller can pin to a specific version or let the runtime select the latest that satisfies its constraints. This makes it safe to roll out new behavior gradually. Old consumers keep resolving to the version they are pinned to.
\n\nThe registry was extracted into its own repository, traverse-framework/registry, and this repo now consumes it as an externally published dependency rather than a workspace crate. You interact with it through the CLI or programmatically through the runtime API. The CLI command traverse-cli capability publish compiles your contract and binary and adds the entry via a governed PR-automation flow.
traverse-cli registry listThink of the registry as the source of truth for what capabilities exist and what they promise. The runtime enforces those promises at call time.
"; const _jsonLd = "{\"@context\":\"https://schema.org\",\"@type\":\"FAQPage\",\"mainEntity\":[{\"@type\":\"Question\",\"name\":\"What is the capability registry?\",\"acceptedAnswer\":{\"@type\":\"Answer\",\"text\":\"The capability registry is the catalog Traverse uses to discover, version, and select WASM capabilities at runtime. It stores contract metadata alongside each binary so the runtime can validate preconditions before execution and pick the right capability version for a given constraint set.\"}}]}"; ---