Operate approval queues without turning delay into permission

Pattern 09 companion: Python example · Behavioral tests · Example license

Watch the queue, not just the button

A review interface can be available while the approval process is failing. Proposals may wait beyond their useful lifetime, reach the wrong reviewer or contain insufficient evidence to support a decision. Measure pending age, expiry, reviewer assignment failures and rejection reasons. A high approval rate is not inherently a quality signal; it can mean good proposals, weak review or pressure to clear a backlog.

For an incident-response assistant, define which operations require review and what evidence reviewers need. A restart during a safe maintenance window differs from a restart during an active data migration. The approval record should point to the relevant context, and a changed context should invalidate or supersede the proposal. Do not force the operator to remember facts that the system could check directly at dispatch.

Architecture and request sequence

Component diagram for Operate approval queues without turning delay into permission — Original reference architecture by Sandeep Belgavi. Arrows show the responsibilities and transitions described below.

Request sequence for Operate approval queues without turning delay into permission — Illustrative sequence for this design; failure and recovery variants are explained in the article.

Expire safely and re-propose explicitly

The reference checks expiry both when recording a decision and when consuming approval. If a request expires, create a fresh proposal after rechecking the incident rather than extending the old timestamp automatically. The new record should link to the superseded one for explanation. This keeps the history clear: the reviewer approved one bounded action under one context, and the system later asked about another.

Test the exact expiry boundary, including a decision that is timely but a dispatch that is late. The companion tests cover both cases with an injected logical clock. In a deployment, monitor clock synchronization and use server-side time. Client clock errors should not grant additional authority, and a browser left open overnight should not turn yesterday's proposal into today's live operation.

Recover a paused process honestly

A pending request survives reopening the SQLite database, so the reviewer need not approve again solely because the worker restarted. That persistence is useful only when the resumed worker checks the same proposal fingerprint and revision. A newly generated action that happens to share an incident identifier is not the same request. Bind the workflow's resume point to the approval identifier and verify the relationship on every transition.

The local marker does not solve remote execution recovery. If dispatch has an uncertain outcome, inspect the destination's receipt or state before deciding whether to retry. Keep approval state and execution state separate in operator tooling. Approved means the action was authorized; dispatched means an attempt was made; confirmed means the destination effect was verified. Collapsing those labels into done makes incident review and postmortems unreliable.

Protect the reviewer identity path

The module accepts a principal from trusted code and compares it with the assigned reviewer. It does not authenticate users. A deployed service must establish identity before calling that policy function and enforce tenant and role boundaries around proposal access. An attacker should not learn another team's incident details simply by guessing an approval identifier, even if they cannot approve it.

Test forged reviewer fields, reused session responses, changed action bodies and attempts to approve a request after assignment changes. Record authorization failures without logging credentials or sensitive evidence bodies. A model can explain a proposal or summarize supporting logs, but it must not certify its own identity as a reviewer. The decision endpoint should remain usable and secure even if the proposal generator produces malicious or malformed text.

Measure human and system cost separately

Track the number of proposals per completed incident, median review time, requests requiring clarification and expired requests that were never viewed. These metrics reveal whether the assistant is saving effort or merely moving work into a queue. Model inference cost is only one part of the system's economics; unnecessary approval interruptions can dominate the operator's workload during an outage.

Set a proposed initial cap on concurrent pending requests per incident and consolidate mutually exclusive actions into one coherent review. Do not auto-approve to satisfy a latency target. If reviewer capacity is exhausted, enter an explicit escalation or nonexecution mode. Use representative synthetic scenarios to evaluate whether summaries omit important consequences, then assess real authorized cases through the evaluation process. A short review time achieved by hiding detail is not success.

Release with a narrow authority boundary

Begin with proposals that only produce local markers, matching the original demonstration. Next connect a reversible, tightly scoped tool in a test environment and verify the full authorization-to-receipt path. Rehearse duplicate clicks, concurrent submissions, stale revisions, expiry, rejection and worker loss. Ensure the interface shows the final service decision rather than optimistically displaying success before validation completes.

Acceptance requires that changed proposals cannot reuse consent, denied or expired requests cannot dispatch, and the resulting action can be traced to the exact approved record. Keep a pause control that stops dispatch without erasing pending decisions or audit history. This pattern should reduce uncertainty around consequential actions. If the only evidence of control is that a person once clicked a button, the approval boundary is not yet complete.