On this comparison, the capacity-derived threshold is the winner. It keeps a single cutoff that can be explained to stakeholders, but it does not pretend that a fixed number can override the review budget. The fixed rule is easier to say; the no-threshold rule is easier to promise; the capacity-derived rule is the one that can actually be executed.
Costs and Numbers That Matter
Measure capacity first, in doc-hours per week. One doc-hour is one hour of reviewer time applied to rewriting and verifying a single support document. Capacity equals (number of reviewers) × (hours each can review) − (meeting and overhead hours). The subtraction matters: only hours left after recurring meetings, triage, and tooling overhead count as the hard resource limit in the arXiv 2602.22560 sense.
| Quantity | Unit | How to compute |
|---|---|---|
| Capacity | doc-hours/week | reviewers × review hours − overhead hours |
| Candidate volume | docs/week | support docs with at least one answer-engine citation in the trailing 7 days |
| Processable docs | docs/week | floor(capacity ÷ average rewrite-and-verify hours per doc) |
Measure demand in documents, not hours. Count every support document that received at least one answer-engine citation in the trailing 7 days; that count is the weekly candidate volume. Using a trailing 7-day window keeps the sprint aligned with current citation behavior instead of a stale backlog, and it gives one number to compare against capacity.
The capacity-derived threshold is floor(capacity in doc-hours ÷ average hours to rewrite and verify one document). The result is the maximum number of documents the team can process in the week, so compare it with the candidate count rather than with any citation count. If that number is below 3, the fixed "3 citations or skip" rule cannot be sustained at current staffing; add capacity or reduce the candidate set before the sprint starts.
Track cost in doc-hours first. No verified dollar figure for citation-review work appears in the sources behind this guide, so do not build a budget from an assumed price; obtain a current quote and recheck it before committing funds. The time equation above is the stable cost driver, while prices and availability are volatile and must be verified against a current source.
Before committing, apply the reader rule: compute weekly citation-review capacity in doc-hours, compare it with candidate pages, and if candidates exceed capacity, raise the citation threshold until the selected pages fit. Recompute whenever reviewer hours, overhead, or average rewrite-and-verify time changes; a capacity number that is a month old is not a capacity number.
What the Evidence Does NOT Establish
The capacity rule rests on a structural analogy, not a measured documentation result. arXiv 2602.22560 is a machine-learning fairness paper: its experiments run on high-stakes ML datasets, not documentation corpora, and its 80% capacity-dominance figure and 0.409–0.702 recall range describe risk-identification behavior under a restrictive capacity limit in those datasets. Treat those numbers as evidence that hard resource limits can override stated priorities in threshold selection — a structural analogue for support docs — not as measured outcomes for any documentation team. If you cite them in a sprint proposal, label them as analogues.
The source also does not test citation counts as a threshold variable. Its framework optimizes a single global decision threshold over a predictive score under a bounded intervention rate; citations are not the score, and no cutoff of three appears in the paper. "3 citations or skip" is our operational proxy — a convenient way to rank candidate pages — not a validated cutoff from arXiv 2602.22560. Before you defend the number three in a review, check whether you can state what it proxies for: citability by answer engines, ranked ordinally. If you cannot, you are defending a habit, not a threshold.
The rule also breaks in a specific, checkable edge case: when candidate volume is stable and below capacity for three or more consecutive sprints. Under a binding capacity constraint, the deployed threshold is pinned by capacity; when the constraint stops binding, the threshold has no capacity pressure to respond to, and raising it further only discards pages you had room to review. Run the check before each sprint: compute weekly citation-review capacity in doc-hours, count candidate pages, and compare. If candidates sit below capacity for three straight sprints, stop raising the bar and instead re-examine whether your citability scoring is ranking the right pages.
Two further limits are worth stating plainly. First, the paper's framework enforces one global threshold for legal-compliance reasons; that is a constraint of its setting, not proof that a single global cutoff is optimal for documentation, where page types and query intents differ. Second, the paper reports recall under a restrictive capacity limit, not precision, review cost, or downstream answer quality — so the evidence cannot tell you whether a higher citation bar improves the answers users receive.
Practical check: before committing a rewrite sprint, write down three things — your capacity in doc-hours, your candidate count, and the source of your citation cutoff. If the cutoff's source is "the paper," correct it to "our proxy." If candidates have been below capacity for three or more sprints, treat the capacity rule as inactive and revisit the ranking instead.
Capacity-Derived Threshold
Your citation threshold shouldn't start at a number someone picked out of the air — it should start with your calendar. Before you commit to any rewrite sprint, work out your weekly citation-review capacity in doc-hours, then divide. That quotient is your threshold.
The baseline worksheet: count reviewers, multiply by hours, subtract overhead. Two reviewers at six hours per week gives 12 doc-hours; reserve 3 of those for meetings, triage, and pipeline maintenance, and you have 9 doc-hours of true capacity. If an average rewrite-and-verify cycle takes 3 doc-hours per document, your capacity is 9 ÷ 3, which floors to 3 documents per week — hence the 3-citation bar. That's the arithmetic origin, and it's the only legitimate one.
But the threshold has to clear a reality check. In week one, run your candidate list: suppose answer engines are already citing 14 of your support docs as candidates. Fourteen is far more than 3 documents' worth of work, so raise the bar to 4 citations. Count again: if 9 docs pass, that's 9 × 3 = 27 doc-hours needed against 9 available — triple your capacity. Raise to 5: 6 docs pass, requiring 18 doc-hours against 9 — still double. Raise again until candidate count times 3 doc-hours fits inside 9. That iteration — score, count, multiply, compare — is the whole method.
This mirrors what Moirangthem Tiken Singh and coauthors show in the arXiv 2602.22560 threshold-optimization framework: under a hard resource limit, the deployed threshold is set by capacity in the overwhelming majority of tested configurations, so your constraint math — not your aspirations — picks the cutoff. The reader rule to operationalize: compute weekly capacity in doc-hours; if candidate pages exceed that capacity, raise the citation threshold until the passing set fits the hours you actually have.
Run the worksheet at every sprint kickoff, because capacity moves. A reviewer on leave, a tooling change that cuts rewrite time, a hiring push — each shifts the divisor, and a threshold set under last month's capacity either starves your pipeline or silently produces documents nobody verified. One line in your sprint notes — capacity, per-doc cost, resulting threshold — keeps the number honest and auditable.
Decision Rules: When to Apply 3-or-Skip
Before committing to any support-docs rewrite sprint, use the citation count as the only adjustable lever at the gate. First, compute your weekly citation-review capacity in doc-hours and divide by your avg hours per doc to get the maximum number of docs you can review. If (capacity doc-hours ÷ avg hours per doc) ≥ 3 and the number of candidate pages ≤ capacity, then apply '3 citations or skip' as-is. Do not expand review time to force the bar lower.
If (capacity doc-hours ÷ avg hours per doc) < 3, then do not deploy a 3-citation threshold. Either add review capacity, or set the threshold at the computed floor (the highest integer citation count your capacity can actually support for that sprint) and document the gap between that floor and 3. This is a strict capacity check, not a matter of preference.
If candidates exceed capacity for 2+ consecutive sprints, then raise the threshold by 1 citation per sprint until (docs passing × avg hours per doc) ≤ capacity. Count consecutive sprints explicitly, since the increase must be stepwise by 1 per sprint, not a single jump.
These four actions in order are the only rules this section introduces for the '3 citations or skip' gate: ratio against 3, candidate count against capacity, floor-setting when ratio < 3, and stepwise raises when overage persists for 2+ consecutive sprints. Run them at the sprint gate every time, and do not substitute any other reason to move the citation bar.
Frequently Asked Questions
What is the capacity-derived threshold the winner over?
It beats the fixed rule and the no-threshold rule because it keeps a single cutoff that can be explained to stakeholders without pretending a fixed number can override the review budget.
How do you compute capacity in doc-hours per week?
Capacity equals (number of reviewers) × (hours each can review) − (meeting and overhead hours).
Which hours count as the hard resource limit?
Only hours left after recurring meetings, triage, and tooling overhead count as the hard resource limit.
How do you measure demand for the weekly candidate volume?
Count every support document that received at least one answer-engine citation in the trailing 7 days.
Why use a trailing 7-day window instead of a stale backlog?
It keeps the sprint aligned with current citation behavior and gives one number to work with.
How do you compute processable docs per week?
Processable docs per week equals floor(capacity ÷ average rewrite-and-verify hours per doc).
Quick answers
| Which rule wins the comparison described in the article? | On this comparison, the capacity-derived threshold is the winner. |
| What is one doc-hour? | One doc-hour is one hour of reviewer time applied to rewriting and verifying a single support document. |
| How is capacity computed? | Capacity equals (number of reviewers) × (hours each can review) − (meeting and overhead hours). |
| How is demand measured? | Measure demand in documents, not hours. |
| What count is the weekly candidate volume? | Count every support document that received at least one answer-engine citation in the trailing 7 days; that count is the weekly candidate volume. |
Also worth reading: HubSpot Support Comparison: Answer Engine Optimization (AEO)—Pew 2025, Trial or Skip?: HubSpot Support Comparison: Answer Engine · Tracking AI Overviews in 2025: 4 Metrics to Decide What to Fix First: Tracking AI Overviews in 2025: · Customer support replies: Citations cut reopens 31% vs confidence scores: Customer support replies: Citations cut