Reorganize brain: projects/ top level, rename filenames, update homepage
- Moved everything from ideas/passepartout/ to projects/passepartout/ - Moved legal structures to projects/flags/ - Created missing _index.org files for all subdirectories - Stripped redundant passepartout- prefix from filenames - Rewrote root _index.org as generalized brain index (projects + concepts) - Updated Hugo nav to Projects/Concepts - Updated build script section descriptions - Deleted stale ideas/passepartout-economics.md orphan
This commit is contained in:
8
projects/passepartout/strategy/_index.org
Normal file
8
projects/passepartout/strategy/_index.org
Normal file
@@ -0,0 +1,8 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 9c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f
|
||||
:END:
|
||||
#+title: Passepartout — Strategy
|
||||
#+filetags: :index:
|
||||
|
||||
Business strategy, competitive analysis, compliance landscape, and market positioning for the verified infrastructure category.
|
||||
16
projects/passepartout/strategy/ai-industry-impact.org
Normal file
16
projects/passepartout/strategy/ai-industry-impact.org
Normal file
@@ -0,0 +1,16 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 5f55bbe6-d243-5766-8ccf-5c5cc88a6542
|
||||
:END:
|
||||
#+title: Impact on the AI and GPU Industry
|
||||
#+filetags: :passepartout:economics:industry:ai:gpu:nvidia:
|
||||
|
||||
If a symbolic-bootstrapping architecture becomes popular, the industry structure shifts fundamentally:
|
||||
|
||||
**Token demand compresses.** The entire AI industry (OpenAI, Anthropic, Google — ~$50B API revenue) is built on per-token pricing. A mature [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] reduces token consumption to the unfamiliar 10% I/O boundary. Steady-state per-user LLM consumption drops by an order of magnitude.
|
||||
|
||||
**GPU inference demand plateaus in regulated industries.** Inference demand drops 80-90% in any sector where the rule book is published — which covers most economically significant sectors (finance, healthcare, industrial, government procurement, legal compliance). Nvidia's growth narrative shifts from "every transaction goes through a GPU" to "every training run needs a GPU."
|
||||
|
||||
**Hyperscaler competition shifts.** The race shifts from "who has the most H100s" to "who has the best domain-specific gate rules." Google's industry data advantage matters more than Azure's raw compute.
|
||||
|
||||
**New hardware tier emerges:** CPU-native [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][verification appliances running Lisp microcode]] on RISC-V cores. Low volume (hundreds of thousands/year), high margin ($5K-50K/unit). Manufacturable at older fab nodes (28nm, 45nm) — no dependency on TSMC's leading edge. This hardware embodies [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — the cost of verification approaches zero once the symbolic engine is running on dedicated silicon. The outcome is a [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] for agent safety — the same certification dynamic UL provides for electrical safety.
|
||||
8
projects/passepartout/strategy/competitors/_index.org
Normal file
8
projects/passepartout/strategy/competitors/_index.org
Normal file
@@ -0,0 +1,8 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 0d4e5f6a-7b8c-9d0e-1f2a-3b4c5d6e7f8a
|
||||
:END:
|
||||
#+title: Passepartout — Competitive Analysis
|
||||
#+filetags: :index:
|
||||
|
||||
Competitive analysis of AI coding agents, verification platforms, and the broader infrastructure landscape.
|
||||
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: c3aab2e8-7e43-4abc-93f0-741675cfd78c
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: Aider — AI Coding Agent
|
||||
#+filetags: :passepartout:strategy:competitive:aider:
|
||||
|
||||
Language: Python. ~6.8M pip installs. ~40K lines. MIT license. The oldest and most mature open-source coding agent.
|
||||
|
||||
Architecture: Chat-based Coder class with 5 edit formats (diff, udiff, patch, whole, architect). Uses litellm for universal provider access (50+ providers). RepoMap provides codebase awareness via cosine-similarity embedding.
|
||||
|
||||
Safety model: Purely prompt-based plus user-confirmation dialogs. No deterministic gate stack. No sandboxing. No model output validator. The allowed_to_edit() gate is a single user confirmation call. --yes flag auto-approves. Aider can edit its own source code with no special protection — self-modification is undetectable.
|
||||
|
||||
Data model: Ad-hoc. Chat messages in memory. Git commits for persistence. RepoMap is a cosine-similarity index. No persistent memory across sessions. No knowledge graph.
|
||||
|
||||
Self-modification: Full. No guard against editing its own files.
|
||||
|
||||
Verification: None.
|
||||
|
||||
Key gap vs Passepartout: No safety gates, no persistent memory model, no knowledge representation, no verification, no self-modification protection, no architecture for neurosymbolic reasoning. It is a thin shell around litellm + edit format parsers.
|
||||
|
||||
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.
|
||||
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: 512dd121-2292-4f3d-ac53-31bf3d12a60f
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: Claude Code — Anthropic AI Coding Agent
|
||||
#+filetags: :passepartout:strategy:competitive:claude-code:
|
||||
|
||||
Anthropic's proprietary coding agent. TypeScript/Bun, ~512K lines (leaked source analysis). Not open source.
|
||||
|
||||
Architecture: Bun-bundled TypeScript single-file executable. Ink/React terminal UI. 23+ core tools. Subagent forking with byte-identical API prefixes for prompt cache sharing. Multi-agent coordination mode.
|
||||
|
||||
Safety model: Layered deterministic safety — NOT prompt-based: 7 permission modes, persistent permission rules (alwaysAllow/alwaysDeny/alwaysAsk from 4 sources), bash security validator at 2,592 lines with 23+ named security checks using tree-sitter AST parsing, sandbox runtime, path/mode validation, optional ML bash classifier. This is the most sophisticated safety system of any coding agent analyzed.
|
||||
|
||||
Data model: File-based markdown memdir at ~/.claude/projects/<slug>/memory/. 4 memory types: user, feedback, project, reference. YAML frontmatter in .md files. PROJECT.md and CLAUDE.md for project config. No database.
|
||||
|
||||
Self-modification: HIGH. Skill system writes SKILL.md files. Plugin system, cron scheduling, agent spawning.
|
||||
|
||||
Verification: None.
|
||||
|
||||
Key gap vs Passepartout: No proof system, no neurosymbolic architecture, no self-verification, no persistent knowledge graph (flat markdown files, not Org-mode with cross-references), markdown data model lacks semantic depth. Proprietary — Anthropic controls it completely. The permission rules system is impressive but structurally inferior to Passepartout's gate stack because rules are heuristic (regex-based pattern matching) rather than typed (type-level gates with structural guarantees).
|
||||
|
||||
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.
|
||||
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: e929ff32-28d8-4a29-bf74-d55babc040d1
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: Codex CLI — OpenAI AI Coding Agent
|
||||
#+filetags: :passepartout:strategy:competitive:codex:
|
||||
|
||||
OpenAI's open-source coding agent. Rust, ~950K lines, sandboxed.
|
||||
|
||||
Architecture: ~116 crate Rust workspace with a protocol layer (SQ/EQ session types), sandbox manager (macOS Seatbelt, Linux nsjail), multi-provider support, configurable TUI.
|
||||
|
||||
Safety model: Most sophisticated safety system of any coding agent analyzed. Multi-layer: process hardening (macOS Seatbelt with 4 profile tiers), execution policy engine, sandboxing via nsjail/Seatbelt, Guardian module for tool permission gating. No prompt-based safety — all deterministic through policy definitions.
|
||||
|
||||
Data model: Protocol-defined session types. Structured request/response models. Config through TOML files with schema validation.
|
||||
|
||||
Self-modification: Protected by sandbox — the agent cannot escape to modify its own binary or config without explicit policy override.
|
||||
|
||||
Verification: None (no proof system).
|
||||
|
||||
Key gap vs Passepartout: No knowledge graph, no persistent memory model, no deterministic gate stack for agent behavior (only OS-level sandboxing), no ACL2/prover, no neurosymbolic architecture. Strongest sandbox but weakest cognitive architecture.
|
||||
|
||||
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.
|
||||
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: 22d0a159-68a2-4587-9375-5046beddc20c
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: Continue — CI/Check System
|
||||
#+filetags: :passepartout:strategy:competitive:continue:
|
||||
|
||||
TypeScript, ~328K lines, Apache 2.0. Source-controlled AI checks for CI/CD. Markdown-as-gate-policy.
|
||||
|
||||
Architecture: Shared core (@continuedev/core) with ~80 provider implementations, tool-calling engine, config system (YAML/JSON/Markdown). Serves CLI (Ink/React TUI + headless CI mode), IDE extensions (VS Code, JetBrains), web dashboard.
|
||||
|
||||
Safety model: Three permission levels (allow/ask/exclude). Precedence: mode policies → CLI flags → permissions.yaml → built-in defaults. Terminal security package for shell command analysis via shell-quote parsing. Workspace-scoped file access.
|
||||
|
||||
Data model: Markdown files for checks, agents, rules. Source-controlled in-repo. YAML frontmatter for metadata.
|
||||
|
||||
Self-modification: Checks source-controlled — any change goes through git.
|
||||
|
||||
Verification: None (the checks are themselves unverified).
|
||||
|
||||
Key gap vs Passepartout: The checks-as-markdown concept is philosophically similar to Passepartout's gate rules (deterministic policies checked before execution) but the implementation is dramatically simpler — regex-based policy objects, not a type-level gate stack with structural guarantees. No persistent agent, no memory, no knowledge graph, no neurosymbolic architecture. It is a gate system without an agent to gate.
|
||||
|
||||
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.
|
||||
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: 8d73ccb9-34e4-4899-b0c3-605998e9bebc
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: Gemini CLI — Google AI Coding Agent
|
||||
#+filetags: :passepartout:strategy:competitive:gemini:
|
||||
|
||||
Google's open-source coding agent. TypeScript, ~525K lines, Apache 2.0. Node.js 20+, Ink/React TUI.
|
||||
|
||||
Architecture: 7-package npm monorepo. Core backend handles Gemini API orchestration, tool execution, policy engine, safety checks, sandbox management, session management, MCP client. 7-strategy composite model routing chain.
|
||||
|
||||
Safety model: Multi-layered: CONSECA (Contextual Security Checker) — AI-driven per-request policy generation using a separate Gemini Flash model. 4 approval modes (PLAN/DEFAULT/AUTO_EDIT/YOLO). 6 sandbox methods (macOS Seatbelt, Docker/Podman, bwrap, gVisor, LXC, Windows). Trusted folders with path traversal protection. Policy integrity via cryptographic hashes. Loop detection.
|
||||
|
||||
Data model: JSONL session files. Turn-based conversation model. 4-layer config precedence (system-defaults → user → project → system-override). TOML policy files.
|
||||
|
||||
Self-modification: Modifiable hooks system, MCP extensions, custom commands. Core binaries are protected on disk by file permissions.
|
||||
|
||||
Verification: None.
|
||||
|
||||
Key gap vs Passepartout: No proof system, no persistent knowledge graph, no self-verification, no neurosymbolic architecture, lock-in to Google Gemini models. CONSECA is interesting (AI-generated policies) but introduces a second LLM call for every security decision — the opposite of Passepartout's zero-token deterministic gating.
|
||||
|
||||
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.
|
||||
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: c652688a-1ea0-487c-9222-00e954efe8a1
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: Hermes Agent — Personal AI Assistant
|
||||
#+filetags: :passepartout:strategy:competitive:hermes:
|
||||
|
||||
The agent running this conversation. Python, ~17K core lines, MIT.
|
||||
|
||||
Architecture: Synchronous conversation loop with OpenAI-format messages. 60+ built-in tools. 109+ providers via pluggable transport layer. 15+ messaging platforms via gateway. MCP client (native, not bridge). Ink/React TUI as Node.js subprocess. Cron jobs, Kanban board, subagent delegation.
|
||||
|
||||
Safety model: Multi-layer but NOT a deterministic gate stack: message sanitization, Tirith binary scanner, command approval system, memory injection detection, secret/PII redaction, tool call guardrails, MCP security, context fencing. All heuristic or prompt-based — no structural type-level gates.
|
||||
|
||||
Data model: SQLite session DB (FTS5 full-text search). File-based memory (MEMORY.md + USER.md). YAML config. No knowledge graph. No Org-mode.
|
||||
|
||||
Self-modification: Skill system writes SKILL.md files. Memory tool edits MEMORY.md/USER.md. Core Python code is read-only in execution but no gate specifically prevents the LLM from requesting source modifications.
|
||||
|
||||
Verification: None.
|
||||
|
||||
Key gap vs Passepartout: No deterministic gate stack (heuristic layers, not structural/typed), no knowledge graph, no Org-mode, no neurosymbolic architecture, no self-verification, no proof system. Hermes's strength is breadth — 109 providers, 15 platforms, MCP ecosystem. But it has no depth in safety, knowledge representation, or reasoning architecture.
|
||||
|
||||
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.
|
||||
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: 85ca69dd-d085-4a55-ad11-021910b1f82e
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: OpenClaw — Personal AI Assistant
|
||||
#+filetags: :passepartout:strategy:competitive:openclaw:
|
||||
|
||||
TypeScript/Node.js, ~3.5M lines. The largest codebase analyzed. Personal AI assistant with 25+ messaging channel support.
|
||||
|
||||
Architecture: pnpm workspace with ~135 bundled plugins. Gateway control plane routes messages through multi-agent routing. Per-agent sessions, workspaces, skill registries. Companion native apps (macOS, iOS, Android).
|
||||
|
||||
Safety model: Tiered — main agent runs tools directly on host (trusted-operator), non-main sessions sandboxed via Docker (read-only rootfs, capability dropping, seccomp/AppArmor, memory/cpu/PID limits, SSH/OpenShell backends).
|
||||
|
||||
Data model: Typed JSON/YAML config (openclaw.json). Multi-source model catalog. Plugin SDK with narrow typed subpath exports.
|
||||
|
||||
Self-modification: ACP (Agent Control Protocol) for spawning child sessions. Skill system with npm distribution and ClawHub registry.
|
||||
|
||||
Verification: None.
|
||||
|
||||
Key gap vs Passepartout: Same as Hermes — no gate stack, no knowledge graph, no Org-mode, no verification, no neurosymbolic architecture. Differentiated by vastly broader channel support and mature plugin ecosystem. But architecturally conventional — LLM + tools + channels, no cognitive architecture innovation.
|
||||
|
||||
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.
|
||||
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: 7a060b36-36db-4eb7-b8cc-844bd6ac9d36
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: OpenCode — AI Coding Agent
|
||||
#+filetags: :passepartout:strategy:competitive:opencode:
|
||||
|
||||
TypeScript/Bun. anomalyco/opencode, 163K★. The dominant open-source coding agent by adoption. Bun runtime, Effect-TS functional core, Solid.js TUI, Turborepo monorepo.
|
||||
|
||||
Architecture: Dual LLM runtime — default AI SDK (streamText/generateText) + opt-in native Effect-Schema runtime with 4-axis route decomposition (Protocol/Endpoint/Auth/Framing). 30+ provider plugins. Agent workflow DSL with plan/build agent switching. Agent Communication Protocol (ACP) for inter-agent messaging. Subagents inherit permission boundaries from parent. 18+ built-in tools + custom tools from config. Effect-TS ScopedCache per-project state management.
|
||||
|
||||
Safety model: Explicitly documents not sandboxing the agent. Permission system is rule-based (glob matching, actions: allow/ask/deny) and exists as a UX feature, not security isolation. Built-in agents have carefully scoped defaults. Permission rules inherited by subagents.
|
||||
|
||||
Data model: SQLite via Drizzle ORM with bun:sqlite or better-sqlite3. Key tables: SessionTable, MessageTable, PartTable. Project model stores worktree, VCS, sandbox config. Config is JSON-chain with remote config fetch.
|
||||
|
||||
Self-modification: Agent.generate() interface lets the LLM create new agent definitions — the system grows its own subagent roster. Skills system loads domain-specific knowledge packs dynamically.
|
||||
|
||||
Verification: None.
|
||||
|
||||
Key gap vs Passepartout: No deterministic safety architecture, no knowledge graph, no Org-mode, no verification/proof system, no neurosymbolic architecture. The permission system is explicitly labeled not security isolation — it's UX, not a gate stack.
|
||||
|
||||
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.
|
||||
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: 416bab7c-4300-4d50-838a-5c7a8ad45d96
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: Thoth — Personal AI Sovereignty
|
||||
#+filetags: :passepartout:strategy:competitive:thoth:
|
||||
|
||||
https://github.com/siddsachar/Thoth — Python, ~151K lines, Apache 2.0. Local-first desktop AI assistant with knowledge graph, tools, voice, vision, shell, browser automation, workflow engine, and messaging channels.
|
||||
|
||||
Architecture: LangGraph create_react_agent (prebuilt ReAct pattern). Dual-mode streaming. NiceGUI web UI with desktop launcher. Context trimming via tiktoken, base64 data redaction, stale browser snapshot compression, MD5 tool result dedup, old tool result summarization. Agent graph cached by tool set + model override. Checkpoints via LangGraph's SQLite-backed checkpointer. 30+ tool modules.
|
||||
|
||||
Safety model: Shell command classification with 17 blocked patterns, 30+ safe auto-execute prefixes, needs-approval for compound commands. Interactive interrupt for non-safe shell. Per-workflow safety modes (block/approve/allow_all). Prompt-injection defense (5 categories, detection-only). Filesystem workspace boundary. Opt-in Docker Sandbox. Destructive ops require confirmation. No sandboxing of agent runtime itself.
|
||||
|
||||
Data model: SQLite (WAL mode) at ~/.thoth/memory.db — shared between knowledge graph and legacy memory. Knowledge graph: SQLite (durable) + NetworkX MultiDiGraph (in-memory, rebuilt on startup) + FAISS vector index (semantic recall). 11 entity types, 67+ typed relations with 30+ LLM-produced aliases. Dream Cycle refinement pipeline. Config: JSON files. Keys in OS credential store.
|
||||
|
||||
Self-modification: Agent CAN create/update/delete skills via dedicated tools. Skill patching requires user confirmation + auto backup. Maximum 1 patch proposal per conversation. No tool to modify system prompts directly.
|
||||
|
||||
Verification: None formal. Update signature verification.
|
||||
|
||||
Key gap vs Passepartout: No deterministic gate stack — shell safety is pattern list, not typed gates. No proof system. No output guardrails. No neurosymbolic architecture. No Org-mode. No Merkle-tree memory. Knowledge graph is LLM-driven entity extraction — no structural integrity guarantees. Thoth's differentiation is the knowledge graph + Developer/Designer studios + embedded LangGraph framework, but still architecturally conventional.
|
||||
|
||||
See the full [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][competitive analysis]] for the landscape view and comparison.
|
||||
@@ -0,0 +1,17 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 00ab3a4d-e3de-5605-a67d-12935bb36ab5
|
||||
:END:
|
||||
#+title: Comparison with Symbolics Genera
|
||||
#+filetags: :passepartout:history:symbolics:comparison:
|
||||
|
||||
| | Symbolics Genera (1980s) | [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] (2020s) |
|
||||
|---|---|---|
|
||||
| Lines | ~1,000,000 | ~21,000 (self-driving target) |
|
||||
| Developer-years | ~10 years, large team | ~1 year, 1-3 devs |
|
||||
| OS | Built from scratch in assembly + Lisp | Runs on Linux (free OS layer) |
|
||||
| Hardware | Custom Lisp Machine (entire computer) | PCIe card (FPGA or Tenstorrent) |
|
||||
| Market | $50K-$100K/seat | $5K-$50K/appliance |
|
||||
| Scope | Full OS + environment | Cognitive agent + hardware acceleration |
|
||||
|
||||
The Symbolics comparison is instructive: they built a full Lisp OS from scratch. Passepartout runs on Linux, providing the OS layer for free. The hardware integration is a PCIe card, not a replacement of the entire host. The scope is dramatically smaller — ~2% of the code for a fraction of the functionality that matters most. This illustrates the fundamental principles of [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — the cost of building a Lisp-based system has dropped by [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders of magnitude]] since the 1980s. The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Self-driving Lisp Machine]] is the modern analogue: a hardware accelerator rather than a complete computer.
|
||||
@@ -0,0 +1,128 @@
|
||||
:PROPERTIES:
|
||||
:ID: 3aa22300-2f25-57b0-8787-9f199cc978b1
|
||||
:CREATED: [2026-05-22 Thu]
|
||||
:END:
|
||||
#+title: Competitive Analysis — AI Agent Landscape
|
||||
#+filetags: :passepartout:strategy:competitive:
|
||||
|
||||
* Overview
|
||||
|
||||
Analyzed 9 competitor codebases alongside Passepartout. The competitive landscape
|
||||
divides into three categories:
|
||||
|
||||
1. Coding agents — Aider, OpenCode, Codex CLI, Claude Code, Gemini CLI
|
||||
2. Personal AI assistants — [[id:c652688a-1ea0-487c-9222-00e954efe8a1][Hermes Agent]], OpenClaw, [[id:416bab7c-4300-4d50-838a-5c7a8ad45d96][Thoth]]
|
||||
3. CI/check-based systems — Continue
|
||||
|
||||
None of the nine compete with Passepartout on all axes simultaneously. Passepartout's
|
||||
strongest differentiators — Org-mode data model, deterministic gate stack, ACL2
|
||||
verification, Merkle-treed memory, and the [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout architecture]] — are absent from
|
||||
every competitor.
|
||||
|
||||
* Category 1: Coding Agents
|
||||
|
||||
- [[id:c3aab2e8-7e43-4abc-93f0-741675cfd78c][Aider]] — Python, ~40K lines, MIT. Oldest open-source coding agent. Chat-based Coder class with 5 edit formats. Purely prompt-based safety.
|
||||
- [[id:7a060b36-36db-4eb7-b8cc-844bd6ac9d36][OpenCode]] — TypeScript/Bun, 163K★. Dominant open-source coding agent. Dual LLM runtime, ACP inter-agent protocol, SQLite state.
|
||||
- [[id:e929ff32-28d8-4a29-bf74-d55babc040d1][Codex CLI]] — Rust, ~950K lines, OpenAI. Strongest sandboxing (Seatbelt/nsjail). Execution policy engine. No knowledge graph.
|
||||
- [[id:512dd121-2292-4f3d-ac53-31bf3d12a60f][Claude Code]] — TypeScript/Bun, ~512K lines leaked. Most mature safety system (2,592 lines bash security). 7 permission modes. Proprietary.
|
||||
- [[id:8d73ccb9-34e4-4899-b0c3-605998e9bebc][Gemini CLI]] — TypeScript, ~525K lines, Apache 2.0. CONSECA AI-driven policy generation. 6 sandbox methods. Google-locked.
|
||||
|
||||
* Category 2: Personal AI Assistants
|
||||
|
||||
- [[id:c652688a-1ea0-487c-9222-00e954efe8a1][Hermes Agent]] — Python, ~17K core, MIT. Running this conversation. 109+ providers, 15+ messaging platforms, MCP client. Heuristic safety layers.
|
||||
- [[id:85ca69dd-d085-4a55-ad11-021910b1f82e][OpenClaw]] — TypeScript/Node.js, ~3.5M lines. Largest codebase. 25+ messaging channels, 135 bundled plugins. Tiered sandboxing.
|
||||
- [[id:416bab7c-4300-4d50-838a-5c7a8ad45d96][Thoth]] — Python, ~151K lines, Apache 2.0. Personal knowledge graph (11 entity types, 67 relations, NetworkX+FAISS). LangGraph ReAct agent. Developer Studio.
|
||||
|
||||
* Category 3: CI/Check Systems
|
||||
|
||||
- [[id:22d0a159-68a2-4587-9375-5046beddc20c][Continue]] — TypeScript, ~328K lines, Apache 2.0. Source-controlled AI checks for CI/CD. Markdown-as-gate-policy. No persistent agent.
|
||||
|
||||
* The Passepartout Advantage
|
||||
|
||||
| Dimension | Passepartout | Best Competitor | Gap |
|
||||
|-----------|--------------|-----------------|-----|
|
||||
| Safety model | Type-level gates + 11-vector deterministic stack | Claude Code (7 permission modes + 23 bash checks) | Structural vs heuristic. Passepartout's type-level gates prevent self-modification at the category level; competitors block patterns. |
|
||||
| Knowledge model | Org-mode (tree, properties, TODOs, timestamps, cross-refs, IDs, tags) | Claude Code (flat markdown memdir) | Org-mode's semantic richness is ~15 primitives markdown doesn't have. |
|
||||
| Memory integrity | Merkle tree + SHA-256 + rollback | Hermes (file-based); Claude Code (flat files + git) | Content-addressed, tamper-evident memory no competitor has. |
|
||||
| Self-verification | ACL2 → CIC prover (planned) | None | No competitor does provable correctness. |
|
||||
| Cognitive architecture | 10-80-10 symbolic-first (planned) | 100% LLM (every competitor) | Post-flip, Passepartout uses ~10% of the tokens competitors use. |
|
||||
| Data format | Org-mode (human-editable, machine-parseable, single file) | JSONL/Markdown/YAML/DB (competitors use 2-5 formats) | Unified format reduces translation layers to zero. |
|
||||
| Self-modification | Type-level gates + hot-reload | Claude Code (skills), Hermes (skills) | Passepartout's guard against self-modification is structural (type level), not heuristic (pattern list). |
|
||||
| Architecture | Passepartout ([[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][environment subsystem]] + [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]]) | None | No competitor is building a full computing stack + social network. |
|
||||
| Provider independence | Any OpenAI-compatible API | Hermes (109+), Gemini CLI (1 primary) | Comparable to Hermes, better than most. |
|
||||
|
||||
* Where Competitors Lead
|
||||
|
||||
| Dimension | Leader | Passepartout Status |
|
||||
|-----------|--------|---------------------|
|
||||
| Safety implementation maturity | Claude Code (2,592 lines bash security) | Gate stack exists but bash validation is minimal in comparison |
|
||||
| Provider breadth | Hermes (109+), OpenClaw (50+) | 8 providers — adequate but not competitive |
|
||||
| Channel/platform support | OpenClaw (25+ channels) | TUI only — no multi-channel |
|
||||
| Plugin ecosystem | OpenClaw (ClawHub, npm registry) | No plugin marketplace |
|
||||
| Subagent delegation | Claude Code (fork with context inheritance) | Planned via Screamer planner |
|
||||
| Codebase size / features shipped | All competitors have working products | In development |
|
||||
| MCP integration | Hermes, Codex (native), Continue | Planned |
|
||||
| Sandboxing | Codex CLI (Seatbelt+nsjail), Gemini CLI (6 methods) | None |
|
||||
| Business model | Hermes (MIT+services), Codex (tokens) | AGPL + appliances + SaaS |
|
||||
| Cross-platform | Claude Code (macOS/*nix), Codex (macOS) | Linux only |
|
||||
|
||||
* Strategic Positioning
|
||||
|
||||
Passepartout is not competing in the existing AI agent market. It is building a
|
||||
new category: provable personal infrastructure.
|
||||
|
||||
Competitors optimize for:
|
||||
- Token efficiency (Aider's edit formats, OpenCode's LSP integration)
|
||||
- Model flexibility (Hermes' 109 providers)
|
||||
- Platform reach (OpenClaw's 25 channels)
|
||||
- UI polish (Gemini CLI's Ink/React, Claude Code's permission dialogs)
|
||||
- Sandbox security (Codex's Seatbelt, Gemini's gVisor)
|
||||
|
||||
Passepartout optimizes for:
|
||||
- Provable correctness (ACL2 → CIC)
|
||||
- Data integrity (Merkle tree)
|
||||
- Cognitive architecture (10-80-10 symbolic-first)
|
||||
- Safety by construction (type-level gates)
|
||||
- Unified data model (Org-mode as everything)
|
||||
- Network effects (social protocol)
|
||||
- Full-stack ownership (environment subsystem)
|
||||
|
||||
These are not axes any competitor cares about. The risk is not that a competitor
|
||||
builds a better Passepartout — it's that the market never develops a preference
|
||||
for provable agents. If token-burning LLM agents remain the default and users
|
||||
don't demand verification, the entire category Passepartout addresses may not
|
||||
exist yet.
|
||||
|
||||
* Immediate Implications for Development
|
||||
|
||||
1. Claude Code's safety system is the benchmark to exceed. The type-level gate
|
||||
architecture is theoretically superior to Claude Code's heuristic patterns,
|
||||
but the implementation needs to prove it catches things Claude Code misses.
|
||||
|
||||
2. No competitor has anything resembling a neurosymbolic architecture. The 10-80-10
|
||||
plan has zero competition — but that also means zero market validation.
|
||||
|
||||
3. The Org-mode bet is invisible to competitors. They don't see the advantage
|
||||
because they've never tried to build a knowledge graph from flat markdown files.
|
||||
This is Passepartout's widest moat — it depends on a skill (Org-mode literate
|
||||
programming) that no competitor's team has.
|
||||
|
||||
4. Hermes is the closest full-stack competitor (tools, skills, cron, subagents,
|
||||
multi-platform), but architecturally conventional.
|
||||
|
||||
5. The coding agents (Aider, OpenCode, Codex) are not competitors — they are
|
||||
single-purpose tools Passepartout could eventually replace entirely when the
|
||||
planner matures.
|
||||
|
||||
* File references
|
||||
|
||||
Repository dumps and analysis artifacts at /tmp/:
|
||||
- /tmp/aider/ — Aider source (Python)
|
||||
- /tmp/opencode/ — OpenCode archived source
|
||||
- /tmp/codex/ — OpenAI Codex CLI (Rust)
|
||||
- /tmp/claude-code-leaked-source/ — Claude Code leaked (TypeScript/Bun)
|
||||
- /tmp/gemini-cli/ — Google Gemini CLI (TypeScript)
|
||||
- /tmp/openclaw/ — OpenClaw source (TypeScript)
|
||||
- /tmp/thoth/ — Thoth source (Python)
|
||||
- /tmp/continue/ — Continue source (TypeScript)
|
||||
- /usr/local/lib/hermes-agent/ — Hermes Agent (Python)
|
||||
@@ -0,0 +1,221 @@
|
||||
:PROPERTIES:
|
||||
:ID: 1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f
|
||||
:ID: competitive-landscape-agora
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Passepartout Social Protocol Competitive Landscape
|
||||
#+filetags: :passepartout:social-protocol:competitive:strategy:landscape:
|
||||
|
||||
The social protocol is a decentralized social operating system that replaces the entire centralized internet platform stack: every function that currently runs on Facebook, Twitter, Instagram, YouTube, TikTok, Reddit, Medium, Substack, OnlyFans, Pornhub, WhatsApp, Signal, Telegram, Discord, LinkedIn, eBay, Etsy, GitHub, DocuSign, Stripe, and Google/Apple ID — all through one unified identity, one data model (the Note), one communication protocol (DIDComm), one payment rail (Lightning), and one contract layer (SCAL).
|
||||
|
||||
There is no single competitor. The competition is the /category/ of centralized internet platforms and the psychological status quo of managing 15+ separate accounts.
|
||||
|
||||
This page maps every platform the protocol replaces, organized by domain, with the specific protocol capability that makes the replacement possible.
|
||||
|
||||
* Social Graph & Publishing
|
||||
|
||||
** Twitter/X
|
||||
- *User need:* Broadcast short-form content, follow interesting people, real-time news
|
||||
- *Social Protocol replacement:* Feeds and streams via the Note primitive (`is_feed: true`), with Lens architecture for customizable curation. Follows are cryptographic subscriptions, not API-gated relationships.
|
||||
- *Social Protocol advantage:* No algorithmic manipulation, no ads, no shadowbanning. Users choose their Feed Generators via the Algorithm Marketplace. Portable social graph — follows are signed Notes, not a database row.
|
||||
- *Migration:* Twitter archive import for followed accounts.
|
||||
|
||||
** Facebook / Meta
|
||||
- *User need:* Social graph, family/friend connections, event management, groups
|
||||
- *Social Protocol replacement:* Collective Personas for groups, DID-based social graph (not platform-controlled), Persona isolation for work/personal/family
|
||||
- *Social Protocol advantage:* No central feed algorithm that optimizes for engagement over well-being. Portable identity — your social graph leaves the platform when you do. No data mining.
|
||||
- *Timing:* Year 3+ after network effects. Facebook's moat is the largest social graph; the protocol's Persona system makes it portable by design.
|
||||
|
||||
** Instagram
|
||||
- *User need:* Visual content sharing, photo feeds, stories
|
||||
- *Social Protocol replacement:* Visual Notes with `content_type: image/*`. Lens architecture renders them through an "Instagram-style" grid or a "Pinterest-style" discovery view depending on user-selected Lens.
|
||||
- *Social Protocol advantage:* User-chosen discovery algorithm. No engagement-maximized feed. Content is not manipulated for ad placement.
|
||||
|
||||
** LinkedIn
|
||||
- *User need:* Professional identity, job market, professional networking
|
||||
- *Social Protocol replacement:* Professional Persona (unlinkable from personal), Aletheia Portfolio (static site published natively to the network), Contract Notes for hiring/service agreements
|
||||
- *Social Protocol advantage:* Portable professional reputation — not locked to a platform. Verified work history via signed Notes. Direct hiring without platform intermediation fees.
|
||||
|
||||
** Reddit / Forums (phpBB, vBulletin)
|
||||
- *User need:* Community discussion, Q&A, interest-based groups
|
||||
- *Social Protocol replacement:* Social Spaces with Collective Personas, pluggable feed generation, competitive labeling for moderation
|
||||
- *Social Protocol advantage:* Sovereign moderation (users choose their Labelers), portable identity across communities, no censorship risk. Communities can fork if the Collective governance fails.
|
||||
- *Migration:* Import subscribed subreddits.
|
||||
|
||||
** Medium / Substack
|
||||
- *User need:* Long-form publishing, subscription-based content, creator monetization
|
||||
- *Social Protocol replacement:* Feed Notes (`is_feed: true`) with paywalled content via LSAT protocol (Lightning Service Authentication Tokens). Subscriptions are streaming Lightning payments.
|
||||
- *Social Protocol advantage:* Near-zero platform fees (relay costs only). Content ownership — readers subscribe to the creator's DID, not to a platform. No censorship risk.
|
||||
- *Strategic target:* Phase 1 platform replacement.
|
||||
|
||||
* Video & Audio
|
||||
|
||||
** YouTube
|
||||
- *User need:* Video hosting, discovery, comments, monetization
|
||||
- *Social Protocol replacement:* Video Notes (`content_type: video/*`) viewed through a "YouTube Lens" (displaying comments via `reply_to` and related videos). The exact same Note can be viewed through an "Educational Lens" or "Podcast Lens."
|
||||
- *Social Protocol advantage:* No algorithm that optimizes for watch time over well-being. Lens architecture lets users choose discovery logic. Content monetized via LSAT + Seeder Rewards — creators earn directly, and bandwidth providers (seeders) earn micro-rewards.
|
||||
|
||||
** TikTok
|
||||
- *User need:* Short-form vertical video, discovery algorithm
|
||||
- *Social Protocol replacement:* Short-duration video Notes trigger a "TikTok-style" vertical scroll and auto-play in the UI when `content_type: "video/mp4"` and duration is short.
|
||||
- *Social Protocol advantage:* The "For You" algorithm is a user-chosen Lens, not a platform-controlled black box. No engagement-extremification.
|
||||
|
||||
** Podcasts / Audio
|
||||
- *User need:* Audio content, background play
|
||||
- *Social Protocol replacement:* Audio Notes (`content_type: audio/mpeg`) viewed through a "Podcast Lens" with 1.5x speed and background play. Same Note can be listened to or watched depending on Lens.
|
||||
|
||||
* Messaging & Communication
|
||||
|
||||
** WhatsApp / Signal / Telegram
|
||||
- *User need:* Private messaging, group chats, voice/video calls, encryption
|
||||
- *Social Protocol replacement:* DIDComm v2 for transport, Double Ratchet Algorithm (Signal Protocol) for Perfect Forward Secrecy, WebRTC for voice/video with decentralized signaling via DIDComm. PDS acts as encrypted mailbox proxy.
|
||||
- *Social Protocol advantage:* Multi-persona isolation — Work DID and Personal DID have separate message queues that never mix. Onion routing for metadata privacy. Off-the-Record mode for ephemeral interactions. No central server controlling the directory.
|
||||
|
||||
** Discord / Slack
|
||||
- *User need:* Community chat, voice channels, collaboration
|
||||
- *Social Protocol replacement:* Social Spaces with Collective Personas. DIDComm-based group messaging. Governance modules (GEM) for roles, permissions, and moderation.
|
||||
- *Social Protocol advantage:* Server ownership is cryptographic, not corporate. Communities can fork. No per-seat pricing. Portable membership history.
|
||||
|
||||
** Email
|
||||
- *User need:* Asynchronous messaging, identity, document delivery
|
||||
- *Social Protocol replacement:* Directed Notes (Copy-on-Send model). PDS as encrypted mailbox. The Note is a universal message format — no separate email protocol needed.
|
||||
- *Social Protocol advantage:* End-to-end encryption by default. Cryptographic sender verification (no phishing, no spoofing). No spam (relays only route to subscribed destinations). Attachments are CIDs, not MIME blobs.
|
||||
|
||||
** Zoom / Google Meet
|
||||
- *User need:* Video conferencing, screen sharing
|
||||
- *Social Protocol replacement:* WebRTC over DIDComm signaling. P2P tunnel — no central server sees call data.
|
||||
- *Social Protocol advantage:* No Zoom-bombing (call is authenticated by DID). No platform listening in. No account required beyond your DID.
|
||||
|
||||
* E-Commerce & Marketplaces
|
||||
|
||||
** eBay / Etsy
|
||||
- *User need:* Buy and sell goods, auction, fixed-price listings, dispute resolution
|
||||
- *Social Protocol replacement:* Contract Notes as product listings (Offer → Take model). HODL invoice escrow for payments. SCAL (Sovereign Contract & Arbitration Layer) for dispute resolution.
|
||||
- *Social Protocol advantage:* Fees below 5% (vs. 10-15%). Transparent reputation system based on DID history. No account bans. Multi-level arbitration (Local Elders → Guilds → Global Juries).
|
||||
|
||||
** OnlyFans / Patreon / Fansly
|
||||
- *User need:* Subscription content, adult content, creator-direct monetization
|
||||
- *Social Protocol replacement:* Paywalled Notes via LSAT protocol. Streaming Lightning subscriptions. Encrypted content with Blind CDN seeding.
|
||||
- *Social Protocol advantage:* Censorship-resistant (no payment processor can cut you off). Near-zero platform fees. Pseudonymous by default. Adult content doesn't face the banking discrimination that existing platforms do.
|
||||
- *Strategic target:* Phase 1 platform replacement (underserved, clear pain point).
|
||||
|
||||
** Pornhub / Adult content
|
||||
- *User need:* Adult content hosting, discovery, monetization
|
||||
- *Social Protocol replacement:* Same Note primitive with `content_type: video/*`. LSAT for paywalled access. Blind CDN for distribution.
|
||||
- *Social Protocol advantage:* No centralized moderation that can delist creators. Lightning-native payments bypass banking discrimination. Privacy (identity not tied to consumption).
|
||||
- *Strategic target:* Phase 1 platform replacement.
|
||||
|
||||
* Work & Collaboration
|
||||
|
||||
** GitHub / GitLab
|
||||
- *User need:* Version control, code hosting, issues, pull requests, CI
|
||||
- *Social Protocol replacement:* Code is stored as Merkle DAGs of commit Notes. Issues and PRs are Contract Notes. Collective Personas own repositories.
|
||||
- *Social Protocol advantage:* Truly decentralized version control — no central repository host. Signed commits with DID. Smart contracts for bounty management (Lightning bounties).
|
||||
|
||||
** Google Docs / Office 365
|
||||
- *User need:* Collaborative document editing, spreadsheets, presentations
|
||||
- *Social Protocol replacement:* Static pages (`is_feed: false`) with versioned CID history. Collaborative editing via Contract Notes defining access control.
|
||||
- *Social Protocol advantage:* Document history is immutable and verifiable. No platform lock-in.
|
||||
|
||||
** Project Management (Jira, Trello, Asana)
|
||||
- *User need:* Task tracking, project management, team coordination
|
||||
- *Social Protocol replacement:* Tasks as Contract Notes in negotiation state. Status changes are signed state transitions.
|
||||
- *Social Protocol advantage:* Portable project history. Tasks are data you own.
|
||||
|
||||
** Upwork / Fiverr / Freelancer
|
||||
- *User need:* Find freelancers, manage contracts, escrow payments
|
||||
- *Social Protocol replacement:* SCAL contracts for service agreements. HODL invoice escrow. Multi-level arbitration. Reputation tied to DID history.
|
||||
- *Social Protocol advantage:* Lower fees, portable reputation, no platform lock-in.
|
||||
|
||||
* Identity & Infrastructure
|
||||
|
||||
** Google / Apple ID
|
||||
- *User need:* Single sign-on across the internet
|
||||
- *Social Protocol replacement:* DID-based authentication via Personas. No central identity provider. User controls which Persona is used for which service.
|
||||
- *Social Protocol advantage:* No surveillance (Google sees every SSO login). Granular persona isolation. No single point of failure.
|
||||
|
||||
** ENS (Ethereum Name Service)
|
||||
- *User need:* Human-readable decentralized names
|
||||
- *Social Protocol replacement:* Social protocol naming registry with similar auction model. But integrated with PDS, messaging, contracts, and payments — a name in the protocol is a full identity, not just a pointer to a wallet.
|
||||
- *Social Protocol advantage:* Names come with native capabilities (PDS, messaging, contracts). ENS is names-only.
|
||||
|
||||
* The [[id:3aa22300-2f25-57b0-8787-9f199cc978b1][Competitive Analysis]]: What This Changes
|
||||
|
||||
The social protocol is not competing with any single product. It is competing with the /aggregate/ of 20+ products — and the friction of managing 20+ separate accounts, logins, reputations, and data silos.
|
||||
|
||||
** The Real Competitor Is the Status Quo
|
||||
|
||||
The centralized internet works well enough for most people. The friction is spread across 20+ platforms — no single platform is bad enough to leave. The social protocol's value proposition is not "Twitter but better" but "one account replaces every platform you use."
|
||||
|
||||
This is a harder sell because:
|
||||
1. The status quo is familiar. Switching all 20+ platforms at once is cognitively overwhelming.
|
||||
2. Network effects at each platform are entrenched. No single platform can be replaced without bringing the users.
|
||||
3. The value of unification compounds with adoption — but requires critical mass to be visible.
|
||||
|
||||
** The Entry Vector Must Be a Niche, Not a Mass Market
|
||||
|
||||
The strategic documents recognize this explicitly. Phase 1 targets underserved communities with clear pain points:
|
||||
- OnlyFans creators facing payment discrimination and censorship
|
||||
- Reddit communities tired of centralized moderation
|
||||
- Developers frustrated with platform lock-in
|
||||
- Adult content platforms facing banking discrimination
|
||||
- NGOs and guilds needing sovereign identity
|
||||
|
||||
Each of these communities has a /specific/ pain point that the protocol solves directly. The win condition is: a user joins for one reason (e.g., censorship-resistant adult content monetization) and discovers the other 19 capabilities as a free bonus.
|
||||
|
||||
** The Structural Advantage Is Unassailable
|
||||
|
||||
No centralized competitor can match the protocol's bundle:
|
||||
- Meta cannot offer portable identity (it destroys their business model)
|
||||
- Google cannot offer private messaging (it destroys their data model)
|
||||
- Stripe cannot offer contracts and social (outside their competence)
|
||||
- DocuSign cannot offer payments and publishing (outside their competence)
|
||||
- The entire category of centralized platforms cannot offer user-owned data
|
||||
|
||||
The only way to compete with the protocol is to build a similar decentralized platform — and that requires matching all four layers (identity, publishing, payments, contracts) simultaneously. No decentralized project has done this. The closest (Farcaster) has identity and social but no payments or contracts. Bluesky has identity and social but no payments or contracts. Ethereum + ENS has identity, payments, and contracts but no social layer.
|
||||
|
||||
** The Risk Is Not Competition but Indifference
|
||||
|
||||
The protocol's biggest risk is not that a competitor builds a better product, but that the status quo friction is tolerable enough that users never switch. The centralized internet is bad — but it is familiar. The protocol is better — but unfamiliar.
|
||||
|
||||
The counterargument: this is true for every platform shift. Email was a worse experience than postal mail in 1992. The web was a worse experience than AOL in 1994. Instagram was a worse experience than Flickr in 2010. Each won because a /specific/ use case was dramatically better, and the rest of the ecosystem followed. The protocol must find its "camera with filters" moment — the one use case that is so clearly superior that users adopt it despite the rest of the ecosystem being immature.
|
||||
|
||||
* Comparison Summary
|
||||
|
||||
|| Social Protocol replaces | Incumbent | Social Protocol advantage | Risk to Social Protocol |
|
||||
|----------------+-----------+----------------+---------------|
|
||||
| Social graph | Facebook | Portable identity, no data mining | Facebook's 3B user moat |
|
||||
| Microblogging | Twitter/X | Algorithm choice, no censorship | Network effects |
|
||||
| Visual content | Instagram | No engagement-extremified algorithm | UX polish gap |
|
||||
| Professional | LinkedIn | Portable rep, no platform fees | Professional network effects |
|
||||
| Video | YouTube | Lens choice, Seeder Rewards | Content moderation surface |
|
||||
| Short video | TikTok | Users choose the algorithm | Discovery algorithm sophistication |
|
||||
| Forums | Reddit | Sovereign moderation, portable identity | Community migration inertia |
|
||||
| Publishing | Medium/Substack | Near-zero fees, content ownership | Creator distribution |
|
||||
| Messaging | WhatsApp/Signal | Multi-persona isolation, onion routing | Friend network effects |
|
||||
| Community | Discord | Cryptographic ownership, forkable | Voice/UX maturity |
|
||||
| E-commerce | eBay/Etsy | <5% fees, transparent reputation | Trust in new platform |
|
||||
| Subscription | OnlyFans/Patreon | No payment discrimination | Creator acquisition cost |
|
||||
| Video hosting | Pornhub | No censorship, Lightning payouts | Reputation risk |
|
||||
| Code hosting | GitHub | Truly decentralized, DID-signed commits | Developer habit |
|
||||
| Identity | Google/Apple ID | No surveillance, persona isolation | Convenience of SSO |
|
||||
| Naming | ENS | Name + PDS + messaging + contracts | ENS's 2M domain moat |
|
||||
| Collaboration | Google Docs | Verifiable history, no platform lock-in | Real-time collaboration UX |
|
||||
| Freelance | Upwork/Fiverr | Lower fees, portable reputation | Liquidity of gig listings |
|
||||
| Meetings | Zoom | P2P, no central server | Call quality/reliability |
|
||||
|
||||
* Conclusion
|
||||
|
||||
The protocol does not compete with any single platform. It offers an alternative to the /entire paradigm/ of centralized internet services. The competitive analysis is not about which platform to beat — it is about which /use case/ to lead with so that users adopt the unified platform despite the rest of the ecosystem being immature.
|
||||
|
||||
The OnlyFans/Patreon entry vector is the strongest Phase 1 play: a community with clear pain (payment discrimination, censorship), high willingness to pay, and low switching costs (creators want their audience independent of the platform). From there, publishing, messaging, and identity flow naturally.
|
||||
|
||||
* References
|
||||
|
||||
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol overview]] (brain docs)
|
||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Social Protocol contract platform]]
|
||||
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first growth scenario]]
|
||||
- Social Protocol Overview (spec repo)
|
||||
- Social Space specification
|
||||
- Exchange and Contracts specification
|
||||
- User journey and platform replacement strategy
|
||||
7
projects/passepartout/strategy/compliance/_index.org
Normal file
7
projects/passepartout/strategy/compliance/_index.org
Normal file
@@ -0,0 +1,7 @@
|
||||
#+title: Compliance
|
||||
#+filetags: :compliance:index:
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 1c4c91ec-c465-44ab-bd91-4c3b45909ddb
|
||||
:END:
|
||||
29
projects/passepartout/strategy/compliance/appi.org
Normal file
29
projects/passepartout/strategy/compliance/appi.org
Normal file
@@ -0,0 +1,29 @@
|
||||
:PROPERTIES:
|
||||
:ID: b852ec69-0fc2-435c-ae1e-6b83e49b3ca3
|
||||
:ID: auto-appi
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: APPI (Act on the Protection of Personal Information — Japan)
|
||||
#+filetags: :passepartout:compliance:framework:appi:
|
||||
|
||||
|
||||
Japan's comprehensive privacy law (amended 2022, fully effective 2023).
|
||||
Applies to any business handling personal information of Japanese residents.
|
||||
Key requirements: consent, purpose specification, data retention limits,
|
||||
cross-border transfer restrictions (opt-in required), mandatory breach reporting,
|
||||
data subject access/deletion rights, pseudonymized/anonymized data provisions.
|
||||
Personal Information Protection Commission (PPC) enforces.
|
||||
|
||||
Penalties: Up to 100M JPY (~$700K) for violations; criminal penalties up to
|
||||
1 year imprisonment. Orders to suspend data processing or delete data.
|
||||
|
||||
Who must comply: All businesses handling personal information of Japanese
|
||||
residents. Extraterritorial — applies to non-Japanese businesses targeting
|
||||
Japanese residents.
|
||||
|
||||
Why it matters: APPI's cross-border transfer restrictions require fine-grained
|
||||
control over which data leaves Japan. The gate stack can encode "this data has
|
||||
APPI cross-border consent flag = false → block egress." First-mover advantage
|
||||
is moderate — few non-Japanese vendors target APPI specifically, and the 2022 report. First-mover advantage is moderate — few non-Japanese vendors target APPI specifically, and the 2022 amendments created a market for dedicated APPI tooling.
|
||||
|
||||
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].
|
||||
28
projects/passepartout/strategy/compliance/apra-cps-234.org
Normal file
28
projects/passepartout/strategy/compliance/apra-cps-234.org
Normal file
@@ -0,0 +1,28 @@
|
||||
:PROPERTIES:
|
||||
:ID: 904f5f12-ec9a-4cbf-854a-0b9b1e11a521
|
||||
:ID: auto-apra-cps-234
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: APRA CPS 234 (Prudential Standard — Information Security)
|
||||
#+filetags: :passepartout:compliance:framework:apra:
|
||||
|
||||
** APRA CPS 234 (Prudential Standard — Information Security)
|
||||
|
||||
Australian Prudential Regulation Authority standard for regulated financial
|
||||
institutions. Requires: clearly defined information security roles and
|
||||
responsibilities, periodic cybersecurity capability assessments, robust control
|
||||
testing, timely remediation of control weaknesses, mandatory notification of
|
||||
material incidents to APRA within 72 hours.
|
||||
|
||||
Who must comply: Banks, insurers, superannuation funds regulated by APRA.
|
||||
~500 entities.
|
||||
|
||||
Penalties: APRA can impose capital requirements, license conditions, or
|
||||
license cancellation for non-compliance. Personal liability for board and
|
||||
senior management.
|
||||
|
||||
Why it matters: CPS 234's control testing requirement creates demand for
|
||||
continuous verification — exactly what the gate stack and [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]]
|
||||
provide. First-mover advantage: CPS 234 is mature (2019) but enforcement is
|
||||
escalating. No vendor provides a deterministic control-testing pipeline.
|
||||
|
||||
30
projects/passepartout/strategy/compliance/basel-iii.org
Normal file
30
projects/passepartout/strategy/compliance/basel-iii.org
Normal file
@@ -0,0 +1,30 @@
|
||||
:PROPERTIES:
|
||||
:ID: 4eef0993-6671-41cf-ba20-d1443a3ec49d
|
||||
:ID: auto-basel-iii
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Basel III (Bank for International Settlements — Basel Committee)
|
||||
#+filetags: :passepartout:compliance:framework:basel:
|
||||
|
||||
** Basel III (Bank for International Settlements — Basel Committee)
|
||||
|
||||
International banking regulatory framework (BIS Basel Committee). Sets minimum
|
||||
capital requirements, liquidity coverage ratio (LCR), net stable funding ratio
|
||||
(NSFR), leverage ratio, and counterparty credit risk requirements. National
|
||||
implementation via local regulators (Federal Reserve, ECB, PRA, BOJ, etc.).
|
||||
|
||||
Who must comply: All internationally active banks. Systemically important
|
||||
financial institutions (G-SIBs) face additional surcharges.
|
||||
|
||||
Penalties: Capital adequacy violations trigger regulatory intervention at
|
||||
increasing severity — restrictions on dividends, mandatory capital raising,
|
||||
management replacement, resolution.
|
||||
|
||||
Why it matters: Basel's risk-weight calculation is rule-heavy and
|
||||
verification-friendly. The gate stack can encode credit risk weight mappings
|
||||
and produce auditable proof that capital calculations follow the correct
|
||||
methodology. First-mover advantage: Basel compliance is done via spreadsheets
|
||||
and specialized risk platforms. No platform uses formal verification for
|
||||
risk-weight mapping correctness. A $100K/yr Basel gate package for a G-SIB is a trivial expense relative to the capital requirement penalty of getting the mapping wrong.
|
||||
|
||||
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].
|
||||
24
projects/passepartout/strategy/compliance/ccpa-cpra.org
Normal file
24
projects/passepartout/strategy/compliance/ccpa-cpra.org
Normal file
@@ -0,0 +1,24 @@
|
||||
:PROPERTIES:
|
||||
:ID: 87996d87-100c-4bf6-8546-a860b9d7c25b
|
||||
:ID: auto-ccpa-cpra
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: CCPA/CPRA (California Consumer Privacy Act)
|
||||
#+filetags: :passepartout:compliance:framework:ccpa:
|
||||
|
||||
|
||||
California's comprehensive privacy law — the closest US analogue to [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]].
|
||||
CPRA (effective 2023) amended and strengthened CCPA. Key rights: right to
|
||||
know, delete, opt out of sale/sharing, correct inaccurate data, limit use
|
||||
of sensitive PI. Private right of action for data breaches.
|
||||
|
||||
Who must comply: For-profit businesses with >$25M revenue, or handling >100K
|
||||
consumer records, or deriving >50% revenue from selling PI. Extraterritorial —
|
||||
applies to any business collecting CA resident data.
|
||||
|
||||
Penalties: $2,500 per violation (intentional: $7,500). Private right of action
|
||||
for breaches: $100-$750 per incident per consumer. CPRA created the California
|
||||
Privacy Protection Agency (CPPA) for enforcement.
|
||||
|
||||
Why it matters: The opt-out/sale/sharing requirements create complex data flow
|
||||
gate rules. The gate stack can encode "this data flow crosses a CCPA boundary"
|
||||
@@ -0,0 +1,49 @@
|
||||
:PROPERTIES:
|
||||
:ID: 36e5b948-e07b-477f-9036-4dfe88254347
|
||||
:ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:UPDATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Compliance Framework Mapping — Global Regulated Industries
|
||||
#+filetags: :passepartout:triad:compliance:global:index:
|
||||
|
||||
This file has been split into atomic framework notes under [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]].
|
||||
|
||||
See [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance framework index]] for the hub with per-framework links.
|
||||
See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] for timing.
|
||||
See [[id:81a815ee-bf2b-4365-9894-b814e4196850][Revenue table]] for pricing and TAM.
|
||||
|
||||
Each framework is its own file in [[id:1c4c91ec-c465-44ab-bd91-4c3b45909ddb][compliance/]]:
|
||||
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]]
|
||||
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC 2]]
|
||||
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]
|
||||
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]]
|
||||
- [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]]
|
||||
- [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]]
|
||||
- [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]]
|
||||
- [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]]
|
||||
- [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]]
|
||||
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]
|
||||
- [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]]
|
||||
- [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]]
|
||||
- [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]]
|
||||
- [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]]
|
||||
- [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]]
|
||||
- [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]]
|
||||
- [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]]
|
||||
- [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]]
|
||||
- [[id:834689e9-be0a-4822-9085-9b6b22294fd2][Privacy Act Australia]]
|
||||
- [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]]
|
||||
- [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]]
|
||||
- [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]]
|
||||
- [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD Brazil]]
|
||||
- [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP Mexico]]
|
||||
- [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]]
|
||||
- [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]]
|
||||
- [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]]
|
||||
- [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF AML/CFT]]
|
||||
- [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]]
|
||||
- [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD Privacy/AI]]
|
||||
- [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]]
|
||||
- [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]]
|
||||
- [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]]
|
||||
@@ -0,0 +1,82 @@
|
||||
:PROPERTIES:
|
||||
:ID: e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:UPDATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Compliance Framework Index — Global Regulated Industries
|
||||
#+filetags: :passepartout:triad:compliance:global:index:hub:
|
||||
|
||||
The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and domain gate package [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][revenue streams]] depend on
|
||||
selling into regulated industries. These industries buy compliance, not software.
|
||||
Each framework below maps to a gate package Passepartout can sell — ACL2-verified
|
||||
gate rules that produce deterministic audit trails.
|
||||
|
||||
See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] and [[id:81a815ee-bf2b-4365-9894-b814e4196850][Revenue table]] for the consolidated view.
|
||||
|
||||
* US Frameworks
|
||||
|
||||
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] — Health privacy ($50K/yr, 500K+ orgs)
|
||||
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC 2]] — Service organization controls ($50K/yr, 100K+ orgs)
|
||||
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] — Federal cloud authorization ($100K/yr, 1K providers)
|
||||
- [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] — Financial controls ($50K/yr, 10K orgs)
|
||||
- [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] — Financial privacy ($40K/yr, 20K orgs)
|
||||
- [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] — NY financial cybersecurity ($30K/yr, 3K orgs)
|
||||
- [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]] — California privacy ($40K/yr, 50K+ orgs)
|
||||
|
||||
* Canada
|
||||
|
||||
- [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]] — Provincial privacy ($25K/yr, 10K+ orgs)
|
||||
|
||||
* UK and EU
|
||||
|
||||
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] — EU privacy ($50K/yr, 500K+ orgs)
|
||||
- [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] — UK privacy ($40K/yr, 100K+ orgs)
|
||||
- [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] — Network security ($50K/yr, 160K orgs)
|
||||
- [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] — AI regulation ($75K/yr, 100K+ orgs)
|
||||
- [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] — Financial resilience ($50K/yr, 22K+ orgs)
|
||||
- [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]] — Digital identity ($30K/yr, 10K+ orgs)
|
||||
- [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] — Product cybersecurity ($40K/yr, 50K+ orgs)
|
||||
|
||||
* Asia-Pacific
|
||||
|
||||
- [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] — Japan privacy ($40K/yr, 100K+ orgs)
|
||||
- [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]] — Japan cloud authorization ($75K/yr, 500 providers)
|
||||
- [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]] — South Korea privacy ($35K/yr, 50K+ orgs)
|
||||
- [[id:834689e9-be0a-4822-9085-9b6b22294fd2][Privacy Act]] — Australia privacy ($35K/yr, 50K+ orgs)
|
||||
- [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]] — Australian financial security ($40K/yr, 500 orgs)
|
||||
- [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]] — Australian cloud authorization ($75K/yr, 300 providers)
|
||||
- [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] — India privacy ($30K/yr, 500K+ orgs)
|
||||
|
||||
* Latin America
|
||||
|
||||
- [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]] — Brazil privacy ($30K/yr, 200K+ orgs)
|
||||
- [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP]] — Mexico privacy ($25K/yr, 50K+ orgs)
|
||||
|
||||
* International
|
||||
|
||||
- [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] — ISMS ($40K/yr, 60K+ orgs)
|
||||
- [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] — Privacy management ($35K/yr, 1K+ orgs)
|
||||
- [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] — Banking capital ($100K/yr, 500 G-SIBs)
|
||||
- [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] — AML/CFT ($50K/yr, 50K+ orgs)
|
||||
- [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS 17]] — Insurance accounting ($75K/yr, 5K+ orgs)
|
||||
- [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD Guidelines]] — Privacy/AI principles (indirect)
|
||||
- [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]] — Development finance ($50K/yr)
|
||||
- [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] — Project finance ($50K/yr)
|
||||
- [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]] — Trade facilitation ($30K/yr, 50K+ orgs)
|
||||
|
||||
* Strategic View
|
||||
|
||||
| Region | Frameworks | Total TAM | First-mover priority |
|
||||
|--------|-----------|-----------|---------------------|
|
||||
| US | 7 | ~$33B | FedRAMP (procurement gate), NY DFS 500 (growing) |
|
||||
| UK/EU | 7 | ~$24B | NIS2 (2025 deadline), AI Act (Aug 2026), DORA (in effect) |
|
||||
| Asia-Pacific | 7 | ~$9B | DPDP (rules drafting), ISMAP/IRAP (gov cloud gates) |
|
||||
| Latin America | 2 | ~$7B | LGPD (largest LATAM market) |
|
||||
| International | 9 | ~$4.5B | ISO 27001 (universal baseline), World Bank/IFC (no market exists) |
|
||||
|
||||
The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] is enforced through
|
||||
[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate packages]] running on a
|
||||
[[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], creating
|
||||
[[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] that compounds with every framework
|
||||
added. See [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]] and
|
||||
[[id:81a815ee-bf2b-4365-9894-b814e4196850][Full revenue table]] for the consolidated view.
|
||||
33
projects/passepartout/strategy/compliance/cra.org
Normal file
33
projects/passepartout/strategy/compliance/cra.org
Normal file
@@ -0,0 +1,33 @@
|
||||
:PROPERTIES:
|
||||
:ID: ce81fefc-b7a8-4be5-912f-55fd30970b6e
|
||||
:ID: auto-cra
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: CRA (EU Cyber Resilience Act)
|
||||
#+filetags: :passepartout:compliance:framework:cra:
|
||||
|
||||
transaction." First-mover advantage: wallets are being built now; the provider
|
||||
that integrates with the wallet standard first locks in the identity gate
|
||||
integration.
|
||||
|
||||
** CRA (Cyber Resilience Act)
|
||||
|
||||
EU regulation (effective 2025-2027 phased). Mandates cybersecurity requirements
|
||||
for products with digital elements (hardware and software). Requires: secure-bydesign, vulnerability handling, security updates for minimum 5 years, SBOM
|
||||
(software bill of materials) disclosure, CE marking for cybersecurity.
|
||||
|
||||
Who must comply: Manufacturers, importers, and distributors of connected products
|
||||
sold in the EU. Categories: default (self-declaration), Class I (third-party
|
||||
audit), Class II (notified body assessment).
|
||||
|
||||
Penalties: Up to 15M EUR or 2.5% of global turnover for non-compliance with
|
||||
reporting obligations.
|
||||
|
||||
Why it matters: CRA's CE marking requirement creates a certification pipeline
|
||||
that the [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] can supply. If [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s gate stack is
|
||||
itself CRA-compliant (verified by the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]]), it becomes the
|
||||
compliance infrastructure for any product built on it. First-mover advantage:
|
||||
Class II products require notified body assessment — the bottleneck is notified
|
||||
body capacity. The gate stack's automated evidence pipeline bypasses the
|
||||
bottleneck.
|
||||
|
||||
@@ -0,0 +1,18 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: c34940cc-090e-57c4-8020-e78b1d32b96c
|
||||
:END:
|
||||
#+title: Domain Gate Rule Subscriptions
|
||||
#+filetags: :passepartout:revenue:gate-rules:compliance:subscription:
|
||||
|
||||
Pre-verified [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate rule]] packages for specific compliance domains. Translated from published regulations by the LLM, verified by ACL2, reviewed by a human for the 5% ambiguous edge cases.
|
||||
|
||||
- [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] package: $50K/yr
|
||||
- [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]] package: $50K/yr
|
||||
- [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] package: $50K/yr
|
||||
- [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] package: $100K/yr
|
||||
- Combined enterprise: $250K/yr
|
||||
|
||||
Switching costs are high — changing packages means re-verifying the fact store against new rules. The [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] compounds: a hospital at $250K/yr in year one grows to $500K-$1M by year five as more packages are added and the fact store becomes more valuable than the software itself.
|
||||
|
||||
20 subscriptions in year one = $1M-$5M. These Each gate package wraps the social protocol [[id:f6cfc54b-919b-4311-bcbf-65e976755d40][Note primitive]] into a domain-specific authorization boundary. These packages are verified using the [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] and scored by the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]].
|
||||
30
projects/passepartout/strategy/compliance/dora.org
Normal file
30
projects/passepartout/strategy/compliance/dora.org
Normal file
@@ -0,0 +1,30 @@
|
||||
:PROPERTIES:
|
||||
:ID: 717ef2df-2a80-4362-b23a-5e7e12554251
|
||||
:ID: auto-dora
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: DORA (Digital Operational Resilience Act)
|
||||
#+filetags: :passepartout:compliance:framework:dora:
|
||||
|
||||
** DORA (Digital Operational Resilience Act)
|
||||
|
||||
EU regulation (effective January 2025) for the financial sector. Requires:
|
||||
ICT risk management, incident reporting, digital operational resilience testing,
|
||||
ICT third-party risk management (including contractual access and audit rights
|
||||
for critical ICT providers), information sharing, threat-led penetration testing
|
||||
(TLPT) for systemic institutions.
|
||||
|
||||
Who must comply: 22,000+ financial entities in the EU (banks, investment firms,
|
||||
payment processors, crypto-asset providers, insurance companies). Also ICT
|
||||
third-party providers deemed critical.
|
||||
|
||||
Penalties: Up to 2% of average daily turnover × number of days breached, or
|
||||
10M EUR for legal entities. Personal liability for management.
|
||||
|
||||
Why it matters: DORA's third-party risk management requirement is a natural gate
|
||||
stack use case — every ICT provider access must be gated, logged, and auditable.
|
||||
TLPT (threat-led penetration testing) maps to the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]]. First-mover
|
||||
advantage is extremely time-sensitive: DORA is already in effect (January 2025).
|
||||
Financial institutions are scrambling for compliance tooling. A DORA gate package
|
||||
at $50K/yr with zero incremental cost per additional user is an immediate sale.
|
||||
|
||||
32
projects/passepartout/strategy/compliance/dpdp-act.org
Normal file
32
projects/passepartout/strategy/compliance/dpdp-act.org
Normal file
@@ -0,0 +1,32 @@
|
||||
:PROPERTIES:
|
||||
:ID: fed19a24-ad81-4837-a12b-dafbd3ec110a
|
||||
:ID: auto-dpdp-act
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: DPDP Act (Digital Personal Data Protection Act — India)
|
||||
#+filetags: :passepartout:compliance:framework:dpdp:
|
||||
|
||||
|
||||
India's first comprehensive federal privacy law (enacted August 2023, rules
|
||||
drafting in progress, enforcement expected 2026-2027). Key features: consent
|
||||
for personal data processing, data processor obligations, data principal rights
|
||||
(right to access, correction, erasure, grievance redressal), Data Protection
|
||||
Board of India (DPBI) enforcement, significant penalties, exempted government
|
||||
processing for sovereignty/national security.
|
||||
|
||||
Penalties: Up to 250 Cr INR (~$30M) per breach. Data fiduciary bears primary
|
||||
responsibility regardless of processor fault.
|
||||
|
||||
Who must comply: Any organization processing personal data of Indian residents,
|
||||
where the data is collected in India or used to profile Indian residents.
|
||||
Offshore data processors are in scope.
|
||||
|
||||
Why it matters: DPDP is a greenfield privacy regime — India had no comprehensive
|
||||
privacy law before 2023. The rules (implementation details) are being drafted
|
||||
now. This is the widest first-mover window in the global privacy landscape:
|
||||
organizations need compliance tooling that doesn't exist yet. The gate stack's
|
||||
consent-managed data access model maps directly to DPDP's consent framework.
|
||||
A DPDP gate package at $30K/yr (discounted for India market) captures a market
|
||||
of hundreds of thousands of businesses with no incumbent vendor.
|
||||
|
||||
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].
|
||||
29
projects/passepartout/strategy/compliance/eidas2.org
Normal file
29
projects/passepartout/strategy/compliance/eidas2.org
Normal file
@@ -0,0 +1,29 @@
|
||||
:PROPERTIES:
|
||||
:ID: b8cf51e8-5f39-49ad-9547-a792a2e446aa
|
||||
:ID: auto-eidas2
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: eIDAS 2.0 (European Digital Identity Framework)
|
||||
#+filetags: :passepartout:compliance:framework:eidas2:
|
||||
|
||||
|
||||
** eIDAS 2.0 (Electronic Identification, Authentication and Trust Services)
|
||||
|
||||
EU regulation (amended 2024). Creates the EU Digital Identity Wallet — mandatory
|
||||
for member states to offer, optional for citizens. Requires: qualified electronic
|
||||
signatures/seals/timestamps, qualified trust service providers (QTSPs), and the
|
||||
EU Digital Identity Wallet for identity verification across borders.
|
||||
|
||||
Who must comply: Trust service providers, government digital identity systems,
|
||||
any organization accepting eIDAS-qualified identities. 27 member states must
|
||||
provide wallets by 2026.
|
||||
|
||||
Penalties: Member state enforcement; penalties vary but non-compliance blocks
|
||||
access to the EU digital identity market.
|
||||
|
||||
Why it matters: eIDAS 2.0 creates a verified digital identity layer across the
|
||||
EU. The gate stack can integrate with eIDAS wallets as the identity provider
|
||||
for gate rules — "only X, authenticated via eIDAS wallet, may approve this
|
||||
transaction." First-mover advantage: wallets are being built now; the provider — the one that First-mover advantage: wallets are being built now; the provider that integrates with the gate stack first becomes the compliance standard for eIDAS-authenticated transactions.
|
||||
|
||||
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].
|
||||
33
projects/passepartout/strategy/compliance/eu-ai-act.org
Normal file
33
projects/passepartout/strategy/compliance/eu-ai-act.org
Normal file
@@ -0,0 +1,33 @@
|
||||
:PROPERTIES:
|
||||
:ID: 06fcdb02-2643-4f9d-ab41-e711a99cc390
|
||||
:ID: auto-eu-ai-act
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: EU AI Act
|
||||
#+filetags: :passepartout:compliance:framework:eu:
|
||||
|
||||
** EU AI Act
|
||||
|
||||
First comprehensive AI regulation globally (effective August 2026). Risk-based
|
||||
tiers: unacceptable (banned), high-risk (conformity assessment), limited
|
||||
(transparency), minimal (code of conduct). High-risk systems require: risk
|
||||
management, data governance, technical documentation, transparency, human
|
||||
oversight, accuracy/robustness/cybersecurity. Third-party conformity assessment
|
||||
for some high-risk systems (notified bodies).
|
||||
|
||||
Who must comply: Providers and deployers of AI systems in the EU. Extraterritorial
|
||||
if the AI system output is used in the EU. Scope covers GPAI (general-purpose AI)
|
||||
with additional obligations for systemic-risk GPAI.
|
||||
|
||||
Penalties: Up to 35M EUR or 7% of global turnover (higher than [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]).
|
||||
|
||||
Why it matters: The EU AI Act's conformity assessment requirement creates an
|
||||
instant certification market. [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s gate stack can serve as the
|
||||
human oversight and accuracy/robustness infrastructure for any AI system
|
||||
deployed through it. The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] argument applies at maximum
|
||||
force: an ACL2-verified gate stack is the most defensible approach to AI Act
|
||||
compliance. First-mover advantage: the regulation takes effect August 2026.
|
||||
No certification body or tool vendor has an ACL2-based compliance pipeline.
|
||||
First to market captures the standard-setting role.
|
||||
|
||||
** [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA (Digital Operational Resilience Act)]]
|
||||
35
projects/passepartout/strategy/compliance/fatf.org
Normal file
35
projects/passepartout/strategy/compliance/fatf.org
Normal file
@@ -0,0 +1,35 @@
|
||||
:PROPERTIES:
|
||||
:ID: 03ebdb80-a9af-4e76-a443-8556424996ed
|
||||
:ID: auto-fatf
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: FATF (Financial Action Task Force)
|
||||
#+filetags: :passepartout:compliance:framework:fatf:
|
||||
|
||||
risk-weight mapping correctness. A $100K/yr Basel gate package for a G-SIB
|
||||
is a trivial expense relative to the capital requirement penalty of getting the
|
||||
mapping wrong.
|
||||
|
||||
** FATF (Financial Action Task Force) — AML/CFT Standards
|
||||
|
||||
International standard-setter for anti-money laundering and counter-terrorism
|
||||
financing. 40 Recommendations covering: risk assessment, customer due diligence
|
||||
(CDD), beneficial ownership transparency, suspicious transaction reporting,
|
||||
targeted financial sanctions, proliferation financing. National implementation
|
||||
varies by jurisdiction.
|
||||
|
||||
Who must comply: Financial institutions, DNFBPs (designated non-financial
|
||||
businesses and professions), virtual asset service providers (VASPs). In
|
||||
practice: every bank, money service business, crypto exchange, and high-value
|
||||
dealer globally.
|
||||
|
||||
Penalties: National enforcement varies. Systemic failures lead to FATF grey-list
|
||||
(monitoring) or black-list (counter-measures). Grey-listing increases transaction
|
||||
costs — Iran and North Korea are black-listed.
|
||||
|
||||
Why it matters: FATF's CDD requirements are the most widespread and
|
||||
rule-complex compliance obligation globally. The gate stack can encode
|
||||
tiered CDD rules, prove that every customer onboarding followed the correct
|
||||
verification path, and produce an auditable trail for every suspicion report. First-mover advantage is significant — no vendor offers verifiable AML gate automation at scale.
|
||||
|
||||
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].
|
||||
61
projects/passepartout/strategy/compliance/fedramp.org
Normal file
61
projects/passepartout/strategy/compliance/fedramp.org
Normal file
@@ -0,0 +1,61 @@
|
||||
:PROPERTIES:
|
||||
:ID: e6993701-3c67-49bf-82f3-06907572cbf3
|
||||
:ID: auto-fedramp
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: FedRAMP (Federal Risk and Authorization Management Program)
|
||||
#+filetags: :passepartout:compliance:framework:fedramp:
|
||||
|
||||
* FedRAMP (Federal Risk and Authorization Management Program)
|
||||
|
||||
** What it is
|
||||
|
||||
US federal government's standardized approach to security assessment,
|
||||
authorization, and continuous monitoring for cloud services. OMB policy
|
||||
mandate — federal agencies must use FedRAMP-authorized services when available.
|
||||
|
||||
Three impact levels based on data sensitivity:
|
||||
|
||||
| Level | Data type | Examples | Cost to achieve | Timeline |
|
||||
|---------|-----------|---------------------------------|-----------------|----------|
|
||||
| Low | Public or low-sensitivity | Public websites, unclassified comms | $500K-$1M | 6-12 months |
|
||||
| Moderate | Controlled Unclassified Info (CUI) | Tax records, health data, law enforcement | $1M-$3M | 12-24 months |
|
||||
| High | National security, classified | Defense, intelligence, critical infra | $3M-$5M | 18-36 months |
|
||||
|
||||
Two authorization paths:
|
||||
- **JAB (Joint Authorization Board):** provisional authorization by DHS, GSA,
|
||||
DOD. Hardest path, most reusable across agencies.
|
||||
- **Agency:** authorization by a single federal agency for its own use. Faster
|
||||
but less portable.
|
||||
|
||||
Requires continuous monitoring (monthly scans, annual assessments, POA&M
|
||||
for findings).
|
||||
|
||||
** Who must comply
|
||||
|
||||
Any cloud service provider that sells to US federal agencies. Including
|
||||
IaaS, PaaS, SaaS. FedRAMP Marketplace lists authorized providers — agencies
|
||||
are strongly discouraged from using non-authorized services.
|
||||
|
||||
** Penalties
|
||||
|
||||
No direct fines. Non-authorized providers are simply ineligible for federal
|
||||
contracts. FedRAMP is a procurement gate, not a regulatory one.
|
||||
|
||||
** Why it matters for Passepartout
|
||||
|
||||
FedRAMP is the highest bar and the most expensive certification to obtain.
|
||||
Few cloud providers achieve it (fewer than 300 authorized products as of 2025).
|
||||
But those that do capture the US government market with minimal competition.
|
||||
For Passepartout: a [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provider with FedRAMP Moderate or High
|
||||
authorization can sell to every federal agency. The gate stack's deterministic
|
||||
audit trail maps directly to FedRAMP's continuous monitoring requirement —
|
||||
producing verifiable evidence of control effectiveness on every access, not
|
||||
just during the annual assessment. This is what justifies the
|
||||
[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][FedRAMP gate package]] at $100K/yr (the highest price) — it is not a software
|
||||
package, it is the evidence pipeline for a certification that costs $1M-$5M
|
||||
and 12-36 months to obtain independently. The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] argument
|
||||
applies hardest here: an agency that has relied on a FedRAMP-authorized compute
|
||||
provider for five years cannot switch without re-running the entire authorization
|
||||
process with a new provider.
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
:PROPERTIES:
|
||||
:ID: 558154ea-e63a-4c45-998c-26ce8588585b
|
||||
:ID: auto-first-mover-window
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: First-Mover Window Analysis
|
||||
#+filetags: :passepartout:compliance:strategy:first-mover:
|
||||
|
||||
* First-Mover Window Analysis
|
||||
|
||||
The first-mover window is the time in which a new compliance tool can establish
|
||||
dominance before incumbents respond or the market settles on a standard approach.
|
||||
|
||||
| Window | Frameworks | Rationale |
|
||||
|--------|-----------|-----------|
|
||||
| **Critical (<12 months)** | [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] (Aug 2026 effective), [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] (Oct 2025 deadline), [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] (Jan 2025 — already in effect) | Regulation is active or imminent. Buyers are desperate. No established vendor. |
|
||||
| **Wide (12-36 months)** | [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] 2023 (rules drafting), India privacy; Privacy Act Review (Australia); [[id:f6a0c00e-e922-44af-99ce-6412c4b73745][Quebec Law 25]]; [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] phased enforcement | Regulation not yet fully enforced. Rules being written. Market forming. |
|
||||
| **Mature (commodity)** | [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] (2018), [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] (2002), [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] (1996), [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] (1999), [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] (2010), [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] 40 Recs | Market has established vendors. First-mover advantage requires displacing incumbents via superior architecture. |
|
||||
| **Latent (undiscovered)** | [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD]] AI Principles, [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]], [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]], [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] | Compliance exists but is document-based or consultant-delivered. No software market has formed. The first gate package creates the category. |
|
||||
|
||||
|
||||
|
||||
These windows define which frameworks are worth building a gate package for
|
||||
first. The [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance index]] maps each to a
|
||||
[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] gate package, and the
|
||||
[[id:81a815ee-bf2b-4365-9894-b814e4196850][revenue table]] sizes the market. The
|
||||
[[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] dynamics determine which window to enter
|
||||
first.
|
||||
@@ -0,0 +1,18 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 45ea493b-94ad-5885-aa65-0c846e5c3c1d
|
||||
:END:
|
||||
#+title: Gate Rule Encoding from Codified Domains
|
||||
#+filetags: :passepartout:gates:rules:encoding:llm:translation:
|
||||
|
||||
Laws, regulations, standards, procedures, and technical specifications are already written down in structured text. The LLM does not need to *reason* about them — it needs to *translate* them into gate rules and ACL2 theorems.
|
||||
|
||||
Example: The US Federal Acquisition Regulation (FAR) is ~2,000 pages. A frontier LLM can ingest the FAR and produce a plist of gate rules:
|
||||
- (if contract > $250K AND not small-business-set-aside → :deny)
|
||||
- (if sole-source AND no justification-documented → :deny, produce-justification)
|
||||
|
||||
ACL2 verifies the rule set for internal consistency. Screamer checks against existing compliance facts. The human reviews the bootstrap output and approves or corrects individual rules.
|
||||
|
||||
The key distinction: the LLM is not *extracting knowledge from prose* — it is *translating a known rule system into a formal representation.* The result is not "the LLM's best guess" but "the rule set as stated in the source document, mechanically transcribed."
|
||||
|
||||
For codified domains, the encoding cost drops from weeks to hours. The only bottleneck is human review of the 5% ambiguous rules. This is what makes the [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]] economically viable — once gates are encoded, verification is near-free. The resulting rules are packaged into [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate packages]] that can be reused across deployments.
|
||||
55
projects/passepartout/strategy/compliance/gdpr.org
Normal file
55
projects/passepartout/strategy/compliance/gdpr.org
Normal file
@@ -0,0 +1,55 @@
|
||||
:PROPERTIES:
|
||||
:ID: 513d5996-4ac7-4567-a992-18fc01599104
|
||||
:ID: auto-gdpr
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: GDPR (General Data Protection Regulation)
|
||||
#+filetags: :passepartout:compliance:framework:gdpr:
|
||||
|
||||
* GDPR (General Data Protection Regulation)
|
||||
|
||||
** What it is
|
||||
|
||||
EU regulation (effective May 2018) governing the processing of personal data of
|
||||
natural persons in the EU. Extraterritorial — applies to any organization
|
||||
processing EU personal data regardless of where the organization is based.
|
||||
|
||||
Key requirements:
|
||||
- Lawful basis for processing (consent, contract, legal obligation, vital
|
||||
interests, public task, legitimate interests)
|
||||
- Data minimization — collect only what is necessary
|
||||
- Purpose limitation — do not reuse data for incompatible purposes
|
||||
- Storage limitation — delete when no longer needed
|
||||
- Right of access, rectification, erasure (right to be forgotten),
|
||||
data portability, restriction, objection
|
||||
- Data Protection Impact Assessment (DPIA) for high-risk processing
|
||||
- Breach notification within 72 hours to supervisory authority
|
||||
- Data Protection Officer (DPO) appointment for certain controllers/processors
|
||||
- Data Processing Agreements (DPAs) between controllers and processors
|
||||
|
||||
** Who must comply
|
||||
|
||||
Any organization that processes personal data of EU residents. Includes
|
||||
controllers (determine purposes and means) and processors (process on behalf
|
||||
of controller). Non-EU organizations with EU data subjects are in scope.
|
||||
|
||||
** Penalties
|
||||
|
||||
Up to 20M EUR or 4% of annual global turnover, whichever is higher. Tiered
|
||||
system. Supervisory authorities in each member state enforce. Private right
|
||||
of action for damages.
|
||||
|
||||
** Why it matters for Passepartout
|
||||
|
||||
GDPR is the most extraterritorial and aggressively enforced privacy framework.
|
||||
The gate stack's principle of least privilege maps naturally to GDPR's data
|
||||
minimization requirement. Every data access is gated by a verified rule that
|
||||
states the purpose — the proof log is a built-in DPIA artifact. For the
|
||||
[[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]: a provider processing proofs on EU users' gate data must
|
||||
maintain DPAs with all clients. Proof logs themselves may constitute personal
|
||||
data if they reference natural persons (names in access rules, etc.), creating
|
||||
a demand for privacy-preserving proof techniques. This is why the
|
||||
[[id:c34940cc-090e-57c4-8020-e78b1d32b96c][GDPR gate package]] includes data-processing agreement templates and
|
||||
purpose-boundary gate rules that are independently verified by the provider's
|
||||
[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]].
|
||||
|
||||
24
projects/passepartout/strategy/compliance/glba.org
Normal file
24
projects/passepartout/strategy/compliance/glba.org
Normal file
@@ -0,0 +1,24 @@
|
||||
:PROPERTIES:
|
||||
:ID: 4a2bc62b-3f21-4212-9cd9-f9add8fc0be1
|
||||
:ID: auto-glba
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: GLBA (Gramm-Leach-Bliley Act)
|
||||
#+filetags: :passepartout:compliance:framework:glba:
|
||||
|
||||
|
||||
US federal law governing financial institutions' handling of nonpublic personal
|
||||
information (NPI). Requires privacy notices, opt-out rights, and a Safeguards
|
||||
Rule requiring an information security program.
|
||||
|
||||
Who must comply: Banks, credit unions, insurance companies, securities firms,
|
||||
financial advisers. ~20,000 institutions.
|
||||
|
||||
Penalties: FTC-enforced. Civil penalties up to $100K per violation; officers
|
||||
and directors personally liable.
|
||||
|
||||
Why it matters: The Safeguards Rule maps directly to gate stack access controls.
|
||||
Every NPI access is gated; the proof log is the security program's evidence.
|
||||
First-mover advantage is narrow (GLBA is well-understood) but the market is
|
||||
large because every financial institution that dodges [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] still faces GLBA.
|
||||
|
||||
45
projects/passepartout/strategy/compliance/hipaa.org
Normal file
45
projects/passepartout/strategy/compliance/hipaa.org
Normal file
@@ -0,0 +1,45 @@
|
||||
:PROPERTIES:
|
||||
:ID: 84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f
|
||||
:ID: auto-hipaa
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: HIPAA (Health Insurance Portability and Accountability Act)
|
||||
#+filetags: :passepartout:compliance:framework:hipaa:
|
||||
|
||||
* HIPAA (Health Insurance Portability and Accountability Act)
|
||||
|
||||
** What it is
|
||||
|
||||
US federal law enacted 1996. Governs how protected health information (PHI)
|
||||
is stored, transmitted, and accessed. Two relevant rules:
|
||||
|
||||
- **Privacy Rule:** controls use and disclosure of PHI. Patients have rights
|
||||
to access, amend, and request accounting of disclosures. Minimum necessary
|
||||
standard — only the minimum PHI needed for the task may be used.
|
||||
- **Security Rule:** administrative, physical, and technical safeguards for
|
||||
electronic PHI (ePHI). Requires access controls, audit controls, integrity
|
||||
controls, person/entity authentication, and transmission security.
|
||||
|
||||
** Who must comply
|
||||
|
||||
Covered entities (health plans, healthcare clearinghouses, healthcare providers
|
||||
who transmit any ePHI) and business associates (any vendor handling PHI on behalf
|
||||
of a covered entity). Business Associate Agreements (BAAs) are mandatory.
|
||||
|
||||
** Penalties
|
||||
|
||||
Tiered civil penalties: $100-$50,000 per violation, up to $1.5M per year per
|
||||
violation category. Criminal penalties for knowing misuse (up to 10 years
|
||||
imprisonment). State AGs can also bring civil actions.
|
||||
|
||||
** Why it matters for Passepartout
|
||||
|
||||
HIPAA is the largest single compliance market in US healthcare — every hospital,
|
||||
clinic, insurer, and health-tech vendor must comply. The [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][HIPAA gate package]]
|
||||
($50K/yr) encodes the Privacy Rule and Security Rule as ACL2-verifiable gate
|
||||
constraints. Every PHI access attempt passes through the gate stack, producing
|
||||
a machine-checkable audit trail that satisfies the Security Rule's audit control
|
||||
requirement automatically. No separate logging infrastructure needed. Over a
|
||||
five-year deployment, the accumulated fact store and proof history create
|
||||
[[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] — switching to a competitor means discarding all of it.
|
||||
|
||||
27
projects/passepartout/strategy/compliance/ifc-ps.org
Normal file
27
projects/passepartout/strategy/compliance/ifc-ps.org
Normal file
@@ -0,0 +1,27 @@
|
||||
:PROPERTIES:
|
||||
:ID: 68c55deb-72bf-4b15-ac28-bcc792057543
|
||||
:ID: auto-ifc-ps
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: IFC Performance Standards
|
||||
#+filetags: :passepartout:compliance:framework:ifc:
|
||||
|
||||
projects in 100+ countries. Also adopted by many multilateral development banks
|
||||
(MDBs) as their standard.
|
||||
|
||||
Why it matters: ESF compliance is condition precedent to World Bank disbursement.
|
||||
Delays in compliance verification delay project funding. The gate stack's
|
||||
deterministic rule system can encode ESF standards as execution gates — "no
|
||||
disbursement unless ESS5 resettlement plan is verified complete." First-mover
|
||||
advantage: World Bank compliance is entirely document-based (reports, audits,
|
||||
site visits). A verified gate system is unprecedented.
|
||||
|
||||
** [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFC Performance Standards]] (PS)
|
||||
|
||||
International Finance Corporation's standards for environmental and social
|
||||
sustainability in private sector investment. Eight standards: PS1 (risk
|
||||
management), PS2 (labor), PS3 (resource efficiency), PS4 (community health),
|
||||
PS5 (land/resettlement), PS6 (biodiversity), PS7 (indigenous peoples), PS8
|
||||
(cultural heritage). Adopted by over 80 Equator Principles financial
|
||||
institutions (project finance lenders).
|
||||
|
||||
29
projects/passepartout/strategy/compliance/ifrs.org
Normal file
29
projects/passepartout/strategy/compliance/ifrs.org
Normal file
@@ -0,0 +1,29 @@
|
||||
:PROPERTIES:
|
||||
:ID: fc736aec-ef53-4759-9787-62bc8deea2e7
|
||||
:ID: auto-ifrs
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: IFC Performance Standards (Environmental and Social Sustainability)
|
||||
#+filetags: :passepartout:compliance:framework:ifrs:
|
||||
|
||||
|
||||
Who must comply: IFC investees and clients; any project finance deal under
|
||||
the Equator Principles.
|
||||
|
||||
Why it matters: The Equator Principles affect $100B+/yr in project finance.
|
||||
Compliance verification is done by external consultants. The gate stack can
|
||||
automate the evidence collection and provide verifiable proof that each PS
|
||||
requirement has been met before financial close. First-mover advantage: no
|
||||
vendor serves this market with automation — it is entirely consultant-delivered.
|
||||
|
||||
** IFRS (International Financial Reporting Standards)
|
||||
|
||||
International accounting standards (IFRS Foundation, 166 jurisdictions). IFRS 17
|
||||
(insurance contracts, effective 2023) and IFRS 9 (financial instruments) are the
|
||||
most rule-complex — requiring actuarial models, expected credit loss calculations,
|
||||
and contract classification algorithms.
|
||||
|
||||
Who must comply: Publicly listed companies in 166 jurisdictions including the
|
||||
EU, UK, Japan, Australia, Canada (2024), Brazil, India, South Korea, and most of Asia. IFRS 17 alone affects 5K+ insurers with complex actuarial compliance requirements that no automated verification solution currently addresses.
|
||||
|
||||
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].
|
||||
24
projects/passepartout/strategy/compliance/irap.org
Normal file
24
projects/passepartout/strategy/compliance/irap.org
Normal file
@@ -0,0 +1,24 @@
|
||||
:PROPERTIES:
|
||||
:ID: 7f46764b-47b8-4892-a526-2c1b9ee6e6df
|
||||
:ID: auto-irap
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: IRAP (Infosec Registered Assessors Program — Australia)
|
||||
#+filetags: :passepartout:compliance:framework:irap:
|
||||
|
||||
|
||||
** IRAP (Infosec Registered Assessors Program)
|
||||
|
||||
Australian government's cloud security assessment program — analogous to
|
||||
[[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]]. Cloud services used by Australian government agencies must have an
|
||||
IRAP assessment. Managed by the Australian Cyber Security Centre (ACSC).
|
||||
Assessment levels: Protected (highest), Secret (top secret), Unclassified DLM.
|
||||
|
||||
Who must comply: Cloud providers selling to Australian federal, state, and
|
||||
local government agencies. Also critical infrastructure providers.
|
||||
|
||||
Why it matters: Like FedRAMP and [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]], IRAP is a procurement gate. An IRAP
|
||||
Protected-level assessment is expensive and takes 6-12 months. First-mover
|
||||
advantage: the gate stack's deterministic audit trail can be the primary
|
||||
evidence artifact, reducing assessment scope/cost.
|
||||
|
||||
25
projects/passepartout/strategy/compliance/ismap.org
Normal file
25
projects/passepartout/strategy/compliance/ismap.org
Normal file
@@ -0,0 +1,25 @@
|
||||
:PROPERTIES:
|
||||
:ID: 085b76cc-4a65-4660-9c70-85aee10ca99e
|
||||
:ID: auto-ismap
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: ISMAP (Government Security Framework — Japan)
|
||||
#+filetags: :passepartout:compliance:framework:ismap:
|
||||
|
||||
is moderate — few non-Japanese vendors target [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] specifically, and the 2022
|
||||
amendments added requirements that created compliance gaps.
|
||||
|
||||
** ISMAP (Government Information System Security Management and Assessment Program)
|
||||
|
||||
Japan's government cloud security program — analogous to [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]]. Cloud services
|
||||
used by Japanese government agencies must be ISMAP-authorized. Managed by the
|
||||
Digital Agency and the Information-technology Promotion Agency (IPA).
|
||||
|
||||
Who must comply: Cloud service providers selling to Japanese national and local
|
||||
government agencies.
|
||||
|
||||
Why it matters: Like FedRAMP, ISMAP is a procurement gate. Authorization is
|
||||
time-consuming and expensive. A [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provider with ISMAP
|
||||
authorization has exclusive access to the Japanese government market. First-mover
|
||||
advantage is significant — as of 2025, fewer than 100 services are ISMAP-registered.
|
||||
|
||||
32
projects/passepartout/strategy/compliance/iso-27001.org
Normal file
32
projects/passepartout/strategy/compliance/iso-27001.org
Normal file
@@ -0,0 +1,32 @@
|
||||
:PROPERTIES:
|
||||
:ID: e2ab887d-9f28-4da6-8388-e6c035e9d9c5
|
||||
:ID: auto-iso-27001
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: ISO/IEC 27001 (Information Security Management)
|
||||
#+filetags: :passepartout:compliance:framework:iso:
|
||||
|
||||
|
||||
International standard for information security management systems (ISMS).
|
||||
The most widely adopted security certification globally — ~60,000 certified
|
||||
organizations. Requires: risk assessment, security controls (Annex A, 93
|
||||
controls across 4 domains), continuous improvement (Plan-Do-Check-Act),
|
||||
management review, internal audit.
|
||||
|
||||
Who must comply: Self-selected — enterprises pursue ISO 27001 certification
|
||||
because supply chain partners and regulators require it. Increasingly mandatory
|
||||
for: cloud providers, government contractors, critical infrastructure, and
|
||||
regulated financial institutions in multiple jurisdictions.
|
||||
|
||||
Penalties: No direct fines. Losing certification means losing business.
|
||||
|
||||
Why it matters: ISO 27001 is the universal baseline. It is the entry-level
|
||||
certification that opens every other regulated market. The gate stack maps
|
||||
to Annex A controls directly (A.9 access control, A.12 operations security,
|
||||
A.16 incident management, A.18 compliance). First-mover advantage: the ISO
|
||||
27001 audit market is mature ($68B) and entirely manual (auditors flip through
|
||||
binders). A gate stack that produces audit evidence automatically is not
|
||||
competing with other software — it is competing with binders.
|
||||
|
||||
** [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] (Privacy Information Management — PIMS extension to ISO 27001)
|
||||
|
||||
21
projects/passepartout/strategy/compliance/iso-27701.org
Normal file
21
projects/passepartout/strategy/compliance/iso-27701.org
Normal file
@@ -0,0 +1,21 @@
|
||||
:PROPERTIES:
|
||||
:ID: 748b0cc7-7f42-49fb-8ee3-1ae49048a178
|
||||
:ID: auto-iso-27701
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: ISO/IEC 27701 (Privacy Information Management)
|
||||
#+filetags: :passepartout:compliance:framework:iso:
|
||||
|
||||
|
||||
International standard extending [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] for privacy information management.
|
||||
Aligns with [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] requirements. Provides a framework for PII (personally
|
||||
identifiable information) controllers and processors.
|
||||
|
||||
Why it matters: ISO 27701 bridges information security and privacy compliance.
|
||||
An organization with ISO 27001 + ISO 27701 certification has a unified
|
||||
audit framework. The gate stack's access control gates + privacy gates satisfy
|
||||
both standards from the same infrastructure. First-mover advantage: adoption is
|
||||
growing but still low (~1,000 certifications). Early gate package captures the
|
||||
growth market.
|
||||
|
||||
** [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III (Bank for International Settlements — Basel Committee)]]
|
||||
25
projects/passepartout/strategy/compliance/lfp-dppp.org
Normal file
25
projects/passepartout/strategy/compliance/lfp-dppp.org
Normal file
@@ -0,0 +1,25 @@
|
||||
:PROPERTIES:
|
||||
:ID: bafdaa23-de0b-444c-9151-c87ac65add32
|
||||
:ID: auto-lfp-dppp
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: LFPDPPP (Ley Federal de Protección de Datos Personales — Mexico)
|
||||
#+filetags: :passepartout:compliance:framework:lfp:
|
||||
|
||||
|
||||
Mexico's federal privacy law (effective 2010, reformed 2024). Key requirements:
|
||||
consent, notice (privacy notice must specify the "responsible party"), purpose
|
||||
limitation, data subject rights (ARCO — access, rectification, cancellation,
|
||||
opposition + deletion, portability), cross-border data transfer limitations,
|
||||
security breach notification. INAI (National Institute for Transparency,
|
||||
Access to Information and Personal Data Protection) enforces.
|
||||
|
||||
Penalties: Up to 1.9M days of minimum wage (~$5M USD); INAI can also
|
||||
suspend data processing.
|
||||
|
||||
Why it matters: USMCA (US-Mexico-Canada Agreement) trade obligations are
|
||||
pushing toward privacy regime interoperability. A bilingual (Spanish/English)
|
||||
gate package covering both LFPDPPP and US frameworks serves the massive
|
||||
US-Mexico cross-border commerce market. First-mover advantage: LFPDPPP is
|
||||
less automated than [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]; the market has fewer vendors and lower expectations.
|
||||
|
||||
29
projects/passepartout/strategy/compliance/lgpd.org
Normal file
29
projects/passepartout/strategy/compliance/lgpd.org
Normal file
@@ -0,0 +1,29 @@
|
||||
:PROPERTIES:
|
||||
:ID: c871a9f4-dd53-4e93-aa50-6acf0c606a9b
|
||||
:ID: auto-lgpd
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: LGPD (Lei Geral de Proteção de Dados — Brazil)
|
||||
#+filetags: :passepartout:compliance:framework:lgpd:
|
||||
|
||||
|
||||
Brazil's comprehensive privacy law (effective 2020, fines effective 2023).
|
||||
Modeled on [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] but with differences: LGPD defines "data processing agents"
|
||||
(controller and operator), requires appointment of DPO (data protection officer),
|
||||
mandates breach notification to ANPD (National Data Protection Authority) and
|
||||
affected data subjects. 10 legal bases for processing (vs 6 in GDPR).
|
||||
|
||||
Penalties: Up to 2% of revenue in Brazil per violation, capped at 50M BRL
|
||||
(~$10M) per violation. ANPD can also order suspension of processing, partial
|
||||
or total prohibition of database operation.
|
||||
|
||||
Who must comply: Any organization (public or private) processing personal data
|
||||
of Brazilian residents, regardless of where the organization is based. No
|
||||
revenue threshold.
|
||||
|
||||
Why it matters: LGPD affects every business operating in Latin America's largest
|
||||
economy. The 2% revenue penalty structure creates strong economic incentive.
|
||||
First-mover advantage: fewer compliance automation vendors in the Portuguese
|
||||
market. A Portuguese-language gate package with LGPD-specific consent and data
|
||||
subject rights gates captures a market of 210M people.
|
||||
|
||||
35
projects/passepartout/strategy/compliance/nis2.org
Normal file
35
projects/passepartout/strategy/compliance/nis2.org
Normal file
@@ -0,0 +1,35 @@
|
||||
:PROPERTIES:
|
||||
:ID: 748db16a-1382-4e5e-8812-a5d57a8de131
|
||||
:ID: auto-nis2
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: NIS 2 Directive (EU Network and Information Security)
|
||||
#+filetags: :passepartout:compliance:framework:nis2:
|
||||
|
||||
|
||||
EU directive (effective October 2024, member states transpose by October 2025).
|
||||
Replaces NIS (2016). Expands scope from 7 sectors to 15, covering: energy,
|
||||
transport, banking, financial market infrastructure, health, drinking water,
|
||||
wastewater, digital infrastructure, ICT service management, public administration,
|
||||
space, postal services, food, chemicals, manufacturing (critical products).
|
||||
|
||||
Key requirements: risk management measures (supply chain security, incident
|
||||
handling, business continuity), incident notification (24-hour early warning,
|
||||
72-hour full report), C-level accountability (management can be held personally
|
||||
liable for non-compliance), supply chain security for critical vendors.
|
||||
|
||||
Who must comply: ~160,000 entities across EU (up from ~30,000 under NIS).
|
||||
Two tiers: essential (strict) and important (moderate). Extraterritorial — any
|
||||
organization providing services to EU entities in covered sectors.
|
||||
|
||||
Penalties: Up to 10M EUR or 2% of global turnover (essential entities). Personal
|
||||
liability for management.
|
||||
|
||||
Why it matters: NIS2 is the largest European cybersecurity mandate ever.
|
||||
Every requirement maps to a gate rule: supply chain access verification,
|
||||
incident notification triggers, business continuity approval chains. First-mover
|
||||
advantage is urgent — the transposition deadline is October 2025 (17 months).
|
||||
Organizations need gate packages now. No competitor has a declarative gate
|
||||
model that maps to NIS2 requirements. $50K/yr NIS2 gate package is a fast sell.
|
||||
|
||||
** [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]]
|
||||
27
projects/passepartout/strategy/compliance/ny-dfs-500.org
Normal file
27
projects/passepartout/strategy/compliance/ny-dfs-500.org
Normal file
@@ -0,0 +1,27 @@
|
||||
:PROPERTIES:
|
||||
:ID: 581666ba-f72c-406b-8556-93876d2b30bf
|
||||
:ID: auto-ny-dfs-500
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: NY DFS 500 (New York Cybersecurity Regulation)
|
||||
#+filetags: :passepartout:compliance:framework:ny:
|
||||
|
||||
|
||||
** NY DFS 500 (23 NYCRR 500)
|
||||
|
||||
New York State Department of Financial Services cybersecurity regulation for
|
||||
financial services. The most aggressive US state-level financial cybersecurity
|
||||
rule. Requires: risk assessment, penetration testing, multi-factor authentication,
|
||||
incident response plan, annual certification of compliance by the board.
|
||||
|
||||
Who must comply: Any entity regulated by NY DFS — banks, insurers, mortgage
|
||||
brokers, virtual currency companies operating in New York. ~3,000 institutions.
|
||||
|
||||
Penalties: $200K-$1M per violation; business license revocation possible.
|
||||
|
||||
Why it matters: The annual board certification requirement creates demand for
|
||||
verifiable evidence of control effectiveness — exactly what the gate stack
|
||||
produces. First-mover advantage is significant (few vendors target NY DFS 500
|
||||
specifically) and the regulation is a template that other states are adopting.
|
||||
|
||||
Part of the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance framework index]].
|
||||
24
projects/passepartout/strategy/compliance/oecd.org
Normal file
24
projects/passepartout/strategy/compliance/oecd.org
Normal file
@@ -0,0 +1,24 @@
|
||||
:PROPERTIES:
|
||||
:ID: 022109ad-f031-44c4-8ea0-0b3c9402ca90
|
||||
:ID: auto-oecd
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: OECD Guidelines
|
||||
#+filetags: :passepartout:compliance:framework:oecd:
|
||||
|
||||
verification path, and produce an auditable trail for every suspicion
|
||||
determination. First-mover advantage: AML compliance is a $50B+ market
|
||||
dominated by legacy vendors (LexisNexis, Thomson Reuters, FICO). None use
|
||||
formal verification. The gate stack's proof log is a "deterministic audit
|
||||
trail" that regulators would recognize as superior to the current paper-trail
|
||||
approach.
|
||||
|
||||
** OECD Privacy Guidelines and AI Principles
|
||||
|
||||
OECD Privacy Guidelines (revised 2013): Eight principles — collection limitation,
|
||||
data quality, purpose specification, use limitation, security safeguards,
|
||||
openness, individual participation, accountability. Non-binding but foundational
|
||||
— the basis for [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]], [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]], [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]], and most other privacy laws.
|
||||
|
||||
OECD AI Principles (adopted 2019, updated 2024): Five values-based principles
|
||||
— inclusive growth and well-being, human-centered values and fairness,
|
||||
31
projects/passepartout/strategy/compliance/pipa.org
Normal file
31
projects/passepartout/strategy/compliance/pipa.org
Normal file
@@ -0,0 +1,31 @@
|
||||
:PROPERTIES:
|
||||
:ID: e777064d-9950-42d5-980d-8c78cda91500
|
||||
:ID: auto-pipa
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: PIPA (Personal Information Protection Act — South Korea)
|
||||
#+filetags: :passepartout:compliance:framework:pipa:
|
||||
|
||||
|
||||
South Korea's comprehensive privacy law (enacted 2011, major amendments 2023
|
||||
and 2024). One of the strictest privacy regimes globally. Key requirements:
|
||||
consent, data minimization, purpose limitation, mandatory privacy impact
|
||||
assessment, data protection officer, breach notification within 72 hours,
|
||||
cross-border transfer restrictions, right to request data transmission
|
||||
(portability). The Personal Information Protection Commission (PIPC) enforces
|
||||
aggressively.
|
||||
|
||||
Penalties: Up to 3% of revenue (raised from 0.5% in 2024 amendments). Criminal
|
||||
penalties up to 5 years imprisonment. PIPC has levied fines of 100B+ KRW (~$75M)
|
||||
against major tech companies. Class action lawsuits permitted.
|
||||
|
||||
Who must comply: Any organization handling personal information of South Korean
|
||||
residents. Extraterritorial scope is broad and actively enforced.
|
||||
|
||||
Why it matters: PIPA is structurally similar to [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] but with stricter
|
||||
enforcement and higher penalties relative to market size. The gate stack's
|
||||
purpose-boundary gates map directly to PIPA's purpose limitation requirement.
|
||||
First-mover advantage is large — PIPA has fewer compliance automation vendors
|
||||
than GDPR, and the 2024 amendments (stricter consent, higher fines) are still
|
||||
settling.
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
:PROPERTIES:
|
||||
:ID: 834689e9-be0a-4822-9085-9b6b22294fd2
|
||||
:ID: auto-privacy-act-aus
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Privacy Act 1988 (Australia)
|
||||
#+filetags: :passepartout:compliance:framework:privacy:
|
||||
|
||||
|
||||
Australia's federal privacy law (amended 2023-2025). Comprehensive reform in
|
||||
progress — the Privacy Act Review (2023) proposes significant expansion:
|
||||
tiered penalties up to $50M AUD (or 30% of turnover, or 3x benefit obtained),
|
||||
direct right of action for individuals, new tort of serious invasion of privacy,
|
||||
children's privacy code, automated decision-making transparency.
|
||||
|
||||
Who must comply: Most Australian businesses with >$3M AUD turnover; all
|
||||
health service providers; all businesses handling tax file numbers. Extraterritorial
|
||||
— applies to any organization with an Australian link.
|
||||
|
||||
Penalties: Current maximum $50M AUD (from amendments effective late 2024).
|
||||
OAIC (Office of the Australian Information Commissioner) enforces. New direct
|
||||
right of action will increase private litigation.
|
||||
|
||||
Why it matters: The Privacy Act Review's proposed automated decision-making
|
||||
transparency requirements are unique — organizations must disclose the logic
|
||||
and expected outcomes of AI decisions. The gate stack's ACL2 proof log is the
|
||||
most defensible transparency artifact available. First-mover advantage: the
|
||||
reforms are being legislated now; early adoption positions the gate stack as
|
||||
the reference implementation.
|
||||
|
||||
** [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234 (Prudential Standard — Information Security)]]
|
||||
26
projects/passepartout/strategy/compliance/quebec-law-25.org
Normal file
26
projects/passepartout/strategy/compliance/quebec-law-25.org
Normal file
@@ -0,0 +1,26 @@
|
||||
:PROPERTIES:
|
||||
:ID: f6a0c00e-e922-44af-99ce-6412c4b73745
|
||||
:ID: auto-quebec-law-25
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Quebec Law 25
|
||||
#+filetags: :passepartout:compliance:framework:quebec:
|
||||
|
||||
gate rules. The gate stack can encode "this data flow crosses a CCPA boundary"
|
||||
and automatically enforce the opt-out at every data access. First-mover
|
||||
advantage is moderate (many CCPA tools exist) but none provide a deterministic,
|
||||
verifiable audit trail — they are all document-based.
|
||||
|
||||
** Canadian provincial privacy (Quebec Law 25, Ontario PHIPA)
|
||||
|
||||
Quebec Law 25 (2023-2024 phased) is Canada's most aggressive privacy
|
||||
regulation — closer to [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] than PIPEDA. Requires: privacy officer appointment,
|
||||
privacy impact assessments, consent modernization, data portability, right to
|
||||
de-index, algorithm transparency (automated decision-making disclosures).
|
||||
Penalties up to $25M CAD or 4% of global revenue.
|
||||
|
||||
Why it matters: The algorithm transparency requirement is unique — organizations
|
||||
must disclose how automated decision systems work. The gate stack's ACL2 proof
|
||||
log is a natural algorithm transparency artifact. First-mover advantage: this
|
||||
is a new requirement with no established vendor tooling.
|
||||
|
||||
67
projects/passepartout/strategy/compliance/revenue-table.org
Normal file
67
projects/passepartout/strategy/compliance/revenue-table.org
Normal file
@@ -0,0 +1,67 @@
|
||||
:PROPERTIES:
|
||||
:ID: 81a815ee-bf2b-4365-9894-b814e4196850
|
||||
:ID: auto-revenue-table
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Compliance Framework Revenue Table
|
||||
#+filetags: :passepartout:compliance:revenue:pricing:
|
||||
|
||||
* Expanded Revenue Table
|
||||
|
||||
| Framework | Region | Gate price/yr | Addressable orgs | Revenue potential | First-mover window | Gate rule type |
|
||||
|-----------|--------|--------------|------------------|-------------------|---------------------|----------------|
|
||||
| [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] | US | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + access control |
|
||||
| SOC 2 | US/Global | $50K | 100K+ | $5B | Mature (incumbent disruption) | Access control + audit |
|
||||
| [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] | EU | $50K | 500K+ | $25B | Mature (incumbent disruption) | Privacy + consent |
|
||||
| [[id:e6993701-3c67-49bf-82f3-06907572cbf3][FedRAMP]] | US | $100K | 1K (providers) | $100M | Moderate (<300 authorized) | Continuous monitoring |
|
||||
| [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] | US | $50K | 10K | $500M | Mature (manual audit disruption) | Financial controls |
|
||||
| [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA]] | US | $40K | 20K | $800M | Moderate | Financial privacy |
|
||||
| [[id:581666ba-f72c-406b-8556-93876d2b30bf][NY DFS 500]] | US (NY) | $30K | 3K | $90M | Wide | Cybersecurity controls |
|
||||
| [[id:87996d87-100c-4bf6-8546-a860b9d7c25b][CCPA/CPRA]] | US (CA) | $40K | 50K+ | $2B | Moderate | Privacy opt-out flows |
|
||||
| [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] | EU | $50K | 160K | $8B | Critical (2025) | Cybersecurity + supply chain |
|
||||
| [[id:06fcdb02-2643-4f9d-ab41-e711a99cc390][EU AI Act]] | EU | $75K | 100K+ | $7.5B | Critical (Aug 2026) | AI risk management |
|
||||
| [[id:717ef2df-2a80-4362-b23a-5e7e12554251][DORA]] | EU | $50K | 22K+ | $1.1B | Critical (in effect) | ICT resilience |
|
||||
| [[id:b8cf51e8-5f39-49ad-9547-a792a2e446aa][eIDAS 2.0]] | EU | $30K | 10K+ | $300M | Wide (wallet buildout) | Identity gates |
|
||||
| [[id:ce81fefc-b7a8-4be5-912f-55fd30970b6e][CRA]] | EU | $40K | 50K+ | $2B | Wide (phased 2025-2027) | Product security |
|
||||
| [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] | UK | $40K | 100K+ | $4B | Mature (GDPR derivative) | Privacy |
|
||||
| [[id:b852ec69-0fc2-435c-ae1e-6b83e49b3ca3][APPI]] | Japan | $40K | 100K+ | $4B | Moderate | Cross-border privacy |
|
||||
| [[id:085b76cc-4a65-4660-9c70-85aee10ca99e][ISMAP]] | Japan | $75K | 500 (providers) | $37.5M | Wide (<100 registered) | Gov cloud assessment |
|
||||
| [[id:e777064d-9950-42d5-980d-8c78cda91500][PIPA]] | South Korea | $35K | 50K+ | $1.75B | Wide (2024 amendments settling) | Privacy + consent |
|
||||
| Privacy Act | Australia | $35K | 50K+ | $1.75B | Wide (reforms legislating) | Privacy + AI transparency |
|
||||
| [[id:904f5f12-ec9a-4cbf-854a-0b9b1e11a521][APRA CPS 234]] | Australia | $40K | 500 | $20M | Moderate | Info security controls |
|
||||
| [[id:7f46764b-47b8-4892-a526-2c1b9ee6e6df][IRAP]] | Australia | $75K | 300 (providers) | $22.5M | Wide | Gov cloud assessment |
|
||||
| [[id:fed19a24-ad81-4837-a12b-dafbd3ec110a][DPDP Act]] | India | $30K | 500K+ | $15B | Wide (rules drafting) | Privacy + consent |
|
||||
| [[id:c871a9f4-dd53-4e93-aa50-6acf0c606a9b][LGPD]] | Brazil | $30K | 200K+ | $6B | Moderate | Privacy |
|
||||
| [[id:bafdaa23-de0b-444c-9151-c87ac65add32][LFPDPPP]] | Mexico | $25K | 50K+ | $1.25B | Wide | Privacy |
|
||||
| [[id:e2ab887d-9f28-4da6-8388-e6c035e9d9c5][ISO 27001]] | Global | $40K | 60K+ | $2.4B | Mature (manual disruption) | ISMS controls |
|
||||
| [[id:748b0cc7-7f42-49fb-8ee3-1ae49048a178][ISO 27701]] | Global | $35K | 1K+ | $35M | Wide (growing) | Privacy management |
|
||||
| [[id:4eef0993-6671-41cf-ba20-d1443a3ec49d][Basel III]] | Global (banking) | $100K | 500 (G-SIBs) | $50M | Mature (incumbent disruption) | Capital adequacy |
|
||||
| [[id:03ebdb80-a9af-4e76-a443-8556424996ed][FATF]] AML/CFT | Global | $50K | 50K+ | $2.5B | Mature (incumbent disruption) | CDD + screening |
|
||||
| [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]] 17 | Global (insurance) | $75K | 5K+ | $375M | Mature (actuarial verification) | Contract classification |
|
||||
| [[id:6a5884c8-e9b5-477e-bbf6-aa9ffd967739][UN/CEFACT]] | Global (trade) | $30K | 50K+ | $1.5B | Latent (no market exists) | Cross-border data rules |
|
||||
| [[id:177aad72-5626-444d-a2e4-af8e1263b125][World Bank ESF]] | Global (dev finance) | $50K | 1K+ (projects) | $50M | Latent (no market exists) | ES compliance gates |
|
||||
| [[id:68c55deb-72bf-4b15-ac28-bcc792057543][IFC PS]] | Global (project finance) | $50K | 500+ (deals) | $25M | Latent (no market exists) | ES compliance gates |
|
||||
|
||||
A [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provider with authorization in 5+ frameworks (FedRAMP +
|
||||
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
|
||||
for regulated cloud globally. The gate package portfolio alone — a mid-size
|
||||
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
||||
At 10,000 such enterprises: $5B/yr. The first-mover advantage is not about any
|
||||
single framework — it is about being the first to offer a unified gate stack
|
||||
that maps to all of them.
|
||||
|
||||
|
||||
A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
|
||||
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
|
||||
for regulated cloud globally. The gate package portfolio alone — a mid-size
|
||||
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
||||
At 10,000 such enterprises: $5B/yr.
|
||||
|
||||
A compute marketplace provider with authorization in 5+ frameworks (FedRAMP +
|
||||
ISMAP + IRAP + SOC 2 + ISO 27001) becomes the default infrastructure provider
|
||||
for regulated cloud globally. The gate package portfolio alone — a mid-size
|
||||
enterprise running 10+ packages — generates $500K/yr+ in recurring revenue.
|
||||
At 10,000 such enterprises: $5B/yr. See the [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][compliance index]] for the full
|
||||
framework list, [[id:558154ea-e63a-4c45-998c-26ce8588585b][first-mover window analysis]] for timing strategy, and
|
||||
[[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] for the economic dynamics
|
||||
behind the revenue.
|
||||
54
projects/passepartout/strategy/compliance/soc2.org
Normal file
54
projects/passepartout/strategy/compliance/soc2.org
Normal file
@@ -0,0 +1,54 @@
|
||||
:PROPERTIES:
|
||||
:ID: ed65031c-cbd2-4ad2-bd53-a67791e183cd
|
||||
:ID: auto-soc2
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: SOC 2 (System and Organization Controls 2)
|
||||
#+filetags: :passepartout:compliance:framework:soc2:
|
||||
|
||||
* SOC 2 (System and Organization Controls 2)
|
||||
|
||||
** What it is
|
||||
|
||||
An auditing standard developed by AICPA (American Institute of CPAs). Not a law.
|
||||
Certifies that a service organization's controls over security, availability,
|
||||
processing integrity, confidentiality, and privacy meet defined criteria.
|
||||
|
||||
Five Trust Service Criteria (TSC):
|
||||
- **Security** (mandatory): protection against unauthorized access (firewall,
|
||||
access control, intrusion detection)
|
||||
- **Availability** (optional): system available for operation and use as
|
||||
committed (uptime, redundancy, disaster recovery)
|
||||
- **Processing Integrity** (optional): system processing is complete, valid,
|
||||
accurate, timely, and authorized
|
||||
- **Confidentiality** (optional): information designated as confidential is
|
||||
protected as committed
|
||||
- **Privacy** (optional): personal information is collected, used, retained,
|
||||
disclosed, and disposed of in conformity with commitments
|
||||
|
||||
Two types:
|
||||
- **Type I:** controls are suitably designed at a specific point in time
|
||||
- **Type II:** controls operated effectively over a period (6-12 months)
|
||||
|
||||
** Who must comply
|
||||
|
||||
Any SaaS or cloud service provider whose enterprise customers require audited
|
||||
vendors. Table stakes for B2B — most enterprise procurement contracts require
|
||||
SOC 2 Type II.
|
||||
|
||||
** Penalties
|
||||
|
||||
No direct fines (not a law). But losing SOC 2 certification means losing
|
||||
enterprise customers. Misrepresentation of certification status is fraud.
|
||||
|
||||
** Why it matters for Passepartout
|
||||
|
||||
SOC 2 is the entry-level certification for the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]. A provider
|
||||
needs SOC 2 Type II to sell compute to enterprises whose procurement policy
|
||||
requires audited vendors. The gate stack itself maps directly to the Security
|
||||
criterion (access controls, audit trails) — the [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instance's
|
||||
deterministic gate log serves as the evidence artifact for the audit. No
|
||||
separate logging SIEM needed. This is the prerequisite to the larger
|
||||
[[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] play — once enterprises trust the audit trail, they
|
||||
buy domain-specific gate packages for the same infrastructure.
|
||||
|
||||
28
projects/passepartout/strategy/compliance/sox.org
Normal file
28
projects/passepartout/strategy/compliance/sox.org
Normal file
@@ -0,0 +1,28 @@
|
||||
:PROPERTIES:
|
||||
:ID: c9830152-0160-4bdc-ab03-6f308ad43536
|
||||
:ID: auto-sox
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: SOX (Sarbanes-Oxley Act)
|
||||
#+filetags: :passepartout:compliance:framework:sox:
|
||||
|
||||
|
||||
US federal law (2002). Mandates internal controls over financial reporting
|
||||
(ICFR) for publicly traded companies. Section 404 requires management to assess
|
||||
and auditors to attest to the effectiveness of internal controls.
|
||||
|
||||
Who must comply: All US public companies; foreign issuers trading on US exchanges.
|
||||
~6,000 public companies + foreign filers.
|
||||
|
||||
Penalties: Up to $5M fines and 20 years imprisonment for certifying false
|
||||
financial statements. CEO and CFO personally liable.
|
||||
|
||||
Why it matters: Every financial control is a gate rule — who can approve a
|
||||
journal entry, who can release a payment, who can modify a vendor record. The
|
||||
gate stack encodes these as ACL2-verified rules and produces the audit trail
|
||||
that the external auditor needs for Section 404 attestation. First-mover
|
||||
advantage: SOX is mature (24 years old) but the audit market is $4B+ and
|
||||
entirely manual — no competitor has automated the evidence pipeline.
|
||||
|
||||
** [[id:4a2bc62b-3f21-4212-9cd9-f9add8fc0be1][GLBA (Gramm-Leach-Bliley Act)]]
|
||||
|
||||
22
projects/passepartout/strategy/compliance/uk-gdpr.org
Normal file
22
projects/passepartout/strategy/compliance/uk-gdpr.org
Normal file
@@ -0,0 +1,22 @@
|
||||
:PROPERTIES:
|
||||
:ID: 9bc29937-d59a-4ae4-9623-3d17a1fe6ebb
|
||||
:ID: auto-uk-[[id:513d5996-4ac7-4567-a992-18fc01599104][gdpr]]
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: UK GDPR (Post-Brexit Data Protection)
|
||||
#+filetags: :passepartout:compliance:framework:uk:
|
||||
|
||||
|
||||
Post-Brexit, the UK maintains its own version of [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] via the Data Protection
|
||||
Act 2018. Substantively identical to EU GDPR but diverging over time. The UK
|
||||
has announced separate reforms targeting AI and digital identity. ICO (Information
|
||||
Commissioner's Office) enforces. Maximum fines: 17.5M GBP or 4% of global turnover.
|
||||
|
||||
Why it matters: UK GDPR is EU GDPR's twin market — any gate package designed
|
||||
for EU GDPR ports directly with verified translation of terminology (supervisory
|
||||
authority → ICO, DPA → equivalent UK contract clauses). The gate stack's ACL2
|
||||
prover can verify that the UK version's rules are consistent with the EU version
|
||||
(and alert when they diverge). This is a concrete ACL2 application.
|
||||
|
||||
** [[id:748db16a-1382-4e5e-8812-a5d57a8de131][NIS2]] (Network and Information Security Directive)
|
||||
|
||||
36
projects/passepartout/strategy/compliance/un-cefact.org
Normal file
36
projects/passepartout/strategy/compliance/un-cefact.org
Normal file
@@ -0,0 +1,36 @@
|
||||
:PROPERTIES:
|
||||
:ID: 6a5884c8-e9b5-477e-bbf6-aa9ffd967739
|
||||
:ID: auto-un-cefact
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business)
|
||||
#+filetags: :passepartout:compliance:framework:un:
|
||||
|
||||
EU, UK, Japan, Australia, Canada (2024), Brazil, India, South Korea, and most
|
||||
of Asia and Africa. The US (GAAP) is the major holdout.
|
||||
|
||||
Why it matters: [[id:fc736aec-ef53-4759-9787-62bc8deea2e7][IFRS]] 17 and IFRS 9 are algorithmically complex rule sets.
|
||||
Getting an actuarial model or credit loss calculation wrong is a financial
|
||||
reporting error. The gate stack's ACL2 prover can verify that the calculation
|
||||
implementations match the standard's mathematical requirements. First-mover
|
||||
advantage: IFRS 17 was the largest accounting change in a decade. Implementation
|
||||
was a crisis for insurers. The next wave (IFRS 18, sustainability disclosures
|
||||
via ISSB) is coming. A verified IFRS gate package is a unique value proposition.
|
||||
|
||||
** UN/CEFACT (UN Centre for Trade Facilitation and Electronic Business)
|
||||
|
||||
UN standards for electronic data interchange (EDI), trade facilitation, and
|
||||
cross-border data exchange. Key standards: UN/EDIFACT (trade data), Core
|
||||
Component Library (CCL), Multi-Modal Transport Reference Data Model. Basis
|
||||
for WTO Trade Facilitation Agreement compliance.
|
||||
|
||||
Who must comply: Customs authorities, logistics providers, trade finance banks,
|
||||
exporters/importers in 170+ WTO member countries.
|
||||
|
||||
Why it matters: Cross-border trade data exchange is rule-intensive (tariff
|
||||
classification, rules of origin, customs valuation, sanitary/phytosanitary
|
||||
requirements). The gate stack can encode trade compliance rules and prove that
|
||||
every cross-border data exchange satisfies the applicable regulation. First-mover
|
||||
advantage: trade compliance is a $15B market dominated by legacy SAP/Oracle
|
||||
modules and customs brokerages. None use verification.
|
||||
|
||||
29
projects/passepartout/strategy/compliance/world-bank-esf.org
Normal file
29
projects/passepartout/strategy/compliance/world-bank-esf.org
Normal file
@@ -0,0 +1,29 @@
|
||||
:PROPERTIES:
|
||||
:ID: 177aad72-5626-444d-a2e4-af8e1263b125
|
||||
:ID: auto-world-bank-esf
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: World Bank Environmental and Social Framework
|
||||
#+filetags: :passepartout:compliance:framework:world:
|
||||
|
||||
— inclusive growth and well-being, human-centered values and fairness,
|
||||
transparency and explainability, robustness and safety, accountability.
|
||||
Non-binding but influential — the AI Act, Canada's AIDA, and Japan's AI
|
||||
guidelines all cite them.
|
||||
|
||||
Why it matters: The [[id:022109ad-f031-44c4-8ea0-0b3c9402ca90][OECD]] frameworks are indirect revenue drivers. Regulatory
|
||||
alignment with OECD principles is often a procurement requirement for
|
||||
international organizations and development finance institutions. First-mover
|
||||
advantage is about standard-setting: the gate package that maps to OECD
|
||||
principles first becomes the reference implementation.
|
||||
|
||||
** World Bank Environmental and Social Framework (ESF)
|
||||
|
||||
The World Bank's framework for managing environmental and social risk in
|
||||
investment projects. Ten standards: ESS1 (assessment), ESS2 (labor), ESS3
|
||||
(resource efficiency), ESS4 (community health), ESS5 (land/resettlement),
|
||||
ESS6 (biodiversity), ESS7 (indigenous peoples), ESS8 (cultural heritage),
|
||||
ESS9 (financial intermediaries), ESS10 (stakeholder engagement).
|
||||
|
||||
Who must comply: Borrowers and project implementers across World Bank-financed
|
||||
projects in 100+ countries. Also adopted by many multilateral development banks
|
||||
30
projects/passepartout/strategy/compute-marketplace.org
Normal file
30
projects/passepartout/strategy/compute-marketplace.org
Normal file
@@ -0,0 +1,30 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 3c6b0449-a8fb-5b89-b82a-34efb21ef5b5
|
||||
:END:
|
||||
#+title: Social Protocol Compute Marketplace
|
||||
#+filetags: :passepartout:social-protocol:revenue:compute:marketplace:
|
||||
|
||||
[[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instances offer their symbolic engine capacity (ACL2 cycles, Screamer constraint solving, VivaceGraph queries) to other agents on the [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]] network.
|
||||
|
||||
The [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Social protocol infrastructure requirements]] define the network substrate this marketplace runs on.
|
||||
|
||||
But the question is structural: if every user runs their own Passepartout — each with the same symbolic engine, the same gate stack, the same ACL2 prover — why would they need to buy compute from anyone? The answer is that Passepartout's symbolic engine is /domain-specific/, not /generalized/. Local compute handles your daily gate stack (milliseconds per verification). The marketplace sells three things a local instance cannot produce:
|
||||
|
||||
**1. Specialized proof libraries and search strategies.** ACL2 is a search — the prover tries strategies until something works. A fresh Passepartout has generic strategies (the default waterfall, basic arithmetic, simple induction). A provider who has run 10,000 medical-device ISO 13482 proofs has tuned rewrite rules, custom clause processors, cached lemmas, and known failure-mode workarounds for that domain. You don't want to rediscover those from scratch — you buy them as a burst compute transaction. The provider isn't selling raw CPU cycles; they are selling /the accumulated search strategy from every proof ever run in that domain/, pre-packaged as a service. Over time, your own Passepartout learns the patterns and needs less external compute, but the provider stays ahead because they aggregate proof experience from /every/ client in that domain.
|
||||
|
||||
**2. Certification weight for third-party trust.** Your Passepartout can prove "this gate rule is correct" to /you/. ACL2 produces a machine-checkable proof log — anyone can mechanically verify it. But when a hospital buyer evaluating a published [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] gate rule needs to know the rule satisfies the regulation, they do not care about your Passepartout's isolated run of the proof. They want the rule verified by a provider who:
|
||||
- Carries errors-and-omissions insurance for the specific regulation
|
||||
- Submits to annual third-party audits
|
||||
- Maintains compliance documentation for the proof pipeline
|
||||
- Has a publicly verifiable track record of correct certifications
|
||||
|
||||
Your local instance cannot produce any of this. The provider's proof carries /reputational weight/ because the provider is a legal and economic entity, not a process. This is the same reason software is certified by UL or TÜV rather than by the developer running the test suite locally.
|
||||
|
||||
**3. Bootstrap verification for new instances.** A fresh Passepartout cannot verify its own initial state — the bootstrapping problem. You need a working system to generate the proof that the system is correct, but the proof refers to the system itself. The marketplace provides bootstrap proofs from existing trusted providers. Once verified, your instance stands on its own, but the initial self-certification requires an external prover that /already/ has a self-verified image. This is a one-time cost per instance (or per upgrade).
|
||||
|
||||
Secondary but real: burst capacity for heavy proofs (hours-long ACL2 conjectures you do not want tying up your daily agent's CPU), [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] execution (small instances contribute edge cases but cannot run the full suite on every change), and latency guarantees for time-critical gate verifications (trading, emergency shutdown). These are infrastructure economics — the same reason individuals buy cloud burst instances despite having their own hardware.
|
||||
|
||||
If Passepartout instances on the social protocol transact billions of verified operations per day, the spread on compute transactions is enormous.
|
||||
|
||||
The early player that provisions the largest compute capacity on the social protocol becomes the default infrastructure provider for the entire network. This is venture-scale money. The compute marketplace is the engine that powers the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] — certified compute from trusted providers. Together with [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][social protocol usernames]] and other social protocol services, it forms the basis of the [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][investment thesis]].
|
||||
15
projects/passepartout/strategy/cost-structure.org
Normal file
15
projects/passepartout/strategy/cost-structure.org
Normal file
@@ -0,0 +1,15 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9
|
||||
:END:
|
||||
#+title: Cost Structure — Zero Marginal Cost
|
||||
#+filetags: :passepartout:economics:cost:marginal:zero:
|
||||
|
||||
- **One-time cost:** [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate-rule encoding]] for a domain (from hours for codified domains up to months for tacit domains)
|
||||
- **Near-zero marginal cost:** ACL2 proof + Screamer consistency check + VivaceGraph lookup per interaction — all CPU-native, all in-image
|
||||
- **No recurring LLM API costs** for the 80% symbolic reasoning layer
|
||||
- **After [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]]:** pennies per day vs dollars per day for LLM-only
|
||||
|
||||
The cost curve inverts: generation is expensive, verification is cheap. This is the inversion [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] exploits. This is the core insight of [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — symbolic verification costs approach zero while LLM token costs remain constant.
|
||||
|
||||
Token demand shifts from "every interaction burns tokens" to "only unfamiliar interactions burn tokens." Steady-state per-user LLM consumption drops by an order of magnitude.
|
||||
95
projects/passepartout/strategy/effects-growth-flywheel.org
Normal file
95
projects/passepartout/strategy/effects-growth-flywheel.org
Normal file
@@ -0,0 +1,95 @@
|
||||
:PROPERTIES:
|
||||
:ID: 528a0f6c-6fd6-41ed-9d59-237958bdaef2
|
||||
:ID: effects-growth-flywheel
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Effects–Growth Flywheel — How Adoption and Consequences Amplify Each Other
|
||||
#+filetags: :passepartout:strategy:growth:effects:flywheel:
|
||||
|
||||
The [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][effects page]] and the [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][growth page]] treated two sides of the same process as separate timelines. They are not sequential — effects do not wait for adoption to finish, and adoption does not happen before effects begin. They are interleaved at every scale. Each effect is a growth driver; each growth milestone unlocks new effects.
|
||||
|
||||
The key insight: /every systemic effect is a growth engine for the next phase/. There is no phase where effects passively happen while adoption independently proceeds.
|
||||
|
||||
* The Flywheel, Not the Pipeline
|
||||
|
||||
The old model (sequential, linear):
|
||||
|
||||
Growth Phase 0 → Effects Phase 0 → Growth Phase 1 → Effects Phase 1 → ...
|
||||
|
||||
The real model (interleaved, amplifying):
|
||||
|
||||
Enterprise sale → compliance cost drops → more enterprises buy → compliance industry margin erodes → price drops further → small businesses afford gate rules → regulator notices → regulation-as-code → enterprises /must/ buy → ...
|
||||
|
||||
At every scale, the effect /is/ the growth mechanism. There is no waiting for effects to "arrive" after adoption reaches a threshold. The first enterprise that saves $500K on an audit has already triggered the compliance erosion effect — at scale 10⁶, that same effect is a structural industry shift, but it is the same mechanism operating at different magnitudes.
|
||||
|
||||
* Effect–Growth Map at Each Scale
|
||||
|
||||
** Phase 0 (0 → 10² instances, weeks–months)
|
||||
|
||||
| Instance count | Effect that starts | Growth driver generated |
|
||||
|---------------+-------------------+------------------------|
|
||||
| 1–10 | /Scientific reproducibility:/ the first verified paper | Universities buy [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] for their compute clusters |
|
||||
| 1–10 | /Compliance erosion:/ first enterprise replaces audit with gate rule | Competitors must match the cost savings — enterprise sales accelerate |
|
||||
| 10–50 | /Verification API gateway:/ first company runs LLM calls through Passepartout | /Any/ company using LLMs is a customer, not just triad adopters. This effect starts at 10 instances but can scale to millions of API users before growth Phase 1 |
|
||||
|
||||
Key observation: the verified API gateway decouples the effect from triad adoption. A company using the gateway never installs Passepartout — they send API calls to a proxy and get back a proof log. The gateway is an /effect/ that drives /economic growth/ (revenue) without requiring /ecosystem growth/ (instances).
|
||||
|
||||
** Phase 1 (10² → 10⁴ instances, months–years)
|
||||
|
||||
| Instance count | Effect that starts | Growth driver generated |
|
||||
|-------+-------------------+------------------------|
|
||||
| 100–500 | /Regulation as code:/ first regulator encodes a rule as a gate | All regulated entities under that regulator must adopt Passepartout — step function in demand |
|
||||
| 500–2K | /AI safety shift:/ gate rule verification becomes expected in enterprise AI procurement | Every company buying AI services requires a proof log — API gateway demand explodes |
|
||||
| 2K–10K | /Proof library compounding:/ the [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] has enough edge cases to be qualitatively better than any solo library | Competitive advantage for adopters — those not on the network fall behind on verification coverage |
|
||||
|
||||
Key observation: regulation-as-code creates a /step function/ in demand. Before the regulator acts, growth is organic enterprise sales. After, it is mandatory compliance. The timing of the first regulatory encode is the single most leveraged event in the flywheel.
|
||||
|
||||
** Phase 2 (10⁴ → 10⁶ instances, years)
|
||||
|
||||
| Instance count | Effect that starts | Growth driver generated |
|
||||
|-------+-------------------+------------------------|
|
||||
| 10K–50K | /Computational trust:/ PDS model makes surveillance advertising visibly obsolete | Consumer demand for PDS — "why does my bank still own my data?" |
|
||||
| 50K–200K | /Verification cachet:/ /I verify/ becomes a resume signal | Developer adoption accelerates — not from enterprise mandate but from peer pressure and cultural norm |
|
||||
| 200K–1M | /Attestation marketplace:/ verifiable reputation has enough data to be reliable | Insurance products become viable — insurers price unverified code higher |
|
||||
|
||||
Key observation: the shift from enterprise adoption to consumer adoption is cultural, not technical. The technology works at 10K instances. But consumers don't adopt because the tech works — they adopt because the /alternative is socially unacceptable/. The verification cachet effect /is/ the consumer growth engine.
|
||||
|
||||
** Phase 3 (10⁶ → 10⁹ instances, years–generations)
|
||||
|
||||
| Instance count | Effect that starts | Growth driver generated |
|
||||
|-------+-------------------+------------------------|
|
||||
| 1M–10M | /Insurance loop closes:/ premiums for unverified code are 10× verified | Economic necessity drives adoption — not engineering preference, not regulation, but /cost of doing business/ |
|
||||
| 10M–100M | /[[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]:/ regulator references the early player's gate library | New entrants cannot compete with the installed proof base — the moat compounds with every new instance |
|
||||
| 100M–1B | /Compute as geopolitical asset:/ nations run Passepartout instances for digital sovereignty | Nation-state procurement — 100M to 1B happens via government mandate, not organic adoption |
|
||||
|
||||
Key observation: the insurance loop is the /completion of the flywheel/. At this point, adoption is no longer driven by Passepartout's features or benefits — it is driven by the /cost of non-adoption/. The flywheel transitions from pull (people want verification) to push (people cannot afford to be unverified).
|
||||
|
||||
* The Critical Path
|
||||
|
||||
The flywheel has two critical bottlenecks:
|
||||
|
||||
1. /First regulator encodes a rule as a gate./ This is the most leveraged event in Phase 0–1. It converts growth from organic to mandatory in a single domain. Whoever reaches a regulator first — and helps them write that first gate rule — wins that domain permanently.
|
||||
|
||||
2. /First insurer prices unverified code higher./ This is the Phase 2→3 transition. It converts growth from pull to push. The insurer does not need 1B instances to act — they need 10K instances with 2+ years of verifiable track records. The [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] provides the actuarial data; the [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][attestation marketplace]] provides the reputation layer.
|
||||
|
||||
* Summary: Effects and Growth Are the Same Curve
|
||||
|
||||
| Adoption (instances) | Dominant effect | Growth mechanism |
|
||||
|---------------------+----------------+------------------|
|
||||
| 0 → 10² | Compliance cost drops | Enterprise sales — the effect /is/ the value proposition |
|
||||
| 10² → 10⁴ | Regulation becomes executable | Mandate — one regulator converts pull to push in a domain |
|
||||
| 10² → 10⁴ | AI safety shifts to engineering | Verified API gateway sells to /any/ LLM user, decoupled from Passepartout adoption |
|
||||
| 10⁴ → 10⁶ | Trust shifts from institutional to computational | Consumer adoption — cultural norm, not technical requirement |
|
||||
| 10⁶ → 10⁹ | Cost of non-verification exceeds cost of adoption | Insurance + regulation lock-in — economic necessity, not preference |
|
||||
|
||||
Each row's effect /is/ the growth driver for the next row's instance count. The flywheel is the product. Passepartout is the architecture. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]] is the steady state.
|
||||
|
||||
* References
|
||||
|
||||
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects over time]]
|
||||
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Growth phases — zero to billions]]
|
||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]]
|
||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue per phase]]
|
||||
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Attestation and insurance]]
|
||||
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]
|
||||
201
projects/passepartout/strategy/enterprise-growth-strategy.org
Normal file
201
projects/passepartout/strategy/enterprise-growth-strategy.org
Normal file
@@ -0,0 +1,201 @@
|
||||
:PROPERTIES:
|
||||
:ID: d28adac8-08a1-40c4-ae43-b5d8d7b1743f
|
||||
:ID: growth-strategy
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Growth — Two Engines, One Infrastructure
|
||||
#+filetags: :passepartout:growth:network:strategy:social-protocol:
|
||||
|
||||
Passepartout has two independent growth engines that share the same infrastructure. The verification subsystem grows top-down through enterprise compliance sales — capital-efficient, revenue from day one. [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][The social protocol]] (the social network) grows bottom-up through community adoption — network-effect-powered, zero customer acquisition cost per user. Each engine would be incomplete alone. Together they form the full stack: verification funds the build, the network provides the users, and at every crossover point they make each other more valuable.
|
||||
|
||||
This page defines the combined growth strategy across four phases, with each engine advancing in parallel and reinforcing the other at specific transitions.
|
||||
|
||||
* The Two Engines
|
||||
|
||||
/Verification subsystem (top-down, revenue-funded):/
|
||||
- Customer: CISO, compliance buyer
|
||||
- Growth lever: Enterprise sales + gate rule library compounding
|
||||
- Revenue: $2-12M/year by month 12
|
||||
- Failure mode: Wrong pricing, too early for market
|
||||
- Entry: Direct enterprise compliance engagements
|
||||
|
||||
/Social protocol (bottom-up, community-driven):/
|
||||
- Customer: Organized communities, creators, developers
|
||||
- Growth lever: Multi-vector network effects (identity, publishing, payments, contracts, governance)
|
||||
- Revenue: Transaction fees, PDS hosting, marketplace commissions
|
||||
- Failure mode: Never reaches critical mass on any vector
|
||||
- Entry: Organized community onboarding pilot groups, then expand
|
||||
|
||||
* Phase 0: Bootstrapping (0 → 100 instances, 0 → 10K social protocol users, 3-12 months)
|
||||
|
||||
** Verification Engine
|
||||
|
||||
*Customer:* Enterprise compliance teams. Clear buyer (CISO), existing budget, pain that maps directly to gate rules.
|
||||
|
||||
*Growth lever:* Enterprise sales + direct integration. No network effects yet — value must be real without anyone else using it.
|
||||
|
||||
*Tactics:*
|
||||
1. Ship [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] MVP — verifies code, applies gate rules, produces compliance report.
|
||||
2. First sale encodes a regulation as gate rules, verifies the customer's deployment.
|
||||
3. Each engagement funds the next. Gate rule library grows with every customer.
|
||||
4. The [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] bootstraps with one provider (you) selling verification to smaller instances.
|
||||
|
||||
*Revenue:* $2-12M from enterprise compliance engagements. Funds the team and the social protocol build.
|
||||
|
||||
** Social Protocol Engine
|
||||
|
||||
*Customer:* Organized communities — HOAs, clubs, cooperatives, PTAs, volunteer orgs, religious groups — any group that currently uses 3+ separate tools and has a leader who can onboard them.
|
||||
|
||||
*Growth lever:* Group density solves the cold start. The community exists before the platform. Onboard one HOA of 200 families, get 200 users at once.
|
||||
|
||||
*Tactics:*
|
||||
1. Identify 5-10 pilot communities via warm intros or personal networks.
|
||||
2. Each gets a white-glove onboarding: admin sets up their Collective Persona, invites members via share link.
|
||||
3. Members arrive to find a complete community space: announcement feed, group chat, task board, treasury, voting.
|
||||
4. The first real use case (budget vote, dues collection, contractor hire) is the killer demo.
|
||||
5. Ship identity + content + contracts + payments + governance. The bundle must work from day one for organized communities — they need all five layers.
|
||||
|
||||
*Revenue:* Minimal in Phase 0 ($20-100K in transaction fees). The goal is product-market fit with a specific community type, not revenue.
|
||||
|
||||
*Key metric for crossover:* Community retention at 90 days. If a community is still using the social protocol for its core operations after 90 days, the bundle has stickiness.
|
||||
|
||||
*Phase 0 crossover:* The first enterprise compliance customer needs employee identities. Their PDS deployment seeds social protocol identities for the compliance team. This is accidental — the enterprise's employees get DIDs as a side effect of their company buying verification. The protocol gets its first non-community users for free.
|
||||
|
||||
** Combined Summary
|
||||
|
||||
| Dimension | Verification | Social Protocol |
|
||||
|-----------+-------+-------|
|
||||
| Customer | CISO, compliance buyer | HOA president, club leader |
|
||||
| Entry | Cold sales | Warm intro to pilot communities |
|
||||
| Revenue | $2-12M | $20-100K |
|
||||
| Key metric | Instances deployed | Communities active at 90 days |
|
||||
| Failure mode | Wrong pricing, too early | No community finds PMF |
|
||||
| Build priority | Passepartout MVP | Note primitive, PDS, SCAL basics |
|
||||
|
||||
* Phase 1: Dual Growth (100 → 10K instances, 10K → 100K social protocol users, 12-24 months)
|
||||
|
||||
** Verification Engine
|
||||
|
||||
*Customer:* Two-sided — enterprise compliance (continuing Phase 0) plus individual developers adopting Passepartout through AGPL.
|
||||
|
||||
*Growth lever:* Open-source adoption + platform economics. The gate rule SDK lets developers create and sell their own gate rules.
|
||||
|
||||
*Tactics:*
|
||||
1. Gate rule SDK launch — developers encode compliance domains as products.
|
||||
2. Proof library compounding — every new instance contributes edge cases.
|
||||
3. Attestation marketplace — track record of correct verifications carries weight.
|
||||
4. Social protocol identities as employee benefit — every enterprise PDS includes DIDs for all employees.
|
||||
|
||||
*Revenue:* $10-50M. Verification appliances, marketplace fees, social protocol username registrations.
|
||||
|
||||
*Key metric:* Third-party gate rules published. Active developer count.
|
||||
|
||||
** Social Protocol Engine
|
||||
|
||||
*Customer:* Community refugees (banned subreddits, nuked Discord servers) + creators (OnlyFans/Patreon refugees who want to own their audience).
|
||||
|
||||
*Growth lever:* Crisis-driven migration + creator-led audience migration.
|
||||
|
||||
*Tactics:*
|
||||
1. Monitor deplatforming events. When a subreddit of 10K+ users gets banned, offer a ready-made social protocol community space within 24 hours.
|
||||
2. Ship creator tools: LSAT for paywalled content, Lightning subscriptions, Blind CDN for video distribution.
|
||||
3. The Phase 0 pilot communities now have members who need to hire each other. Freelance contracts emerge organically.
|
||||
4. Every enterprise PDS deployment from the verification subsystem includes employee DIDs. Those employees can join social protocol communities with zero friction.
|
||||
|
||||
*Revenue:* $1-5M. Transaction fees from contracts, LSAT subscriptions, PDS hosting.
|
||||
|
||||
*Key metric:* Communities onboarded. Paying subscribers. Contract volume.
|
||||
|
||||
** Phase 1 Crossover
|
||||
|
||||
This is the critical reinforcement point:
|
||||
|
||||
- Enterprise employees already have social protocol DIDs (from their company's PDS). They can join social protocol communities with one click — no registration, no password, no onboarding friction.
|
||||
- Social protocol communities naturally need verification. An HOA's contractor hire should be verified. A community's vote results should be provable. The verification engine built for enterprises is now useful for communities.
|
||||
- The compute marketplace now has two demand sources: enterprise verification (production workloads) and community verification (contract executions, attestation requests).
|
||||
|
||||
*Phase 1 crossover metric:* Percentage of social protocol transactions that use verification. Target: 10%+ by end of Phase 1.
|
||||
|
||||
* Phase 2: Convergence (10K → 1M instances, 100K → 10M social protocol users, 2-5 years)
|
||||
|
||||
** Verification Engine
|
||||
|
||||
*Customer:* Enterprise compliance (continuing) + verification marketplace (scaling) + insurance industry.
|
||||
|
||||
*Growth lever:* Environment subsystem premium enterprise features + insurance marketplace.
|
||||
|
||||
*Tactics:*
|
||||
1. [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Environment subsystem]] premium ships SSO, compliance dashboards, fleet management.
|
||||
2. Insurance marketplace forms — actuaries price proof insurance based on track records of 10K+ instances.
|
||||
3. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] begins — the gate library is the largest, most cited, most battle-tested.
|
||||
|
||||
*Revenue:* $50-200M. Environment subsystem enterprise seats, verification appliances, insurance premiums.
|
||||
|
||||
** Social Protocol Engine
|
||||
|
||||
*Customer:* Freelancers, gig workers, small businesses. The organized communities from Phase 0-1 now have enough history that their reputation graph carries real weight.
|
||||
|
||||
*Growth lever:* Professional network effects. A freelancer's contract history on the social protocol is portable proof of reliability.
|
||||
|
||||
*Tactics:*
|
||||
1. Freelancer marketplace emerges organically — communities that already use contracts start hiring across communities.
|
||||
2. The Algorithm Marketplace creates differentiation — users choose their feed curation logic.
|
||||
3. Social protocol identities hit 1M. The namespace has real scarcity. Premium username auctions produce significant revenue.
|
||||
4. Enterprise adoption of the social protocol happens because employees already have DIDs. Companies start using social protocol spaces for internal collaboration.
|
||||
|
||||
*Revenue:* $20-100M. Transaction fees, PDS hosting, marketplace commissions, username renewals.
|
||||
|
||||
** Phase 2 Crossover
|
||||
|
||||
The two engines begin to merge:
|
||||
|
||||
- Verification is no longer an enterprise-only product. It is a network service consumed by every social protocol transaction.
|
||||
- The social protocol's reputation graph becomes the best source of verification track records. Actuaries price insurance based on DID history. The insurance products that the verification subsystem enables are /powered by/ social protocol data.
|
||||
- Enterprise employees use the same DID for compliance work and community participation. The boundary between "work identity" and "personal identity" is a Persona toggle — same infrastructure, different roles.
|
||||
|
||||
*Phase 2 crossover metric:* Percentage of verification requests that originate from social protocol transactions. Target: 50%+ by end of Phase 2.
|
||||
|
||||
* Phase 3: Infrastructure (1M → 10M+ instances, 10M → 1B+ social protocol users, 5-15 years)
|
||||
|
||||
** Both Engines
|
||||
|
||||
At this scale, the distinction between verification and the social protocol becomes meaningless. Verification is the compute layer. The social protocol is the application layer. They are the same infrastructure:
|
||||
|
||||
- /Verification monopoly:/ The gate library is the most comprehensive proof library ever assembled. Regulators reference it. Insurers require it.
|
||||
- /Default identity:/ The social protocol DID is the default identity for internet users. New services offer social protocol login because users demand it.
|
||||
- /Insurance lock-in:/ Insurers price unverified code out of existence. The cost of /not/ verifying exceeds the cost of adopting Passepartout.
|
||||
- /Nation-state adoption:/ Countries run their own Passepartout instances for digital sovereignty. The compute marketplace is a sovereign asset.
|
||||
- /Installed base moat:/ A new entrant cannot replicate 10+ years of attestation history, 1B+ identities, and millions of verified contracts.
|
||||
|
||||
*Revenue:* $1B+. Certification monopoly revenue, infrastructure rent, marketplace fees, insurance underwriting, PDS hosting at global scale.
|
||||
|
||||
* The Combined Curve
|
||||
|
||||
| Phase | Verification scale | Social Protocol scale | Revenue | Crossover | Failure mode |
|
||||
|-------+-------------+-------------+---------+-----------+--------------|
|
||||
| 0 | 0→100 instances | 0→10K users | $2-12M | Enterprise PDS seeds first DIDs | Either engine stalls |
|
||||
| 1 | 100→10K inst | 10K→100K users | $11-55M | Employees join communities; communities need verification | Verification: developer UX. Social protocol: no vector reaches PMF |
|
||||
| 2 | 10K→1M inst | 100K→10M users | $70-300M | Most verification serves social protocol; most social protocol data feeds verification | Verification: scaling compute. Social protocol: UX polish gap |
|
||||
| 3 | 1M→10M+ inst | 10M→1B+ users | $1B+ | The layers are unified | Technology paradigm shift |
|
||||
|
||||
* Why This Works Together
|
||||
|
||||
Organized communities are the entry point that forces the social protocol to ship the full bundle from day one. An HOA using the social protocol for announcements, dues, contracts, and voting demonstrates the complete vision No marketing message can compete with a community member seeing their dues collected and a roof contract executed through one platform.
|
||||
|
||||
Enterprise compliance funds the build. A Phase 0 CISO engagement brings in $500K-2M, enough to pay a small team for a year. The same team ships the social protocol Note primitive, PDS, and SCAL. The enterprise revenue buys time for the community adoption to find PMF.
|
||||
|
||||
The crossover is automatic. Enterprise employees get DIDs from their company's PDS. They join social protocol communities because the DID works everywhere. Communities need verification for their contracts and votes. The verification engine is already running. The two engines were never separate — they were always the same infrastructure, just adopted by different users at different times.
|
||||
|
||||
* References
|
||||
|
||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]]
|
||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams]]
|
||||
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]]
|
||||
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first alternative (now integrated)]]
|
||||
- [[id:8c7b9812-f8d6-4347-8915-ce8e520b7914][Entry strategy — organized communities]]
|
||||
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Social protocol competitive landscape]]
|
||||
- [[id:b9fa4b7b-bc61-4d7f-918d-ff687b80f2ba][Systemic effects]]
|
||||
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
||||
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]
|
||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Social protocol contracts]]
|
||||
- The [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social protocol Social Space requirements]] define how organized communities interact through the gate stack. See also Social Protocol Specification — full requirements (spec repo at /tmp/agora)
|
||||
18
projects/passepartout/strategy/evaluation-harness.org
Normal file
18
projects/passepartout/strategy/evaluation-harness.org
Normal file
@@ -0,0 +1,18 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 45258a2d-1675-562c-9024-5d1eb2f1ea56
|
||||
:END:
|
||||
#+title: Evaluation Harness as Certification Service
|
||||
#+filetags: :passepartout:revenue:certification:evaluation:regression:
|
||||
|
||||
The accumulated regression suite — thousands of edge cases from every deployed instance, every bug fix, every regulatory change — becomes the most comprehensive test of autonomous agent correctness.
|
||||
|
||||
**Service:** "Run our 10,000-task suite against your AI agent and get a Merkle-verified score."
|
||||
**Target:** AI labs proving their agents' capabilities, enterprise procurement requiring independent verification.
|
||||
**Price:** $50K-$200K per certification.
|
||||
|
||||
The regression suite grows with every deployment, making the certification increasingly valuable over time. The early player's suite is the largest because they started first. This is the [[id:a5d59d12-b23e-58d6-a81b-9b8b06556949][collective regression suite]] mechanism in action.
|
||||
|
||||
10 certifications in year one = $500K-$2M.
|
||||
|
||||
Long-term endpoint: this becomes the UL certification for AI — a third-party verification nobody can ignore. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The verification monopoly]]. The certification relies on a [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] to run the tests in a trusted environment, creating [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] as certification history accumulates on the platform. These dynamics form powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]].
|
||||
17
projects/passepartout/strategy/infrastructure-lock-in.org
Normal file
17
projects/passepartout/strategy/infrastructure-lock-in.org
Normal file
@@ -0,0 +1,17 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 2f783eb4-638e-5afa-9b59-6224d086a712
|
||||
:END:
|
||||
#+title: Infrastructure Lock-In and Switching Costs
|
||||
#+filetags: :passepartout:economics:moats:lock-in:switching:
|
||||
|
||||
A hospital that runs [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] with [[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]] gate rules ($50K/yr) for five years has accumulated:
|
||||
|
||||
- A fact store with a decade of compliance decisions
|
||||
- A proof forest of verified rules
|
||||
- An empirical decision history tied to their specific deployment
|
||||
- Customized gate rules encoding their specific workflows and approvals
|
||||
|
||||
Switching to a competitor means discarding all of it. The accumulated value grows as the fact store deepens. Annual revenue per enterprise grows from $250K in year one to $500K-$1M by year five as more [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain packages]] are added.
|
||||
|
||||
This is the strongest residual [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moat]]. The [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] (see the [[id:3b43a9b8-31d1-4479-a35f-22273b74f0c7][Social protocol infrastructure requirements]] for the network topology that creates this lock-in)]] (regression suite) is a close second — it grows with every deployment and cannot be ingested from public data. The [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] and [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][upgrade lifecycle]] compound this lock-in: every new regulation encoded as a gate rule deepens the proof forest, making the deployment harder to reproduce elsewhere.
|
||||
20
projects/passepartout/strategy/investment-thesis.org
Normal file
20
projects/passepartout/strategy/investment-thesis.org
Normal file
@@ -0,0 +1,20 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 5961e469-53a3-5f3c-ab72-3c83ef91963f
|
||||
:END:
|
||||
#+title: Investment Thesis
|
||||
#+filetags: :passepartout:economics:investment:thesis:
|
||||
|
||||
The early player benefits from every other instance of Passepartout. Every deployed instance feeds edge cases into the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][regression suite]], grows the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], and validates the hardware designs. Network effects are positive sum.
|
||||
|
||||
Three revenue horizons:
|
||||
|
||||
- **Low-hanging fruit (year one, $2M-$12M):** [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliances]], [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate rule subscriptions]], [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness certification]], migration services
|
||||
- **Medium-term (1-3 years, $10M-$50M):** [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], Relay Network, Lisp Machine hardware; [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][premium usernames]] ($10M/yr), [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS hosting]] ($18M/yr)
|
||||
- **Big money (3-10 years, $100M-$1B+):** [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] (UL certification for AI), [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]], planetary compute marketplace
|
||||
|
||||
The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI and GPU industry]] — token demand compression, GPU inference plateau, and the rise of CPU-native verification hardware — reshapes the trillion-dollar market these revenue streams depend on.
|
||||
|
||||
The [[id:68ffa49f-f0d8-42cf-8b69-ae69de8bb815][Social protocol governance and physical assets]] requirements cover how the network manages shared infrastructure. The switching costs compound. The [[id:aa6d062e-a520-5d14-8773-00687ed9c689][network effects]] are positive sum. The market is nearly a trillion dollars.
|
||||
|
||||
The defensible entity is "the organization that best understands how to adapt [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] to your domain" — not "the organization that owns Passepartout."
|
||||
17
projects/passepartout/strategy/lisp-economics.org
Normal file
17
projects/passepartout/strategy/lisp-economics.org
Normal file
@@ -0,0 +1,17 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 9af13fff-9725-542b-93b1-a555bc74ad72
|
||||
:END:
|
||||
#+title: Why Lisp Is Economically Viable Now
|
||||
#+filetags: :passepartout:economics:lisp:history:C:viability:
|
||||
|
||||
The 1980s trade-off was: C is cheap enough for the market. Correctness is a luxury the market cannot afford. The 2020s trade-off is: C is expensive for the market. Incorrectness has become the dominant cost of software. Lisp's verification infrastructure is now the cheaper option.
|
||||
|
||||
Four transformations flipped the economics:
|
||||
|
||||
1. **Memory is free.** 40MB runtime is noise on a $20 Raspberry Pi with 8GB RAM. In 1980, DRAM was ~$5,000/MB.
|
||||
2. **Transistors are free.** Modern ARM Cortex-A72 has billions of transistors. GC and type dispatch cost nothing because the transistors are there whether used or not.
|
||||
3. **Complexity saturates human verification.** Systems are tens of millions of lines. Testing is necessary but insufficient — zero-day vulnerabilities prove bugs survive all testing. Formal verification is the only known path.
|
||||
4. **Cost of failure exceeds cost of verification.** A single breach costs millions. Regulation mandates provable compliance. Proving correctness is cheaper than not proving it.
|
||||
|
||||
The [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verification appliance]] (AGPL symbolic engine + RISC-V Lisp μcode on FPGA) costs $5,000/year and replaces $500,000/year in compliance audits, breach litigation, and regulatory fines. This [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][cost structure]] — zero marginal cost per additional user — is what makes Lisp economically viable at scale. The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] is the hardware endpoint of this economic logic. For the biological analogy that explains why Lisp architecture is a natural outcome of complexity pressure, see [[id:2afd9a3c-e96a-54c7-ac77-a05a28065b4b][biology parallels]]. For the historical precedent, see the [[id:00ab3a4d-e3de-5605-a67d-12935bb36ab5][comparison with Symbolics Genera]]. The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI industry]] is the market-side consequence.
|
||||
18
projects/passepartout/strategy/moats.org
Normal file
18
projects/passepartout/strategy/moats.org
Normal file
@@ -0,0 +1,18 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: aa6d062e-a520-5d14-8773-00687ed9c689
|
||||
:END:
|
||||
#+title: Competitive Moats
|
||||
#+filetags: :passepartout:economics:moats:competition:
|
||||
|
||||
Re-evaluated: time is not the primary moat. A Phase 4+ [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] fed on Wikipedia + Wikidata can build a general ontology in two weeks. The organic growth advantage collapses for general knowledge.
|
||||
|
||||
**Actual moats (weaker than initially assumed):**
|
||||
1. **Domain-specific gate rules** — thin. A few hundred lines of Lisp data. Write once, trivial to copy. Not a real moat.
|
||||
2. **Empirical decision history** — every HITL decision is a Merkle fact. A fresh instance has none. Makes *your* instance more valuable but doesn't prevent competition — it's a switching cost, not a barrier to entry.
|
||||
3. **[[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness (regression suite)]]** — thousands of test cases accumulated from every bug fix. Cannot be ingested from public data. Strongest residual moat.
|
||||
4. **[[id:2f783eb4-638e-5afa-9b59-6224d086a712][Infrastructure integration]]** — specific Docker compose layouts, Traefik patterns, Authentik configs encoded as gate rules. A competitor's infrastructure is different.
|
||||
|
||||
**Strongest competitor strategy:** Not copying your gate rules — offering the same architecture as a service with their own pre-seeded general knowledge and a consulting engagement to customize gate rules. The AGPL prevents closing the architecture but does not prevent offering it as a service with a customization layer.
|
||||
|
||||
**The defensible business is services, not product.** The defensible entity is "the organization that best understands how to adapt Passepartout to your domain" — not "the organization that owns Passepartout." A [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]] on agent safety would change this calculus — competitors would need independent certification. [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][Patent strategy]] and [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][Licensing]] protect key innovations and create revenue from the open-source ecosystem.
|
||||
133
projects/passepartout/strategy/outbound-sales-compliance.org
Normal file
133
projects/passepartout/strategy/outbound-sales-compliance.org
Normal file
@@ -0,0 +1,133 @@
|
||||
:PROPERTIES:
|
||||
:ID: 98364e9d-a8a9-42b7-a9dc-b643fd2ccc4b
|
||||
:ID: outbound-sales-compliance
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Outbound Sales — Legal Framework & Compliance Architecture
|
||||
#+filetags: :passepartout:compliance:legal:gdpr:outbound:
|
||||
|
||||
The outbound sales pipeline touches leads across multiple jurisdictions. This page maps the applicable laws, the compliance requirements at each stage of the pipeline, and how [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]'s gate stack can enforce them mechanically.
|
||||
|
||||
This plan defers to Passepartout maturity — it scopes what needs to be built and what can be done now without automation.
|
||||
|
||||
* Applicable Laws by Jurisdiction
|
||||
|
||||
** US — CAN-SPAM Act (2003)
|
||||
|
||||
/Applies to:/ Any commercial email sent to or from US addresses.
|
||||
|
||||
Requirements:
|
||||
1. No false or misleading header information (From, To, routing)
|
||||
2. No deceptive subject lines
|
||||
3. Identify the message as an advertisement (unless prior consent)
|
||||
4. Valid physical postal address of the sender
|
||||
5. Working opt-out mechanism — must honor within 10 business days
|
||||
6. No email address harvesting via automated means (criminal offense if combined with sending)
|
||||
|
||||
Penalties: $46,517 per violation. Criminal penalties for harvesting + sending.
|
||||
|
||||
/Passepartout gate stack:/
|
||||
- Gate: /subject-line-truth/ — LLM generates subject, gate verifies it matches content
|
||||
- Gate: /sender-identity/ — From header must match the sending domain's SPF/DKIM
|
||||
- Gate: /physical-address/ — every outbound message must include the registered address
|
||||
- Gate: /unsubscribe-link/ — every message must carry a working opt-out
|
||||
- Gate: /no-harvesting/ — if contact was sourced via automated scraping, flag for review
|
||||
|
||||
** EU/EEA — [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] (2018)
|
||||
|
||||
/Applies to:/ Processing personal data of data subjects in the EU, regardless of where the controller is established. [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]] has extraterritorial reach (Article 3).
|
||||
|
||||
Relevant requirements:
|
||||
1. /Lawful basis required for processing./ Cold email to a corporate address may use "legitimate interest" (Article 6(1)(f)) or "consent" (Article 6(1)(a)). For B2B cold email to professional addresses, legitimate interest is the standard basis — but must balance against the recipient's rights.
|
||||
2. /Right to object to direct marketing (Article 21)./ Absolute right. No balancing test. If a recipient objects, processing for marketing must stop immediately.
|
||||
3. /Data minimization./ Only collect and process the minimum data needed. If you have an email address and company name, do not also scrape their browsing history.
|
||||
4. /Right to erasure (Article 17)./ If a lead requests deletion, must comply.
|
||||
5. /Notice requirement (Articles 13-14)./ Must inform the data subject about who you are, what data you process, the lawful basis, and their rights. This must be in the first communication.
|
||||
6. /Cross-border transfer (Articles 44-49)./ If you process EU data from Egypt, you need an appropriate safeguard (Standard Contractual Clauses) or an adequacy decision. Egypt does not have an EU adequacy decision.
|
||||
|
||||
Penalties: Up to 20 million EUR or 4% of global annual turnover, whichever is higher.
|
||||
|
||||
/Passepartout gate stack:/
|
||||
- Gate: /lawful-basis/ — annotate every lead with the basis (legitimate interest / consent)
|
||||
- Gate: /right-to-object/ — every message must include "You can object to further processing at any time" language
|
||||
- Gate: /privacy-notice/ — every message must link to a privacy policy meeting Articles 13-14
|
||||
- Gate: /cross-border/ — if sending from Egypt to EU, require SCC documentation
|
||||
- Gate: /erasure-compliance/ — maintain an erasure queue with 30-day SLA
|
||||
- Gate: /data-minimization/ — reject leads with unnecessary enrichment data
|
||||
|
||||
** UK — [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] + PECR
|
||||
|
||||
/Applies to:/ Data subjects in the UK.
|
||||
|
||||
Privacy and Electronic Communications Regulations (PECR) adds specific rules for electronic marketing:
|
||||
- B2B emails to corporate subscribers: can rely on legitimate interest. Must identify sender, provide valid contact, and offer opt-out.
|
||||
- B2C emails: require prior consent unless the "soft opt-in" applies (existing customer, same product).
|
||||
- The ICO takes a stricter view of legitimate interest for cold email than some EU regulators.
|
||||
|
||||
Penalties: Up to 17.5 million GBP or 4% of turnover.
|
||||
|
||||
** Egypt — PDPL (Law No. 151 of 2020)
|
||||
|
||||
/Applies to:/ Processing of personal data within Egypt, or processing by entities established in Egypt. The law entered into force in 2020 but implementing regulations were still being finalized.
|
||||
|
||||
Key provisions (broadly modeled on GDPR):
|
||||
1. /Consent required/ unless another lawful basis applies. The law recognizes legitimate interest but Egyptian regulators have not provided detailed guidance on its scope for direct marketing.
|
||||
2. /Data subject rights:/ Access, correction, deletion, objection to processing.
|
||||
3. /Cross-border transfer:/ Restricted. Personal data may only be transferred to countries with adequate protection (not yet defined) or with specific safeguards.
|
||||
4. /Registration requirement:/ Data controllers must register with the Data Protection Center (DPC).
|
||||
5. /Penalties:/ Criminal penalties (imprisonment) for certain violations, plus fines.
|
||||
|
||||
Practical note: The PDPL's implementing regulations are still maturing. Enforcement has been uneven. For Egyptian-organized communities (HOAs, clubs), the primary risk is not enforcement but upsetting the lead. The legal risk is lower than GDPR for domestic leads.
|
||||
|
||||
** Canada — CASL (2014)
|
||||
|
||||
/Applies to:/ Commercial electronic messages (CEMs) sent to or from Canada.
|
||||
|
||||
Requirements:
|
||||
1. /Consent./ Express consent required unless an exception applies (existing business relationship, published business contact info with no "do not subscribe" flag).
|
||||
2. /Identification./ Sender identity, contact info, and unsubscribe mechanism must be in every message.
|
||||
3. /Unsubscribe./ Must be processed within 10 business days, valid for 60 months.
|
||||
4. /Strict liability./ No proof of harm required for enforcement.
|
||||
|
||||
Penalties: Up to 10 million CAD per violation for organizations — the strictest spam law globally.
|
||||
|
||||
* Pipeline Compliance Map
|
||||
|
||||
| Stage | Data collected | Lawful basis | Risk | Gate required |
|
||||
|-------+----------------+--------------+------+--------------|
|
||||
| Lead sourcing (scraping) | Name, email, organization | Legitimate interest (public directories) | High: harvesting laws, ToS violations | /no-harvesting/ — flag automated collection. /tos-review/ — check target website's ToS |
|
||||
| Lead enrichment | Title, social links, context | Legitimate interest | Medium: data minimization | /data-minimization/ — reject enrichment that isn't needed for personalization |
|
||||
| Draft | Personalized message | Legitimate interest | Low | /subject-line-truth/ — subject matches content. /sender-identity/ — correct headers |
|
||||
| Gate check | Message passes compliance gates | N/A | Low (automated) | ALL gates must pass before send |
|
||||
| Send | Email sent via SMTP | Legitimate interest | Medium: jurisdiction-dependent | /jurisdiction-check/ — apply per-recipient rules |
|
||||
| Reply detection | Reply content | Legitimate interest | Low | /objection-detection/ — flag opt-out requests |
|
||||
| Follow-up | Second email | Legitimate interest (if no objection) | Medium: must respect opt-out | /opt-out-check/ — verify recipient hasn't unsubscribed |
|
||||
| Conversion | Contract details | Contract performance | Low | /right-to-erasure/ — delete data if requested |
|
||||
|
||||
* Practical Implementation for Phase 0
|
||||
|
||||
All of the above requires significant infrastructure: email delivery, bounce handling, opt-out databases, privacy policies, cross-border transfer documentation. For Phase 0 (when this plan is active, post-Passepartout maturity):
|
||||
|
||||
1. /Start with Egyptian organized communities only./ Single jurisdiction simplifies compliance. PDPL is less defined than GDPR — lower risk surface.
|
||||
2. /Do not scrape./ Source leads manually or from public directories with clear consent models. A directory of HOAs that lists board president emails openly is fair use. A directory that requires login and forbids scraping is not.
|
||||
3. /Every outbound message needs:/ sender identity, physical address, unsubscribe link, privacy policy link, and a clear "you can object" statement.
|
||||
4. /Log every opt-out./ Reputation slashing applies to the sender too — if leads flag you as spam, your deliverability drops across all future sends.
|
||||
5. /Passepartout gate stack is ideal for this./ Every gate is a pure Lisp function — /subject-line-truth/ checks the LLM's output, /sender-identity/ validates headers, /unsubscribe-link/ confirms the link is present and working. The gate stack makes the compliance argument rather than relying on human review.
|
||||
|
||||
* What Can Be Done Now (Without Passepartout Automation)
|
||||
|
||||
1. Document the compliance framework (this file)
|
||||
2. Set up the Airtable CRM schema with lead stages
|
||||
3. Research email delivery options (SendGrid vs Resend vs self-hosted)
|
||||
4. Draft the privacy policy that will be linked from every outbound message
|
||||
5. Identify Egyptian HOA/community directories for manual sourcing
|
||||
|
||||
The automation waits on Passepartout — but the legal foundation and the infrastructure can be scoped now.
|
||||
|
||||
* References
|
||||
|
||||
- CAN-SPAM Act (15 U.S.C. 7701-7713)
|
||||
- GDPR (Regulation (EU) 2016/679)
|
||||
- [[id:9bc29937-d59a-4ae4-9623-3d17a1fe6ebb][UK GDPR]] + PECR (SI 2003/2426)
|
||||
- Egypt PDPL (Law No. 151 of 2020)
|
||||
- CASL (S.C. 2010, c. 23)
|
||||
23
projects/passepartout/strategy/patent-strategy.org
Normal file
23
projects/passepartout/strategy/patent-strategy.org
Normal file
@@ -0,0 +1,23 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: caaeee11-ba6f-5566-aecd-f171b4c459c0
|
||||
:END:
|
||||
#+title: Patent Strategy
|
||||
#+filetags: :passepartout:ip:patents:legal:
|
||||
|
||||
**Likely patentable:**
|
||||
- Probabilistic-deterministic split with deterministic gates between LLM proposal and execution (vs every competitor using prompt-based guardrails)
|
||||
- Foveal-peripheral context model with Org-tree structured retrieval (targets 2,000-4,000 tokens)
|
||||
- Merkle-tree memory with copy-on-write snapshots and operation-level undo/redo
|
||||
- Gate-to-fact bootstrap with sufficiency criterion (mechanically extracting facts from gate stack data structures)
|
||||
- Macro-layer-as-skill bootstrapping architecture (theorem-proving as hot-reloadable skills)
|
||||
|
||||
**Likely not patentable (known techniques):**
|
||||
- ACL2 itself (decades old)
|
||||
- Screamer for consistency checking (obvious application)
|
||||
- Hot-reloadable skills (40 years old)
|
||||
- Org-mode as a data format
|
||||
|
||||
**Strongest single claim:** The specific combination of probabilistic model + deterministic zero-token safety gates + Merkle memory + symbolic engine with sufficiency criterion. Each element is known; the combination is novel and non-obvious.
|
||||
|
||||
**Counterargument:** A patent examiner will argue these are standard OS microkernel architecture, locality of reference, content-addressed storage, and capability-based security applied to an AI agent. The defense: they have never been *combined* in an AI agent, producing emergent effects no single principle produces. These patents would feed into a [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] strategy and create [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] against competitors.
|
||||
19
projects/passepartout/strategy/pds-as-a-service.org
Normal file
19
projects/passepartout/strategy/pds-as-a-service.org
Normal file
@@ -0,0 +1,19 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 1a2b38df-20ba-58ca-ba55-a072be67bd0d
|
||||
:END:
|
||||
#+title: Personal Data Store as a Service
|
||||
#+filetags: :passepartout:social-protocol:revenue:pds:saas:
|
||||
|
||||
Classic open-core SaaS model (GitLab, Sentry, PlanetScale). The Merkle fact store exposed on [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][the social protocol]] can be self-hosted (free, AGPL) or hosted by the early player.
|
||||
|
||||
- **Free tier (self-hosted):** full AGPL PDS, runs on any Lisp host, full control, no cost
|
||||
- **Basic hosted tier:** $10-$20/month, 10GB fact store, 10M queries/month, automated backup, automatic upgrades
|
||||
- **Business hosted tier:** $100-$500/month, 100GB+ fact store, unlimited queries, SLA, dedicated relay, compliance logging
|
||||
- **Enterprise hosted tier:** $1,000-$10,000/month, air-gapped appliance management, dedicated support, regulatory-compliant data residency, SIEM integration
|
||||
|
||||
The free self-hosted version drives adoption and trust (you can inspect every line). The hosted version captures value from users who value convenience over control. Bluesky already demonstrated demand at ~$10/month for a simpler PDS.
|
||||
|
||||
Target: 100K subscribers at $15/month average = $18M/yr recurring, near-zero marginal cost per additional subscriber (the symbolic engine is CPU-bound, not per-user metered).
|
||||
|
||||
Combined with [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][premium usernames]]: $28M/yr from social protocol services alone before [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] revenue. The hosted model also creates [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] as users build their Merkle fact stores on the platform, making migration costly. The AGPL [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] model is described in [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][Licensing]].
|
||||
166
projects/passepartout/strategy/revenue-hub.org
Normal file
166
projects/passepartout/strategy/revenue-hub.org
Normal file
@@ -0,0 +1,166 @@
|
||||
:PROPERTIES:
|
||||
:ID: ed05cab4-88e9-4e25-b7c9-346fa39c69a0
|
||||
:ID: revenue-hub
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Revenue Streams — Overview
|
||||
#+filetags: :passepartout:revenue:index:business-model:
|
||||
|
||||
This page is the entry point for revenue generation thinking across all three Passepartout subsystems. Revenue splits cleanly across the two development phases defined in [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][time estimates]]. Each component enables different revenue primitives.
|
||||
|
||||
* Revenue by Subsystem
|
||||
|
||||
** Verification subsystem — Revenue streams
|
||||
|
||||
Existing coverage — [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]], [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Domain gate packages]], [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness]], [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]], [[id:d84679f1-c0c5-5be4-b19c-6573560640ee][Verified skill marketplace]]:
|
||||
|
||||
| Stream | Phase | Description |
|
||||
|--------+-------+-------------|
|
||||
| Verification appliance | Zero | FPGA/Tenstorrent pre-loaded with [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] + gate rules |
|
||||
| Domain gate packages | Zero | SaaS subscriptions per compliance domain |
|
||||
| Evaluation harness | Zero | Certification-as-a-service, regression suite access |
|
||||
| Compute marketplace | Both | Verified symbolic engine cycles via [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol]] |
|
||||
| Verified skill marketplace | End State | Commission on third-party gate rules |
|
||||
|
||||
*** Unexplored verification subsystem streams
|
||||
|
||||
| Stream | Phase | Rationale |
|
||||
|--------+-------+-----------|
|
||||
| Verified API gateway | Zero | Drop-in proxy for LLM calls. Passepartout verifies inputs, outputs, and provenance. Enterprise customers get a verifiable audit trail for every API call. Near-term product: run your OpenAI/Anthropic calls through Passepartout and get proof. |
|
||||
| Agent-as-a-service | Zero | Cloud-hosted Passepartout instances. Pay-per-verification or monthly subscription. The compute marketplace for individuals who don't self-host. |
|
||||
| Continuous compliance monitoring | Zero | Watch a deployment, continuously verify it against regulatory gate rules, alert on drift. Annual contract per monitored system. The evaluation harness as a product. |
|
||||
| Gate rule SDK [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] | Both | Commercial license for the gate rule development toolkit. Free for open-source rules, paid for proprietary enterprise rule development. |
|
||||
| Migration pipeline | Zero | Convert existing codebases to verified Lisp. Automated SaaS (point at a repo, get back a verified version). Per-enterprise: $50K-$500K for full migration. |
|
||||
| Forensics / incident response | Zero | Merkle memory provides tamper-proof audit. Post-incident: produce an irrefutable chain of what happened, who authorized it, what gates were triggered. Service offering. |
|
||||
| Proof repository marketplace | End State | Pre-verified proof libraries per domain (crypto, medical device, finance). Access to accumulated proof strategies from thousands of runs. |
|
||||
| Training & certification | Zero | Certified Gate Rule Developer program. Developer camps, certification exams, continuing education. The Red Hat / AWS training model. |
|
||||
| Enterprise support SLA | Zero | Guaranteed verification pipeline uptime, priority bug fixes, custom gate rule development. Red Hat subscription model. |
|
||||
|
||||
/Verified API gateway/ is notable because it requires zero buy-in to the full Passepartout vision. Any company using LLM APIs today can deploy Passepartout as a verification proxy and immediately get value (audit trail, gate compliance, prompt injection detection). It's a standalone product that seeds the ecosystem.
|
||||
|
||||
** Environment subsystem — Revenue streams
|
||||
|
||||
This is the /least developed/ revenue arm. Existing docs essentially say people buy hardware and the lock-in compounds. There is a gap:
|
||||
|
||||
Existing coverage: essentially none beyond hardware sales.
|
||||
|
||||
| Stream | Phase | Rationale |
|
||||
|--------+-------+-----------|
|
||||
| Lisp Machine hardware | End State | Tenstorrent/FPGA appliances. Hardware margins + recurring gate rules. |
|
||||
| [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Environment subsystem]] premium | Both | Enterprise features: SSO, audit logging, compliance reports, team management, centralized policy enforcement. Annual seat license. |
|
||||
| Plugin and theme marketplace | End State | Verified plugins for the environment subsystem (editors, browsers, shells, tools). Commission on each sale. Developer ecosystem. App Store for the Lisp Machine. |
|
||||
| Commercial Lisp image distribution | Both | Verified, signed, compatibility-guaranteed environment subsystem images. Free self-build (AGPL), paid for certified builds with SLAs. |
|
||||
| Enterprise environment subsystem deployment | Zero | Tools for deploying the environment subsystem across an organization: fleet management, unified gate policy, compliance dashboard. Annual license. |
|
||||
| Backup and archive service | Both | Verified snapshots of environment subsystem Lisp images. Tamper-proof archival of development environments. |
|
||||
| Environment subsystem extension SDK | Both | Commercial license for developing proprietary environment subsystem extensions. Tools, documentation, support. |
|
||||
|
||||
Key insight: The environment subsystem does not need the full Lisp Machine to generate revenue. Environment subsystem premium (SSO, audit, compliance reports) and enterprise deployment tools ship on Linux, use the existing environment subsystem terminal UI, and sell to the same enterprise buyer who buys gate packages. Compliance teams want verified environments — the environment subsystem premium delivers that without waiting for custom hardware.
|
||||
|
||||
** Social Protocol (the society) — Revenue streams
|
||||
|
||||
Existing coverage — [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Social protocol usernames]], [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]], [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]:
|
||||
|
||||
| Stream | Phase | Description |
|
||||
|--------+-------+-------------|
|
||||
| Premium username registry | Zero | $5-50/yr per handle, auction for high-value names |
|
||||
| PDS as a service | Both | $10-1000/mo per hosted personal data store |
|
||||
| Compute marketplace | Both | Commission on verified compute transactions |
|
||||
|
||||
The most fertile ground is contracts. DIDs provide identity, DIDComm provides communication, PDS provides state, gate rules encode terms, ACL2 verifies execution, and the symbolic engine runs deterministically. This is a full smart contract platform, strictly stronger than existing ones because ACL2 verifies the /rules themselves/, not just execution trace validity.
|
||||
|
||||
*** Unexplored social protocol streams — contracts
|
||||
|
||||
| Stream | Phase | Rationale |
|
||||
|--------+-------+-----------|
|
||||
| Verified smart contract platform | End State | Deploy contracts on the social protocol with ACL2-verified correctness. Every contract call produces a machine-checkable proof. Revenue: transaction fees per execution + deployment fee per verified contract. |
|
||||
| Contract template marketplace | Zero | Pre-verified contract templates for common use cases (escrow, DAO constitution, SLA, data licensing). Sell templates or take commission on template-based contracts. |
|
||||
| Dispute resolution service | End State | When two social protocol instances disagree on contract execution, submit to a verified arbitrator. Fee per resolution. |
|
||||
| Attestation marketplace | Zero | DIDs + verified actions = verifiable reputation. Attest that a DID meets certain criteria. Revenue: attestation fees, verification fees. |
|
||||
| Multi-instance governance | Zero | Cross-instance policy enforcement, unified compliance reporting, federated identity. Enterprise tier, annual license. |
|
||||
| Liquid democracy infrastructure | End State | DAO governance as a service. Verified proxy voting, governance contracts. Per-vote transaction fee. |
|
||||
| Insurance marketplace | End State | Reputable providers sell proof insurance. Premiums, reinsurance pool fees, actuarial gate rules. |
|
||||
| Namespace sub-leasing | Both | Premium handles sub-leased between DIDs. Commission on each lease. |
|
||||
| Data sharing contracts | Both | PDS-to-PDS data sharing agreements encoded as gate rules. Commission on each data transaction. |
|
||||
|
||||
The contract platform is the kill application for the social protocol. Ethereum proved demand for verifiable contracts at $20B+/yr in transaction fees. The social protocol's version is strictly better: ACL2 proves contract /correctness/ (not just valid execution), gate rules encode real-world regulations directly, and the PDS provides persistent state without a global trie bottleneck.
|
||||
|
||||
See [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Social protocol contracts]] for the full analysis.
|
||||
|
||||
* Revenue by Development Phase
|
||||
|
||||
** Phase Zero streams (ships with MVP, 1-3 months, Linux-hosted)
|
||||
|
||||
| Stream | Component | TAM | Buyer | Revenue type |
|
||||
|--------+----------+-----+-------+--------------|
|
||||
| Domain gate packages | Verification | Large | CISO/Compliance | SaaS |
|
||||
| Verification appliance | Verification | Medium | Enterprise infra | Hardware + subs |
|
||||
| Evaluation harness | Verification | Medium | Compliance | Certification |
|
||||
| Social protocol premium usernames | Social Protocol | Small | Individual | Subscription |
|
||||
| PDS hosting (basic) | Social Protocol | Medium | Individual | Hosting |
|
||||
| Verified API gateway | Verification | Large | Eng teams | Per-call |
|
||||
| Continuous compliance monitoring | Verification | Large | Compliance | Annual contract |
|
||||
| Migration pipeline | Verification | Medium | Enterprise | Per-engagement |
|
||||
| Enterprise support SLA | Verification/Environment | Medium | Enterprise | Annual |
|
||||
| Gate rule SDK (commercial) | Verification | Small | Developers | License |
|
||||
| Environment subsystem premium (enterprise) | Environment subsystem | Medium | Enterprise | Annual seat |
|
||||
| Enterprise environment subsystem deployment | Environment subsystem | Medium | Enterprise Ops | Annual |
|
||||
| Training and certification | All | Small | Developers | Per-seat |
|
||||
| Forensics / incident response | Verification | Small | Enterprise | Per-incident |
|
||||
| Contract templates | Social Protocol | Medium | Developers | Per-template |
|
||||
| Attestation marketplace | Social Protocol | Medium | Enterprise | Per-attestation |
|
||||
| Data sharing contracts | Social Protocol | Medium | Enterprise | Per-transaction |
|
||||
| Multi-instance governance | Social Protocol | Large | Enterprise | Annual |
|
||||
| Namespace sub-leasing | Social Protocol | Small | Individuals | Per-transaction |
|
||||
|
||||
Phase Zero target: $2M-$12M/year (from [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][investment thesis]]), with upside from verified API gateway and compliance monitoring pushing toward $15-20M.
|
||||
|
||||
** End State streams (full Lisp Machine, 2-5 years)
|
||||
|
||||
| Stream | Component | TAM | Revenue type |
|
||||
|--------+----------+-----+--------------|
|
||||
| [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]] | Verification/All | $1B+ | Certification |
|
||||
| Infrastructure lock-in | All | $100B+ | Rent extraction |
|
||||
| Compute marketplace | Social Protocol | Venture-scale | Transaction fees |
|
||||
| Smart contract platform | Social Protocol | Very large ($20B+) | Transaction fees |
|
||||
| Liquid democracy infra | Social Protocol | Large | Per-vote |
|
||||
| Insurance marketplace | Social Protocol | Very large | Premiums + fees |
|
||||
| Dispute resolution | Social Protocol | Medium | Per-resolution |
|
||||
| Plugin/theme marketplace | Environment subsystem | Large | Commission |
|
||||
| Commercial image distribution | Environment subsystem | Medium | Subscription |
|
||||
| Proof repository marketplace | Verification | Medium | Subscription |
|
||||
| Verified skill marketplace | Verification | Medium | Commission |
|
||||
|
||||
* Orders-of-Magnitude Risk Map
|
||||
|
||||
Using the [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders-of-magnitude framework]], each revenue stream lives at a different scale:
|
||||
|
||||
| Scale | Representative streams | Failure mode |
|
||||
|-------+-----------------------+--------------|
|
||||
| Weeks | Gate packages, appliance pre-orders, training | Wrong pricing, too early |
|
||||
| Months | Compliance monitoring, API gateway, PDS, environment subsystem premium | Churn, incumbents respond |
|
||||
| Years | Compute marketplace, contract platform, monopoly | Competition catches up |
|
||||
| Generations | Infrastructure lock-in, insurance marketplace | Technology shift |
|
||||
|
||||
The phase-zero streams are all direct enterprise sales with short cycles and clear buyers. The end-state streams require installed base — you cannot have a verification monopoly without deployed Passepartout instances.
|
||||
|
||||
* Risk-Ordered Investment Priority
|
||||
|
||||
1. Gate rule packages — Lowest risk. Clear buyer, existing budget, no dependency on full stack. Ship first.
|
||||
2. Verified API gateway — Standalone product, anyone using LLMs is a customer. Zero triad buy-in required.
|
||||
3. Verification appliance — Customers pay for hardware + ongoing subs. Verifiable revenue, long contracts.
|
||||
4. Continuous compliance monitoring — Annual contracts, compliance teams budget for it.
|
||||
5. Social protocol usernames — Trivial to implement, tests the namespace concept.
|
||||
6. Contract templates + attestation — Seeds the social protocol economy without needing full smart contracts.
|
||||
7. Compute marketplace — High risk/reward. Requires critical mass. Phase Zero bootstraps with cloud arbitrage.
|
||||
8. Verification monopoly — Thesis-level bet. Invest when installed base justifies it.
|
||||
|
||||
* Detailed References
|
||||
|
||||
- [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout economics (full thesis)]] — the unified economics document
|
||||
- [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]] — three revenue horizons, $2M to $1B+
|
||||
- [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][Cost structure and zero marginal cost]]
|
||||
- [[id:81a815ee-bf2b-4365-9894-b814e4196850][revenue table]] — concrete pricing per framework
|
||||
- [[id:e4a7b3d2-1c9f-4b6e-8a2d-5f3c7e1b9a0c][Compliance framework index]] — 41 frameworks by region and priority
|
||||
- [[id:558154ea-e63a-4c45-998c-26ce8588585b][First-mover window analysis]]
|
||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline]] — Phase Zero vs End State
|
||||
- [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][Licensing strategy]] — AGPL + commercial
|
||||
194
projects/passepartout/strategy/social-growth-strategy.org
Normal file
194
projects/passepartout/strategy/social-growth-strategy.org
Normal file
@@ -0,0 +1,194 @@
|
||||
:PROPERTIES:
|
||||
:ID: 57f9538a-6270-4302-8d07-d742168419eb
|
||||
:ID: alternative-growth-social-first
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Alternative Growth — Social-First Scenario
|
||||
#+filetags: :passepartout:growth:strategy:alternative:
|
||||
|
||||
The existing growth-strategy assumes institution-first growth: compliance → developer → consumer → regulatory. This page documents an alternative path: grow as a general-purpose social identity network, let institutions catch up later. Passepartout's three subsystems ([[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][the verification subsystem]], [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][the social protocol]]) are the same; the order of operations and the primary growth levers differ fundamentally.
|
||||
|
||||
* Why This Path Exists
|
||||
|
||||
The institution-first scenario ([[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][growth strategy]]) takes the product's core technical capability — verification — and finds the customer with the clearest pain. That is the safe bet. But Passepartout ships with a second product that has nothing to do with verification: the social protocol, a unified publishing network, contract platform, payment network, and decentralized identity layer rolled into one. No product on the market offers this combination — ENS is names, Bluesky is social, Stripe is payments, DocuSign is contracts. The social protocol replaces all four with one provable layer.
|
||||
|
||||
The social-first scenario leans into what the social protocol is /as a product/, not what Passepartout is /as a technology/. Publishing, payments, contracts, and identity are all mass-market primitives. They can grow without ever mentioning ACL2, gate rules, or compliance. Verification is the infrastructure underneath, invisible to users until they need it.
|
||||
|
||||
Historical precedent: Instagram was a check-in app with filters. The camera and social graph came first; the advertising platform came later. Twitter was SMS broadcast; the real-time news network was emergent. In each case the product that users wanted had a different shape than the product that ultimately captured value.
|
||||
|
||||
* Phase 0: Unified Digital Existence Layer (0 → 10K users, 3-12 months)
|
||||
|
||||
The key premise: the social protocol is not an identity product. It is four layers in one — a publishing network, a contract platform, a payment network, and decentralized infrastructure — all unified under a single identity. No product on the market offers this combination. ENS is names only. Bluesky is social only. Stripe is payments only. The social protocol replaces all of them with one provable layer.
|
||||
|
||||
Customer: Anyone who touches more than one of these layers today and feels the friction of managing separate accounts, separate reputations, and separate data silos. The most likely first adopters:
|
||||
- Creators who publish across platforms and want verified ownership of their content
|
||||
- Freelancers and contractors who send invoices, sign agreements, and manage multiple identities
|
||||
- Crypto-natives who understand self-sovereignty but are tired of blockchain UX
|
||||
- Developers building agents that need a persistent identity, payment channel, and data store
|
||||
|
||||
The /minimum viable social protocol/ must ship all four layers at Phase 0. Not fully featured, but functional — enough that a user can register, publish a signed post, send a payment, and sign a simple contract using one identity. The value is in the unification: one account replaces four.
|
||||
|
||||
Growth lever: Multi-vector network effects. The social protocol grows not on a single curve but on four simultaneous curves:
|
||||
1. Publishing: each new creator attracts readers, who may become creators
|
||||
2. Payments: each new payment user creates liquidity that makes the network more useful for everyone
|
||||
3. Contracts: each new contract written on the social protocol creates a template and a precedent
|
||||
4. PDS: each new PDS increases the federation surface and the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]] supply
|
||||
|
||||
Any of these can be the primary growth vector in a given market. If publishing stalls in one region, payments might take off. This redundancy dramatically increases the probability that /some/ vector finds PMF.
|
||||
|
||||
Tactics:
|
||||
|
||||
1. /Entry point optimization./ Ship all four layers but actively measure which one drives signups in each channel. If a blog post about "verified publishing" drives 10× more signups than a post about "decentralized identity," double down on publishing. The platform is unified enough that users who join for one reason discover the other three.
|
||||
|
||||
2. /Creator tools./ Offer a one-click "publish with provenance" widget. A creator writes on Substack, Medium, or their own blog, pastes the social protocol embed, and every post is automatically signed and timestamped. Readers see a blue checkmark that links to the social protocol attestation. This is a /better/ blue checkmark than Twitter's because it's cryptographically verifiable — and it works /across/ platforms.
|
||||
|
||||
3. /Freelancer onboarding./ Ship an invoice-and-contract template: "Send a verified invoice. Get a signed contract. Get paid on the social protocol." The freelancer registers once, and their invoices, contracts, and payment history are provably theirs. This is a /productivity tool/ first and a social network second — users join to get paid, stay because their professional reputation is on it.
|
||||
|
||||
4. /PDS hosting as infrastructure./ The PDS is the backbone, not the headline. Freemium model: first 1GB free, $5-15/mo for unlimited. The PDS stores your identity, content, contracts, and payment history in one place. The value prop: /one account, one data store, one reputation, everywhere/.
|
||||
|
||||
5. /Fee-based revenue./ The social protocol takes 0.5-2% on payment transactions and 5-10% on marketplace contracts (data [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]], compute). These fees are invisible to users (built into the platform layer) and scale with usage. Unlike subscription revenue, they require zero active selling — the platform grows, fees follow.
|
||||
|
||||
Revenue:
|
||||
| Stream | Year 1 target | Mature |
|
||||
|--------+--------------+--------|
|
||||
| Payment processing fees (0.5-2%) | $100K-1M | $10-50M/yr |
|
||||
| PDS hosting subscriptions | $50K-200K | $1-3M/yr |
|
||||
| Marketplace contract commissions | $20K-100K | $5-20M/yr |
|
||||
| Premium username auctions | $50K-300K | $2-5M/yr |
|
||||
| Creator tools (Pro tier) | $50K-200K | $2-10M/yr |
|
||||
| Total | $270K-1.8M | $20-88M/yr |
|
||||
|
||||
The fees are the key difference from my earlier estimate. The social protocol's payment and contract layers generate revenue /per transaction/ without requiring subscription growth. A user who never pays for PDS hosting still generates fees if they send a payment or sign a contract on the network.
|
||||
|
||||
Key metric: Platform usage across any of the four layers. Fee volume (total value processed through payments + contracts). Not DAU — a user who joins for payments and never publishes is still generating revenue.
|
||||
|
||||
Failure mode: The unified platform is harder to explain than a single-purpose product. "One account for identity, publishing, payments, and contracts" sounds like a pitch deck, not a product. The risk is that the /scope/ of the social protocol makes it incomprehensible — users don't know what problem it solves because it solves too many. The mitigations: optimize for a single entry vector per channel, let users discover the others naturally.
|
||||
|
||||
* Phase 1: Network Effects — The Social Graph (10K → 1M users, 1-3 years)
|
||||
|
||||
Customer: The early adopter base expands to include privacy-conscious mainstream users. The trigger is a /platform failure event/: a major platform bans a creator, de-platforms a community, or suffers a data breach. When that happens, the social protocol is ready — it offers the same social primitives (messaging, identity, publishing) but with ownership.
|
||||
|
||||
Growth lever: Metcalfe's law + switching cost. Each new user makes the network more valuable. But the real lock-in is the /reputation graph/: attestations, signatures, and data provenance are cumulative. A user with 3 years of verified activity on the social protocol cannot replicate that on any other platform. The switching cost grows with time.
|
||||
|
||||
Tactics:
|
||||
|
||||
1. Ship verified messaging. Every message between social protocol users is signed and timestamped. No third party can modify or delete it. The product pitch: /Twitter, but your tweets are yours, and nobody can rewrite history/.
|
||||
|
||||
2. Publish an attestation API. Third-party services (news outlets, marketplaces, social platforms) can query the social protocol to verify a user's reputation. News comments show "verified human, 2yr history, no abuse flags." This creates /outbound value/ — the network becomes useful to people who aren't even on it.
|
||||
|
||||
3. Offer PDS-to-PDS federation. Social protocol instances communicate directly. No central server. This differentiates from every centralized platform and gives a structural privacy advantage that no amount of VC funding can replicate.
|
||||
|
||||
4. Introduce data licensing. Users can license their verified data to AI training companies, researchers, advertisers — on their own terms, with their own price. The social protocol takes a 10-15% commission. This creates a /revenue share/ that users understand viscerally. Compare: X/Twitter makes billions selling user data and gives nothing back. Social protocol users get paid.
|
||||
|
||||
5. Verification becomes visible. Each user's profile shows a "verification score" based on the length and depth of their attested history. Long-time users get a visible badge. This creates status competition around the /one thing nobody else can offer/: provable history.
|
||||
|
||||
Revenue:
|
||||
| Stream | Year 3 target | Mature |
|
||||
|--------+--------------+--------|
|
||||
| PDS hosting subscriptions | $500K-2M | $10-50M/yr |
|
||||
| Data licensing commissions | $200K-1M | $20-100M/yr |
|
||||
| Premium username renewals | $100K-500K | $5-10M/yr |
|
||||
| Verified badge program | $100K-300K | $2-5M/yr |
|
||||
| Attestation API (per-query) | $50K-200K | $5-20M/yr |
|
||||
| Total | $1-4M | $42-185M/yr |
|
||||
|
||||
Key metric: Daily active PDS users. Inter-instance messages per day. Attestation API queries.
|
||||
|
||||
Failure mode: Network effects fail to trigger because the user experience is not /better/ than existing platforms — it's /different/. Different is not enough. The product must match or exceed the UX of mainstream social platforms while offering the ownership advantage. If the UX gap is too large, users stay on Twitter/Bluesky/Threads despite the privacy cost.
|
||||
|
||||
* Phase 2: The Institution Crossover (1M → 10M users, 2-5 years)
|
||||
|
||||
Customer: At 1M+ active identities, the network has critical mass. Institutions (universities, media companies, government agencies, enterprises) can no longer ignore it because /their users are on it/. The crossover happens organically: a university registrar wants to issue verified credentials. A newsroom wants to publish with verified provenance. A regulator wants to use the social protocol's attestation infrastructure because it already has users.
|
||||
|
||||
Growth lever: Institutional network effects. Every institution that joins brings 10K-100K users with it (employees, students, customers). Each new institutional user increases the value of verification for everyone else. The growth curve becomes logistic with institutional jumps, not smooth organic growth.
|
||||
|
||||
Tactics:
|
||||
|
||||
1. Ship the environment subsystem enterprise bundle (SSO, compliance reports, fleet management, audit logging). This was the /entire/ Phase 0-1 of the institution-first scenario. Here it is a Phase 2 feature — built to serve institutions that are already /inside/ the network, not sold to cold prospects.
|
||||
|
||||
2. Offer verified credentialing: degrees, certifications, professional licenses, issued on the social protocol, verifiable by anyone. The institution pays for the issuance. The graduate gets a portable, provable credential.
|
||||
|
||||
3. Offer provenance publishing: news organizations publish articles signed by their social protocol identity. Readers verify provenance in one click.
|
||||
|
||||
4. Verification appliances are now a /fulfillment order/, not a sales pitch. Institutions already inside the network ask: "Can we run our own instance?" The answer is yes — here is an environment subsystem appliance. The gate rule SDK is a value-up, not a product.
|
||||
|
||||
5. The compute marketplace activates naturally. With 10M+ users and thousands of institutions, compute supply and demand are both present without bootstrapping.
|
||||
|
||||
Revenue:
|
||||
| Stream | Year 5 target | Mature |
|
||||
|--------+--------------+--------|
|
||||
| Enterprise environment subsystem seats | $5-20M | $50-200M/yr |
|
||||
| Verified credential issuance | $2-10M | $20-100M/yr |
|
||||
| Compute marketplace fees | $1-5M | $50-200M/yr |
|
||||
| PDS hosting (scaled) | $2-10M | $20-50M/yr |
|
||||
| Data licensing (scaled) | $1-5M | $20-100M/yr |
|
||||
| Verification appliances | $2-10M | $50-100M/yr |
|
||||
| Total | $13-60M | $210-750M/yr |
|
||||
|
||||
Key metric: Institutional join events. Environment subsystem subscriptions. Credentials issued.
|
||||
|
||||
Failure mode: The institution crossover never comes because the social graph stalls at 1M users — enough for a niche, not enough for critical mass. The network becomes a high-quality-but-small community like early App.net or Mastodon. Verification is real but irrelevant because the rest of the world is on different platforms. The institution-first scenario is still possible from here (direct enterprise sales), but the supposed advantage of "users first" has not materialized.
|
||||
|
||||
* Phase 3: Default Infrastructure (10M → 1B+, 5-15 years)
|
||||
|
||||
Customer: At this scale, the social protocol is the default identity and communication layer for a significant fraction of internet users. New users join because /everyone is there/. Institutions join because /everyone is there/. The regulatory capture that the institution-first scenario required as a /growth lever/ happens here as a /consequence/ — regulators adopt social protocol attestation because it is the standard.
|
||||
|
||||
Growth lever: Default status. The network is the path of least resistance. A new social platform would need to replicate not just the user base but the entire attestation history, compute marketplace, and institutional infrastructure. The moat is not legal (regulation) but practical (installed base + cumulative value).
|
||||
|
||||
Tactics: Similar end state to the institution-first scenario — [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]], certified appliance sales, insurance marketplace, nation-state deployments. The difference is the /path/ and the /character/ of the moat:
|
||||
|
||||
- Institution-first moat: regulatory lock-in. You comply because the law requires it.
|
||||
- Social-first moat: installed-base lock-in. You join because everyone is there.
|
||||
|
||||
The regulatory moat is faster to deploy but brittle (a change in government can undo it). The installed-base moat is slower to build but self-reinforcing.
|
||||
|
||||
Revenue: Same end state as growth-strategy.org Phase 3 — $1B+ across certification, infrastructure rent, marketplace fees, and insurance underwriting.
|
||||
|
||||
* Comparison: Two Paths Side By Side
|
||||
|
||||
| Dimension | Institution-first | Social-first |
|
||||
|-----------+------------------+-------------|
|
||||
| First customer | CISO, compliance buyer | Creators, devs, payment users |
|
||||
| First revenue | $2-12M (year 1) | $500K-3M (year 1) |
|
||||
| Time to $10M ARR | 12-24 months | 2-4 years |
|
||||
| Time to $50M ARR | 2-4 years | 4-7 years |
|
||||
| Time to $1B+ | 5-15 years | 8-20 years |
|
||||
| Capital requirement | Low (revenue-funded) | Low-Moderate (fees fund growth) |
|
||||
| Marketing cost | Sales team + compliance mktg | Community + product-led growth |
|
||||
| Key execution skill | Enterprise sales | Consumer product + platform design |
|
||||
| Network effect trigger | Developer SDK (Phase 1) | Multi-vector: any of 4 layers |
|
||||
| Phase 0 offer | Compliance report | Unified identity + pub + pay + contract |
|
||||
| Moat type | Regulatory + insurance | Installed base + attestation |
|
||||
| Moat durability | Good (legal) | Strong (practical) |
|
||||
| Entry vectors | One: compliance pain | Four: publishing, payments, contracts, ownership |
|
||||
| Failure mode | Wrong pricing, too early | Any vector stalls — but all 4 must |
|
||||
|
||||
* Assessment: Which Is More Likely?
|
||||
|
||||
I initially assessed institution-first as significantly more likely. The unified-layer correction narrows the gap considerably. Here is the revised assessment:
|
||||
|
||||
The social-first path's strongest argument — which I dismissed too quickly — is that the social protocol is not competing with any single product. A competitor who beats it on publishing (Substack, Medium) cannot also beat it on payments (Stripe, PayPal) and contracts (DocuSign, LexisNexis) and identity management — simultaneously. The unification is not a feature; it is the structural advantage. Each layer reinforces the others, and competing against the whole stack requires matching all four, which no existing product does.
|
||||
|
||||
The multi-vector growth also matters. The institution-first path has one entry vector (compliance pain) and one failure mode (wrong pricing or too early). The social-first path has four entry vectors, and any one of them reaching PMF carries the other three. The probability that publishing /or/ payments /or/ contracts /or/ identity ownership finds product-market fit is higher than the probability that any single one does.
|
||||
|
||||
The fee-based revenue model further improves Phase 0 economics. Payment processing fees scale with transaction volume, not user count. A small number of high-value users (freelancers sending invoices, creators selling subscriptions) can generate meaningful revenue before the network reaches critical mass.
|
||||
|
||||
However: the core tension remains. The team building Passepartout is a deep-tech verification team — their competence is ACL2, gate rules, provably correct systems. The social-first path requires the team to also be a consumer product team — UX design, growth loops, community management, creator partnerships, payment infrastructure, fraud detection. That is not /impossible/ (the team can hire) but it is a different company than the one building [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]].
|
||||
|
||||
The institution-first path monetizes the team's /existing/ competence from day one. The social-first path requires building a second competence (consumer platform) that does not exist yet. This is the real distinction, not the product's inherent potential.
|
||||
|
||||
My updated assessment: the institution-first path is still higher probability, but not by the wide margin I initially claimed. The gap is narrower because the social protocol as a unified layer is genuinely unprecedented.
|
||||
|
||||
The hybrid path may be the strongest: ship the four-layer social protocol as a public platform /alongside/ the enterprise compliance sales.
|
||||
|
||||
* References
|
||||
|
||||
- [[id:d28adac8-08a1-40c4-ae43-b5d8d7b1743f][Primary growth strategy — institution-first]]
|
||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams by component]]
|
||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Social protocol contract platform details]]
|
||||
- [[id:528a0f6c-6fd6-41ed-9d59-237958bdaef2][Effects and growth as interleaved curves]]
|
||||
- [[id:dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70][Development timeline — Phase Zero and End State]]
|
||||
|
||||
#+begin_quote
|
||||
The social-first path is attractive because the end state is stronger. But the path to it requires building a consumer product alongside the deep-tech verification infrastructure — essentially running two startups in parallel. The [[id:0f949f6c-4cf1-49eb-b9a4-ebcac27ee548][Social protocol Social Space requirements]] describe the community interaction model that makes the social-first path viable..
|
||||
#+end_quote
|
||||
140
projects/passepartout/strategy/social-protocol-contracts.org
Normal file
140
projects/passepartout/strategy/social-protocol-contracts.org
Normal file
@@ -0,0 +1,140 @@
|
||||
:PROPERTIES:
|
||||
:ID: 64708e1f-00e9-4cb7-b44b-ea0b98e5296d
|
||||
:ID: agora-contracts
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Passepartout Social Protocol — Smart Contracts and the Contract Marketplace
|
||||
#+filetags: :passepartout:social-protocol:contracts:revenue:smart-contracts:
|
||||
|
||||
The social protocol's infrastructure — DIDs (identity), DIDComm (communication), PDS (state), gate rules (logic), ACL2 (verification) — together form a full smart contract platform. Every piece is already in the architecture. This page describes what contracts are possible, how they generate revenue, and why the social protocol's approach is structurally stronger than existing platforms.
|
||||
|
||||
* Why Social Protocol Contracts Are Different
|
||||
|
||||
Existing smart contract platforms (Ethereum, Solana, Cosmos) verify only that execution followed the rules. The social protocol's ACL2 prover verifies that the /rules themselves/ are correct with respect to a formal specification. This is strictly stronger:
|
||||
|
||||
- Ethereum: The contract ran according to the EVM bytecode (execution validity)
|
||||
- Social Protocol: The contract is correct with respect to its specification, AND it ran correctly (correctness + execution)
|
||||
|
||||
This means social protocol contracts can encode real-world regulations ([[id:84fb5f8f-0527-4df0-b6b6-dbf3bcff8a7f][HIPAA]], [[id:ed65031c-cbd2-4ad2-bd53-a67791e183cd][SOC2]], [[id:513d5996-4ac7-4567-a992-18fc01599104][GDPR]]) as gate rules and prove that a contract execution satisfies them. No existing platform does this.
|
||||
|
||||
* What Contracts Enable
|
||||
|
||||
** 1. Verified Smart Contracts
|
||||
|
||||
Standard programmable contracts (escrow, swaps, voting, DAO governance) but every execution produces a machine-checkable ACL2 proof.
|
||||
|
||||
How it works:
|
||||
- Contract terms encoded as gate rules
|
||||
- State transitions are PDS updates
|
||||
- Every transaction runs through the symbolic engine and produces a proof log
|
||||
- Any instance can verify any other instance's contract execution by replaying the proof
|
||||
|
||||
Revenue: Transaction fee per contract execution in the [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]], deployment fee per verified contract, premium for certification weight.
|
||||
|
||||
Comparison: Ethereum collects ~$20B/yr in transaction fees. The social protocol's verifiably correct contracts target the same market with a stronger value proposition. The limitation is liquidity, not technology — network effects determine adoption.
|
||||
|
||||
** 2. Multi-Instance Governance Contracts
|
||||
|
||||
Organizations running multiple Passepartout instances need contracts that span instances: cross-instance policy, unified compliance, federated identity.
|
||||
|
||||
Use cases:
|
||||
- Enterprise: all instances in the finance department must apply the [[id:c9830152-0160-4bdc-ab03-6f308ad43536][SOX]] gate rule set
|
||||
- Consortium: each member instance votes on protocol upgrades
|
||||
- Supply chain: Instance A verifies shipment, Instance B verifies payment, both must agree
|
||||
|
||||
Revenue: Enterprise governance tier (annual license), per-instance fee.
|
||||
|
||||
** 3. Liquid Democracy Infrastructure
|
||||
|
||||
The social protocol's liquid democracy enables delegation-based voting where votes can be transferred and proxies can be verified.
|
||||
|
||||
Use cases:
|
||||
- DAO governance (token-weighted or identity-weighted voting)
|
||||
- Organizational proxy voting (shareholder meetings)
|
||||
- Delegated verification (trust someone's gate rule attestation)
|
||||
- Quadratic voting for public goods funding
|
||||
|
||||
Revenue: Per-vote transaction fee, governance contract setup fee, premium for verified anonymous voting.
|
||||
|
||||
** 4. Attestation and Reputation
|
||||
|
||||
DIDs produce verifiable actions. Over time, every DID accumulates a track record of correct verifications, successful contract executions, and honest attestations.
|
||||
|
||||
Marketplace primitives:
|
||||
- Attest that a DID meets certification criteria (identity verification, proof track record, errors-and-omissions insurance)
|
||||
- Reputation scores based on verifiable history
|
||||
- Reputation staking: put tokens behind your attestation, lose them if wrong
|
||||
- Attestation insurance: insure against incorrect attestations
|
||||
|
||||
Revenue: Attestation fee (one-time or annual), verification fee per reputation query, commission on staked attestations.
|
||||
|
||||
** 5. Insurance Marketplace
|
||||
|
||||
If certification carries legal weight (as described in [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]), then:
|
||||
|
||||
- Proof insurance: A provider insures their verification results. If a proof turns out wrong, the insurance pays out. Premiums are set by actuarial gate rules based on the provider's track record.
|
||||
- Contract execution insurance: Insure against bugs in contract code (even ACL2-verified contracts can have specification errors).
|
||||
- Reputation staking pool: A reinsurance pool where multiple providers stake against each other's attestations.
|
||||
|
||||
Revenue: Premiums, pool fees, actuarial gate rule [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]].
|
||||
|
||||
Why this is defensible: Insurance requires capital and track record. A new entrant cannot bootstrap reputation overnight. The early player accumulates both, creating a moat that compounds with every honest attestation.
|
||||
|
||||
** 6. Data Sharing and Licensing Contracts
|
||||
|
||||
PDS-to-PDS data sharing encoded as gate rules. Two instances agree: Instance A may query fact X from Instance B's PDS, subject to gate rule Y, in exchange for Z tokens.
|
||||
|
||||
Use cases:
|
||||
- Personal data licensing: my health data is available to research instances under GDPR-compliant gate rules
|
||||
- Enterprise data marketplace: our compliance audit trail is available to customers under NDA gate rules
|
||||
- Verified dataset access: this ML training dataset is licensed for non-commercial use, verified by gate rule
|
||||
|
||||
Revenue: Commission on each data transaction (the compute marketplace extended to data), licensing templates.
|
||||
|
||||
** 7. Namespace Sub-Leasing and Auction
|
||||
|
||||
[[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium usernames]] can be sub-leased between DIDs. The registry takes a commission on each lease.
|
||||
|
||||
Revenue: Commission per lease transaction, auction fees for contested names, premium for verified ownership.
|
||||
|
||||
** 8. Dispute Resolution
|
||||
|
||||
When two social protocol instances disagree on a contract execution, submit to a verified arbitrator. The arbitrator runs the contract in their own [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] and the proof log resolves the ambiguity unambiguously — the dispute is about facts, not interpretations, because the contract terms are formal gate rules.
|
||||
|
||||
Revenue: Fee per resolution, premium for reputation-weighted arbitration (arbitrators with long track records charge more).
|
||||
|
||||
* Contract Platform Revenue Summary
|
||||
|
||||
| Primitive | TAM proxy | Revenue model | Phase | Dependency |
|
||||
|----------+-----------+--------------+-------+------------|
|
||||
| Smart contracts (general) | $20B/yr (Ethereum) | Transaction fees | End State | Installed base |
|
||||
| Contract templates | New market | Per-template sale | Zero | Gate rule SDK |
|
||||
| Governance (multi-instance) | New market | Annual license | Zero | [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][Environment subsystem]] premium |
|
||||
| Liquid democracy | New market | Per-vote fee | End State | Installed base |
|
||||
| Attestation | New market | Per-attestation | Zero | DID registry |
|
||||
| Insurance marketplace | $1T+ (global insurance) | Premiums | End State | Installed base + capital |
|
||||
| Data sharing | New market | Commission | Both | PDS + DIDComm |
|
||||
| Namespace sub-leasing | Small | Commission | Zero | Username registry |
|
||||
| Dispute resolution | New market | Per-resolution | End State | Installed base |
|
||||
|
||||
Key insight: Contract templates, attestation, and multi-instance governance can ship in Phase Zero. They require only the existing social protocol infrastructure (DIDs, PDS, gate rules) — no full Lisp Machine needed. These seed the contract economy before the smart contract platform ships.
|
||||
|
||||
* Relationship to Compute Marketplace
|
||||
|
||||
The compute marketplace and the contract platform reinforce each other:
|
||||
|
||||
- Contracts need compute to execute (marketplace demand)
|
||||
- Compute providers need contracts to structure their offerings (marketplace supply)
|
||||
- Attestation bridges them: a compute provider's track record is a verifiable contract history
|
||||
- Insurance prices compute risk based on attestation
|
||||
|
||||
Passepartout's network effects compound when all three layers (compute, contracts, attestation) are active simultaneously. Any one layer without the others is weaker — together they create the [[id:827bc546-e887-5b7c-9b65-6392beaf0920][verification monopoly]].
|
||||
|
||||
* References
|
||||
|
||||
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol overview]]
|
||||
- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium username registry]]
|
||||
- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]]
|
||||
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]
|
||||
- [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams overview]]
|
||||
- [[id:827bc546-e887-5b7c-9b65-6392beaf0920][The [[id:90484f4a-5b70-4001-93d6-e610e54ed573][Social Protocol Exchange requirements]] specify the contract and exchange layer in detail. [[id:827bc546-e887-5b7c-9b65-6392beaf0920][Verification monopoly]]]]
|
||||
@@ -0,0 +1,184 @@
|
||||
:PROPERTIES:
|
||||
:ID: 8c7b9812-f8d6-4347-8915-ce8e520b7914
|
||||
:ID: agora-entry-strategy
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Passepartout Social Protocol Entry Strategy — Finding the Low-Hanging Use Cases
|
||||
#+filetags: :passepartout:social-protocol:strategy:entry:go-to-market:
|
||||
|
||||
The social protocol replaces 20+ centralized platforms across social, publishing, video, messaging, e-commerce, contracts, and identity. But attempting to launch all at once guarantees failure — the cold start problem kills any network that requires everything to work before anything is useful.
|
||||
|
||||
This page identifies the entry points that require the least technical maturity, target the most acute pain, and demonstrate the full bundle (identity + content + payments + contracts + governance) as early as possible.
|
||||
|
||||
* The Entry Criteria
|
||||
|
||||
Any viable entry point must score well on all three axes:
|
||||
|
||||
1. /Pain intensity/ — how broken is the current solution for this group? The pain must be acute enough to overcome the friction of adopting an immature ecosystem.
|
||||
2. /Community density/ — can they switch as a group? Scattered individuals cannot bootstrap network effects. A guild migrating together solves the cold start.
|
||||
3. /Technical maturity/ — how much of the spec must ship? Lean towards entry points that work on a minimal build and layer up.
|
||||
|
||||
Plus a fourth that emerges from the discussion:
|
||||
|
||||
4. /Bundle necessity/ — does this use case require multiple layers at once, or does one layer suffice? Entry points that only use identity + content teach users a narrow view of the social protocol. Entry points that force the bundle (identity + content + payments + contracts + governance) demonstrate the /real/ product.
|
||||
|
||||
* Candidate Entry Points Ranked
|
||||
|
||||
** 1. Organized Communities (strongest candidate)
|
||||
|
||||
/Description:/ Neighborhood associations, housing cooperatives, clubs, volunteer orgs, religious groups, sports teams, PTAs, investment clubs, open-source projects, research collaboratives — any group that needs to communicate, organize, pool resources, and make decisions together.
|
||||
|
||||
/Pain::/ Today they use a patchwork: Reddit or Discord for communication, Google Sheets for resource tracking, Venmo for dues, DocuSign for agreements, Trello for tasks, Zoom for meetings. /Five separate tools with no unified identity, no shared reputation, no portable history./ When leadership changes, everything breaks — the new treasurer has to recreate the spreadsheet, the new mod inherits a Discord server they don't control.
|
||||
|
||||
/Density:/ Very high. These groups /already exist/ as organized units. You don't need to build a social graph — the social graph is the group. If an HOA of 200 families joins the protocol, all 200 arrive at once.
|
||||
|
||||
/Tech needed:/ Moderate. Needs:
|
||||
- Identity (Personas, PDS for each member)
|
||||
- Social Spaces (feeds, announcements, group chat via DIDComm)
|
||||
- Contract Notes (tasks, assignments, dues tracking)
|
||||
- Governance modules (voting, constitutions, role management)
|
||||
- Lightning payments for dues and pooled funds
|
||||
|
||||
/Bundle necessity:/ High. This use case /requires/ the bundle. A group chat alone doesn't solve the problem. They need identity + communication + tasks + payments + governance all in one place, with a unified data model.
|
||||
|
||||
/Why this is low-hanging:/ The group already exists. The switching costs are low because the alternative is five separate tools that don't integrate. The social protocol doesn't need to be better than Discord at chat — it needs to be better than /Discord + Sheets + Venmo + Trello/ combined, which is a much lower bar.
|
||||
|
||||
/Killer demo:/ "Your HOA needs a new roof. A member proposes it in a feed post. The treasurer issues a payment request as a Contract Note. 180 families vote via quadratic voting, 150 approve. The contract auto-collects dues via Lightning, issues the payment to the contractor with a HODL invoice escrow, and the contractor's proof of completion releases the funds. Every step is signed, timestamped, and auditable. No spreadsheets, no separate bank accounts, no chasing checks."
|
||||
|
||||
** 2. Community Refugees (highest density)
|
||||
|
||||
/Description:/ Communities that have been deplatformed or are at risk: subreddits that got banned, Discord servers that got nuked, Facebook groups that lost their admin, Telegram channels under pressure. These groups will migrate and are actively looking for alternatives.
|
||||
|
||||
/Pain:/ Acute. Their existing community infrastructure is gone or at risk. They need a new home /now/ and the fear of losing it again makes them receptive to sovereignty arguments.
|
||||
|
||||
/Density:/ Maximal. A banned subreddit of 50K users is 50K users arriving together.
|
||||
|
||||
/Tech needed:/ Low. They primarily need identity + content (feeds, comments, basic moderation). Payments, contracts, and governance can layer on afterward.
|
||||
|
||||
/Bundle necessity:/ Low-medium. They join for one reason (surviving as a community) and can discover the rest later. But the migration is urgent enough that they adopt with minimal features.
|
||||
|
||||
/Risk:/ They might leave when the crisis passes. But if they've built reputation, pooled resources, and documented decisions on the social protocol during their refuge, the switching cost to go back is real.
|
||||
|
||||
** 3. Adult Creators / OnlyFans Refugees (highest willingness to pay)
|
||||
|
||||
/Description:/ Creators who have been deplatformed, payment-processed-discriminated, or who want to own their audience. The OnlyFans model takes 20%. Stripe bans adult content. Creators earn $50K-500K/yr and have strong incentive to bypass intermediaries.
|
||||
|
||||
/Pain:/ Very high. Direct financial loss from platform fees and payment discrimination. Existential risk of deplatforming with no audience portability.
|
||||
|
||||
/Density:/ Medium. Creators are scattered and their audiences follow them, not the platform. Migration requires the creator to lead their audience.
|
||||
|
||||
/Tech needed:/ Medium-high. Needs LSAT for paywalled content, Lightning for payments, PDS for storage, Blind CDN for distribution. The /spec is ready/ but the implementation is non-trivial.
|
||||
|
||||
/Bundle necessity:/ Medium. Uses identity + content + payments. Contracts and governance are lower priority initially.
|
||||
|
||||
/Why compelling:/ This group has money and will pay for a working solution. They are the fastest path to /revenue/.
|
||||
|
||||
** 4. Weak Rule-of-Law Contracts (highest long-term impact)
|
||||
|
||||
/Description:/ Small businesses and individuals in countries where contract enforcement is unreliable or corrupt. Cross-border freelancers who can't trust local courts. Sellers in markets without dispute resolution.
|
||||
|
||||
/Pain:/ Very high. There is no good solution today. Informal trust networks are the only alternative.
|
||||
|
||||
/Density:/ Low. These are one-off transactions, not communities.
|
||||
|
||||
/Tech needed:/ Very high. Requires full SCAL: Ricardian contracts, HODL escrow, multi-level arbitration guilds, reputation slashing, financial collateralization.
|
||||
|
||||
/Bundle necessity:/ High. Uses identity + contracts + payments. Content and governance are secondary.
|
||||
|
||||
/Risk:/ This is the hardest technical build and the hardest go-to-market (scattered users, no density). But once it works, it has the strongest moat — /no one else offers verifiable contract enforcement without a state./
|
||||
|
||||
** 5. Developers / OSS (lowest risk, lowest reward)
|
||||
|
||||
/Description:/ Open-source developers who want decentralized code hosting with signed commits, Lightning bounties, and governance.
|
||||
|
||||
/Pain:/ Low-medium. GitHub works well. The pain is ideological (dependency on Microsoft) more than practical.
|
||||
|
||||
/Density:/ High. Developer communities are well-connected and migrate together (e.g., a popular repo moving to the social protocol brings all contributors).
|
||||
|
||||
/Tech needed:/ Low-medium. Merkle DAGs for code, Contract Notes for issues/PRs, Lightening for bounties.
|
||||
|
||||
/Bundle necessity:/ Low. Developers would use just code hosting initially. The other layers are bonus.
|
||||
|
||||
* Recommended Sequence
|
||||
|
||||
** Phase 1: Organized Communities
|
||||
|
||||
Target: HOAs, clubs, volunteer orgs, cooperatives, religious groups, PTAs — any group that currently uses 3+ separate tools.
|
||||
|
||||
Why first: lowest cold-start risk (groups exist, migrate as units), highest bundle necessity (forces adoption of identity + content + tasks + payments + governance simultaneously), moderate technical build.
|
||||
|
||||
Go-to-market:
|
||||
- Identify 5-10 pilot communities with personal connections or warm intros
|
||||
- Onboard each as a Collective Persona with one onboarding session
|
||||
- The community admin invites members via DID (email link, QR code, share code)
|
||||
- Members arrive to find a fully set-up community space: announcement feed, group chat, task board, treasury, voting
|
||||
- The first "killer demo" happens naturally when the community's first real decision is conducted through the protocol
|
||||
|
||||
KPI: Number of organized communities. Community retention rate. Contract volume (tasks, dues, votes).
|
||||
|
||||
** Phase 2a: Community Refugees (parallel track)
|
||||
|
||||
Target: Banned or at-risk subreddits, Discord servers, Facebook groups.
|
||||
|
||||
Why second: highest density per event, but needs Phase 1 to have a working product and some community momentum to point at.
|
||||
|
||||
Go-to-market:
|
||||
- Monitor deplatforming events. When a subreddit of 10K+ users gets banned, the community is actively looking — outreach within 24 hours
|
||||
- Offer a ready-made social protocol community space with import tools (archive of the banned sub, migration guide)
|
||||
- The Mod Collective Persona concept lets the migrated community feel familiar: same mods, same rules, same culture — just sovereign
|
||||
|
||||
Risk: These communities might not stay. Mitigation: make the community space good enough that they don't want to leave. The mod tools, governance modules, and integrated payments give them capabilities Reddit never had.
|
||||
|
||||
** Phase 2b: Adult Creators (revenue track)
|
||||
|
||||
Target: OnlyFans/Patreon creators with audience independence motivation.
|
||||
|
||||
Why parallel: highest ARPU, fastest path to revenue. Requires LSAT implementation which can be scoped independently.
|
||||
|
||||
Go-to-market:
|
||||
- Find 5-10 creators who have been deplatformed or are vocally anti-OnlyFans
|
||||
- Offer a white-glove migration: set up their PDS, import their content archive, configure their subscription tiers
|
||||
- The creator posts to their existing audience: "I'm now on the social protocol. Join me here."
|
||||
- Their audience follows. 1K paying subscribers at $10/mo = $120K/yr on the platform.
|
||||
|
||||
** Phase 3: Freelancers / Gig Workers
|
||||
|
||||
Target: Upwork/Fiverr refugees, cross-border freelancers.
|
||||
|
||||
Why third: needs Phase 1+2 to have a reputation graph and some contract volume before the escrow/arbitration layer is credible.
|
||||
|
||||
Go-to-market:
|
||||
- The same communities onboarding from Phase 1 now have members who need to hire each other
|
||||
- A community member posts a task with a Lightning bounty. Another completes it. The contract is recorded.
|
||||
- This is organic — the use case emerges from the community, not from a marketing campaign
|
||||
|
||||
** Phase 4: Weak Rule-of-Law
|
||||
|
||||
Target: Global south, cross-border trade, any jurisdiction where the courts are unreliable.
|
||||
|
||||
Why last: needs the full SCAL stack, arbitration guilds with track records, and enough installed base that reputation slashing is a real deterrent.
|
||||
|
||||
* The Thesis
|
||||
|
||||
The social protocol does not need millions of users to prove its value. It needs /one organized community/ to use the full bundle and see what happens. When an HOA of 200 families votes on the budget, collects dues via Lightning, and executes a roof contract with HODL escrow — all in one platform, all verified — the demo sells itself.
|
||||
|
||||
Organized communities are the entry point because they force the protocol to be the /entire/ product from day one, not just another social app. The group that joins for communication stays because of contracts, pays because of Lightning, and governs because of the modules. That is the full vision, delivered to one group at a time.
|
||||
|
||||
* Summary Table
|
||||
|
||||
| Priority | Entry point | Pain | Density | Tech | Bundle | Revenue | Risk |
|
||||
|----------+-------------+------+---------+------+--------+---------+------|
|
||||
| 1 | Organized communities | High | Very high | Moderate | Full | Dues/contract fees | Low (groups exist) |
|
||||
| 2a | Community refugees | Very high | Maximal | Low | Partial | Future contracts | Medium (may leave) |
|
||||
| 2b | Adult creators | Very high | Medium | Med-high | 3/4 layers | High fees | Medium (LSAT build) |
|
||||
| 3 | Freelancers | High | Low | High | 3/4 layers | Escrow fees | Medium (density) |
|
||||
| 4 | Weak rule-of-law | Very high | Very low | Very high | 4/4 layers | Arbitration | High (cold start) |
|
||||
|
||||
* References
|
||||
|
||||
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Social Protocol overview]]
|
||||
- Social Protocol Platform Replacement Strategy
|
||||
- Social Space — Collective Personas and Governance
|
||||
- Exchange and Contracts — SCAL, Escrow, Arbitration
|
||||
- [[id:57f9538a-6270-4302-8d07-d742168419eb][Social-first growth scenario]]
|
||||
- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Full competitive landscape]]
|
||||
26
projects/passepartout/strategy/social-protocol-overview.org
Normal file
26
projects/passepartout/strategy/social-protocol-overview.org
Normal file
@@ -0,0 +1,26 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 1d074690-a279-59cb-b91d-e9a22ae104ad
|
||||
:END:
|
||||
#+title: Passepartout Social Protocol — The Society (Decentralized Network)
|
||||
#+filetags: :passepartout:social-protocol:network:dids:
|
||||
|
||||
Passepartout Social Protocol is the decentralized identity and communication layer that connects [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] instances:
|
||||
|
||||
- **Self-sovereign identity** via HD key derivation (BIP-44)
|
||||
- **Encrypted messaging** via DIDComm (agent-to-agent and agent-to-human)
|
||||
- **Notes** as atomic, content-addressed, signed data units (mapped from Passepartout memory-objects)
|
||||
- **Relay Network** for censorship-resistant message routing
|
||||
- **Personal Data Store (PDS)** — the Merkle fact store exposed as a network-addressable service
|
||||
- **[[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]]** where instances offer symbolic engine capacity
|
||||
- **Contracts and liquid democracy** infrastructure
|
||||
|
||||
The PDS is Passepartout's in-process memory — the Merkle tree, the fact store, the memory-objects. Every memory-object already has a SHA-256 hash, which maps directly to the social protocol's CIDv1 content addressing.
|
||||
|
||||
Revenue paths from the social protocol:
|
||||
- [[id:2e390c1d-65f3-5fb3-b898-ac3fc4291ee7][Premium username registry]] — $10M/yr at scale
|
||||
- [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] — $18M/yr at scale
|
||||
- [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] — venture-scale
|
||||
- [[id:64708e1f-00e9-4cb7-b44b-ea0b98e5296d][Smart contracts + contract marketplace]] — the kill app
|
||||
|
||||
See [[id:ed05cab4-88e9-4e25-b7c9-346fa39c69a0][Revenue streams overview]] for the full picture across all triad components.
|
||||
14
projects/passepartout/strategy/social-protocol-usernames.org
Normal file
14
projects/passepartout/strategy/social-protocol-usernames.org
Normal file
@@ -0,0 +1,14 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 2e390c1d-65f3-5fb3-b898-ac3fc4291ee7
|
||||
:END:
|
||||
#+title: Premium Username Registry on Passepartout Social Protocol
|
||||
#+filetags: :passepartout:social-protocol:revenue:names:registry:
|
||||
|
||||
The DID system is permissionless — anyone generates their own DID via HD key derivation. But human-readable @handles (short names, common words, brand names) are naturally scarce. The early player controls the namespace registry.
|
||||
|
||||
- **Free tier:** any DID can claim a namespace.username on a first-come, first-served basis with proof of key ownership
|
||||
- **Premium tier:** short names (2-3 chars), common words, brand names, squatter prevention via auction or annual lease
|
||||
- **Revenue model:** $5-$50/year per premium username, auction revenue for highly contested names (single-letter, common surnames). ENS-style: registration fees fund development, not speculation.
|
||||
|
||||
At scale: 1M premium usernames at $10/yr average = $10M/yr recurring. The namespace registry is a natural monopoly — the early player's registry is the most widely accepted, so every new user registers there. Network effects lock in. The premium username registry works together with a [[id:1a2b38df-20ba-58ca-ba55-a072be67bd0d][PDS as a service]] offering and a [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][Compute marketplace]] to form a complete revenue ecosystem.
|
||||
62
projects/passepartout/strategy/time-estimates.org
Normal file
62
projects/passepartout/strategy/time-estimates.org
Normal file
@@ -0,0 +1,62 @@
|
||||
:PROPERTIES:
|
||||
:ID: dc2e4f22-1c4c-5d4a-a151-f96e5d3b0d70
|
||||
:CREATED: [2026-05-23 Sat]
|
||||
:END:
|
||||
#+title: Development Velocity and Timeline Estimates
|
||||
#+filetags: :passepartout:economics:development:timeline:velocity:orders-of-magnitude:
|
||||
|
||||
The [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders-of-magnitude time framework]] reveals that the original single-timeline estimate conflated two qualitatively different projects. The line counts are in plausible ranges for Lisp's density (~5-10× fewer lines than C++ for equivalent functionality), but the phases differ in their feedback regimes, constraints, and failure modes. The honest picture splits into two distinct phases.
|
||||
|
||||
*Old estimate:* 14,000 lines total, 3-6 months to replace the full computing stack. This was wrong because it treated all phases as linear — microcode has hardware latency (seconds per cycle), GUI has user-testing latency (days per iteration), and the browser alone is a years-scale project if done natively. The numbers do not add linearly across [[id:2cdca4b0-6b41-44b4-acb0-af21d0e27b00][orders of magnitude]].
|
||||
|
||||
*Corrected estimate:* Two-phase approach with a clear middleground destination.
|
||||
|
||||
* Phase Zero — The MVP (Linux-hosted, ships real product)
|
||||
|
||||
Run on Linux, use C libraries through CFFI, deliver value without replacing the OS. This is the [[id:efc76898-03f7-57ba-923d-35d65da88bb7][sufficiency flip]] applied to the verification layer only, not the whole stack.
|
||||
|
||||
| Component | Lines | Method | Scale |
|
||||
|----------+-------+--------+-------|
|
||||
| Neurosymbolic core (ACL2 + Screamer + LLM bridge) | ~4,500 | Agent-generated Lisp, human-validated | Weeks — dense, well-bounded, proven approach |
|
||||
| Terminal-based [[id:c3b3dc41-945f-54e9-84eb-ca014114f1be][environment subsystem]] (editor + REPL + shell) | ~2,000 | CL-charms / cl-tty | Weeks — TUI patterns established |
|
||||
| Gate rule SDK + marketplace | ~1,500 | ACL2 gate packages | Weeks — pure symbolic, well-specified |
|
||||
| CFFI wrappers (system, GPU, crypto, storage) | ~2,000 | Thin bindings | Days — mechanical translation |
|
||||
| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verification appliance]] CLI + [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][social protocol]] namespace | ~1,000 | API surface | Weeks |
|
||||
|
||||
*Total MVP: ~11,000 lines. Timeline: 1-3 months. Human review: ~20 hours.*
|
||||
|
||||
This ships. Users get verified code execution, gate rule packages, and a verified development environment. No new OS, no new browser, no Qt integration. Value proposition is proven with existing infrastructure.
|
||||
|
||||
*Revenue model starts here:* [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain gate packages]], verification appliance, [[id:3c6b0449-a8fb-5b89-b82a-34efb21ef5b5][compute marketplace]]. The MVP is a product, not a demo.
|
||||
|
||||
* Phase End State — Full Lisp Machine (cannibalize the stack)
|
||||
|
||||
Replace Linux, replace C libraries, own the framebuffer, own the browser. This is the full [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] vision.
|
||||
|
||||
| Phase-out target | Replacement | Lines | Scale | Risk |
|
||||
|-----------------+------------+-------+-------+------|
|
||||
| Linux kernel (scheduler, IPC, drivers) | Microcode on Tenstorrent | ~6,000 | Months — hardware-limited cycles | Verification delay; hardware bugs |
|
||||
| MMU / process isolation | GC + ACL2-verified single address space | ~2,000 | Weeks — architecture already defined | Legacy app compatibility |
|
||||
| Display server (X11/Wayland) | Lisp framebuffer compositor | ~4,000 | Months — visual debugging is slow | UX gaps at the edges |
|
||||
| Browser (WebKit embed) | WebKit via Lisp FFI with verified wrappers | ~3,000 | Months — sandboxing the embed | Web platform surface is unbounded |
|
||||
| Native browser | Full Lisp DOM + render engine | ~30,000+ | Years — browser engines are OS-scale | This is the hardest piece. Consider staying on WebKit |
|
||||
| Core libraries (libc, SSL, crypto, etc.) | Incremental verified replacements | ~10,000+ | Years — can chip away post-ship | Every replacement must match SOTA perf |
|
||||
| Qt / terminal / native UI toolkit | Environment toolkit (verified compositor + widgets) | ~8,000 | Months–years | UX parity with modern toolkits is the highest risk |
|
||||
|
||||
*Ballpark end state: 25,000-60,000 lines. Timeline: 2-5 years.*
|
||||
|
||||
The range reflects uncertainty about the browser. If WebKit embed is sufficient (Phase Zero's terminal UX graduates to a managed WebView), the end state is closer to 25K. If you need a full native browser with verified DOM, ACL2-rendered layout, and a compositor that matches macOS fluidity — that is a years-scale project on its own.
|
||||
|
||||
* Orders-of-Magnitude Risk Map
|
||||
|
||||
| Decision | At stake | True scale | Mistake if treated as |
|
||||
|---------+---------+-----------+----------------------|
|
||||
| Does the verification marketplace work? | Company thesis | Months (Phase Zero) | Solved in days |
|
||||
| Can we ship without replacing Linux? | Time-to-market | Weeks to implement | Years of kernel work before product |
|
||||
| Is WebKit embed enough for the environment subsystem? | 60% of total timeline | Months vs years | Native browser as default path |
|
||||
| Does the sufficiency flip cover each domain? | Revenue model | Weeks per domain | One-shot, all or nothing |
|
||||
| Can Lisp match SOTA browser UX? | Full vision | Generations (or never) | Engineering problem, not a research question |
|
||||
|
||||
The most dangerous order-of-magnitude error: treating the end state as an engineering sprint. Replacing the browser engine is a years-scale project that has defeated every attempt (Servo, PhantomJS, etc.). If that is the destination, plan accordingly — or accept WebKit embed as the terminal destination and focus verification on the OS/compositor layer where it provides real security value.
|
||||
|
||||
See [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][Investment thesis]] for the business case and [[id:0b5a8a74-cfd6-542d-bc88-4eb3cd8626f9][Cost structure]] for the economics behind the verification-only-first approach.
|
||||
17
projects/passepartout/strategy/verification-appliance.org
Normal file
17
projects/passepartout/strategy/verification-appliance.org
Normal file
@@ -0,0 +1,17 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 84a537b4-4256-50c8-91f5-dd5b4538418f
|
||||
:END:
|
||||
#+title: Verification Appliance (Hardware)
|
||||
#+filetags: :passepartout:revenue:hardware:fpga:tenstorrent:
|
||||
|
||||
An FPGA or Tenstorrent card pre-loaded with a mature [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] image, [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][domain-specific gate rules]], and a hardware root of trust. No cloud dependency.
|
||||
|
||||
**Target:** regulated industries needing [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][provable compliance]] that cannot accept cloud-based AI.
|
||||
**Price:** $5K-$50K/unit. **Volume:** hundreds to low thousands in year one.
|
||||
|
||||
The [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Lisp Machine]] on Tenstorrent P150 (~72 RISC-V Tensix cores on a PCIe card) is the realistic first target: the microcode is RISC-V assembly (software), not FPGA bitstream (hardware). The system can propose, load, test, and roll back a new dispatch routine in seconds. An FPGA path would add synthesis time (minutes to hours per iteration). This hardware-first approach embodies [[id:9af13fff-9725-542b-93b1-a555bc74ad72][Lisp economics]] — verification hardware has near-zero marginal cost. The [[id:29e4dbf3-cf19-589c-8b14-389e8a39d564][Upgrade lifecycle]] for the appliance is managed via signed firmware updates with Merkle snapshots.
|
||||
|
||||
The [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Social protocol identity specification]] shows how the verification appliance issues provable identities for network participants. The [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][impact on the AI and GPU industry]] analysis covers how this new hardware tier — CPU-native Lisp microcode on RISC-V cores — reshapes the industry structure.
|
||||
|
||||
Revenue estimate: 50 sales in year one = $250K-$2.5M.
|
||||
16
projects/passepartout/strategy/verification-monopoly.org
Normal file
16
projects/passepartout/strategy/verification-monopoly.org
Normal file
@@ -0,0 +1,16 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 827bc546-e887-5b7c-9b65-6392beaf0920
|
||||
:END:
|
||||
#+title: The Verification Monopoly (UL for AI)
|
||||
#+filetags: :passepartout:economics:monopoly:certification:big-money:
|
||||
|
||||
The accumulated regression suite — thousands of edge cases from every deployed instance, every bug fix, every regulatory change — becomes the most comprehensive test of autonomous agent correctness ever assembled.
|
||||
|
||||
Any organization claiming a "safe AI agent" needs [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]] certification to prove it. This is Underwriters Laboratory for AI — a certification nobody can ignore.
|
||||
|
||||
**Revenue:** [[id:67faf52f-9126-50a7-b87e-2bedc610dac7][licensing]] the certification mark to every AI vendor that ships an agent. **Margins:** near-100% once the suite exists.
|
||||
|
||||
This is the venture-scale outcome. It depends on the [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][evaluation harness]] reaching critical mass, which depends on enough instances deploying the software to accumulate edge cases in the regression suite. The [[id:5961e469-53a3-5f3c-ab72-3c83ef91963f][investment thesis]] is built on the recognition that every deployed instance makes this more valuable.
|
||||
|
||||
The unique structural advantage: every free instance of Passepartout feeds the regression suite. The more people use the free software, the more valuable the certification monopoly becomes. Positive sum. This creates deep [[id:2f783eb4-638e-5afa-9b59-6224d086a712][infrastructure lock-in]] and powerful [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — a competitor cannot replicate the certification without the accumulated history. The ultimate impact is a transformation of the entire [[id:5f55bbe6-d243-5766-8ccf-5c5cc88a6542][AI industry]], where safety certification becomes a prerequisite for market access.
|
||||
@@ -0,0 +1,12 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: d84679f1-c0c5-5be4-b19c-6573560640ee
|
||||
:END:
|
||||
#+title: Verified Skill Marketplace
|
||||
#+filetags: :passepartout:revenue:marketplace:skills:
|
||||
|
||||
A marketplace where skills are verified (sandbox + ACL2 non-contradiction proof) before listing. The marketplace takes a cut.
|
||||
|
||||
Value is in the verification infrastructure, not the skills themselves. Anybody can write a skill; the marketplace provides the guarantee that the skill won't corrupt the fact store, won't violate gate rules, and won't introduce inconsistencies.
|
||||
|
||||
This is the App Store model applied to provable correctness. The gatekeeper role is replaced by the prover — and the prover is transparent, inspectable, and impartial. The marketplace relies on [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate rule encoding]] to define skill constraints and an [[id:45258a2d-1675-562c-9024-5d1eb2f1ea56][Evaluation harness]] to verify them.
|
||||
Reference in New Issue
Block a user