hermes-brain/ideas/lisp-geometry-engine.org

— 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.