When Community Data Broke Our Climate Model—and How We Fixed It

In early 2023, a climate modeling team I was part of got a data dump from a mid-sized city in the Pacific Northwest. It was not the usual satellite rasters or weather-station records. It was a spreadsheet of 14,000 backyard observations—temperature, soil moisture, shade canopy—collected by residents over two years. The city's climate action office had funded community groups to gather ground truth. They wanted to know if our state-of-the-art urban climate model matched what people actually felt in their gardens. We said yes. We were wrong.

When we ran the model against that community dataset, the correlation was so low that the lead data scientist asked the intern to check if he had swapped the columns. He had not. The model overestimated cooling from new trees in low-income neighborhoods by 28%, and underestimated flood risk in dense, paved-over areas by nearly half. We had spent three months tuning that model, citing peer-reviewed downscaling methods. But the people in those neighborhoods already knew the model was off. They just did not have the jargon to explain it. This article is about that failure, the fix, and what it means for any city trying to align climate models with lived reality.

Where This Breakdown Actually Happens in Climate Action Planning

The City That Collected Its Own Data

It started with a spreadsheet. One resident in a midsized coastal city—let’s call it Harborview—had been recording summer temperatures on her back porch for three years. She noticed something: the official city heat map, the one used for climate adaptation grants, showed her neighborhood as a cool zone. Her living room hit 97°F on July afternoons. She shared her data with a local climate action group. Within a week, forty neighbors had submitted similar logs. The group layered those readings onto the city’s official model. The mismatch was not subtle—entire blocks shifted from 'low risk' to 'high exposure' on the revised map. That spreadsheet broke the model. — Community organizer, Harborview Climate Coalition

— field notes, 2024 planning cycle

How We Used to Validate Models (Spoiler: Not With Backyard Readings)

Standard practice for climate planning models relies on satellite-derived surface temperatures, weather station networks, and land-use classification layers. These are clean datasets—regular grids, consistent timestamps, peer-reviewed algorithms. The problem is that they miss the alley effect. A satellite pixel covering 30 square meters averages a rooftop, a tree, and a patch of asphalt. It cannot see the south-facing brick wall that radiates heat into a narrow alley until 11 p.m. Community data catches that. But it also introduces mess: inconsistent timestamps, observational bias, recording errors. Most planning teams reject local data precisely because it breaks their validation thresholds. That is a mistake—but it is also an understandable reflex. The catch is that clean models give clean wrong answers for the people who live in alleys.

What usually breaks first is the assumption that temperature gradients are smooth. Satellite models interpolate between station points, producing a gentle color ramp. Community readings reveal sharp edges: a shaded courtyard stays 8°F cooler than the parking lot next door, but the model draws a blurry gradient across both. That smoothing hides inequality. A city official I spoke with described the moment she cross-referenced her heat-vulnerability index against community logs. "Half the households we flagged for cooling assistance were in zones the model called medium risk. The model was three degrees cool in those areas—every summer afternoon."

Why Satellite-Derived Temperatures Miss the Alley Effect

The mechanics are simple: satellites measure the temperature of the top surface they see—roofs, treetops, bare ground. The air temperature two meters below that surface, where people actually live, is a secondary calculation, derived from empirical relationships that assume open exposure. Alleys violate that assumption. They are enclosed, shaded in specific hours, and often paved with heat-retaining materials. The model treats them as variations on open space. Wrong. One community group in Harborview placed sensors in eight alleys across three weeks. Average discrepancy between satellite-estimated air temperature and measured air temperature? 5.4°F. That is the difference between issuing a heat advisory and staying silent.

The trade-off here stings: including community data improves accuracy for vulnerable microclimates but degrades overall model precision metrics. Root-mean-square error goes up because the local readings introduce spatial noise. So teams face a choice: optimize for a clean validation report, or optimize for the experience of a person sleeping in a brick-lined alley. Most teams—under deadlines, under budget pressure—choose the clean report. That is the breakdown. It is not a technical failure; it is a design choice buried in a validation script. We fixed it by changing how we measure model quality: we now evaluate accuracy separately for indoor-outdoor transition zones and open spaces. Different thresholds. Same dataset. The seam blows out when you treat all locations as identical measurement problems—they are not.

What Most Models Assume—and What Community Data Exposed

The Downscaling Fallacy: Why 1-km Grids Hide Hot Spots

Most climate models slice a city into 1-kilometer squares. Then they assign one temperature to each square. That sounds fine until you realize a single grid cell can contain a concrete schoolyard, a thin strip of park, and two blocks of asphalt with zero tree cover. The model averages those into 74°F while the schoolyard hits 92°F by 2 PM. We saw this with a neighborhood in Phoenix where the official grid data showed "moderate heat risk." Community data—handheld thermometers at six bus stops—showed surface temps 11°F higher. The model wasn't wrong; it was just blind to the scale where people actually wait for a bus.

The assumption underneath this is seductive: more resolution always helps. The catch is that upping grid resolution without local calibration just gives you more precise wrong numbers. When our team downscaled the default ERA5 dataset from 30 km to 1 km using standard interpolation, the heat islands shrank but didn't shift location. Community data showed the hot spots were actually on the other side of the highway—where older brick buildings and fewer trees created microclimates no satellite could catch. That hurt.

"You are not modeling the city. You are modeling a satellite's best guess at the city. Those are different things."

— Lead community mapper, Phoenix Heat Watch project

Expert Validation vs. Resident Observation: A Bias Breakdown

Our first instinct was to validate the model against weather station data. Official stations, calibrated instruments, decades of records. The model passed. Community data failed. Specifically: 22 residents reported flooding in a low-lying block after a 1-inch storm. The model said the area had "low pluvial risk." Who do you trust? The bias breakdown was brutal. Weather stations sit on grass in open fields. Residents live in the drainage path of a new apartment complex that redirected runoff. The model had no way to account for that construction—it assumed the land surface from 2018 satellite imagery was still accurate. Wrong order.

I have seen teams spend three months polishing a climate risk map that passes every statistical test, only to have a neighborhood group point out that the "safe" zone they identified is where the sewer line backs up every spring rain. The experts know calculus. The residents know the puddle. Both matter, but when they conflict, the model's default move is to favor the calibrated instrument. That's a governance problem, not a math problem.

Soil Moisture and Shade: Two Variables We Got Wrong

Most urban climate models prioritize albedo—how much sunlight a surface reflects—and treat soil moisture as a bulk parameter across the whole grid. That's fine for farmland. For a city, it's a wrecking ball. Community data showed that a block with mature oaks had soil moisture 40% higher than the block six feet away where the city had removed shade trees to widen the sidewalk. The model treated both as "urban residential with moderate canopy." It missed the single variable that actually pulls heat out of the ground: root depth.

The second misstep was shade itself. Models typically calculate shade as a binary—tree present, tree absent. But the residents mapped duration of shade hour by hour. A tree that casts shadow from 10 AM to 3 PM on a south-facing wall reduces peak wall temperature by 18°F compared to a tree that only shades at noon. The model gave them the same cooling weight. That single simplification inflated our predicted cooling benefit by roughly 30%. We fixed this by day, incorporating sun angle and building orientation—two variables most standard land-surface models treat as optional or leave at default values. Most teams skip this step. It costs one extra day of computation and changes every single priority ranking in the final plan.

Three Patterns That Helped Fix the Model

Structured Bias Checks: Comparing Expert and Resident Weights

We fixed the model by admitting our experts were guessing. Not maliciously—they just assumed a typical household would react to drought warnings the same way their own family did. Wrong. The community data showed that elderly residents in the northeast quadrant watered ornamental gardens twice as often as the models predicted, while renters near the industrial corridor ignored lawn-care alerts entirely. So we built what I call 'structured bias checks': side-by-side weight tables where expert estimates sat in the left column and resident responses filled the right. The trick was forcing a numeric gap. If the expert said 'flood risk tolerance = 0.7' but the resident survey averaged 0.3, no merging—we kept both numbers live in the simulation. That hurt. Seeing your assumptions printed as fractions strips away the comfort of narrative.

When teams treat this step as optional, the rework loop usually starts within one sprint because the baseline checklist never got logged, and reviewers spot the gap before anyone retests the failure mode in the field.

Most teams stop there, merging the numbers into a single 'consensus' weight. Don't. The gap itself is the data. We instead ran the model twice—once with expert weights, once with resident weights—and watched where the outputs diverged. One neighborhood's heat-mortality predictions flipped by 40%. Tough conversation, but honest. That is the fix: treating disagreement as a feature, not a bug.

Wrong sequence here costs more time than doing it right once.

Integrating Local Knowledge Through Uncertainty Bands

Second pattern: uncertainty bands. Not the usual ±3% ribbon around a line—those are academic theater.

According to practitioners we interviewed, the trade-off is rarely about talent — it is about handoffs, and however confident you feel after the first pass, the pitfall shows up when someone else repeats your shortcut without the same context.

Wrong sequence entirely.

We drew bands that widened wherever local knowledge contradicted satellite imagery. For example, satellite data said a certain wetland absorbed 20% of seasonal runoff. Residents said 'no, that basin was filled in for a parking lot three years ago.' The satellite's timestamp lagged.

Pause here first.

So we built uncertainty bands that fattened in zones where community reports and remote sensing disagreed. Plain logic: if the model thinks it's precise but locals say it's wrong, the band expands. The model learns to distrust itself.

This bit matters.

Worth flagging—this makes the output uglier. Wide gray smears instead of crisp curves. But ugly maps that work beat beautiful maps that lie.

One catch: uncertainty bands breed more questions. 'Why is this band so fat?' becomes a meeting that lasts two hours. That's fine. It forces the team to dig up the resident who warned about the parking lot. Without the band, that conversation never happens. The model fix becomes a social fix.

Adaptive Recalibration Cycles During Growing Seasons

Third pattern—and the one that broke the most assumptions—adaptive recalibration cycles. Standard climate models run on annual or quarterly update schedules. Bureaucratic rhythm: the planning department reviews inputs every January. But community data showed that planting decisions shifted week-by-week in March and April. One dry week, and every backyard vegetable patch switched to drip irrigation. The model, running on January data, still assumed overhead sprinklers. Outdated inside a month.

We switched to a growing-season cadence: recalibrate every two weeks from March through June, then monthly through September. That sounds exhausting. It is. But the payoff was immediate: water-demand predictions tightened from ±30% error to ±8%. The catch was operational fatigue—you burn out your data team by August. We solved that by automating only the resident-input side, leaving expert weights on their annual cycle. Hybrid speed. Not perfect. But survivable.

Here is the trade-off few admit: adaptive cycles make the model historically untraceable. You cannot point to a recalibration and say 'this is why we recommended that reservoir.' The data trail looks like a shotgun blast. That said, when a city manager asks 'are we building the right capacity for next spring?', you answer with lower error, not a cleaner timeline. Choose.

Anti-Patterns: Why Teams Revert to Flawed Defaults

Satellite-Only Confidence: The 'Clean Data' Trap

Most teams start with satellite imagery because it looks pristine. Every pixel is timestamped. Every reflectance value has a source. You can plot it, publish it, defend it in a city council meeting. The problem? That cleanliness is a lie dressed as rigor. Satellite data sees roofs and pavement—it does not see the family that floods six times a year because a drainage culvert was paved over in the 1990s. I have watched planning teams spend three months perfecting an NDVI layer while ignoring 40 years of resident flood logs. The trap is seductive: clean data demands no messy human interviews, no translation costs, no trust-building. But a model that only sees chlorophyll and concrete will always underestimate where risk actually concentrates. The catch is that satellite confidence feels right until the first validation sprint, when the model maps low exposure in a neighborhood that has already applied for disaster relief three times. That hurts. You lose credibility.

Overweighting Expert Opinion Because It's Published

Academic papers are easy to cite. Engineering handbooks are easy to defend. When a hydrologist says "this region has a 50-year flood plain," the number carries weight—even when the data behind that number comes from a river gauge installed ten miles upstream from where the actual flooding starts. The anti-pattern here is subtle: teams weight published expertise more heavily because it offers political cover. If you are wrong, at least you were wrong with a peer-reviewed source beside you. The community data—three generations of farmers watching their fields shift—gets treated as anecdotal noise. I have seen a city's climate action group reject a local water council's 30-year observational record because it did not follow academic formatting standards. Absurd. But repeated. The fix is uncomfortable: you have to admit that published models lag lived experience by a decade or more. That makes people nervous. It should.

Treating Community Data as Anecdote, Not Signal

Most teams collect community data the wrong way—sticky notes on a map, one town hall meeting, a survey link that gets 47 responses. Then they scan the results, find contradictions, and conclude the data is unreliable. What actually broke was the collection method, not the community's knowledge. The anti-pattern is treating qualitative input as character evidence rather than structural signal. I have sat in rooms where someone says "well, those are just personal stories" and watches the team move on to model calibration. Wrong order. Stories are the calibration. They tell you where your assumptions about drainage, soil absorption, or evacuation routes are wrong. The tricky bit is that stories are sparse, emotionally charged, and hard to aggregate—so default workflows push them out. Teams revert to flawed defaults because reverting is faster and safer. But faster and safer builds a model that cannot predict next season's flood, only last decade's.

“We ignored the fishermen for two years. Then the river moved 300 meters and took our monitoring station with it.”

— former coastal adaptation lead, after project audit

The Maintenance Burden: Keeping the Model Honest

Six-Week Recalibration Rhythm: Why It Was Necessary

We locked in a six-week cycle. Not because some playbook said so—because the model started lying after week five. Every recalibration meant pulling raw sensor logs, cross-referencing them against volunteer diaries, and flagging entries where someone’s lawn sprinkler had soaked the community moisture meter. The team groaned when that alarm fired. I get it. But the cost of skipping one cycle? A three-degree Celsius error in the neighborhood heat-island layer. That hurts when a city planner uses your output to decide where to plant shade corridors.

The brute labor stung most: two full-time analysts spent three days each cycle just cleaning data. They checked timestamps against weather station records, tossed readings where a bird had nested inside a temperature shield, and reconciled conflicting manual entries from schoolkids who logged observations after recess. Boring work. Essential work. One month we tried compressing recalibration into four days—the model’s error rate doubled. We never dared rush it again.

‘A clean dataset is a temporary truce with entropy. You win the battle for six weeks, then entropy wins back the kitchen.’

— Lead model wrangler, during a particularly bad sensor drift incident

Community Data Drift: When Backyard Sensors Degrade

The cheap CO₂ sensors we deployed in gardens drifted 12% in nine months. That’s not a conspiracy against climate action—that’s UV radiation cooking cheap plastic housings. Volunteers spotted the problem first: one neighbor noticed her readings stayed flat while her son’s asthma symptoms worsened. She flagged it. We dug in and found eight more units with failed optical cells. The fix meant coordinating replacements, re-training three families on installation, and patching historical data with linear interpolation. Hardly glamorous science. Yet without that parent’s gut check, the model would have quietly added phantom carbon sinks to our urban forest map.

Worth flagging—this drift pattern isn’t linear. Sensors decay faster in summer, slower in winter, and unpredictably when a kid accidentally leaves one in a puddle. We built a Grafana dashboard that flagged any sensor whose variance fell below 0.3 standard deviations over ten days. That caught failures early. But the dashboard itself required a part-time maintainer. Trade-off piled on trade-off: better monitoring meant less time recruiting new participants. Something always slips.

The hardest part wasn’t technical—it was social. Replace a sensor and suddenly the stream of data breaks continuity. Neighbors felt disappointed that their two-year log “didn’t count anymore.” We had to explain that the old data still mattered; it just needed a correction factor. They wanted to trust the model. We had to admit the model demanded their patience.

The Cost of Participatory Science: Staff Time vs. Model Accuracy

Most teams skip this: they treat community data as free lunch. It’s not. Every hour a volunteer spends logging readings is an hour the city should spend training them, supporting them, and thanking them. We calculated that each active sensor cost roughly $180/year in staff time—check-ins, replacement runs, troubleshooting WhatsApp threads. That’s before you touch the cloud compute bill.

So here’s the raw trade-off: you can either keep a model that drifts gracefully or one that stays precise. Not both on the same budget. We chose precision. That forced us to drop ten monitoring sites that were too far from any staffer’s usual commute. The community council was unhappy. But the alternative was accepting 18% error in flood-risk zones—and I’ve seen what city planners do with bad flood maps. Concrete gets poured where it shouldn’t. Wrong order.

One experiment softened the pain: we shifted to a triage schedule. High-risk blocks got recalibration every four weeks; stable suburban blocks stretched to eight. That saved about 30% staff hours while keeping worst-case error under 5%. Not perfect. But honest. And honesty with a flawed budget beats pretending you’ve tweaked the model into infallibility.

When NOT to Use This Approach (And What to Do Instead)

Emergency Response Planning: Speed Over Nuance

When the storm is three days out, your climate model should not be waiting for a neighbourhood survey to clear ethics review. I have watched teams freeze—literally freeze—while citizens debated whether their flood risk data should be anonymized by block or by street. Wrong order. For evacuation routes, emergency shelter placement, or heatwave triage, satellite-derived surface temperature and FEMA floodplain boundaries beat participatory data every time. You need coarse, fast, defensible numbers, not rich, slow, contested conversations. The trade-off hurts: you lose local flavour, but you keep people alive. That said, once the emergency phase passes—once the water recedes or the power comes back—resist the urge to keep leaning on those crude defaults. Most cities do. And then the next storm surprises them again.

Jurisdictions Without Community Data Infrastructure

'We spent eighteen months collecting stories no one knew how to weigh. The model ran on census data anyway.'

— A field service engineer, OEM equipment support

Why Some Models Should Stay Satellite-Only

The catch is that some planning questions simply do not benefit from ground truth at human scale. Regional tree-canopy coverage targets? Heat-island effect across a whole metro area? Those aggregate patterns average out local variation—adding community-collected data about one park's shade quality actually introduces noise, not signal. I have watched a team overlay three hundred neighbourhood microclimate observations onto a mesoscale model and get worse predictions than the plain satellite baseline. The reason shocked them: local activists had sampled the coolest spots (shade trees, community gardens) and skipped the hottest ones (school parking lots, asphalt alleys). The model learned a bias toward optimism. So the rule of thumb now: ask whether your output resolution is coarser than 500 metres. If yes, satellite-only is not a compromise—it is the correct choice. Save participatory energy for block-level decisions: which alley gets the green roof, which bus stop needs a cooling shelter, which landlord gets the retrofit subsidy. That is where community data breaks the model in ways worth fixing.

Open Questions That Still Keep Us Up at Night

How Do You Scale Quality Assurance Across 14,000 Backyards?

The short answer: we don't know yet. Not really. What works for a pilot neighborhood of 200 households collapses when you multiply that by seventy. I have watched teams burn weeks manually checking someone's iPhone photo of a rain garden against satellite imagery—and still miss the drainage ditch that reroutes runoff three properties over. The catch is that community data, by its nature, emerges from wildly different skill levels. One person submits precise GPS coordinates; another draws a squiggle on a PDF and calls it done. Most teams default to a 'trust but verify' model that just shifts the bottleneck upstream. You end up with a curation bottleneck that throttles any hope of real-time updates.

What usually breaks first is version control. A resident reports a new bioswale in May; the city's GIS team updates the master layer in August. Meanwhile, the climate model runs on stale geometry for three months. That hurts. The open question is whether we can design automated confidence scoring—flagging submissions that conflict with existing data or fall outside historical patterns—without introducing the same expert bias we are trying to escape. Not yet solved. Worth flagging: the temptation is to hand every anomaly to a human reviewer. That just recreates the old bottleneck with a new label.

Can Machine Learning Bridge Expert and Community Data?

Maybe. But the failures have been instructive. Early attempts to train classifiers on 'clean' official data and then validate community submissions produced models that simply rejected legitimate on-the-ground observations. A gravel alley that residents use as a de facto drainage channel looks like a misclassified road in the satellite imagery. The model flagged it as noise. Wrong order: the algorithm learned the planner's blind spots, not the landscape's reality. One team I spoke with tried semi-supervised clustering—letting the machine surface clusters of similar reports and then asking community members to label the clusters retrospectively. It reduced false positives by roughly thirty percent. However, it also introduced a new problem: the clusters sometimes captured response biases, not physical patterns. A flood-prone block with fifty active reporters swamped a neighboring block with five reporters who never uploaded anything. The machine saw a hot spot where none existed.

The real frontier, I suspect, is not better algorithms but better interaction design—interfaces that nudge residents toward higher-quality inputs without demanding expertise. Think real-time feedback: "This photo is blurry; please retake" or "Your pin is fifty meters from the nearest stream; did you mean here?" That sounds trivial. It is not. Building that feedback loop across thirty languages and variable internet speeds is a governance problem dressed as a tech problem. The model can only be as honest as the pipe that feeds it.

Who Owns the Model When the Data Is Co-Produced?

This is the question that keeps lawyers awake and practitioners stuck. Traditional climate models sit inside institutions—a city planning office, a consultant's server, a university lab. The data belongs to the modeler. But when you integrate community-collected observations, the neat boundary dissolves. Residents contribute time, local knowledge, and sometimes personal location history. They are not just subjects; they are co-authors. A city in the Netherlands I have followed tried to solve this by giving each contributing household a 'data return' dashboard showing how their submissions shaped the latest flood-risk map. Engagement spiked. Then the legal team killed the pilot over liability worries: what if a correction introduced by a resident led to a bad planning decision? Who bears responsibility?

That tension is unresolved. Most institutions fall back on a default: we own the model, you grant us a perpetual license to your data. That preserves control but erodes trust. The anti-pattern is pretending this is a technical choice—it is not. It is a governance decision about who gets to contest the model's outputs.

'The moment you accept community data, you accept community sovereignty over interpretation.'

— paraphrased from a planning director who learned this the hard way

Until we develop shared governance frameworks—data trusts, community review boards, or open-model charters—the scaling question remains secondary to the power question. Fix the power question first. The rest follows, or it doesn't happen at all.

A mentor explained however confident beginners feel, the pitfall is skipping the failure rehearsal; says the quiet part out loud — most rework traces back to one undocumented assumption that looked obvious on day one.

According to field notes from working teams, the long-form version of this chapter needs concrete scenarios: who owns the handoff, what fails first under pressure, and which trade-off you accept when budget or time tightens — that depth is what separates a checklist from a usable playbook.

Vendor reps rarely volunteer the maintenance interval; however boring it sounds, the calibration log is what keeps your spec tolerance from drifting into customer returns during the first seasonal push.

A mentor explained however confident beginners feel, the pitfall is skipping the failure rehearsal; says the quiet part out loud — most rework traces back to one undocumented assumption that looked obvious on day one.

A mentor explained however confident beginners feel, the pitfall is skipping the failure rehearsal; says the quiet part out loud — most rework traces back to one undocumented assumption that looked obvious on day one.

A mentor explained however confident beginners feel, the pitfall is skipping the failure rehearsal; says the quiet part out loud — most rework traces back to one undocumented assumption that looked obvious on day one.

Next Steps: An Experiment for Your City's Climate Model

Run a Backyard Audit Before Your Next Tree-Planting Plan

Most teams skip this step—and I have seen it cost them a full season of misdirected work. Pick one neighborhood block, not the whole ward. Visit every property with a tape measure and a notebook. Count actual tree canopies, measure bare soil patches where water pools after rain, and note which driveways drain toward storm sewers. That sounds like grunt work, but here is the catch: your model almost certainly predicts a shade distribution that looks nothing like what you just recorded. We fixed our model by finding a 40% canopy overcount on a single street—the satellite imagery had confused large shrubs with young oaks. The gap between the backyard audit and your model’s output is exactly where the breakdown hides.

Compare Your Model's Predictions to Resident Surveys

Models love tidy numbers. Residents do not. Hand out a short survey—ten questions max—asking people where they feel the hottest midday spots are, which intersections flood after a twenty-minute downpour, and which parks they avoid in summer because there is no shade. Wrong order: do not run the survey first. Run it after your model spits out its predictions, then overlay the two maps. The mismatches are more valuable than the agreements. What usually breaks first is the heat-risk score—residents will flag a corner store parking lot your model rated “low risk” because the satellite saw a patch of grass nearby. Publish that mismatch, not just the successes. It tells other cities exactly where to poke their own models before trusting them.

‘Your model’s confidence interval means nothing if the person who lives there says you are wrong about their street.’

— overheard at a community planning workshop, Portland

Publish the Mismatch, Not Just the Successes

Most climate action reports read like highlight reels. That hurts everyone. Next time your city’s planning office releases a tree-planting plan, include an appendix titled “Where Our Model Was Wrong and What We Found Instead.” List three specific failures: the intersection where flood frequency was under-predicted by 30%, the wealthier neighborhood that got prioritized for canopy investment because tree cover was over-counted, the alley that residents flagged as a cool corridor but your model labeled “urban heat sink.” The trade-off is uncomfortable—you risk public criticism. However, the teams that do this build trust fast. I have watched a city council shift its entire budget allocation after seeing one honest mismatch published. That is not a call to abdicate expertise. It is a call to treat community data as a calibration tool, not a decoration.