docs(fleet): add the interop / portable-credential page

src/components/docs/nav.ts

@@ -496,6 +496,11 @@ export const DOCS_NAV: DocsSection[] = [
                 label: 'Compliance crosswalk',
                 blurb: 'Fleet artifacts mapped to EU AI Act / SOC 2 / NIST AI RMF — with honest rails. The procurement exit.',
             },
+            {
+                href: '/fleet/interop',
+                label: 'Interop credential',
+                blurb: 'How an OC delegation+bond rides into x402 / AP2 / A2A / ERC-8004 as a portable, offline-verifiable credential. Design intent.',
+            },
             {
                 href: '/fleet/webhooks',
                 label: 'Webhooks',

src/pages/fleet/interop.mdx

@@ -0,0 +1,69 @@
+export const metadata = {
+    title: 'Fleet interop — the portable credential',
+    description:
+        'How an OC delegation + bond is designed to ride inside the agent rails that win — x402, Google AP2, A2A AgentCards, ERC-8004 — as a settlement-agnostic, offline-verifiable credential. Design intent and the current status, stated plainly.',
+};
+
+# Interop — the portable credential
+
+> **Status: design intent, not a shipped API.** This page describes how fleet is
+> meant to compose with the wider agent ecosystem. The bond + delegation
+> primitives it builds on are live (see [Bond verification](/fleet/bond)); the
+> credential-attachment helpers below are a roadmap item, not something you can
+> `import` today. Where that matters, it's called out.
+
+## The position
+
+fleet does not compete with the rails that move money or mint agent identities.
+It sits **above settlement** and **beside the IdP**: the one thing those rails
+deliberately skip is _does this agent have something to lose, and can a
+counterparty verify that without trusting anyone?_ (see the [overview](/fleet)).
+
+The corollary is that an OC delegation + bond should be **portable** — a small,
+offline-verifiable credential that travels inside whatever rail an agent is
+already using, rather than asking anyone to adopt a new one. An OC artifact is
+content-addressed and BIP-322-signed, so it verifies the same way no matter what
+carries it.
+
+## Where the credential is designed to ride
+
+| Rail                         | What it does                                                | Where OC attaches (designed)                                                                                                                       |
+| ---------------------------- | ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| **x402** (Coinbase / Circle) | HTTP 402 stablecoin settlement; no reputation/bonding layer | An OC delegation+bond id as a request header field — the payer's agent presents verifiable standing alongside payment.                             |
+| **Google AP2**               | Signed Mandates proving a human authorized _this_ purchase  | An OC bond reference annotating a mandate — adds standing skin-in-the-game the mandate itself does not assert.                                     |
+| **A2A (agent-to-agent)**     | AgentCards describing an agent's capabilities               | An OC delegation+bond claim in the AgentCard — a counterparty agent weighs the bond before transacting.                                            |
+| **ERC-8004** (EVM, on-chain) | Identity + Reputation + Stake registries                    | An OC artifact as an **off-chain attestation** referenced from the registry — bitcoin-rooted, no-custody, no-token, alongside the on-chain record. |
+
+In every case the carrier is opaque to the trust claim: the relying party
+fetches the referenced OC delegation + bond, re-derives its id, re-checks the
+BIP-322 signature, and re-resolves the bond against live bitcoin UTXO state —
+exactly as described in [Bond verification](/fleet/bond). The rail moves the
+value or the identity; OC supplies the verifiable accountability, and it does so
+without OC, or the rail, being trusted.
+
+## Why "ride into" rather than "replace"
+
+The only credible bitcoin-neutral competitor is ERC-8004 (mainnet 2026:
+Identity + Reputation + Stake). It is custodial (locked-token staking), has a
+token, and is EVM-only. fleet's primitives win where those are liabilities — no
+custody, no token, offline-verifiable, bitcoin-rooted — and the way to express
+that advantage is **not** to ask the ecosystem to switch rails. It is to make
+the OC credential cheap to attach to the rails already winning. A bond is worth
+more as a field in a header everyone already sends than as a standard nobody
+adopts.
+
+## What exists today vs. what's designed
+
+- **Live now:** the delegation and bond primitives, content-addressed and
+  offline-verifiable; `GET /api/bond` to re-resolve a bond from anywhere; the
+  client-side [verifier](https://fleet.ochk.io/verify).
+- **Designed (roadmap):** the thin attachment helpers — encoders/decoders that
+  pack an OC delegation+bond reference into an x402 header field, an AP2 mandate
+  annotation, an A2A AgentCard claim, or an ERC-8004 off-chain attestation, plus
+  the relying-party verifiers for each. These ship as a small package when the
+  rails' formats stabilize; this page will move from "designed" to "live" then.
+
+If you're building on one of these rails today and want the OC credential in it,
+the primitive you need already exists — the bond is verifiable from any context
+via `/api/bond`. Talk to us about the carrier format; that's the part still
+settling.