Cell-Node Parameters
An exploratory concept for modular parameter organisation and domain knowledge representation, so components can be added, replaced or removed.
Overview
CNP is an exploratory concept for how parameters could be organised inside the cell and node structure, so that components can be added, replaced, disabled or removed.
A node is a logical unit
A node represents a logically scoped knowledge or capability component — “organic chemistry”, say, or “Python debugging”. It is an architectural unit made of many parameter tensors, not an individual scalar weight in a neural network.
Cells inside nodes
Following the 3CN idea, each node’s parameters are split across a Knowledge cell, a Thinking cell and a Reasoning cell. CNP asks how those cells map onto concrete weight groups: separate layers, adapters, shared blocks with node-specific parts, or something else.
Parameter groups by domain
Modules contain parameter groups. Groups can be organised by domain so that the weights relevant to a field live together — which is what makes them possible to load, quantise or remove as a unit.
Disconnect a module. See what changes.
The interactive module-removal diagram needs JavaScript.
Add, replace, disable, remove
- Add — attach a new module and teach the router when to use it.
- Replace — swap a module for an improved one with a compatible interface.
- Disable — keep the weights on disk but never route to them.
- Remove — delete the module entirely; its capability goes with it.
In real terms these are operations on weight files, router tables and memory residency — not on abstract boxes in a diagram.
Hypothetical configurations
The comparison below is illustrative. It shows the shape of the trade-off, not measured figures.
An interactive, hypothetical memory-budget illustration (requires JavaScript).
Why removable components matter
A smaller deployment could carry only the modules its user needs: a coding assistant without medicine, a field kit without music theory. The shared core stays; the domain depth is chosen. That only works if removing a module degrades gracefully instead of breaking the system.
Technical challenges
- Stable interfaces between the core and modules across versions.
- Training modules separately without drifting away from the core.
- Graceful degradation when a needed module is missing.
- Routing that knows what has been removed.
- Measuring real memory residency, not just theoretical parameter counts.