- Layer: 1 — Membership System
- Status: Template — adapt for your community
- RCOS reference: §3.2, §3.3, §3.8
Admission Criteria
Why write down who gets in?
Admission is the moment a stranger becomes bound by — and protected by — the community’s rules. If the criteria are informal, the decision collapses into whoever happens to like the applicant. Written criteria make admission a governance act, not a social favor, and make rejection defensible on grounds the community can point to.
How to fill this in
State the explicit conditions under which an applicant may be admitted. Each criterion should be testable from the application itself or from an external check.
- <Criterion 1, e.g. alignment with the primary purpose and Layer 0 identity constraints.>
- <Criterion 2, e.g. willingness to actively contribute in at least one recognized category.>
- <Criterion 3, e.g. no prior forced exit or rejection within the last X months.>
- <Criterion 4, e.g. completion of the application form in good faith — no misrepresentation.>
Onboarding Steps
Why make the process a fixed sequence?
Consent to governance only means something if the member has actually seen the governance. A fixed sequence — review, consent, technical setup — ensures every Full Member crossed the same threshold in the same order, so nobody slips into full rights without having encountered the constraints that come with them.
How to fill this in
List the ordered steps every new member must complete to move from applicant to Full Member. Include explicit consent steps and any tooling/access provisioning required.
- <Step 1, e.g. review all Layer 0–6 artifacts and this onboarding protocol.>
- <Step 2, e.g. explicitly consent to the Membership Agreement and Layer 0 identity constraints.>
- <Step 3, e.g. set up required tooling (wallet, accounts, identity).>
- <Step 4, e.g. join member-only communication channels.>
- <Step 5, e.g. be granted any required permissions for governance participation.>
- <Step 6, e.g. onboarding completion recorded — membership state transitions to Full Member.>
Initial Membership State
Why assign a state at the end of onboarding?
Between “applicant approved” and “fully integrated” there is a real gap — permissions, access, and expectations all change. Declaring the exact state a new member holds at each step removes ambiguity about what they can do right now, and prevents unintentional grants of rights before onboarding is complete.
How to fill this in
State the membership states a member transitions through during onboarding, and what triggers each transition. Reference the Membership State Registry.
- On approval: <e.g. Trial Member.>
- On onboarding completion: <e.g. Full Member (automatic upon completion).>
Trial and Evaluation
RCOS clauses: 3.3.1, 3.3.2, 3.3.3, 3.3.4
Why bound the trial period?
An unbounded trial is a second-class membership that never ends — all obligations, fewer rights. Fixing the duration, the criteria, and the failure path forces a decision point: either the new member transitions into full standing or a defined exit runs. It prevents the trial state from becoming a permanent holding pen.
How to fill this in
Define the duration, evaluation criteria, transition decision, grace period, failure path, and any extension rules. Trial rights are defined in the Membership State Registry.
- Duration: <e.g. 30 days from approval.>
- Evaluation criteria: <e.g. all onboarding steps completed and recorded.>
- Transition decision: <e.g. automatic on completion; or vote-based.>
- Grace period: <e.g. additional X days if onboarding not complete on time.>
- Failure to complete: <e.g. exit process triggered automatically after total period elapses.>
- Extension: <e.g. one-time X-day extension on request.>
- Rights during trial: <reference Membership State Registry.>
- Re-application block: <e.g. members exited due to incomplete onboarding may not reapply for X months.>
Completion Record
RCOS clauses: 3.8.2
Why keep the record permanent?
The completion record is the evidence that a member consented to a specific version of the rules on a specific date. Losing or editing it would make it impossible to answer, months or years later, “what exactly did they agree to?” — which is the only question that matters when a dispute arrives.
How to fill this in
State where the completion record is kept, what it captures (timestamp, artifact versions consented to), and the retention rule.
<Description of the onboarding completion record — where it lives, what it captures, and that it is retained permanently after exit.>
Ratification Record
- Adopted: <YYYY-MM-DD>
- Decision type: Strategic
- Version: <version>
- Decision record: <link to decision record>