Scope Declaration
Download this template
Generated 2026-08-31 · Download all templates
In-Scope Assets
What does the community own or steward together?
RCOS clauses 2.2.1, 2.2.2, 2.2.4
Why enumerate every governed asset?
If the community has not explicitly named an asset as in-scope, it isn't — full stop. Listing assets by name closes the gap where informal claims of authority grow over undeclared resources, and gives members a concrete checklist to verify what the community actually controls.
How to fill this in
List every asset the community collectively governs: shared funds, treasuries, land, real estate, software, websites, social accounts, brand, intellectual property, physical infrastructure, etc. Be specific — name accounts, wallets, domains.
- <Asset 1, e.g. the shared treasury held in a specific multi-sig wallet.>
- <Asset 2, e.g. the community website and its domain.>
- <Asset 3, e.g. shared physical infrastructure or land.>
- <Asset 4.>
What to cover
- What do we own, hold or look after together — money, land, buildings, equipment, software, websites, accounts, our name and logo?
- For each one: what exactly is it — which account, which plot, which domain — so no one can argue about what is meant?
- What do individuals hold on the community's behalf, such as an account or a domain in a member's name — and do we count it as ours?
- Is anything shared in practice that we have never named? (Which decisions and which work are collective are their own questions.)
Examples
The collective governs: the shared treasury held in our two-of-three multi-signature wallet; the project website and its domain; the code repositories under the collective's organisation account; our chat server and social media accounts; and the collective's name, logo and published guides. Any account a member registers on the collective's behalf belongs to the collective.
Examples, not recommendations. Your answers will be your own.
In-Scope Decision Domains
Which decisions belong to the group rather than to individuals?
RCOS clauses 2.2.1, 2.2.2
Why name decision domains, not just assets?
Scope isn't only about stuff — it's about which kinds of questions the community gets to answer collectively. Naming decision domains makes it unambiguous where collective authority applies and where an individual or external party still decides, preventing quiet capture of decision territory.
How to fill this in
List the categories of decisions the community has authority over. These map to later layers (governance, membership, treasury, etc.) — name them at a level that makes it clear what kinds of questions the community decides together.
- <Decision domain 1, e.g. governance rules and decision processes (Layer 2).>
- <Decision domain 2, e.g. membership rules and admission (Layer 1).>
- <Decision domain 3, e.g. treasury and shared resource allocation (Layer 3).>
- <Decision domain 4.>
What to cover
- What kinds of questions do we decide together — for example how we decide, who can join, how shared money is spent, how shared spaces are used?
- For each one: where does it stop — what stays with an individual, a household or an outside party?
- Are any decisions taken by one person today out of habit that we want to name as the group's — or say plainly are not? (How each kind of decision is made is its own question.)
Examples
We decide together on: our governance rules and how decisions are made; who may join, and on what terms; how the shared budget and reserves are spent; the use and upkeep of the shared house, garden and guest rooms; and any agreement made in the community's name with an outside party. Decisions about each household's own flat stay with that household.
Examples, not recommendations. Your answers will be your own.
In-Scope Activities and Responsibilities
Which work and responsibilities are collective?
RCOS clauses 2.2.1, 2.2.2
Why declare the work the community owns?
Authority without owned responsibility produces paralysis; responsibility without declared authority produces burnout and blame. Listing the activities the community collectively governs makes the work visible, assignable, and accountable — and makes it obvious when something important has no owner.
How to fill this in
List the ongoing activities the community is responsible for: maintaining shared infrastructure, admitting members, reporting on resources, stewarding the brand, etc. These are the things that need an owner via Layer 5.
- <Activity 1.>
- <Activity 2.>
- <Activity 3.>
- <Activity 4.>
What to cover
- What ongoing work are we responsible for as a community — upkeep, welcoming new members, keeping accounts, looking after our name, hosting visitors?
- For each one: is it done regularly or only when needed, and what goes wrong if no one does it?
- Is anyone doing work today that nobody formally took on — and should it be collective, or should we say it is not? (Who does each piece of work is decided when roles are assigned.)
Examples
As a community we are responsible for: maintaining the shared water supply, paths and solar system; running the vegetable garden and orchard; admitting and welcoming new members; keeping the accounts and reporting on them twice a year; and hosting visitors and volunteers. Work on private dwellings and personal gardens is not a collective responsibility.
Examples, not recommendations. Your answers will be your own.
Explicitly Out of Scope
What is none of the community's business — and stays that way?
RCOS clauses 2.2.3, 2.2.4, 2.2.5
Why name what the community must not touch?
An unstated boundary is no boundary at all. Explicit out-of-scope items protect members from the community reaching into their private lives and finances, and protect external parties from the community presuming authority over their affairs. If it isn't named here, the default rule of "not in-scope means out of scope" still applies — but naming the big ones removes any room for argument.
How to fill this in
List the most important boundaries: things people might assume are in scope but aren't. Personal finances, private relationships, third-party infrastructure, external projects, etc.
- <Out-of-scope item 1, e.g. personal income and private finances of members.>
- <Out-of-scope item 2, e.g. private relationships and personal living arrangements (except where Layer 4 safety-critical conditions apply).>
- <Out-of-scope item 3, e.g. underlying server infrastructure and third-party service contracts.>
- <Out-of-scope item 4.>
What to cover
- What might people assume the community has a say in, that it does not — members' money, relationships, jobs, beliefs, or other projects they belong to?
- Which outside organisations, services or neighbours do we work with but have no authority over?
- Do we say plainly that anything not named as in scope is out of scope, even if this list does not mention it?
- What happens to a decision that reaches into something on this list — does it simply have no effect?
Examples
The following are out of scope: members' personal income, savings and private finances; their private relationships and how they arrange their own homes; their paid work and projects outside the community; and the hosting companies and software services we use, whose terms we accept but do not govern. Anything not declared in scope is out of scope, and a community decision that reaches into these areas has no effect.
Examples, not recommendations. Your answers will be your own.
Ratification Record
Who adopted this scope, when, and how was it decided?
- Adopted: <YYYY-MM-DD>
- Decision type: Constitutional
- Version: <version>
- Decision record: <link to decision record>