Name of a scorer whose weight has dropped near the WEIGHT_MIN floor.
A dead scorer is effectively not participating in selection. If the
scorer encodes a signal that should matter (e.g., latency for a
latency-sensitive workload), the learning loop may have over-penalized
it from early failures. Consider raising its per-claim _weight_<name>
override to inject a floor above WEIGHT_MIN.
null if no scorer is near the floor.
Name of a scorer that has captured more than 70% of total weight.
A dominant scorer means the other signals are largely ignored. This may be correct (e.g., resonance is genuinely the best predictor) or a sign of overfitting to a narrow workload. Inspect the scorer delta table in the offline analyzer to distinguish the two.
null if no scorer exceeds the threshold.
True when 10 or more updates have been applied but no weight has moved more than 0.002 from its default.
Possible causes: all requests are going to name-selector monads (no
mesh-claim decisions), zero-contribution breakdowns (scorer values are
all zero), or the bridge is not calling correlateOutcome. Check that
MONAD_DEBUG_WEIGHTS=1 shows updates after forwarded requests.
True when the recent reward signal alternates sign frequently.
Computed over the last 10 rewards: if more than 40% of consecutive pairs change sign, the learning loop is receiving contradictory signal. Common causes: two claimants with similar scores and opposite reliability profiles, or an exploration rate that is too high for the current mesh size.
Runtime health signals for the adaptive learning loop.
These are diagnostic, not prescriptive — they surface conditions that warrant attention, not automatic corrections. All four can be false simultaneously on a healthy, well-calibrated system.