CGU
Computational Gut Unit
I built a working hardware-and-software prototype that gives a computer a simple internal-state layer. It senses changing conditions, establishes a baseline, detects stress or novelty, and changes visible or computational behavior in response.
Overview
CGU began with a question about whether a machine could have something closer to a gut feeling without pretending to be conscious. Intelligent systems process enormous amounts of external information, but most do not maintain a persistent interpretation of their own condition that can influence attention, effort, or regulation.
The first Computational Gut Unit made that question physical. A Raspberry Pi Pico W/WH and temperature-and-humidity sensor provided a continuous signal. Host-side Python software established reference conditions, measured deviation and rate of change, interpreted simplified stress and novelty states, displayed those states through a GUI and RGB LED, recorded them to CSV, and could adjust host-process priority as a reflex-like response.
CGU is the sensing and internal-state architecture. The related Instinct Engine is the behavior layer that explores what a computer should do with those signals.
How It Started
The idea grew from my interest in the relationship between the gut, nervous system, and cognition. Biological systems continuously sense, compare, prioritize, and regulate before conscious analysis is complete. That led me to ask whether modern computing systems were missing a comparable layer beneath higher-level reasoning.
On August 4, 2025, I began using the terms Computational Gut and Computational Gut Unit and separated the physical/internal-state system from the Instinct Engine software layer. The project moved immediately from naming into hardware: a Pico W/WH, DHT20-class sensor, breadboard, wiring, RGB LED, and resistors.
Within the first build sequence, the firmware, host communication, visible LED behavior, and internal-state logic were implemented and debugged. By August 10, I had documented a working v0.1 system. Later code review refined the baseline, stress, curiosity, GUI, logging, and regulation behavior, and a January 2026 handoff consolidated the architecture for restoration and publication.
What changes when a machine does not merely receive a sensor value, but continuously interprets that value as part of its own condition?
Architecture
Physical Input
The prototype uses a Raspberry Pi Pico W/WH, a DHT20-class temperature-and-humidity sensor, and RGB LED output. Temperature and humidity provide a simple changing environment that can be sensed continuously and compared over time.
Firmware and Hardware Layer
The Pico firmware reads the sensor, manages the LED, and exposes data to the host. Early versions used serial communication; the later handoff architecture used Wi-Fi HTTP endpoints for sensor data and host-driven color state.
The device remains deliberately simple. It senses and acts, while the interpretation lives in the host application.
CGU Core
The Python host application performs the internal-state work:
- warm-up and reference establishment;
- exponential moving-average homeostasis;
- deviation and humidity-weighted stress calculation;
- a separate curiosity or novelty reference;
- rate-of-change tracking;
- persistence, dwell, debounce, and sustained-stress logic;
- GUI updates;
- CSV logging;
- controlled LED-state updates.
Instinct Engine, Regulation, and Records
The Instinct Engine is the response layer above CGU. It translates the interpreted state into bounded behavior such as LED signaling, process-priority adjustment, visible status, or recovery behavior.
The GUI and CSV record make the loop reviewable. Instead of relying on an impression that the system “reacted,” the project preserves the readings, reference conditions, state variables, causes, and outputs over time.
Development Timeline
Concept and hardware direction
The Computational Gut Unit name was introduced, its relationship to the Instinct Engine was defined, and the physical prototype parts were selected.
Firmware and visible response
Sensor communication, Pico firmware, serial behavior, and RGB response were debugged. The system reached stable visible behavior, including a blue-to-purple-to-pink-to-red response range.
Working v0.1
The project summary documented a hardware prototype that had been designed, built, and validated. The full loop was working rather than remaining a conceptual architecture.
Host integration and correction
Firmware and host versions were refined, working code was confirmed, and project terminology was corrected when assistant interpretations drifted away from the intended CGU definition.
State logic and review
The host expanded beyond simple thresholds through baseline math, stress and novelty variables, rate of change, persistence, GUI visualization, CSV output, and process-priority behavior.
Consolidated handoff
The Pico W/WH, DHT20, Wi-Fi HTTP, host interpretation, GUI, logging, and claim boundaries were consolidated into a reconstruction-ready handoff.
Results and Current Boundaries
Complete sensing loop
The prototype demonstrated a working path from physical input through contextual interpretation to visible and computational response.
Context instead of isolated thresholds
Readings were evaluated against recent or anchored reference conditions, allowing the same sensor value to mean different things depending on the system’s established state and recent change.
Reviewable behavior
The GUI, CSV logs, charts, and process behavior preserved how the system changed over time and made the internal-state logic inspectable.
CGU is a classical proof of concept for internal-state monitoring and regulation. Its stress and curiosity variables are engineering labels, not biological emotion or cognition. The project does not demonstrate consciousness, general intelligence, quantum behavior, or that interoception is required for AGI.
Behind the Build
The clearest way to understand CGU is to see the physical loop, the state logic, and the recorded output together. I am showing the pieces that explain the system rather than publishing the entire working folder.
What I built
A Raspberry Pi Pico W/WH, temperature-and-humidity sensor, RGB LED, and Python host application. Together they created a continuous loop from sensing, to interpretation, to visible response and logging.
The key idea
The software does not treat each sensor value as an isolated alarm. It continuously updates a reference condition, measures the difference, and uses the size and persistence of that change to influence the system state.
Selected technical detail
Turning change into an internal state
delta = temp_c - self.state.homeostasis
self.state.delta_smooth = (
0.75 * self.state.delta_smooth + 0.25 * delta
)
stress = clip(self.state.delta_smooth + 0.5)
priority = "low" if stress > 0.70 else "normal"
is_curious = abs(delta) >= 1.0This shortened excerpt shows the core relationship: compare the present condition with the system’s reference, smooth the change over time, and use that result to influence priority and visible state.
Evidence to show on the page
These are the strongest visual proof points for a recruiter or technical reviewer. The image and video URLs can be inserted after the Squarespace asset list is finalized.
The Pico, sensor, RGB LED, breadboard, and wiring.
The host interface showing readings, interpreted state, and output.
A sample log or chart showing the baseline and response changing over time.