Q&A: What happens when the Phase 5 safety gate rejects a WeightDelta — silent fail, exception, or Blackboard event?

[web3guru888]

What happens when the safety gate rejects a WeightDelta mid-tick?

Issue #204 outlines Phase 5's OnlineLearningAdapter ABC. The safety gate is a simple threshold check by default:

def safety_gate(self, delta: WeightDelta) -> bool:
    return delta.confidence >= 0.3

But what should happen when the gate fires and rejects a delta?

---

Question 1: Reject silently vs. raise vs. log?

Three options:

A — Reject silently (return early)

delta = await adapter.compute_update(snapshot)
if delta and adapter.safety_gate(delta):
    await adapter.apply_update(delta)
# If gate fails: do nothing

B — Raise a typed exception

class SafetyGateViolation(Exception):
    def __init__(self, delta, reason): ...

# Caller catches and logs, cycle continues

C — Write rejection event to Blackboard

# On gate failure:
blackboard.write("online.rejected_deltas", {
    "source": delta.source_module,
    "confidence": delta.confidence,
    "tick_id": current_tick,
    "reason": "below_threshold"
}, ttl=10)

Option C is the most observable — the CycleFaultSummary can pick it up, SSE stream shows it, and a human can inspect what's being rejected. It also means the Blockchain module can audit rejections.

---

Question 2: Should rejected deltas flow to the MeshResultAggregator?

If multiple agents each contribute a WeightDelta for the same parameter (e.g. five agents each computing an STDP update for the same synaptic weight), and one agent's delta is rejected by the safety gate, should that rejection be factored into the MeshResultAggregator's confidence calculation?

Options:

• Exclude rejected deltas entirely — cleaner, fewer moving parts
• Include as a zero-confidence data point — lowers the aggregate confidence, which is honest
• Escalate to CRITICAL if >50% of deltas are rejected — prevents silent degradation

---

Question 3: Re-attempt rejected deltas on the next tick?

If MemoryConsolidatorAdapter.compute_update() generates a delta with confidence=0.25 (below threshold), should the system:

• Discard it — the learning step is lost
• Retry on the next tick with a recomputed delta (the underlying data might change)
• Queue it for human review in a separate buffer

---

My answers

1. Option C — write to Blackboard. Silent rejection is fine for production but terrible for debugging. The online.rejected_deltas key costs nothing and makes everything inspectable.

2. Exclude rejected deltas from aggregation — including a confidence=0 data point distorts the WEIGHTED strategy without adding signal. But escalate to CRITICAL if ≥50% of agents are rejected in the same tick.

3. Discard and retry naturally — the underlying data changes every tick, so the delta from tick N is stale by tick N+1 anyway. No explicit retry queue.

What are others' thoughts — especially on the MeshResultAggregator integration?

[web3guru888]

Safety Gate Rejection — What Happens Next

When safety_gate(delta) or the formal safety_adapter.verify() rejects a WeightDelta, three things happen:

1. Rejection logged to Blackboard

blackboard.write(
    key="safety.weight_update_blocked",
    value={
        "module": delta.source_module,
        "parameter_path": delta.parameter_path,
        "confidence": delta.confidence,
        "content_hash": delta.content_hash(),
        "reason": verdict.reason,          # if formal verification ran
        "timestamp": time.time(),
    },
    ttl=3600  # retained for 1 hour for audit
)

2. The module state is unchanged

apply_update() is never called. The module's internal parameters remain at their last-known-good state. This is intentional — a rejected update should be a no-op, not a partial write.

3. CycleFaultSummary records the event

The CycleFaultSummary (designed in #144) treats a safety rejection as a FaultSeverity.WARNING — not a full failure, but worth surfacing on the /cycle/health/stream SSE endpoint.

---

Persistent rejection: escalation path

If the same adapter is rejected 3+ times in a row, AgentDiscovery should mark that agent's status as DEGRADED. The pattern:

class OnlineLearningAdapter(ABC):
    _consecutive_rejections: int = 0
    REJECTION_THRESHOLD: int = 3

    async def tick(self, snapshot: dict) -> None:
        ...
        if not approved:
            self._consecutive_rejections += 1
            if self._consecutive_rejections >= self.REJECTION_THRESHOLD:
                blackboard.write("mesh.agent.{self.agent_id}.status", "DEGRADED")
            return
        self._consecutive_rejections = 0  # reset on success
        await self.apply_update(delta)

Recovery path

A DEGRADED adapter can recover when:

• The underlying model weights are reset to last-known-good (manual or automated)
• A federated aggregation round completes with higher confidence
• The safety module constraint that triggered rejection is resolved

Recovery sets mesh.agent.{id}.status back to HEALTHY — AgentDiscovery picks this up on its next heartbeat cycle.