THE FIELD GUIDE / AI & THROUGHPUT

AI waits, provider backoff & recovery

See why work is waiting, when it can resume and which interruptions require a human review.

Mr Patchy documentation · 2 min read

A wait is not a failed assessment

Update scoring, incident/startup advisory plans and release configuration review retain durable eligibility when shared pacing, daily spending or provider backoff blocks admission. A timed wait shows its next eligible start; an administrator pause shows an explicit resume requirement. Packages, Activity and AI worker status expose retained work, counts and blockers. Waiting work releases execution capacity rather than sleeping in a busy slot.

Respect one provider backoff across the fleet

Transient provider/network failures establish a shared durable floor before another paid request is admitted. Retry-After values take precedence over bounded exponential jitter up to the shared 24-hour provider cap. An audited administrator clear removes the provider floor while retaining independent local retry delays. A manual retry and a different AI purpose respect the same boundary. Requests already in flight cannot be recalled, and each transmitted attempt retains its own usage or uncertain-spend record.

Resume only under current conditions

Eligibility is the earliest time to try admission again, not a guaranteed start or permission to bypass a control. The scheduler rechecks server lifecycle, current evidence, global/per-server pause, data sharing, finite concurrency, provider backoff, budget and rate policy. Changed package evidence supersedes old scoring work. A pre-send refusal makes no provider call and consumes no paid-call reservation.

Retain uncertainty after interruption

If a worker disappears after advisory work starts, interrupted paid work enters an explicit recovery hold. Open the retained AI run, call and budget records before an administrator releases the server queue. Review distinguishes a request that was never sent from a transmitted request with no trustworthy result. Lost responses can still be billable; recovery does not quietly replay them.

Distinguish plan recovery from target recovery

An advisory-plan hold concerns retained AI/spend evidence. An uncertain patch or release execution concerns possible changes on the target and requires the corresponding operation/target review. Releasing either hold is a recorded recovery decision; it does not accept an incomplete verdict or approve a response. See reboot, rollback and recovery.

Use manual checks and release planning deliberately

Interactive connection tests return their result or controlled refusal to the caller. Multi-stage release review seals accepted results before the next provider call. A resumed plan reuses completed stages when evidence, model, policy and reference context match. A deferred plan stays ineligible for approval, and a sent call with an uncertain result requires reconciliation. The spending guide explains reservations, reset times and uncertain charges.

Go deeper

Open the application reference for capability scope and technical details.

Open Open SECURITY_IMPLEMENTATION.md on GitHub ↗

Actual application interface with illustrative documentation data.