Substrate Launch and Modulation Model

This page explains the architecture choices behind substrate launch and modulation.

The core model

A caller invokes a generic launcher once with SubstrateDomain. The launcher selects adapter mechanics, invokes launch(domain), and the runtime delegates modulator assembly to a mediated broadcast flow where RAS signals through Neuromodulators and synthesizers self-select internally.

Implementation invariant: any specific relay involved in this flow is a wrapper over its own NeuralRelay instance. The wrapper defines boundary-facing APIs, while the underlying NeuralRelay performs transport and routing.

The core runtime shape is:

1. The launcher resolves the launch target and dispatches into the package boundary.
2. RAS sends a single modulator signal to Neuromodulators for one concrete modulator.
3. Neuromodulators broadcasts a SynthesisTask to all registered synthesizers.
4. The first eligible synthesizer creates the Modulator instance and stores it in Neuromodulators.
5. Silent or late synthesizers are ignored, and the broker returns only the winning result.
6. Neuromodulators emits a single ModulatorSuccess or ModulatorFailure carrying the artifact-ref or failure metadata.
7. RAS resolves the artifact-ref from Neuromodulators, receives the result through a terminal registered to NeuralRelay, and injects it into the ModulatorCocktail.
8. The concrete *Substrate configures itself from the updated cocktail after the transmission arrives through the substrate terminal.

Why separate launcher, adapter, and RAS orchestration

Launcher

Policy boundary:

1. Choose dispatch strategy from domain launch metadata.
2. Enforce launch output contract.

Adapter

Transport boundary:

1. Import module path.
2. Resolve symbol name.
3. Invoke launch(domain).

RAS plus Neuromodulators plus synthesizers

Modulation boundary:

1. Broadcast a single substrate need as a modulator request.
2. Let Neuromodulators fan out that signal as SynthesisTask messages to synthesizers.
3. Let the synthesizers self-select whether they can satisfy the task.
4. Accept the first valid success or fail on timeout/no-match.
5. Resolve the returned artifact-ref from Neuromodulators, receive the result through a terminal registered to NeuralRelay, and inject it into the cocktail.
6. Hand the updated cocktail to the substrate runtime after the transmission arrives through the substrate terminal.

This separation keeps policy, mechanics, and construction independent.

Why broadcast orchestration

Mediated broadcast orchestration moves substrate construction responsibility into the biological control plane rather than centralizing it in an engineered call chain.

This gives predictable composition while staying closer to the domain metaphor:

1. RAS does not need to know which Synthesizer owns which modulator or how fanout is executed.
2. Each Synthesizer can independently decide whether it can satisfy a request.
3. Neuromodulators accepts the first successful synthesis result and ignores silent or late replies on the relay channel.
4. New modulators can be added by registering new Synthesizers rather than editing central assembly code.
5. The same mechanism works both at launch time and during runtime updates.

Laminae define the inheritance structure inside a substrate. The assembly seam sits at RAS, Neuromodulators, and the synthesizers, not in a central assembly chain.

For a CliSensoryCortexSubstrate-style runtime, the conceptual layering is still:

1. BaseLamina
2. AgenticLamina
3. CortexLamina
4. SensoryMotorCortexLamina
5. SensoryCortexLamina

Those laminae define structure. RAS, Neuromodulators, and the synthesizers now determine which modulators are injected into that structure.

Neuromodulators is both the messaging boundary and registry space where synthesized modulators live between production and injection.

Runtime vs construction contracts

The substrate runtime contract is intentionally narrow:

1. lifecycle state
2. health and readiness
3. runtime handle identity

Modulation and assembly mechanics are intentionally outside runtime contracts and handled by RAS, Neuromodulators, synthesizers, and the launch boundary.

Lifecycle and identity invariants

Core invariants:

1. instance_id is created once per launched runtime.
2. definition_id remains stable through layers.
3. shutdown transitions runtime to stopped state.
4. readiness depends on healthy plus ready lifecycle state.

Launch flow in one diagram

sequenceDiagram
    participant Caller
    participant L as Generic Launcher
    participant A as Adapter
    participant P as package launch(domain)
    participant R as RAS
    participant M as Neuromodulators
    participant N as Registered synthesizers
    participant S as Substrate

    Caller->>L: launch(domain)
    L->>A: resolve and dispatch
    A->>P: import and invoke
    P->>R: request modulators for substrate
    R->>M: ModulatorRequest
    M->>N: fanout ModulatorRequest
    N->>M: add(modulator)
    M-->>R: ModulatorSuccess(artifact-ref)
    R->>M: get(artifact-ref)
    R->>S: inject ModulatorCocktail
    S-->>P: configured runtime
    P-->>A: runtime
    A-->>L: runtime
    L-->>Caller: runtime

Tradeoffs

Chosen tradeoffs:

1. More classes and wiring in exchange for explicit boundaries.
2. Broadcast request handling in exchange for easier extension and runtime updates.
3. Thin launch wrappers in exchange for stable call semantics.

Rejected alternatives:

1. Putting modulation logic inside adapters.
2. Keeping a generic assembly concept as the assembly surface.
3. Hard-coding Synthesizer-specific knowledge into RAS.

Relationship to contracts packages

Current boundary:

1. cerebel-substrate-core defines substrate launch and runtime primitives.
2. cerebel-contracts defines higher-level domain bundle models and specializations (cortex/comms/agent config).

This keeps substrate lifecycle concerns stable while allowing launch and modulation vocabulary to evolve around the RAS plus Neuromodulators plus synthesizer model.