**RCOS — Regenerative Community Operating System**

# Accountability Protocol

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

---
- **Layer:** 4 — Conflict, Repair & Accountability
- **Status:** Template — adapt for your community
- **RCOS reference:** [§6.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [§6.5](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#65-artifacts)

---

## Triggers

*RCOS clauses: [6.4.1](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.5.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#65-artifacts)*

<details data-kind="rationale">
<summary>Why enumerate what starts an accountability check?</summary>

If accountability checks only happen when someone feels strongly enough to push, they become political. Naming the exact triggers — inactivity, breach, invariant violation, referral — means the process starts from a condition anyone can verify, not from a judgement about a person.

</details>

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

List the specific, verifiable triggers that initiate an accountability check. Each trigger should be observable from records or a direct referral.

</details>

An accountability check is initiated when:

1. _<A member has not made a recognized contribution in X consecutive months.>_
2. _<A member has breached a Membership Agreement obligation.>_
3. _<A member has violated a Layer 0 identity constraint or invariant.>_
4. _<A referral is made from the Conflict Resolution Ladder (Step 3 or above).>_

## Investigation and Review

*RCOS clauses: [6.4.2](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.4.3](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.4.6](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.5.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#65-artifacts)*

<details data-kind="rationale">
<summary>Why graduate the response by severity?</summary>

Treating a missed contribution the same as an invariant violation either crushes minor cases with heavy process or lets serious ones slip through a private chat. Graduated pathways — soft check-in, medium written notice, direct escalation for serious breaches — match response weight to breach weight and keep repair the default where repair is still possible.

</details>

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

Define soft (inactivity), medium (obligation breach), and serious (invariant violation, safety) pathways. State who initiates, the response window, and the escalation route for each.

</details>

> **Breach severity guidance:** _<medium = non-compliance with a Membership Agreement obligation that does not threaten member safety or community integrity; serious = Layer 0 invariant violation, credible safety concern, persistent bad-faith conduct.>_

- **Inactivity (soft breach):** _<who contacts the member; response window; outcome paths.>_
- **Obligation breach (medium):** _<written notice; response window; resolution / escalation paths.>_
- **Serious breach / invariant violation:** _<direct escalation to the appropriate Conflict Resolution Ladder step.>_

## Due Process Guarantees

*RCOS clauses: [6.4.2](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.4.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.5.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#65-artifacts)*

<details data-kind="rationale">
<summary>Why spell out notice, response, and appeal rights?</summary>

Accountability without due process is just punishment with paperwork. A member facing a sanction needs to know the concern, have real time to respond, and have somewhere to appeal to — otherwise the deciding body's word is final by default, which concentrates power exactly where it should not concentrate.

</details>

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

State the right to written notice, a minimum response window, and an explicit appeal path to Full Members.

</details>

- **Right to notice:** _<member is notified in writing of the concern before any review or sanction begins.>_
- **Right to respond:** _<minimum response window — e.g. 30 days.>_
- **Right to appeal:** _<any decision may be appealed via the governance process (Strategic vote).>_

## Anti-Retaliation Protections

*RCOS clauses: [6.3.2](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#63-safeguards)*

<details data-kind="rationale">
<summary>Why protect participants explicitly?</summary>

If raising a concern or giving information can cost a member standing, relationships, or access, people will stay silent and the accountability system collapses in practice. Naming retaliation as itself a trigger makes the cost of suppression higher than the cost of reporting.

</details>

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

State that retaliation against any member who raises, participates in, or gives information to an accountability process is itself an accountability trigger.

</details>

_<Retaliation against a member for participating in any part of this process is itself an accountability trigger.>_

## Sanction and Repair Options

*RCOS clauses: [6.4.1](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.4.2](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.4.3](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.4.5](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.4.6](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation), [6.5.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#65-artifacts)*

<details data-kind="rationale">
<summary>Why pre-define the menu of sanctions?</summary>

Ad-hoc sanctions invented mid-process reflect whoever is loudest in the room, not what the breach warrants. A fixed menu — with preconditions, authorized body, and appeal path for each — keeps responses proportional, prevents informal exclusion from becoming the default punishment, and makes it obvious when a sanction is out of scope for the body applying it.

</details>

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

For each sanction type, define preconditions, authorized body, and appeal path. Repair-oriented responses should be the default; punitive ones reserved for safety-critical or unresolved breaches.

</details>

> Repair-oriented responses are preferred over punitive ones except in safety-critical cases.
> Sanctions must be proportional, time-bounded where applicable, documented, and never applied through informal exclusion or social pressure.

| Type | Preconditions | Authorized body | Appealable? |
|---|---|---|---|
| _<Private check-in / reminder>_ | _<inactivity or minor breach>_ | _<role>_ | _<yes>_ |
| _<Written warning>_ | _<unresolved obligation breach after check-in>_ | _<role>_ | _<yes>_ |
| _<Temporary access restriction>_ | _<safety-critical situation; review window>_ | _<role>_ | _<yes>_ |
| _<Forced exit>_ | _<serious or unresolved breach, or Full Member decision>_ | _<Full Members>_ | _<yes — re-vote>_ |

## Conditions for Restoring Rights

*RCOS clauses: [6.4.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation)*

<details data-kind="rationale">
<summary>Why make restoration conditions explicit?</summary>

If there is no defined path back, every sanction becomes effectively permanent and every exit becomes a life sentence. Explicit restoration conditions signal that accountability is about repair where repair is possible, and they prevent post-hoc gatekeeping about whether someone is "really" welcome back.

</details>

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

For each sanction class, state the path to restoration of rights — re-application after voluntary exit, re-application block after forced exit, restoration after temporary restriction.

</details>

- **After voluntary exit:** _<re-application via Onboarding Protocol; no automatic restoration.>_
- **After forced exit:** _<minimum re-application block; standard admission process applies.>_
- **After temporary access restriction:** _<rights restored upon confirmation of resolution within review window.>_

## Coordination with Layer 1

*RCOS clauses: [6.4.4](https://blueprint.ecohubs.community/articles/rcos-core/v0-1/layer-4-conflict-repair-accountability#64-sanctions-repair-and-separation)*

<details data-kind="rationale">
<summary>Why tie this to the Exit & Separation Protocol?</summary>

Exit rules live in Layer 1 for a reason — they govern who is and is not a member. If accountability actions created their own parallel exit path, there would be two sets of rules, two sets of records, and a loophole for skipping due process. One canonical exit protocol closes that gap.

</details>

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

State that all forced exits and temporary access restrictions follow the Exit & Separation Protocol (Layer 1), and clarify that a temporary restriction does not constitute exit.

</details>

_<All forced exits and temporary access restrictions follow the Exit & Separation Protocol (Layer 1). A temporary access restriction does not constitute exit and does not trigger the re-application block unless a forced exit is subsequently voted by Full Members.>_

---

## Ratification Record

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