GOFAINEAT: bounded offline decision systems

Source: GOFAINEAT_DEFINITION.md
Source SHA-256: 6f060a90e2269a7d6fad699e879ddb673ce3f3f146001b3a949449901172e0be
Status: Historical architecture proposal

REVIEW NOTE: The source describes an intended lifecycle: seed a narrow decision model, evolve it against reviewed examples, then curate later corrections. Its implementation-status claims are historical and were not revalidated for this publication. Its “no runtime inference cost or latency” wording is too strong: local inference still consumes compute and time; the intended advantage is avoiding a network model call.

GOFAINEAT means GOFAI-NEAT: Good Old-Fashioned AI (classical symbolic/expert-system framing — the discipline of decomposing a task into named, auditable, narrow decisions) crossed with NEAT (NeuroEvolution of Augmenting Topologies — genetic-algorithm-evolved neural network topologies, Stanley & Miikkulainen, real neuroevolution of actual networks, not just rule sets). It names a methodology, not a single product: distilling narrow, LLM-shaped decisions into evolved, compiled, offline expert systems that trade general reasoning for speed, cost, and determinism on well-scoped, repeated tasks.

**Correction, 2026-09-13:** the two pilots built so far ([internal implementation reference omitted], [internal implementation reference omitted]) are real, working, and a legitimate proof of the overall corpus→review→GA→compile→verify pipeline - but they're Holland-style rule-based learning classifier systems (condition→action rule populations), not neural networks. That's a real gap against the "NEAT" half of the name, caught and corrected here rather than left standing: the target architecture going forward is real tiny evolved neural networks (true neuroevolution, matching what NEAT actually means), not rule sets relabeled as such. The existing two pilots remain valid precedent for the surrounding process (bootstrap corpus, human/AI review, offline compile, verification) - only the "what gets evolved inside each stage" changes from a rule population to an actual small network topology+weights.

Instead of calling an LLM API every time a system needs to fill in one blank in a template, maintain a large collection of small, purpose-built, embedded tiny neural networks — each closed over its own narrow slot — that each answer one hyper-specific question: *"what goes in this Mad-Libs-style slot, given only this context, without making a server call?"*

Each network's behavior is not hand-coded from scratch. The real lifecycle has three stages: (1) an initial, intelligently-designed seed (a real starting topology/weights or rule scaffold reflecting a human's or frontier model's best first guess at the decision boundary, not a random init), (2) genetic-algorithm evolution/refinement against a real, reviewed corpus (true NEAT-style neuroevolution — evolving topology and weights, not just tuning a fixed architecture), and (3) ongoing, continuous hand-curation by a frontier model on the backend after deployment - periodically reviewing real production decisions the network made, correcting systematic errors, and feeding corrections back into further evolution rather than treating the compiled artifact as permanently finished after one training run.

- **Answered 2026-09-13** (was open): the ongoing training/maintenance loop is real, continuous frontier-model curation on the backend, not a one-shot GA run — a frontier model periodically reviews real production decisions and feeds corrections back into further evolution. Still open: the concrete mechanics of that curation cadence (how often, what triggers a re-evolution pass, how corrections are actually fed back into the GA's fitness function) haven't been designed yet.
- **Answered by precedent, needs porting**: the two existing pilots ([internal implementation reference omitted] etc.) prove the corpus→review→GA→compile→verify pipeline end to end for rule populations. The same pipeline needs to be adapted to evolve actual neural network topology+weights (true NEAT) instead of rule sets - this is real, concrete follow-up work, not a fresh design question.
- Where the boundary sits between "genuinely reducible to a classifier" and "actually needs a real LLM call" for a given slot - misjudging this is the main real risk (a network confidently returning a wrong fill for a case its evolved training never saw, with no fallback). See `GOFAINEAT_CASCADE_DESIGN_PATTERN.md` for the real, worked-through answer to this for open-ended tasks specifically (decompose into a cascade of narrow stages, accept a small constrained-generation remainder rather than forcing classification everywhere).