Models, controls, and comparison logic
The four neural conditions were not chosen as a generic benchmark suite. Each one removes or changes a specific part of OPM so that the sealed comparison can answer a different causal question.
A single baseline could not identify what produced the advantage.
OPM combines structured oracle information, bounded sequential execution, operation-specific modules, sparse selection, and continuous parameter sharing across domains. Comparing it with an unrelated model would change too many variables at once. A performance difference could then be caused by the oracle, the interface, the training data, the execution depth, model capacity, or weight sharing.
The primary matrix therefore used a family of closely related neural models. Their encoders, typed inputs, oracle bindings, maximum two-step execution, training examples, optimization budget, checkpoint rule, and declared seeds were held constant as far as the frozen specification allowed. The main manipulated variable was how the procedural transition parameters were organized and updated.
The comparison preserves the task and execution scaffold.
The goal was to change parameter sharing without changing the information available to the models.
Typed arguments, selected evidence, operation tokens, and execution order were supplied identically.
Fact and query encoders, entity embeddings, state dimension, and decoder were shared in design.
One selected transition per step and at most two sequential calls.
Identical train, validation, and sealed test generators and fingerprints.
Five seeds, 50,000 steps, shared pilot-selected learning rate and dropout.
Observed-cell macro-validation selected one checkpoint per run without sealed labels.
What each model was designed to test.
Outcome values are pooled across the five declared seeds on the sealed recombination endpoint.
OPM_SHAREDContinuously shared operation primitives
Eight candidate primitive modules are available; four active modules correspond to the four operations through a fixed seed-specific permutation. The same operation module is executed in PROGRAM, SCENE, and SET.
- Question
- Does putting the same procedural parameters behind an operation allow training in one domain to remain available in another?
- Why it mattered
- This is the architecture under test. It turns cross-domain experience into updates to one shared operation-specific transition instead of three separate copies.
DOMAIN_GENERALISTOne general transition per domain
Each domain has one transition module shared across its observed operations. A 32-dimensional operation embedding is shared globally, so the model knows which operation was requested without receiving an operation-specific shared transition.
- Question
- Could a strong domain model combine a trained domain pathway with shared operation information and generalize without reusable operation modules?
- Why it mattered
- This is the decisive scientific control. Its target-domain transition was trained on other operations, and its operation embedding was trained in other domains. It is also capacity-advantaged by a wider transition input.
PROC_UNTIEDIndependent procedural modules by domain
The primitive interface, oracle information, and active execution are identical to OPM, but every domain owns a separate copy of each primitive. The held-out domain–operation copy receives no training.
- Question
- What happens when the correct procedural structure exists but operation weights cannot transfer between domains?
- Why it mattered
- This isolates the availability of trained operation weights. It has three times the stored primitive parameters while using the same active primitive FLOPs, but defeating it alone cannot support H1 because its target copy is untrained.
PROC_CLONEIdentical starting modules that become untied
Domain-specific primitive copies begin from the same seed-specific active-module template, then receive independent updates for the rest of training.
- Question
- Is a shared starting point enough, or must weights remain tied throughout training for recombination transfer to emerge?
- Why it mattered
- This separates shared initialization from continuous sharing. If cloned modules transferred like OPM, the result could be attributed to beginning from the same representation rather than accumulating cross-domain updates in one module.
Each contrast eliminates a different explanation.
The evidence becomes stronger as the alternative model is given more useful information about the held-out combination.
- DiagnosticOPM_SHARED versus PROC_UNTIED
Tests whether trained operation weights being available across domains matters. The untied target copy is untrained, so this is the expected transfer diagnostic—not the sole scientific test.
Δuntied +49.7822 pp - InitializationOPM_SHARED versus PROC_CLONE
Rules out identical starting weights as a sufficient explanation. The cloned modules began together but diverged because they did not share continuous updates.
+49.7811 pp - Primary H1OPM_SHARED versus DOMAIN_GENERALIST
Tests whether operation-specific cross-domain computation adds value beyond a trained domain pathway plus globally shared operation information. This is the preregistered principal comparison.
+42.6200 pp
ORACLE_SYMBOLIC was an upper-bound and data-contract check, not a neural H1 baseline.
The frozen model specification also defined a programmed executor that applied the formal task rules directly. Its purpose was to confirm that the generated examples were solvable under the declared algebra and to supply a mechanism sanity check. It had no learned encoder, no trainable primitive modules, and no optimization trajectory, so comparing its accuracy with OPM would not isolate neural parameter sharing.
The symbolic-oracle accuracy required by the composite mechanism criterion was not present in aggregate v4. Its formal status was therefore NOT_EVALUABLE. The paper does not infer or reconstruct that missing value.
Important models that v1.1.4 did not test.
These comparisons were deliberately deferred until their inputs, pooling, routing, compute accounting, and matching rules could be preregistered exactly.
OPM_DENSE_EXECDense-execution primitive control
Would execute every candidate primitive before retaining the same selected transition, isolating sparse execution from primitive organization.
Not executed in canonical v1.1.4DENSE_TRANSFORMERConventional dense baseline
Would test whether an ordinary non-modular network reaches the same quality without an explicit procedural interface.
Not executed in canonical v1.1.4VANILLA_MOELearned-routing mixture of experts
Would test whether conventional expert routing matches the quality–compute frontier without ordered primitive execution.
Not executed in canonical v1.1.4ORACLE_MOEOracle-informed mixture of experts
Would separate the value of privileged decomposition information from the value of the OPM primitive interface.
Not executed in canonical v1.1.4The primary result is not simply “OPM beat three models.” It is that continuous operation-specific sharing beat a strong trained domain pathway under the same oracle-guided procedural task.