Naming Conventions

This section defines the project ontology: the naming system that makes architectural intent legible, consistent, and reviewable across the codebase.

A well-designed ontology is not decorative. It is how the system communicates what something is, what role it plays, and how it relates to the rest of the architecture.

Why ontology matters

Without a shared naming ontology, the same concept can drift into multiple meanings.

Examples:

a reusable inheritance layer and a fully assembled runtime object can both be called “substrate” without warning
a domain boundary can be confused with a thing that belongs to that domain
a message and a runtime actor can blur together if the vocabulary does not distinguish them clearly

The naming system prevents that drift by giving each architectural role a distinct grammatical and conceptual identity.

The core idea

The project does not treat names as arbitrary labels. It treats names as semantic contracts.

Every naming choice answers one question:

Is this the domain itself?
Is this a structural layer?
Is this a concrete runtime object?
Is this a message, a relay, a factory, or a modulator?

Once the role is clear, the name becomes self-documenting.

The naming pattern

The naming system is built on a few recurring patterns:

Pattern	Meaning	Example
`Lamina`	Inherited structural layer	`BaseLamina`
`Substrate`	Concrete assembled runtime class	`CliSensoryCortexSubstrate`
`Synthesizer`	Factory that produces modulators	`CortexLaminaSynthesizer`
`Signal` / `Reply` / `Broadcast`	Orchestration and relay messaging	`PeripheralSignal`
`Modulator` / `Cocktail`	Runtime state and behavior influences	`ModulatorCocktail`
`Periphery` / `Peripheral`	Domain noun vs domain-owned adjective	`PeripheryRelay` vs `PeripheralTerminal`

The important principle is that the noun describes the domain or object itself, while the adjective describes something belonging to or coming from that domain.

Expanded vocabulary

The following terms are part of the core ontology and should be used consistently across the architecture.

Structural and identity terms

Term	Definition	Examples
`Axis`	A privileged, direct, bidirectional communication channel between two substrates. Bypasses the general-purpose relay for low-latency, high-priority communication. Named source-first.	`CerebroThalamicAxis`, `CorticalPrefrontalAxis`, `PrefrontoCerebralAxis`, `PrefrontalHippocampalAxis`
`Relay`	The foundational routing fabric that carries transmissions between components.	`NeuralRelay`, `PeripheryRelay`, `SynthesisRelay`, `CorticalRelay`
`Terminal`	The sending and receiving interface bound to a relay.	`SynapticTerminal`, `PeripheralTerminal`, `ThalamicTerminal`
`Biomarker`	The unique, intrinsic identifier of a substrate or component. Used for routing and tracing.	`Biomarker`
`Cortex`	A domain-specialized substrate responsible for a focused role within the broader system.	`SensoryCortexLamina`, `PrefrontalCortexSubstrate`
`Lamina`	An inherited structural layer that contributes one capability toward a final runtime object.	`BaseLamina`, `CortexLamina`
`Substrate`	A fully assembled concrete runtime class.	`CliSensoryCortexSubstrate`

Messaging and storage terms

Term	Definition	Examples
`Percept`	A specialized cortical message carrying both the original peripheral input and its system-ontology translation. Sent from a cortex to the PFC.	`Percept`
`Transmission`	The envelope wrapping every message with routing, tracing, and correlation metadata.	`Transmission`
`Vesicle`	A storage compartment that holds transmissions until released by a gate.	`Vesicle`, `PeripheralOutputVesicle`
`Gate`	The decision-making component that controls how items enter or leave a vesicle.	`PassThroughGate`, `PriorityGate`, `ComposableGate`
`Signal`	A directed message carrying intent or action to a specific recipient.	`PeripheralSignal`
`Reply`	A return message that resolves or confirms a signal.	`Reply`
`Broadcast`	A diffuse message delivered to multiple recipients.	`Broadcast`

Modulation and brain-region terms

Term	Definition	Examples
`Modulator`	A dynamic runtime influence injected to shape behavior without redefining identity.	`DopamineModulator`
`Cocktail`	A grouped runtime state configuration assembled from one or more modulators.	`ModulatorCocktail`
`Neuromodulators`	The mediation boundary and runtime registry that receives signals from RAS and fans out to synthesizers.	`Neuromodulators`
`Synthesizer`	A factory that produces modulators in response to broadcast requests.	`CortexLaminaSynthesizer`
`Cerebrum`	The top-level domain expert system. Owns the thalamus, periphery, and cortex population.	`Cerebrum`
`Thalamus`	The central relay and gatekeeper for cortical communication.	`Thalamus`
`Hippocampus`	The memory substrate that indexes percepts for later recall.	`Hippocampus`
`RAS`	The broadcast system that requests modulators from synthesizers.	`RAS`
`CorticalRelay`	A relay specialized for communication between cortices, gated by the thalamus.	`CorticalRelay`

Verb conventions

These are not nouns, but they are part of the established vocabulary and should be used intentionally to avoid software-default verbs.

Verb	Meaning	Replaces
`bind`	Attach a functional dependency.	`set`
`retrieve`	Read a bound dependency without removing it.	`get`
`release`	Release stored contents from a vesicle.	`dequeue`
`dissociate`	Remove a binding. Produces an apo state, not a null state.	`unbind`, `unset`

How it is used

This ontology is intended to be used consistently in:

class names and interfaces
documentation and architecture references
review discussions and design decisions
implementation naming across related subsystems

The goal is not maximum cleverness. The goal is immediate clarity.

Example: Periphery vs Peripheral

Periphery and Peripheral are a concrete example of the same rule that governs the wider system. They are not random variants; they are the same grammatical pattern used elsewhere, such as Cortex / Cortical, Thalamus / Thalamic, and Cerebrum / Cerebral.

This example is a good demonstration because it makes the distinction explicit:

Periphery = the domain itself
Peripheral = something that belongs to or comes from that domain

See the detailed breakdown here: Periphery vs Peripheral

Canonical rule

When naming something, ask: is this the domain itself, or is this something that belongs to the domain?

If it is the domain itself, use the noun form. If it is in or from the domain, use the adjective form.

That distinction is the foundation of the project naming ontology.

Semantic Suffixing Naming System

The general architectural naming system for Laminae, Substrates, Synthesizers, Signals, Replies, and Modulators.

Read reference →

Periphery vs Peripheral

A concrete example of the ontology in practice, including the domain noun vs domain-owned adjective rule.

Read example →