Modern CAD systems are usually described through their user interface: sketch, extrude, fillet, assemble, draw, export. Underneath that workflow is a deeper question: what is the mathematical source of truth for the model?

Most mature CAD platforms answer with boundary representation. Geometry is stored as faces, edges, vertices, surface patches, tolerances, and a history tree that attempts to rebuild the topology after each edit. That architecture is powerful and industrially proven, but it also explains why topology changes, feature references, generative design output, and AI-assisted editing are difficult to make robust.

NeuroCAD takes a different route. The platform is built around a dual-engine mathematical kernel:

Engine A: Signed Distance Field geometry with numeric evaluation through nalgebra / f64.
Engine B: Geometric Algebra in CGA and PGA for structural reasoning, transformations, rigid motions, motors, and algebraic constructions.

The engines are not competing representations. They are complementary. Engine A is the numeric geometry authority. Engine B is the structural and transformation authority on the overlap operations where both engines can compute a result. A coherence layer projects Engine B outputs back into numeric form and checks them against Engine A using explicit tolerances.

That dual-engine approach is then organized through five graph layers: kernel_graph, DCG, e-graph, BVH, and NeuroGraph.

Engine A: Signed Distance Fields as Numeric Geometry

A signed distance field represents geometry as a function:

f(x, y, z) -> signed distance

The sign tells whether a point is inside, outside, or on the surface of a solid. The distance value gives the measurement needed for evaluation, rendering, gradients, offsets, and field composition.

This is why SDF geometry is a strong fit for AI-native and simulation-ready CAD:

Boolean operations can be expressed as field composition.
Offsets and variable wall thickness can be expressed as field transformations.
Gradients can expose surface normals and sensitivity information.
Lattices and implicit structures can remain compact until meshing or export is required.
Geometry can be evaluated at different resolutions without changing the source model.

SDF is not a rendering trick in NeuroCAD. It is one of the two mathematical engines behind the CAD kernel.

Engine B: Geometric Algebra for Structure, Motion, and Construction

The second engine is Geometric Algebra. In the current platform specification, it is split into two permanent algebraic branches:

CGA, Conformal Geometric Algebra: useful for points, spheres, planes, circles, point pairs, tangent constructions, inversions, and conformal transforms.
PGA, Projective Geometric Algebra: useful for rigid motion, screw axes, motors, mate constraints, mechanism paths, and assembly-style kinematics.

This matters because many CAD operations are not only “evaluate this solid.” They are structural questions:

What is the tangent circle defined by two curves?
What is the plane, line, or point implied by these constraints?
What rigid motion maps one part reference to another?
What screw-axis relation describes this assembly mate?
How do we compose motion without accumulating hidden matrix drift?

PGA represents rigid motion as motors. A motor is the algebraic equivalent of a rotation plus translation, with screw-axis structure directly available in the representation. CGA represents spheres, planes, circles, and related constructions in a way that is natural for geometric reasoning.

That is why NeuroCAD should not be described as “just an SDF CAD system.” The SDF engine handles numeric field geometry. The Geometric Algebra engine handles a second class of mathematical work that a serious mechanical CAD platform needs: structure, transformations, motion, and exact geometric construction logic.

Coherence: The Two Engines Must Agree

Dual representations can become dangerous if they drift. NeuroCAD’s design addresses this directly.

For operations where Engine A and Engine B overlap, Engine B’s multivector output is projected back into the numeric form expected by Engine A. The projected value is checked against Engine A’s result using an explicit per-operation tolerance.

In plain terms:

project(Engine B result) must match Engine A result within tolerance

If the engines disagree beyond the allowed threshold, that is treated as a correctness signal. It is not hidden behind a silent tolerance repair.

This is important for investor and technical diligence because it shows the architecture is not relying on vague “AI confidence” or informal math. The kernel has a defined reconciliation model for overlap operations.

The Five Graph Layers

The dual-engine kernel is coordinated through five graph layers.

Layer	Role
`kernel_graph`	Operation history and canonical node identity. It records what exists in the model.
DCG	Distributed Constraint Graph for dependency tracking and dirty propagation.
e-graph	Equality saturation and canonical-form extraction for equivalent expressions.
BVH	Bounding-volume hierarchy for spatial indexing and fast field queries.
NeuroGraph	Documentary segmentation, persistent identity, versioning, replay, and history layer.

Each graph answers a different question:

What is the current model?
What depends on what?
Which expressions are equivalent?
Where is the relevant geometry in space?
What changed over time, and how do we preserve identity?

This separation is deliberate. It makes each graph testable, but it also creates a new responsibility: committed model states must be coherent across all graph views. The specification defines post-commit invariants for that coherence.

Why E-Graphs Matter in This Architecture

E-graphs are often associated with compilers. NeuroCAD applies the same idea to geometry.

An SDF expression can often be written in multiple equivalent forms. Some are cheaper to evaluate. Some are better for GPU dispatch. Some are better for canonical comparison. Equality saturation lets the system explore equivalent forms without destructively choosing one rewrite too early.

In the dual-engine design, e-graphs also matter for Geometric Algebra. CGA and PGA identities can be represented and optimized symbolically, and extracted forms can be checked through the coherence layer.

This is a central reason the platform is AI-native without making AI the source of truth. AI may propose an operation sequence, a modeling command, or an edit direction. The kernel still validates deterministic commands, graph updates, and mathematical coherence.

Why This Matters for Mechanical Engineering

For a mechanical engineer, the architectural details only matter if they improve real work. The target outcomes are practical:

fewer brittle references when topology changes;
faster iteration on parameter changes and field edits;
browser-native workflows without turning CAD into a thin cloud viewer;
cleaner path from geometry to simulation and export;
deterministic command history and replay;
a safer boundary for AI-assisted design operations.

The point is not to replace engineering judgment. The point is to make the CAD substrate better suited for modern engineering workflows: implicit geometry, optimization, simulation handoff, web delivery, and AI-assisted execution.

Current Status: Works Today, In Progress, Roadmap

Investor-facing and customer-facing claims need to stay precise. NeuroCAD should be discussed in three buckets.

Works Today

NeuroCAD has a working MVP/demo and a private technical repository. The platform direction is browser-native CAD with an SDF-based geometry foundation, graph-based state management, and AI-assisted execution boundaries.

In Progress

The current product work is focused on hardening the MVP into credible pilot workflows: clearer demo paths, stronger geometry evidence, export and validation workflows, and better separation between implemented functionality and roadmap claims.

The dual-engine and five-graph architecture is specified in detail. Not every advanced surface is a finished commercial feature today, so external material should distinguish implemented demo capability from in-progress engineering work.

Roadmap

The roadmap includes deeper pilot deployments, production-grade workflow coverage, expanded Geometric Algebra use in assembly and motion, stronger NeuroGraph identity/history behavior, and physics-aware design through the NeuroFEM direction.

The foundation physics model and GPU training infrastructure should be described as roadmap and evidence-building work unless and until production validation exists.

The Short Version

NeuroCAD is not a CAD plugin and not a kernel-only library. It is a full AI-native CAD platform being built around a dual-engine mathematical kernel.

Engine A gives numeric SDF geometry. Engine B gives Geometric Algebra structure, construction, and motion. Five graph layers keep the model coherent across operations, dependencies, optimization, spatial queries, and history.

That is the technical thesis: a CAD platform where geometry, structure, optimization, and AI-assisted operations share one coherent mathematical foundation.

Inside NeuroCAD's Dual-Engine CAD Kernel: SDF Geometry, Geometric Algebra, and Five-Graph Coherence