Operations Manual

Download this template

Generated 2026-07-07 · 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
<Member onboarding> <role> <see Onboarding Protocol (Layer 1)>
<Member exit> <role> <see Exit & Separation Protocol (Layer 1)>
<Proposal publication> <role> <see Governance Protocol (Layer 2)>
<Contribution recording> <role> <see Internal Economy Protocol (Layer 3)>
<Recurring meeting> <facilitator> <agenda publication; notes; action tracking>
<Treasury management> <finance steward> <see Treasury Ruleset (Layer 3)>
<Platform access review> <infrastructure steward> <review cadence; access revocation for exited members>

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:

  • <Explicitly time-bounded from the outset (specific end date or completion condition).>
  • <Documented as temporary at the time of assignment.>
  • <Reviewed before the end date; converted to a formal role or terminated.>

<Maximum duration of any temporary responsibility before it must be formally assigned or terminated — e.g. 90 days.> 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
<role> <role> <what is handed off>
<role> <role> <…>

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: <recurring meeting cadence and maximum duration; rules for extraordinary meetings.>
  • Role load: <cap if any; rule for flagging overload; resolution window.>
  • Response time expectations: <non-urgent async; urgent operational; safety-critical.>
  • Renegotiation and relief: <process for redistributing responsibilities; resolution window.>

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: <honest list of single points of failure; recruitment plan to reduce concentration.>
  • Handover mechanisms: <reference handover requirements per role in the Role Registry; handover must be completed before a role is vacated.>
  • Continuity review cadence: <quarterly; ad hoc on role change.>

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.

  • <Governance decisions accessible to all Full Members.>
  • <Meeting notes published within X hours.>
  • <Membership state and role assignments accessible.>
  • <Contribution records accessible.>
  • <Information request response window.>
  • <Withholding access to information members are entitled to is an accountability trigger under Layer 4.>
  • <No role or individual may be the sole point of access for information required by other role holders.>

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
<RCOS artifacts> <location> <owner> <cadence>
<Member registry> <location> <owner> <cadence>
<Meeting notes> <location> <owner> <cadence>
<Governance proposals> <location> <owner> <cadence>
<Contribution records> <location> <owner> <cadence>

Ratification Record

  • Adopted: <YYYY-MM-DD>
  • Decision type: Strategic
  • Version: <version>
  • Decision record: <link to decision record>

RCOS Standard 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.