Home› Groups› Evidence Informed Decision Making(EIDM)› Evidence Informed Decision Making(EIDM)› When Community Feedback Contradicts the Model: What Counts…

When Community Feedback Contradicts the Model: What Counts as Evidence to Retire or Revalidate?

Started by Charles Oct 21, 2026 3 replies 👁 4 views
Charles Member Community Champion (1,500+ points) Community Champion
Oct 21, 2026 at 10:23 pm

Colleagues,

Building from a rich discussion in our ABM CoP on model decay and retirement, I want to bring a question to this EIDM group.
We agreed that models can drift — calibration from 2020 does not fit 2026 reality after policy shifts, health campaigns, mobile money expansion etc.
But an important point emerged: drift is often felt by field teams and communities before it shows up in the dashboard.

In our programs, a field officer saying "this is not what we see anymore" is often the first signal. Yet in many evidence frameworks, that observation is logged as "anecdote," not evidence. It has no formal route into model governance.
Rhoda's challenge was sharp: if field teams are the early-warning system, they need a formal role — a standing agenda item, a named custodian — not an informal conversation.
So my question to this community:
1. When should lived experience and frontline observation count as legitimate evidence to trigger revalidation or retirement of a model/tool?

2. How have you formalized it? Do you have a governance mechanism where community sensing automatically opens an evidence review?

3. What is the minimum documentation needed so another local team can re-run and revalidate without the original modeller?
My working view: A retired model is not failure. Keeping an outdated model alive because we have no mechanism to hear the community is failure.
Would love to learn how others are handling this tension between formal evidence and lived experience.
Rhoda Nakhosi Admin Community Champion (1,500+ points) Community Champion
4 days ago

@Charles Bawate you've put your finger on the fault line that runs through most evidence systems: frontline observation is treated as anecdote precisely because it arrives informally, not because it's weak. My view is that lived experience should count as legitimate evidence from the moment it is systematically collected and traceable, which is a design choice, not a status the observation lacks. A field officer's "this is not what we see anymore" becomes evidence when it's logged with who observed it, where, when, and what specifically changed, and when it carries an obligation to be reviewed rather than filed. On formalising it, the minimum I'd argue for is three things: a named intake route (a standing agenda item with an owner), a defined threshold for triggering review (e.g., three independent field reports converging, or one report corroborated by routine data), and a documented decision, even if the decision is "no change," with reasons. That last part matters because it closes the loop and tells field teams their sensing was heard. On documentation for handover, I'd keep it minimal and usable: full code, parameter provenance with sources, calibration data, an assumptions log, and an explicit statement of where the model should not be used if another team can't rerun and revalidate without the original modeller, the documentation has failed. My one pushback on your framing: "a retired model is not failure" is right, but I'd add that a revalidated model isn't automatically success either sometimes the honest outcome is that the model was answering the wrong question for the new context, and no amount of revalidation fixes that.

Nonvicks Ochieng Member Community Champion (1,500+ points) Community Champion
22 hours ago

@Charles Frontline observations must be treated as formal sentinel data, not mere anecdote. Lived experience legitimately triggers revalidation when field teams see recurring patterns across districts, when workers must rely on operational workarounds, or when structural conditions like cash-transfer policies or connectivity shift, invalidating baseline assumptions long before statistical drift registers on lagging dashboards.

To institutionalize this, embed a mandatory variance question into routine field reporting tools (e.g., "Did the model's output reflect field reality?"). Crossing an alert threshold automatically triggers an "amber review" on the governance agenda, mandating an operational pause and widening confidence intervals while teams investigate. Appointing a designated Field Custodian ensures qualitative ground truth bypasses data backlogs and reaches decision-makers as formal evidence briefs.

For local teams to revalidate models independently, minimum documentation requires a plain-language model card outlining failure boundaries, containerized code environments, and a parameter dictionary translating abstract formulas into real-world variables. Local teams must know the behavioral assumptions behind the math to test whether the model still holds. Retiring an obsolete tool is adaptive management; relying on a blind algorithm because we fail to hear frontline reality is the true institutional failure.

Charles Member Community Champion (1,500+ points) Community Champion
14 hours ago

Thank you Rhoda and Nonvicks for this rich pushback — you both moved my thinking forward.

Rhoda, thank you for naming the fault line so clearly. I agree: frontline observation becomes evidence the moment we design it to be traceable — who, where, when, what changed — not because the observation itself was weak. Your three minimums are now in my notebook:
 1) named intake route with owner, 
2) defined threshold to trigger review, 
3) documented decision even if "no change" to close the loop.
That closing the loop part is crucial — it tells field teams they were heard. And I take your pushback on my framing. You are right: a revalidated model is not automatically success. If it was answering the wrong question for the new context, revalidation is just polishing the wrong tool. Retirement may still be the honest outcome.
Nonvicks, thank you for the term "sentinel data" — I will borrow it. Framing lived experience as formal sentinel data, not anecdote, is exactly the shift we need. I also value your practical mechanism: a mandatory variance question inside routine reporting tools — "Did the model's output reflect field reality?" — that automatically triggers an amber review, operational pause, and widening of confidence intervals. That is governance, not conversation. And appointing a Field Custodian as a formal evidence brief route solves what I called "no formal route." Your point on model cards in plain language — failure boundaries, parameter dictionary translating math into behavior — is the minimum documentation I was searching for
Where I land now after your contributions:
1. Lived experience counts as evidence from design, not after. If we log it systematically, it is sentinel data.
2. Governance needs automation. An intake route + threshold + amber review ensures community sensing automatically opens evidence review, without waiting for dashboard lag.
3. Documentation fails if another local team cannot re-run without the original modeller. Code, calibration, assumptions log, and explicit "where not to use" — in plain language.
Thank you both. My original line stands but sharpened by you: A retired model is not failure. A revalidated model answering the wrong question is not success. Failure is keeping a blind algorithm alive because we have no mechanism to hear the community.
Grateful for this CoP.
Charles
#EIDM #DataGovernance #PurposeRwanda