Onboarding Protocol
Download this template
Generated 2026-08-31 · Download all templates
Admission Criteria
Who can join, on which written criteria, and who decides — so nobody becomes a member just by being around?
RCOS clauses 3.2.3, 3.2.4
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.>
What to cover
- Which criteria must an applicant meet, written so anyone could check them?
- Who decides an application? (Name the body the Decision Matrix gives admissions to, rather than a second rule.)
- How do we make sure nobody becomes a member informally, or after the fact?
Onboarding Steps
What actually happens between "I'd like to join" and "I'm in"?
RCOS clauses 3.2.1, 3.2.2
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.>
What to cover
- What are the steps, in order, from an approved application to full membership?
- At which step does someone read all our governance documents, and how do we know they have?
- At which step do they explicitly agree to our identity constraints and our membership rules — and how?
- At which step is their starting membership state declared, and by whom? (What that state allows is its own question.)
- Which accounts, tools and channels are set up, by whom, and at which step?
Examples
1. The applicant reads all our governance documents with a buddy, who answers their questions. 2. They confirm in writing that they consent to our identity constraints and the Membership Agreement, and the membership steward declares them a Trial Member. 3. The admin sets up their member account and adds them to the members' chat. 4. When their trial ends with a positive decision, completion is recorded and they become a Full Member.
Examples, not recommendations. Your answers will be your own.
Initial Membership State
What is someone on their first day — and what can they do yet?
RCOS clauses 3.1.2, 3.1.4
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).>
What to cover
- Which membership state does someone hold on their first day, named as in our Membership State Registry?
- Which states do they pass through during onboarding, and what triggers each move?
- What can they do yet on their first day, and what has to wait? (The rights of each state are set in the Membership State Registry.)
- How do we make sure no access or right is given before the step that unlocks it?
Examples
When their application is approved, a new person becomes a Trial Member, with the rights the Membership State Registry gives that state. They become a Full Member automatically on the day their onboarding completion is recorded. There is no other route to Full Member, and no Full Member access is given before that day.
Examples, not recommendations. Your answers will be your own.
Trial and Evaluation
How long is someone new on trial, what are they judged on, who decides — and what happens if it does not work out?
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.>
What to cover
- How long does the trial last, and from when is it counted?
- What is the new member judged on — written so they can check it themselves?
- Who makes the decision at the end of the trial, and how?
- During the trial, which obligations apply, and how does the new member know them? (Which rights are limited is set in the Membership State Registry.)
- If the trial does not end in full membership, what happens — can it be extended, for how long and how often, and when does exit begin?
- After an exit at the end of a trial, how long before someone may apply again?
Examples
The trial lasts 6 months from the day the person signs, and every member obligation applies in full. They are judged on having completed every onboarding step and met the participation minimum in at least 5 of the 6 months. At the end, the full members decide by consent at a general meeting. If the criteria are not met, the trial can be extended once by up to 3 months; after that, the exit process begins, and the person may reapply after 12 months.
Examples, not recommendations. Your answers will be your own.
Completion Record
How do we record that someone has finished joining, and what does the record keep?
RCOS clauses 3.8.2
- 3.8.2 Layer 1 artifacts MUST be:
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.>
What to cover
- Where is the completion record kept, and who writes it?
- What does it capture — at least the date, and the exact version of every document the person agreed to?
- How long is it kept, including after the person leaves?
Examples
The membership steward records completion in the members' register on the day the last onboarding step is done. The entry holds the date, the person's name, their new membership state, and the version number of each document they consented to. Entries are never deleted; after someone leaves, their entry stays, marked with the exit date.
Examples, not recommendations. Your answers will be your own.
Ratification Record
Who adopted this onboarding process, when, and how was it decided?
- Adopted: <YYYY-MM-DD>
- Decision type: Strategic
- Version: <version>
- Decision record: <link to decision record>