- Layer: 3 — Economic & Resource System
- Status: Template — adapt for your community
- RCOS reference: §5.1, §5.2, §5.4, §5.5
Commons vs. Private Classification
RCOS clauses: 5.1.1, 5.1.2, 5.1.3, 5.1.4, 5.1.5, 5.6.2
Why classify every resource?
Unclassified resources are where quiet privatization happens — someone starts treating a shared asset as personal, or a private asset gets quietly absorbed into community obligations, and by the time anyone notices the norm has shifted. Explicit classification, with stewards and transfer rules named up front, makes any change to that status a visible governance act rather than a creeping fact.
How to fill this in
For each resource the community holds, declare classification (Commons / Private), name a steward, define access rules, and state transfer constraints. Unclassified resources must not be allocated, encumbered, monetized, or transferred until classified.
| Resource | Classification | Steward | Access rules | Transfer constraints |
|---|---|---|---|---|
| <…> | <…> | <…> | <…> | |
| <…> | <…> | <…> | <…> | |
| <…> | <…> | <…> | <…> | |
| <…> | <…> | <…> | <…> |
Any unclassified resource must not be allocated, encumbered, monetized, or transferred until classification is completed.
Recognized Contribution Categories
RCOS clauses: 5.2.1, 5.2.3, 5.6.3
Why name the kinds of work that count?
If the community never says out loud which kinds of work it depends on, the invisible work — care, facilitation, moderation, stewardship — stays invisible, and the people doing it burn out or leave. Enumerating categories converts “someone just does this” into recognized labour the system has to account for.
How to fill this in
List the categories of contribution your community recognizes. Care, facilitation, stewardship, and informal participation are commonly under-recognized — name them explicitly if they apply.
| Category | Examples |
|---|---|
Contribution Recognition Mechanism
Why pin down how recognition actually works?
Without a defined mechanism, “who gets credit” becomes a matter of who is loudest or closest to whoever decides. Specifying what qualifies, how it’s recorded, who validates, and how to dispute it turns recognition into something a member can actually rely on — and blocks recognition from silently mutating into governance influence.
How to fill this in
State what qualifies, how recognitions are recorded, who validates, what they unlock (or do not unlock), and how members dispute a record.
- What qualifies:
- How contributions are recorded:
- Who validates:
- Effect on access/privileges:
- Dispute:
Internal Units
Why define internal units this precisely?
Internal units tend to grow powers no one voted for — decay, caps, transferability, governance weight — unless each property is nailed down in writing. Listing issuance, transfer rules, privacy, and explicit non-governance status makes the units tools of recognition rather than quiet shadow currencies.
How to fill this in
If your community uses internal units (XP, ECO, credits, etc.), define each unit’s purpose, issuance, transferability, decay, cap, fraud prevention, and privacy. Explicitly state that units do not grant governance rights beyond the membership state.
| Property | ||
|---|---|---|
| Purpose | <…> | <…> |
| Issuance | <…> | <…> |
| Transferability | <…> | <…> |
| Expiration / decay | <…> | <…> |
| Hard cap | <…> | <…> |
| Fraud prevention | <…> | <…> |
| Privacy | <…> | <…> |
Internal units do not grant governance rights beyond what the membership state defines.
Accumulation Constraints
RCOS clauses: 5.4.1, 5.4.2, 5.4.3, 5.4.4, 5.6.4
Why constrain accumulation at all?
Any internal unit that can pile up without limit eventually becomes leverage — a few members with large balances gain informal sway the governance system never granted them. Stating accumulation rules explicitly, even when the current rule is “none yet,” keeps the question open and forces a visible decision before concentration becomes a structural problem.
How to fill this in
State the current accumulation rule (cap, decay, none) and the rule that no internal unit may be converted into governance authority.
External Income Interfaces
RCOS clauses: 5.3.2
Why require approval before money arrives?
Once funds are in hand, the conversation shifts from “should we accept this?” to “what do we do with it?” — and the conditions attached to the income (grant terms, partnership obligations, service commitments) are often already locked in. Requiring a Strategic decision before any new income channel opens keeps the community in control of what it takes on.
How to fill this in
List current declared income channels, name potential future channels, and require Strategic approval before any new channel is opened.
Dispute Resolution for Economic Records
Why time-box economic disputes?
Contribution and balance records accumulate fast; if disputes could be raised indefinitely, the ledger would never settle and every historical credit would stay contestable. A defined window with a named resolver and an appeal path gives members a real chance to correct errors without leaving the whole economic history perpetually unstable.
How to fill this in
State the dispute window, named resolver, and appeal path. Reference the Contribution Recognition Mechanism for the full process.
Ratification Record
- Adopted:
- Decision type: Strategic
- Version:
- Decision record: