Restructure three-pronged → knowledge-layers: collapse 11 files to 3, integrate into main architecture

- Rename 'three-pronged' folder to 'knowledge-layers' — prong metaphor
  was misleading (implied parallel tines), replaced with epistemic layers
  (deductive base, empirical middle, probabilistic oracle — vertical stack)
- Collapse 11 overlapping files into 3 coherent documents:
  - knowledge-layers/_index.org: core framework (two engines + one store,
    World Model formula, 0-14 layer table, provenance store design,
    conflict resolution, cold-start, stage mapping)
  - knowledge-layers/practical-implications.org: design-world-aware-of-
    physics, 10 powers, Schafmeister existence proof, epistemic transparency
  - knowledge-layers/neurological-empirical.org: neural networks in
    provenance framework (kept intact)
- Relocate wolfram/mathematica and Schafmeister docs to ideas/viability/
- Integrate into main architecture _index.org:
  - Gate: expanded from two vectors (ACL2+LLM) to three (deductive,
    provenance/empirical, LLM oracle)
  - Autodidactic loop: split into Track 1 (deductive hardening, fast)
    and Track 2 (empirical validation, slow, experimental-feedback-driven)
  - See also: added Knowledge Layers cross-reference
- Add all-lisp geometry engine note (ideas/lisp-geometry-engine.org) as
  concrete illustration of the empirical layer's effect on design work
- Rebuild site: 148 files, 0 errors

ideas/lisp-geometry-engine.org

@@ -0,0 +1,174 @@
+:PROPERTIES:
+:CREATED:  [2026-05-11 Mon]
+:END:
+---
+type: idea
+title: All-Lisp Geometry Engine
+created: '2026-06-04T00:00:00.000Z'
+tags:
+  - APM
+  - CAD
+  - CAM
+  - UX
+  - architecture
+  - constraint-solving
+  - design-tools
+  - empirical
+  - gaming
+  - geometry-engine
+  - lisp
+  - provenance
+  - three-pronged
+---
+
+A unified Lisp geometry engine built on the three-pronged model — the
+constraint kernel IS the physics, and the design world is aware of its own
+physics by default because the system won't let you produce a design that
+violates physical constraints without flagging it.
+
+This is Ivan Sutherland's Sketchpad vision (1963), fully realized: the
+drawing IS the program, the constraints ARE the physics, and the system
+solves them in real-time — across CAD precision, game rendering, and UX
+layout — from one kernel in one address space.
+
+---
+
+**The three prongs, applied to the geometry engine.**
+
+The three-pronged architecture (deductive proofs / provenance-tracked
+empirical models / probabilistic oracle, under one gate) is not an abstract
+epistemological framework. It maps directly onto what a design tool needs.
+
+**Prong 1 — deductive: the constraint solver.**
+
+The geometry kernel IS deductive mathematics. When the solver determines
+that four points are coplanar, or that an edge is tangent to a cylinder at
+exactly 5mm offset, it is computing a deductive consequence of the
+constraint system. The formulas for intersection, tangency, and spatial
+relationships are formal geometry. ACL2 could verify them. The constraint
+network is a theorem: the set of all poses that satisfy the specified
+relations. Solving it is proving the theorem.
+
+**Prong 2 — empirical: provenance-tracked material properties.**
+
+This is the prong that changes design work fundamentally. Currently, design
+software pretends material properties are true numbers. You pick "steel"
+from a dropdown and see Young's modulus = 200 GPa. But that 200 GPa is an
+average across 50 samples from different suppliers at different batch runs.
+The actual value for your specific part is between 190 and 210 GPa, and the
+software never tells you.
+
+With provenance-tracked empirical models, every parameter in the constraint
+network carries its epistemic status: measured from a specific experiment,
+fitted to a published dataset, extrapolated beyond validation with a
+confidence penalty, or guessed because no data exists. The provenance store
+holds the source chain, validity envelope, and confidence interval for every
+parameter. The constraint solver propagates uncertainty automatically.
+
+The consequence: the designer designs to a distribution, not a platonic
+number. The clearance at a joint shows as 0.03-0.08mm, not 0.05mm flat.
+Material selection becomes a query with confidence thresholds, not a
+dropdown. Tolerance stack-up falls out of provenance automatically. The
+finished design carries a confidence budget: "Confidence this meets
+specification under rated load: 95%. Material parameter uncertainty
+contributes 3%, manufacturing tolerance contributes 1.5%."
+
+The validity envelope constrains what the designer can even specify. You try
+to design a seal for 500C operation. The provenance store says: the
+empirical model for this material is validated to 300C. Above that, the only
+data is a single 1973 paper with a 2x extrapolation factor and no confidence
+interval. The gate flags it. The designer must explicitly accept the risk
+(logged to the provenance chain with a signature) or select a material with
+better empirical coverage.
+
+Manufacturing feedback closes the loop. The part is made, as-manufactured
+dimensions are measured, the real friction coefficient is recorded. These
+values write back to the provenance store. The next design iteration has
+tighter confidence intervals because it incorporates production data.
+Datasheet revisions propagate retroactively: a bearing manufacturer revises
+load rating downward, the provenance store updates, the gate re-checks all
+existing designs and flags: "Your coupling assumed 5kN from the 2022
+datasheet. The 2025 revision shows 4.2kN. Safety margin is now below
+required threshold."
+
+**Prong 3 — probabilistic: the LLM as constraint explorer.**
+
+The LLM proposes constraint system structures: "Here's a four-bar linkage
+with these initial parameters." The solver validates deductively. The LLM
+diagnoses failures: "The solver can't converge because constraint A and
+constraint B conflict — the offset exceeds available column space given the
+pivot locations." The LLM proposes alternatives; the solver checks.
+
+The LLM handles what cannot be formalized: model selection (which force
+field for this molecule class?), interpretation (why did the simulation
+fail?), creative generation (suggest a design that meets these spec limits).
+The gate ensures the LLM proposes only — it never executes.
+
+---
+
+**One representation, all domains.**
+
+The same constraint kernel drives engineering (CAD/CAM — float64, micron
+precision, batch solve), gaming (float32, 144fps, iterative solve), and UX
+layout (pixel-aligned, 120fps, layout constraints). CLOS dispatch selects
+the solver backend based on the precision context and frame deadline. The
+constraint language is the same; the solver varies by domain.
+
+Lisp macros generate optimized inner loops from the constraint DSL — typed,
+inlined, unstyled — that SBCL compiles to within 2x of C. The hot path
+narrowphase runs as native code, not through generic function dispatch.
+
+---
+
+**Origin: Drexler's APM community and Godot.**
+
+The motivation came from Eric Drexler's atomically precise manufacturing
+community, which wanted to use Godot as a molecular machine design suite. A
+game engine provides exactly what molecular nanotechnology design requires:
+real-time 3D, constraint-based physics, collision detection, and interactive
+spatial editing. But Godot's C++/GDScript substrate has no provenance
+tracking, no validity envelopes, and no epistemic awareness. A Lisp geometry
+engine on the three-pronged architecture provides what the APM design suite
+needs: the constraint kernel ensures geometric consistency (deductive), the
+provenance store tracks force field parameters and validity envelopes
+(empirical), and the LLM proposes molecular machine designs guided by
+physical constraints (probabilistic).
+
+---
+
+**Computational feasibility.**
+
+- CAD: feasible today on SBCL. Float64 is native, no frame deadline, CLOS
+  dispatch at design scale (thousands of constraints, not millions).
+- UX layout: feasible today. 2D constraints at 120fps with moderate scene
+  complexity.
+- Gaming at 144fps: needs Stage 3 hardware (tagged RISC-V, hardware GC,
+  geometry accelerators). CLOS dispatch overhead and GC tail latency on
+  commodity hardware consume too much of the 6.9ms frame budget for AAA
+  scene complexity.
+- The LLM-guided constraint search (prong 3) makes the symbolic approach
+  tractable at assembly scale — the LLM proposes, the solver validates,
+  successful patterns cache as deductive rules.
+
+---
+
+**Connection to Passepartout's three-pronged architecture.**
+
+The three-pronged section of the architecture describes "two reasoning
+engines and one data store": the symbolic engine (ACL2, formal proofs,
+deductive gate rules), the provenance store (empirical parameters with
+sources, validity envelopes, confidence intervals), and the probabilistic
+oracle (the LLM, proposing within gate bounds).
+
+The geometry engine is not an application that happens to use this
+architecture. The geometry engine IS the architecture made concrete. The
+constraint solver IS the symbolic engine reasoning about design rules. The
+material property database IS the provenance store. The designer exploring
+alternatives IS the LLM oracle proposing and the solver validating. The gate
+checking a design against the validity envelope before permitting it to be
+released to manufacturing IS the same gate that checks a shell command
+against security policy.
+
+Stage 3 hardware makes it run fast enough for real-time domains. That is
+where the geometry engine meets the Lisp machine — the killer app that
+justifies and defines the hardware feature set.