Skip to content

Mutual Aid Roster

Coordination artifact — instantiates Shared-Benefit Contribution Governance

A living directory of who can help with what — standing offers, named backups, and the pathways to reach them — so aid is found by lookup instead of improvised in the moment.

A group can only draw on help it can find. Mutual Aid Roster is the shared artifact that turns scattered, tacit willingness into a lookup: each member's standing offers of help and resources, a named backup for every capability, and the pathway to reach the right person fast. Its defining move is that it is forward-looking and availability-based — it answers "who can I call for this, and how?" It does not tally who has given (that is a ledger), and it does not display who is pulling weight right now (that is a board). The roster's whole value is that when a need lands, no one has to scramble or guess; the answer is already written down and already has a fallback.

Example

A rural volunteer fire brigade keeps a mutual aid roster. Each member lists what they can cover — pump operation, ladder work, first-response medical — the hours they are reachable, a named backup for their role, and any resource they can bring: one member has a water tanker, another a chainsaw and a generator. A call comes in at 2 a.m. for a barn fire, but the brigade's only trained pump operator is away at a wedding. Instead of a frantic phone tree, the duty officer opens the roster, sees the backup listed against "pump," and reaches that person directly. The tanker owner is paged in the same lookup.

The outcome is not heroics but the absence of a scramble: a capability that lived in one person's head — and would have been a single point of failure at the worst hour — was already declared, already backed up, and already reachable. The roster made the group's latent aid addressable.

How it works

  • Standing offers, declared in advance. Members pre-commit what help and resources they can provide, so aid is a catalog to search, not a favor to negotiate under pressure.
  • A named backup per capability. Every critical role carries a second name, so no single absence breaks coverage.
  • Explicit reach pathways. Each offer says how it is activated — call this number, post here, page the coordinator — so a need connects to an offer without a middleman guessing.
  • Kept current. Offers and availability are re-confirmed on a cadence; the roster is a live directory, not a founding document.

Tuning parameters

  • Offer granularity — coarse ("can help with meals") versus specific ("can drive a wheelchair van on Tuesdays"). Finer entries match needs precisely but take more upkeep and go stale faster.
  • Backup depth — one fallback per role versus a chain of two or three. Deeper chains survive multiple absences but add coordination overhead and dilute ownership.
  • Openness — a self-serve directory anyone can search versus a gatekept list a coordinator routes. Open is faster but concentrates load on the popular names and raises privacy exposure.
  • Refresh cadence — how often offers and availability are re-confirmed. A roster that is not refreshed fails precisely when it is finally needed.
  • Activation mode — direct (the requester contacts the listed person) versus dispatched (a coordinator assigns). Direct is fast; dispatched spreads load and prevents a few names being over-asked.

When it helps, and when it misleads

Its strength is that it converts "who do I even ask?" into a lookup, and — by demanding a backup for every capability — it forces the group to notice the tasks only one person can do and cover them before they fail.

Its central failure mode is false assurance: a roster is only as trustworthy as its freshness, and a stale entry promises coverage that has quietly evaporated. It also tends to concentrate load — a few generous names get called for everything — unless routing deliberately spreads the asks. The classic misuse is treating the roster as proof that coverage exists when the listed people were never actually confirmed, only optimistically written down. The discipline that guards against this is periodic re-confirmation plus tracking real call-outs, so the single-point-of-failure that a roster is meant to expose — the capability with no genuine second — cannot hide behind an entry.[1]

How it implements the components

  • mutual_aid_pool — the roster is the visible catalog of the group's aid pool: the standing offers of help, resources, and backup capacity that members can draw on.
  • coordination_interface — it supplies the lookup-and-reach layer, the pathways that connect a specific need to the right offer without a scramble or a gatekeeper's memory.

It does not price or bank what people give (that is Time Bank or Service Credit System), does not display who is currently pulling weight (Contribution Board or Dashboard), and does not allocate a shared pot of money or supplies (Participatory Budget or Resource Pool).

Notes

A roster records intent to help, not confirmed delivery — a named offer can evaporate the moment it is called on. It is strongest paired with a mechanism that catches the gap between offer and follow-through, such as Reciprocity Check-In or a Contribution Board, so that a roster full of willing names does not lull the group into thinking the work is covered.

References

[1] The bus factor (or single-point-of-failure): the number of people who would have to be lost before a capability is gone. A roster's demand for a named backup on every role is a direct, low-tech way to raise it above one. ↩