Approval Bottleneck

1. Do not confuse an approval control with a bottleneck

A required review or Code Owner is not automatically a failure. Approval Bottleneck exists when a technically ready change spends a dominant share of its lead time in approval topology, reviewer-capacity waiting, serial gates, or repeated re-review. First prove the delay comes from approval flow rather than missing tests, unclear requirements, or a justified risk hold.

2. Map policy topology before measuring speed

For every change, record three separate facts: risk tier, the gate actually required, and the reviewers authorized to satisfy it. If everything from a routine dependency update to access-control code is routed through one specialist, the failure may be topology rather than a slow person. Policy authority must remain separate from team habit.

3. Queue age and review latency are different signals

queue_age is the wait before review begins; review_latency is the time from review start to a valid response. A long queue with fast reviews can indicate insufficient capacity. A short queue with many long rounds can indicate rework or re-review churn. Reading both prevents one-metric diagnosis.

4. Separate approval-blocked time from total lead time

Total lead time includes coding, CI, product waiting, review, and deployment. This lesson requires isolating the approval-related share. If a change was mostly stopped by test failures or incomplete evidence, reviewer scarcity is not the dominant blocker. The record keeps the contribution of each blocker auditable.

5. Reviewer capacity is not a headcount

eligible_reviewer_count, actual availability, skill boundary, and authorized substitution must be considered together. Five engineers do not create five units of high-risk review capacity if only one may approve access-control changes. Conversely, an authorized pool for low/medium risk can reserve the specialist for work that truly requires specialist control.

6. Serial approval multiplies waiting

Independent gates executed serially can accumulate delay even when each reviewer responds quickly. Before removing a control, test whether independent reviews can run in parallel, automated evidence can be produced earlier, or each risk tier can enter a more appropriate path. The target is the same control outcome with less avoidable waiting.

7. Stale approval is a distinct failure mode inside this boundary

GitHub can invalidate an approval after a new commit. That behavior may be required to preserve control, but repeated small edits after review can turn the dominant delay from scarcity into a re_review_loop. Adding a second reviewer may have little effect when every update restarts approval.

8. Do not label incomplete technical evidence as an approval bottleneck

If a change lacks required tests, threat analysis, rollout evidence, or acceptance evidence, a reviewer may be correct to hold it. In the third fixture, the queue looks long but several changes would not be merge-ready even with instant reviewers. The classification must remain TECHNICAL_EVIDENCE_GAP or OPEN.

9. Risk-tiered review is not a governance bypass

Low-risk changes can use a broader reviewer pool, automation, or a different approval path when policy explicitly authorizes it. This preserves governance while matching control to risk. The high-risk specialist gate can remain intact while routine changes stop consuming specialist queue capacity.

10. An authorized alternative must be explicit

Every recovery option needs authority: an authorized reviewer pool, an authorized substitute, automation eligibility, an escalation path, or a recorded exception. “Merge it for now” is not recovery. If authority for the alternative is unknown, use DEFER or ESCALATE and preserve UNKNOWN state.

11. Containment, recovery, and closure are separate

Stopping low-risk intake into the specialist queue can be containment. Creating an authorized pool or parallel review can be recovery. Closure requires lower queue age and blocked lead time, controlled re-review behavior, and preservation of the required control outcome. One successful merge is not enough.

12. Approval Flow Bottleneck Diagnosis & Recovery Record v1

The record includes change_risk, required_gate, eligible_reviewer_count, queue_age, review_latency, blocked_lead_time, reviewer_availability, serial_steps, re_review_count, technical_evidence_complete, authorized_substitute, automation_eligibility, escalation_path, control_preserved, closure_probe, and residual_governance_risk. Every claim is labeled OBSERVED, AUTHORITY, INFERRED, or UNKNOWN.

13. Build classification from evidence

HEALTHY_CONTROL_FLOW means the required control exists and queue/rework are proportionate. APPROVAL_CAPACITY_BOTTLENECK means technical evidence is complete but approval capacity or topology dominates waiting. RE_REVIEW_CHURN means reviewer capacity is adequate but stale invalidation and repeated edits dominate delay. TECHNICAL_EVIDENCE_GAP means approval is a symptom, not the cause. If policy or capacity is unknown, remain OPEN.

14. Lab: eight fixtures and 64 assertions

The lab covers specialist serial overload, a justified high-risk hold, incomplete technical evidence, a healthy reviewer pool, stale-approval churn, an unavailable reviewer with an authorized substitute, a low-risk automation candidate, and unknown policy topology. Eight deterministic outputs are checked per case: gate state, capacity state, queue state, re-review state, technical-evidence state, dominant blocker, recovery path, and decision—64 assertions total.

15. Exit checklist and transfer

Before exit, separate policy-required gates from team habit; measure queue age and review latency independently; attribute blocked lead time to actual blockers; record reviewer eligibility and availability; check technical evidence before blaming approvals; choose alternatives only with authority; and prove closure with lead-time improvement plus control_preserved=true. Then rebuild the transfer fixture from blank evidence: a second medium-risk reviewer is added, but every code-changing commit invalidates prior approval. Decide whether scarcity still dominates or re-review churn has taken over.