1) Diagnostic Identity

Diagnostic Name: Review Capacity

Short Name / Symbol: review_capacity

Diagnostic Class: Review / Audit / Correction / Decision Quality / Governance Throughput

Primary Function: Estimate whether a system has enough capacity to inspect, evaluate, compare, contest, verify, revise, and approve decisions, classifications, repairs, exceptions, appeals, memories, metrics, or actions before they become consequential.

Primary Use: Determine whether review systems can keep pace with decision load, risk level, complexity, appeal demand, feedback volume, and memory durability.

Core Risk if Ignored: The system may appear governed, audited, or accountable while review queues, shallow review, rubber-stamping, delay, fatigue, or under-resourcing prevent meaningful correction.

Core Risk if Overtrusted: Review may be expanded so heavily that it creates procedural drag, bottlenecks, avoidance, or false safety through process volume.

2) Mechanical Definition

review_capacity measures the system’s usable ability to evaluate decisions and signals before, during, and after consequence.

review_capacity answers:

Can the system meaningfully inspect what it is about to bind, approve, reject, classify, repair, or remember?

Review capacity is not the same as having a review process.

A system may have formal review while lacking review capacity if reviewers lack:

time
attention
authority
evidence access
domain context
independence
memory
comparative cases
repair power
ability to slow action
ability to reverse outcomes

Review Capacity is closely related to attention_capacity, but narrower.

• attention_capacity asks whether the system can notice and hold signal.
• review_capacity asks whether the system can formally or functionally evaluate that signal for decision, correction, or consequence.

A simple form:

review_load > review_capacity ⇒ rubber-stamp / delay / missed-error risk ↑

3) What the Diagnostic Measures

Direct Measurement Target

review_capacity measures:

• ability to inspect evidence
• ability to compare alternatives
• ability to review classifications
• ability to review appeals
• ability to review exceptions
• ability to review repairs
• ability to review memory binding
• ability to review high-risk actions
• ability to verify source lineage
• ability to test claims before closure
• ability to correct prior decisions
• ability to identify insufficient evidence
• ability to slow or block action
• ability to preserve review quality under load
• ability to match review depth to consequence severity

Indirect / Proxy Signals

review_capacity can be estimated from:

• review backlog
• review queue age
• time-to-review
• reviewer load
• shallow review patterns
• rubber-stamp approvals
• recurring errors after review
• review findings ignored
• high reversal rates after external audit
• appeals delayed beyond usefulness
• exception reviews skipped
• repair-complete claims approved too quickly
• memory bindings reviewed after harm
• reviewers lacking source access
• reviewers lacking authority to change outcome
• high-risk decisions receiving same review as low-risk decisions
• review fatigue
• review being used as procedural cover rather than correction

What It Does Not Measure

review_capacity does not directly measure:

• whether the reviewed decision is correct
• whether reviewers are wise
• whether more review is always better
• whether all decisions require review
• whether review should block action indefinitely
• whether review is independent
• whether review has repair authority
• whether review quality is sufficient in all domains
• whether review burden is fairly distributed
• whether low review volume means low risk

High review_capacity means the system can evaluate more decisions or signals with meaningful depth.

It does not guarantee good judgment.

Low review_capacity means decisions may move faster than verification.

It does not mean the system is careless; it may be under-resourced, overloaded, or facing high complexity.

4) Canonical State Variables Involved

Canonical state vector:

S = {O, H, ε, ι, Au, µᵢ, BΣ, K, R, Φ}

Primary Variables

• Au: review requires traceable evidence, rationale, source lineage, and decision history
• O: review protects coherence by preventing misclassification, bad repair, and poor selection
• H: hidden debt rises when review misses or delays correction
• R: restoration depends on review identifying what must be repaired
• µᵢ: integrity requires decisions to remain inspectable and correctable
• BΣ: review protects boundaries before constraints, access, classifications, or permissions bind

Secondary Variables

• ε: visible errors may reveal review failure
• ι: pseudo-review creates appearance of governance while correction fails
• K: compatibility decisions require review proportional to coupling depth
• Φ: review can be captured by performance metrics or throughput targets

Variables Commonly Confused With review_capacity

5) Localization Signature

Primary Legibility Layers

• U1 — Power / Budgets: review requires time, staffing, expertise, attention, compute, and institutional resources
• U3 — Execution: where reviews are performed, skipped, rushed, or delayed
• U4 — Classification / Metrics / Narratives: where review labels decisions as approved, denied, provisional, repaired, or escalated
• U5 — Coordination / Time: where review queues, deadlines, escalation timing, and approval sequencing occur
• U7 — Memory / Recurrence: where review findings, precedents, corrections, and recurring missed issues are stored
• U6 — Coherence Field: where trusted review sustains legitimacy and shared reality

Primary Leverage Layers

• U1: increase reviewer time, staffing, expertise, or tooling
• U3: improve review execution and evidence inspection
• U4: refine review criteria and status labels
• U5: manage review timing, queue priority, and escalation
• U7: store review precedent and correction memory
• U2: define which decisions require which level of review

Verification Layers

• U1: are review resources sufficient?
• U3: are reviews performed meaningfully?
• U4: are review outcomes classified accurately?
• U5: are reviews timely enough to matter?
• U7: do review findings prevent recurrence?
• U6: does review restore trust and coherence?

Common Mislocalizations

• Treating process as review capacity
• Treating approval as review
• Treating reviewer existence as review quality
• Treating delay as depth
• Treating speed as efficiency
• Treating checklist completion as judgment
• Treating high approval rate as quality
• Treating low reversal rate as correctness
• Treating review backlog as harmless
• Treating rubber-stamp as consensus
• Treating audit trail as reviewed truth
• Treating external audit as ordinary review substitute

6) Input Requirements

Required Inputs

To estimate review_capacity, the system needs:

• review domain being evaluated
• decision or signal type under review
• review load
• review resources
• reviewer expertise
• reviewer authority
• evidence access
• review timing
• consequence severity
• affected variables in S
• current backlog
• review criteria
• escalation pathways
• appeal volume
• exception volume
• review outcome history
• recurrence after review
• ability to correct or block outcomes

Optional Inputs

These improve precision:

• review queue age
• average review time
• reviewer-to-case ratio
• reversal rates
• external audit comparisons
• reviewer fatigue indicators
• review quality sampling
• false positive / false negative rates
• appeal success data
• exception review data
• memory-binding review data
• high-risk gate review history
• source inspection records
• review notes
• dissent within review
• post-review recurrence
• affected-node validation
• public/private review comparison

Missing Input Behavior

If review_capacity inputs are missing:

• If review load is unknown, capacity cannot be judged
• If review authority is unknown, review may be advisory only
• If evidence access is unknown, review may be superficial
• If backlog is unknown, timeliness may be overestimated
• If review criteria are unknown, review may be arbitrary
• If recurrence after review is unknown, review effectiveness is unvalidated
• If consequence severity is unknown, review depth may be mismatched
• If reviewer independence is unknown, capture risk may be hidden

Default missing-input posture:

map review load → map reviewer resources and authority → match review depth to consequence → validate with recurrence and reversals

7) Diagnostic States / Ranges

These ranges are qualitative and should be domain-calibrated.

Healthy / Coherence-Supporting Range

Review capacity is sufficient for load, consequence, complexity, and timing.

Signals:

• review queues are manageable
• reviewers have evidence access
• reviewers can slow, reverse, or escalate decisions
• review criteria are explicit
• high-risk decisions receive deeper review
• review findings alter outcomes
• recurrence declines after review
• appeals are processed in time
• exception reviews are meaningful
• review memory supports future decisions

Recommended posture:

continue review process
monitor queue and recurrence
store review findings in U7
scale review with consequence severity

Watch Range

Review capacity is under pressure but still functioning.

Signals:

• backlog is growing
• review timing is slowing
• reviewers are relying on summaries
• high-risk and low-risk reviews are not sufficiently differentiated
• appeal review is delayed
• exception review is inconsistent
• review notes are thinning
• recurrence is not yet severe but warning signs appear
• reviewers have limited time for alternatives or affected-node signal

Recommended posture:

triage reviews by consequence
increase reviewer support
improve evidence access
protect high-risk review depth
avoid irreversible closure

Degraded Range

Review capacity is insufficient; decisions are moving faster than meaningful evaluation.

Signals:

• reviews are rubber-stamped
• backlog exceeds useful timing
• reviewers lack evidence access
• review cannot change outcomes
• high-risk decisions receive shallow review
• appeals are delayed past usefulness
• exceptions are approved without analysis
• repair-complete claims pass without validation
• recurrence persists after review
• external audit often finds missed issues

Recommended posture:

pause high-impact closure
increase review resources
limit decision throughput
restore evidence access and authority
repair review memory

Contraindicated:

scaling decision volume
durable memory binding
irreversible constraints
public certainty from reviewed status
treating formal approval as coherence

Critical / Collapse-Prone Range

Review has become symbolic, captured, absent, or structurally unable to prevent downstream error.

Signals:

• review exists only as procedure
• reviewers cannot block or correct
• high-risk actions pass unexamined
• backlog is unbounded
• review is bypassed during urgency
• review failure causes legitimacy shock
• affected nodes seek external review
• review memory is unreliable
• repeated harms were “reviewed”
• system cannot distinguish approval from correction

Recommended posture:

freeze review-dependent actuation
preserve evidence
activate independent review
rebuild review authority and capacity
reopen high-risk decisions
correct U7 review memory

False Positive Risk

review_capacity may appear low when:

• review is intentionally selective
• low-risk decisions are correctly streamlined
• backlog reflects increased reporting, not failure
• review is slow because evidence review is deep
• reviewers are batching similar cases efficiently
• upstream FI has resolved many issues before formal review
• review intensity is temporarily focused on origin-layer repair

False Negative Risk

review_capacity may appear healthy when:

• approvals are fast because reviews are shallow
• backlog is hidden through closure metrics
• reviewers rely on summaries without source
• appeal demand is low because appeal is distrusted
• review exists but cannot change outcomes
• recurrence window is too short
• external audit has not yet occurred
• affected-node signal is excluded
• review quality is judged by throughput

8) Leading Indicators

review_capacity degradation appears early as:

• review notes get shorter
• reviewers ask for more time
• high-risk cases wait longer
• summaries replace source evidence
• appeal backlogs grow
• exception review becomes routine
• review criteria are skipped
• review meetings become perfunctory
• approval rate rises under pressure
• dissent inside review disappears
• reviewers stop considering alternatives
• recurrence after review increases
• affected-node evidence is deferred
• review is invoked as legitimacy without showing work

9) Lagging Indicators

review_capacity failure has already accumulated debt when:

• external audit overturns reviewed decisions
• legitimacy shock follows review exposure
• high-risk errors were approved
• affected nodes abandon internal review
• repeated harms pass review
• official memory overstates review quality
• review backlog becomes crisis
• false classifications persist
• repair-complete claims fail after review
• reviewers lose credibility
• review process must be rebuilt
• decisions must be reopened at scale

10) Interpretation Rules

How to Read review_capacity

review_capacity should be read as:

usable evaluation capacity relative to decision load and consequence severity

It is not merely review existence.

A system may have:

• high review capacity and few formal reviews because upstream filters work
• low review capacity despite many reviewers if authority or evidence access is weak
• high review speed and low review quality
• slow review and high review quality
• strong review for low-risk decisions and weak review for high-risk decisions
• high formal review and low affected-node trust
• high internal review and low independence

What Changes Its Meaning

review_capacity changes meaning under:

• high consequence severity
• high memory_binding_risk
• low classification_reversibility
• high appeal volume
• high exception_rate
• high High Risk Gate load
• low attention_capacity
• low Au_eff
• weak FI_integrity
• high affected_node_cost
• high resource_asymmetry
• high rank_threshold_gap
• high crisis_loop_index
• high Cv(t)
• high U8 forcing

Context Modifiers

High consequence severity: review depth must rise.

High memory-binding risk: review must happen before U7 hardens.

Low reversibility: review must happen earlier.

High appeal volume: review system may be overloaded.

High exception rate: review must distinguish adaptation from hidden governance.

Low attention capacity: review quality degrades.

Low Au_eff: reviewers cannot inspect evidence.

High rank threshold gap: review may protect some nodes more than others.

High crisis pressure: review may be bypassed.

Domain Calibration Notes

review_capacity should be calibrated by domain:

• in engineering: code review, architecture review, incident review, release review, security review
• in AI: safety review, eval review, memory review, tool-call review, policy review, model behavior review
• in institutions: complaint review, appeal review, hiring/promotion review, policy review, service quality review
• in governance: legal review, administrative review, oversight, audit, public remedy review
• in relationships: review of shared conclusions, repair progress, boundary agreements, recurrence patterns
• in archives: canon review, glossary review, cross-link review, source review, deprecation review, spec review

11) Operator Sequencing Implications

If review_capacity Is Healthy

Allowed with ordinary gate checks:

• Γ can select after review
• Π can constrain with reviewed rationale
• High Risk Gate can process high-risk bindings
• ℛ can use review findings for repair
• U7 can bind reviewed memory with provenance
• Δ can test review assumptions
• Τ can proceed with monitored decision quality

Recommended:

evidence → review → Γ selection → Π/ℛ action → U7 reviewed memory → recurrence validation

If review_capacity Is Low

Recommended:

pause high-impact decisions → triage review queue → increase review resources → restore evidence access and correction authority

Or:

keep outcomes provisional until review capacity catches up

Avoid or delay:

• durable memory binding
• irreversible constraints
• high-risk classification
• repair-complete claims
• scaling decision volume
• automation of unreviewed decisions
• public certainty from approval status
• exception expansion without review

Operators Recommended Under Low Review Capacity

• Π: limit decision throughput and protect review gates
• Γ: prioritize which reviews matter most
• Au: improve evidence accessibility
• FI: route feedback into review
• ℛ: repair review process
• Θ: damp urgency and approval pressure
• Ψ: restore attention to source evidence
• High Risk Gate: tighten until review is sufficient

Operators Contraindicated Under Low Review Capacity

• Γ hard closure: may close unreviewed outcomes
• Π irreversible constraint: binds insufficiently reviewed decisions
• ⊕ composition: embeds review debt
• Τ acceleration: outruns review
• Σ escalation: sacralizes unreviewed claims
• ✕ force: enforces decisions without correction capacity
• ⊗ deep coupling: increases review load and propagation risk

12) Gate Implications

Gates Strengthened By Reliable review_capacity

• High Risk Gate: review capacity determines whether high-risk binding can be safely processed
• Au-Actuation: review uses evidence trails meaningfully
• FI-Gate: feedback can be evaluated, not just received
• MS-Gate: checks whether review access and quality are symmetrical
• ☷ᵢ: ensures principle claims are reviewed in context

Gates Weakened If review_capacity Is Poor or Unknown

If review capacity is low:

• High Risk Gate may bottleneck or rubber-stamp
• Au may generate traces no one reviews
• FI may surface feedback that review cannot process
• MS may miss unequal review depth
• ☷ᵢ may be applied without sufficient context
• Π may overconstrain from shallow review
• Γ may select prematurely
• ℛ may validate incomplete repair

Gate Outcomes Affected

Low review_capacity should push gates toward:

• Pause high-impact closure
• Require review triage
• Require evidence access
• Require reviewer authority
• Require consequence-weighted depth
• Deny durable memory binding
• Deny irreversible actuation
• Deny review-based legitimacy claims
• ∅ for high-risk action where meaningful review cannot occur in time

13) Scaling Behavior

review_capacity becomes harder under scale because decision volume, evidence volume, complexity, appeals, exceptions, and memory bindings increase.

As systems scale:

• review load grows
• review queues lengthen
• reviewers specialize
• review criteria fragment
• appeals increase
• exception reviews multiply
• summaries replace evidence
• high-risk cases compete with low-risk cases
• reviewer fatigue increases
• review becomes procedural
• review authority separates from review labor
• external audit risk increases
• mistakes propagate before review catches them
• memory binds faster than review can inspect

Scaling Risks

• rubber-stamp governance
• review theater
• appeal backlog
• exception drift
• high-risk binding errors
• unreviewed memory contamination
• delayed correction
• reviewer burnout
• public/private review gap
• external audit shock
• formal approval / practical non-review split
• recurring missed errors
• procedural legitimacy collapse

Scaling Requirements

To scale review safely, systems need:

• review triage
• consequence-weighted review depth
• reviewer resources
• reviewer authority
• evidence access
• review independence where needed
• appeal queue management
• exception review systems
• memory-binding review
• review quality sampling
• escalation triggers
• external audit triggers
• reviewer rotation or support
• review criteria consistency
• review outcome tracking
• post-review recurrence analysis

Scaling Rule

Review capacity must scale with decision volume, consequence severity, irreversibility, appeal load, exception rate, and memory durability.

Sanity constraint:

review_load > review_capacity ⇒ review_debt ↑

If review demand exceeds capacity, review debt accumulates.

Second constraint:

high_consequence + low_review_capacity ⇒ downstream_error_risk ↑

If consequence is high and review is weak, downstream error risk rises.

Third constraint:

memory_binding_rate > review_capacity ⇒ U7 contamination risk ↑

If memory binds faster than review can inspect, false memory risk rises.

14) Interaction / Coupling Behavior

review_capacity reveals whether coupled systems can inspect and correct each other’s effects before harm hardens.

What It Reveals About Coupling

• whether shared decisions are meaningfully reviewed
• whether one node’s claims can be evaluated by another
• whether review burden is shared or one-sided
• whether high-risk coupling decisions are inspected
• whether appeals can be processed
• whether boundary decisions are revisitable
• whether shared memory is reviewed before binding
• whether coupling creates more review load than capacity

What It Reveals About Boundary Integrity

Boundary decisions often require review.

When review_capacity is low:

• boundary crossings may be approved too quickly
• refusal may be misclassified
• consent ambiguity may go unresolved
• BΣ repair may be declared too early
• boundary memory may bind without review
• affected nodes may seek external recourse

What It Reveals About Compatibility

Compatibility requires review capacity proportional to coupling depth.

A coupling may be unsafe if:

the coupling generates more high-consequence decisions than either node can review

or:

one node’s classifications bind the other before review can occur

Healthy compatibility includes review pathways that can slow, revise, and repair coupling decisions.

Relevant Interface Acts

• ↺ Reflection: review shared understanding before binding
• ⇩ Relaxation: lower urgency and review pressure
• ⊘ Attenuation: reduce coupling while review backlog is repaired
• ⊙ Alignment: inspect one’s own claims before externalizing them
• →? Invitation: invite review before deepening commitment
• ⚕︎ Restorative Override: requires post-action review capacity
• ✕ Force: high risk if review capacity is weak

15) Failure Modes Detected

Primary Failure Modes

review_capacity detects or predicts:

• review theater
• rubber-stamp approval
• review backlog
• appeal backlog
• exception drift
• high-risk binding error
• unreviewed memory binding
• shallow approval
• delayed correction
• external audit shock
• reviewer burnout
• review authority gap
• formal approval / practical non-review split
• false repair validation
• classification persistence
• governance bottleneck
• procedural legitimacy collapse

Composite Regimes Where review_capacity Matters

• Repair Theater: review approves repair without validation
• Goodhart Collapse: review optimizes approval metrics
• Crisis Loop: review backlog prevents learning
• Pseudo-Coherent Basin: formal review hides hidden debt
• Mission Lock: review is bypassed for trajectory
• Taboo Lock: protected topics cannot be reviewed
• LOS: actual review happens through latent pathways
• Coercive Fusion: one node cannot review the other’s claims
• Compression Collapse: review depth collapses under pressure

16) Accountability & Reintegration Implications

If review_capacity Was Ignored

Likely consequences:

• decisions passed without meaningful inspection
• high-risk classifications bound too early
• appeals were delayed or useless
• exceptions drifted
• repair-complete claims failed
• memory contamination persisted
• external audit overturned decisions
• reviewers became overburdened
• legitimacy declined
• formal approval was mistaken for coherence

Accountability questions:

• What needed review?
• Was review capacity sufficient?
• Did reviewers have evidence access?
• Did reviewers have authority?
• Was review timely?
• Was review depth proportional to consequence?
• Were affected-node signals included?
• Did review findings change outcomes?
• Did recurrence decline after review?
• Was approval mistaken for validation?

If review_capacity Was Misread

Possible misread forms:

• slow review mistaken for high quality
• fast review mistaken for efficiency
• high approval rate mistaken for good decisions
• low appeal volume mistaken for review trust
• checklist completion mistaken for evaluation
• reviewer authority assumed but absent
• review backlog mistaken for careful governance
• external audit treated as ordinary internal review
• formal process mistaken for real correction

Required Restoration

When review capacity failure is found:

identify review domain and load
→ triage by consequence and irreversibility
→ restore reviewer evidence access and authority
→ increase review resources
→ reopen high-risk decisions if needed
→ correct U7 review memory
→ validate recurrence reduction

If review capacity failure affected nodes asymmetrically, MS-Gate should review who received meaningful review, who received rubber-stamp review, and who carried cost.

17) Cross-Domain Examples

Technical / Engineering

Code review exists, but reviewers are overloaded and approve changes after skimming. Defects rise after “reviewed” releases.

Diagnostic implication: formal review exists, but review capacity is degraded.

Operator sequence: review load audit → high-risk review triage → staffing/time repair → post-release recurrence tracking.

Institutional / Governance

Complaint appeals exist, but the review office has a six-month backlog. By the time review happens, the consequence is already durable.

Diagnostic implication: appeal access is formal, but review capacity makes recourse ineffective.

Operator sequence: backlog triage → temporary relief pathway → review staffing → U7 correction process.

AI / Algorithmic

A safety review queue receives too many edge cases. Many are categorized by quick template rather than source-level analysis.

Diagnostic implication: review capacity is too low for high-risk classification.

Operator sequence: risk-tiered review → source inspection → eval update → memory correction.

Interaction / Relational

A recurring issue is “reviewed” during conflict, but neither person has enough calm attention or time to actually inspect the pattern.

Diagnostic implication: relational review capacity is lower than recurrence complexity.

Operator sequence: slow review window → shared memory reconstruction → bounded repair plan → recurrence check.

Archive / Framework Design

Spec sheets are produced faster than glossary, cross-link, and canon review can evaluate them.

Diagnostic implication: archive review capacity is lagging production throughput.

Operator sequence: pause expansion → review queue → glossary/cross-link audit → resume with review cadence.

18) Test Protocols

1. Review Load Test

How many items require review?

Failure signal: review load exceeds reviewer capacity.

2. Evidence Access Test

Can reviewers inspect source evidence?

Failure signal: review relies only on summaries.

3. Authority Test

Can reviewers change or block outcomes?

Failure signal: review is advisory or symbolic.

4. Timeliness Test

Does review occur before consequence hardens?

Failure signal: review arrives too late to matter.

5. Depth Matching Test

Does review depth match consequence severity?

Failure signal: high-risk and low-risk items receive same depth.

6. Backlog Test

Is the review queue growing?

Failure signal: queue age exceeds correction window.

7. Recurrence Test

Do reviewed issues recur?

Failure signal: review does not reduce recurrence.

8. Appeal Review Test

Can appeals be reviewed meaningfully?

Failure signal: appeal exists but review capacity is unavailable.

9. Memory Binding Review Test

Are durable records reviewed before binding?

Failure signal: U7 stores claims faster than review can inspect.

10. Reviewer Burden Test

Are reviewers overloaded or captured?

Failure signal: review quality falls under load, fatigue, or dependence.

19) Anti-Patterns

• Approval as review
• Checklist as judgment
• Process as capacity
• Speed as review quality
• Delay as depth
• Review backlog as harmless
• Rubber-stamp as consensus
• Summary as source
• Formal review as real correction
• Reviewer title as reviewer capacity
• Advisory review as authority
• Review after harm as recourse
• High approval rate as correctness
• Low appeal rate as trust
• Review metrics as review integrity
• External audit as ordinary review
• Review without affected-node signal
• Review without U7 correction
• Exception approval as exception review
• Repair-complete approval without recurrence validation

20) Spec Validation Check

• Is this truly a diagnostic, not an operator? Yes.
• Does it measure state, capacity, risk, or response rather than act directly? Yes.
• Does it map to S? Yes.
• Are U-layers specified? Yes.
• Are leading and lagging indicators separated? Yes.
• Are interpretation risks defined? Yes.
• Are operator sequencing implications clear? Yes.
• Are gate implications clear? Yes.
• Are scaling risks included? Yes.
• Are interaction implications included? Yes.
• Does it avoid new primitives? Yes.

Condensed Archive Summary

review_capacity is the diagnostic estimate of whether a system has enough usable ability to inspect, evaluate, compare, contest, verify, revise, and approve decisions, classifications, repairs, exceptions, appeals, memories, metrics, or actions before they become consequential. It does not measure whether review exists; it measures whether review has sufficient time, attention, evidence access, authority, depth, independence, and correction power relative to load and consequence. Low review_capacity indicates risk of review theater, rubber-stamp approval, appeal backlog, exception drift, high-risk binding error, unreviewed memory contamination, false repair validation, delayed correction, external audit shock, and procedural legitimacy collapse. Under low review capacity, the system should pause high-impact closure, triage by consequence and irreversibility, increase reviewer resources, restore evidence access and authority, keep outcomes provisional, reopen high-risk decisions if needed, and avoid durable memory binding, irreversible constraints, automation, or scaling decision volume until meaningful review capacity is restored.