gbrain: sync converted org-mode brain files

projects/passepartout/architecture/architecture.org

@@ -62,6 +62,34 @@ The LLM layer is probabilistic. The ACL2 layer is deductive. The gate architectu
 
 The gate does not depend on OS privilege boundaries because it is in the evaluation loop itself. This is the architectural reason for the Lisp machine: a conventional OS interposes between the gate and the hardware. A Lisp machine eliminates that interposition by making the gate part of the evaluator.
 
+**How the gate knows which procedure belongs to which domain.**
+
+Every action entering the gate carries a domain tag. The tag is set by context — a file write under /home/user/documents/ gets the "documents" domain, a network call to an approved registry gets "network", a shell command running a compiler gets "software-engineering". The domain tags form a tree: "files" has children "documents", "code", "config", "system", each with its own rule set.
+
+The gate maintains a procedure registry mapping domain tags to ACL2-verified boundary functions. When an action arrives, the gate looks up the most specific domain tag that has a registered procedure. If "documents" has one, it uses that. If not, it walks up to "files". If no domain in the tree has a procedure, the action falls under LLM authority bounded only by the generic outer fence.
+
+Domain tags are defined in the policy configuration — a hierarchy of Org headings or YAML that maps path patterns, network destinations, and command prefixes to domain names. New domains can be added at any time with no code changes, just a policy edit. New domains start with no verified procedures and rely entirely on the LLM until experience accumulates and ACL2 boundaries are written.
+
+**How the verified procedure registry grows.**
+
+Verified procedures are not all written upfront. The initial gate ships with a minimal set of obviously correct outer boundaries — three to five rules that prevent catastrophic, irreversible actions. The registry grows through two mechanisms:
+
+1. Mistake-driven hardening: when the LLM's provisional authority causes harm, that action is logged, a human or automated process writes an ACL2 conjecture to prevent it, the Prover verifies it, and the resulting boundary function is added to the registry under the relevant domain tag.
+
+2. Adversarial probing: the gate randomly injects probe actions that would violate known desirable boundaries but are caught before execution. These probes generate the same hardening signal even when no mistake occurred. They cover the blind spot where the LLM always gets it right and no error is ever logged.
+
+3. Syscall wrappers: every action that crosses from the Lisp image into the host OS passes through a gate wrapper that records the kernel's response. When the kernel denies an action (permissions, seccomp, namespaces) that the gate had no rule for, the wrapper translates that kernel denial into a hardening signal — "the kernel prevented this. Consider codifying it as an ACL2 boundary." This covers the blind spot where the kernel catches the problem first and the gate never sees the danger.
+
+These three channels feed a queue. The autodidactic loop (or a human reviewer) periodically processes the queue, drafts ACL2 conjectures, runs the Prover, and deploys new verified boundaries. The gate's procedure registry grows transaction by transaction, domain by domain, from three rules to hundreds to thousands over the lifetime of the system.
+
+**The two blind spots and their mitigations.**
+
+Blind spot 1 — the LLM always gets it right. If the LLM never attempts a dangerous action in a domain, no mistake is logged, and no ACL2 boundary is proposed. Mitigation: adversarial probing. The gate regularly tests the LLM with actions that would violate known safety properties, logged before execution. These probes generate hardening signals regardless of the LLM's accuracy.
+
+Blind spot 2 — the kernel prevents the action before the gate sees it. If the LLM tries to write to /etc/shadow and the kernel's DAC permissions reject it, the LLM sees a permission error, the gate sees a failed action, but neither knows a safety boundary was enforced. Mitigation: syscall wrappers. The gate wraps every kernel transition and records the reason for denial. A kernel EACCES on /etc/shadow becomes a hardening signal: "the kernel has a rule about /etc/shadow that the gate doesn't. Codify it."
+
+Without these mitigations, the gate's coverage converges to a plateau determined only by what has already broken, leaving large regions permanently dependent on the LLM's probabilistic reliability.
+
 **The social protocol: provable communication.**
 
 The social protocol extends the verified semantics beyond a single machine. It provides:

projects/passepartout/architecture/conceptual-walkthrough.org

@@ -0,0 +1,100 @@
+:PROPERTIES:
+:CREATED:  [2026-05-31 Sun]
+:ID:       f0e1d2c3-b4a5-6c7d-8e9f-0a1b2c3d4e5f
+:END:
+#+title: A Conceptual Walkthrough of Passepartout
+#+filetags: :passepartout:architecture:overview:
+#+STATUS: draft
+
+This note explains how Passepartout works from beginning to end — what the parts are, how they compose, how the system grows itself, and what happens at each stage. It is the single document that ties all the others together.
+
+**What is Passepartout?**
+
+A personal computing environment where every action is verified, every communication is provable, and every piece of data is owned by you in a format you control. It is one system built from four subsystems that share one evaluation semantics, one memory graph, and one proof chain:
+
+- The Environment — your editor, shell, browser, and agent running in a single Lisp address space
+- The Knowledge subsystem — your notes, structured data, and symbolic assertions in Org-mode, with neural and symbolic indices built on top
+- The Verification subsystem — the Gate, which sits between every action and the system, deciding permit or deny
+- The Social Protocol — DID identity, encrypted messaging, PDS, relay, compute marketplace, liquid democracy
+
+**Stage-by-stage what the system looks like:**
+
+Stage 0 — the starting point. Conventional Linux, a Python agent (Hermes), SQLite knowledge store (gbrain). The Gate does not exist yet as software — it exists as a design. You use Hermes and gbrain while the Gate is being written. This is Passepartout's bootloader. Zero-day exploits exist. Patches are manual. No action is verified.
+
+Stage 1 — the social protocol layer goes live. Messages between instances become provable. Each instance gets a self-sovereign DID. The relay network forms. Revenue streams start from relay operation and PDS hosting. The Gate is being designed on this working infrastructure that generates income.
+
+Stage 2 — the Gate deploys as a software layer over the host OS. Every shell command, LLM proposal, and network message now passes through the same decision procedure. The Gate has two layers: a deductive layer running pre-verified ACL2 functions (for formal boundaries) and an LLM layer for everything else. The procedure registry starts with three to five ACL2-verified rules — the minimum fence that prevents catastrophic failure. The registry grows over time.
+
+Stage 3 — the host OS is replaced by a bare-metal Lisp image. No layers between the Gate and the hardware anymore. No kernel to attack, no MMU boundary, no syscall interface. The Gate is now the evaluator itself.
+
+Stage 4 — LLM inference moves into the Lisp process. No more API calls. The LLM becomes a function in the same address space. Token costs vanish. The autodidactic loop speeds up by orders of magnitude because every Gate decision can query the LLM without latency or cost.
+
+Stage 5 — neural weights are stored as plist-native data structures. The gap between symbolic and neural representations closes. The symbolic index and the neural index can cross-validate each other.
+
+Stage 6 — verified fine-tuning. Every weight update is Gate-checked against policy. The LLM itself is now subject to the same verification as everything else.
+
+Stage 7 — what remains: physical theft, electronic warfare, holes in the specification, LLM fallibility. Limits of computation.
+
+**How the Gate processes an action at Stage 2:**
+
+An action arrives — a shell command from the user, a proposal from the LLM, a message from the network. The action carries a domain tag determined by context (path prefix, network destination, entity cluster).
+
+First, the Gate checks the deductive layer. Does the action's domain have any registered ACL2-verified boundary procedures? If yes, check them one by one. If any denies, reject instantly. The LLM cannot overrule.
+
+If no verified procedure denies, the Gate checks with Screamer. Does a constraint network exist that resolves this question? Screamer has rules extracted by the LLM and corrected by humans — domain-specific constraints, rights, and prohibitions. If Screamer finds a resolution, apply it. Done.
+
+If Screamer has no matching constraint, the Gate asks the LLM. The LLM reasons about the action given its understanding of the domain — extracted from Org files, Wikipedia, regulations, and past corrections. The LLM proposes permit or deny. The Gate checks the proposal against the deductive layer boundaries again (defense in depth). If it passes, permit.
+
+The entire decision — action, context, which boundaries were checked, whether the LLM was invoked, what it proposed, what happened — is logged to the Gate's decision log.
+
+**How the Gate learns:**
+
+The autodidactic loop reads the decision log and looks for patterns:
+
+- If the LLM is frequently invoked for the same type of action, Screamer should get a new constraint to cover it. The LLM generates the constraint. Screamer adds it.
+
+- If the LLM made a mistake and was corrected, the correction is logged. Screamer's constraint network is updated. The mistake joins the hardening queue for ACL2.
+
+- If the Gate logged a kernel-level denial it didn't have a rule for, a syscall wrapper flagged it. The autodidactic loop proposes a new ACL2 boundary to replace the kernel's protection.
+
+- If a domain cluster shows high LLM utilization, the autodidactic loop asks the LLM to label it, registers it in the procedure registry with zero verified procedures, and starts tracking it as a distinct domain.
+
+The hardening queue is processed periodically. A conjecture is drafted for ACL2. The Prover runs it. If the proof passes, the new boundary function is compiled and added to the procedure registry. If the proof fails, the conjecture is refined or abandoned. The action stays under LLM authority.
+
+**How domains emerge:**
+
+The user writes notes in Org. The symbolic index extracts entities and relationships. Screamer's constraint network connects them. Over time, clusters form — entities that mention each other frequently and mention outside entities rarely. The Gate notices clusters where LLM utilization is high. It asks the LLM to label them: "This cluster deals with financial records. Shall I create a domain called accounting?" If the user confirms, the procedure registry gets a new tag. New actions matching the cluster get the tag. Verified procedures can now be registered under it.
+
+New domains start empty — no verified boundaries. The LLM has full provisional authority within the generic outer fence. As mistakes accumulate, ACL2 boundaries are written under the domain tag.
+
+**How the social protocol connects instances:**
+
+Every instance has a DID — a cryptographic identity it controls. Messages between instances are DIDComm: end-to-end encrypted, signed, tracked in a content-addressed DAG. The relay network delivers messages between instances that don't know each other's network addresses. The PDS stores the instance's identity documents, messages, and shared data.
+
+The social protocol is not a blockchain. DAG-based ordering handles causality. Delegable trust replaces proof of work.
+
+The compute marketplace extends this: instances can offer or purchase verified compute. A smart contract on the social protocol matches buyers to sellers, verifies execution against the buyer's Gate rules, and settles payment in protocol-native tokens.
+
+Liquid democracy extends it further: governance decisions are made by delegate-weighted voting, where any instance can delegate its vote to another instance, forming a delegation graph. The Gate enforces each instance's voting policy.
+
+**How the four commons map to the four subsystems:**
+
+- Common Lisp — the Environment subsystem. The address space contract, the evaluator, the Gate in the loop.
+- Common Law — the Social Protocol. Liquid democracy, delegable voting, governance.
+- Common Wealth — the Social Protocol. Compute marketplace, resource accounting, token settlement.
+- Common Sense — the Knowledge subsystem + the Gate. Propositions proposed by LLM, verified by Gate, stored in Org, indexed symbolically.
+
+**The autodidactic loop in full:**
+
+The autodidactic loop is the mechanism by which the system improves itself without human intervention. It runs continuously, at a configurable cadence:
+
+1. Read the decision log since the last run.
+2. Identify high-frequency patterns where the LLM was invoked.
+3. Propose Screamer constraints for the top patterns.
+4. Check the hardening queue for new ACL2 conjectures ready to prove.
+5. Check the adversarial probe results — did any probe reveal an unprotected boundary?
+6. Check the syscall wrapper logs — did the kernel deny anything the Gate missed?
+7. Propose new domain clusters if LLM utilization in a cluster exceeds a threshold.
+8. Run the Prover on pending conjectures.
+9. If proofs pass, compile and deploy new boundary functions.
+10. Log the cycle results.

projects/passepartout/architecture/distinguishing-features.org

@@ -0,0 +1,61 @@
+:PROPERTIES:
+:CREATED:  [2026-05-31 Sun]
+:ID:       d5c6e7f8-9a0b-1c2d-3e4f-5a6b7c8d9e0f
+:END:
+#+title: Distinguishing Features of the Passepartout Architecture
+#+filetags: :passepartout:architecture:
+#+STATUS: draft
+
+This is a working list of what distinguishes Passepartout's architecture from alternatives. Not final — still being refined.
+
+**1. Neurosymbolic (vs pure neural)**
+
+Not an LLM bolted onto a database. The system fundamentally bridges neural and symbolic representations, not as an integration layer but as a unified semantics.
+
+**2. Symbolic above neuro (vs other neurosymbolic architectures)**
+
+The Gate is the mechanism: an ACL2-verified deductive layer that is authoritative over the LLM. The LLM proposes actions, facts, and interpretations. The Gate decides. The LLM cannot overrule a verified denial. Most neurosymbolic systems are neural-dominated with symbolic afterthoughts; this inverts that hierarchy.
+
+**3. Org-mode data store + neural index + symbolic index**
+
+One file format for human and machine. The Org file is not a representation of the data — it IS the data. Both indices (neural embeddings for semantic search, symbolic assertions for formal reasoning) are derived views that can be rebuilt from the Org source. No translation layer, no schema migration, no vendor lock-in.
+
+**4. Wikipedia bootstraps general knowledge, LLM bootstraps specialized domains**
+
+General world knowledge seeds from structured sources (Wikidata, Wikipedia infoboxes) at minimal cost. Specialized domains (regulatory compliance, physics, medicine) are extracted by LLM from prose, then verified by the Gate. The bootstrapping is cheap and incremental, not a 24.5M-assertion Manhattan project.
+
+**5. Lisp and homoiconicity — one address space**
+
+Editor, shell, browser, and agent run in the same Lisp image. The Gate is in the evaluation loop itself, not interposed as an OS layer. There is no MMU boundary between components because there are no separate processes. No IPC, no kernel boundary to attack. The system verifies code at the level where code and data share representation.
+
+**6. Social protocol**
+
+Communication between instances is provable, not just encrypted. Every message is signed by a self-sovereign DID, tracked in a content-addressed DAG, optionally notarized.
+
+**7. Social network relies on: decentralization, cryptographic ID, payment layer, contracts**
+
+No central server, no platform dependency. Identity is cryptographic, not account-based. Payment and contracts are native to the protocol, not bolt-ons.
+
+**8. Unified social primer: the Note**
+
+A single primitive — the Note — serves as message, document, contract, vote, and identity claim. The social graph is built from Notes referencing Notes. No separate types for posts, transactions, or agreements.
+
+**9. Staged progression 0→7**
+
+Each stage is independently useful and fully functional. Stage 0 (current) runs conventional Linux with Hermes and gbrain. Stage 7 is custom silicon with the full verified stack. The migration is progressive component swap, not a cut-over. No stage requires the next stage to exist.
+
+**10. Self-modification / hot-reload (the autodidactic loop)**
+
+Because code and data share the same representation in a Lisp address space, the system can modify itself without restarting. The Gate monitors its own performance, proposes improvements, and applies them with verification. The system learns to be more secure, not just patched to fix CVEs.
+
+**11. Cost inversion (80% symbolic at near-zero marginal cost)**
+
+Symbolic reasoning is typically expensive (knowledge engineering, ontology maintenance). Passepartout inverts this: the LLM generates symbolic assertions cheaply, the Gate verifies them deductively, and the Org source stores them as a human-readable byproduct. The expensive part becomes the verification, which compounds with every use.
+
+**12. Potential revenue streams from Stage 1**
+
+The social protocol (Stage 1) enables paid services before the full stack is built — DID registration, relay node operation, PDS hosting, compute marketplace fees. Revenue starts flowing before the Gate exists as a software layer.
+
+**13. Dual growth strategies: social + institutional**
+
+Social growth: DID identity propagates through existing social graphs, messaging as the substrate, PDS self-hosted by friends. Institutional growth: compliance appliances sold to regulated industries, verification as a service, enterprise gate configurations. Neither is sufficient alone; both compound each other.

projects/passepartout/strategy/competitors/rainbird-ai-case-study.org

@@ -0,0 +1,111 @@
+:PROPERTIES:
+:CREATED:  [2026-05-31 Sun]
+:ID:       a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d
+:END:
+#+title: Rainbird AI — Comprehensive Case Study
+#+filetags: :passepartout:strategy:competitors:rainbird:
+#+STATUS: draft
+
+* Overview
+
+Rainbird Technologies Ltd is a UK-based AI company founded around 2015. It builds a commercial neurosymbolic decision intelligence platform — the closest existing product to Passepartout's Gate, but focused exclusively on enterprise policy decisioning rather than being a general-purpose verified computing environment.
+
+* The Three-Engine Architecture
+
+Rainbird's platform has exactly three engines, which map directly to Passepartout's architecture:
+
+1. **Language Engine** — an LLM that serves as the natural language interface. Users ask questions in English; the LLM translates them into symbolic queries. It also assists in building the knowledge graphs.
+
+2. **Neural Engine** — handles pattern recognition over unstructured data. Extracts entities, relationships, and uncertainties from documents and free text. Feeds into the knowledge graph.
+
+3. **Reasoning Engine** — a proprietary symbolic inference engine. This is the authoritative layer. It reasons deterministically over the knowledge graph, propagates uncertainties, and produces provably correct decisions with full audit trails.
+
+The hierarchy is symbolic-above-neural — the same architectural choice as Passepartout. The LLM translates and proposes; the reasoning engine decides.
+
+* Knowledge Graphs and Ontology
+
+This is the core of Rainbird's approach and the most relevant part for Passepartout.
+
+Rainbird calls their knowledge representations **"world models"** — deterministic graph-based structures that encode an organization's regulations, policies, and expert knowledge. The graph consists of:
+
+- **Entities** — the objects in a domain (Customer, Policy, Claim, Transaction, Provider)
+- **Relationships** — how entities connect (Customer has Policy, Policy covers Claim)
+- **Rules** — deterministic logic that governs decisions (If claim amount exceeds 10,000 AND policy type is basic, then flag for manual review)
+- **Uncertainty annotations** — Rainbird's engine natively propagates uncertainty through the graph rather than treating all facts as binary
+
+The graph is built in **Rainbird Studio**, a no-code visual environment. A fine-tuned LLM assists in construction: you describe your domain in natural language, the LLM proposes entities and rules, and a human expert reviews and approves them before they enter the graph. This is the critical difference from Passepartout's approach — Rainbird's knowledge base is human-curated, not self-hardened.
+
+Rainbird also supports:
+
+- **Version control** on world models
+- **Deployment control** across environments
+- **Collaborative building** — multiple experts can work on the same graph
+- **Testing and reporting** on graph accuracy
+
+* How a Decision Happens
+
+1. A user asks a question in natural language, or an automated process submits a query.
+2. The Language Engine (LLM) translates the question into a symbolic query against the knowledge graph.
+3. The Reasoning Engine walks the graph deterministically, applying rules, propagating uncertainties, and producing an answer.
+4. A proof tree is generated — every step of the reasoning is recorded, showing exactly which rules fired, which entities were consulted, and what uncertainties were propagated.
+5. The Language Engine translates the result and proof back into natural language for the user.
+
+Because the LLM never makes a decision — it only translates — there are zero hallucinations in the output. Every answer is traceable to a specific path through the knowledge graph.
+
+* Market Position
+
+**Customers and case studies:**
+
+- **EY** — automated data-privacy checks, turning a process from months to minutes, with every result fully explainable and auditable
+- **BDO** — cut R&D tax reviews from 5 hours down to seconds, helping advisors take on more clients with consistent decisions
+- **DACB (law firm)** — uncovered 800% more fraud 500% faster with full transparency into how every decision was made
+- **Killik & Co (financial advisory)** — client suitability checks in a fraction of the time, fully compliant with financial regulations
+- **NHS (UK National Health Service)** — COVID-19 risk assessments during the pandemic
+
+**Target sectors:** Banking and finance, insurance, tax and audit, healthcare, law, intelligent automation.
+
+**Positioning on the Gartner Hype Cycle for AI 2023:** Rainbird is the exemplar of **neurosymbolic AI**, listed under innovations that will be fueled by generative AI. Gartner positions neurosymbolic AI on the Slope of Enlightenment, meaning it is understood by early adopters and entering practical deployment.
+
+**Pricing model:** Rainbird is a proprietary SaaS platform sold through enterprise licensing. Pricing is not public, but given their customer profile (EY, BDO, NHS), it is in the tens-to-hundreds of thousands per year range for enterprise deployments. They also offer partner delivery models through their delivery partner network.
+
+* Architecture Comparison with Passepartout
+
+| Dimension | Rainbird | Passepartout |
+|-----------|----------|-------------|
+| Role | Decision engine (queried for answers) | Operating environment (gates every action) |
+| Architecture | Three engines: Language, Neural, Reasoning | Four subsystems: Environment, Knowledge, Verification (Gate), Social Protocol |
+| Authority | Symbolic engine is authoritative | ACL2-verified deductive layer is authoritative over LLM |
+| Knowledge format | Knowledge graphs built in Studio (human-curated) | Org files (human writes), indices derived (machine builds) |
+| Graph growth | Manual — human experts build and update in Studio | Automatic — autodidactic loop hardens from Gate decisions |
+| LLM role | Natural language translation only | Proposes actions, facts, interpretations; cannot overrule Gate |
+| Audit trail | Proof trees from reasoning engine | Full decision log from every Gate action |
+| Execution environment | Conventional cloud/SaaS | Lisp address space, bare metal at Stage 3+ |
+| Identity | User accounts in SaaS | Self-sovereign DID |
+| Social protocol | None | DIDComm, PDS, relay, compute marketplace, liquid democracy |
+| Openness | Proprietary, closed source | Designed to be open and self-hosted |
+| Autodidactic loop | None — models updated manually | Continuous — learns from decisions, probes, and kernel wrappers |
+| Pricing | Enterprise SaaS, undisclosed | Self-hosted free, hosted tier $10-30/mo |
+
+* Key Weaknesses and Gaps
+
+**No evaluation loop.** Rainbird is a system you query. It does not sit in the action path. It cannot prevent an action before it happens — it can only answer whether an action is compliant. This is the fundamental architectural difference. The Gate prevents; Rainbird advises.
+
+**No autodidactic loop.** Every rule in Rainbird's knowledge graph was written by a human in Studio. The system does not learn from its own decisions. It does not harden novel patterns into verified procedures. It remains permanently dependent on manual knowledge engineering.
+
+**No self-improvement.** Related to the above — Rainbird can never improve its own reasoning engine. If a new type of decision is needed, a human must add rules to the knowledge graph. Passepartout's Gate can propose new boundaries, have them verified by ACL2, and deploy them autonomously.
+
+**No identity layer.** Rainbird has no concept of a self-sovereign identity, DID, or personal data store. It authenticates through SaaS accounts. It cannot participate in a decentralized social protocol.
+
+**Proprietary and hosted.** Customers cannot audit the inference engine, cannot modify it, cannot run it on their own bare metal. They trust Rainbird's SaaS infrastructure. This limits deployment to enterprises that can accept a third-party SaaS dependency.
+
+**No operating environment.** Rainbird does not run your editor, shell, browser, or agent. It is a tool you consult, not a system you live in.
+
+* Implications for Passepartout
+
+**Validation.** Rainbird proves the market exists. Enterprises will pay significant sums for deterministic symbolic AI over a natural language interface. Every Rainbird case study — especially in regulated industries — validates the revenue model Passepartout targets for Stage 2.
+
+**Differentiation.** Rainbird's weaknesses are Passepartout's strengths. The autodidactic loop, the evaluation loop interposition, the social protocol, the Lisp address space, the self-hosted pricing — these are gaps in Rainbird's offering that Passepartout can exploit.
+
+**Patent risk.** Rainbird predates the Gate and weakens patent claims around the probabilistic-deterministic split in isolation. Passepartout's strongest patent position after Rainbird is the combination of all six differentiating elements — not just the split, but the autodidactic loop, Merkle memory, evaluation loop interposition, sufficiency criterion, and social protocol combined.
+
+**Knowledge graph lessons.** Rainbird's Studio-based knowledge graph construction is mature and proven in enterprise deployments. Passepartout should study their approach to entity modeling, rule representation, uncertainty propagation, and proof tree format. There is no need to reinvent the ontology layer from scratch.

projects/passepartout/strategy/hosting-economics.org

@@ -0,0 +1,152 @@
+:PROPERTIES:
+:CREATED:  [2026-05-31 Sun]
+:ID:       b2c3d4e5-f6a7-8b9c-0d1e-2f3a4b5c6d7e
+:END:
+#+title: Pass as a Service — Hosting Economics
+#+filetags: :passepartout:strategy:hosting:economics:
+#+STATUS: draft
+
+* Assumptions
+
+- Stage 2 instance: one SBCL Lisp process with Gate + PDS + environment in one address space
+- User brings own LLM API key — no AI token cost to the provider
+- Containerized: Docker image running on cloud VMs (AWS spot instances)
+- Instances are embarrassingly parallel — no cross-instance coordination
+
+* Unit cost per idle instance
+
+At rest: ~500 MB-1 GB RAM. Active peaks at 2-3 GB. CPU at rest negligible.
+
+* Packing density
+
+AWS r6a instances (AMD, good price-to-RAM):
+- r6a.4xlarge (128 GB RAM): ~$0.23/hr spot, ~80 instances per VM
+- r6a.8xlarge (256 GB RAM): ~$0.45/hr spot, ~160 instances per VM
+
+Cost per user per month at ~80 instances per 128 GB VM: ~$1.50 for compute.
+
+* Infrastructure cost breakdown (100K users)
+
+| Component | Detail | $/user/month |
+|-----------|--------|-------------|
+| Compute | r6a spot, 80 instances/VM | ~$1.50 |
+| Storage | 10 GB EBS gp3 per user | ~$0.80 |
+| Egress | Light protocol usage | ~$0.50 |
+| Relay | K8s, stateless web service | ~$0.50 |
+| **Infra subtotal** | | **~$3.30** |
+
+| Overhead | | |
+|----------|---|-------------|
+| Engineering | 4-5 people | ~$0.80-1.60 |
+| Support | 2-3 people | ~$0.40-0.80 |
+| **Overhead subtotal** | | **~$1.20-2.40** |
+
+| **Total** | | **~$4.50-5.70** |
+
+* Pricing and margin
+
+At $10/user/month:
+- Cost: ~$4.50-5.70/user/month
+- **Margin: 43-55%**
+
+* Scaling inflection points
+
+| Users | Provider cost/user/mo | Margin at $10/mo |
+|-------|---------------------|-----------------|
+| 1K | $25-40+ | Negative |
+| 10K | $8-12 | ~0-20% |
+| 50K | $5-7 | ~30-50% |
+| 100K | $4.50-5.70 | ~43-55% |
+| 1M | $2-4 | ~60-80% |
+
+10K-20K users is the crossover to positive unit economics. Below that, the team overhead dominates.
+
+* Cloud vs colo
+
+At small scale (under 10K users): AWS wins. No hardware risk, no colo contract, elastic.
+
+At large scale (100K+ users): Colo is 2-5x cheaper per instance. AWS premium comes from degraded packing density (hypervisor overhead, can't overcommit memory).
+
+Crossover at roughly 50K-100K users where dedicated ops justify colo.
+
+* Architecture
+
+Relay on Kubernetes (stateless web service, standard pattern). Instances are Docker containers on raw VMs — one container = one SBCL Lisp process + volume mount for PDS. No orchestration magic needed for the instance layer.
+
+The hardest operational problems: port mapping at scale (reverse proxy in front of VM pools) and PDS data persistence on VM failure (EBS snapshots or NFS-backed volumes).
+
+* Why this works
+
+Three things make the unit economics viable early:
+1. Zero AI token cost (user brings own API key)
+2. The Gate runs even without an LLM — caches common decisions, declines to reason when no key is configured. Not a degraded product, just a non-AI mode.
+3. Docker-on-large-VM packing recovers bare-metal packing density on cloud, avoiding per-instance overhead.
+
+* Addressable market
+
+**AI chat vs AI agents — orders of magnitude gap:**
+
+| Category | Users (Jun 2026) | Notes |
+|----------|-----------------|-------|
+| ChatGPT (chatbot) | 900M weekly active | Mostly text generation |
+| AI agent users (all tools) | 5-10M | Actions, tools, environment control |
+| Ratio | ~100:1 | Not 1000:1 as of mid-2026 |
+
+Agent users are 1% of chatbot users today. If agent adoption follows the same growth curve as chatbots but lags by 18-24 months:
+
+| Year | Est. agent users | 0.1% capture = users | MRR at $10/mo | Annual rev at 50% margin |
+|------|-----------------|--------------------|--------------|--------------------------|
+| 2026 | 5-10M | 5K-10K | $50K-100K | $300K-600K |
+| 2027 | 50-100M | 50K-100K | $500K-1M | $3M-6M |
+| 2028 | 300-500M | 300K-500K | $3M-5M | $18M-30M |
+
+This is conservative — 0.1% capture of the agent market, $10/month (no AI tokens included).
+
+Passepartout is not just an AI agent. It's a social protocol, verified computing environment, and knowledge system. It competes on more than agent UX. Even a fraction of the growing agent market funds the infrastructure.
+
+* Price ladder
+
+The most important constraint: the price users will bear must cover real infrastructure cost at whatever scale you're at. Two tiers solve for both growth and unit economics.
+
+**Self-hosted tier (growth engine):**
+- User downloads the image, runs on own hardware or $5-10/mo VPS
+- Brings own API key for LLM access
+- Provider cost: ~$0.50-1/user/month (relay + routing)
+- Zero per-user compute or storage cost to provider
+- Negative margin but negligible — scales to millions freely
+- This is the wedge: proves the protocol, builds the network, costs nothing to operate per user
+
+**Hosted tier (revenue engine):**
+- Provider-managed container, user brings API key
+- Packing density drives cost:
+  - At small scale (<5K hosted users): cost = $20-25/user/month
+  - At mature scale (50K+): cost = $5-7/user/month
+
+| Phase | Scale | Hosted cost/mo | Charged price | Margin |
+|-------|-------|---------------|---------------|--------|
+| Bootstrap | <5K | $20-25 | $25-30 | 10-20% |
+| Break-even | 5-20K | $10-15 | $20-25 | 40-50% |
+| Mature | 50K+ | $5-7 | $15-20 | 60-70% |
+| Commodity | 500K+ | $2-4 | $10-15 | 75-85% |
+
+**Pricing strategy:**
+- Never price below cost — ramp pricing down as infrastructure efficiency improves
+- First 5K hosted users are enthusiasts and early adopters who pay a premium ($25-30)
+- When costs drop below $10/user/month, you have room to price at $10-15 and open a much wider funnel
+- Self-hosted grows the network regardless of whether the hosted tier succeeds
+
+**What the price buys:**
+- Persistent Passepartout environment (shell, editor, browser, agent in one image)
+- Social protocol identity (DID, PDS, encrypted messaging)
+- The Gate verifying every action
+- Org data you own, in a format you own
+- AI tokens are NOT included — user brings own API key
+
+**Buyer profile:**
+- Already spends $10-200/month on LLM API keys
+- Values a verified, persistent environment over ephemeral chatbot sessions
+- Wants to own data and identity
+- Can't or won't self-host
+- Developer, researcher, or knowledge worker
+
+**The non-obvious constraint:** The addressable market at $25-30/month is narrower (0.1-0.5% of agent users) than at $10-15/month (1-5%). The hockey stick in user growth depends on infrastructure costs dropping far enough to price at consumer-friendly levels without burning capital.