Chapter 13: Quantitative Evidence
Measurable constrained-evolution signatures: NTT-to-FFT kernel identity (~97%), convergent IPC, fastidious specialization.
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!)”.
| Component | NTT (fhe_ntt.wgsl) | FFT (fft_1d.wgsl) | Match |
|---|---|---|---|
| Domain arithmetic library | 93 lines (U64 emulation) | 16 lines (complex mul/exp) | Different (domain-specific) |
| Buffer bindings (4 each) | 4 lines | 4 lines | Same structure |
| Params struct | 8 fields (needs modulus/Barrett) | 4 fields | Partial |
| Load from input | 4 lines | 4 lines | Identical structure |
| Load twiddle | 4 lines | 4 lines | Identical structure |
| Store to output | 4 lines | 5 lines | Identical structure |
| Modular arithmetic wrappers | 20 lines | 0 | Unique to NTT |
| Butterfly struct | 4 lines | 4 lines | Identical |
| Butterfly function | 5 lines: u=(a+tb)%q, v=(a-tb)%q | 5 lines: u=a+tb, v=a-tb | Identical (NTT adds mod) |
bit_reverse_index | 8 lines | 8 lines | 100% identical |
| Main compute kernel | 40 lines | 39 lines | ~97% identical |
bit_reverse kernel | 26 lines | 26 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
| Feature | Primals Converging | Independent Implementations |
|---|---|---|
| JSON-RPC 2.0 message format | 11/11 | 11 distinct parsers |
| Unix domain socket transport | 11/11 | 11 distinct socket handlers |
| Capability advertisement on connect | 10/11 | 10 distinct advertisement protocols |
| Async Tokio runtime | 11/11 | 11 distinct runtime configurations |
| Structured error types (enum + Display) | 11/11 | 11 distinct error hierarchies |
| Zero unsafe blocks | 11/11 | Enforced 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:
| Phase | Primals | Avg Rust Lines | Avg #[test] | Age (months) |
|---|---|---|---|---|
| Phase 1 | 5 | 618,966 | 14,299 | ~10 |
| Phase 2 | 7 | 96,972 | 4,148 | ~3–6 |
| Ratio | 6.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)
| Spring | Domain | Checks | Papers Reproduced |
|---|---|---|---|
| hotSpring | Plasma physics, nuclear, lattice QCD, spectral, NPU brain | 697+ | 25 |
| airSpring | ET₀ (8 methods), soil, IoT, Richards PDE, immunological Anderson | 2,631+ | 57 |
| wetSpring | 16S metagenomics, Anderson QS, PFAS, drug repurposing, immunology | 5,421+ | 52 |
| groundSpring | Sensor noise, spectral theory, transport, quasispecies, rare biosphere | 236+ | 21 |
| neuralSpring | PINN, DeepONet, LSTM, evo comp, dose-response, coralForge | 3,200+ | 25+ |
| Total | 8 domains, 13 professors | 11,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:
| Primitive | hotSpring Use | wetSpring Use | neuralSpring Use |
|---|---|---|---|
| GEMM | SU(3) matrix multiplication | Spectral cosine matching | All neural network layers |
| Reduction | Observable averaging | Diversity index computation | Loss computation |
| FusedMapReduceF64 | Transport coefficient integration | Bulk statistics | Batch normalization |
| BatchedEighGpu | Nuclear eigenvalue decomposition | — | Hessian 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:
- NTT→FFT: ~93 shared structural lines between cryptographic and physics transforms, with character-identical main compute kernels — emerged from constraint, not design
- 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
- 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
- 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
- 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:
- BarraCuda — where the kernels evolved
- Constrained Evolution — Formal — the predictions these measurements test