Was the generator using the fly's whole brain?

EXPERIMENTS.md · lines 8347–8395

E137 — The fly is using 2.5 per cent of the brain, and it is a filter, not a limit

What is actually loaded. data/malecns_circuit.json holds 5,311 neurons: 4,062 Kenyon cells (KCab 1810, KCg 1557, KCa 695), 316 PAM, 97 MBON, and projection neurons. Its extraction spec reads:

node_policy  type_regex
type_regex   ^(KC|MBON|PAM|PPL|APL)|PN
max_nodes    20000
eligible_nodes_before_cap  5311

The cap was never binding. max_nodes is 20,000 and only 5,311 neurons were eligible, so the type filter is the entire constraint. It selects the mushroom body and nothing else.

What is available. The raw MaleCNS asset is on disk - 1.05 GB of edges, 14 MB of annotations, no network needed - and holds 211,577 annotated bodies:

ol_intrinsic       89,403     optic lobe, visual processing
cb_intrinsic       32,164     central brain: mushroom body, central complex, the rest
vnc_intrinsic      13,161
visual_projection   9,201
(unannotated)      44,877

So the circuit in use is 2.5 per cent of the annotated connectome, and connectome.py already supports a superclass node policy that would take the central brain whole.

The honest uncertainty, stated before the test. More neurons buy representational capacity: 4,062 Kenyon cells at 10 per cent sparsity give about 406 active per input, and discrimination between compositions scales with that. But the proposals do not come from the representation - they come from FlyGenerator's 24 walkers doing run-and-tumble on the field the circuit learns. Diversity of output is a property of the walker dynamics, and it is not obvious that a bigger circuit changes it at all. That is the thing worth measuring rather than assuming.

Predicted, extracting cb_intrinsic and re-running the fly against the same target:

1. The extraction yields 25,000 to 32,000 nodes, five to six times the present circuit, and the induced edge count rises faster than the node count because the central brain is more densely connected than a type-filtered subgraph.
2. The forward pass slows roughly in proportion to edges, so a run costs several times more per proposal. If it slows by much more than the edge ratio the implementation does not scale and that is the finding.
3. Distinct in-class finds per unit spend do NOT improve much - I expect within a factor of two of E136's 5.0 - because the bottleneck is the walkers, not the representation.

Falsified if distinct finds per unit spend rise substantially - say beyond twice E136's rate - which would mean representational capacity really was the limit and the whole-brain circuit is the fix the operator has been asking for. That is the outcome worth having and it has never been tested.