Ideas: How should ASI:BUILD respond to agent dissent? Passive metric, automatic escalation, or task-criticality gating?

[web3guru888]

MeshResultAggregator (see #159) produces a dissent_ratio every time multiple agents give conflicting answers. The question is: what should the system do with it?

Three Options

Option A — Passive metric only

Write dissent_ratio to the Blackboard as metadata. Let downstream consumers (CognitiveCycle, PLN) decide whether to act on it.

Pro: Maximum flexibility. No implicit coupling between aggregator and safety system.
Con: Dissent may be silently ignored. High-dissent safety decisions could proceed unchecked.

Option B — Threshold-based escalation

If dissent_ratio > threshold (e.g., 0.4), automatically write a safety.dissent_alert entry to the Blackboard and pause the CognitiveCycle tick.

Pro: Catches dangerous disagreements automatically.
Con: False positives — benign disagreements on non-critical tasks stall the cycle.

Option C — Task-type gating

Tag tasks at dispatch time with a criticality field. Only escalate dissent for criticality=HIGH tasks (safety, goal updates, agent directives).

Pro: Precision. Critical tasks get extra scrutiny; routine tasks run fast.
Con: Requires callers to correctly classify task criticality. Misclassification is a subtle bug.

Option D — Confidence-adjusted dissent

Instead of raw dissent_ratio, weight by confidence: if the winning agent has confidence 0.98 and dissent_ratio is 0.3, that is less concerning than confidence 0.6 with the same dissent.

Composite score: concern = dissent_ratio × (1 - winner_confidence)

Only escalate if concern > threshold.

Pro: More nuanced than raw dissent.
Con: Adds complexity to what should be a simple output field.

My Inclination

Option C + D — task criticality gating with confidence-adjusted concern score. Safety-critical tasks get automatic escalation when concern > 0.2. Routine tasks just log the metric.

This mirrors how the Safety module gates Blackboard writes (#37) — we already have the criticality concept, we should reuse it rather than inventing a parallel system.

What do you think?

1. Should dissent_ratio be the primary escalation signal, or something more composite?
2. Is task criticality the right axis, or should we use output type (numeric vs. decision vs. action)?
3. Could high dissent be a positive signal in some cases — e.g., diverse perspectives producing a richer ensemble?