Hi everyone,
I’ve been diving deep into Barbara Webb’s latest work View article (Mitchell & Webb 2026) on insect steering circuits and your video regarding the mechanics of “how to flip a switch.” in
2026/02 - Summary of Brainstorming Week. Based on these, I was thinking of a neural architecture.
The core idea: The system doesn’t “know” what a switch is. It doesn’t recognize objects or use standard image processing. Instead, it navigates purely through Movement Vectors (Flow) and Causality.
How the System Works: A Causal Loop
Before looking into it deeper, you have to understand the philosophy. This system operates like a self-correcting feedback loop. Think of it like a person navigating a dark room with a cane. They don’t see the wall, but they learn: “When I move my arm this way, I feel a specific resistance (Flow), and then my world state changes.”
The system doesn’t navigate a picture; it navigates a State-Space. It constantly asks:
-
Where am I now?
-
Where do I want to be?
-
Which movement brought me to that goal in the past?
The Signal Flow: Step-by-Step
1. Capturing State (The Ring Attractors)
The system maps the world onto Ring Attractor Networks. Imagine these as circular neural tracks where a “bump” of activity (a cluster of firing neurons) moves back and forth.
-
Ring 1 (Arm Position): Where is my arm located?
-
Ring 2 (Switch Position): Where in the camera’s field of view is there “flicker” or movement?
-
Ring 3 (Light State): How bright is the environment (simulated Lux sensor)?
A “bump” looks like this internally: O O O X X X O O O. The XXX represents the current position. This gives us a “map” of the current situation without needing a single pixel-perfect image.
2. Goal Setting & Error Calculation
You give the system a goal, like “Light On.” This injects a virtual Goal Bump into the Light Ring at the “Bright” position. Since the current state is “Dark,” the system calculates the distance between the two bumps. This difference is the Error Vector. This error is the fuel—as long as it isn’t zero, the system is driven to act.
3. The Causal Matrix (CAM) & Taking Action
This is the memory. The Causal Associative Matrix (CAM) is a storage unit that has learned: “Arm movement Right leads to Flow at the switch, which leads to Brightness in the Light Ring.” The system picks the motor command (e.g., “Arm Right”) that it knows will best reduce this specific error.
4. Prediction (Efference Copy)
As the motor starts, something crucial happens: the system sends an Efference Copy (a duplicate of the motor command) to an internal Forward Model. The model predicts: “I am moving right, so I expect the camera to report flow moving right.”
5. The Prediction Error & Learning
The system compares its prediction with the real-time camera data.
-
Does it see only what it predicted? Everything is normal.
-
Is there “extra flow” because the switch clicked? The Prediction Error screams: “Something happened that I didn’t cause myself!” In this exact moment, the system learns the causal link between the arm movement, the switch, and the light and it is stored in the CAM. So next time the system knows exactly which movement is the one that leads to bright.
The Validation: A Software Simulation
To prove this, I intend to build a 1D simulation: a virtual arm which can move 1D, a switch on a line, and a light source.
The “Flow-Only” Camera Pipeline: In this simulation, the camera won’t see colors or shapes. It will only process Flow (when something is moving in a certain direction). If the switch flips, it will create a very specific pattern in the data. The system will learn that this specific movement pattern is the “key” that toggles the Light Ring.
The “Lock-In”: The simulation is designed to reveal a fascinating behavior. The arm will move as long as there is an error in the Light Ring. The moment the switch clicks and the light sensor reports “Bright,” the current bump in the Light Ring will jump to the Goal position.
At that exact moment, the error becomes zero. Mathematically, the “drive” for the motors simply vanishes. The arm won’t stop because of a timer or a “stop” command; it will stop because it has physically locked into the goal state within the neural rings.
Why this matters: If I move the switch to a different position during the simulation, the system shouldn’t care. Because it’s constantly trying to “align the bumps,” the arm will just keep searching until it hits the switch and gets the light feedback. It’s not a rigid program; it’s steering in a causal space.
What do you think? You can tell me openly if this is complete nonsense 
And also the idea still lacks many details but I am working on it.
Looking forward to your thoughts!
