ideas: editorial sweep — atomization, interlinking, restructuring
- Split competitive-analysis-2026-05.org → TOC + 9 competitor files in ideas/competitors/. Dropped date from filename. All competitor UUIDs generated, TOC keeps original UUID for backlink continuity. - Deleted passepartout-economics.org archive (replaced by 27-node KB). - Inlined 5 'See also' blocks into natural prose (compliance-index, first-mover-window, revenue-table, orders-of-magnitude-time, native-org-knowledge-base). - Linked 7 orphan compliance pages back to compliance index + finished truncated sentences. - Linked all 14 Agora requirement docs from topic-relevant pages (identity→lisp-machine-security, infrastructure→compute-marketplace, social-space→growth-strategy, exchange→agora-contracts, etc.). - Linked ai-industry-impact from investment-thesis, sufficiency-flip, verification-appliance, effects-growth-flywheel (up from 1 to 10+ pages). - Fixed CREATED timestamps to use git commit dates instead of today. - Made all links absolute from root (no port inheritance). - Removed stale agora/docs/ duplicate content.
This commit is contained in:
Hermes
28
ideas/stoa/_index.org
Normal file
28
ideas/stoa/_index.org
Normal file
@@ -0,0 +1,28 @@
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: c3b3dc41-945f-54e9-84eb-ca014114f1be
|
||||
:END:
|
||||
#+title: Stoa — The Porch (Environment)
|
||||
#+filetags: :passepartout:stoa:editor:browser:hardware:
|
||||
|
||||
Stoa (Στοά) is the body/environment layer of the [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][triad]] — editor, browser, shell, and infrastructure all running in a single [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verified Lisp image]]. The [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Dispatcher gate stack]] verifies every action regardless of who initiated it. The distinction between "tool" and "self" dissolves.
|
||||
|
||||
The full roadmap is documented across seven stages on this page, each covering engineering, security, cost, timeline, and practical implications. Start reading from [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]].
|
||||
|
||||
The three layers of the triad:
|
||||
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Logos]] — the mind: recorded discourse, verified reasoning, the gate
|
||||
- Stoa — the porch: environment, infrastructure, the verified Lisp machine
|
||||
- [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] — the society: identity, communication, contracts
|
||||
|
||||
Key features across all stages:
|
||||
- **No kernel, no process boundaries, no memory corruption** — the verified Lisp evaluator is the only computation substrate
|
||||
- **Merkle-verified memory graph** — every object has a [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][structural hash]], composable proofs of integrity
|
||||
- **[[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate-stack authorization]]** — the Dispatcher is the only path to state mutation, verified in [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2]]
|
||||
- **Dual-unit ASIC** — symbolic core (tagged RISC-V) + tensor unit (cons-cell-native matmul), one chip, one proof
|
||||
- **In-process LLM inference** under [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate-level token interception]] — no API calls, no sandbox to escape
|
||||
- **Plist-native weights** — every weight Merkle-verified, provenance from training to inference
|
||||
- **[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Verified fine-tuning]]** — every gradient step authorized against policy, data consent per example
|
||||
- **Neural world model** (LeCun type) — sensory-physical prediction, falsified against the accumulated observation DAG
|
||||
- **Common sense** enters through three channels (LLM, world model, causal inference) and is brought under gate control through falsification
|
||||
|
||||
The ultimate goal is a [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][self-driving Lisp Machine]] running on custom dual-unit silicon.
|
||||
84
ideas/stoa/stoa-stage-0-now.org
Normal file
84
ideas/stoa/stoa-stage-0-now.org
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: Stage 0 — Now (Conventional Computing)
|
||||
type: reference
|
||||
tags: :stoa:roadmap:
|
||||
created: 2026-05-24
|
||||
---
|
||||
|
||||
← [[id:329a30cd-55fb-496d-a60b-91388c211bba][Stoa Index]] → [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]]
|
||||
|
||||
# Stage 0: Now
|
||||
|
||||
*Summary: The conventional stack as it exists today. Not a design — the starting point.*
|
||||
|
||||
This is the baseline we inherit. Linux on x86, C/Rust toolchain,
|
||||
web-based applications, GPU compute for AI, TCP/IP networking. Every layer
|
||||
is independently built and independently untrusted.
|
||||
|
||||
The conventional stack spans every layer:
|
||||
|
||||
| Layer | Threats |
|
||||
|-------+---------|
|
||||
| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] | silicon trojan, rowhammer, speculation side channels (spectre/meltdown), physical theft |
|
||||
| Firmware | UEFI implants, SMM rootkits, ME backdoor — unaccountable opaque processors |
|
||||
| OS kernel | privilege escalation, syscall bugs, driver exploits — CVEs weekly |
|
||||
| Compiler | Ken Thompson's "Trusting Trust" — compiler backdoors invisible at source level |
|
||||
| Runtime | heap corruption, use-after-free, buffer overflow — the dominant malware vector |
|
||||
| Network | MITM, TLS state machine bugs, DNS poisoning, routing attacks |
|
||||
| Application | XSS, SQLi, RCE, dependency chain attacks, supply chain |
|
||||
| User | phishing, social engineering, credential theft |
|
||||
| LLM (if present) | jailbreaks, prompt injection (unbounded space), data leakage in outputs, probabilistic unreliability |
|
||||
|
||||
**Key property:** Every layer is independent and untrusted. No layer can vouch
|
||||
for any other. Security is *empirical* — "no bugs found in this release" — not
|
||||
deductive.
|
||||
|
||||
## What is eliminated
|
||||
|
||||
Nothing. Every threat that has ever existed in computing exists at Stage 0.
|
||||
|
||||
## What does this cost?
|
||||
|
||||
- **Patching treadmill** — the industry spends uncountable hours applying CVEs.
|
||||
Every OS update risks regressions. Security teams are measured by mean time
|
||||
to detect, not mean time to prevent.
|
||||
- **Incident response** — breaches are expected, not exceptional. The average
|
||||
dwell time (attacker inside system before detection) is months.
|
||||
- **Bug bounties** — a market failure tax: pay researchers to find the bugs
|
||||
your toolchain inevitably produces.
|
||||
- **Complexity tax** — every OS, driver, library, and daemon is a potential
|
||||
entry point. The attack surface is unknowable because no layer can vouch
|
||||
for any other.
|
||||
- **No deductive guarantees** — security is empirical. "No bugs found in this
|
||||
release" does not mean no bugs exist.
|
||||
|
||||
Even with all this spending, the system is not provably secure. You can't
|
||||
audit your way to deductive guarantees on a conventional stack.
|
||||
|
||||
## What does this enable?
|
||||
|
||||
Everything we have. The entire software ecosystem, all hardware, every network.
|
||||
The cost and the capability are the same thing — maximum flexibility, minimum
|
||||
provable trust.
|
||||
|
||||
## When is this viable?
|
||||
|
||||
Today. This is where we are.
|
||||
|
||||
## In practice
|
||||
|
||||
We have normalized reactive security because the alternative — building a
|
||||
provably secure stack — is considered too expensive. Every company of
|
||||
meaningful size has a security team whose job is to detect when they've been
|
||||
breached, not to prevent it. The average dwell time is measured in months.
|
||||
This is treated as normal because the alternative — a provably secure stack —
|
||||
is seen as prohibitively expensive. This roadmap is the argument that the
|
||||
provable alternative is not only possible, but the inevitable destination.
|
||||
The question is not whether to build it, but at what pace.
|
||||
|
||||
← [[id:329a30cd-55fb-496d-a60b-91388c211bba][Stoa Index]] → [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]]
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 4a1f23b0-abc1-4def-9876-543210abcdef
|
||||
:END:
|
||||
85
ideas/stoa/stoa-stage-1-agora.org
Normal file
85
ideas/stoa/stoa-stage-1-agora.org
Normal file
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: Stage 1 — Agora (In-Transit Integrity)
|
||||
type: reference
|
||||
tags: :stoa:roadmap:agora:
|
||||
created: 2026-05-24
|
||||
---
|
||||
|
||||
← [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]]
|
||||
|
||||
# Stage 1: [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]]
|
||||
|
||||
*Summary: Every message is signed, DAG-tracked, and content-addressed.
|
||||
Communication becomes provable — when you choose it to be.*
|
||||
|
||||
## What is added
|
||||
|
||||
- DID-based identity per participant (Ed25519 key pairs)
|
||||
- Message-level authentication via JWE/JWS envelopes
|
||||
- DAG of content-addressed messages for auditable history
|
||||
- Channels for directed and broadcast communication
|
||||
- End-to-end encryption (Double Ratchet, MLS) with perfect forward secrecy
|
||||
- Ephemeral Notes via `ephemeral_duration` (time-locked encryption, key shedding, mandatory infrastructure GC)
|
||||
- Off-the-Record (OTR) mode bypassing PDS storage entirely (volatile client memory only, clients prohibited from recording)
|
||||
- Pseudonymous Personas for deniable identity
|
||||
- Relays as transient routers (pub/sub model, no long-term storage)
|
||||
- Onion routing between PDSs for metadata masking
|
||||
|
||||
## What is eliminated
|
||||
|
||||
- **Message forgery** — every message is signed; you prove the sender
|
||||
- **Message tampering in transit** — envelopes are authenticated; tampering changes the CID and breaks the chain
|
||||
- **Impersonation / spoofing** — DID identity keys, not usernames
|
||||
- **Replay attacks** — nonces and sequence numbers per message
|
||||
- **MITM on Agora-mediated channels** — end-to-end signatures; relays need no trust
|
||||
- **Loss of message history** — DAG is append-only and content-addressed
|
||||
|
||||
## What does this cost?
|
||||
|
||||
- **Crypto overhead per message** — every message requires signing and verification.
|
||||
For high-throughput channels, this adds latency and CPU cost
|
||||
- **DAG storage grows unbounded** — the append-only log never shrinks unless GC
|
||||
is explicitly designed
|
||||
- **Key management burden** — DID resolution, key rotation, revocation. Lost keys
|
||||
mean lost identity. No "reset password" for DIDs
|
||||
- **No anonymous participation by default** — DIDs tie every message to a
|
||||
cryptographic identity. Pseudonymity is a Persona choice, not the baseline
|
||||
|
||||
## What does this enable?
|
||||
|
||||
Provable communication infrastructure. You can prove who said what, when, and
|
||||
to whom — or choose off-the-record privacy. Every subsequent stage builds on
|
||||
this DAG: it is the source of truth for evidence, audit, and the accumulated
|
||||
knowledge that later stages use for falsification.
|
||||
|
||||
## When is this viable?
|
||||
|
||||
Today. Agora is a protocol design that can be deployed on existing networks.
|
||||
The infrastructure (PDS, Relay, Gateway) runs on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]].
|
||||
|
||||
## In practice
|
||||
|
||||
Communication becomes provable — but only when the user chooses. Agora's Note
|
||||
primitive supports the full spectrum: persistent DAG-stored messages for audit
|
||||
and compliance, ephemeral Notes that self-destruct, and full Off-the-Record
|
||||
(OTR) mode that bypasses PDS storage entirely.
|
||||
|
||||
The user chooses per-channel or per-message: permanent and attributable for
|
||||
contracts and governance, ephemeral and deniable for private conversation. The
|
||||
infrastructure enforces each choice — PDS garbage-collects expired CIDs, Relays
|
||||
drop them from routing tables, clients shed message keys after display. Agora
|
||||
replaces trust with evidence where evidence is wanted; elsewhere it provides
|
||||
privacy by design.
|
||||
|
||||
Agora does not secure the endpoint. The machines running Agora clients can
|
||||
still be compromised at the OS, compiler, or hardware level. The keys are on
|
||||
those machines — malware that compromises an endpoint can sign messages using
|
||||
the endpoint's keys. The messages are authentic; the sender wasn't. Agora
|
||||
carries the authorization; it doesn't evaluate it.
|
||||
|
||||
← [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]] → [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]]
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 4a1f23b0-abc2-4def-9876-543210abcdef
|
||||
:END:
|
||||
84
ideas/stoa/stoa-stage-2-logos.org
Normal file
84
ideas/stoa/stoa-stage-2-logos.org
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: Stage 2 — Logos (Verified Reasoning Layer)
|
||||
type: reference
|
||||
tags: :stoa:roadmap:logos:
|
||||
created: 2026-05-24
|
||||
---
|
||||
|
||||
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]]
|
||||
|
||||
# Stage 2: [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Logos]]
|
||||
|
||||
*Summary: A verified gate evaluates every action against formal policy.
|
||||
Capability-based authorization. "Root" as an attack target no longer exists.*
|
||||
|
||||
## What is added
|
||||
|
||||
- [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2-verified]] gate functions that evaluate every proposed action
|
||||
- [[id:c34940cc-090e-57c4-8020-e78b1d32b96c][Capability-based authorization]]: every action requires a token, not an identity
|
||||
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate]] checks every action — from user, agent, or external message — against:
|
||||
- Is the action authorized by policy?
|
||||
- Does the capability grant this operation?
|
||||
- Does the action violate any system invariant?
|
||||
- Decision procedure formalized in ACL2, machine-checked
|
||||
- Gate runs as a decision layer on the conventional host (Stage 0 [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]])
|
||||
|
||||
## What is eliminated
|
||||
|
||||
- **Unauthorized actions** — even a fully compromised endpoint cannot perform an
|
||||
action the gate blocks. The gate is the final arbiter, not the OS or client.
|
||||
- **Privilege escalation** — no amount of subversion below the gate can grant
|
||||
capabilities the policy doesn't allow. The gate checks capability tokens,
|
||||
not caller identity.
|
||||
- **"Root" as a meaningful attack target** — there is no root in Logos. There
|
||||
are capabilities, and capabilities are checked.
|
||||
|
||||
## What does this cost?
|
||||
|
||||
- **Verification latency** — every action is checked against policy. Complex
|
||||
policies add delay
|
||||
- **Policy formalization burden** — everything must be written explicitly. Gaps
|
||||
block legitimate actions (false positives) or allow undesirable ones (false
|
||||
negatives). There is no [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Common Sense]] fallback — the policy cannot rely on
|
||||
unformalized human intuition. Everything must be written down
|
||||
- **Capability management complexity** — distributing, revoking, auditing
|
||||
capabilities is itself security-critical. A leaked capability is
|
||||
indistinguishable from an authorized action
|
||||
- **Policy drift** — as the system evolves, the policy must evolve with it.
|
||||
Out-of-date policy blocks new legitimate uses
|
||||
- **Proof maintenance** — the gate's decision procedure is verified, but the
|
||||
policy is not. Each policy change needs new proof
|
||||
- **The gate runs on untrusted hardware** — if the OS or hardware is
|
||||
compromised, the gate's guarantees are meaningless. The attacker can skip
|
||||
the gate or modify its output. Logos's full power arrives at Stage 3
|
||||
|
||||
## What does this enable?
|
||||
|
||||
The system can now say "no" to unauthorized actions even when the endpoint is
|
||||
fully compromised. Security is no longer dependent on client integrity. This is
|
||||
the first layer where deductive guarantees enter the picture — but they are
|
||||
contingent on Stage 3's trust substrate.
|
||||
|
||||
## When is this viable?
|
||||
|
||||
Today as a software layer on conventional hardware, but with limited guarantees
|
||||
(the gate itself can be compromised by the host OS). Full power arrives at
|
||||
Stage 3 when the gate runs on the verified Lisp machine.
|
||||
|
||||
## In practice
|
||||
|
||||
The gate is the final arbiter, not the OS or the client. But it runs on a
|
||||
machine it doesn't trust. Users must weigh the benefit (unauthorized actions
|
||||
blocked) against the operational cost (everything must be explicitly authorized
|
||||
in policy). For high-stakes environments, the trade-off is worth it. For casual
|
||||
use, the friction may lead users to bypass the gate.
|
||||
|
||||
*Logos's full power arrives when it runs on Stoa. Before that, it's a
|
||||
correctness proof running on an untrusted substrate.*
|
||||
|
||||
← [[id:4a1f23b0-abc2-4def-9876-543210abcdef][Stage 1 — Agora]] → [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]]
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 4a1f23b0-abc3-4def-9876-543210abcdef
|
||||
:END:
|
||||
134
ideas/stoa/stoa-stage-3-stoa.org
Normal file
134
ideas/stoa/stoa-stage-3-stoa.org
Normal file
@@ -0,0 +1,134 @@
|
||||
---
|
||||
title: Stage 3 — Stoa (Verified Infrastructure)
|
||||
type: reference
|
||||
tags: :stoa:roadmap:
|
||||
created: 2026-05-24
|
||||
---
|
||||
|
||||
← [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]] → [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]]
|
||||
|
||||
# Stage 3: Stoa
|
||||
|
||||
*Summary: The [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][verified Lisp machine]]. One image, one [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][memory graph]], one [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][gate stack]].
|
||||
No kernel, no process boundaries, no memory corruption. [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] and Logos are no
|
||||
longer separate components — they are properties of the same machine.*
|
||||
|
||||
## What is added
|
||||
|
||||
Stoa spans three engineering phases that converge on the same architecture:
|
||||
|
||||
### Phase A — Software emergence (2-3 years)
|
||||
|
||||
The Lisp machine emerges inside a host OS. A single SBCL image absorbs every
|
||||
user interface into one address space:
|
||||
|
||||
- **Lish editor:** a multi-threaded Common Lisp editor via Qt/QML (EQL5).
|
||||
The agent's system prompt lives in an Org buffer — visible, editable,
|
||||
hot-reloadable. Org-babel for inline evaluation. The editor IS the daemon.
|
||||
- **Nyxt browser:** Common Lisp web browser in three erosion stages:
|
||||
Qt+WebKit → S-expression DOM → pure Lisp layout. Web content is natively
|
||||
queryable and modifiable as Lisp data structures.
|
||||
- **Lish shell:** text-stream replaced by plists. Pipe becomes function
|
||||
composition. Scripts become Lisp functions on memory objects.
|
||||
- **Emacs migration (three phases):** parasite bridge (v0.4.0) → ELisp
|
||||
compatibility layer inside CL image → native CL implementations.
|
||||
- **Minibuffer:** universal command surface — edit files, navigate web,
|
||||
run Lisp expressions, invoke agent commands.
|
||||
|
||||
### Phase B — Cannibalization (3-5 years)
|
||||
|
||||
Gradual replacement of every external dependency with native Lisp:
|
||||
|
||||
- TCP bridge → internal function call (single SBCL image)
|
||||
- QML layout → Lisp layout (Yoga FFI as intermediate)
|
||||
- WebKit → Lisp DOM + Lisp-native layout engine
|
||||
- Qt widgets → Lisp-native X11/Wayland bindings
|
||||
- Font rendering → HarfBuzz FFI → Lisp replacement
|
||||
- Qt event loop → SBCL native thread scheduler
|
||||
- Linux bootloader → Stage0 Lisp bootstrap (500 bytes hex → self-hosting Lisp)
|
||||
|
||||
The system remains usable at every step. Each replacement is a component swap.
|
||||
|
||||
### Phase C — [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] (5-10 years)
|
||||
|
||||
The dual-unit ASIC: one chip, two compute units, one Merkle-verified memory graph:
|
||||
|
||||
1. **Symbolic core** — tagged RISC-V (4-8 type tag bits per word, hardware
|
||||
type checking, single-cycle LISP.CAR/LISP.CDR). Runs gate stack, cognitive
|
||||
loop, general Lisp evaluation.
|
||||
2. **Tensor unit** — cons-cell-native matrix compute. Walks the tensor DAG
|
||||
directly for attention and matmul. No FFI boundary, no GPU mirror.
|
||||
|
||||
Prototyping: TinyTapeout (130nm, 8-bit tagged toy) → FPGA core (DE10-Nano,
|
||||
VexRiscv) → FPGA tensor (Xilinx VU9P, cons-cell matmul) → shuttle (12nm,
|
||||
tagged RISC-V at 100-300MHz) → ASIC (5nm, both units on die).
|
||||
|
||||
Phase migration: parasitic FPGA PCIe card → functional hijacking → driver
|
||||
cannibalization → self-hosting (Stage0 on bare metal).
|
||||
|
||||
Hardware GC: dedicated Scavenger bus master runs GC in parallel with symbolic
|
||||
and tensor computation. Persistent NVRAM: boot to exactly where you left off.
|
||||
|
||||
## What is eliminated
|
||||
|
||||
- **Memory corruption entirely** — verified Lisp evaluator, no undefined
|
||||
behavior. No buffer overflow, use-after-free, type confusion.
|
||||
- **OS kernel exploitation** — no kernel. Evaluator is the substrate. No
|
||||
syscalls, no drivers, no MMU to confuse.
|
||||
- **Compiler backdoors** — Lisp-to-Lisp compilation within the verified
|
||||
evaluator. [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Ken Thompson's "Trusting Trust"]] is structurally impossible.
|
||||
- **Malware / viruses / worms** — no "download and execute" path that bypasses
|
||||
the gate. The evaluator only runs objects in the verified memory graph.
|
||||
- **Supply chain at binary level** — every object has a Merkle chain to its
|
||||
origin. A dependency is a pointer, not a file.
|
||||
- **The Stoa ↔ Logos ↔ Agora composition problem** — one address space, one
|
||||
semantics, one proof. The interface between them is an internal relationship.
|
||||
|
||||
## What does this cost?
|
||||
|
||||
- **Lisp tax on everything** — verified execution is 2-10x slower than
|
||||
optimized C on equivalent hardware. Symbolic core is designed to minimize
|
||||
this; tensor unit sidesteps it for neural compute
|
||||
- **No backward compatibility** — existing software doesn't run on Stoa. No
|
||||
Linux binaries, no x86 drivers, no GPU compute stacks (without mirror path)
|
||||
- **Single address space fragility** — no process isolation. A bug in the
|
||||
editor can corrupt the browser. One crash radius, one machine
|
||||
- **Massive engineering investment** — shortest plausible timeline to a usable
|
||||
software Lisp machine is 2-3 years; ASIC 5-10 years
|
||||
- **Ecosystem abandonment** — no open-source packages, no shared libraries.
|
||||
Everything is in the Merkle memory graph or it doesn't exist
|
||||
|
||||
## What does this enable?
|
||||
|
||||
Deductive security replaces empirical security. Memory bugs — the dominant
|
||||
attack vector for decades — are structurally eliminated. No more patching for
|
||||
CVEs. No ASLR, no DEP, no CFI — the class of attacks they mitigate doesn't
|
||||
exist. Every boot is a fresh verification that the evaluator, memory graph,
|
||||
and gate stack are intact.
|
||||
|
||||
## When is this viable?
|
||||
|
||||
- **Software (Phase A+B):** 2-3 years on existing hardware. Single SBCL image,
|
||||
gate stack, Lish/Nyxt/Lish — usable on a developer workstation today.
|
||||
- **ASIC (Phase C):** 5-10 years. FPGA prototype within 1-2 years, shuttle
|
||||
within 3-5, commercial foundry 5-10.
|
||||
|
||||
## In practice
|
||||
|
||||
Memory bugs — the dominant attack vector for decades — are structurally
|
||||
eliminated. No more patching for CVEs. No antivirus, no firewall (at the
|
||||
machine level — network boundaries remain). A Stoa machine that boots
|
||||
correctly will not crash from a memory corruption bug, ever.
|
||||
|
||||
But you've given up the entire existing software world. You cannot run Firefox,
|
||||
Postgres, nginx, Python, or any Linux binary. The machine is a Lisp machine
|
||||
and everything must be written in Lisp. The practical trade is: absolute
|
||||
memory safety at the cost of adopting an entirely new computing paradigm.
|
||||
This is not an upgrade path — it is a replacement.
|
||||
|
||||
← [[id:4a1f23b0-abc3-4def-9876-543210abcdef][Stage 2 — Logos]] → [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]]
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 4a1f23b0-abc4-4def-9876-543210abcdef
|
||||
:END:
|
||||
95
ideas/stoa/stoa-stage-4-inference.org
Normal file
95
ideas/stoa/stoa-stage-4-inference.org
Normal file
@@ -0,0 +1,95 @@
|
||||
---
|
||||
title: Stage 4 — Inference (In-Process LLM)
|
||||
type: reference
|
||||
tags: :stoa:roadmap:
|
||||
created: 2026-05-24
|
||||
---
|
||||
|
||||
← [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]] → [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]]
|
||||
|
||||
# Stage 4: Inference
|
||||
|
||||
*Summary: The LLM runs in-process under the gate. Every token is inspected
|
||||
during generation. No external API, no separate trust domain.*
|
||||
|
||||
## What is added
|
||||
|
||||
- CFFI binding to llama.cpp (or pure-Lisp inference engine) — LLM in the same
|
||||
SBCL image as the agent, editor, and gate
|
||||
- [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][Gate-level token interception]]: the Dispatcher inspects every partial token
|
||||
sequence during generation. Trajectories that would produce unauthorized
|
||||
actions are suppressed mid-stream, not filtered after the fact
|
||||
- Weights loaded from Stoa's Merkle-verified store as a macro-tag blob (one
|
||||
tagged Lisp object pointing to flat binary)
|
||||
- Deterministic inference: same input, same output, same hash — auditable
|
||||
and replayable
|
||||
|
||||
*Two neural components on the same substrate:* Stage 4 hosts the LLM for
|
||||
generative reasoning and action proposals. The LeCun-type world model (sensory
|
||||
prediction) joins at Stage 6. Both run on the same tensor unit with the same
|
||||
plist-native weight architecture and gate-level interception. The LLM proposes
|
||||
actions to the gate (authorization — binary, deductive). The world model
|
||||
proposes predictions to the gate (falsification — structural, empirical). The
|
||||
gate handles both through different procedures.
|
||||
|
||||
## What is eliminated
|
||||
|
||||
- **LLM as a separate trust domain** — no external server, no API call, no
|
||||
cloud provider to breach
|
||||
- **Remote inference model attacks** — the model cannot be swapped without
|
||||
changing the Merkle hash
|
||||
- **Prompt injection as an action bypass** — the gate sees partial generation.
|
||||
A jailbreak that would produce an unauthorized action is caught before the
|
||||
tokens complete
|
||||
- **Model integrity ambiguity** — you know exactly which model is running,
|
||||
at which commit, with which hash
|
||||
|
||||
## What does this cost?
|
||||
|
||||
- **~10x compute, RAM, and storage** — the gate evaluates semantics at every
|
||||
token, not just logits. A model running at 50 tok/s natively runs at ~5 tok/s
|
||||
under gate-level interception
|
||||
- **GPU/accelerator constraints** — CFFI to GPU libraries is the bottleneck.
|
||||
Exotic [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] may not be supported
|
||||
- **Memory pressure** — the LLM shares the address space with the entire system.
|
||||
A 70B param model at 4-bit takes ~35GB. At 10x multiplier, effective
|
||||
conventional-equivalent cost is ~350GB
|
||||
- **Determinism is double-edged** — auditable but cannot adapt or creatively drift
|
||||
- **No model parallelism** — Stoa runs on one machine. Frontier-scale models
|
||||
may be too large for a single address space
|
||||
|
||||
## What does this enable?
|
||||
|
||||
Action proposals from the LLM are intercepted by the gate before they reach
|
||||
the system. The gate authorizes or denies in real time based on policy, not
|
||||
on trust in the LLM. This eliminates the entire class of "LLM escaped its
|
||||
sandbox" attacks.
|
||||
|
||||
## When is this viable?
|
||||
|
||||
- **Server hardware (A100/H100 class, 512GB+ RAM):** today. 5 tok/s on 7B
|
||||
models is usable for chat
|
||||
- **Consumer hardware (RTX 5090 class):** 3-5 years
|
||||
- **On ASIC tensor unit:** the 10x overhead drops closer to 2-5x because the
|
||||
gate runs on the symbolic core in parallel with inference on the tensor unit
|
||||
|
||||
## In practice
|
||||
|
||||
The LLM is no longer a black box connected by API. The gate watches every
|
||||
token as it's generated and can stop any generation trajectory that would
|
||||
produce an unauthorized action. The model is powerful; the gate is in control.
|
||||
|
||||
Chat is noticeably slower — roughly 5 tok/s instead of 50 — but the security
|
||||
guarantee is structural, not probabilistic. For bulk processing or real-time
|
||||
applications, the 10x tax may be prohibitive without dedicated acceleration.
|
||||
|
||||
The weights are still a verified *blob* — you know the file's hash but can't
|
||||
prove anything about individual weights. Training provenance is not tracked.
|
||||
The inference is FFI-mediated, so trust in llama.cpp remains.
|
||||
|
||||
← [[id:4a1f23b0-abc4-4def-9876-543210abcdef][Stage 3 — Stoa]] → [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]]
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 4a1f23b0-abc5-4def-9876-543210abcdef
|
||||
:END:
|
||||
88
ideas/stoa/stoa-stage-5-weights.org
Normal file
88
ideas/stoa/stoa-stage-5-weights.org
Normal file
@@ -0,0 +1,88 @@
|
||||
---
|
||||
title: Stage 5 — Weights (Plist-Native)
|
||||
type: reference
|
||||
tags: :stoa:roadmap:
|
||||
created: 2026-05-24
|
||||
---
|
||||
|
||||
← [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]] → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]
|
||||
|
||||
# Stage 5: Weights
|
||||
|
||||
*Summary: Every weight is a [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Lisp object in the Merkle memory graph]]. You can
|
||||
prove not just that the model file is unmodified, but that this specific
|
||||
attention head has the weight vector it should have.*
|
||||
|
||||
## What is added
|
||||
|
||||
- Plist-native weight graph: weights are typed plists structured as a tree of
|
||||
tensors DAG, not a flat blob
|
||||
- Structural weight diffs: the response to "which weight changed?" is "layer 17,
|
||||
head 3, weights 2048-4096 differ by vector V" — not "the blob hash changed"
|
||||
- Weight provenance chain: the memory graph links each layer to its training
|
||||
event. A structural property of the weights, not a log entry about them
|
||||
- No FFI boundary for inference: the tensor unit (or GPU mirror) operates on
|
||||
Lisp objects directly. The evaluator's verified semantics cover computation
|
||||
|
||||
## What is eliminated
|
||||
|
||||
- **Sub-tensor granularity tampering** — you can verify individual attention
|
||||
heads, not just the blob
|
||||
- **Weight provenance ambiguity** — every weight links to its origin event
|
||||
- **The FFI inference gap** — inference runs on Lisp data directly. No C/GPU
|
||||
code outside the evaluator's semantics
|
||||
|
||||
## What does this cost?
|
||||
|
||||
- **~100x compute, RAM, and storage on conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]] (GPU path).**
|
||||
A 7B model requiring 4GB as GGUF needs ~400GB as plist-native weights on a
|
||||
GPU. GPUs are built for flat arrays and SIMT; cons-cell traversal is their
|
||||
worst case
|
||||
- **This 100x is GPU-relative, not fundamental.** An ASIC tensor unit with
|
||||
tagged memory, Merkle hashing in the memory controller, and sparse DAG-
|
||||
walking matmul closes the gap to 2-5x
|
||||
- **Two implementation paths:**
|
||||
1. *GPU path (near-term):* plist-native weights as gold standard for
|
||||
provenance, GPU-native mirror for compute, Merkle-verifiable loading
|
||||
protocol. Cost: 100x storage, ~2-3x load-time overhead
|
||||
2. *ASIC path (destination):* tensor unit speaks cons-cell. No mirror
|
||||
needed. Cost: 2-5x over GPU for dense matmul
|
||||
- **GC pressure** — plist-native weights produce enormous GC load. The
|
||||
Scavenger handles this on ASIC; on GPU path the mirror avoids it
|
||||
- **Mixed-precision is complex** — 4-bit and 8-bit quantization destroy
|
||||
pointer structure. Full float32/64 may be the only practical option
|
||||
|
||||
## What does this enable?
|
||||
|
||||
You can prove exactly what your model is and that it hasn't been modified.
|
||||
The Merkle chain from training event to individual weight is structural, not
|
||||
logged. Fine-tuning provenance becomes as verifiable as the code running on
|
||||
the machine. This is the stage where hardware choice determines practical
|
||||
viability.
|
||||
|
||||
## When is this viable?
|
||||
|
||||
- **GPU hybrid path:** today. Works on any Stoa system with a GPU
|
||||
- **ASIC native path:** 5-10 years (tensor unit on the dual-unit chip)
|
||||
|
||||
## In practice
|
||||
|
||||
Every individual weight is Merkle-verified, structurally tracked, and computed
|
||||
within the Lisp evaluator's verified semantics. The FFI trust gap is closed.
|
||||
|
||||
Stage 5 is where hardware choice determines practical viability. The GPU path
|
||||
works today but carries the storage overhead of two representations (plist gold
|
||||
standard + GPU mirror) and the load-time verification cost. The ASIC path is
|
||||
the destination — one representation, one chip, no workaround. Most users will
|
||||
use the GPU path for years before the ASIC becomes available.
|
||||
|
||||
Either path is viable. The GPU path can be built today with existing hardware.
|
||||
The ASIC path is the destination — a single verified chip that doesn't need
|
||||
the hybrid workaround.
|
||||
|
||||
← [[id:4a1f23b0-abc5-4def-9876-543210abcdef][Stage 4 — Inference]] → [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 4a1f23b0-abc6-4def-9876-543210abcdef
|
||||
:END:
|
||||
124
ideas/stoa/stoa-stage-6-training.org
Normal file
124
ideas/stoa/stoa-stage-6-training.org
Normal file
@@ -0,0 +1,124 @@
|
||||
---
|
||||
title: Stage 6 — Training (Verified Fine-Tuning + World Model)
|
||||
type: reference
|
||||
tags: :stoa:roadmap:
|
||||
created: 2026-05-24
|
||||
---
|
||||
|
||||
← [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]] → [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Stage 7 — Remaining]]
|
||||
|
||||
# Stage 6: Training
|
||||
|
||||
*Summary: Verified fine-tuning under the gate. Every example checked for consent.
|
||||
Every gradient application is a verified state transition. The neural world model
|
||||
runs in parallel with the LLM for sensory-physical prediction.*
|
||||
|
||||
## What is added
|
||||
|
||||
### Verified fine-tuning
|
||||
|
||||
The training loop is not a script. It is a verified function in the evaluator:
|
||||
|
||||
1. Read a training example from the [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][memory graph]]
|
||||
2. Check the example's authorization tag against [[id:45ea493b-94ad-5885-aa65-0c846e5c3c1d][policy]]
|
||||
3. Compute the gradient
|
||||
4. Check gradient constraints (permitted weights, bounded LR, scope limits)
|
||||
5. Apply the update
|
||||
6. Record the state transition with a Merkle link to the input
|
||||
|
||||
### The neural world model (LeCun type)
|
||||
|
||||
A second neural network runs on the tensor unit alongside the LLM. It predicts
|
||||
sensory and physical dynamics — object trajectories, scene evolution, low-level
|
||||
sensor futures. It shares the same plist-native weight architecture and the
|
||||
same verified training pipeline:
|
||||
|
||||
- **Domain:** physical world prediction (not social — that belongs to the
|
||||
accumulated knowledge DAG)
|
||||
- **Training:** imported from conventional [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware]]. Pretrain elsewhere,
|
||||
verify import, fine-tune under gate
|
||||
- **Gate interaction:** the world model proposes predictions to the gate
|
||||
("the ball will land at position X"). The gate falsifies predictions against
|
||||
the accumulated observation DAG after the fact, tracking calibration over
|
||||
time. This is verification through falsification, not authorization
|
||||
|
||||
### The interaction at Stage 6
|
||||
|
||||
1. World model predicts sensory outcome: "user will press button in 2 seconds"
|
||||
2. LLM reasons about the predicted outcome: "if user presses button, C follows"
|
||||
3. LLM proposes action to gate: "preempt C"
|
||||
4. Gate checks policy + accumulated knowledge for similar past scenarios
|
||||
5. Gate authorizes or denies
|
||||
6. After outcome occurs, gate falsifies world model's prediction against actual
|
||||
observation, updating calibration score
|
||||
|
||||
## What is eliminated
|
||||
|
||||
- **Data poisoning** — every training example is authorized before gradient
|
||||
application. Only data tagged with consent is trainable
|
||||
- **Unauthorized fine-tuning** — training policy specifies scope (layers, LR,
|
||||
data tags) and the gate enforces all constraints at every step
|
||||
- **Malicious checkpoint injection** — no checkpoints. Training is a verified
|
||||
sequence of continuous state transitions
|
||||
- **Training-time backdoors** — the optimizer function is verified by hash.
|
||||
A Trojan optimizer fails the gate check because its identity doesn't match
|
||||
|
||||
## What does this cost?
|
||||
|
||||
- **~100x slower than conventional fine-tuning** — building on Stage 5's 100x
|
||||
overhead (GPU path) plus verified gate checks per example. A LoRA fine-tuning
|
||||
that takes 2 hours natively takes ~200 hours. Doable overnight, not for rapid
|
||||
iteration
|
||||
- **Storage per training step** — every Merkle-tracked state transition adds
|
||||
to the memory graph. A fine-tuning run could produce hundreds of terabytes
|
||||
of deltas
|
||||
- **Only fine-tuning is practical** — full pretraining on Stoa never makes
|
||||
sense. The 100x overhead is structural. Practical workflow: pretrain on
|
||||
conventional GPU cluster → import as verified blob → convert to plist-native
|
||||
under gate → fine-tune in Stoa
|
||||
- **Data gate latency** — every training example passes through the
|
||||
authorization gate. For datasets with millions of examples, this pre-
|
||||
processing step can take days
|
||||
- **Wrong-spec for training policy** — the training policy is the most
|
||||
security-critical spec. A compromised admin writing a policy that authorizes
|
||||
all layers and all data defeats the system through its own verification
|
||||
|
||||
## What does this enable?
|
||||
|
||||
You can train on private data with proof of consent per example. The fine-tuning
|
||||
history is structural, not logged — every gradient step is Merkle-linked to its
|
||||
input. The world model gives the system sensorimotor common sense: object
|
||||
persistence, trajectory prediction, basic physics — grounded in this specific
|
||||
environment's observations.
|
||||
|
||||
## When is this viable?
|
||||
|
||||
- **Fine-tuning (GPU path):** 3-5 years on server hardware
|
||||
- **World model:** same timeline — shares the pipeline and tensor unit
|
||||
- **ASIC native:** when tensor unit silicon arrives (5-10 years)
|
||||
|
||||
## In practice
|
||||
|
||||
Training integrity is guaranteed at every step. Data consent is verified per
|
||||
example. The optimizer cannot be swapped. Checkpoints cannot be backdoored.
|
||||
But this system is not for training frontier models — it is for auditing
|
||||
training runs that happen elsewhere.
|
||||
|
||||
The practical workflow is: pretrain on a conventional GPU cluster, import the
|
||||
weights into Stoa as a verified blob (Stage 4), then fine-tune within Stoa
|
||||
under the verified training loop. The pretraining phase remains unverified,
|
||||
but the fine-tuning phase — where the model gains knowledge of private data
|
||||
and user preferences — is verified. This is the pragmatic sweet spot.
|
||||
|
||||
The world model learns your environment's physics — how your voice sounds,
|
||||
how your face moves when confused, how quickly you respond to different
|
||||
message types. The gate falsifies its predictions, so the world model
|
||||
converges toward accurate beliefs about your world, not the statistical
|
||||
average of the internet.
|
||||
|
||||
← [[id:4a1f23b0-abc6-4def-9876-543210abcdef][Stage 5 — Weights]] → [[id:4a1f23b0-abc8-4def-9876-543210abcdef][Stage 7 — Remaining]]
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 4a1f23b0-abc7-4def-9876-543210abcdef
|
||||
:END:
|
||||
171
ideas/stoa/stoa-stage-7-remaining.org
Normal file
171
ideas/stoa/stoa-stage-7-remaining.org
Normal file
@@ -0,0 +1,171 @@
|
||||
---
|
||||
title: Stage 7 — What Remains
|
||||
type: reference
|
||||
tags: :stoa:roadmap:
|
||||
created: 2026-05-24
|
||||
---
|
||||
|
||||
← [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]
|
||||
|
||||
# Stage 7: What Remains
|
||||
|
||||
*Summary: At full maturity — dual-unit ASIC, plist-native weights, verified
|
||||
fine-tuning, neural world model — the following irreducible threats survive.
|
||||
None can be eliminated by computation alone.*
|
||||
|
||||
## 1. Physical threats
|
||||
|
||||
| Threat | Mitigation | Cost |
|
||||
|--------|-----------|------|
|
||||
| Theft | Tamper-resistant packaging (mesh sensors, zeroization on opening) | 10-100x packaging cost |
|
||||
| EMP | Write-once checkpoint recovery | Mid-transaction data at risk |
|
||||
| [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][Hardware]] trojan in fabrication | Independent fab runs + trace comparison | 2x fab cost minimum |
|
||||
| Power/EM side channels | Constant-power design, shielding | Power overhead |
|
||||
|
||||
Physical hardening is expensive in direct proportion to the threat level.
|
||||
If someone steals your Stoa machine, they have your data. Hardware hashing
|
||||
and encryption slow them down, but the security boundary is now physical.
|
||||
|
||||
## 2. Side channels in the verified model
|
||||
|
||||
The system is functionally correct but may leak information through timing
|
||||
channels (unless the spec explicitly models timing as an output), access-
|
||||
pattern channels (verified gates enforce authorization but not non-interference),
|
||||
and the crypto-verification tension (proving constant-time is a different proof
|
||||
from proving functional correctness).
|
||||
|
||||
Closing side channels requires 2-4x the verification effort for crypto routines
|
||||
and oblivious RAM overhead for memory access. Feasible for security-critical
|
||||
code, impractical for the entire system. For LLM inference, this means an
|
||||
attacker on the same machine could determine which tokens were generated by
|
||||
measuring computation time — an open research problem.
|
||||
|
||||
## 3. Oracle poisoning
|
||||
|
||||
The system reasons perfectly about a world that may not exist:
|
||||
|
||||
- **Time** — a clock that can be wrong (NTP drift or attack). The machine
|
||||
cannot verify which time source is correct
|
||||
- **DNS / network routing** — BGP hijack reroutes traffic. Cryptographic
|
||||
envelopes survive, but traffic goes to the wrong destination
|
||||
- **Sensors / physical input** — the machine processes correctly; the sensor
|
||||
may be compromised
|
||||
- **User input** — the single most dangerous oracle. A user who authorizes a
|
||||
malicious action bypasses every security guarantee. The system is secure;
|
||||
the user was wrong
|
||||
|
||||
Oracle diversity reduces surface area but introduces Byzantine agreement
|
||||
problems. The question at Stage 7 shifts from "can the attacker break the
|
||||
crypto?" to "can the attacker convince the user to press the button?"
|
||||
|
||||
## 4. The bootstrap axiom
|
||||
|
||||
- **Hardware** — silicon correctness cannot be proved from within the system
|
||||
- **[[id:84a537b4-4256-50c8-91f5-dd5b4538418f][ACL2 kernel]]** — ~500 lines of Lisp accepted, not proved
|
||||
- **Stage-0 bootstrap** — 500-byte hex sequence, readable by a human in an
|
||||
afternoon, not mechanically verified
|
||||
|
||||
This is the Godelian boundary of the system. Any attack that modifies the
|
||||
bootstrap is undetectable from within. Detection requires physical inspection
|
||||
by a trusted external party. For any real-world threat model, this is not the
|
||||
weakest link — the user's Wi-Fi password is far more likely to be compromised.
|
||||
|
||||
## 5. The gap between specification and intent
|
||||
|
||||
- **Wrong spec** — the system is provably correct with respect to its formal
|
||||
spec. If the spec is wrong, the system is correct and wrong
|
||||
- **Incomplete invariants** — every invariant must be explicitly formalized.
|
||||
There is no Common Sense fallback (see Appendix A). The most dangerous gaps are unknown ones
|
||||
- **Emergent failures** — two individually correct operations can produce a
|
||||
catastrophic result in combination
|
||||
|
||||
The verified system is perfectly correct about the wrong thing. This is the
|
||||
same class of failure as "the software compiled without warnings and crashed
|
||||
in production" — but instead of debugging a crash, you are debugging a formal
|
||||
specification that may take weeks to analyze.
|
||||
|
||||
## 6. The world outside the system
|
||||
|
||||
- **Lying peers** — a peer with a valid DID can give dishonest answers
|
||||
- **Legal compliance** — a provably correct drug transaction is still illegal
|
||||
- **Coercion / duress** — the user can be compelled to authorize actions. The
|
||||
gate faithfully records the authorization
|
||||
|
||||
These externalities cannot be addressed within the system. Any attempt (duress
|
||||
mode, silent alert) expands the threat model.
|
||||
|
||||
## Appendix A: Common Sense
|
||||
|
||||
**Common sense is the set of generalized expectations about how the world works
|
||||
that are not derived from specific observations within a particular system.**
|
||||
That a chair is for sitting. That promises create expectations. That people
|
||||
contacted at 3am are likely to be annoyed.
|
||||
|
||||
These are distinct from the accumulated knowledge in the [[id:1c95ce7d-a2db-506a-9608-df68f9ae211b][Merkle DAG]], which records
|
||||
specific observations. Common sense is the *generalization engine*.
|
||||
|
||||
**Three channels in the Stoa architecture:**
|
||||
|
||||
| Channel | Origin | Verification | Granularity |
|
||||
|---------|--------|-------------|-------------|
|
||||
| LLM pretraining | Internet-scale corpus | None (probabilistic, distributed) | Vast but opaque |
|
||||
| World model (LeCun) | Sensory observations + training | Falsified against accumulated DAG | Physical dynamics |
|
||||
| Causal inference on accumulated knowledge | This system's DAG | Merkle-linked to evidence | Precise but bounded |
|
||||
|
||||
**The falsification loop brings common sense under gate control:**
|
||||
|
||||
1. LLM proposes a common-sense belief: "users don't like being contacted at 3am"
|
||||
2. The world model formalizes it into a causal edge with a confidence weight
|
||||
3. The gate queries the accumulated DAG: "how many 3am messages were
|
||||
well-received in this user's history?"
|
||||
4. If the evidence confirms, it enters the structural knowledge store
|
||||
5. If contradictory, the gate rejects it and the LLM must revise
|
||||
|
||||
Over time, common sense that matches this specific user's world becomes
|
||||
structural knowledge. The system converges toward beliefs aligned with the
|
||||
user's actual environment, not the statistical average of the internet.
|
||||
|
||||
Common sense is never fully formalized and never fully trusted. It always
|
||||
remains probabilistic, the LLM's domain, subject to falsification. The gate
|
||||
does not "have" common sense. It gates access to the structural knowledge
|
||||
store for beliefs that survive falsification.
|
||||
|
||||
## Appendix B: Summary table of eliminated threats
|
||||
|
||||
| Threat | Eliminated at stage |
|
||||
|--------|---------------------|
|
||||
| Memory corruption | 3 — Stoa |
|
||||
| OS exploitation | 3 — Stoa |
|
||||
| Malware / viruses / worms | 3 — Stoa |
|
||||
| Compiler backdoors | 3 — Stoa |
|
||||
| Message forgery / tampering | 1 — [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] |
|
||||
| MITM on communication | 1 — Agora |
|
||||
| Unauthorized actions | 2 — Logos (fully at 3) |
|
||||
| Prompt injection bypassing gate | 4 — In-process inference |
|
||||
| Weight tampering (blob level) | 4 — Verified blob hash |
|
||||
| Weight tampering (fine-grained) | 5 — Plist-native weights |
|
||||
| Data poisoning / unauthorized training | 6 — Verified training + world model |
|
||||
| Physical theft / EMP | Survives to 7 |
|
||||
| Side channels | Survives to 7 (specification gap) |
|
||||
| Oracle poisoning | Survives to 7 (ground truth gap) |
|
||||
| Wrong spec / human error | Survives to 7 (intent gap) |
|
||||
| Bootstrap axiom | Survives to 7 (Gödelian boundary) |
|
||||
| External coercion / law | Survives to 7 (not solvable by computation) |
|
||||
|
||||
The system ends up deductively secure inside a physically and oracularly
|
||||
bounded envelope. That envelope — the chip, the world, the user — is the
|
||||
only remaining attack surface worth worrying about.
|
||||
|
||||
Every security guarantee in this document has a price. The question is not
|
||||
"is this secure?" but "is the price worth it for the threat model it
|
||||
eliminates?" For a personal AI that holds private conversations and manages
|
||||
keys, Stages 1-4 may be enough. For a financial system that settles billions,
|
||||
Stages 5-6 justify the overhead. The progressive threat model is also a
|
||||
progressive cost-benefit analysis — know the price, then decide.
|
||||
|
||||
← [[id:4a1f23b0-abc7-4def-9876-543210abcdef][Stage 6 — Training]]
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 4a1f23b0-abc8-4def-9876-543210abcdef
|
||||
:END:
|
||||
44
ideas/stoa/stoa-vision-roadmap.org
Normal file
44
ideas/stoa/stoa-vision-roadmap.org
Normal file
@@ -0,0 +1,44 @@
|
||||
---
|
||||
title: Stoa Vision Roadmap — The Porch
|
||||
type: reference
|
||||
tags: :reference:architecture:stoa:
|
||||
created: 2026-05-24
|
||||
---
|
||||
|
||||
→ [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]]
|
||||
|
||||
Stoa (Στοά) is the body/environment layer of the [[id:d71df46b-9012-433c-86ce-ec21b78eac5f][triad]]:
|
||||
|
||||
| Logos | The mind — recorded discourse (memex + agent) |
|
||||
| Stoa | The porch — editor, browser, shell, infrastructure |
|
||||
| [[id:1d074690-a279-59cb-b91d-e9a22ae104ad][Agora]] | The society — identity, communication, contracts |
|
||||
|
||||
The name comes from the Stoa Poikile (Painted Porch) in ancient Athens,
|
||||
where Zeno taught Stoic philosophy. The porch was not the philosophy
|
||||
itself — it was the environment that made discourse possible. Stoa is
|
||||
the same: not the agent, not the network, but the infrastructure that
|
||||
hosts both.
|
||||
|
||||
The roadmap and threat model are merged into a single document.
|
||||
Each stage covers: what is added, what threats are eliminated, what it
|
||||
costs, what it enables, when it is viable, and what it means in practice.
|
||||
Appendices at the end cover common sense, the bootstrap axiom, and a
|
||||
summary table of eliminated threats.
|
||||
|
||||
| Stage | Delivers | Key cost | Timeline |
|
||||
|-------+----------+----------+----------|
|
||||
| [[id:4a1f23b0-abc1-4def-9876-543210abcdef][0 — Now]] | Baseline: conventional computing | Patching treadmill, no deductive guarantees | Today |
|
||||
| [[id:4a1f23b0-abc2-4def-9876-543210abcdef][1 — Agora]] | Communication integrity, provable DAG | Crypto overhead, key management | Today |
|
||||
| [[id:4a1f23b0-abc3-4def-9876-543210abcdef][2 — Logos]] | Verified gate, capability auth | Policy formalization burden | Today (limited) |
|
||||
| [[id:4a1f23b0-abc4-4def-9876-543210abcdef][3 — Stoa]] | Lisp machine, Merkle memory, no kernel | Lisp tax, no backward compat, single address space | 2-5yr (soft) / 5-10yr (ASIC) |
|
||||
| [[id:4a1f23b0-abc5-4def-9876-543210abcdef][4 — Inference]] | In-process LLM, token interception | ~10x compute/RAM/storage | Server now; consumer 3-5yr |
|
||||
| [[id:4a1f23b0-abc6-4def-9876-543210abcdef][5 — Weights]] | Plist-native weights, weight-level provenance | ~100x GPU / ~2-5x ASIC | GPU hybrid now; ASIC 5-10yr |
|
||||
| [[id:4a1f23b0-abc7-4def-9876-543210abcdef][6 — Training]] | Verified fine-tuning, neural world model | ~100x fine-tuning only | 3-5yr fine-tuning |
|
||||
| [[id:4a1f23b0-abc8-4def-9876-543210abcdef][7 — Remaining]] | Physical threats, oracles, speculation, bootstrap axiom | Mitigations are non-computational | Forever |
|
||||
|
||||
→ [[id:4a1f23b0-abc1-4def-9876-543210abcdef][Stage 0 — Now]]
|
||||
|
||||
:PROPERTIES:
|
||||
:CREATED: [2026-05-24 Sun]
|
||||
:ID: 3f24ad65-0845-4e75-a3d7-dc4de734a6ac
|
||||
:END:
|
||||
Reference in New Issue
Block a user