[Discussion] How do core components interact to form a closed simulation loop?

[hu6789]

Beyond listing individual components, a central design question is:
How do these components interact to form a coherent, closed-loop system?

This issue focuses on the interaction patterns between. In particular, it discusses:
how information flows between layers,
how feedback loops are controlled or delayed,
and why certain interactions are intentionally indirect.

The described interaction model represents the current baseline, not a final design.

[hu6789]

While Issue #1 focuses on what the core components are, this issue focuses on how they interact.

MacroImmunet aims to simulate immune dynamics through repeated cycles of:
world state → perception → decision → world update
To achieve this, the system separates sensing, decision-making, and state storage into distinct components.

How should the core components be connected to form a coherent, reusable, and extensible decision loop?More concretely:
How does information flow from the World to ScanMaster, and from ScanMaster to CellMaster?
How should CellMaster transform aggregated signals into concrete effects on the world?

How strict should the separation between:
sensing (ScanMaster),
decision logic (CellMaster),
state mutation (LabelCenter) be?

Current Loop (Draft).The current architecture loosely follows this iterative structure:

World / LabelCenter

Maintains the authoritative simulation state.

ScanMaster

Observes the world in a read-only manner and detects:
regions of interest,
interaction patterns,
context-dependent signals.

CellMaster

Receives structured summaries and:
organizes cells by type, region, and internal state,
applies shared or per-context decision logic,
generates intents or labels to be written back into the world.

This separation is designed to:
avoid circular dependencies within a single tick,
allow independent evolution of each component,
keep the system auditable and modular.
2026.01.23

[hu6789]

CellMaster × InternalNet Receptor Interface (node–edge version)

This update documents the current, canonical interface between CellMaster and InternalNet under the explicit node–edge InternalNet implementation.
At this stage, InternalNet is treated as a closed, stable intra-cellular causal network, and this update focuses on how external signals are allowed to enter the network, and just as importantly, how they are prevented from leaking into the full graph.

Design stance (current phase)

CellMaster is not a decision network

Responsibilities:

cell identity (cell_type / genotype / state)
context scheduling (region / budget / tick)
orchestration of decision backends
CellMaster does not own or modify InternalNet nodes or edges.
InternalNet is the sole intra-cellular causal graph
Nodes represent physiological variables, intermediate states, and decision-relevant signals.
Edges represent propagation, modulation, or constraint relationships.
The node–edge topology is considered runtime-stable in the current phase.
All external influence must pass through receptor-level inputs
No direct access to internal nodes
No bypass of predefined input nodes
No runtime structural mutation

CellMaster → InternalNet interface

Under the node–edge version, CellMaster provides only constrained, typed inputs, grouped into three categories.

• Receptor inputs (primary entry points)

  • Examples include:
    cytokine-like signals
    abstracted pMHC / TCR-style activations

  • Mechanism:
    CellMaster evaluates presence and intensity of signals.
    Values are injected only into predefined receptor/input nodes of InternalNet.

These nodes are declared at network design time, not dynamically created.

• Context flags (weak modulators)

  • Examples:
    infected
    stressed
    exhausted
  • Usage:
    Do not directly trigger behaviors.
    Act as bias or gating modifiers on selected nodes or edges.

• Resource / constraint signals

  • Examples:
    energy availability
    translation capacity
  • Purpose:
    Shape internal state evolution.
    Enforce physiological constraints rather than action-level triggers.

InternalNet → CellMaster outputs

At this stage, InternalNet produces only:

state_summary
A compact representation of the internal physiological state at tick end.
behavior_candidates
Pre-HIR, non-authoritative behavior suggestions.
Not equivalent to Intents.

CellMaster does not:

Inspect intermediate node activations.
Post-process internal reasoning paths.
Override InternalNet causal flow.

Why such strict boundaries?

A known risk of explicit node–edge networks is downstream over-activation caused by weak or improperly scoped signals.
To mitigate premature “global activation” effects, the current implementation deliberately enforces:
No external writes to internal nodes
No signal injection outside receptor-level nodes
No dynamic topology changes at this phase

This preserves:

Traceability of causal chains
Stability of intra-cellular dynamics
A clean baseline for future extensions
Explicit non-goals of this update

The following topics are intentionally deferred:

InternalNetBuilder or dynamic network construction
Cross-cell or lineage-level network sharing
Network divergence after differentiation
These will be raised later (see #4) as design tensions and future extension points, not as resolved mechanisms.

2026.02.01

[hu6789]

Execution flow and per-CellMaster internal ownership

This update extends earlier discussion by clarifying how ScanMaster, CellMaster, InternalNet, and IntentBuilder interact during execution.

Execution Flow (Refined)

The current conceptual flow can be summarized as:

1. ScanMaster observes the world and produces summarized signals.
2. CellMaster interprets these signals and determines contextual constraints.
3. InternalNet executes internal state propagation only within allowed subgraphs.
4. IntentBuilder evaluates internal outcomes and decides on world-facing intents.
5. Intents are applied atomically to the shared world state.
   This preserves a strict read–compute–realize separation.

Shared Logic vs. Isolated Execution

A critical design choice is that:

• InternalNet logic may be shared
• InternalNet state may not be shared

In other words:

• multiple CellMasters may rely on the same InternalNet definition
• each CellMaster maintains its own execution instance and state history

This aligns with the “mother brain” abstraction:
a template-level mother, but instance-level autonomy.
The same principle applies to IntentBuilder.

Why Not a Single Global InternalNet?

A single global InternalNet would introduce several problems:

• unintended coupling between unrelated cell populations
• loss of contextual isolation
• difficulty in reasoning about causality
• biologically implausible synchronization effects

By maintaining per-CellMaster internal execution, the system avoids these pitfalls while retaining structural reuse.

Open Concern: Latent Network Overreach

The question of whether a broad InternalNet might enable unintended downstream activation is explicitly acknowledged.

At this stage, the system relies on:

• contextual gating by CellMaster
• execution thresholds
• staged realization via IntentBuilder

This concern is intentionally deferred for deeper discussion, as it relates to regulatory mechanisms rather than baseline architecture.
2026.02.09