Scientific manuscript · Closed study

Oracle Primitive Model

Shared procedural computation for transfer to withheld domain–operation combinations.

Protocol
v1.1.4
Primary H1
Supported
Mechanism
Not supported
Study state
Closed · 27 Aug 2026
Chapter 02 of 09

Theory and preregistered hypotheses

The OPM program treats reuse as a functional and causal property of computation—not as a label assigned to a module or a pattern observed in latent space.

2.1 · Governing thesis

Reusable computation should transfer when surface form changes but causal structure does not.

The OPM research program begins from a structural hypothesis: several domains may require the same bounded operation even when their surface vocabularies, object types, and renderers differ. A network that stores a separate implementation in each domain receives no direct computational benefit from this common structure. A network that continuously reuses the same operation-specific parameters receives training evidence from every domain in which that operation appears.

This parameter recurrence creates a testable transfer prediction. If an operation is omitted from one domain during training but learned in the other domains, a genuinely shared implementation should remain available when the operation is later requested in the held-out domain. A domain-specific implementation, by contrast, has no trained copy for that combination.

Learn reusable computational primitives, compose them into procedures, and preserve only the domain-specific differences that causally matter.
2.2 · Proposed causal model

From a rendered task to a shared state transition.

The oracle supplies decomposition, not the answer. The scientific variable is whether the selected operation executes through parameters shared across domains.

  1. 01Rendered task

    Domain-specific facts and a query describe one latent relational problem.

  2. 02Oracle bindings

    Typed arguments, selected evidence, operation token, and order are supplied.

  3. 03Primitive transition

    One operation-specific module updates a compact execution state per step.

  4. 04Binary decision

    The decoder reads only the final execution state.

Shared procedurep = Ck₂ ∘ Ck₁

At most two sequential primitive calls; one selected module per active step.

2.3 · Why an oracle?

The experiment isolates execution from discovery.

A mature system would need to infer arguments, operations, and procedure order. OPM v1.1.4 deliberately does not test that full problem. Stage A supplies the correct typed bindings, the abstract operation sequence, and execution order through a fixed arbitrary operation-to-module permutation for each seed.

This makes the experiment an upper-bound test. Success means reusable execution is viable under ideal decomposition; it does not mean the system can discover that decomposition autonomously. Failure would have shown that learned parsing or routing could not rescue the proposed execution mechanism.

The oracle may provide

Typed argument bindings, abstract operations, a bounded procedure skeleton, and operation order.

The oracle may not provide

The target answer, label-correlated shortcuts, hidden facts, or a route code that makes the world evidence unnecessary.

2.4 · Operational definition

A module is not reusable merely because several domains select it.

The charter requires a convergent pattern across behavioral transfer and causal intervention. No single probe or embedding visualization is sufficient.

01

Parameter recurrence

The same parameters execute compatible operations originating in multiple domains.

02

Cross-domain interchangeability

Compatible states can cross domain pathways without destroying the operative behavior.

03

Counterfactual consistency

Irrelevant domain or surface changes leave the primitive’s central result stable.

04

Argument rebinding

The computation continues to work for new entities occupying the same typed roles.

05

Composability

A primitive can participate in a new valid procedure, not only memorized whole-task configurations.

06

Causal specificity

Disabling or replacing it damages the associated behavior while substantially preserving unrelated abilities.

2.5 · Hypotheses

Four theories were separated so one success could not stand in for another.

Only H1 had a complete, executable decision rule in v1.1.4. H2 lacked a quality-matched resource threshold; H3 and H4 were explicitly out of scope.

H1
Compositional advantage

Shared primitives improve valid withheld combinations relative to non-sharing and generic controls.

SUPPORTED
H2
Theoretical resource advantage

At matched quality, sparse primitive execution reduces active parameters, active FLOPs, or duplicated storage.

NOT EVALUABLE
H3
Real hardware advantage

The theoretical savings improve latency, throughput, training time, memory, or energy on declared hardware.

NOT EVALUABLE
H4
Correct boundary of reuse

The architecture transfers genuinely shared rules without catastrophic transfer of domain-specific rules.

NOT EVALUABLE
2.6 · Falsification

What would have weakened the theory?

The central transfer account would be weakened if OPM_SHARED failed to outperform the domain-generalist control on valid withheld combinations, if its advantage disappeared under renderer changes, or if interpolation competence collapsed. The mechanism account would be weakened if ablations were nonspecific, adapters could solve the task alone, shared-state interchange failed, or evidence representations leaked the answer.

The charter also anticipates informative partial failures: successful reuse with poor hardware efficiency would separate H1 from H3; exact transfer with harmful domain-specific exceptions would separate H1 from H4; oracle execution with failed learned selection would establish a viable mechanism without autonomous decomposition.