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.

ideas/lisp-machine-security.org

@@ -1,16 +1,17 @@
 :PROPERTIES:
+:CREATED:  [2026-05-24 Sun]
 :ID:       1c95ce7d-a2db-506a-9608-df68f9ae211b
 :END:
 #+title: Lisp Machine Security — Unified Memory Threat Model
 #+filetags: :passepartout:security:lisp-machine:pmp:isolation:
 
-On a bare metal [[file:self-driving-lisp-machine.org][Lisp Machine]] with a unified Lisp image, the defense-in-depth provided by the OS kernel disappears. The gate stack and the code it protects share a single address space. An attacker who exploits a memory corruption in the browser renderer can modify the gate stack's permission tables, the policy engine's state, or the ACL2 prover's decision output. There is no kernel underneath to catch them.
+On a bare metal [[id:13e6ae54-2d24-5aa0-b1cd-a7e8e749aa70][Lisp Machine]] with a unified Lisp image, the defense-in-depth provided by the OS kernel disappears. The gate stack and the code it protects share a single address space. An attacker who exploits a memory corruption in the browser renderer can modify the gate stack's permission tables, the policy engine's state, or the ACL2 prover's decision output. There is no kernel underneath to catch them.
 
 This note analyzes the threat model and proposes a hardware-enforced privilege separation within the single Lisp image.
 
 **The problem**
 
-In the conventional layered model (Linux + SBCL + Passepartout), there is defense in depth. Even if the gate stack has a bug, Linux provides seccomp, namespaces, file permissions, and process isolation as a safety net. If SBCL segfaults, the kernel catches it.
+In the conventional layered model (Linux + SBCL + [[id:28c46769-c14b-42aa-ac7a-69d310157f8f][Passepartout]]), there is defense in depth. Even if the gate stack has a bug, Linux provides seccomp, namespaces, file permissions, and process isolation as a safety net. If SBCL segfaults, the kernel catches it.
 
 On a bare metal Lisp Machine, the model collapses:
 
@@ -21,7 +22,7 @@ Everything (agent, editor, browser, shell, gate stack, ACL2)
 
 The only protection is that the gate stack is verified by ACL2 to be correct. But ACL2 verification is static — it proves properties about source code. At runtime, a memory corruption in the same image invalidates the entire proof. "All defense is symbolic" is exactly right.
 
-**The solution: [[file:verification-appliance.org][hardware-enforced privilege zones]] within the Lisp image**
+**The solution: [[id:84a537b4-4256-50c8-91f5-dd5b4538418f][hardware-enforced privilege zones]] within the Lisp image**
 
 RISC-V provides three hardware privilege levels: M-mode (machine), S-mode (supervisor), and U-mode (user). Physical Memory Protection (PMP) enforces access control at the hardware bus level — it cannot be bypassed by software, even by code running in S-mode if configured in M-mode. The key: use these mechanisms to create zones within the shared Lisp address space.
 
@@ -82,7 +83,7 @@ ACL2 trust problem. ACL2 verifies the gate stack. But ACL2 itself is ~50,000 lin
 
 The conventional Linux approach: TCB is ~28 million lines of C across kernel, drivers, and runtime. Defense in depth from many layers. But each layer adds attack surface.
 
-The Lisp Machine approach: TCB is ~2,500 lines of verified Lisp (M-mode gate core + S-mode gate stack). Attack surface is ~500 lines of ECALL handler. The TCB is roughly 10,000x smaller. This security advantage creates [[file:moats.org][moats]] — a competitor would need to match both the hardware isolation and the verified codebase.
+The Lisp Machine approach: TCB is ~2,500 lines of verified Lisp (M-mode gate core + S-mode gate stack). Attack surface is ~500 lines of ECALL handler. The TCB is roughly 10,000x smaller. This security advantage creates [[id:aa6d062e-a520-5d14-8773-00687ed9c689][moats]] — a competitor would need to match both the hardware isolation and the verified codebase.
 
 The fundamental trade: fewer layers, less depth, but each layer is simpler, smaller, and verified. A bug in the ECALL handler is catastrophic. A bug in the Linux kernel might be contained by seccomp or namespaces. The question is which is more likely: a bug in 500 lines of verified Lisp, or a bug in 28 million lines of C that is not contained by the remaining depth?
 
@@ -92,7 +93,7 @@ But this is a single-point-of-failure architecture. If the ECALL handler holds,
 
 **Gaps in the current design**
 
-None of this is in the architecture documents. The following are not yet specified — these architectural innovations are potential candidates for [[file:patent-strategy.org][patent strategy]]:
+None of this is in the architecture documents. The following are not yet specified — these architectural innovations are potential candidates for [[id:caaeee11-ba6f-5566-aecd-f171b4c459c0][patent strategy]]:
 
 1. PMP region layout — exactly what is protected and by which region
 2. ECALL handler specification — the exact interface, request types, validation logic, and error handling
@@ -102,4 +103,6 @@ None of this is in the architecture documents. The following are not yet specifi
 6. Side-channel mitigation — speculation control, timing attacks
 7. ACL2 trust documentation — the bootstrap chain and what it means for the gate stack's verification
 8. The boot attestation protocol — how the gate core verifies the gate stack before loading it
-9. Zone transition costs — how many cycles does an ECALL take, and does that affect the 10-80-10 ratio
+9. 
+See the [[id:6fe67db6-25bd-4d11-bd1d-b44ec809e858][Agora Identity specification]] for how user identity, key derivation, and DID management integrate with the gate stack's boot chain and privilege zones.
+ — how many cycles does an ECALL take, and does that affect the 10-80-10 ratio