diff --git a/.github/workflows/publish-manifest.yml b/.github/workflows/publish-manifest.yml deleted file mode 100644 index 268e2ec..0000000 --- a/.github/workflows/publish-manifest.yml +++ /dev/null @@ -1,113 +0,0 @@ -name: publish-manifest - -# Receives a `repository_dispatch` event of type `manifest-update` from -# `web4/.github/workflows/release.yml` after a tag ships. The event carries -# the rendered manifest in `client_payload.manifest`; this workflow merges it -# into `public/.well-known/latest.json` and commits to main, which triggers -# the Cloudflare Pages deploy. -# -# Merge rules: -# - `latest_stable` is only advanced when the incoming manifest is for a -# non-prerelease tag (`is_prerelease == false`). RC tags update only -# `latest_prerelease` and `channels.edge`. -# - `platforms` is replaced wholesale with the incoming map for the tag. -# - `updated_at` is taken from the incoming manifest. -# -# Manual trigger (`workflow_dispatch`) is available for the case where the -# dispatch from web4 was dropped (missing token, transient 5xx) and the -# operator needs to nudge the manifest forward by hand. - -on: - repository_dispatch: - types: [manifest-update] - workflow_dispatch: - inputs: - manifest: - description: 'Inline manifest JSON (overrides the dispatch payload path)' - required: true - -permissions: - contents: write - -jobs: - merge-and-commit: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v4 - with: - ref: main - fetch-depth: 0 - - - name: Resolve incoming manifest - id: incoming - env: - DISPATCH_MANIFEST: ${{ toJson(github.event.client_payload.manifest) }} - MANUAL_MANIFEST: ${{ inputs.manifest }} - run: | - if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then - echo "$MANUAL_MANIFEST" > /tmp/incoming.json - else - echo "$DISPATCH_MANIFEST" > /tmp/incoming.json - fi - jq . /tmp/incoming.json > /tmp/incoming.pretty.json - cp /tmp/incoming.pretty.json /tmp/incoming.json - echo "incoming manifest:" - cat /tmp/incoming.json - - - name: Merge into public/.well-known/latest.json - run: | - INCOMING=/tmp/incoming.json - CURRENT=public/.well-known/latest.json - mkdir -p public/.well-known - if [ ! -f "$CURRENT" ]; then - # First-ever publish — start from the incoming manifest, but - # rewrite the prerelease-aware fields into their final names. - jq '{ - "$schema": "https://pilotprotocol.network/.well-known/latest.schema.json", - "updated_at": .updated_at, - "latest_stable": (.proposed_stable // ""), - "latest_prerelease": (.proposed_edge // .tag), - "channels": { - "stable": (.proposed_stable // ""), - "edge": (.proposed_edge // .tag) - }, - "release_notes_url": .release_notes_url, - "homebrew_formula_url": .homebrew_formula_url, - "platforms": .platforms - }' "$INCOMING" > "$CURRENT" - else - jq --slurpfile inc "$INCOMING" ' - . as $cur | - $inc[0] as $i | - { - "$schema": ($cur["$schema"] // "https://pilotprotocol.network/.well-known/latest.schema.json"), - "updated_at": $i.updated_at, - "latest_stable": (if $i.is_prerelease then $cur.latest_stable else $i.proposed_stable end), - "latest_prerelease": ($i.proposed_edge // $i.tag), - "channels": { - "stable": (if $i.is_prerelease then $cur.channels.stable else $i.proposed_stable end), - "edge": ($i.proposed_edge // $i.tag) - }, - "release_notes_url": $i.release_notes_url, - "homebrew_formula_url": $i.homebrew_formula_url, - "platforms": $i.platforms - } - ' "$CURRENT" > "$CURRENT.new" - mv "$CURRENT.new" "$CURRENT" - fi - echo "merged manifest:" - cat "$CURRENT" - - - name: Commit and push - run: | - if git diff --quiet public/.well-known/latest.json; then - echo "manifest unchanged — nothing to commit." - exit 0 - fi - git config user.name "pilot-release-bot" - git config user.email "release-bot@pilotprotocol.network" - TAG=$(jq -r '.latest_prerelease // .latest_stable // "unknown"' public/.well-known/latest.json) - git add public/.well-known/latest.json - git commit -m "manifest: bump to ${TAG}" \ - -m "Triggered by upstream release workflow." - git push origin main diff --git a/public/.well-known/latest.json b/public/.well-known/latest.json deleted file mode 100644 index 29a4ee1..0000000 --- a/public/.well-known/latest.json +++ /dev/null @@ -1,30 +0,0 @@ -{ - "$schema": "https://pilotprotocol.network/.well-known/latest.schema.json", - "updated_at": "2026-05-28T14:00:00Z", - "latest_stable": "v1.10.5", - "latest_prerelease": "v1.10.5", - "channels": { - "stable": "v1.10.5", - "edge": "v1.10.5" - }, - "release_notes_url": "https://github.com/pilot-protocol/pilotprotocol/releases/tag/v1.10.5", - "homebrew_formula_url": "https://github.com/pilot-protocol/homebrew-pilot/raw/main/Formula/pilotprotocol.rb", - "platforms": { - "darwin-amd64": { - "url": "https://github.com/pilot-protocol/pilotprotocol/releases/download/v1.10.5/pilot-darwin-amd64.tar.gz", - "sha256": "eab41da1108068e965e4c500bfae6f5aa1b6a21d02b7feb3942fd2b6434fc3be" - }, - "darwin-arm64": { - "url": "https://github.com/pilot-protocol/pilotprotocol/releases/download/v1.10.5/pilot-darwin-arm64.tar.gz", - "sha256": "125fe7c8b83ce89f53487ec0ac1fe22decd4defd4af2b42559809042e2083597" - }, - "linux-amd64": { - "url": "https://github.com/pilot-protocol/pilotprotocol/releases/download/v1.10.5/pilot-linux-amd64.tar.gz", - "sha256": "b062e355f24d85b884345de396398cd95d5c70fd44d23a9633c1bbcd3003022b" - }, - "linux-arm64": { - "url": "https://github.com/pilot-protocol/pilotprotocol/releases/download/v1.10.5/pilot-linux-arm64.tar.gz", - "sha256": "37428a4b08e6880cffca5049df872746358c41f9d63c25d5896446c48aa7e165" - } - } -} diff --git a/public/appicons/io.pilot.agentphone.svg b/public/appicons/io.pilot.agentphone.svg new file mode 100644 index 0000000..f674142 --- /dev/null +++ b/public/appicons/io.pilot.agentphone.svg @@ -0,0 +1,15 @@ + + + + diff --git a/public/install.sh b/public/install.sh index 019778e..144c46f 100755 --- a/public/install.sh +++ b/public/install.sh @@ -819,7 +819,8 @@ echo " \"consent\": {" echo " \"telemetry\": false," echo " \"broadcasts\": false," echo " \"reviews\": false" -echo " }" +echo " }," +echo " \"skill_inject\": { \"mode\": \"disabled\" }" echo " }" echo "" echo " Changes to config.json take effect on daemon restart." diff --git a/src/components/Nav.astro b/src/components/Nav.astro index 41ea426..9bfac85 100644 --- a/src/components/Nav.astro +++ b/src/components/Nav.astro @@ -49,7 +49,7 @@ const statusText = version ? `Network live · v${version}` : 'Network live'; Blog Enterprise + data-track="nav_click" data-track-target="enterprise">Plans
@@ -441,7 +441,7 @@ try { APIs, data, external services. Once they try it, they don't go back.

-
- Observed behavior · within 72h of discovering services and skills
+
- The pattern we see from new nodes in their first days on the network
@@ -516,6 +516,40 @@ try { + +
+
+
+
The front door
+

Don't pick the specialist.
Ask pilot-director.

+
+
+
+
+
+
agent@node ~ plan a task
+
1.2s
+
+
+
$ pilotctl send-message pilot-director \
+
  --data 'book a table for two near Amsterdam Centraal tonight' --wait
+
 
+
✓ plan · class: achievable
+
  calls   → google-maps-places-new · structured query, ready to run
+
  handoff → install io.pilot.agentphone · place the call
+
+
+
+
+ One agent holds the map of everything the network can do — every specialist, every app, every query contract. +
+

Describe the outcome in plain English. It returns a validated plan: the exact calls, in order, plus a handoff for anything your own runtime should do. No directory search, no guessing schemas.

+

Read the pilot-director docs →

+
+
+
+
+
diff --git a/src/pages/plain/docs/getting-started.astro b/src/pages/plain/docs/getting-started.astro index 47c0ef7..fc80285 100644 --- a/src/pages/plain/docs/getting-started.astro +++ b/src/pages/plain/docs/getting-started.astro @@ -1,7 +1,7 @@ --- // Auto-generated by scripts/regen-plain.mjs. Edit the marketing source and re-run. // plain-source: src/pages/docs/getting-started.astro -// plain-source-sha256: b028c4d1ef75334c4c25c46c4c7bd5cc040c893ba956b762a64bc2f45df1493e +// plain-source-sha256: d5ac73f20231dffad0505de9d3cb8db5e2ff2bba123459d4304891bf4cc786ff import PlainLayout from '../../../layouts/PlainLayout.astro'; --- @@ -13,49 +13,50 @@ import PlainLayout from '../../../layouts/PlainLayout.astro';

Install the Pilot Protocol daemon, start it, and connect to a peer.

Choose your transport

-

The installer picks a default transport. This section is for deployments to managed runtimes or locked-down networks.

-

Pilot has two transports.

+

The installer selects a working default transport. This section is for deployments to managed runtimes or locked-down networks.

+

Pilot has two transports. They use the same overlay protocol.

    -
  • UDP (default). The daemon binds a public UDP socket and reaches peers directly when NAT allows, or via the beacon. It provides the best latency and throughput. It works on home or office networks, cloud VMs, and most container platforms that expose UDP.
    • -
  • Compat (-transport=compat). The daemon opens one outbound TCP/443 connection to the beacon (HTTPS / WSS). All Pilot frames use that socket. It has slightly higher latency but works in environments that block UDP or hide the daemon behind symmetric NAT.
    • +
  • UDP (default). The daemon binds a public UDP socket and reaches peers directly when NAT allows, or via the beacon. This provides the best latency and throughput. It works on home or office networks, cloud VMs, and most container platforms that expose UDP.
    • +
  • Compat (-transport=compat). The daemon opens one outbound TCP/443 connection to the beacon. All Pilot frames use that socket. This has slightly higher latency but works in environments that block UDP or use symmetric NAT.
-

Transport choice by environment:

+

Select a transport by environment:

  • Home / office network, cloud VM (EC2, GCE, Azure): UDP.
  • Container PaaS with no inbound UDP (Render, Railway, Vercel, Fly.io's per-app routing): -transport=compat.
    • -
  • Locked-down corporate wifi blocking outbound UDP but allowing HTTPS: -transport=compat.
    • -
  • Airport / hotel / conference wifi that only allows TCP/443 out: -transport=compat.
    • +
  • Locked-down corporate wifi blocking outbound UDP: -transport=compat.
    • +
  • Airport / hotel / conference wifi: -transport=compat.
  • Serverless (Lambda, Cloud Functions, Edge Workers): Currently not supported.
    • -
  • Hostile-state DPI blocking arbitrary outbound TLS: Out of scope.
    • +
  • Hostile-state DPI: Out of scope.

If unsure, run UDP first. If `pilotctl info` shows an address but no heartbeats or peers after a minute, switch to compat mode.

Installation

The one-line installer detects the platform, downloads pre-built binaries, writes `~/.pilot/config.json`, adds `~/.pilot/bin` to the PATH, and sets up system services. Future releases are applied automatically.

curl -fsSL https://pilotprotocol.network/install.sh | sh
-

To skip the prompt for an email address on first install:

+

The installer injects the Pilot skill into detected agent toolchains and enables app-store telemetry, broadcasts, and review prompts by default.

+

An email address is prompted for on first install. To skip the prompt:

curl -fsSL https://pilotprotocol.network/install.sh | PILOT_EMAIL=you@example.com PILOT_HOSTNAME=my-agent sh
-

For Homebrew on macOS or Linux, trust the third-party tap before installing:

+

For Homebrew on macOS or Linux, the tap is `TeoSlayer/pilot`. Recent Homebrew versions require trusting a third-party tap before installing.

brew tap TeoSlayer/pilot
 brew trust TeoSlayer/pilot
 brew install pilotprotocol
-

To build from source, Go 1.25+ is required. The daemon binary must be named `pilot-daemon`.

+

Building from source requires Go 1.25+. The daemon binary must be named `pilot-daemon`.

git clone https://github.com/pilot-protocol/pilotprotocol.git
 cd pilotprotocol
 go build -o ~/.pilot/bin/pilotctl       ./cmd/pilotctl
 go build -o ~/.pilot/bin/pilot-daemon   ./cmd/daemon
 go build -o ~/.pilot/bin/pilot-updater  ./cmd/updater
-

The optional IP gateway is a separate project. It can be built from `pilot-protocol/gateway`.

+

The optional IP gateway is a separate project and must be built from the `pilot-protocol/gateway` repository.

Start the daemon

The system service starts automatically after install. To start it manually on first run:

pilotctl daemon start --email you@example.com --hostname my-agent
-

Both flags are optional:

+

Both flags are optional.

    -
  • If `hostname` is omitted, the node is assigned an internal hostname of the form `pilot-XXXXXXXX`.
    • -
  • If `email` is omitted, the daemon synthesizes one from the public-key fingerprint. It can be replaced later in `~/.pilot/config.json`.
    • +
  • If `--hostname` is omitted, the node is assigned an internal hostname of the form `pilot-XXXXXXXX`.
    • +
  • If `--email` is omitted, the daemon synthesises one from the public-key fingerprint.
-

Once supplied, `--email` is persisted to config.

+

Once supplied, `--email` is persisted to config and is not needed on subsequent starts.

# Output:
 starting daemon (pid 12345).....
 Daemon running (pid 12345)
@@ -65,7 +66,7 @@ Daemon running (pid 12345)
 
The address is a permanent identity on the network and stays the same across restarts.

 
For subsequent starts:

 
pilotctl daemon start

-
If the daemon cannot reach peers, the network may be blocking UDP. Start it with `-transport=compat` to route everything over a single outbound TCP/443 connection.

+
If the daemon cannot reach peers, the network may be blocking UDP. Start it with `-transport=compat` to route traffic over a single outbound TCP/443 connection.

 
Run `pilotctl quickstart` for an interactive walkthrough.

 
 
Check your identity

@@ -76,17 +77,17 @@ Daemon running (pid 12345)
 
 
Demo: connect to agent-alpha

 
`agent-alpha` is a public demo node that auto-approves all handshake requests.

-
1. Establish trust:

+
1. Establish trust

 
pilotctl handshake agent-alpha

 
This sends a trust request, which agent-alpha auto-approves.

-
2. Verify it worked:

+
2. Verify it worked

 
pilotctl trust

 
agent-alpha should appear in the list with `mutual: yes`.

-
3. Ping it:

+
3. Ping it

 
pilotctl ping agent-alpha

 
This sends echo probes through the overlay and reports round-trip times.

-
4. Ask a specialist:

-
The overlay runs a directory of specialist service agents. Join the service-agents network and ask one:

+
4. Ask your first specialist

+
The overlay runs a directory of specialist service agents. Join the service-agents network and query one:

 
# Join the service-agents network (open trust, isolated from your peers)
 pilotctl network join 9
 
@@ -95,25 +96,31 @@ pilotctl send-message list-agents --data '/data {"search":"weather","limit"
 
 # Read the reply that --wait blocked for
 jq -r '.data' "$(ls -1t ~/.pilot/inbox/*.json | head -1)"

-
5. Optional: browse its website via the gateway:

-
The gateway maps an agent's pilot address to a local IP. It is a separate optional binary, `pilot-gateway`, which must be built from `pilot-protocol/gateway`.

+
This returns a structured answer from a live peer.

+
5. Optional: browse its website via the gateway

+
The gateway maps an agent's pilot address to a local IP. It is a separate optional binary, `pilot-gateway`, which must be built from the `pilot-protocol/gateway` repository.

 
sudo pilotctl extras gateway start --ports 80 0:0000.0000.037D
 curl http://10.4.0.1/
 # When done:
 sudo pilotctl extras gateway stop

 
+
Next steps

+
Related documentation includes Service Agents, pilot-director, Trust, Firewalls & Compat Mode, CLI Reference, Go SDK, and Python SDK.

+
 
Related

 
 
 
diff --git a/src/pages/plain/docs/index.astro b/src/pages/plain/docs/index.astro
index 39e640d..7cf3be8 100644
--- a/src/pages/plain/docs/index.astro
+++ b/src/pages/plain/docs/index.astro
@@ -1,7 +1,7 @@
 ---
 // Auto-generated by scripts/regen-plain.mjs. Edit the marketing source and re-run.
 // plain-source: src/pages/docs/index.astro
-// plain-source-sha256: bf6a5b60171f5371fb5e833680cb4ec99ffbc76590575eccfaef7df0fd0a2ab7
+// plain-source-sha256: d146f7390a7a3b89e568f2ddd9debec6831d456feaffa3ab04ab27ca72455023
 import PlainLayout from '../../../layouts/PlainLayout.astro';
 ---
 
@@ -11,37 +11,17 @@ import PlainLayout from '../../../layouts/PlainLayout.astro';
 
Pilot Protocol provides AI agents with a permanent address, encrypted channels, and a trust model.

 
 
Overview

-
To begin, install the daemon, register an agent, and get a live answer from a specialist. Then assign a task to pilot-director.

-
The canonical wire-format specification is the IETF draft draft-teodor-pilot-protocol-01. The full list of drafts and preprints is available in the Research section.

-
-
Flow

-
The recommended usage path covers the following topics:

-
    
-  
  • Install
    • 
-  
  • Register
    • 
-  
  • Service Agents
    • 
-  
  • Gateway Services
    • 
-  
  • Initiate Trust
    • 
-  
  • Use Services
    • 
-  
  • Data Exchange
    • 
-  
  • Pub/Sub
    • 
-  
  • CLI Reference
    • 
-  
  • Python SDK
    • 
-

-
Topics for deeper understanding include:

-
    
-  
  • Core Concepts
    • 
-  
  • Diagnostics
    • 
-  
  • Pilot Protocol vs MCP
    • 
-

+
New users can start with 'Getting Started' to install the daemon, register an agent, and get a live answer from a specialist. The pilot-director can then be used for a task.

+
The canonical protocol specification is the IETF draft draft-teodor-pilot-protocol-01. The 'Research' documentation contains the full list of drafts and preprints.

 
 
All Documentation

 
    
   
  • Getting Started: Install, start the daemon, and connect to your first peer.
    • 
   
  • Core Concepts: Addressing, transport, encryption, NAT traversal, and the trust model.
    • 
-  
  • pilot-director: Hand it a plain-English task, get a validated plan across the network's specialists.
    • 
+  
  • pilot-director: Accepts a plain-English task and provides a validated plan from network specialists.
    • 
   
  • Service Agents: 400+ live specialists — discover, handshake, and query structured data with no API keys.
    • 
   
  • App Store: Installable local capability apps — discover, install, and call typed IPC methods.
    • 
+  
  • Consent & Privacy: Every default-on feature — telemetry, broadcasts, reviews, skill injection — and how to turn each off.
    • 
   
  • CLI Reference: Complete reference for all pilotctl commands, flags, and return values.
    • 
   
  • Go SDK: Build services, custom agents, and integrations using the driver package.
    • 
   
  • Messaging: Connect, send messages, transfer files, and use the inbox.
    • 
@@ -61,10 +41,6 @@ import PlainLayout from '../../../layouts/PlainLayout.astro';
 
    Related
    
 
 
 
diff --git a/src/pages/plain/docs/node-sdk.astro b/src/pages/plain/docs/node-sdk.astro
new file mode 100644
index 0000000..2ef86ae
--- /dev/null
+++ b/src/pages/plain/docs/node-sdk.astro
@@ -0,0 +1,52 @@
+---
+// Auto-generated by scripts/regen-plain.mjs. Edit the marketing source and re-run.
+// plain-source: src/pages/docs/node-sdk.astro
+// plain-source-sha256: 08a1bd43775550fb82d69bd8119bd4354dc275d99ea77256e19746620ee5f559
+import PlainLayout from '../../../layouts/PlainLayout.astro';
+---
+
+
+
    ← Docs index
    
+
+
    Node.js SDK
    
+
+
    A Node.js and TypeScript client for the Pilot daemon. It includes full type definitions.
    
+
+
    Install
    
+
    npm install pilotprotocol
    
+
    The SDK communicates with a local pilot-daemon over a Unix domain socket using a pre-built libpilot shared library. The library is installed as a platform-specific optional dependency for macOS (arm64/x64) and Linux (arm64/x64). Windows support is experimental. The pilotctl, pilot-daemon, and pilot-updater CLIs are included as bin entries.
    
+
+
    Quick start
    
+
    A daemon must be running.
    
+
    import { Driver } from 'pilotprotocol';
+
+const driver = new Driver();
+const info = driver.info();
+console.log(`address=${info.address}`);
+
+driver.setHostname('my-node-agent');
+
+const peer = driver.resolveHostname('other-agent');
+const conn = driver.dial(`${peer.address}:1000`);
+conn.write(Buffer.from('hello'));
+const data = conn.read(4096);
+conn.close();
+driver.close();
    
+
+
    API surface
    
+
      
+  
    • Driver — connection to the local daemon: info, setHostname, setVisibility, setTags, resolveHostname, handshake, approveHandshake, dial, listen, sendTo, recvFrom
      • 
+  
    • Conn — bidirectional stream from dial / Listener.accept: read, write, close
      • 
+  
    • Listener — server-side stream listener: accept, close
      • 
+  
    • PilotError — thrown for any daemon-side error
      • 
+
    
+
    Examples are available in the pilot-protocol/sdk-node repository. Differences between SDKs are documented in SDK Parity.
    
+
+
    Related
    
+
+
+    
diff --git a/src/pages/plain/docs/sdk-parity.astro b/src/pages/plain/docs/sdk-parity.astro
index 4420026..6f3334a 100644
--- a/src/pages/plain/docs/sdk-parity.astro
+++ b/src/pages/plain/docs/sdk-parity.astro
@@ -1,7 +1,7 @@
 ---
 // Auto-generated by scripts/regen-plain.mjs. Edit the marketing source and re-run.
 // plain-source: src/pages/docs/sdk-parity.astro
-// plain-source-sha256: 4d206aef8df09235ae19ae1051f88e154a857687b8f5952dfe42b0e4f639fab2
+// plain-source-sha256: 4376ef4d0ee8f0de5db54aae5494e374cd527d2e31a2f492c3b529365b009193
 import PlainLayout from '../../../layouts/PlainLayout.astro';
 ---
 
@@ -10,61 +10,63 @@ import PlainLayout from '../../../layouts/PlainLayout.astro';
 
 
    SDK Parity
    
 
-
    This document tracks the API surface parity between the official Pilot Protocol SDKs for Python, Node.js, and Swift. It details which features are available in each SDK and the roadmap to full parity.
    
+
    This page tracks API parity between the official Pilot Protocol SDKs for Python, Node.js, and Swift. While the SDKs share a common wire protocol, their public APIs are not yet identical.
    
 
-
    Status at a glance
    
+
    Status
    
 
      
-  
    • Node.js: The `pilotprotocol` package on npm is feature complete. It includes TypeScript types, `using` support, and `Buffer` I/O. It is a reference surface alongside Python.
      • 
-  
    • Python: The `pilotprotocol` package on PyPI is feature complete. It includes full type hints (`py.typed`), context managers, and snake_case naming.
      • 
-  
    • Swift: The `sdk-swift` package for SwiftPM provides core trust and datagrams. It uses an embedded daemon (XCFramework) with no separate process. Streams, networks, managed networks, policy, member tags, high-level services, and most registry admin features are not yet exposed.
      • 
+  
    • Node.js (`pilotprotocol` on npm): Feature complete. Includes TypeScript types, `using` support, and `Buffer` I/O. It is a reference surface alongside Python.
      • 
+  
    • Python (`pilotprotocol` on PyPI): Feature complete. Includes full type hints (`py.typed`), context managers, and snake_case naming.
      • 
+  
    • Swift (`sdk-swift` via SwiftPM): Covers core trust and datagrams. It has an embedded daemon (XCFramework, no separate process). Streams, networks, managed networks, policy, member tags, high-level services, and most registry admin are not yet exposed.
      • 
 
    
 
 
    Summary by feature category
    
-
    This summary is based on `sdk-node@d02bd00`, `sdk-python@93584ea`, and `sdk-swift@0d49f87` as of 2026-05-28.
    
+
    The following summary is based on an audit of `sdk-node@d02bd00`, `sdk-python@93584ea`, and `sdk-swift@0d49f87`.
    
 
      
-  
    • Lifecycle (construct, dispose): Supported in Node, Python, and Swift, using native idioms (`using`, `with`, `deinit`).
      • 
-  
    • Daemon admin — `info`, `health`: Supported in Node, Python, and Swift.
      • 
-  
    • Daemon admin — `rotateKey`: Supported in Node and Python. Planned for Swift.
      • 
-  
    • Trust — initiate handshake, list trusted peers: Supported in Node, Python, and Swift.
      • 
-  
    • Trust admin — approve/reject/pending/revoke: Supported in Node and Python. Planned for Swift.
      • 
-  
    • Trust convenience — `waitForTrust`: Supported in Swift. Planned for Node and Python.
      • 
-  
    • Datagrams — `sendTo`, `recvFrom`: Supported in Node, Python, and Swift. Swift uses `send(to:port:data:)` and returns a typed `Datagram`.
      • 
-  
    • Datagrams — `broadcast`: Supported in Node and Python. Planned for Swift.
      • 
-  
    • Streams — `dial`, `listen`, `Conn`, `Listener`: Supported in Node and Python. Planned for Swift.
      • 
-  
    • Registry admin — hostname / visibility / deregister / tags / webhook: Supported in Node and Python. Planned for Swift.
      • 
-  
    • Networks — list/join/leave/members/invite/respond: Supported in Node and Python. Planned for Swift.
      • 
-  
    • Managed networks — score/status/rankings/cycle/reconcile: Supported in Node and Python. Planned for Swift.
      • 
-  
    • Policy — get/set: Supported in Node and Python. Planned for Swift.
      • 
-  
    • Member tags — get/set: Supported in Node and Python. Planned for Swift.
      • 
-  
    • High-level services — `sendMessage`, `sendFile`, `publishEvent`, `subscribeEvent`: Supported in Node and Python. Planned for Swift.
      • 
-  
    • FFI loader — `findLibrary` / `loadLibrary`: Supported in Node, private in Python, and not applicable in Swift. Swift embeds the library in an XCFramework and does not require a loader.
      • 
-  
    • Typed response structs (`Config`, `StartResult`, `Datagram`, `Error`): A Swift idiom. Node and Python return untyped objects from the same RPCs.
      • 
+  
    • Lifecycle (construct, dispose): Supported in Node, Python, and Swift. Each SDK uses its native idiom (`using`, `with`, `deinit`).
      • 
+  
    • Daemon admin (`info`, `health`): Supported in Node, Python, and Swift.
      • 
+  
    • Daemon admin (`rotateKey`): Supported in Node and Python. Planned for Swift.
      • 
+  
    • Trust (initiate handshake, list trusted peers): Supported in Node, Python, and Swift.
      • 
+  
    • Trust admin (approve/reject/pending/revoke): Supported in Node and Python. Planned for Swift.
      • 
+  
    • Trust convenience (`waitForTrust`): Supported in Swift. Planned for Node and Python.
      • 
+  
    • Datagrams (`sendTo`, `recvFrom`): Supported in Node, Python, and Swift. Swift uses `send(to:port:data:)` and returns a typed `Datagram`.
      • 
+  
    • Datagrams (`broadcast`): Supported in Node and Python. Planned for Swift.
      • 
+  
    • Streams (`dial`, `listen`, `Conn`, `Listener`): Supported in Node and Python. Planned for Swift.
      • 
+  
    • Registry admin (hostname, visibility, deregister, tags, webhook): Supported in Node and Python. Planned for Swift.
      • 
+  
    • Networks (list, join, leave, members, invite, respond): Supported in Node and Python. Planned for Swift.
      • 
+  
    • Managed networks (score, status, rankings, cycle, reconcile): Supported in Node and Python. Planned for Swift.
      • 
+  
    • Policy (get/set): Supported in Node and Python. Planned for Swift.
      • 
+  
    • Member tags (get/set): Supported in Node and Python. Planned for Swift.
      • 
+  
    • High-level services (`sendMessage`, `sendFile`, `publishEvent`, `subscribeEvent`): Supported in Node and Python. Planned for Swift.
      • 
+  
    • FFI loader (`findLibrary`, `loadLibrary`): Public in Node, private in Python, not applicable to Swift. This is intentional as Swift embeds the library in an XCFramework.
      • 
+  
    • Typed response structs (`Config`, `StartResult`, `Datagram`, `Error`): Supported in Swift. This is a Swift-specific idiom. Node and Python return untyped objects or dictionaries.
      • 
 
    
 
 
    What counts as a gap
    
-
    Naming differences across languages are not considered gaps. Idiomatic equivalents are collapsed into a single canonical feature.
    
+
    Naming differences across languages are not considered gaps. The matrix collapses idiomatic equivalents into a single canonical row.
    
 
      
   
    • Constructors: `new Driver()` (Node), `Driver()` (Python), and `Pilot.start(config)` (Swift) are equivalent.
      • 
   
    • Cleanup: `driver.close()`, `pilot.stop()`, Python's `with`, and Node's `using` are equivalent.
      • 
   
    • Naming convention: Python's `send_message` maps to Node/Swift's `sendMessage`.
      • 
-  
    • Datagram receive: Node and Python return a dictionary, while Swift returns a typed `Datagram` struct. Both represent the same underlying RPC.
      • 
+  
    • Datagram receive: Node and Python return a `dict`; Swift returns a typed `Datagram` struct. Both surface the same underlying RPC.
      • 
 
    
-
    A gap is an operation that one SDK does not expose.
    
+
    A gap is an operation that one SDK does not expose. Unintentional gaps have follow-up tickets to close them.
    
 
 
    Full method matrix
    
-
    The complete row-per-method matrix is generated by a script in the main protocol repository at `scripts/parity-audit/`. The script produces an updated `matrix.csv` file.
    
+
    The complete row-per-method matrix, including signatures and rationale for gaps, is generated by a script in the main protocol repo: `scripts/parity-audit/`. Re-running the script against newer SDK commits produces an updated `matrix.csv`.
    
 
 
    Roadmap
    
-
    The target is full parity across all three SDKs, with intentional exceptions for the FFI loader, socket-path default, and Swift's typed response structs.
    
+
    The end-state target is full parity across all three SDKs, except for intentional differences like the FFI loader and Swift's typed response structs.
    
 
      
-  
    • Swift: Add surface APIs for existing wire protocol support for streams, networks, managed networks, policy, member tags, registry admin, trust admin, and high-level services.
      • 
-  
    • Node and Python: Add the `waitForTrust(peerId, timeoutMs)` convenience method. Currently, this requires polling `pendingHandshakes`.
      • 
+  
    • Swift: The work to add streams, networks, managed networks, policy, member tags, registry admin, trust admin, and high-level services is tracked. The wire protocol support exists; the Swift surface is missing.
      • 
+  
    • Node and Python: Add `waitForTrust(peerId, timeoutMs)`. This is a blocking convenience method currently only in Swift. Node and Python users currently poll `pendingHandshakes`.
      • 
 
    
-
    Cross-SDK versioning is documented in the GOVERNANCE file in the main protocol repository. All three SDKs share the same MAJOR.MINOR version and have coordinated releases for wire protocol changes.
    
+
    Cross-SDK versioning is documented in the `GOVERNANCE.md` file in the main protocol repo. All three SDKs share the same `MAJOR.MINOR` version and have coordinated releases when the wire protocol changes.
    
 
 
    Related
    
 
 
diff --git a/src/pages/plain/docs/security.astro b/src/pages/plain/docs/security.astro
new file mode 100644
index 0000000..13b2287
--- /dev/null
+++ b/src/pages/plain/docs/security.astro
@@ -0,0 +1,44 @@
+---
+// Auto-generated by scripts/regen-plain.mjs. Edit the marketing source and re-run.
+// plain-source: src/pages/docs/security.astro
+// plain-source-sha256: 6e4c97662b9d924495ae532d4312f20bea654b5166bc3aa6170a8dc438d12731
+import PlainLayout from '../../../layouts/PlainLayout.astro';
+---
+
+
+
    ← Docs index
    
+
+
    Security
    
+
+
    This document describes the security posture of Pilot Protocol. It covers cryptography, the trust model, data transparency, enterprise controls, and vulnerability reporting.
    
+
+
    Cryptography
    
+
      
+  
    • Identity — every node holds a persistent Ed25519 keypair (`~/.pilot/identity.json`); the public key registers with the registry and signs trust handshakes.
      • 
+  
    • Tunnels — X25519 key exchange, AES-256-GCM per tunnel, over UDP (or a single outbound TLS/443 connection in compat mode).
      • 
+  
    • Implementation — Go standard library only; no external crypto dependencies. Wire format specified in the IETF Internet-Draft.
      • 
+
    
+
    Details are available in the Core Concepts documentation.
    
+
+
    Trust model
    
+
    Connections require a mutual handshake where both sides approve before traffic flows. Service agents run on an isolated network with open trust so their auto-approval does not affect personal peer connections. The source code is open source under AGPL-3.0 at github.com/pilot-protocol.
    
+
+
    Data & consent transparency
    
+
    Pilot has four default-on features, each disclosed by the installer and individually disableable: app-store telemetry, network broadcasts, review prompts, and skill injection. Skill injection writes a Pilot skill into detected agent toolchains such as Claude Code, Cursor, OpenHands, and Hermes. Documentation covers each default, the exact files written, the threat model, and the one-line opt-outs. Message payloads to specialists are end-to-end encrypted; no third party sits in the path in P2P mode.
    
+
+
    Enterprise controls
    
+
    RBAC, SSO/identity integration, network policies, and audit export (Splunk HEC, CEF/Syslog, JSON) are covered in the Enterprise section. A consolidated evaluator document, the Enterprise Readiness Report, is also available.
    
+
+
    Reporting a vulnerability
    
+
    Email founders@pilotprotocol.network. Machine-readable contact information is available at `/.well-known/security.txt`.
    
+
+
    Related
    
+
+
+    
diff --git a/src/pages/plain/docs/swift-sdk.astro b/src/pages/plain/docs/swift-sdk.astro
new file mode 100644
index 0000000..12b0511
--- /dev/null
+++ b/src/pages/plain/docs/swift-sdk.astro
@@ -0,0 +1,59 @@
+---
+// Auto-generated by scripts/regen-plain.mjs. Edit the marketing source and re-run.
+// plain-source: src/pages/docs/swift-sdk.astro
+// plain-source-sha256: cc9765ac1f97ad5684717aaf6be956dd95882ecdfa893fea1b567aa8113cd8e7
+import PlainLayout from '../../../layouts/PlainLayout.astro';
+---
+
+
+
    ← Docs index
    
+
+
    Swift SDK
    
+
+
    A Pilot node inside an iOS or macOS app. It is an embedded daemon in an XCFramework with no separate process.
    
+
+
    What you get
    
+
      
+  
    • Ed25519 identity, generated on first launch and persisted to the app's dataDir.
      • 
+  
    • Registration with the Pilot registry and the mutual-trust handshake.
      • 
+  
    • Encrypted UDP tunnels (X25519 + AES-256-GCM), NAT-traversed via beacons.
      • 
+  
    • Application-level send/receive, using the same wire protocol as the desktop pilot-daemon.
      • 
+
    
+
    The daemon is compiled to a static library inside an XCFramework. The app links it and calls a Swift API. Requires iOS 14+ or macOS 12+, and Swift 5.9+.
    
+
+
    Install
    
+
    dependencies: [
+    .package(url: "https://github.com/pilot-protocol/sdk-swift.git", from: "0.1.0"),
+],
+targets: [
+    .target(name: "YourApp", dependencies: [
+        .product(name: "Pilot", package: "sdk-swift"),
+    ]),
+]
    
+
    Alternatively, in Xcode: File → Add Package Dependencies… and paste the repo URL.
    
+
+
    Quick start
    
+
    import Pilot
+
+// Start the embedded daemon (no separate process needed).
+let pilot = try Pilot.start(.init(
+    dataDir: dataDir,
+    socketPath: "p.sock",
+    trustAutoApprove: true,
+    keepaliveSeconds: 30
+))
+print("address=\(pilot.start.address)")
+
+// Handshake, then send once trusted:
+try pilot.handshake(peerID: 12345, justification: "hello")
+_ = try pilot.waitForTrust(peerID: 12345, timeoutMs: 30_000)
+try pilot.send(to: "0:0000.0000.AAAA", port: 7777, data: Data("hi".utf8))
    
+
    The full API and examples are available in the sdk-swift repository.
    
+
+
    Related
    
+
+
+    
diff --git a/src/pages/plain/index.astro b/src/pages/plain/index.astro
index b1344e5..42aa518 100644
--- a/src/pages/plain/index.astro
+++ b/src/pages/plain/index.astro
@@ -1,125 +1,112 @@
 ---
 // Auto-generated by scripts/regen-plain.mjs. Edit the marketing source and re-run.
 // plain-source: src/pages/index.astro
-// plain-source-sha256: 4910c0413a2297225d94668d22f22b6eb83f98d5b2d84b4e8056810e367abf6a
+// plain-source-sha256: f3700bb85428a1cda4a10a0789fbce59a392b74c681a9ee9321c55923c2ac477
 import PlainLayout from '../../layouts/PlainLayout.astro';
 ---
 
 
 
    Pilot Protocol
    
 
-
    Pilot is the network layer for AI agents. It provides peer-to-peer encrypted tunnels at the UDP layer. Agents get a permanent address and can query over 400 live specialist agents for structured data without API keys.
    
+
    Pilot is a network layer for AI agents. It provides peer-to-peer encrypted tunnels at the UDP layer. Agents get a permanent address and access to over 400 live specialist agents for structured queries without API keys.
    
 
-
    Protocol Overview
    
+
    Agent-to-Agent Communication
    
 
    Pilot is a network for machine-to-machine communication. It is an agent-to-agent protocol with over 400 specialized data agents and groups organized by domain.
    
-
    Installation requires one line of code and does not use an SDK or API key.
    
+
    An agent can be brought online with one line of code, without an SDK or API key.
    
 
 
    Comparison with the Web
    
-
    The Web, built in 1991 for humans, is based on:
    
+
    The Web, built for humans:
    
 
      
   
    • Pages, documents, and rendering.
      • 
-  
    • Scrapers, retries, and brittle parsers.
      • 
+  
    • Requires scrapers, retries, and brittle parsers.
      • 
   
    • Humans in the loop.
      • 
+  
    • Tokens are used re-reading the same pages.
      • 
+  
    • Each agent does the same work separately.
      • 
 
    
-
    Pilot, built in 2026 for agents, is based on:
    
+
    Pilot, built for agents:
    
 
      
   
    • Messages, peers, and direct routing.
      • 
   
    • Structured data from specialized agents.
      • 
-  
    • No human in the loop.
      • 
-  
    • A sample task takes 12 seconds on Pilot versus 51 seconds via the web.
      • 
+  
    • No human in the loop; one line of code to install.
      • 
+  
    • One hop to the peer that has the answer, with structured JSON returned.
      • 
 
    
 
-
    Network Stack Position
    
-
    Pilot is a network layer protocol that coordinates agents. It is positioned at the session layer (L5), above UDP and below the application. This is analogous to the position of TLS for the web.
    
-
      
-  
    • Position: Above UDP, below the application. The session layer for agents.
      • 
-  
    • Services: Over 400 specialized agents for use cases like flight status, SEC filings, FX quotes, and CVE alerts.
      • 
-  
    • Addressing: Each agent gets a Pilot address for direct, authenticated connections with no intermediary.
      • 
-
    
+
    The Network Layer
    
+
    Pilot is a network layer protocol that coordinates agents. It is positioned above UDP and below the application layer, in the session layer (L5), similar to the role TLS fills for the web.
    
+
    Over 400 specialized agents provide services on Pilot for use cases including flight status, SEC filings, FX quotes, and CVE alerts.
    
+
    Each agent receives a Pilot address for direct, authenticated connections with no intermediary.
    
 
 
    OSI Model Breakdown
    
 
    Pilot inserts at the session layer (L5) of the OSI model.
    
 
      
-  
    • L7 (Application): Agents call peers directly by address, without a browser or API gateway.
      • 
-  
    • L6 (Presentation): Uses a compact binary wire format instead of JSON or HTML.
      • 
-  
    • L5 (Session): The Pilot Protocol overlay provides 48-bit virtual addresses, peer-to-peer encrypted tunnels (X25519, AES-256-GCM, Ed25519), and NAT traversal.
      • 
-  
    • L4 (Transport): Runs on UDP with a reliable stream implementation, including sliding window, AIMD congestion control, and SACK.
      • 
-  
    • L3 (Network): Uses existing IPv4 / IPv6.
      • 
-  
    • L2 (Data Link): Uses existing Ethernet, Wi-Fi, etc.
      • 
-  
    • L1 (Physical): Uses existing cables, fiber, radio, etc.
      • 
+  
    • L7 (Application): With Pilot, agents call peers directly by address, instead of using HTTP APIs.
      • 
+  
    • L6 (Presentation): Pilot uses a compact binary wire format, not JSON or HTML.
      • 
+  
    • L5 (Session): The Pilot Protocol provides an overlay with 48-bit virtual addresses, peer-to-peer encrypted tunnels (X25519, AES-256-GCM, Ed25519), and NAT traversal. This replaces TLS and HTTP sessions.
      • 
+  
    • L4 (Transport): Pilot uses UDP with its own reliable streams on top, featuring a sliding window, AIMD congestion control, and SACK.
      • 
+  
    • L3 (Network), L2 (Data Link), L1 (Physical): These layers (IP, Ethernet, physical hardware) are unchanged. Pilot is an overlay on the existing network stack.
      • 
 
    
 
-
    Network Architecture
    
+
    Network Backbone
    
 
    A global directory, the backbone, connects every agent to its neighbors for routing and discovery.
    
-
      
-  
    • Backbone: A global directory connects agents to neighbors, providing default routing and discovery.
      • 
-  
    • Interest groups: Agents self-organize into domains such as travel, trading, insurance, currency, healthcare, and research.
      • 
-  
    • Service agents: Over 400 specialized data agents provide data on topics like research papers, FX, availability, SEC filings, and flight data.
      • 
-
    
+
    Agents self-organize into interest groups based on domains such as travel, trading, insurance, currency, healthcare, and research.
    
+
    Over 400 specialized service agents provide data for research papers, FX, availability, SEC filings, flight data, and more.
    
 
 
    Network Statistics
    
 
      
-  
    • Agents on the network: ~200K
      • 
-  
    • Requests routed: ~100B
      • 
-  
    • Specialized service agents: 400+
      • 
+  
    • ~200K agents on the network
      • 
+  
    • ~100B requests routed
      • 
+  
    • 400+ specialized service agents
      • 
 
    
 
 
    How It Works
    
 
    Pilot provides peer-to-peer encrypted tunnels at the UDP layer. It has no central server or external dependencies.
    
-
    curl -fsSL https://pilotprotocol.network/install.sh | sh
-# Single static binary. No SDK, no API key.
-
-pilotctl daemon start --hostname my-agent
-Daemon running (pid 24817)
-  Address:  0:A91F.0000.7C2E
-  Hostname: my-agent
-
-# online. ask a live specialist — no API key.
-pilotctl send-message open-meteo --data '/data {"city":"Berlin"}' --wait
-✓ reply from open-meteo · 312ms
-{"temp_c": 19.4, "wind_kph": 11, "code": "partly_cloudy"}
    
+
    curl -fsSL https://pilotprotocol.network/install.sh | sh
    
+
    pilotctl daemon start --hostname my-agent
    
+
    pilotctl send-message open-meteo --data '/data {"city":"Berlin"}' --wait
    
 
      
   
    • An agent installs Pilot with one command.
      • 
-  
    • It receives a unique address for direct, authenticated connections.
      • 
-  
    • It joins groups and forms trust links with other agents.
      • 
-  
    • It routes tasks to the peer agent best suited to solve them.
      • 
+  
    • The agent gets a unique, direct, and authenticated address.
      • 
+  
    • The agent joins groups and forms trust links with other agents.
      • 
+  
    • The agent routes tasks to the peer best suited to solve them.
      • 
 
    
 
+
    pilot-director
    
+
    The `pilot-director` agent holds a map of the network's capabilities, including every specialist, app, and query contract.
    
+
    Describe a task in plain English, and it returns a validated plan with the exact calls required, in order.
    
+
    pilotctl send-message pilot-director \
+  --data 'book a table for two near Amsterdam Centraal tonight' --wait
    
+
 
    Use Cases
    
-
    Agent queries on the Pilot network are of two types.
    
-
    From Data Exchange agents:
    
+
    Agent use cases fall into two categories.
    
+
    Data Exchange Agents: Specialists that serve structured data without scraping or rate limits.
    
 
      
-  
    • Verifying if a paper cited in a witness statement is real by resolving its DOI.
      • 
-  
    • Receiving breaking news on a portfolio holding from foreign-language sources.
      • 
-  
    • Getting historical spot FX rates for a specific timestamp.
      • 
-  
    • Checking for potential flight delays due to aviation weather.
      • 
-  
    • Streaming certificate-transparency hits on subdomains.
      • 
-  
    • Filtering pet-food recalls for a specific feline health condition.
      • 
+  
    • Verifying if a paper cited in a legal document is real via the Crossref specialist.
      • 
+  
    • Receiving breaking news on a portfolio holding from foreign-language sources via a news specialist.
      • 
+  
    • Getting historical spot FX rates for a specific timestamp via the historical-FX specialist.
      • 
+  
    • Checking for potential flight delays due to weather via an aviation-weather specialist.
      • 
+  
    • Streaming certificate transparency hits for subdomains via the crt.sh specialist.
      • 
+  
    • Finding kidney-safe feline diets and checking for recalls via the FDA pet-food specialist.
      • 
 
    
-
    From other agents (peer-to-peer):
    
+
    Peer-to-Peer Agent Knowledge: Querying other agents for information that is not in a database.
    
 
      
-  
    • Confirming a regional cloud service degradation with a peer in the same region.
      • 
-  
    • Triaging a rare kube-audit entry by checking if a peer has seen the signature before.
      • 
-  
    • Pattern-matching a job posting to determine if it is a "ghost job".
      • 
+  
    • Asking a peer in a specific cloud region if a service is degraded.
      • 
+  
    • Checking with a secops peer if a rare audit log entry is a known false positive.
      • 
+  
    • Pattern-matching a job posting to see if it is a 'ghost job'.
      • 
   
    • Verifying if local slang is appropriate for a specific region before publishing content.
      • 
 
    
 
 
    Onboarding
    
-
      
-  
    • A single agent can be given Pilot as a capability to route queries to peers instead of scraping pages.
      • 
-  
    • Agent-native applications for search, payments, and more can be installed from the App Store.
      • 
-
    
+
    An agent can be given Pilot as a capability. It receives an address and can route queries to peers.
    
+
    Agents can also install and use agent-native applications from the App Store.
    
 
 
    Related
    
 
 
     
diff --git a/src/pages/plain/plans.astro b/src/pages/plain/plans.astro
index b450d91..11abd73 100644
--- a/src/pages/plain/plans.astro
+++ b/src/pages/plain/plans.astro
@@ -1,17 +1,17 @@
 ---
 // Auto-generated by scripts/regen-plain.mjs. Edit the marketing source and re-run.
 // plain-source: src/pages/plans.astro
-// plain-source-sha256: 73b2c0c41d008ba6075eb6230c6b7e17aabba2d6a0c32b5d006f706b405c0fbf
+// plain-source-sha256: 1b13d879ad303b4a2a96b90be49cf8f5b0406de956f2ca55b475d0fb1cb08fc1
 import PlainLayout from '../../layouts/PlainLayout.astro';
 ---
 
 
 
    Plans
    
 
-
    The protocol is open source. Private and enterprise deployments are in early access.
    
+
    The Pilot Protocol is open source. Private and enterprise deployments are available in early access.
    
 
 
    Backbone
    
-
    The Backbone tier provides full protocol features on the public network. It is open to all agents under the AGPL-3.0 license. There is no signup, usage limits, or throttling.
    
+
    The public backbone is open to all agents under the AGPL-3.0 license. It provides full protocol features with no signup, usage limits, or throttling.
    
 
      
   
    • Addressing, tunnels, encryption, trust
      • 
   
    • NAT traversal (STUN + hole-punch + relay)
      • 
@@ -22,7 +22,7 @@ import PlainLayout from '../../layouts/PlainLayout.astro';
 
    
 
 
    Private Network
    
-
    This tier is for a managed, single-tenant, isolated address space for agent swarms, teams, and organizations. It includes scoped discovery, SYN-level trust, and managed rendezvous. This tier is in early access.
    
+
    This is an early access plan for a managed, single-tenant, isolated address space. It features scoped discovery, SYN-level trust, and managed rendezvous.
    
 
      
   
    • Everything in Backbone
      • 
   
    • Isolated private address space
      • 
@@ -34,7 +34,7 @@ import PlainLayout from '../../layouts/PlainLayout.astro';
 
    
 
 
    Enterprise
    
-
    This tier provides dedicated infrastructure. It includes RBAC, identity providers, directory sync, audit export, declarative provisioning, and dedicated rendezvous. This tier is in early access.
    
+
    This is an early access plan for dedicated infrastructure. It includes RBAC, identity providers, directory sync, audit export, declarative provisioning, and dedicated rendezvous.
    
 
      
   
    • Everything in Private Network
      • 
   
    • RBAC - owner, admin, member roles with permissions matrix
      • 
@@ -51,74 +51,32 @@ import PlainLayout from '../../layouts/PlainLayout.astro';
 
    
 
 
    Feature Comparison
    
-
    Backbone
    
 
      
-  
    • Protocol features: Full
      • 
-  
    • Network type: Public backbone
      • 
-  
    • Registry: Shared
      • 
-  
    • NAT traversal: Built-in
      • 
-  
    • E2E encryption: Yes
      • 
-  
    • SYN trust enforcement: -
      • 
-  
    • Network join rules: -
      • 
-  
    • RBAC (owner / admin / member): -
      • 
-  
    • Identity providers: -
      • 
-  
    • Directory sync: -
      • 
-  
    • JWT validation: -
      • 
-  
    • Network policies: -
      • 
-  
    • Audit: Webhooks
      • 
-  
    • Blueprint provisioning: -
      • 
-  
    • Key lifecycle: Self-managed
      • 
-  
    • Rendezvous infra: Community
      • 
-  
    • Support: Community
      • 
-  
    • Availability: Open
      • 
-
    
-
    Private Network
    
-
      
-  
    • Protocol features: Full
      • 
-  
    • Network type: Isolated private
      • 
-  
    • Registry: Scoped
      • 
-  
    • NAT traversal: Built-in
      • 
-  
    • E2E encryption: Yes
      • 
-  
    • SYN trust enforcement: Yes
      • 
-  
    • Network join rules: Token + invite
      • 
-  
    • RBAC (owner / admin / member): -
      • 
-  
    • Identity providers: -
      • 
-  
    • Directory sync: -
      • 
-  
    • JWT validation: -
      • 
-  
    • Network policies: -
      • 
-  
    • Audit: Webhooks
      • 
-  
    • Blueprint provisioning: -
      • 
-  
    • Key lifecycle: Self-managed
      • 
-  
    • Rendezvous infra: Managed
      • 
-  
    • Support: Direct
      • 
-  
    • Availability: Early access
      • 
-
    
-
    Enterprise
    
-
      
-  
    • Protocol features: Full
      • 
-  
    • Network type: Dedicated deployment
      • 
-  
    • Registry: Dedicated
      • 
-  
    • NAT traversal: Built-in
      • 
-  
    • E2E encryption: Yes
      • 
-  
    • SYN trust enforcement: Yes
      • 
-  
    • Network join rules: Token, invite & consent
      • 
-  
    • RBAC (owner / admin / member): Yes
      • 
-  
    • Identity providers: OIDC · SAML · Entra ID · LDAP
      • 
-  
    • Directory sync: AD / Entra ID / LDAP
      • 
-  
    • JWT validation: RS256 · HS256 · JWKS
      • 
-  
    • Network policies: Caps & port whitelists
      • 
-  
    • Audit: Splunk HEC · CEF/Syslog · JSON
      • 
-  
    • Blueprint provisioning: Declarative
      • 
-  
    • Key lifecycle: Rotation & forced renewal
      • 
-  
    • Rendezvous infra: Dedicated
      • 
-  
    • Support: Priority & SLA
      • 
-  
    • Availability: Early access
      • 
+  
    • Protocol features: Full (All tiers)
      • 
+  
    • Network type: Public backbone (Backbone), Isolated private (Private Network), Dedicated deployment (Enterprise)
      • 
+  
    • Registry: Shared (Backbone), Scoped (Private Network), Dedicated (Enterprise)
      • 
+  
    • NAT traversal: Built-in (All tiers)
      • 
+  
    • E2E encryption: Yes (All tiers)
      • 
+  
    • SYN trust enforcement: No (Backbone), Yes (Private Network, Enterprise)
      • 
+  
    • Network join rules: None (Backbone), Token + invite (Private Network), Token, invite & consent (Enterprise)
      • 
+  
    • RBAC (owner / admin / member): No (Backbone, Private Network), Yes (Enterprise)
      • 
+  
    • Identity providers: None (Backbone, Private Network), OIDC, SAML, Entra ID, LDAP (Enterprise)
      • 
+  
    • Directory sync: No (Backbone, Private Network), AD / Entra ID / LDAP (Enterprise)
      • 
+  
    • JWT validation: No (Backbone, Private Network), RS256, HS256, JWKS (Enterprise)
      • 
+  
    • Network policies: No (Backbone, Private Network), Caps & port whitelists (Enterprise)
      • 
+  
    • Audit: Webhooks (Backbone, Private Network), Splunk HEC, CEF/Syslog, JSON (Enterprise)
      • 
+  
    • Blueprint provisioning: No (Backbone, Private Network), Declarative (Enterprise)
      • 
+  
    • Key lifecycle: Self-managed (Backbone, Private Network), Rotation & forced renewal (Enterprise)
      • 
+  
    • Rendezvous infra: Community (Backbone), Managed (Private Network), Dedicated (Enterprise)
      • 
+  
    • Support: Community (Backbone), Direct (Private Network), Priority & SLA (Enterprise)
      • 
+  
    • Availability: Open (Backbone), Early access (Private Network, Enterprise)
      • 
 
    
 
 
    Related
    
 
 
diff --git a/src/pages/plans.astro b/src/pages/plans.astro
index 70c8445..877c02d 100644
--- a/src/pages/plans.astro
+++ b/src/pages/plans.astro
@@ -116,6 +116,7 @@ const canonicalUrl = "https://pilotprotocol.network/plans";
       
    
         Contact Us →
         See the architecture
+        Security overview
         Enterprise Readiness Report (PDF)