0a8e77e949
- 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
63 lines
5.8 KiB
Org Mode
63 lines
5.8 KiB
Org Mode
: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.
|