Add missing _index.org files for 7 sections: stages, ai-agents-scoping, compliance, impact, social-protocol, verification, resources — rebuild clean after file reorganization

projects/passepartout/strategy/social-protocol/_index.org

@@ -0,0 +1,10 @@
+:PROPERTIES:
+:CREATED:  [2026-06-03 Tue]
+:ID:       75bc14db-d241-4af8-a4e0-f14aff654d17
+:END:
+#+title: Social Protocol
+#+filetags: :passepartout:social-protocol:network:identity:
+
+The Passepartout Social Protocol — identity, contracts, governance, and exchange mechanisms for the personal intelligence network.
+
+{{< page-list >}}

projects/passepartout/strategy/social-protocol/social-protocol-contracts.org

@@ -0,0 +1,140 @@
+:PROPERTIES:
+:ID:       64708e1f-00e9-4cb7-b44b-ea0b98e5296d
+:ID:       agora-contracts
+:CREATED:  [2026-05-23 Sat]
+:END:
+#+title: Smart Contracts and 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]]]]

projects/passepartout/strategy/social-protocol/social-protocol-entry-strategy.org

@@ -0,0 +1,184 @@
+:PROPERTIES:
+:ID:       8c7b9812-f8d6-4347-8915-ce8e520b7914
+:ID:       agora-entry-strategy
+:CREATED:  [2026-05-23 Sat]
+:END:
+#+title: Social Protocol Entry Strategy
+#+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][Adoption — social process section]]
+- [[id:1bc22b89-d3eb-4f6d-bcfc-2b0c19c8ed8f][Full competitive landscape]]

projects/passepartout/strategy/social-protocol/social-protocol-overview.org

@@ -0,0 +1,26 @@
+:PROPERTIES:
+:CREATED:  [2026-05-24 Sun]
+:ID:       1d074690-a279-59cb-b91d-e9a22ae104ad
+:END:
+#+title: Social Protocol Overview
+#+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.

projects/passepartout/strategy/social-protocol/social-protocol-usernames.org

@@ -0,0 +1,14 @@
+:PROPERTIES:
+:CREATED:  [2026-05-24 Sun]
+:ID:       2e390c1d-65f3-5fb3-b898-ac3fc4291ee7
+:END:
+#+title: Premium Username Registry
+#+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.