Code-Space Structural Cocoon

• Code-Space Structural Cocoon is a term that defines both a topology-aware spatial envelope for program logic and a metric framework for assessing code concentration.
• In object-spatial programming, the cocoon embeds data, connectivity, and control within explicit graph structures, enabling efficient, localized computation.
• In generative recommenders, the cocoon measures hierarchical code-space concentration through metrics like layer-wise entropy and top-K code concentration, diagnosing system collapse.

Code-Space Structural Cocoon is a term used in two distinct technical senses in recent arXiv literature. In "Object-Spatial Programming" (Mars, 20 Mar 2025), it denotes the spatial envelope created when data, connectivity, and control are unified through explicit graph-structured program constructs. In "Do Generative Recommenders Deepen the Information Cocoon? A Closed-Loop Simulation with LLM-powered User Simulators" (Yang et al., 16 Jun 2026), it denotes a model-level metric family for measuring concentration in the hierarchical code space generated by Semantic ID tokenization. The phrase therefore names either a programming-language construct for enclosing logic in a topology-aware execution substrate or an analytical lens for diagnosing collapse within discrete generative code hierarchies.

1. Terminological scope and dual usage

A common source of confusion is terminological: the phrase does not denote a single established construct across the two cited works. In the OSP setting, the cocoon is a structural property of the program itself; in the recommender setting, it is a measurement framework applied to model outputs and feedback cycles (Mars, 20 Mar 2025, Yang et al., 16 Jun 2026).

Context	Meaning	Core elements
Object-Spatial Programming	A spatial envelope around program logic	object classes, node classes, edge classes, walker classes
Generative recommendation	A model-level metric for code-space concentration	layer-wise code entropy, Top-$\kappa$ code concentration, relative entropy reduction

This dual usage is not merely lexical. In OSP, the cocoon is the explicit graph in which computation resides and moves. In generative recommendation, the cocoon is the narrowing of generation within a hierarchical code vocabulary under repeated retraining and interaction. The shared vocabulary reflects a common emphasis on structure, containment, and topology, but the underlying objects of analysis are different.

2. Object-Spatial Programming and the spatial envelope

Object-Spatial Programming extends Object-Oriented Programming by introducing topologically-aware class constructs called archetypes and, in the abstract’s formulation, fundamentally inverts the traditional relationship between data and computation, enabling computation to move to data (Mars, 20 Mar 2025). The details describe this as a "Code-Space Structural Cocoon" that weaves together data, connectivity, and control into a single, self-contained spatial envelope around program logic.

At the heart of OSP are four class archetypes, each inheriting from a universal object type $\tau_{\text{obj}}$. Object classes are exactly like the classes known from Java, C++, or Python: they hold pure data or helper methods that do not participate in the spatial graph. Node classes satisfy $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$; every node is also an object, but with added spatial semantics. Nodes carry data and abilities, serve as anchor points for edges and walkers, and are added automatically to the global $N$ set when instantiated by new τ_node(). Edge classes satisfy $\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$ and are first-class objects connecting exactly two nodes. They are directed as forward, backward, or bidirectional, may carry weights or capacities, and can be instantiated only if both endpoints are already in $N$. Walker classes satisfy $\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$ and represent mobile computational entities that carry mutable state, a dynamic location pointer $n_{\text{loc}} \in N$, and a queue $Q(w)$ of destinations.

The cocoon metaphor is grounded in a specific contrast with traditional OOP. In the source description, objects in conventional OOP "float in a largely unstructured heap" and inter-object links are "just pointers—opaque to both the programmer and any optimizer." By contrast, OSP makes space itself first-class: every datum lives at a named node, every relationship is an explicit edge, and every active computation is embodied in a walker that carries its own state through the graph. By combining the four archetypes, one builds a graph $G=(N,E)$ and a set of autonomous agents $\tau_{\text{obj}}$0 traversing it. This graph, in the paper’s terms, literally "cocoons" the logic, because relationships and traversals are no longer ad hoc side-structures but part of the same formal topology.

3. Formal semantics and spatial integrity

The OSP presentation gives the cocoon a formal semantics rather than treating it as metaphor alone (Mars, 20 Mar 2025). The subtyping structure is explicit: $\tau_{\text{obj}}$1 is the universal supertype, and $\tau_{\text{obj}}$2, $\tau_{\text{obj}}$3, $\tau_{\text{obj}}$4.

An edge instance is defined as

$\tau_{\text{obj}}$5

A walker instance is defined as

$\tau_{\text{obj}}$6

The global system state is

$\tau_{\text{obj}}$7

where $\tau_{\text{obj}}$8 is all object instances, $\tau_{\text{obj}}$9 the node instances, $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$0 the edge instances, $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$1 the walker instances, $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$2 the traversal queue, and $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$3 the current location map.

Traversal is specified by the visit operator $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$4. For a single edge, $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$5 enqueues $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$6 when $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$7 and the edge direction permits traversal. For a multi-edge set, $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$8 analogously enqueues all reachable destinations. Ability activation order is also fixed: when walker $\tau_{\text{node}} \subseteq \tau_{\text{obj}}$9 arrives at node $N$0, all node-abilities in $N$1 matching $N$2’s type execute before all walker-abilities in $N$3 matching $N$4’s type. The source gives this as

$N$5

Spatial integrity is enforced by a node deletion cascade:

$N$6

The stated consequence is that the program’s dynamic state remains a well-formed, connected graph plus a set of properly queued walkers. In that sense, every piece of logic lives in and must respect the structural envelope.

4. Applications, runtime behavior, and systems payoff

The OSP exposition grounds the cocoon in worked domains rather than only in type-theoretic machinery (Mars, 20 Mar 2025). In the social-network case study, Profile, Tweet, and Comment are node classes; Follow, Like, and Post are edge classes; visit_profile, create_tweet, and load_feed are walker classes; and TweetInfo and utility functions remain ordinary objects. The description emphasizes that load_feed can spawn walker instances along every Follow edge, collectors enqueue Tweet nodes, nodes fire their get_info ability, and results are assembled in walker state. Because the follower graph and feed-generation logic live in the same cocoon, parallelism is directly visible and Profile and Tweet data can be co-located on the same physical machine to minimize cross-machine traffic.

The same pattern is extended to agent-based systems, where agents are walkers with internal state and goals, the environment is represented by nodes with resource capacities, and edges encode adjacency or accessibility. The cocoon forces explicit declaration of available edges, so an agent cannot illegally move outside the modeled geography. Finite state machines are mapped with states as node classes, transitions as edge classes, and the input token as a single walker; reachability can then be analyzed statically and states partitioned dynamically across threads. Neural networks are represented with neurons as node classes, synapses as edge classes with weight properties, activations as walkers carrying real-valued activation, and backpropagation as reverse walkers. Distributed systems and microservices are modeled with services as node classes, RPC links as edge classes, and requests or traces as walkers.

Because topology is explicit, the runtime is described as being able to exploit the cocoon through graph partitioning and data locality, walker scheduling policies, data locality heuristics, and traversal path caching and reuse. The details mention spectral methods or multilevel partitioners for minimizing edge cuts, affinity scheduling that keeps a walker on the same core as its last-visited node, traversal-frequency tracking $N$7 for prefetching adjacent node data, and grouping hot subgraphs in high-bandwidth memory. In the distributed-services example, graph-partitioning algorithms such as METIS and spectral partitioning are named explicitly, and the runtime may rewire edges at runtime to relieve hotspots.

The reported payoff is both formal and empirical. Structural invariants such as cascade deletion and well-typed traversal are said to guarantee that one never gets a dangling pointer or illegal move. Parallelism is described as manifest in the graph topology, locality optimizations as automatable once edges are explicit and weighted by traffic, and maintainability as improved because control flow is co-located with the data graph it traverses. The details further state that early experiments in Jaseci/Jac on graph neural nets, conversational agents, and microservice choreography show 2–3× speed-ups purely from topology-aware scheduling and memory placement.

5. Code-space concentration in generative recommenders

In the recommender-systems paper, Code-Space Structural Cocoon is not a programming construct but a metric family for concentration in the generated Semantic ID space (Yang et al., 16 Jun 2026). The paper’s starting point is that items are no longer atomic IDs but multi-level discrete codes. Each item $N$8 is embedded by a semantic encoder such as a CLS vector from title and description, and a Residual Quantization VAE quantizes that continuous vector into an $N$9-layer code sequence

$\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$0

These discrete codes serve as Semantic IDs.

A user interaction history $\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$1 is then mapped into a continuous code-embedding space by looking up each layer’s code, embedding each code through a learned embedding, and summing or concatenating across layers. The resulting sequence of vectors forms the model input on which a Transformer or other autoregressive model is trained to generate the next code tokens.

Yang et al. define two complementary metrics at each simulation cycle $\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$2 and each code layer $\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$3. The first is layer-wise code entropy,

$\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$4

where $\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$5 is the fraction of codes at layer $\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$6 in user $\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$7’s exposure list $\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$8 equal to $\tau_{\text{edge}} \subseteq \tau_{\text{obj}}$9. This measures average intra-user diversity of layer-$N$0 codes. The second is Top-$N$1 code concentration. If $N$2 is the overall frequency of code $N$3 at layer $N$4 across all users’ exposures, and $N$5 are codes sorted by descending frequency, then

$N$6

To summarize collapse over $N$7 cycles, the paper also computes relative entropy reduction,

$N$8

so that larger $N$9 means stronger narrowing at layer $\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$0.

The implementation procedure is explicit. For each cycle, and for each user, the model’s top-$\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$1 exposure list is mapped back to item codes at every layer; per-user code counts are built and normalized to obtain $\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$2; $\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$3 is computed by averaging user-level entropies; and system-wide counts are aggregated, normalized, and sorted to obtain $\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$4. The per-cycle complexity is

$\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$5

with the note that $\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$6 and $\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$7 are modest, for example 256 codes times 3 layers.

6. Experimental setup, findings, and design implications

The experimental study uses Amazon Office Products with 4,905 users, 2,420 items, and 4-level taxonomy, and Toys & Games with 19,412 users, 11,924 items, and 3-level taxonomy, both under 5-core preprocessing and chronological order (Yang et al., 16 Jun 2026). The recommender set comprises traditional baselines SASRec and Mamba4Rec, and generative models TIGER and OneRec at 0.5B, 1.5B, and 3B parameter scales via the MiniOneRec codebase. Two tokenization strategies are compared: Semantic ID, where RQ-VAE is trained on text embeddings from title and description, and Collaborative ID, where RQ-VAE is trained on item embeddings from a pre-trained SASRec. The closed-loop simulator, RecLoop, runs for 15 retraining cycles with $\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$8 exposures per user per cycle, Qwen3-8B deterministic LLM user agents, a 5-step sliding memory, reflection every 5 cycles, and retraining after each cycle on all accumulated interactions.

At the exposure level, the reported results state that SASRec and Mamba4Rec show Category Entropy drops of approximately 30–50% in the first 5 cycles; TIGER declines more unevenly; and OneRec oscillates but always loses less entropy than the baselines, with the specific note that OneRec stays above 1.4× initial at Toys Level 3. For Inter-User Jaccard on Office Products by cycle 15, the paper reports approximately 0.22 for SASRec, 0.14 for Mamba4Rec, 0.11 for TIGER, and 0.06 for OneRec, with similar ordering on Toys. Coverage and Gini indicate that all models experience rising Gini and thus strong head-item concentration, but generative models maintain broader category reach and slower homogenization.

At the code-space level, the Toys & Games example shows substantial differences between models. For TIGER, the entropy reductions are $\tau_{\text{walker}} \subseteq \tau_{\text{obj}}$9, $n_{\text{loc}} \in N$0, and $n_{\text{loc}} \in N$1. For OneRec (1.5B), the corresponding values are $n_{\text{loc}} \in N$2, $n_{\text{loc}} \in N$3, and $n_{\text{loc}} \in N$4. Top-10 layer-0 concentration for TIGER rises from 27.0% to 86.6%, whereas for OneRec it remains below approximately 50%. The paper also notes that figures plotting $n_{\text{loc}} \in N$5 over 15 cycles show a steep early collapse at coarse layers and relative stability at fine layers.

Tokenization strategy and model scale are presented as major determinants of cocoon severity. On Office Products, TIGER with CID tokenization sees fine-layer diversity collapse almost as strongly as coarse-layer diversity, whereas under SID the fine layer remains more than 2× more diverse. OneRec is described as more robust; on Toys, SID occasionally concentrates more than CID, which the paper treats as evidence that tokenization effects depend on dataset taxonomy and model architecture. For model scale, OneRec at 3B preserves higher layer entropies by cycle 15—6.67, 7.22, and 7.12—than the 0.5B model, which records 5.30, 5.24, and 4.87. At layer 2, the 3B model uses 233 distinct codes versus 70 for 0.5B, and the long tail of the code distribution remains reachable only for the largest model.

The practical implications are framed in design terms. Tokenization is treated as a design variable because collaborative embeddings can carry popularity bias into discrete codes. Model capacity is described as a diversity buffer, since larger generative recommenders preserve broader code-space usage. The paper further proposes hierarchical regularization as future work, such as adding an entropy bonus on the first token or injecting exploratory code sampling, and recommends multi-objective tuning that incorporates code-space cocoon metrics alongside standard exposure diversity metrics. A common misconception would be to equate improved exposure diversity with the absence of internal concentration; the reported findings state the opposite. Generative recommenders are generally less prone to exposure-level cocoon formation than traditional baselines, but feedback loops can still induce concentration within the generated SID space, especially at early code layers and when tokenization amplifies popularity bias.