DeepThink: A Conceptual Model for Knowledge-Addressable Recurrent Language Modeling

Weiguo Chen

Source-linked AI summary

DeepThink: A Conceptual Model for Knowledge-Addressable Recurrent Language Modeling

Weiguo Chen

arXiv:2610.16171v1Oct 12, 2026cs.CL

TL;DR

DeepThink addresses how language models can make parameterized content addressable and recombine it across state updates. It formalizes a recurrent framework that selects and assembles knowledge configurations for a shared operator, and establishes exact fixed-schedule realization of existing models under stated compatibility conditions. The paper presents this as a route from pretrained models to dynamically selected recurrent computation, while leaving its empirical effectiveness open.

Problem
The paper asks how parameterized content can be selected and recombined across state updates while retaining a stable computational interface.
Source: §1.1.2 · p. 6
Method
DeepThink uses a Knowledge Bank, state-conditioned activation, typed assembly, and a shared recurrent operator to organize addressable parameter configurations.
Source: §1 · p. 6, §2.3.1 · p. 9
Results
For compatible templates and complete runtime-state configurations, fixed-schedule execution exactly preserves the corresponding pretrained model's complete states and final output.
Source: §4.2.1 · p. 15, §4.2.2 · p. 15
Takeaways & Limitations
The framework separates stored capacity, active width, and recurrent depth while providing a route for reusing pretrained models in dynamic recurrent computation.
Source: §1 · p. 6, §1.2.2 · p. 7
The manuscript reports no experiments, leaving dynamic selection effectiveness, reusable-unit emergence, budget allocation, and pretrained-capability retention open for study.
Source: §8.3.2 · p. 25

Abstract

from arXiv · show

This manuscript presents DeepThink, a knowledge-addressable framework for recurrent language modeling. A Knowledge Bank stores typed Knowledge Units, a Knowledge Activator selects units from the current execution state, Knowledge Assembly produces an executable configuration, and a Shared Thinking Operator updates that state. An output stage then organizes generation. This organization exposes knowledge capacity, activation width, and recurrent depth as separate design variables, supporting both complete parameter packages and fine-grained expert or low-rank modules. We formalize the interfaces and their execution semantics, including state-dependent selection, parameter-space assembly, and thinking followed by generation. For compatible templates and complete runtime-state configurations, we establish an exact Fixed-Schedule Realization of an existing fixed-depth model. Exact shared-base reparameterization and pretrained output-tail reuse provide complementary initialization constructions. Together, these results define a route from pretrained models to dynamically selected and assembled recurrent computation. A synthesis of conditional computation, recurrent models, modular parameters, and knowledge interfaces positions DeepThink within the research landscape and identifies the design questions arising from their integration.

1. Overview and Architectural Motivation

DeepThink treats learned parameter content as addressable configurations applied through reusable state updates. Its design separates stored knowledge, selection, recurrent computation, and output organization while allowing those interfaces to share parameters.

1. Overview and Architectural Motivation

DeepThink organizes language modeling around addressable parameter content and reusable state updates, making storage, execution order, and output organization explicit.The framework offers a vocabulary for dynamic architectures and a route for reusing pretrained models.Source: §1 · p. 6

1.1.1. Computation and Memory in the von Neumann Perspective

The von Neumann analogy separates stored learned payloads from the shared operator that applies them, but does not prescribe hardware memory layout.Knowledge Units are computational payloads, not machine instructions or symbolic facts.Source: §1.1.1 · p. 6, Figure 1 · p. 6

1.1.2. Parameterized Content in Language Models

DeepThink makes parameter configurations addressable so content can be selected and recombined across a sequence of state updates.The motivating question is how to do this while retaining a stable computational interface.Source: §1.1.2 · p. 6

1.1.3. Repeated Templates and Depth-Specific Parameters

Repeated templates with depth-specific configurations motivate separating an execution template from the parameters that give each invocation its behavior.For heterogeneous backbones, typed operators preserve distinctions in the original computation graph.Source: §1.1.3 · p. 7

1.2.1. Addressable Knowledge and Shared State Updates

The Knowledge Bank stores numbered units, while the activator selects them from the current state and assembly configures the shared operator for an update.A fixed schedule provides an initial policy for which content is called and when.Source: §1.2.1 · p. 7

1.2.2. Knowledge Capacity, Activation Width, and Recurrent Depth

Bank size N, activation width K, and recurrence budget R independently control available units, units selected per decision, and state updates.Increasing N need not increase K or R, although routing cost can still depend on N; the content and size of units also affect capacity.Source: §1.2.2 · p. 7, Figure 2 · p. 8

1.3.1. Interface Roles and Parameter Ownership

Distinct roles for storage, selection, assembly, state transition, and output make parameter configurations independently addressable while shared parameters participate in execution.Implementations can fuse operations for efficiency while preserving their interfaces.Source: §1.3.1 · p. 7

1.3.2. Reusable Content and Shared Thinking

Reusable content can serve different computational situations as the state evolves, while a common operator organizes its application across successive updates.The terms knowledge and thinking describe these intended computational roles.Source: §1.3.2 · p. 8

2. Core Architecture and Execution

DeepThink specifies a recurrent execution interface in which compatible knowledge units are selected and assembled to configure a shared operator. The complete runtime state, legal information at each token position, assembly semantics, and output handoff define the execution contract.

2.1.1. Hidden Representations and Complete Runtime State

The execution template determines components such as attention and normalization, while its configuration specifies behavior and the state passed between invocations.The complete state includes hidden representations and persistent workspace, caches, counters, and other runtime state; activation must respect the available autoregressive prefix.Source: §2 · p. 8, §2.1.1 · p. 8, §2.1.2 · p. 9

2.2.1. Identifiers, Parameter Payloads, and Compatible Interfaces

A Knowledge Unit pairs a stable identifier and execution interface with a compatible parameter payload or functional module.Units can be experts, adapters, or complete block configurations; types specify dimensions and calling semantics, and incompatible types require an explicit adapter.Source: §2.2.1 · p. 9, §2.2.2 · p. 9

2.3.1. State-Conditioned Selection and Top-K Activation

At each update, the activator scores eligible identifiers from a query and current state, and Top-K selects the highest-scoring compatible units.Selection and weighting are separate policies, normalization is optional, and state-dependent policies may retain or change selections as representations evolve.Source: §2.3.1 · p. 9

2.3.2. Fixed Policies and Routing Granularity

A fixed schedule can choose units by execution position, while dynamic routing may operate per prefix, token, sequence, or local interface.K counts units per decision, so tokens can collectively access more than K distinct units; fixed outer scheduling can coexist with routing inside a stored payload.Source: §2.3.2 · pp. 9–10

2.4.1. Parameter-Space and Function-Space Composition

Knowledge Assembly maps selected payloads and optional coefficients to a typed executable configuration, with composition rules specified by the interface.For nonlinear modules, mixing parameters before evaluation can differ from mixing independently evaluated outputs; the ReLU example yields 0 versus 1/2, while the distinction disappears for purely linear increments.Source: §2.4.1 · p. 10, Figure 3 · p. 10

2.4.2. Sets, Ordered Selections, and Assembly Semantics

Permutation-invariant combinations use a selected set, whereas ordered composition requires an explicit order policy aligned with ranking and coefficient indexing.A singleton-preserving contract returns the original unit configuration when its sole coefficient is one.Source: §2.4.2 · p. 11

2.5.1. Recurrent State Transitions and Stopping

The shared operator updates the complete state using the assembled configuration, and an optional controller can choose a stopping time within the recurrence budget.Stopping determines the number of updates; activation determines which units contribute to an update.Source: §2.5.1 · p. 11

2.5.2. Output Interfaces and Execution Traces

After the executed updates, the output stage maps the terminal state to logits, a distribution, or a generated object under a specified decoding policy.Execution traces record state and invocation decisions, selection frequencies, and state evolution; generation-state updates must follow the declared output contract.Source: Figure 4 · p. 11, §2.5.2 · p. 12

3. Parameterizations and Architectural Configurations

DeepThink separates parameter storage and selection from recurrent state updates, with configurations ranging from complete block packages to local modules. It also distinguishes recurrent computation from output organization and supports heterogeneous computational graphs.

3.1.1. Complete Parameter Packages and Expert Modules

Complete packages bind a block’s parameters and settings, while expert functions operate at local interfaces and require a combination rule and compatible intermediate states.Complete packages are particularly useful for preserving pretrained behavior.Source: §3.1.1 · p. 12

3.1.2. Shared Bases and Low-Rank Increments

Low-rank increments add unit-specific factors to a shared linear base, with the rank budget controlling the representable increments.With a fixed shared bias, evaluating selected linear branches matches materializing the effective matrix.Source: §3.1.2 · p. 12

3.2.1. A Recurrent Core with an Output-Organizing Stage

The recurrent core updates state before an output stage of L conventional layers and a head; when L=0, the state goes directly to the head.The output stage may retain distinct pretrained parameters.Source: §3.2.1 · p. 12, Figure 5 · p. 13

3.2.2. Reusing the Pretrained Generation Tail

Retaining a pretrained output tail and its state-handling rules offers a behavior-preserving initialization while adaptation focuses on the recurrent path, selection policy, and state interface.This separates recurrent state refinement from subsequent output organization.Source: §3.2.2 · p. 13

3.3.1. Independent Banks for Local Computational Slots

Each compatible local slot has its own bank and activation policy, selecting payloads from its input to configure the local operation within each outer update.Slots can be serial, parallel, or branching, following the original dependency graph.Source: §3.3.1 · p. 13, Figure 6 · p. 14

3.3.2. Typed Templates and Heterogeneous Computation Graphs

Typed templates allow different module types, widths, banks, and selection rules while preserving the specified order of serial, parallel, or branched dependencies.The outer recurrence reuses the typed graph, with local banks supplying configurations at its slots.Source: §3.3.2 · p. 14

4. Static Realizations of Existing Language Models

The section constructs a fixed-schedule path through DeepThink interfaces that can reproduce compatible pretrained models. Its realization depends on complete configurations and preserved runtime behavior, and extends to typed templates and retained output tails.

4. Static Realizations of Existing Language Models

A fixed-depth model supplies a reference path through DeepThink interfaces before any dynamic policy is learned.The construction is a starting point for pretrained migration.Source: §4 · p. 14

4.1.1. Complete Configuration and Template Compatibility

Compatibility requires one shared template and configurations that preserve every needed parameter and layer-specific rule, including normalization, biases, gates, and structural constants.The execution state includes hidden representations and persistent runtime state.Source: §4.1.1 · p. 14

4.1.2. Singleton Assembly and Preserved State Transitions

Singleton assembly returns the selected complete configuration unchanged, while preserving initialization, context, output mapping, state transitions, and cache identities and update schedules.Preserving cache behavior extends the realization to incremental generation.Source: §4.1.2 · p. 15

4.2.1. Proposition and Realization Conditions

Under complete configurations, identity singleton assembly, and preserved initialization, output, and runtime rules, a depth-D model’s scheduled realization matches every corresponding state and final output.The result is exact in real arithmetic and holds pathwise for matched stochastic choices.Source: §4.2.1 · p. 15

4.2.2. Typed Realization of Heterogeneous Backbones

A finite schedule of compatible typed templates yields the same realization when each template preserves its original transition, interfaces, and execution dependencies.The schedule retains adapters, branch dependencies, and intermediate states.Source: §4.2.2 · p. 15

4.3.1. Representation-Level Containment

The fixed-depth model family satisfying the realization contract is contained in the DeepThink family, which also exposes state-conditioned selection, repeated invocation, and compatible assembly.The inclusion represents the original parameter sequence as an addressable fixed schedule.Source: §4.3.1 · p. 15

4.3.2. From Layer Positions to Addressable Configurations

The construction turns layer positions into addressable configurations, providing a behavior-preserving path before shared numerical cores or compressed payloads are introduced.Initially, depth-specific numerical parameters can remain in payloads while the shared component is the execution template.Source: §4.3.2 · p. 16

5. Migration from Pretrained Language Models

DeepThink migrates pretrained models by first preserving their configurations and execution schedule, then introducing learned activation, assembly, recurrence, or compression. Complete configurations and complete deltas preserve the fixed-schedule function under the execution contract; changing routes or discarding residuals changes that reference computation.

5.1.1. Encapsulating Existing Parameters and Runtime Rules

Registering original configurations as knowledge units preserves the pretrained parameters and runtime rules while a shared template executes each selected package.Preserve input embeddings, position handling, causal rules, output parameters, and relevant parameter ties.Source: §5.1.1 · p. 16

5.1.2. Initializing the Original Execution Schedule

The original schedule selects unit t + 1 with weight one for D steps, providing a pretrained-function initialization without a learned selector.Additional iteration features or controls must be disabled or behaviorally neutral.Source: §5.1.2 · p. 16

5.2.1. Exact Reconstruction with Complete Deltas

Complete deltas around a shared base reconstruct the original parameters exactly in real arithmetic and preserve the fixed-schedule function when other parameters and runtime rules remain intact.The shared base provides a common reference while complete deltas retain layer-specific differences.Source: Singleton selection with unit weight… · p. 16

5.2.2. Rank Conditions and Retained Approximation Residuals

Low-rank payloads reconstruct exactly when their rank budget accommodates the residual rank, or when the residual is retained; discarding residuals can make the representation approximate.Truncated singular-value decomposition is cited as a standard approximation.Source: §5.2.2 · p. 17

5.3.1. Learning Activation and Assembly Policies

A trainable activator can move from imitating the original schedule to state-dependent selection, while compatible assembly enables parameter interpolation, nonlinear expert-output mixtures, or reordered transitions.Task and retention objectives guide the resulting execution policies.Source: §5.3.1 · p. 17

5.3.2. Extending Knowledge Libraries and Recurrence Budgets

New compatible units can expand the bank without renumbering existing units, but changing recurrence budgets or reuse patterns changes encountered states and cache paths.Adaptation learns to use the expanded library and the newly reached runtime states.Source: §5.3.2 · p. 17

5.4.1. Exact Encapsulation and Interface Refinement

Migration registers configurations, exposes typed slots or complete deltas, then learns policies and selects compressed ranks; the first two stages retain the original schedule.Dropping a residual belongs to compression, not exact interface refinement.Source: §5.4.1 · p. 17

5.4.2. Adaptation, Retention, and Output-Stage Reuse

Retaining the final L transitions and original output map as a generation stage preserves the pretrained input–output function while the preceding Dpre blocks form the recurrent prefix.The prefix depth is Dpre = D − L.Source: §5.4.2 · pp. 17–18

6. Learning Objectives and Resource Considerations

The section specifies language-modeling and retention objectives, approaches to training discrete routing and balancing usage, and distinguishes stored capacity from active computation. It also notes that routing, repeated execution, data movement, and runtime-state ownership contribute to implementation costs.

6.1.1. Language Modeling and Conditional Generation

The language-modeling objective trains conditional generation, while legal prediction queries must observe the same information boundary as their conditional probabilities.The input representation, shared parameters, knowledge payloads, activator, and output stage may be learned jointly or in selected groups.Source: §6.1.1 · pp. 18–19

6.1.2. Distribution Matching to the Pretrained Model

A retention objective matches student next-token distributions to a pretrained teacher; it is zero when their distributions coincide under Proposition 1 and constrains adaptation after routes, payloads, or recurrence budgets change.The adaptation distribution determines which pretrained behaviors the retention term emphasizes.Source: §6.1.2 · p. 19

6.2.1. Discrete Selection and Singleton-Routing Gradients

Hard Top-K separates discrete support selection from coefficient weighting, and route imitation supplies an initial supervised policy without differentiating the discrete support.The original schedule serves as the reference policy.Source: §6.2.1 · p. 19

6.2.2. Load Balance and Functional-Specialization Objectives

A usage penalty can encourage bank usage toward target proportions, while retention, route-imitation, and balance terms can be combined with stage-specific hyperparameters.The target proportions specify desired allocation; the squared penalty is one possible choice.Source: §6.2.2 · pp. 19–20

6.3.1. Stored Capacity Versus Active Parameter Use

Stored parameter capacity differs from per-update activation: a large N can coexist with small K, but stored payloads, gradients, and optimizer state still require an implementation strategy.Across a token sequence, the union of selected IDs can exceed K; compression requires a representation change.Source: §6.3.1 · p. 20

6.3.2. Routing, Assembly, Recurrence, and Cache Ownership

Execution cost includes routing, assembly, state transitions, repeated computation, and data movement; cache ownership follows executed stages and their dependencies.Parameter sharing avoids extra parameter copies but repeated execution still incurs work and training activations.Source: §6.3.2 · p. 20

7. Research Landscape and Positioning

The research landscape combines sparse capacity, recurrence, modular parameters, parameter assembly, and staged output processing. DeepThink positions these mechanisms around addressable content, explicit assembly, shared state updates, and pretrained execution, while identifying the interface choices involved in integrating them.

7.1.1. Sparse Expert Banks and Active Computation

Sparse expert systems already separate stored capacity from active expert use; DeepThink adds recurrent execution and an explicit assembly interface to that design perspective.A large bank with a small activation width is an established principle.Source: §7.1.1 · p. 21

7.1.2. Fine-Grained Experts and Product-Key Retrieval

Product-key retrieval and PEER are relevant to K ≪ N because dense scoring of every bank entry can itself become expensive.Total execution cost still includes search, selection, and data movement.Source: §7.1.2 · p. 21

7.2.1. Shared Depth and Adaptive Halting

Universal Transformers and Adaptive Computation Time establish recurrent depth and learned update counts; DeepThink makes the selected parameter configuration an explicit input to each shared transition.These mechanisms show that effective depth need not equal the number of distinct parameterized layers.Source: §7.2.1 · p. 21

7.2.2. Iterative Experts and Cross-Layer Expert Reuse

MoEUT, Chain-of-Experts, and MoRE cover recurrent experts, iterative reselection, and cross-layer banks; DeepThink specifies bank scope, payload types, assembly semantics, and pretrained execution in a common interface.The interface vocabulary supports comparisons among these recurrent and cross-layer designs.Source: §7.2.2 · p. 21

7.2.3. Latent Feedback and Output-Stage Organization

Depth recurrence updates representations within model depth, while Coconut feedback advances sequence positions; DeepThink’s knowledge activation can coexist with MoR’s allocation of shared computation.Changing recurrence budgets can affect later representations or cache entries depending on caching strategy.Source: §7.2.3 · pp. 21–22

7.3.1. Low-Rank Modules and Routed Adapter Libraries; 7.3.2. Parameter Merging and Weight Generation

Low-rank adapters and routed adapter libraries provide mechanisms for modular payloads, while parameter-space merging differs from mixing independently computed nonlinear expert outputs.Payload granularity ranges from task adapters spanning layers to local typed slots.Source: §7.3.1 · p. 22, §7.3.2 · p. 22

7.3.3. Pretrained Conversion and Depth-Specific Residuals

RRT offers a pretrained conversion route using approximate residuals; DeepThink’s complete residual payloads with the original singleton schedule provide an exact starting representation.Reducing residual rank can introduce approximation unless the discarded residual is retained; state-conditioned selection is a further adaptation step.Source: §7.3.3 · p. 22

7.4.1. Parametric Memories, Knowledge Adapters, and Retrieval; 7.4.2. Fixed Templates and Conditional Representation; 7.5.1. Mechanism-Level Comparison with Closest Architectures; 7.5.2. Established Mechanisms and the DeepThink Proposal

DeepThink distinguishes callable parameter payloads from document retrieval and supervised knowledge adapters, and organizes established mechanisms around addressable content, assembly, and shared updates.Its integrated design choices include bank scope and type, assembly semantics, recurrent and output boundaries, and initialization from an existing model.Source: §7.4.1 · p. 23, §7.4.2 · p. 23, §7.5.1 · p. 23

8. Design Implications and Open Questions

DeepThink separates knowledge capacity, activation width, recurrent updates, and output organization, while using shared computation to revisit or recombine knowledge as state evolves. The section connects this design to modular adaptation and pretrained reuse, and identifies open questions; the manuscript reports no experiments.

8.1.1. Independently Configurable Knowledge and Compute Controls

Separate controls for available units, active units, recurrent updates, and output depth let knowledge capacity and computation be adjusted independently.The shared operator can revisit units, combine them differently, or switch configurations as state evolves.Source: §8.1.1 · p. 24

8.1.2. Modular Updates and Pretrained Capability Reuse

Addressable units can be retained, replaced, extended, or frozen while preserving common interfaces, making domain adaptation and library growth expressible as local operations.A pretrained path can populate the bank, initialize activation in the original order, and retain a ready generation interface for staged adaptation.Source: §8.1.2 · pp. 24–25

8.2.1. Reusable Knowledge Units and Computational Organization

Complete configurations favor pretrained compatibility, while local experts and low-rank modules offer finer control over selected content.Open design questions include which unit types support reuse, how specialization emerges, and how composition interacts with evolving state.Source: §8.2.1 · p. 25

8.2.2. Dynamic Execution, Retention, and Generalization

State-conditioned activation expands a fixed execution path to include repeated calls, new combinations, and variable refinement budgets, with a retained generation stage as a comparison boundary.Open questions include cross-domain activation, stopping criteria, composition across slot types, scalable bank addressing, and allocating computation between latent refinement and language generation.Source: §8.2.2 · p. 25

8.3.1. The DeepThink Perspective

DeepThink treats language modeling as an evolving state repeatedly calling addressable configurations through shared interfaces, with conventional compatible layer stacks represented as fixed schedules.The framework links large libraries, sparse use, recurrent refinement, and separate output organization as a basis for exploring their interaction in existing models.Source: §8.3.1 · p. 25

8.3.2. Open Exploration

The manuscript presents architectural intuition, definitions, and formal constructions but reports no experiments.Dynamic selection, reusable units, budget allocation, and pretrained-capability retention remain open empirical questions.Source: §8.3.2 · p. 25

A.1.1. Deterministic Execution and Matched Randomness

Execution equivalence requires matched initialization, compatible complete configurations, the original schedule and output map, and corresponding random draws with matched conditional laws.Runtime state must preserve quantities that affect later transitions or outputs, including caches and counters; equal seeds alone do not ensure corresponding draws when call schedules differ.Source: §A.1.1 · p. 28, §A.1.2 · p. 28

A.3.1. Prefix Boundary and Empty-Tail Convention

The retained tail receives the complete corresponding boundary state, and residual-free low-rank reconstruction is exact when the delta rank does not exceed the rank budget.The prefix has D−L updates; when L=0, the output stage is the original output map and at least one recurrent prefix update is retained.Source: §A.3.1 · p. 28, §B.1.1 · p. 29

B.1.2. Local Approximation Specifications

The local approximation specifications describe discrepancies for a linear interface under fixed inputs and routing, and explicitly do not bound the full recurrent model when states or routes change.

B.1.2. Local Approximation Specifications

The local output discrepancy is specified for a fixed row-vector input, identical base and bias, and a decomposition of the delta into low-rank factors plus residual.The passage defines the comparison conditions but does not state a numeric discrepancy value.Source: §B.1.2 · p. 29
For an assembled selection, the comparison holds the input, selected support, and coefficients equal while accounting for each unit’s discarded residual.With nonnegative normalized coefficients, the bound is at most the input norm times the largest selected residual operator norm.Source: §B.1.2 · p. 29
The residual bound applies to one linear interface with fixed routing, not the full recurrent model after its states or routes change.For nonnegative normalized coefficients, the bound is ∥z∥2 max_i∈S_t ∥E_i∥op.Source: §B.1.2 · p. 29

B.2.1. Shared-Base Shift Invariance

A compatible shift of the shared base and unit deltas preserves effective matrices under the stated assembly conditions. Low-rank factors also admit equivalent internal coordinates without changing their increment or rank budget.

B.2.1. Shared-Base Shift Invariance

Singleton effective matrices and normalized weighted assemblies remain unchanged under a compatible shared-base shift.The shift convention is selectable when deltas remain admissible; freezing the base or fixing a factor convention chooses a parameter convention for learning.Source: §B.2.1 · p. 29
Full-delta factoring permits multiple shared-base choices, while rank-constrained libraries require each shifted delta to remain admissible.A frozen base or fixed factor convention selects the parameter convention used in subsequent learning.Source: §B.2.1 · p. 29

B.2.2. Equivalent Low-Rank Factorizations

Invertible changes to the low-rank factors’ internal coordinates preserve the same increment and rank budget.Constraints may select a particular factor convention during optimization.Source: §B.2.2 · p. 30

C. Operational Specifications

Operational specifications define typed payloads and assembly rules, then require execution to propagate complete mutable state and deliver it through an output boundary.

C.1.1. Knowledge Payload and Assembly Contracts

A typed unit records an ID, type, and execution payload; compatible assembly maps selected payloads and coefficients to a configuration accepted by an execution interface.Types specify dimensions, calling semantics, and compatible templates; equal dimensions alone do not make different operator kinds interchangeable.Source: §C.1.1 · p. 30

C.1.2. State-Transition and Output Contracts

An executor consumes the complete state, configuration, and legal context, then returns mutable information needed by later stages.The output stage consumes terminal state through its boundary map; sampled strings additionally require a decoding policy and corresponding random draws for coupled equal samples.Source: §C.1.2 · p. 30

C.2. Forward Specifications

The specifications define both fixed-schedule realization and state-dependent dynamic execution, then constrain causal queries, assembly order, and cache reuse. Together, these rules make execution depend on compatible units, runtime state, and the computation path.

C.2.1. Fixed-Schedule Initialization

Fixed-schedule realization runs compatible complete units in original order and applies the original output stage to the resulting state.It assumes the original unit order, compatible templates, and original runtime rules; the identity mapping is used when no representation change has been introduced.Source: §C.2.1 · pp. 30–31

C.2.2. State-Dependent Dynamic Execution

Dynamic execution selects compatible units from the current state, assembles their weighted configuration, and stops at a declared criterion or budget.A typed controller restricts admissible units, while active width K must not exceed the compatible-unit count at any executed update.Source: §C.2.2 · p. 31

C.3.1. Causal Queries and Order-Sensitive Assembly

At each target position, queries must depend only on the known prefix and legal external conditions, and selected transformations must preserve their intended order.Reversing sequential composition generally changes the function; parameter mixing before a nonlinearity also differs from averaging nonlinear expert outputs.Source: §C.3.1 · p. 31

C.3.2. Cache Ownership under Changed Execution Paths

Cache reuse must follow the executed computation, parameter configuration, and dependencies; changed units, coefficients, order, or budgets require validity checks.Exact initialization retains the original cache identity and update schedule.Source: §C.3.2 · p. 31