MoE Adapter (Mixture of Experts)

The MoE adapter maps expert vocabulary — experts, gates, routing decisions — onto the engine’s actor vocabulary without leaking domain-specific assumptions into the engine core. It is a facade over SubstrateSession that translates between MoE-native terms and fly-by-wire actors, steps, and telemetry.

What It Does

A Mixture-of-Experts system speaks in terms of experts, expert groups, and routing decisions. The KAIROS engine speaks in terms of actors, steps, and telemetry. The MoE adapter bridges this gap by owning a SubstrateSession and keeping all expert-to-actor mappings internal.

Unlike the LLM adapter, the MoE adapter does not bundle its own ActionPhysicsMapper. It uses whatever mapper is registered on the session. This makes the adapter domain-generic — you can pair it with the built-in ai_safety mapper, a custom mapper, or no mapper at all (state-only gating).

Architecture

The adapter sits between the MoE system and the engine core:

Caller (MoE system)
  |
  v
MoeAdapter          <- expert vocabulary
  |
  v
SubstrateSession    <- actor vocabulary (fly-by-wire)
  |
  v
Engine              <- domain-agnostic core

The caller interacts only with expert-native terms. The adapter translates these into session API calls. The engine never sees domain-specific concepts.

Mapping Modes

The adapter supports three strategies for mapping experts onto engine actors. The choice determines granularity and lifecycle semantics.

Mode	Mapping	Actor ID prefix	Use when
OneExpertPerActor	1:1 expert to actor	moe-expert-	Each expert needs independent safety tracking
ExpertGroupPerActor	N:1 experts to shared actor	moe-group-	A group of experts shares a single risk profile
RouterDecisionPerActor	1:1 router to actor	moe-router-	Each routing step is a distinct decision to monitor

Group Mode Semantics

ExpertGroupPerActor maps multiple experts onto a single shared actor. This mode has specific rules that differ from the 1:1 modes:

Reference-counted lifecycle. A group actor is created when the first expert registers and removed when the last expert in the group unregisters. Registering additional experts to an existing group increments the reference count without creating a new actor.

De-duplicated stepping. In group mode, step_expert is not available — use step_experts (batch). When multiple experts in the same group are stepped together, the adapter de-duplicates: same direction produces one step, conflicting directions produce an error.

Policy-setting restrictions. Only the first expert registered to a group may set a policy. Subsequent registrations to the same group must omit the policy field. This prevents conflicting policies on a shared actor.

Design Rules

Duplicate rejection. Registering an expert with an expert_id that is already registered is rejected in all modes. Unregister first, then re-register.

Timeline alignment. Adapter-created actors start at the session’s current tick. Late registrations align to the current engine timeline rather than starting from tick zero.

Actor ID reuse. Unregistering and re-registering the same expert ID is allowed. The adapter generates a fresh actor from the same ID prefix.

Batch stepping in group mode. ExpertGroupPerActor requires step_experts for all stepping operations. The batch call de-duplicates per group — if two experts in the same group both specify Right, only one step executes. If they specify conflicting directions, the call returns an error.

When to Use Each Mode

OneExpertPerActor is the default for most deployments. Each expert gets independent telemetry, independent warning signals, and independent action gating. Use this when experts have meaningfully different risk profiles.

ExpertGroupPerActor is appropriate when experts within a group share a risk profile and should be evaluated as a unit. The group’s collective behavior — not any individual expert’s — determines the safety trajectory. Use this for tightly coupled expert ensembles where individual monitoring would produce redundant signals.

RouterDecisionPerActor treats the routing layer itself as the subject of safety monitoring. Each routing step creates a decision actor that tracks the routing path through the expert graph. Use this when the routing logic — not the individual experts — is the primary risk surface.