Chapter 13: Quantitative Evidence

Measurable constrained-evolution signatures: NTT-to-FFT kernel identity (~97%), convergent IPC, fastidious specialization.

📐 Architecture-ready

13.1 Overview

This chapter presents the measurable signatures of constrained evolution in the ecoPrimals codebase, moving beyond biological analogy to quantitative evidence that the same dynamics observed in the LTEE and hot spring populations operate in computational systems under type-theoretic constraint.


13.2 The NTT → FFT Structural Evolution

13.2.1 Background

BarraCuda’s Number Theoretic Transform (NTT) was evolved under fully homomorphic encryption (FHE) constraints for polynomial multiplication in (\mathbb{Z}_q). The Fast Fourier Transform (FFT), needed for physics simulation (lattice QCD, spectral methods), shares the Cooley-Tukey butterfly structure.

13.2.2 Structural Comparison (Measured from Source)

Source files: fhe_ntt.wgsl (263 lines), fft_1d.wgsl (186 lines), fft_1d_f64.wgsl (197 lines). The FFT header explicitly records its ancestry: “Adapted from fhe_ntt.wgsl (80% structure reuse!)”.

ComponentNTT (fhe_ntt.wgsl)FFT (fft_1d.wgsl)Match
Domain arithmetic library93 lines (U64 emulation)16 lines (complex mul/exp)Different (domain-specific)
Buffer bindings (4 each)4 lines4 linesSame structure
Params struct8 fields (needs modulus/Barrett)4 fieldsPartial
Load from input4 lines4 linesIdentical structure
Load twiddle4 lines4 linesIdentical structure
Store to output4 lines5 linesIdentical structure
Modular arithmetic wrappers20 lines0Unique to NTT
Butterfly struct4 lines4 linesIdentical
Butterfly function5 lines: u=(a+tb)%q, v=(a-tb)%q5 lines: u=a+tb, v=a-tbIdentical (NTT adds mod)
bit_reverse_index8 lines8 lines100% identical
Main compute kernel40 lines39 lines~97% identical
bit_reverse kernel26 lines26 lines~97% identical

Shared structural core: ~93 lines identical between NTT and FFT (butterfly, bit-reversal, indexing, load/store, main dispatch). The main compute kernel — stage indexing, stride computation, block decomposition, twiddle lookup — is character-for-character identical between both files.

The FFT is shorter than its NTT ancestor because complex floats (native vec2<f32>) map to GPU hardware natively, while NTT requires U64 emulation from u32 pairs (WGSL lacks native u64). The f64 FFT variant (197 lines) uses a Complex64 struct but retains the identical butterfly/indexing skeleton. This is the computational analog of an adaptation that simplifies — the Lenski populations’ improved glucose transport is simpler and more efficient than the ancestral mechanism.

13.2.3 Interpretation

No one designed BarraCuda for physics. The FHE constraint required NTT; NTT required the Cooley-Tukey butterfly; the butterfly is the FFT’s skeleton. Each step follows by mathematical necessity within the constraint. This is constrained evolution: the constraint (FHE) reshaped the fitness landscape to select for a structure (butterfly transform) that happened to be fit for an unrelated domain (physics).

This is Taq polymerase in code. The hot spring (FHE constraint) produced an enzyme (NTT butterfly) that proved useful far beyond its original environment (physics simulation), because the constraint selected for a mathematical structure that was universal.


13.3 Convergent IPC Patterns

13.3.1 Method

All 11 primals implement JSON-RPC 2.0 IPC independently. We analyze the structural similarity of these independent implementations — the computational analog of convergent evolution in isolated populations.

13.3.2 Convergent Features

FeaturePrimals ConvergingIndependent Implementations
JSON-RPC 2.0 message format11/1111 distinct parsers
Unix domain socket transport11/1111 distinct socket handlers
Capability advertisement on connect10/1110 distinct advertisement protocols
Async Tokio runtime11/1111 distinct runtime configurations
Structured error types (enum + Display)11/1111 distinct error hierarchies
Zero unsafe blocks11/11Enforced by constraint, not by convention

13.3.3 Non-Identical Solutions

Despite convergent features, the implementations differ in:

  • Error granularity (BearDog has ~40 error variants; Songbird has ~25)
  • Connection pooling strategies
  • Timeout and retry logic
  • Message batching approaches
  • Capability versioning schemes

This is the cephalization/eyes/wings pattern: same function, different developmental pathways, because the constraint rewards the function without prescribing the mechanism.


13.4 Fastidious Specialization Over Time

13.4.1 Method

Analyzing primal scale across the evolutionary timeline reveals a clear maturity gradient:

PhasePrimalsAvg Rust LinesAvg #[test]Age (months)
Phase 15618,96614,299~10
Phase 2796,9724,148~3–6
Ratio6.4×3.4×

Phase 1 primals average 6.4× more code and 3.4× more tests than Phase 2 primals. This is the accumulation signature: longer evolutionary exposure under constraint produces larger, more specialized, more thoroughly tested organisms.

13.4.2 Primal-Level Specialization

The largest primals are also the most specialized:

  • Squirrel (681,933 lines, 25,359 tests) — deeply adapted to multi-provider AI coordination, MCP protocol, model routing. Could not be ported to another IPC model without complete rewrite.
  • ToadStool (788,209 lines, 13,503 tests) — deeply adapted to WGSL/Vulkan compute, f64 emulation, shader pipeline management. The 628 WGSL shaders represent extreme specialization to the GPU constraint.
  • BearDog (577,341 lines, 11,872 tests) — deeply adapted to cryptographic operations, 91 methods, HSM integration. The entropy hierarchy principle is BearDog-specific.

Meanwhile, younger primals like skunkBat (7,366 lines, 48 tests) and rhizoCrypt (27,565 lines, 278 tests) remain more generic — less specialized because they have undergone fewer evolutionary cycles.

13.4.3 Expected Full Analysis

A complete git history analysis (pending) would measure:

  • Idiomatic Rust usage (clippy lint compliance over time)
  • Dependency tree narrowing (fewer external crates over time)
  • Trait boundary tightening (more specific type constraints over time)
  • Test coverage trajectory
  • Lines per function (should decrease as specialization increases)

The prediction: these metrics follow power-law dynamics (rapid early improvement, decelerating), paralleling the LTEE fitness trajectory (Wiser et al., 2013).


13.5 The 11,161-Check Velocity

13.5.1 Current Inventory (Measured March 7, 2026)

SpringDomainChecksPapers Reproduced
hotSpringPlasma physics, nuclear, lattice QCD, spectral, NPU brain697+25
airSpringET₀ (8 methods), soil, IoT, Richards PDE, immunological Anderson2,631+57
wetSpring16S metagenomics, Anderson QS, PFAS, drug repurposing, immunology5,421+52
groundSpringSensor noise, spectral theory, transport, quasispecies, rare biosphere236+21
neuralSpringPINN, DeepONet, LSTM, evo comp, dose-response, coralForge3,200+25+
Total8 domains, 13 professors11,161+70+

13.5.2 Interpretation

11,161+ validated science checks across 8 scientific domains in ~69 days of development, by a single developer. The comparable institutional pace for reproducing a single computational paper is weeks to months (Mesnard & Barba, 2017). The velocity is not explained by AI alone (the AI was available to everyone; the methodology was not). It is explained by the constrained evolution methodology: the Rust type system eliminated broad classes of bugs, the phased validation protocol provided clear direction, and the AI provided high-frequency generation of candidates.

The growth from the initial 2,882 checks (February 2026) to 11,161+ (March 2026) — a 3.9× increase in ~5 weeks — occurred through three mechanisms: (1) deepening existing springs (wetSpring from 1,368 to 5,421+ through Track 4 soil, Track 5 immunological Anderson, and PFAS extensions), (2) broadening into new domains (immunology, pharmacology, drug repurposing via Gonzales and MSU Drug Discovery), and (3) cross-spring validation (the same Anderson framework validated independently in hotSpring, wetSpring, airSpring, and groundSpring). The growth rate itself is evidence for the constrained evolution model: the infrastructure specializes to its constraint environment (Rust + WGSL + validated kernels), and each new domain added to the springs exercises existing kernels rather than requiring new ones. Cross-domain kernel reuse (Section 13.6) is the mechanism behind superlinear growth.


13.6 Cross-Domain Kernel Reuse

13.6.1 The Isomorphism Theorem

neuralSpring’s Isomorphism Theorem (Chapter 12) demonstrates that all neural architectures decompose into 6 fundamental primitives: GEMM, Attention, Normalization, Nonlinearity, Reduction, Gating. BarraCuda implements all 6 as WGSL shaders.

The same primitives serve multiple domains:

PrimitivehotSpring UsewetSpring UseneuralSpring Use
GEMMSU(3) matrix multiplicationSpectral cosine matchingAll neural network layers
ReductionObservable averagingDiversity index computationLoss computation
FusedMapReduceF64Transport coefficient integrationBulk statisticsBatch normalization
BatchedEighGpuNuclear eigenvalue decompositionHessian analysis

13.6.2 Interpretation

Kernels evolved under one domain’s constraints (hotSpring’s plasma physics) proved fit for other domains (wetSpring’s biology, neuralSpring’s ML) without modification. This is the NTT→FFT pattern at the kernel level: constraint-driven adaptation producing structures with cross-domain fitness.


13.7 Summary

The quantitative evidence shows:

  1. NTT→FFT: ~93 shared structural lines between cryptographic and physics transforms, with character-identical main compute kernels — emerged from constraint, not design
  2. Convergent implementation patterns: 11 primals sharing directed architectural choices (JSON-RPC, capability-based) but independently converging on undirected implementation details (error granularity, retry logic, capability versioning) — the constraint environment shapes solutions beyond what the developer specifies
  3. Cross-domain kernels: 6 BarraCuda primitives serve 8 scientific domains without modification — the same GEMM that does SU(3) matrix multiplication does spectral cosine matching in metagenomics and attention in neural networks
  4. Velocity: 11,161+ checks across 70+ papers in ~69 days exceeds institutional reproduction rates by an order of magnitude, with 3.9× growth in the most recent 5 weeks driven by cross-domain kernel reuse
  5. Fastidious specialization: Phase 1 primals average 6.4× more code and 3.4× more tests than Phase 2 primals, reflecting evolutionary maturity under constraint

These are not analogies. They are measurements from 757,000 lines of Rust, 914 WGSL shaders, across 11 primals and 5 springs. The constrained evolution principle predicts all five observations. Alternative hypotheses (“good engineering”) predict convergence and velocity but not cross-domain fitness from unrelated constraints (NTT→FFT). “Fast AI” predicts velocity but not the specific pattern of implementation convergence within directed architecture. The full pattern — convergence, specialization, cross-domain fitness, superlinear growth via kernel reuse — is predicted by the constrained evolution model.


See also: