
A clinic posts hours, yet patients show up to a locked door. A responsive clinic apologises, posts why it happened, updates hours, and texts people next time. The fix becomes part of the system.¶ 1 (permalink to paragraph 1)
Competent action creates new information. The person who was served, or failed, now knows something about the system that the system does not yet know about itself. Refusing to receive that knowledge is the fastest path to repeated failure.¶ 2 (permalink to paragraph 2)
In Caring Democracy, Joan Tronto defines responsiveness as “observing that response, and making judgments about it (for example, whether the care given was sufficient, successful, or complete?)” She adds a point that is easy to overlook: the person cared for need not be the one who responds; others in the care setting can assess. Those best placed to judge whether care worked are usually the people who live closest to its effects.¶ 3 (permalink to paragraph 3)
Aimee van Wynsberghe read the same element into design a decade ago: responsiveness is what “encourages an active stance of the care-receiver rather than a more passive, vulnerable one” (2013, p. 418). For Civic AI, the public question is simple: when a system harms someone, who can contest the result, how fast, and what changes because they spoke?¶ 4 (permalink to paragraph 4)
Start in your room
Imagine saying to an institution, “I said this was wrong. Who can change it, and when will they answer?” Make it easy to reach a person who can review the case, then follow it through until the repair is made.¶ 5 (permalink to paragraph 5)
Definition
- People closest to harm define harm. They hold the author’s pen for evaluations and have a real say in whether repair counted.¶ 6 (permalink to paragraph 6)
- A right to reply must change something. A reply that cannot trigger correction, rollback, or compensation is theatre. (The reply is what Albert Hirschman called voice; Pack 5’s portability is his exit, and each disciplines an institution only when the other is real.)¶ 7 (permalink to paragraph 7)
- Shared memory matters. Post-incident learnings become tests; tests prevent repeats.¶ 8 (permalink to paragraph 8)
- Time is part of the service. A fast wrong-then-right beats a slow maybe. Reversible defaults matter.¶ 9 (permalink to paragraph 9)
- Care labour is labour. Eval writing, appeals, moderation, and facilitation should be compensated and visible. Participatory-AI research has named the trap: participation is not a design fix unless the work is paid and the participants hold the pen (Birhane et al., 2022).¶ 10 (permalink to paragraph 10)
Why it matters
Pack 3 checks whether the process ran as promised. Pack 4 checks whether the care actually landed. So responsiveness begins with community judgement.¶ 11 (permalink to paragraph 11)
An aggregate satisfaction score, or any single number, cannot replace situated knowledge. Surveys can detect large shifts in sentiment, but they are structurally blind to what a night-shift nurse or a community member notices at the edge of the system. It takes both the numbers and people with authority to act on what they see.¶ 12 (permalink to paragraph 12)
Community-authored evaluations, appeals, and repair logs are the public commitment. Some teams later feed those signals into routing or model updates (sometimes called Reinforcement Learning from Community Feedback, RLCF), but that choice comes second. The community writes the yardstick first.¶ 13 (permalink to paragraph 13)
Responsiveness keeps the other three phases from becoming control. Care without the care-receiver’s own assessment projects the carer’s preferences onto a passive recipient. Institutional care has caused enormous harm this way: care that was actually control. The residential schools that separated Indigenous children from their families were, by many official accounts, expressions of care. The psychiatric institutions that confined people judged deviant often understood that confinement as therapeutic.¶ 14 (permalink to paragraph 14)
A system that is attentive, responsible, and competent, but has no mechanism for the people it serves to say “this is not working for me,” can drift, undetected, from care into domination. The person receiving care, or someone authorised to speak for them where they cannot, must be able to say that sentence, and the sentence must change the system.¶ 15 (permalink to paragraph 15)
The brake as a care mechanism
Feedback pipelines can change future training runs, but they cannot interrupt a wrong decision in the moment when interruption is what care requires. That takes a brake: the mechanism by which the care-receiver, or the care-giver on their behalf, can say “this time, the automated model is wrong; stop, let me override, or route this to a human now.”¶ 16 (permalink to paragraph 16)
For a nurse, that means overriding the system’s “no alert” verdict, stopping it from closing the case, and calling the doctor without justifying it to a software interface; for a resident, a two-minute action that triggers human review of their case; for a language community, a way to flag a pattern and force a policy review, not merely lodge individual complaints. A brake works when people can reach it without a maze and pulling it actually stops something.¶ 17 (permalink to paragraph 17)
An honest design cannot hide the tension: a brake that is easy to reach is also easy to lean on, and a ward where every alert is overridden has not solved alarm fatigue. It has automated it. The answer is a legible brake, not a harder one: log every pull in an attributable running record, the override ledger, and feed over-override patterns back into community-authored evaluations as a signal in their own right.¶ 18 (permalink to paragraph 18)
What it looks like in practice
- Community-authored evaluations. Affected communities co-write the tests for harm and successful repair.¶ 19 (permalink to paragraph 19)
- Shared eval registry. Use a public, Wikipedia-like registry for tests: anyone can draft, civil society partners review, and labs adopt or explain. Weval, built by the Collective Intelligence Project, is the working example; one of us (Audrey) is a senior research fellow there, so weigh the recommendation accordingly.¶ 20 (permalink to paragraph 20)
- Clear appeals. For discussion, we propose replies within 24 hours for urgent cases, 7 days for standard cases and 30 days for complex ones. The affected community and the accountable team must agree workable service windows and consequences for breach; these are proposed contract terms with no measured deployment behind them. The appeal is the oldest instrument on this page: Danielle Citron’s technological due process (2008) asked for notice, hearing, and reasons for automated public decisions, and the contestable-AI literature has since treated contestability as a design requirement.¶ 21 (permalink to paragraph 21)
- Visible repair. Give each incident a page: what happened, whom it affected, what changed, and which new test now guards against repeat harm.¶ 22 (permalink to paragraph 22)
- Correction backlog transparency. Keep a shared queue of open corrections with case age and owner; escalate when backlog depth or oldest-case age exceeds agreed thresholds so repairs keep pace.¶ 23 (permalink to paragraph 23)
From ideas to practice
- Expose the appeal button. Every decision should show a one-click route to challenge it, with the clock visible.¶ 24 (permalink to paragraph 24)
- Accept harm drafts. Let people describe harms in plain language; turn them into community-reviewed tests with partners.¶ 25 (permalink to paragraph 25)
- Triage by severity. Highest-severity cases trigger immediate pause or reversible defaults.¶ 26 (permalink to paragraph 26)
- Fix or explain. Publish the remedy or the reason with next steps, on the clock.¶ 27 (permalink to paragraph 27)
- Memorialise. Turn incidents into tests and link them from the contract changelog.¶ 28 (permalink to paragraph 28)
- Check back. Close the loop with the people who appealed and ask whether repair made the process more trustworthy. Our proposed trust-under-loss test is informed by Tom Tyler’s procedural-justice research. It is not a validated AI measure or a promise that people who lose will trust the system.¶ 29 (permalink to paragraph 29)
Buildable tools
- Appeal API with timers, statuses, and escalation.¶ 30 (permalink to paragraph 30)
- Community feedback pipeline that can feed approved evals into routing, training, or policy signals when appropriate.¶ 31 (permalink to paragraph 31)
- Eval editor that turns plain-language harms into test harnesses.¶ 32 (permalink to paragraph 32)
- Incident tracker for severity, owners, deadlines, and public notes.¶ 33 (permalink to paragraph 33)
- Repair log template for root cause, remedy, and test added. The tracker moves the work; the repair log makes the learning public.¶ 34 (permalink to paragraph 34)
- Correction backlog board that exposes unresolved repairs by age, queue depth, and owner, with reassignment/escalation prompts as cases age.¶ 35 (permalink to paragraph 35)
One case: the flood-bot
This is a fictional composite for illustration. It is not operating evidence.¶ 36 (permalink to paragraph 36)
- Appeals surge. A language community flags mistranslations in proof rules.¶ 37 (permalink to paragraph 37)
- Local eval. Community partners submit a translation-fidelity eval; the group is compensated from the project’s escrow fund, because community knowledge is labour, not free quality assurance. The bot fails the eval; pause triggers; reversible defaults apply.¶ 38 (permalink to paragraph 38)
- System change. Translation uncertainty now routes cases to bilingual human review, and auto-denial is dropped. The eval enters the registry as a permanent release gate: no future update to the bot’s documentation rules ships without passing it.¶ 39 (permalink to paragraph 39)
- Fix. Bilingual reviewers update rules; the new test guards future changes.¶ 40 (permalink to paragraph 40)
- Close the loop. Elena gets a text: “We fixed the error; your provisional payment is now a final decision; here is how to see what changed; and here is how to reach a caseworker directly.” This illustrates what the proposed trust-under-loss test asks; it reports no observed increase in trust.¶ 41 (permalink to paragraph 41)
What could go wrong
- Appeal maze. Too many steps. Fix: Single button; automatic escalation when a response deadline is missed; status visible to the appellant at every stage.¶ 42 (permalink to paragraph 42)
- Eval spam. Low-quality tests flood the system, and AI-generated evals can swamp repair channels at the scale already seen in public-comment dockets, drowning signal from the directly affected. Fix: Partner moderation; reputation for contributors; merge/duplicate tools; provenance and accountable standing (not public identity) on feedback channels; per-community rate limits; audit trails that distinguish one affected person from generated proxies. The goal is quality, not credentialing. Moderation must not privilege established organisations over community members with direct experience; priority for those directly affected is preserved.¶ 43 (permalink to paragraph 43)
- Blame storms. People, not processes, get blamed. Fix: Blameless incident reviews; focus on mechanism design.¶ 44 (permalink to paragraph 44)
- Weaponised appeals. Adversaries flood appeals or strategically trigger pauses to disrupt service; synthetic appellants can swamp the same repair channels at AI scale. Fix: Require accountable standing (not public identity) for pause triggers and appeal routes; rate-limit by community; audit trails that separate genuine standing from generated proxies; preserve priority access for those directly affected.¶ 45 (permalink to paragraph 45)
- Over-override. The brake gets pulled against correct alerts; alert fatigue is automated rather than solved. Fix: Keep the brake easy to pull but legible, as the brake section above sets out: log and attribute every pull.¶ 46 (permalink to paragraph 46)
- Backlog drift. A handful of urgent fixes can clear quickly while older, lower-priority corrections quietly stack up. Fix: enforce throughput commitments, explicit backlog caps, and public escalation when the oldest open correction or backlog depth exceeds agreed thresholds.¶ 47 (permalink to paragraph 47)
Interfaces
- From Responsibility (Pack 2): who acts is clear; remedies are wired.¶ 48 (permalink to paragraph 48)
- From Competence (Pack 3): observability and guardrails feed responsiveness; incident loops start here.¶ 49 (permalink to paragraph 49)
- To Attentiveness (Pack 1): new needs discovered through response reshape what we notice; the cycle restarts.¶ 50 (permalink to paragraph 50)
- To Solidarity (Pack 5): public repair culture builds cross-group trust.¶ 51 (permalink to paragraph 51)
- To Symbiosis (Pack 6): responsive systems earn the right to stay local.¶ 52 (permalink to paragraph 52)
A closing image: the workshop wall of retired broken parts
Imagine a workshop with a wall full of retired broken parts, each tagged with the story of how it broke, how to avoid future damage, and who fixed it. The wall is a wall of learning, not shame. It is public, and kept by the community that uses the workshop as well as the engineers who built the machines. The shop that hides its breaks will repeat them. The shop that builds the wall becomes, over time, the most reliable shop in the district, because it has made its failures the foundation of its competence.¶ 53 (permalink to paragraph 53)
Sources for this pack
- Tronto, Moral Boundaries (1993), pp. 105–108 and 134–136: care-receiving and responsiveness; van Wynsberghe, “Designing Robots for Care” (2013), p. 418: responsiveness as the care-receiver’s active stance.¶ 54 (permalink to paragraph 54)
- Hirschman, Exit, Voice, and Loyalty (1970): the appeal as voice.¶ 55 (permalink to paragraph 55)
- Citron, “Technological Due Process” (2008); Alfrink et al., “Contestable AI by Design” (2023); Lyons, Velloso, and Miller, “Conceptualising Contestability” (2021): the appeal as a design requirement.¶ 56 (permalink to paragraph 56)
- Sloane et al., “Participation Is Not a Design Fix for Machine Learning” (2022); Birhane et al., “Power to the People?” (2022): community-authored evaluation as paid, participatory work.¶ 57 (permalink to paragraph 57)
- Tyler, Why People Obey the Law (1990): procedural justice, the finding behind trust-under-loss.¶ 58 (permalink to paragraph 58)
- Bainbridge, “Ironies of Automation” (1983); Sendelbach and Funk, “Alarm Fatigue” (2013): why a brake needs a ledger.¶ 59 (permalink to paragraph 59)
- Douw et al., “Nurses’ Worry or Concern” (2015): nurses’ concern can precede a change in vital signs.¶ 60 (permalink to paragraph 60)
- The full trail is on the Sources page.¶ 61 (permalink to paragraph 61)
