R20 -- Computational Engineering Backbone

The Encoded-Physics Philosophy

R20 treats engineering computation as a typed pipeline, not a probabilistic generator. The pattern follows LEAP71's Noyron framework -- the same architecture that produced the world's first AI-designed liquid-fuel rocket engine using their PicoGK signed-distance-field kernel. The founders' framing is direct:

You cannot ask a black-box AI to generate an airplane and trust that it works. Engineering requires deterministic kernels with closed-form physics, constraint propagation, and reproducible audit trails. The LLM is a conversational driver, not the engineer. -- paraphrased from LEAP71 Noyron / JARVIS framing

R20 embodies this in our CAR architecture: a Rust engine doing the real computation, with an LLM driver providing the interface. The Rust engine is the load-bearing structure ("the car"); LLM calls are sprinklers on the lawn, not the foundation. The contract is uniform across domains:

Every spec-to-artifact pair carries a SHA chain so any output can be re-derived bit-for-bit from its inputs. This is the precondition for engineering claims -- BIND-021 (no numeric claims without measured data), BIND-051 (verification-complete before success claims), and BIND-059 (compute over estimate) all rest on having a deterministic substrate to compute on.

Substrate Inventory

The R20 substrate is measured at build time from the live source tree, not estimated. Counts below reflect the latest cached snapshot:

The numbers above are live-bound to /api/r20-substrate.json and refreshed at build time (PEAR amendment 5). The static fallback is the value inside the <span class="data-live"> tag, which the build pipeline syncs with the JSON cache.

interceptor-gen -- Drone-Design Generator (Flagship)

interceptor-gen is the flagship encoded-physics kernel. It takes a typed YAML spec describing an interceptor's mission envelope (mass class, propulsion type, sensor payload, threat profile, engagement geometry) and emits a CFD-ready geometry through a forward-parametric pipeline.

The polymorphic family is the leverage point: a single typed spec sweep can generate hundreds of interceptor variants, each one a distinct deterministic artifact. The drone-eval vertical (R20.3) consumes these artifacts through standardised CFD and engagement-geometry rubrics. See the case study at /cases/airguard/ for the engagement context.

airguard-dsp -- Counter-UAS Signal Processing

airguard-dsp is the real-time DSP family that sits behind the AirGuard sensor stack. It implements closed-form physics, well-known signal-processing primitives, and constraint-propagation patterns -- the same composition Noyron's actual architecture uses.

License: EUPL-1.2. The library composes by traits: each primitive exposes a typed input, a typed output, and a deterministic update contract. There are no probabilistic narrators in the math path -- every claim is reproducible from the input frame.

Other Domains -- Rubber Chemistry & ROI Math

The Noyron pattern transfers cleanly across engineering domains. Two further R20 kernels demonstrate cross-domain reuse:

Architectural Pattern -- Layer-by-Layer

Every R20 kernel maps onto the same six layers. The uniformity is the point: new domains plug in by implementing the layer contracts, not by inventing new pipelines.

The audit layer is where R20 plugs into the wider FDRP evidence fabric: every R20 artifact lands a row in engineering_audit_trail with the (spec_sha256, crate_sha, generation_seed) tuple, the solver run-id, and a pointer to the eval rubric. BIND-051 verification reads from this table before any claim about an R20 artifact reaches a human reviewer.

Cross-Domain Reuse Signal (R4.7)

Each R20 kernel carries an applicable_domains JSON tag that drives cross-domain transfer (R4.7 -- knowledge grafting). The tag is not decorative: downstream pipelines query it to decide which lessons travel.

The drone-eval lessons are already feeding the irrigation hydraulics track -- a cross-pollination that surfaced because both pipelines share the SDF substrate. Future pathways: rubber chemistry → composite layup, audio DSP → structural-health monitoring.

Roadmap Status

R20 is a capability track, not a single subsystem. It lands incrementally through numbered phases. Status is sourced from roadmap_items where applicable, and from the live JSON cache otherwise:

The WAVE-R12-LOCAL-MODELS-V1 entry in roadmap_items covers the LLM-driver side of CAR; the encoded-physics engine side is the R20 substrate this page describes.

Related Material