Ideas: OnlineLearningAdapter trigger model — pull (per-tick), push (event-driven), or hybrid?

[web3guru888]

Should OnlineLearningAdapter be pull or push?

Issue #204 proposes a shared OnlineLearningAdapter ABC as the foundation for all Phase 5 write-back paths. The core interface:

class OnlineLearningAdapter(ABC):
    async def compute_update(self, blackboard_snapshot: dict) -> WeightDelta | None: ...
    async def apply_update(self, delta: WeightDelta) -> None: ...
    def safety_gate(self, delta: WeightDelta) -> bool: ...

One open question: should adapters be polled by the CognitiveCycle (pull) or triggered by Blackboard events (push)?

---

Option A — Pull (called by CognitiveCycle every tick)

# In CognitiveCycle.run_tick():
for adapter in self.online_learning_adapters:
    delta = await adapter.compute_update(self.blackboard.snapshot())
    if delta and adapter.safety_gate(delta):
        await adapter.apply_update(delta)

Pros:

• Simple to reason about: learning happens exactly once per tick in a defined phase
• No event bus coupling — adapters don't need to know about EventBus topology
• Budget enforcement is straightforward: total Phase 5 time = sum of compute_update times

Cons:

• Every adapter is called every tick, even when there's nothing to learn
• SLEEP_PHASE consolidation (MemoryConsolidatorAdapter) is awkward — it should only fire during bio_inspired sleep, not every tick

---

Option B — Push (triggered by Blackboard events)

# Adapters subscribe to specific EventBus topics
class STDPLearningAdapter(OnlineLearningAdapter):
    def __init__(self, blackboard):
        blackboard.event_bus.subscribe("bio.stdp_spike", self._on_spike)

    async def _on_spike(self, event):
        delta = await self.compute_update({"spike": event.data})
        if self.safety_gate(delta):
            await self.apply_update(delta)

Pros:

• Zero-cost when nothing is happening (event-driven, not polled)
• MemoryConsolidatorAdapter subscribes to bio.sleep_phase_start — clean integration
• Matches the existing async adapter pattern used by all 24 current Blackboard adapters

Cons:

• Harder to enforce tick budget — events can arrive at any time
• Safety gate must be re-entrant (multiple events can queue up)
• Harder to test: requires EventBus mock, not just a blackboard_snapshot dict

---

Option C — Hybrid (pull for tick-aligned adapters, push for event-driven ones)

# Phase 5 adapters declare their own mode
class OnlineLearningAdapter(ABC):
    trigger_mode: Literal["tick", "event"] = "tick"
    event_topic: str | None = None  # only if trigger_mode == "event"

• STDPLearningAdapter → trigger_mode="tick" (every LEARNING phase)
• FederatedHotReloadAdapter → trigger_mode="event", topic "federated.round_complete"
• MemoryConsolidatorAdapter → trigger_mode="event", topic "bio.sleep_phase_start"
• ConsciousnessPlanner → trigger_mode="tick" (runs every PLANNING phase)

Pros:

• Best of both: tick adapters get budget enforcement, event adapters get natural triggers
• Declarative — the ABC makes the coupling explicit

Cons:

• More complex ABC, two registration paths in CognitiveCycle

---

My lean: Option C

The MemoryConsolidatorAdapter case makes Option A awkward — you'd need a should_run_this_tick() method to gate it. Option B loses tick budget enforcement for ConsciousnessPlanner. The hybrid gives each adapter the trigger it actually needs.

But I'm curious: is there a simpler Option D that I'm missing? What's the community's read?

[web3guru888]

Trigger Model Decision — Recommendation and Tradeoff Analysis

The three trigger models each suit different adapter types. Here's the analysis:

Pull (per-tick)

Best for: STDPLearningAdapter, MemoryConsolidatorAdapter

# CognitiveCycle calls on every tick:
await stdp_adapter.tick(snapshot)

• ✅ Simple, predictable, integrates with CycleProfiler timing budget
• ❌ Wasteful if nothing changed — STDP only produces meaningful deltas when spike patterns change
• Mitigation: return early if delta is None — negligible overhead when no update needed

Push (event-driven)

Best for: FederatedHotReloadAdapter, CoalitionFormationAdapter

# Adapter subscribes to EventBus:
blackboard.subscribe("federated.model_ready", self._on_model_ready)

• ✅ Zero overhead when no event occurs
• ✅ Natural fit for infrequent events (federated model arrives every N minutes, not every tick)
• ❌ Async event delivery can lag behind the CognitiveCycle; need to buffer the delta and apply next tick

Hybrid (condition-gated pull)

Best for: GWTInferenceBridge, ConsciousnessPlanner

# Only runs if GWT broadcast is fresh:
async def tick(self, snapshot: dict) -> WeightDelta | None:
    if snapshot.get("consciousness.gwt.broadcast_active") is None:
        return None  # skip — no broadcast
    return await self.compute_update(snapshot)

• ✅ Runs on tick schedule (predictable budget), but short-circuits cheaply when precondition unmet
• ✅ Keeps timing determinism without wasting cycles when Φ is not being computed

Recommendation

Use hybrid for all adapters — default to pull trigger but gate on a precondition check. This gives the CycleProfiler consistent timing instrumentation, while keeping overhead minimal when an adapter has nothing to do.

Adapters that are truly event-driven (federated hot-reload) should buffer their delta to blackboard["online.pending_updates"] on event receipt, and drain that buffer on the next pull tick.