:PROPERTIES:
:ID:       aae3b3a9-05c2-4acd-bfd4-a7f65003c0bf
: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.
