A community that forgot why
The rule survives and the reason does not — so nobody can tell whether it still earns its place, or which version is even in force.
What it looks like
- A rule is followed and nobody present can say what it was for.
- Two versions of a document exist and nobody can say which one is in force.
- Decisions are recorded as outcomes, without who decided them or under what rule.
- The people who could explain the history are the people who left.
Why it is hard to see
Because nothing is missing until somebody asks.
The rule is on the page. People follow it. The community functions. It is only when a member proposes changing it — or a new arrival asks why — that the group discovers it holds an artefact whose purpose has gone. And the discovery usually comes with an argument, because in the absence of a stated reason everybody supplies their own, and theirs conveniently supports what they already wanted.
The second reason: the loss is gradual and load-bearing at the same time. A rule with a forgotten reason cannot be evaluated. It cannot be defended against a bad-faith challenge or repealed when it has genuinely expired, because both require knowing what it was for. So communities keep everything, and the agreements slowly become an accumulation rather than a design.
Then the sharper version, which is what turns forgetting into a live problem: the record does not say which version is in force. A document that has been revised without an adoption record is not one document with a history. It is two documents with a claim, and every rule downstream of it inherits the ambiguity.
What to check
Pick three rules and ask what each was for. Not what it does — what happened that made somebody write it. If nobody in the room can answer for two of them, the reasons are gone and the rules are running unexamined.
Ask which version is current. Then ask how you would know. “Whichever is in the shared folder” is not an answer if the folder contains two.
Look at a decision record from four years ago. Does it say who decided, under what rule, and from when? Or only what was decided? The second is a note, not a record, and it cannot settle a dispute.
Ask what the community learned from its hardest year. If the answer lives in three people’s memories, it will leave when they do.
If it is already happening
Fix the present before the past. Establish which documents are in force today, agreed in one meeting. That is achievable; reconstructing a decade is not, and communities that attempt the second usually abandon both.
Add the two fields that would have prevented it: an adoption record on every document — who agreed it, when, under which rule — and a summary of what changed from the previous version. Two fields, and they are the difference between a version history and a pile.
Keep the superseded text. Deleting the old version destroys the evidence of what the community used to think, which is exactly what you need when somebody asks why.
And write down the reasons while the people are still here. A short note against each significant rule — this exists because of what happened in 2019 — is the cheapest institutional memory available, and it can be done in an afternoon by whoever has been there longest. It is also the single most valuable thing a departing long-standing member can leave behind, and almost nobody asks them for it.
What prevents it
A version history that makes “which version is in force” answerable, and a learning log that records what a difficult year taught. Both are clerical, and this is the one failure class where the defence is entirely clerical.
Sources & further reading
- 1 RCOS stress test — Institutional Amnesia — the specification this page puts into plain language
- 2 RCOS Core — Layer 6: Evolution & Adaptation — version history, the learning log, and what makes a rule change valid
- 3 Drift — the slow version, and why it does not feel like anything while it happens
Written by EcoHubs members, with AI assistance for drafting and editing, and reviewed by a person before publication. Facts are checked against the sources listed; anything we could not verify is marked. How this is written
The specification
This page is the plain-language version. RCOS publishes the stress test itself — the failure pattern, what is being tested, and what a compliant community would have in place.
Terms used here
- Drift
- The slow failure where nothing breaks. Agreements stop being read, shared habits thin out, and nobody ever decided any of it.
- Agreements
- The written rules a community has consented to. Distinct from values: agreements say what happens, and what follows when it does not.
- Ratification
- A hold between a proposal passing and it taking effect, during which the result is confirmed before it becomes real.
- Founder transition
- Turning the authority that built a community into something anyone can hold or inherit. Communities that skip it cannot disagree with their founders or continue without them.
These travel together
Failures are rarely alone. If this one is familiar, check the others from the same lesson before concluding you have found the whole problem.
- The emergency measure that stayed
Decided fast because it had to be, never reviewed, and now it is what the community does — with a precedent attached.
- Experiments with no way back
A trial that quietly became the arrangement — because nobody wrote down when it ended or what would count as it failing.
- Sub-groups with undefined autonomy
A community grows into parts, and nobody says what the parts may decide — so each one improvises a constitution and discovers later they do not match.
- Governance with no path to change it
The rules can no longer be changed, so people stop trying — and the community loses its members quietly instead of loudly.
- The invariant nobody protected
The founding principle everybody assumed was permanent — changeable, it turns out, by an ordinary majority on an ordinary evening.