GERM and MOVE: the unit of description transfer

Chapter 3. GERM and MOVE: the unit of description transfer

GERM as container · The biological seed · MOVE as asset or component · The ROOT repository and D-components

3. 1. GERM as container

The description of an organism by itself does not unfold into a running network. MOVE is a vector in the space of ontogeny, a static data structure. For it to become a running network, an executor is required — a program capable of reading MOVE and executing the RTR0 procedure. This executor must be attached to the description in advance, otherwise the unfolding cannot start.

In the Gativus architecture, this task is solved by GERM (Gativus Embryonic Resource Module). GERM is a container that joins the description of an organism (MOVE) with the minimal operational network (OPNG) capable of executing it.

a) Composition of GERM

GERM consists of two mandatory parts.

The first part — MOVE, the sixteen-dimensional vector of the description of the organism in the space of ontogeny. All sixteen coordinates, corresponding to the MOLD diagrams, are packaged into a unified representation. The six supporting diagrams (CLSS, COMP, COMM, ACTD, SPCE, RSRC) are usually filled completely; the ten reserved diagrams may be empty or contain only partial information. The completeness of filling is determined by the complexity of the organism being described — for a simple functional organ, several diagrams suffice; for a complete SRNT network, all diagrams are used.

The second part — OPNG (OPerational Network of Genesis), the operational network of genesis. This is the minimal necessary executor, capable of reading MOVE and starting RTR0. OPNG does not implement the full functions of the future organism; it implements only the morphogenesis procedure: parsing of MOVE, neurogenesis, synaptogenesis, coordination of unfolding phases, transition to operation. After the completion of morphogenesis, OPNG is transformed into OPN, the operational network corresponding to the running of the organism itself. This transformation is considered in detail in Chapter 4.

b) Self-sufficiency of GERM

A property of principle of GERM is self-sufficiency. Placing GERM in any environment with sufficient AVEC resources triggers an autonomous unfolding process without external control. GERM does not need a coordinating procedure, a connection to a management server, or instructions from an operator. The description and the executor inside GERM are sufficient to begin and complete morphogenesis.

This property is derived from the architecture itself. MOVE contains a complete description of what is to be built. OPNG contains the complete procedure of building. External access is required only to the ROOT repository for obtaining D-components — and this access is mediated by standard network mechanisms that do not require a dedicated protocol.

3. 2. Analogy with the biological seed

The construction of GERM reproduces the structure of a biological seed. This analogy is exact and deserves detailed analysis because it records several essential architectural decisions.

a) Seed, not egg-cell

Biological reproductive units fall into two classes. An egg-cell contains only half of the genetic material and requires fertilization to begin development — that is, the contribution of the other half of the genome from an external source. A seed contains a complete genome and the necessary cellular apparatus — it is self-sufficient, requiring only a suitable environment.

GERM corresponds in its construction to a seed, not to an egg-cell. MOVE contains a complete description of the organism; OPNG contains a complete machinery for unfolding. No 'fertilization' from external sources is required. Placed on a GATE with sufficient AVEC, GERM autonomously starts germination.

This decision is not accidental. An architecture requiring an external contribution would require a coordinating node through which all requests for creating organisms must pass. Such a node would become a single point of failure and a bottleneck for scaling. The self-sufficiency of GERM removes this problem: germination can occur in parallel in any number of GATEs, without a common coordinator.

b) Environment, not instructions

A seed does not receive instructions from outside about what to do. It receives conditions — soil, moisture, temperature, light. The decision to begin germination is taken by the seed itself based on an analysis of the conditions: are they sufficient for unfolding. If the conditions are insufficient, the seed remains dormant — potentially for years or decades.

GERM operates similarly. Placing GERM on a platform does not mean an immediate launch of germination. OPNG analyses the available AVEC: is it sufficient to unfold at least a minimally viable organism by this MOVE. If resources are adequate — germination begins. If not — GERM remains inactive, awaiting an increase in quota or transfer to another platform.

This means that GERM can remain in an inactive state for an extended time. In repositories, on backup media, in archives — anywhere data integrity is ensured. Activation happens only upon placement in suitable conditions. In this respect too, the analogy with the seed is accurate.

c) Result of unfolding

A seed at germination produces not an exact copy of the mother plant but a plant of the same species with unique individual features — a concrete shape, concrete size, concrete branch topology. It corresponds structurally to the mother but differs in detail.

GERM at germination yields a network corresponding structurally to MOVE but individual in detail. The nodes receive new UNONs — not those of the nodes of the originally folded network. The SYGA connections are established emergently through autonomous search for partners and do not exactly reproduce the topology from which MOVE was derived. The initial state of the V-sections is formed anew. The result is a new instance, not a copy.

This is consistent with the general property of reverse transformations: RTR# yields a new realization and does not restore the original. In the case of GTR0, this means that the same MOVE unfolded twice yields two different individuals of the same species — with the same architecture but with different life trajectories.

1. 3. Branching point: the status of MOVE in the network architecture

MOVE has so far been considered as an abstract unit — a description vector that is transferred from one node to another somehow. For concrete engineering implementation, however, the question must be answered: what is MOVE as an object of the Gativus network? Does it exist as an independent entity or as a part of some node? Is it transferred through standard network mechanisms or does it require a dedicated protocol?

This question has two direct answers and one synthetic. Each answer corresponds to an architectural decision with its own consequences.

a) Variant A: MOVE as a component of a node

In this variant, MOVE exists as an M-component in the M-section of a concrete NDDI node. The M-section (see GNET, Chapter 3) is a section of a node intended for storing ontogenetic information: the description of the node itself, the class to which it belongs, the templates of connectors, references to D-components. MOVE as an M-component is a natural extension of this role: the same node that holds a description of its own structure can hold a description of a whole organism for subsequent unfolding.

In this variant, the transfer of MOVE between nodes is realized through the m-relation — a typed connection between the M-components of two nodes for the transfer of ontogenetic information. The m-relation works by the same protocols as v-relations and d-relations and does not require a dedicated mechanism for asset registration.

The biological analogy of this variant is exact. DNA does not exist as an independent transferable entity with a global registry. It exists within a concrete cell as part of its nucleus, and at reproduction it is copied into the nuclei of descendants. There is no registry of DNA, no accounting of the number of copies, transfer occurs locally between mother and daughter cells.

The architecture of MOVE as component is simple and elegant. It does not require the introduction of new entities — it uses existing mechanisms of the M-section and the m-relation. It has no scaling bottleneck: MOVE is copied only where it is actually needed without appeal to a global registry. It reflects the biological pattern without distortion.

b) Variant B: MOVE as a digital asset

In this variant, MOVE exists as a GATN asset in the distributed registry of the network (see GNET, Chapter 4). A GATN asset has a 64-bit unique identifier, is registered upon creation, transferred between nodes through the asset-exchange protocol with notarization, and is subject to the issuer hierarchy ROOT → LRAI → owner.

In this variant, the transfer of MOVE between nodes is the transfer of an asset. The issuer node creates MOVE in the registry as a new asset, registers it, and delegates ownership to the receiving node through one of the four standard transfer ways (see GNET, Chapter 4, section 4.10). After transfer, MOVE becomes the property of the recipient, which can use it to start germination.

This variant has essential advantages for engineering systems. Every MOVE has a unique identifier, which simplifies version management and provenance tracking. The transfer of MOVE is a standard transaction handled by the existing asset-registry infrastructure, without requiring a dedicated protocol. Every MOVE can be traced back to a signature chain originating at ROOT, protecting against substitution and forgery of the description. Smart contracts (see GNET, Chapter 4, section 4.13) can be attached to MOVE as to an asset, regulating the conditions of use.

The biological analogy of this variant is less direct but still exists. Certified varieties in agricultural trade are seeds with a registered identity: every variety is registered, its propagation is regulated, transfers between producers are documented. A natural seed thus simultaneously remains a physical object but acquires an additional legal status as a registered object.

c) Variant C: MOVE has a dual nature

The third variant is synthetic. It accepts the first two variants as simultaneously valid, not mutually exclusive. MOVE exists both as an M-component in a node and as a GATN asset in the registry. These are two ontological projections of the same entity, analogous to the two projections of a node of neural tissue described in GNSS Chapter 1 (as cell and as information node).

Inside the node, MOVE lives as an M-component: used at morphogenesis, accessible through the m-relation, part of the space of ontogeny of this organism. In the registry, MOVE exists as an asset: with a unique identifier, with traceable provenance, with transfers between owners regulated.

These two roles do not contradict each other. The M-component in a node is the physical localization of the description, the concrete place of its storage and use. The asset in the registry is the legal status of the same description as a registered object. The same MOVE can simultaneously reside in the M-section of a concrete node and be registered in the registry as an asset of this type.

The biological analogy here is a seed of a certified variety. A concrete physical seed of a certain variety exists as an individual in a concrete place, physically contains the DNA of this variety. At the same time, the variety as a legal entity is registered in a registry of breeding achievements, has a code, has rights holders. The physical seed and the legal variety are two aspects of the same reality.

3. 4. Arguments for the variants

The analysis of arguments proceeds along several criteria essential for the engineering implementation of Gativus.

a) Architectural simplicity

Variant A is the simplest. MOVE as component uses existing mechanisms of the M-section, introduces no new entities, and requires no asset infrastructure for basic morphogenesis scenarios. A simple case — starting the germination of one organism from one MOVE on one platform — is realized with minimal means.

Variant B complicates the architecture: every MOVE must be registered, must have an identifier, a signature chain, notarization upon transfer. For simple scenarios this is redundant.

Variant C adds an additional layer on top of B but does not require the use of the asset infrastructure in simple cases: if the asset dual is not needed, MOVE can be just an M-component. Assets are created only where registration is needed.

b) Biological accuracy

Variant A reproduces the biological picture most accurately. DNA exists only within a cell; there is no global registry of DNA; transmission from parent to descendant is local and does not require registration operations.

Variant B departs essentially from biology: a global seed registry, mandatory registration — this is not the natural pattern but the industrial one.

Variant C preserves biological accuracy for the main mode of operation and adds a registration superstructure only when needed. This is consistent with the actual structure of relations in modern agriculture: the vast majority of seed transfers pass without registration, but certified varieties are subject to registration.

c) Protection against substitution and forgery

Variant A provides no built-in means of protection. An M-component in the M-section of a node may be substituted without obvious traces. One can rely only on general means of data integrity and access control.

Variant B provides strict protection: a signature chain originating at ROOT guarantees authenticity, notarization upon transfer excludes unauthorized transmission, the network immune system (see GNET, Chapter 4, section 4.7) automatically rejects MOVEs with damaged or absent signature chains.

Variant C provides protection where needed and does not impose it where redundant. MOVE circulating in a local network among trusted nodes can exist only as an M-component. MOVE transferred across trust boundaries or used in commercial scenarios should have an asset dual with a complete signature chain.

d) Scalability

Variant A has no bottleneck by construction: every node handles its own M-section locally without appeal to a global infrastructure. It scales linearly with the number of nodes.

Variant B has a potential bottleneck at the registry. The distributed registry architecture described in GNET (the ROOT → LRAI → owner tree, see section 4.8) solves this problem: the registry is not centralized, operations are local for the overwhelming majority of cases. Yet the mandatory registration of every MOVE remains an extra overhead.

Variant C introduces no scalability limits beyond those already present in the GNET registry. M-components remain local, asset duals are created only when necessary.

e) Support for smart contracts

Variant A does not support smart contracts attached to MOVE. If MOVE is only a local M-component, there is nothing to attach to it as an identifiable contract party.

Variant B fully supports them: MOVE as an asset can be a party to any smart contract that, on the MAP9 level, is a narrative attached to G-assets (see GNET, Chapter 4, section 4.13).

Variant C supports them selectively: MOVE with an asset dual can be attached to smart contracts; MOVE only as an M-component cannot. This gives engineers a choice: create assets only for those MOVEs that need to be regulated by contracts.

3. 5. Decision: MOVE has a dual nature

From the above arguments follows the choice of variant C — MOVE has a dual nature. This decision is based on the following considerations.

Variant A is too restrictive. It suits closed scenarios where all MOVEs circulate within one trusted network without any need for version registration, anti-forgery protection, or contract regulation. But Gativus does not presuppose closedness. The Gativus network is a global infrastructure in which descriptions of organisms can be transferred between platforms, between jurisdictions, between owners. Without an asset infrastructure these scenarios become problematic.

Variant B is too heavy. Mandatory registration of every MOVE — even temporary, intermediate, test — produces excessive overhead and contradicts the biological nature of morphogenesis: in biology, most unfoldings occur locally without registration.

Variant C preserves the merits of both variants and avoids their drawbacks. Basic mode of operation — MOVE as an M-component: simple, local, biologically accurate. Extended mode — MOVE with an asset dual: registered, protected, regulated. The choice of mode is an architectural decision per concrete scenario, not a mandatory system-wide requirement.

a) When to create an asset dual

The decision to create an asset dual for a concrete MOVE is taken on several criteria.

Creating an asset is necessary if MOVE is transferred across trust boundaries — for example, between different organizations or jurisdictions. Signature chain and notarization become essential guarantees of authenticity.

Creating an asset is advisable if MOVE is the result of significant engineering work, requires version management, or may be the subject of commercial transactions. A registered identity simplifies life-cycle management and supports smart contracts.

Creating an asset is not necessary if MOVE is used locally within a single platform or a trusted development group, has a short life cycle (test versions, intermediate versions), and has no special security requirements.

b) Relationship between M-component and asset

When an asset dual is created, a determinate relation is established between it and the M-component. The asset registers the identity of MOVE — its unique identifier, the issuer, the signature chain. The M-component contains the content of MOVE — the actual sixteen-dimensional vector with filled diagrams.

The asset's identifier is written into the M-component as a reference. The M-component contains both its own content and the identifier of the corresponding asset. When the M-component is transferred between nodes, the identifier is preserved — which allows the recipient to check the provenance of MOVE through a query to the registry.

The content of MOVE can exist completely in the M-component (the standard case for working copies), or only as a reference to a copy of the asset in the registry (an archival case — the content is retrieved from the registry on demand). This gives flexibility in storage management: frequently used MOVEs are cached locally as M-components; rarely used ones may exist only as assets in the registry.

3. 6. Distribution of D-components through ROOT

MOVE describes what is to be built: which classes of nodes, which connection templates, which proportions. MOVE itself and OPNG do not contain the executable code of the nodes of the future organism — only references to type classes. The executable code resides in D-components, which are stored separately.

D-components are the result of the evolutionary training of GTR0 (see Chapter 1, section 1.6). Each D-component is object code, compiled in ELF format, that implements the behaviour of nodes of a certain type: their reaction to incident relations, their internal logic, their interaction with other sections. D-components are the trained weights of morphotransformation, packaged in executable form.

a) ROOT as repository of genes

All D-components of Gativus reside in ROOT — the root node of the network performing the function of repository. ROOT (renamed from GLAI) plays several roles in the Gativus architecture. As root issuer of assets, it determines the consistency space CNST₀ and issues system assets (see GNET, Chapter 4). As repository, it contains a library of D-components available for the morphogenesis of any organism.

The biological analogue is the universal gene pool shared by different species. The genes of many cellular mechanisms, metabolic pathways, basic signalling systems are conserved across organisms of very different complexity. The ROOT repository plays a similar role for Gativus: it contains universal building blocks available for the morphogenesis of different organisms.

b) D-relations and access to code

The connection between a node class in MOVE and the corresponding D-component in ROOT is realized through the d-relation — a typed connection that transmits executable code. At morphogenesis, ANOD establishes d-relations from each created node class to the required D-components in ROOT. The code is transmitted through these relations into the local cache of the GATE platform and is used at the instantiation of concrete nodes of this class.

An architectural consequence of principle: one D-component in ROOT serves many classes in many GATEs through the network of d-relations. When a GATE creates a node of a determinate class, it does not need to store its own copy of the code — a d-relation to ROOT suffices. The local cache is used for optimization, but truth is in ROOT.

This has an important consequence for the evolution of the system. An update of a D-component in ROOT propagates automatically at the next relinking (see GNET, Chapter 3, section 3.2) to all nodes that have a d-relation to it. The evolution of Gativus as a system occurs through changes in the ROOT repository; each change is gradually realized in all dependent organisms through the standard relinking mechanism.

c) D-components as assets

D-components, unlike MOVE, are unambiguously assets. This follows from their nature: D-components are the result of significant development (in the biological case, evolutionary training), have determinate authorship (or inherited lineage), require version management, must be protected against forgery. All these considerations point to the necessity of a registered identity.

Every D-component in the ROOT repository is registered as a GATN asset (see GNET, Chapter 4, section 4.9). The identifier includes: the number of the issuing GATE (for basic system components, this is ROOT itself), the suffix of the issuer's UNON, the type prefix. For all system D-components, the signature chain is traceable to ROOT.

The transfer of a D-component is a standard asset-transfer transaction. When a GATE loads a D-component into the local cache, this is the re-issuance of a d-relation with registration (see GNET, Chapter 4, section 4.10). When a node receives a new D-component through the d-relation of another node, the signature chain is verified and the component is accepted only if authenticity is confirmed.

d) Relation between MOVE and D-components

The difference in status between MOVE and D-components reflects a difference in their function.

MOVE describes a concrete organism — its unique combination of classes, proportions, and connections. A concrete MOVE can be a working one, a temporary one, a test one; can circulate locally without registration; can be replicated en masse among nodes of the same type. The dual nature of MOVE provides flexibility in choosing the registration mode.

A D-component describes a universal building block — a node type used by many organisms. A D-component is developed over the long term, is carefully verified, is updated rarely and cautiously. Each of its changes affects many dependent organisms. For a D-component, asset status is not a choice but a necessity.

This asymmetry — between MOVE and D-components — is natural and is preserved in the Gativus architecture. MOVE is the description of an individuality, D-components are universal code. Correspondingly, the modes of their registration in the network differ.

3. 7. Transition to Chapter 4

This chapter has defined GERM as a seed container holding MOVE and OPNG. The self-sufficiency of GERM — analogous to the self-sufficiency of a biological seed — ensures the autonomous start of morphogenesis when placed in an environment with sufficient AVEC.

The question of the status of MOVE as an object of the Gativus network has been resolved. The variant adopted is dual nature: MOVE exists both as an M-component in a node and as a GATN asset in the registry. This gives flexibility in the choice of registration mode and depends on the use scenario.

The role of ROOT as the root repository of D-components is established, and the mechanism of their distribution through d-relations is described. D-components, unlike MOVE, are unambiguously assets with a complete signature chain.

Open remains the question of the germination procedure: how does GERM placed on a platform actually unfold into a running network? What steps does RTR0 include? In what order are they executed? How are they coordinated with one another? This question is the subject of the next chapter. Chapter 4 describes the atomic units of morphogenesis (MORN, MLOM), the procedures of node generation (NRGN) and connection establishment (SYGD and SYGA), the parallelism of phases, and the transformation of OPNG into OPN.