docs(site): Mon SEO — registry model rights + deprecated/revoked Q&As

public/llms.txt

@@ -43,6 +43,8 @@ Current packages: crates.io at 0.14.0 (pin `traverse-registry` at `=0.25.0` if y
 - [How do I author a capability in plain English?](https://traverse-framework.com/questions/how-do-i-author-a-capability-in-plain-english.html): Claude skill `traverse-capability-author` — interview → registry check → contract → WASM → human-reviewed PR; under the hood still Rust→WASM; manual Rust is secondary.
 - [How do I go from a skill draft to a published capability?](https://traverse-framework.com/questions/how-do-i-go-from-skill-draft-to-published-capability.html): after the skill opens the registry PR — review, CI, human merge, next catalog release; no side-door upload.
 - [Does capability publish validate model attribution before the registry write?](https://traverse-framework.com/questions/does-capability-publish-validate-model-attribution.html): yes for contract-decidable rules — `traverse-cli capability publish` rejects bad `ai` objects offline before any registry Git write (Decision 109 / Spec 056 v1.1.0 / #1597); keeps `ai` verbatim; evidence digests + rights drift stay registry-CI-only (no CLI network fetch).
+- [Does the Traverse registry record model licenses and usage rights?](https://traverse-framework.com/questions/does-the-registry-record-model-rights.html): yes, registry-side (registry spec 026): model-backed contracts declare commercial_use/redistribution/derivatives (`unknown` rejected), LICENSE/NOTICE pinned by sha256, immutable upstream commit, derivation, contract bytes signed; index `usage_class`; signed maintainer declaration, not legal certification; Traverse CLI/runtime enforcement is traverse#1598 (not shipped).
+- [What happens when a registry capability version is deprecated or revoked?](https://traverse-framework.com/questions/what-happens-when-a-capability-version-is-revoked.html): nothing is edited or deleted; `deprecated.json` / `revoked.json` siblings; range resolution skips both; 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 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.

src/pages/questions/does-capability-publish-validate-model-attribution.astro

@@ -21,6 +21,7 @@ const relatedLinks = [
   { href: '/questions/is-production-model-signing-ready.html', label: 'Is production model signing ready?' },
   { href: '/questions/what-is-exact-ref-model-execution.html', label: 'What is exact-ref model execution?' },
   { href: '/questions/how-do-hosts-trust-signed-models.html', label: 'How do hosts trust signed models?' },
+  { href: '/questions/does-the-registry-record-model-rights.html', label: 'Does the registry record model licenses and usage rights?' },
 ];
 ---
 <QuestionLayout

src/pages/questions/does-the-registry-record-model-rights.astro

@@ -0,0 +1,59 @@
+---
+import QuestionLayout from '@layouts/QuestionLayout.astro';
+
+const jsonLd = JSON.stringify({
+  '@context': 'https://schema.org',
+  '@type': 'FAQPage',
+  mainEntity: [{
+    '@type': 'Question',
+    name: 'Does the Traverse registry record model licenses and usage rights?',
+    acceptedAnswer: {
+      '@type': 'Answer',
+      text: 'Yes, on the registry side. Registry spec 026 (model rights compliance) requires every newly added model-backed contract to declare commercial_use, redistribution and derivatives for each ai.models entry, with unknown rejected. It also pins LICENSE and NOTICE files by sha256, requires an immutable upstream commit, records how shipped weights were derived, and signs the contract bytes so the rights record is authenticated. The index projects a usage_class (unrestricted, evaluation-only or conditional). The record is a signed maintainer declaration, not a legal certification. Traverse CLI inspection and runtime enforcement are tracked in traverse#1598 and are not shipped yet.',
+    },
+  }],
+});
+
+const relatedLinks = [
+  { href: '/questions/does-capability-publish-validate-model-attribution.html', label: 'Does capability publish validate model attribution?' },
+  { href: '/questions/what-happens-when-a-capability-version-is-revoked.html', label: 'What happens when a capability version is deprecated or revoked?' },
+  { href: '/questions/how-do-i-verify-a-signed-capability-artifact.html', label: 'How do I verify a signed capability artifact?' },
+  { href: '/questions/what-is-the-capability-registry.html', label: 'What is the capability registry?' },
+  { href: '/questions/can-i-use-traverse-commercially.html', label: 'Can I use Traverse commercially?' },
+];
+---
+<QuestionLayout
+  title="Does the Traverse registry record model licenses and usage rights?"
+  description="Yes. Registry spec 026 makes model-backed contracts declare commercial use, redistribution and derivative rights, pins LICENSE/NOTICE by digest, and signs the contract. Traverse-side enforcement is still open (traverse#1598)."
+  canonical="https://traverse-framework.com/questions/does-the-registry-record-model-rights.html"
+  category="Contracts and Capabilities"
+  relatedLinks={relatedLinks}
+  jsonLd={jsonLd}
+>
+  <p><strong>Short answer:</strong> 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 <strong>026-model-rights-compliance</strong> turns each <code>ai.models</code> 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.</p>
+
+  <h2>What a model-backed contract has to declare</h2>
+  <p>Registry CI checks every <em>newly added</em> contract with <code>ai.model_backed: true</code>. Each model entry must carry:</p>
+  <ul>
+    <li><strong><code>commercial_use</code>, <code>redistribution</code>, <code>derivatives</code></strong>, each <code>allowed</code>, <code>forbidden</code> or <code>conditional</code>. <code>unknown</code> fails validation, because the registry won't redistribute weights on unknown rights.</li>
+    <li><strong>LICENSE and NOTICE files</strong> as <code>{"{url, sha256}"}</code> on registry Release assets. CI downloads them and checks the digest. NOTICE is required when attribution is required.</li>
+    <li><strong>An immutable upstream pin</strong>: a full commit id, not a branch or tag.</li>
+    <li><strong>A <code>derivation</code></strong> (or an explicit <code>null</code>) describing how the shipped weights differ from upstream, for example quantization or format conversion, with the converted digest.</li>
+    <li>Optional <strong><code>data_obligations</code></strong> for training or label data terms.</li>
+  </ul>
+  <p>CI also rejects contradictions it can decide without guessing, such as <code>redistribution: forbidden</code> (publishing is redistribution) or a derivation on a model marked <code>derivatives: forbidden</code>. It does not infer rights from an SPDX identifier.</p>
+
+  <h2>How consumers read it</h2>
+  <p>The registry index projects a <code>usage_class</code> for each model reference from those three fields alone: <code>unrestricted</code> when all are allowed, <code>evaluation-only</code> when commercial use is forbidden, and <code>conditional</code> otherwise. The consumer guidance in the spec is deny-by-default on <code>conditional</code>.</p>
+  <p>New <code>signature.json</code> files also sign the contract itself: an Ed25519 signature over the SHA-256 of the exact committed <code>contract.json</code> bytes, with the same registry key that signs artifacts. That is what authenticates the rights fields, not just the WASM bytes.</p>
+
+  <h2>What it is not</h2>
+  <p>The record is a <strong>maintainer-declared</strong>, 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.</p>
+
+  <h2>What is still open (as of October 5, 2026)</h2>
+  <ul>
+    <li><strong>Traverse-side enforcement.</strong> Showing the full rights record in <code>traverse-cli</code>, honoring <code>revoked</code> at runtime, and verifying the contract signature are tracked in <a href="https://github.com/traverse-framework/traverse/issues/1598">traverse#1598</a>. They are not in a published Traverse release yet.</li>
+    <li><strong>Existing agents.</strong> Already-published versions are never judged retroactively. The five existing model-backed agents get compliant new MINOR versions under <a href="https://github.com/traverse-framework/registry/issues/623">registry#623</a>.</li>
+  </ul>
+  <p>The publish path already checks the parts of this record that the contract alone can decide, offline: see <a href="/questions/does-capability-publish-validate-model-attribution.html">Does capability publish validate model attribution?</a>.</p>
+</QuestionLayout>

src/pages/questions/index.astro

@@ -33,6 +33,8 @@ const groups = [
       ['how-do-i-write-a-capability-contract.html', 'How do I write a capability contract?'],
       ['how-do-i-publish-a-capability-to-the-registry.html', 'How do I publish a capability to the Traverse registry?'],
       ['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-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?'],

src/pages/questions/what-happens-when-a-capability-version-is-revoked.astro

@@ -0,0 +1,51 @@
+---
+import QuestionLayout from '@layouts/QuestionLayout.astro';
+
+const jsonLd = JSON.stringify({
+  '@context': 'https://schema.org',
+  '@type': 'FAQPage',
+  mainEntity: [{
+    '@type': 'Question',
+    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.',
+    },
+  }],
+});
+
+const relatedLinks = [
+  { 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?' },
+  { href: '/questions/how-do-i-publish-a-capability-to-the-registry.html', label: 'How do I publish a capability to the registry?' },
+];
+---
+<QuestionLayout
+  title="What happens when a registry capability version is deprecated or revoked?"
+  description="Versions are never edited or deleted. Deprecated and revoked versions drop out of range resolution, while exact pins still resolve with a status the runtime can act on. Traverse-side revoked handling is tracked in traverse#1598."
+  canonical="https://traverse-framework.com/questions/what-happens-when-a-capability-version-is-revoked.html"
+  category="Contracts and Capabilities"
+  relatedLinks={relatedLinks}
+  jsonLd={jsonLd}
+>
+  <p><strong>Short answer:</strong> 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.</p>
+
+  <h2>Deprecated: the cargo-yank shape</h2>
+  <p>Registry spec 005 adds a sibling <code>deprecated.json</code> next to the version's <code>contract.json</code>. The index marks the version deprecated. Range resolution (<code>^1.2.0</code> 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.</p>
+  <p>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.</p>
+
+  <h2>Revoked: a stronger signal for rights problems</h2>
+  <p>Registry spec 026 adds a sibling <code>revoked.json</code> with a <code>reason</code>, an <code>evidence_url</code> and a <code>revoked_at</code> time. It's meant for cases like a model whose rights turned out to be wrong. The index keeps the entry with <code>status: "revoked"</code>, its revocation record and its full rights record, and it must never be presented as active.</p>
+  <p>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.</p>
+
+  <h2>Where this stands today (October 5, 2026)</h2>
+  <ul>
+    <li><strong>Registry side:</strong> the <code>revoked.json</code> marker, index <code>status</code>, and the crate types have landed on the registry's main branch. The published <code>traverse-registry</code> crate on crates.io is still 0.25.0.</li>
+    <li><strong>Exact-pin alignment:</strong> 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 <a href="https://github.com/traverse-framework/registry/issues/631">registry#631</a>.</li>
+    <li><strong>Traverse side:</strong> honoring <code>revoked</code> in the runtime and showing lifecycle status in <code>traverse-cli</code> is <a href="https://github.com/traverse-framework/traverse/issues/1598">traverse#1598</a>, not shipped yet.</li>
+  </ul>
+
+  <h2>Related</h2>
+  <p>How versions and ranges work in general: <a href="/questions/what-is-contract-versioning.html">What is contract versioning?</a>. The rights record a revocation usually concerns: <a href="/questions/does-the-registry-record-model-rights.html">Does the registry record model licenses and usage rights?</a>.</p>
+</QuestionLayout>

src/pages/questions/what-is-contract-versioning.astro

@@ -1,7 +1,9 @@
 ---
 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?' },
+];
 const _body = "<p>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.</p>\n\n      <h2>Why versioning matters</h2>\n      <p>Business 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.</p>\n\n      <h2>How version selection works</h2>\n      <p>When a caller requests <code>calculate_price</code> 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 <code>1.0.0</code>, the runtime resolves only that entry.</p>\n\n      <h2>Breaking vs. non-breaking changes</h2>\n      <ul>\n        <li>Adding an optional input field — non-breaking, patch or minor bump</li>\n        <li>Removing a required input field — non-breaking for callers, minor bump</li>\n        <li>Adding a required input field — breaking for existing callers, major bump</li>\n        <li>Changing output field types — breaking, major bump</li>\n        <li>Tightening preconditions — breaking for callers that relied on the looser constraint</li>\n      </ul>\n\n      <h2>Retiring old versions</h2>\n      <p>There's no CLI command for this — the registry is a Git-backed file tree, and deprecation is a PR that adds a sibling <code>deprecated.json</code> file next to that version's <code>contract.json</code> (the original contract is never modified). Once that lands, range-based resolution (like <code>^1.0.0</code>) skips the deprecated version automatically. Callers pinned to the exact version, like <code>1.0.0</code>, still resolve it successfully — deprecation removes a version from discovery, not from existence. Plan migrations before deprecating versions that active callers still pin to.</p>\n\n      <p>See also <a href=\"/questions/what-is-the-contract-lifecycle.html\">what is the contract lifecycle</a> for the full picture from creation to retirement.</p>";
 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.\"}}]}";
 ---