loop-pipeline-router

Loop Pipeline Router

Overview

Loop pipelines introduce feedback for self-correction when perfect first-attempt reasoning is unrealistic. The decision that makes a loop a loop is the conditional edge after the validate node. Naively this is "valid -> proceed, else -> retry" (Example 5-6), but production needs the nuance of Example 5-9: distinguish correctable errors (refine) from fundamental ones (stop), and handle the retries-exhausted case (fall back to an alternative strategy) so the loop neither terminates prematurely nor spins forever.

The unified decision table:

valid                            -> proceed
correctable + retries remaining  -> refine (retry_count += 1, loop back)
correctable + retries exhausted  -> fallback_strategy
fundamental                      -> terminate_with_partial

The finite retry budget (Example 5-6's retry_count < 3 / recursion_limit) is the explicit termination guarantee. An invalid result with no error diagnostic is treated as fundamental — you cannot safely refine what you cannot diagnose.

In the DevOps latency investigation (account 123456789012), document verification on a related claim returns "incomplete" — the operative report lacks anesthesia-time records. That is a correctable error: refine (request the specific missing documentation, re-verify), bounded to three request cycles before escalating. A schema-level contradiction in the plan ("synchronous AND event-driven for the same operation") is fundamental: terminate with partial results rather than burn the retry budget on an unfixable error.

When to Use

• First-attempt success is unrealistic and a validator can flag correctable errors
• Documentation-gap re-requests, plan refinement, transient-failure recovery
• You need a guaranteed-terminating self-correction loop with an audit trace

Phrases: "loop pipeline", "refine and re-validate", "retry with feedback", "correctable vs fundamental error", "fallback planner", "recursion limit".