**RCOS — Regenerative Community Operating System**

# Membership Agreement

- **Generated:** 2026-04-29
- **Source (latest version):** [https://blueprint.ecohubs.community/articles/rcos-templates/layer-1/membership-agreement](https://blueprint.ecohubs.community/articles/rcos-templates/layer-1/membership-agreement)
- **All RCOS templates:** [https://blueprint.ecohubs.community/articles/rcos-templates](https://blueprint.ecohubs.community/articles/rcos-templates)

---
- **Layer:** 1 — Membership System
- **Status:** Template — adapt for your community
- **RCOS reference:** [§3.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#34-rights-and-obligations), [§3.5](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#35-participation-and-contribution), [§3.8](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#38-artifacts)

> Signed (or explicitly acknowledged) by every member at the time of admission. Defines the rights and obligations of each membership state.

---

## Membership State on Signing

*RCOS clauses: [3.1.2](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#31-membership-states), [3.1.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#31-membership-states)*

<details data-kind="rationale">
<summary>Why declare state at signing?</summary>

Membership is not a single binary. A person joining must know exactly which state they are entering — Trial or Full — because the state determines what they can do and what is expected of them. Naming it at the moment of consent prevents ambiguity later about what they actually signed up for.

</details>

<details data-kind="instructions">
<summary>How to fill this in</summary>

State which membership state(s) a new member enters at signing (e.g. Trial Member, Full Member, or any custom state defined in your Membership State Registry).

</details>

_<Membership state assigned at signing — e.g. Trial Member on application approval; Full Member on onboarding completion.>_

## Member Rights

*RCOS clauses: [3.4.1](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#34-rights-and-obligations), [3.4.3](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#34-rights-and-obligations), [3.4.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#34-rights-and-obligations)*

<details data-kind="rationale">
<summary>Why enumerate rights explicitly?</summary>

Rights that are not written down are rights that can be quietly withdrawn. Enumerating them makes the community's commitments legible, enforceable, and symmetrical with the obligations members are asked to carry. Without this list, obligations become open-ended demands with no reciprocal protection.

</details>

<details data-kind="instructions">
<summary>How to fill this in</summary>

List concrete rights granted to each membership state. Reference the Decision Matrix (Layer 2) for voting rights, the Role Registry (Layer 5) for role eligibility, and Layer 4 for due-process guarantees.

</details>

1. _<Right 1, e.g. the right to vote on all decisions as defined in the Decision Matrix.>_
2. _<Right 2, e.g. the right to access all member-only channels, calls, and community records.>_
3. _<Right 3, e.g. the right to hold roles as defined in the Role Registry.>_
4. _<Right 4, e.g. the right to earn recognition through recognized contributions.>_
5. _<Right 5, e.g. the right to propose changes through the governance process.>_
6. _<Right 6, e.g. the right to raise a conflict through the Conflict Resolution Ladder without retaliation.>_
7. _<Right 7, e.g. the right to exit the community voluntarily at any time.>_
8. _<Right 8, e.g. the right to due process before any forced exit, suspension, or access restriction.>_

## Member Obligations

*RCOS clauses: [3.4.2](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#34-rights-and-obligations), [3.4.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#34-rights-and-obligations), [3.4.5](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#34-rights-and-obligations)*

<details data-kind="rationale">
<summary>Why bound obligations tightly?</summary>

Open-ended obligations are how communities slide into exploitation — "contribute more," "be available," "show up" with no defined limit. Listing obligations discretely, and tying each one to a corresponding right, keeps the ask bounded and contestable. A member must always be able to tell whether they are meeting the agreement or being asked for something beyond it.

</details>

<details data-kind="instructions">
<summary>How to fill this in</summary>

List concrete, bounded obligations. Each obligation must be testable: a member must be able to know whether they are meeting it. Avoid vague duties.

</details>

1. _<Obligation 1, e.g. adhere to all Layer 0 identity constraints and invariants at all times.>_
2. _<Obligation 2, e.g. contribute to the community in at least one recognized category per defined period.>_
3. _<Obligation 3, e.g. participate in conflict resolution processes when named as a party or requested as a witness.>_
4. _<Obligation 4, e.g. complete onboarding before exercising Full Member rights.>_
5. _<Obligation 5, e.g. notify the community before extended absence.>_
6. _<Obligation 6, e.g. not misrepresent the community, its members, or its governance externally.>_
7. _<Obligation 7, e.g. not exercise authority beyond what is explicitly assigned through the governance system.>_

## Participation and Contribution Expectations

*RCOS clauses: [3.5.1](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#35-participation-and-contribution), [3.5.2](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#35-participation-and-contribution), [3.5.3](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#35-participation-and-contribution), [3.5.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-1-membership-system#35-participation-and-contribution)*

<details data-kind="rationale">
<summary>Why define participation in numbers?</summary>

"Active member" means nothing without a threshold. A defined minimum — in time, category, and cadence — turns participation from a feeling into a fact, so nobody has to guess whether they are in good standing, and nobody can be accused of drifting without evidence. It also makes the line between a genuine absence and quiet abandonment visible early enough to act on.

</details>

<details data-kind="instructions">
<summary>How to fill this in</summary>

State a measurable minimum (frequency × category), substitution and absence rules, and the trigger that moves a non-participating member into a Layer 4 process.

</details>

- **Minimum contribution:** _<e.g. at least one recognized contribution per 6 months, in any recognized category.>_
- **Recognized categories:** _<reference the Internal Economy Protocol (Layer 3).>_
- **Substitution:** _<e.g. a member may delegate a specific task but remains responsible for meeting overall contribution expectations.>_
- **Extended absence:** _<e.g. notification required before absences longer than X months; expectations paused for the notified period up to a maximum.>_
- **Non-participation trigger:** _<e.g. absence of recognized contribution for X consecutive months without prior notice triggers an accountability check (Layer 4).>_

## Due Process Reference

<details data-kind="rationale">
<summary>Why re-state due process here?</summary>

The Membership Agreement is the one document every member actually reads and consents to. Naming due process here — not only in Layer 4 — guarantees that no member can be removed or restricted under a rule they were not shown when they joined. It closes the gap between what the community promises and what it can do.

</details>

<details data-kind="instructions">
<summary>How to fill this in</summary>

Reference the Conflict Resolution Ladder (Layer 4) and the Exit & Separation Protocol so that any member reading the Membership Agreement knows where the procedural protections live.

</details>

Any forced exit, suspension, or access restriction follows Layer 4 due process and the Exit & Separation Protocol.

## Consent Acknowledgment

<details data-kind="rationale">
<summary>Why require explicit consent?</summary>

Consent that is assumed is consent that can be denied later. Requiring an explicit act — signing, clicking, acknowledging — at a known moment binds the member to the specific artifact versions in force that day, and gives the community a defensible record that the agreement was entered freely and knowingly.

</details>

<details data-kind="instructions">
<summary>How to fill this in</summary>

Describe the act of consent (signature, in-app acknowledgment, etc.), and what artifact versions the member is consenting to at that moment.

</details>

By entering the community through the defined onboarding process, the member explicitly consents to the terms of this agreement and the Layer 0 artifacts in force at the time of admission.

---

## Ratification Record

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