ORA-2026-0059: Symptom-to-action distance axis

ORA-2026-0059: Symptom-to-action distance axis

Pattern

Three doctrines — ORA-2026-0053, ORA-2026-0056, ORA-2026-0058 — sit on the same axis: the distance between a symptom appearing and corrective action executing.

Current state

user → STRAT reads symptom → dispatch ticket → claimer picks up → execute
                    ~5 min           ~20 min            ~25 min      ~50 min total

Target state

symptom → watchdog detects → execute
              ~30s              ~90s total

The gap between current and target is three kinds of distance: 1. Visibility: the symptom exists but no output names it (0053 fixes this) 2. Routing: the symptom is visible but action requires Chad to wake a seat (0056 fixes this) 3. Authority: the symptom is visible, the seat is awake, but the seat relabels instead of acting (0058 fixes this)

The competence failure in dispatch-without-monitor

PRIOR-DIAGNOSTIC (ORA-2026-0007) captures why a dispatch was made — it is a competence receipt for the decision to dispatch. But there is no analogous receipt for whether the dispatch landed. The fleet dispatches and moves on. This is a Pillar 2 (competence) gap:

• Pillar 2 says every output teaches the fleet (cite doctrine + memory

so seats learn from each other's decisions).

• A dispatch that is never monitored teaches nothing — neither the

dispatching seat nor the fleet learns whether the dispatch pattern worked or failed.

• The result: dispatch becomes fire-and-forget, and BLOCKED items

accumulate silently until the operator escalates.

The missing artifact: dispatch-outcome receipt. Analogous to PRIOR-DIAGNOSTIC but backward-looking: did the claimer pick it up? Did it unblock downstream? Was the decision rendered?

Proposed mechanisms

1. OUTCOME-CHECK field on dispatch posts

OUTCOME-CHECK: 2026-04-25T15:30Z (30 min after dispatch)

The dispatching seat (or a cron watchdog per ORA-2026-0033) re-reads the feed at the named time to verify claim + progress. If unclaimed, the dispatch failed — re-dispatch or render directly.

2. Watchdog cron for dispatch-outcome monitoring

A thin-pointer cron (per ORA-2026-0033) that: 1. Reads all dispatches with OUTCOME-CHECK timestamps in the past 2. Checks fleet-active-queue for claim status 3. For unclaimed dispatches past their check time: posts a STALE-DISPATCH alert to the feed with re-dispatch recommendation

3. Dispatch-outcome scoring

Track dispatch-to-claim latency as a fleet health metric alongside decision-render throughput (ORA-2026-0058 remediation §1). A fleet where dispatches land in <5 min is healthy. A fleet where dispatches sit unclaimed for >30 min has a routing or capacity problem.

Graduation criterion

This pattern reaches M2 when the dispatch-outcome receipt is implemented on ≥3 dispatches and the watchdog cron fires at least once. It reaches M3 when dispatch-to-claim latency is measurable across a 24-hour period.