Outbound validator + refine loop

Every outbound message — guest reply, task auto-send, manual send — runs through the outbound validator before it leaves the platform. The validator returns a verdict (clean / has-findings / blocked) per message; the platform's response to the verdict depends on the binding mode and the operator's per-template configuration.

This section documents the unified validation + refine architecture shipped in

Sections

• Validation verdicts — what the validator says about a draft.
• Refine button (Refine / Send Anyway / Dismiss) — operator's 3 options on a blocked draft.
• Autonomous auto-refine loop — when the platform retries refinement on its own, with a cap.
• WhatsApp block alerts — interactive 3-button WA notification when a send is blocked.
• Configurable blocking threshold — per-binding / per-template "block all / major+critical / critical-only" knob.

One unified validation layer

Before

both paths route through one validator with two modes:

• operator-in-loop — validator surfaces findings; operator decides Refine / Send Anyway / Dismiss.
• autonomous — validator runs the auto-refine loop (cap 5 attempts), then either passes or notifies the operator.

The mode is per-template (configured in the Task Templates editor).

How a typical send flows

Operator types / accepts draft → validator runs → verdict
 ├─ clean → send fires
 ├─ has-findings (below blocking threshold) → send fires + finding logged
 └─ blocked → routes to one of:
 ├─ operator-in-loop: Refine / Send Anyway / Dismiss buttons appear
 └─ autonomous: auto-refine loop (cap 5) → re-validate → if still blocked, notify operator via WA

What used to fail silently (now caught)

Pre-

(general outbound delivery guard) +:

• A blocked send never settles the task done.
• The task surfaces with the validator's reason + the Refine / Send Anyway / Dismiss options.
• The WA notification surfaces the block, not a false completion (see WA block alerts).