Operations Manual

Download this template

Generated 2026-04-29 · Download all templates

  • Layer: 5 — Operations & Coordination
  • Status: Template — adapt for your community
  • RCOS reference: §7.1, §7.3, §7.4, §7.5, §7.6

Core Operational Processes

RCOS clauses: 7.3.4, 7.7.2, 7.6.3

Why document critical processes?

If a process only lives in one person’s head, the community depends on that person showing up — forever. Writing the critical processes down, with named owners, is what converts private knowledge into a community asset that survives handovers, absences, and exits.

How to fill this in

For every recurring critical process (onboarding, exit, proposal publication, contribution recording, meeting cadence, treasury management, platform access review), name an owner and a brief description.

Process Who Detail

Temporary and Ad-Hoc Responsibilities

RCOS clauses: 7.1.5, 7.1.4, 7.7.1

Why cap temporary responsibilities?

Ad-hoc tasks quietly calcify into permanent unpaid jobs — usually on whoever said yes once. A hard time-box and a forced review make the difference between “I covered for a week” and “apparently this is my role now.”

How to fill this in

State that any temporary responsibility must be time-bounded at assignment, documented, reviewed before expiry, and either formalised or terminated.

When a task or responsibility is assigned temporarily, it must be:

If a temporary responsibility has no owner after its end date, it lapses; it does not transfer implicitly.


Role and Domain Interfaces

RCOS clauses: 7.6.3, 7.3.4

Why map handoffs explicitly?

Most operational failures happen not inside a role but between roles — at the boundaries where work moves from one owner to the next. Naming the handoffs turns invisible dependencies into reviewable ones, and prevents “I thought you had it” failures.

How to fill this in

For each pair of roles that pass work to each other, name the handoff and the type of work transferred.

From To Handoff
<…>

Workload Boundaries

RCOS clauses: 7.4.1, 7.4.2, 7.4.3, 7.7.3

Why make workload limits explicit?

Unbounded coordination load is the default failure mode of volunteer communities — it quietly burns out the most committed members until they leave. Explicit, reviewable limits make capacity a shared concern rather than a private burden.

How to fill this in

Set bounds on meeting load, role load, response-time expectations, and the path for renegotiating responsibilities.

  • Meeting load:
  • Role load:
  • Response time expectations:
  • Renegotiation and relief:

Operational Continuity

RCOS clauses: 7.5.1, 7.5.2, 7.5.3

Why plan for continuity now?

A community that depends on one irreplaceable person is one illness, one conflict, or one exit away from collapse. Naming the single points of failure — honestly — and building handover into every role is what keeps the community surviving its founders.

How to fill this in

Name current single points of failure honestly. State the handover requirement for each role and the cadence of continuity review.

  • Current state:
  • Handover mechanisms:
  • Continuity review cadence:

Information Flow and Anti-Gatekeeping

RCOS clauses: 7.3.5, 7.7.4, 7.3.2

Why treat information access as a governance issue?

Whoever controls access to information controls the community, whether they mean to or not. Making access rules explicit — and disallowing sole points of access — is what prevents informal gatekeepers from accumulating the kind of power the governance system is supposed to check.

How to fill this in

State which records are open to all Full Members, the response window for information requests, and the rule against sole points of access for governance-relevant information.


Documentation Locations and Update Procedures

RCOS clauses: 7.3.1, 7.3.2, 7.3.3

Why name where every document lives?

If no one can say where the canonical version of something lives, there is no canonical version. Naming the location, owner, and review cadence for each document type is what makes the community’s memory auditable rather than folkloric.

How to fill this in

For each document type, name the canonical location, the owner, and the review cadence.

Document type Location Owner Review cadence

Ratification Record

  • Adopted:
  • Decision type: Strategic
  • Version:
  • Decision record:

RCOS Blueprint by EcoHubs

A modular operating system that defines how intentional communities organize — from governance and roles to resource sharing and conflict resolution — in support of resilience, fairness, and regeneration.

Connect

© 2026 EcoHubs Platform. All rights reserved.