docs: add source links and citations

- Link Google Testing Blog for flake rate guidance
- Link ACM research on developer productivity
- Link Gloria Mark's research paper on focus interruptions
- Soften unsourced statistical claims
- Cross-reference companies page for queue metrics

Co-Authored-By: Claude Opus 4.5 <[email protected]>
Change-Id: I61e7f7d8a938fadfe7f926346efd2aca41434345
Claude-Session-Id: 43e5bb59-bfd1-4f17-982a-657235752c0d

Author: jd

src/content/docs/decision/failure-scenarios.md

@@ -205,7 +205,7 @@ Every time a developer is blocked, they have to:
 2. Investigate or wait
 3. Resume their original work (losing context)
 
-Research by Gloria Mark at UC Irvine shows it takes **23 minutes** to regain focus after an interruption. A broken main interrupts everyone.
+[Research by Gloria Mark at UC Irvine](https://www.ics.uci.edu/~gmark/chi08-mark.pdf) shows it takes **23 minutes** to regain focus after an interruption. A broken main interrupts everyone.
 
 ### Compound Delays
 

src/content/docs/decision/prerequisites.md

@@ -39,7 +39,7 @@ flowchart TD
 
 ### Target: <2% flake rate
 
-Before adopting a merge queue, your test suite should have a flake rate under 2%. That means fewer than 1 in 50 runs fails randomly.
+Before adopting a merge queue, your test suite should have a flake rate under 2%. That means fewer than 1 in 50 runs fails randomly. [Google's testing guidelines](https://testing.googleblog.com/2016/05/flaky-tests-at-google-and-how-we.html) discuss how they tackled this at scale.
 
 ### How to measure
 
@@ -96,7 +96,7 @@ CI speed matters because of the **feedback loop**. When a PR fails in the queue,
 
 ### Ideal: <20 minutes
 
-Under 20 minutes keeps the feedback loop tight. Developers can fix issues and re-queue within the same focus session.
+Under 20 minutes keeps the feedback loop tight. Developers can fix issues and re-queue within the same focus session. [Research on developer productivity](https://queue.acm.org/detail.cfm?id=3595878) shows that fast feedback cycles significantly improve developer experience.
 
 But not everyone can achieve this—and that's okay. If your CI is slower, merge queue features can help:
 

src/content/docs/use-cases/high-velocity-teams.md

@@ -72,7 +72,7 @@ Not all PRs are equal. [Priority management](/features/priority-management/) let
 
 ## Measuring Queue Health
 
-Track these metrics to know if your queue is keeping up:
+Track these metrics to know if your queue is keeping up. These thresholds are based on patterns observed at [high-performing teams like GitHub, Shopify, and Uber](/introduction/companies-using-merge-queues/)—adjust for your context:
 
 | Metric | Healthy | Warning | Critical |
 |--------|---------|---------|----------|

src/content/docs/use-cases/long-ci-pipelines.md

@@ -33,7 +33,7 @@ flowchart LR
     Full --> Merge["Merge"]
 ```
 
-- **PR CI**: Lint, unit tests, build — catches 90% of issues in 5 minutes
+- **PR CI**: Lint, unit tests, build — catches most issues quickly (typically 80-90%)
 - **Queue CI**: Integration tests, E2E, full validation — runs only for approved PRs
 
 Engineers get fast feedback. The queue runs thorough checks. Both needs met.