6e992cc0c5
- 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
175 lines
8.0 KiB
Org Mode
175 lines
8.0 KiB
Org Mode
: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.
|