How Mosquito Surveillance Data Becomes an Operational Plan

Surveillance data does not have inherent meaning. It has meaning relative to a decision. Before touching a spreadsheet, state what the program is trying to decide: where to focus inspection effort next month, whether a habitat management change had any observable effect, which sites are being under-serviced, or what to tell a board about coverage.

Programs that skip this step tend to produce summaries that are interesting and unusable. A chart of seasonal totals is informative but does not tell a crew lead where to go on Tuesday. Naming the decision first determines which comparisons matter and, just as importantly, which ones can be ignored.

The next step is unglamorous and frequently the whole project. Comparability requires that a given field means the same thing across inspectors, sites, and seasons. In many programs it does not. One inspector records "standing water present" as a yes-no; another writes a description. Trap servicing intervals drift. A site is renamed and appears twice in the history.

Work through a sample of records from different crews and different periods and check whether you can honestly place them on the same axis. Where you cannot, you have two options: normalize retroactively where a defensible mapping exists, or accept a shorter comparable window and fix collection going forward. Both are legitimate. Pretending the records are comparable when they are not is what produces confidently wrong conclusions.

A trap count is not a measurement of population. It is a measurement of what that trap, in that placement, under those conditions, captured during that interval. Weather during the collection period, vegetation growth, nearby water level changes, equipment condition, and even the time of servicing all affect it.

This is why condition fields belong on the collection form rather than reconstructed later from memory or a regional weather source. When context travels with the count, a low number can be read as "low activity" or "collection compromised" instead of being averaged into a trend that hides both.

Cross-site comparison is tempting and often misleading, because habitat, placement, and access differ in ways no adjustment fully accounts for. A site’s own history is a much stronger reference. Is this location producing results that differ from what it produced in the same period in previous seasons, under similar conditions?

Once within-site comparison is established, cross-site comparison becomes more useful, because you are comparing deviations rather than raw magnitudes. Two sites with very different baseline counts can both be flagged for review if both are behaving unusually relative to themselves.

Written observations carry the most operational detail and are the least reviewed part of most programs. An inspector noting that a culvert has been blocked since April, that access to a site now requires a gate key nobody has, or that vegetation has overgrown a trap location explains more than a column of numbers.

If notes are too voluminous to read, that is a processing problem, not a reason to ignore them. Summarizing long-form notes by site and period, while retaining the ability to open the original entry, turns the most neglected records into the most useful ones. This is one of the clearer places where AI-assisted summarization earns its place, provided every summary remains traceable to the entry it came from.

The output of analysis should be short. A list of locations warranting review, each with the specific observation that put it there, is actionable. A ranked table of every site in the program is not, because nobody works through a fifty-row list under seasonal pressure.

Attach the reason to each item. "Site 14 — counts elevated relative to same period in prior two seasons; note from 06 May records new standing water east of access road" is something a crew lead can act on or dismiss with judgment. "Site 14 — priority score 0.81" is not.

Someone with relevant expertise has to look at the list and decide. That review should be a defined step with a named owner, not an assumption. Reviewers need access to the underlying records, the ability to reject items, and a place to record why.

Recording rejections matters more than it sounds. When a reviewer removes a site because they know a construction project explains the change, that knowledge enters the program record instead of staying in one person’s head. Over several cycles this is how a program accumulates institutional memory rather than losing it with each staffing change.

The final step is the one most often skipped: record the action taken, or the decision not to act, alongside the information that informed it. Without this, next season’s review starts from the same position as this one, and the program cannot evaluate whether its prioritization was any good.

This is what turns a set of records into an operational plan that improves. The plan is not just the list of what to do next. It is the documented chain from observation to decision to outcome, which is the only thing that makes the following cycle better than the last.