diff --git a/src/outreach/campaign-queue.mjs b/src/outreach/campaign-queue.mjs
index 0597aa9..8673dd5 100644
--- a/src/outreach/campaign-queue.mjs
+++ b/src/outreach/campaign-queue.mjs
@@ -25,17 +25,20 @@ function equivalentSql(column) {
 }
 
 function candidateQuery(confirmed) {
-  // leadNumber/leadEquivalent are computed ONCE per row in the derived `candidates`
-  // subquery below (as lead_number/lead_equivalent columns) instead of being
-  // re-embedded as raw expression text at every usage site further down. The
-  // normalizedSql()/equivalentSql() expressions expand into a deeply nested chain
-  // of replace()/substr()/length() calls; textually re-embedding them at each of
-  // this query's several correlated-subquery sites (verification join, opt-out
-  // check, shared-number check, inbound-replies check) made SQLite recompute that
-  // whole chain independently at every site, for every row — measurably expensive
-  // once a 5th usage site (the shared-number check) was added, especially in the
-  // worst case where a candidate segment has zero pre-verified numbers and the
-  // scan can't terminate early (see task-3-report.md for the investigation).
+  // lead_number/lead_equivalent are named columns computed in the derived
+  // `candidates` subquery below, purely as a readability device so the rest of
+  // this query can refer to `candidates.lead_number`/`candidates.lead_equivalent`
+  // instead of repeating the normalizedSql()/equivalentSql() expression text at
+  // every usage site. This is NOT a per-row precomputation optimization: SQLite
+  // flattens the derived subquery and re-substitutes the expression text at each
+  // usage site regardless, so the compiled query plan (and replace()-opcode count)
+  // is identical to the earlier inline form. During Task 3's perf investigation,
+  // rare multi-second outliers were observed on the 1.3M-row perf test both before
+  // and after this restructuring; repeated runs (5 consecutive, on two different
+  // machines) landed comfortably under the 8s budget either way, and the root
+  // cause of the rare spikes was not conclusively isolated to this SQL's shape —
+  // it looked more consistent with host-level noise than a query-cost regression.
+  // See task-3-report.md for the full investigation and evidence.
   const leadNumberExpr = normalizedSql('raw.whatsapp');
   const leadEquivalentExpr = equivalentSql('raw.whatsapp');
   const leadNumber = 'candidates.lead_number';