Why Cerebel

Modern language models are powerful, but they are often asked to do more than they can sustain on their own. They can perform well when the task is clearly framed, but that does not automatically give them the broader understanding needed to decide what matters, maintain context over time, or coordinate complex work across a domain. A capable system needs more than a model that can respond in the moment; it needs structure that supports understanding, memory, and direction.

That shift in perspective is what led to Cerebel. Rather than treating intelligence as a single assistant with a set of tools, the project treats it as a system of cooperating parts that together support domain expertise, coordination, and adaptation. The architecture borrows its language from the brain not as a claim of biological equivalence, but as a practical domain model for organizing responsibilities. That model provides a stable conceptual frame while the surrounding AI techniques, models, and interfaces continue to change.

Guiding Principles

The goal of Cerebel is to create an AI domain specialist that acts as an augmentation to a person. That is not to say augmentation is the only goal, but the system has to be guided by the principle that it is a co-creator. Its purpose is to help the user with thinking errors, anticipate potential needs and shortcomings, and support a longer-term understanding of how to interact with a person. Unlike a chatbot, which is focused only on the immediate need, an augmentation must necessarily understand the user’s long-term goals and needs. This can be applied to any discipline, and the strength of the Cerebel system is that it can be taught any domain and improve upon what it is taught.

The augmentation can also take the form of accepting instructions, doing its job until there is a question, and then returning to the user for further instruction and understanding. This could be used for a task like quality control, where the Cerebel is learning how to deal with new abnormalities. While the current interface is CLI and GUI, there is no reason a Cerebel could not be used as a subsystem in robotics.

To build a symbiotic relationship between the Cerebel and the user, we have to maximize our understanding of what is happening within the system. The system is capable of plasticity, so any discovered self-improvements would need to be inspected to better understand how the system is reacting to the introduction of new or additional information.

We have to be able to retrace the actions of every substrate and modulator. This requires logging every action at both a domain level and a systemic level. It might make sense to look at a CQRS system that saves events to allow traceable playback.

AI belongs to the people. It has been built on centuries of mathematics and the study of the brain. It has grown out of our collective understanding of software and engineering. It has been developed through experiments in public universities and with public funding. It has been able to grow at the rate it has, thanks in part to its cousin, the internet, and all of the tools, protocols, and research that were also built by the people. Because AI belongs to the people, this project is licensed under AGPLv3 to ensure that all development remains shareable. We should also look into legal protections for the safeguards built into Cerebel and ensure that the code can only be used with those safeguards in place.

For short-term definitions, see the Glossary.

Cerebel

Cerebel is the name of the project.

Operationally, a Cerebel is a working system built around a Cerebrum substrate plus the supporting code required to launch, run, and integrate it in a real system.

At a high level, a Cerebel behaves as a domain specialist.

Substrate

A substrate is a bootable or launchable system unit in this architecture, with its own declaration, acquisition source, launch contract, and lifecycle policy.

A substrate may be a whole system or a subsystem; examples include Cerebrum, cortices, Thalamus, and future additions.

Cerebrum

The Cerebrum is the core intelligence substrate within a Cerebel.

It contains the structures needed for the system to be taught and to exhibit neuroplasticity over time.

Conceptually, it is also the top-level API surface for the domain expert system: the single entry point that external users, APIs, and host systems interact with.

For the current architecture map, see Cerebrum System Architecture.

Cerebellum

The Cerebellum is the supervisory partner to the Cerebrum.

Its role is human-in-the-loop monitoring, correction, and feedback, giving the system a clear place for review and fine-tuning rather than collapsing that responsibility into the decision-making path itself.

Thalamus

The Thalamus is a coordinating substrate that manages message flow between Cortices.

It is responsible for enabling coherent routing and exchange across specialized capabilities.

In the current architecture direction, it also serves as the sensory relay and gatekeeper between external inputs and internal decision-making.

Cortices

A Cortex is a specialized substrate oriented toward a domain responsibility.

Each Cortex is oriented toward expert behavior in a specific responsibility area, while its reusable inheritance layers are expressed as laminae such as SensoryCortexLamina and MotorCortexLamina.

Prefrontal Cortex

The Prefrontal Cortex is currently a required Cortex in the Cerebrum.

It is responsible for a significant share of reasoning, orchestration, and processing across incoming inputs and other Cortices.

More specifically, it owns the executive role: goal setting, decision-making, and conflict resolution.

SensoryMotorCortexLamina

The SensoryMotorCortexLamina is the shared communication-oriented layer in the Cerebrum.

It provides the reusable behavior needed for interfacing with external systems, while the assembled runtime remains a concrete substrate rather than the lamina itself.

RAS

The Reticular Activating System, or RAS, is the broadcast and boot orchestration layer for substrates.

It is responsible for requesting modulators from synthesizers, collecting the responses into a cocktail, and configuring the working system rather than participating directly in domain decisions.

Naming System Direction

To keep architecture terminology readable at scale, the project is moving toward semantic suffixing for class names.

In this approach:

1. Lamina names inherited structural layers.
2. Substrate names fully assembled concrete runtime units.
3. Modulator and Cocktail name runtime state influences and grouped state configuration.

This preserves the brain metaphor while making class intent self-documenting.

For the full convention and examples, see Naming Conventions.