Layer 5 · Operations
1 Operations Manual
- Layer: 5 — Operations & Coordination
- Status: Stub — not yet adopted
- RCOS reference: §7.1, §7.3, §7.4, §7.5, §7.6
Core Operational Processes
RCOS definition7.3.4, 7.7.2, 7.6.3
- 7.3.4 Critical operational processes MUST be documented such that continuity does not depend on tacit knowledge held by specific individuals.
- 7.7.2 Critical operational processes MUST NOT rely solely on individual memory, goodwill, or informal transmission.
- 7.6.3 The Operations Manual MUST define, at minimum:
Read 7.3 Documentation and Information Flow in the RCOS spec ↗
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.
| Process | Who | Detail |
|---|---|---|
Temporary and Ad-Hoc Responsibilities
RCOS definition7.1.5, 7.1.4, 7.7.1
- 7.1.5 Temporary or ad-hoc responsibilities MUST be explicitly time-bounded and MUST NOT become ongoing without formal role definition.
- 7.1.4 No ongoing responsibility MAY exist without an explicit role, and no person MAY be held accountable for responsibilities not formally assigned to a role.
- 7.7.1 Ongoing responsibilities MUST NOT exist without an explicit role.
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.”
<Rules for time-bounding, documenting, and reviewing temporary responsibilities — to be defined.>
Role and Domain Interfaces
RCOS definition7.6.3, 7.3.4
- 7.6.3 The Operations Manual MUST define, at minimum:
- 7.3.4 Critical operational processes MUST be documented such that continuity does not depend on tacit knowledge held by specific individuals.
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.
| From | To | Handoff |
|---|---|---|
Workload Boundaries
RCOS definition7.4.1, 7.4.2, 7.4.3, 7.7.3
- 7.4.1 Time, attention, coordination capacity, and emotional labor MUST be treated as finite and limited resources.
- 7.4.2 The community MUST define explicit workload boundaries, including:
- 7.4.3 Workload boundaries MUST be reviewable and adjustable through an authorized governance process.
- 7.7.3 Meeting load, coordination burden, and unpaid or invisible labor MUST be bounded and reviewable.
Read 7.4 Workload and Capacity Boundaries in the RCOS spec ↗
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.
<Meeting load, role load, response time expectations, and renegotiation process — to be defined.>
Operational Continuity
RCOS definition7.5.1, 7.5.2, 7.5.3
- 7.5.1 The community MUST ensure that no single individual is a critical single point of failure for core operations.
- 7.5.2 Core operational roles and processes MUST include:
- 7.5.3 Operational continuity planning MUST be reviewed periodically.
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.
<Current state, handover mechanisms, and continuity review cadence — to be defined.>
Information Flow and Anti-Gatekeeping
RCOS definition7.3.5, 7.7.4, 7.3.2
- 7.3.5 Information flow MUST be designed to prevent gatekeeping, bottlenecks, or dependency on informal intermediaries.
- 7.7.4 Information access rules MUST be explicit and enforceable.
- 7.3.2 Documentation rules MUST specify, at minimum:
Read 7.3 Documentation and Information Flow in the RCOS spec ↗
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.
<Access rules for governance decisions, meeting notes, membership state, and contribution records — to be defined.>
Documentation Locations and Update Procedures
RCOS definition7.3.1, 7.3.2, 7.3.3
- 7.3.1 The community MUST define explicit documentation rules for decisions, roles, operations, and shared obligations.
- 7.3.2 Documentation rules MUST specify, at minimum:
- 7.3.3 All decisions MUST be traceable to:
Read 7.3 Documentation and Information Flow in the RCOS spec ↗
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.
| Document type | Location | Owner | Review cadence |
|---|---|---|---|
| RCOS artifacts | layers/ in this repo | Per change protocol (Layer 6) | |
| <other document types — to be defined> |
Ratification Record
- Adopted:
- Decision type: Strategic
- Version:
- Decision record: