diff --git a/ideas/growth-strategy.org b/ideas/growth-strategy.org new file mode 100644 index 0000000..9dc7986 --- /dev/null +++ b/ideas/growth-strategy.org @@ -0,0 +1,116 @@ +:PROPERTIES: +:ID: growth-strategy +:CREATED: [2026-05-23 Sat] +:END: +#+title: Growth — Zero to Billions Across Time Scales +#+filetags: :passepartout:growth:network:strategy: + +How the triad grows from zero instances to planetary infrastructure. Each phase is a qualitatively different growth regime, with its own customers, levers, and failure modes. + +The growth curve is logistic, not exponential from day one. Enterprise first (linear, high value per node), then developer-led (quadratic, moderate per node), then regulatory/insurance-driven (punctuated). The stacked network effects make each subsequent phase easier to scale than the previous one — but each phase must be solved /before/ the next can begin. + +* Phase 0 → 1: Zero to Enterprise (0 → 100 instances, 3-12 months) + +** 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. + +** How it works:** + +1. Ship the MVP ([[file:time-estimates.org]]) — a Passepartout that verifies code, applies gate rules, and produces a compliance report. +2. First sale is a compliance engagement: encode a regulation as gate rules, verify the customer's deployment, produce a report their auditor accepts. +3. Each engagement funds the next. Gate rule library grows with every customer. This compounds — each new regulation encoded is a product, not a project. +4. The compute marketplace ([[file:compute-marketplace.org]]) bootstraps with one provider (you) selling verification to smaller instances. No liquidity problem because you are both sides of the market initially. + +** Key metric:** Deployed instances. Gate package revenue. Regulations encoded. + +** Failure mode:** Wrong pricing. Too early for market. The compliance buyer exists but the product must replace an existing process, not add a new line item. + +** Phase 0 revenue:** $2M-$12M (from [[file:investment-thesis.org]]). Funds the team, keeps the lights on. + +* Phase 1: 1 to 10³ — Enterprise to Developer Ecosystem (100 → 10,000 instances, 12-24 months) + +** 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. The marketplace has supply. + +** How network effects kick in:** + +1. /Proof library compounding:/ Each new instance contributes edge cases to the regression suite ([[file:collective-regression-suite.org]]). Ten instances have a good proof library; a hundred have a great one; a thousand have a library no single organization could build alone. The curve is super-linear in instances. + +2. /Compute marketplace liquidity:/ 100+ instances means providers and consumers exist simultaneously. The marketplace can price verification in real time. No single instance needs to provision for peak load — they buy burst compute from the marketplace. + +3. /Attestation starts working:/ With 100+ instances, a track record of correct verifications carries weight. The attestation marketplace ([[file:agora-contracts.org]]) has enough data for reputation scores. The first insurance products become possible. + +** Revenue growth:** $10M-$50M. Verification appliances scale from project to program. Marketplace fees begin. Agora usernames ([[file:agora-usernames.org]]) start generating recurring revenue. + +** Key metric:** Third-party gate rules published. Marketplace monthly transaction volume. Active developer count. + +** Failure mode:** Developer adoption stalls because the AGPL experience is not polished enough. Gate rule SDK is too hard to use. This phase requires the most product attention — the first thousand developers must succeed. + +* Phase 2: 10³ to 10⁶ — Developer to Mainstream (10,000 → 1M, 2-5 years) + +** Customer:** Consumers + small businesses. PDS as a service ([[file:pds-as-a-service.org]]) becomes a consumer product. Agora usernames go mainstream. + +** Growth lever:** Consumer network effects. Each new PDS makes the Agora network more valuable. Each new user is a potential compute provider, gate rule buyer, and data licensor. + +** How it works:** + +1. /Stoa premium ([[file:revenue-hub.org]]) ships enterprise features./ SSO, compliance dashboards, fleet management. The enterprise buyer from Phase 1 upgrades from project to org-wide deployment. + +2. /Agora identity reaches critical mass./ Username registrations cross 100K. The namespace has value — short names are scarce. The auction market ([[file:agora-usernames.org]]) produces real revenue. + +3. /Compute marketplace hits density./ 1M+ instances means verification is ubiquitously available. Latency drops because there is always a provider within network distance. The marketplace transitions from /can I find a provider/ to /which provider gives the best price/. + +4. /Insurance marketplace forms./ With 10K+ instances and 2+ years of verifiable track records, actuaries can price proof insurance. The first products: /gate rule correctness insurance/ and /compute provider SLA insurance/. + +** Revenue growth:** $50M-$500M. Compute marketplace fees become the dominant revenue stream. PDS hosting at scale. Username registry renewals compound. + +** Key metric:** Agora identities. PDS count. Verified operations per day. Marketplace gross merchandise value. + +** Failure mode:** Consumer adoption requires UX polish the engineering team may deprioritize. The terminal-based Stoa works for developers but not for mainstream users. Qt integration (Stoa v2 from [[file:stoa.org]]) is the gating dependency. + +* Phase 3: 10⁶ to 10⁹ — Mainstream to Infrastructure (1M → 1B+, 5-15 years) + +** Customer:** Nation-states. Enterprises that cannot justify unverified infrastructure. Anyone who needs insurance. + +** Growth lever:** Regulatory mandate + insurance feedback loop. Verification is no longer a choice — it is a requirement for participation in the insured economy. + +** How the loop closes:** + +1. /Verification monopoly ([[file:verification-monopoly.org]]):/ The early player's gate library is the largest, most battle-tested, most cited. Regulators reference it. Insurers require it. A new entrant cannot replicate 10+ years of edge cases embedded in 1M+ instances. + +2. /Insurance lock-in:/ Insurers price unverified code out of existence. Premiums for unverified deployments are 10× or more. The cost of /not/ verifying exceeds the cost of adopting the triad. This is the insurance parallel to what happened with fire safety — buildings without sprinklers cannot get insured. + +3. /Nation-state adoption:/ The compute marketplace is a sovereign asset. Countries that run their own triad instances have verified digital sovereignty. Countries that do not are dependent on foreign verification infrastructure. The geopolitics are self-reinforcing (see [[file:triad-systemic-effects.org]]). + +** Revenue growth:** $1B+. Certification monopoly revenue. Infrastructure lock-in rent. Marketplace fees at global scale. Insurance underwriting profits. + +** Key metric:** Percentage of global compute running on verified stack. Number of nation-state triad deployments. Insurance premiums written against gate rules. + +** Failure mode:** Technology shift makes the approach obsolete. A fundamentally different verification paradigm (quantum proof systems, for example) could bypass ACL2. The installed base is a moat, not a guarantee. + +* Growth Curve Summary + +| Phase | Scale | Timeframe | Revenue | Primary lever | Failure mode | +|-------+-------+----------+---------+--------------+--------------| +| 0 | 0→100 | 3-12 mo | $2-12M | Enterprise sales | Wrong pricing, too early | +| 1 | 10²→10⁴ | 1-2 yr | $10-50M | Open source + SDK | Developer UX | +| 2 | 10⁴→10⁶ | 2-5 yr | $50-500M | Consumer network effects | UX polish gap | +| 3 | 10⁶→10⁹ | 5-15 yr | $1B+ | Regulation + insurance | Tech paradigm shift | + +Each phase's revenue funds the next. Phase 0 pays for the team. Phase 1 funds the product. Phase 2 builds the moat. Phase 3 is the end state. + +The network effects stack across phases: Phase 0's proof library makes Phase 1's marketplace valuable. Phase 1's developer ecosystem makes Phase 2's consumer product compelling. Phase 2's installed base makes Phase 3's regulatory capture possible. No phase can be skipped — and no phase guarantees the next. + +* References + +- [[file:time-estimates.org][Development timeline]] — the engineering underpinning +- [[file:revenue-hub.org][Revenue streams]] — what each phase sells +- [[file:investment-thesis.org][Investment thesis]] — the three revenue horizons +- [[file:triad-systemic-effects.org][Systemic effects]] — where this all leads +- [[file:compute-marketplace.org][Compute marketplace]] — the liquidity engine +- [[file:verification-monopoly.org][Verification monopoly]] — the end state moat +- [[file:agora-contracts.org][Agora contracts]] — attestation, insurance, governance +- [[file:collective-regression-suite.org][Collective regression suite]] — how proof libraries compound with scale +- [[file:infrastructure-lock-in.org][Infrastructure lock-in]] — why switching costs compound diff --git a/ideas/time-estimates.org b/ideas/time-estimates.org index da37da2..5d571ba 100644 --- a/ideas/time-estimates.org +++ b/ideas/time-estimates.org @@ -7,38 +7,34 @@ The orders-of-magnitude time framework ([[file:orders-of-magnitude-time.org][Orders of Magnitude — Time]]) 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 don't add linearly across orders of magnitude. +*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 orders of magnitude. -**Corrected estimate:** Two-phase approach with a clear middleground destination. +*Corrected estimate:* Two-phase approach with a clear middleground destination. ---- - -## Phase Zero — The MVP (Linux-hosted, ships real product) +* 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 [[file:sufficiency-flip.org][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 Stoa (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 | | Verification appliance CLI + Agora namespace | ~1,000 | API surface | Weeks | -**Total MVP: ~11,000 lines. Timeline: 1-3 months. Human review: ~20 hours.** +*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:** domain gate packages, verification appliance, compute marketplace. The MVP is a product, not a demo. +*Revenue model starts here:* domain gate packages, verification appliance, compute marketplace. The MVP is a product, not a demo. ---- - -## Phase End State — Full Lisp Machine (cannibalize the stack) +* Phase End State — Full Lisp Machine (cannibalize the stack) Replace Linux, replace C libraries, own the framebuffer, own the browser. This is the full [[file:self-driving-lisp-machine.org][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 | @@ -47,22 +43,20 @@ Replace Linux, replace C libraries, own the framebuffer, own the browser. This i | 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 | Stoa 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.** +*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's a years-scale project on its own. +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 +* 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 Stoa? | 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's 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. +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 [[file:investment-thesis.org][Investment thesis]] for the business case and [[file:cost-structure.org][Cost structure]] for the economics behind the verification-only-first approach. diff --git a/scripts/org-to-gbrain.py b/scripts/org-to-gbrain.py index 44c077f..9a74987 100644 --- a/scripts/org-to-gbrain.py +++ b/scripts/org-to-gbrain.py @@ -45,6 +45,7 @@ ROUTING = { "revenue-hub": "concepts", "agora-contracts": "concepts", "triad-systemic-effects": "concepts", + "growth-strategy": "concepts", "competitive-analysis-2026-05": "ideas", "passepartout-economics": "ideas", }