AI Initiative lab

Modular ANN: learning in parts

Investigate whether intelligence can acquire useful capabilities through smaller, explicitly controlled changes, while preserving the ability to examine what changed.

Research implementation Experimental components and selective-training research. Useful transfer between tasks remains a research question.

Download this guide ↗Return to the story ↗

The design question

What can change without rebuilding everything?

The architecture separates the task’s meaning, the learned proposal and the mechanism that allows an action. That separation makes it possible to ask which change helped, which behaviour stayed useful and where exact computation is a better fit than learning.

A view of the responsibilities

A controlled learning experiment

01Define the activityDefine the question
02Choose what may changeKeep the responsibilities distinct
03Train a candidateFollow the chosen path
04Check the retained stateInspect what happened
05Evaluate and decideUse the result carefully

Across the flow

Declare the task and the model state allowed to change, then compare the candidate with its parent and evaluate both target and prior behaviour.

A responsibility-level flow through the work. It does not imply that separate experiments or applications are one deployed service. Select a step to read its walkthrough.

What each part is responsible for

The building blocks

Task definition

Defines what an observation means, which outputs are legal and how an outcome is evaluated.

Receives: A task, observations and allowed outcomes
Produces: An explicit problem and comparison

Observation encoder

Converts a task observation into the representation expected by its model. Model and encoder compatibility are checked together.

Receives: A task observation and representation choice
Produces: A compatible model input

Learned policy

Produces a task-specific proposal. Sharing numerical machinery does not make different tasks or checkpoints interchangeable.

Receives: A compatible observation and fixed model state
Produces: A task-specific proposal

Selective training

The research candidate supports training the output stage while keeping the remaining declared state fixed. Full training remains a separate choice.

Receives: A parent model, examples and permitted change scope
Produces: A candidate model with a declared change scope

Checkpoint and comparison record

Connects an experiment to its starting state, resulting state and evaluation. It supports comparison and recovery rather than treating every change as progress.

Receives: Parent and candidate states with experiment context
Produces: A comparison record and a recoverable starting point

Typed coordination and action checks

Carries proposals between components with explicit meaning. A separate runtime decides whether an action can occur.

Receives: A typed proposal and current runtime state
Produces: An accepted action or an explicit refusal

Evaluation

Examines the new task, earlier abilities and the combined activity. Preserving parameters alone does not establish preserved behaviour.

Receives: Held-out cases, reference methods and candidate outputs
Produces: Evidence about target behaviour and relevant prior abilities

Following one piece of work

How the flow fits together

01Define the activity

State what the input represents, what counts as a valid output and how the activity will be assessed. This makes a useful comparison possible: a candidate should be judged on the same problem as its reference, including what information it is allowed to see.

02Choose what may change

Begin from a known state and declare the part to be trained. The inspected research includes a bounded output-stage update while other declared state remains fixed. This is a controlled experiment, not a general mechanism that can adapt arbitrary learned skills.

03Train a candidate

Use the defined examples and objective to produce a candidate. Mathematical routines, task validation and model updates have different responsibilities. A reduction in the amount of trainable state is only one part of cost; encoding, data preparation and evaluation still matter.

04Check the retained state

Compare the resulting state with the declared change scope. Also check the input representation: keeping parameters fixed does not preserve behaviour if the meaning of the inputs changes. Retain the parent so the comparison can be repeated or the candidate rejected.

05Evaluate and decide

Examine held-out target behaviour, relevant prior activities and the cost of the complete experiment. Compare against a suitable fresh model or deterministic reference. Keep, revise or reject the candidate according to the result, without treating a successful small example as general transfer.

Illustrative example · not a benchmark result

Illustrative experiment

A new classification activity uses an existing compatible feature representation.

Train only its output stage, retain the parent state and compare the resulting behaviour with a fresh model and an exact-rule baseline.

The useful result: A comparison of learning effort, target performance and relevant prior behaviour.

A successful small activity would not establish useful transfer to unrelated tasks or a general reduction in total learning cost.

What is learned, remembered or calculated?

Learning: Training changes selected model state in response to examples and an objective.

Memory: Experiment records and runtime state preserve context; keeping a record does not retrain the policy.

Exact computation: Arithmetic, input validation, legality and resource accounting can use deterministic code. They do not need to be learned.

Future composition: A general catalogue of named learned skills, arbitrary adaptation and autonomous architecture evolution are wider proposals, not claims about this baseline.

Reading the architecture accurately

Scope and status

What the work covers

Experimental components and selective-training research. Useful transfer between tasks remains a research question.
Training changes selected model state in response to examples and an objective.
Experiment records and runtime state preserve context; keeping a record does not retrain the policy.
Arithmetic, input validation, legality and resource accounting can use deterministic code. They do not need to be learned.

What this work does not establish

Universal transfer between unrelated tasks.
A production security boundary for hostile code.
An autonomous architecture-evolution controller.
A general learning-speed improvement inferred solely from fewer trainable parameters.

Where the design must hold up

Boundaries and evaluation

Boundary	Why it matters	How to examine it
Representation changes	A changed encoder can change behaviour even when model parameters are frozen.	Check the meaning and output of the encoder as well as the declared frozen model state; compare behaviour before and after the change.
Checkpoint compatibility	Matching numerical dimensions does not make a checkpoint appropriate for a different task or representation.	Confirm that the task, observation meaning and permitted outputs match; exercise an intentionally incompatible case and require an explicit rejection.
Generalisation and retention	A good training score can conceal poor held-out performance or loss of an earlier ability.	Use held-out target cases and relevant prior tasks, with a fair reference and the total cost of the experiment included.
Execution trust	The local runtime controls cooperating components; it is not a security sandbox for hostile code.	Demonstrate which local actions are accepted or refused. Evaluate hostile-code containment separately before treating it as a security boundary.