Learning Log
Records major failures, adaptations, reversals, and systemic learnings. Repeated failure patterns must trigger structural review, not individual blame. Entries are prepended (most recent first).
Download this template
Generated 2026-08-31 · Download all templates
What Constitutes a Learnable Event
What kind of thing going wrong is worth writing down and learning from?
RCOS clauses 8.4.1, 8.4.4, 8.6.5, 8.7.4
- 8.4.1 Major failures, adaptations, reversals, and systemic learnings MUST be documented.
- 8.4.4 Repeated failure patterns MUST trigger structural review rather than individual blame.
- 8.6.5 The Learning Log MUST define:
- 8.7.4 Major failures and adaptations MUST be captured as shared learning, not erased or hidden.
Why define the trigger explicitly?
If "we should learn from this" is left to individual judgement, the hardest lessons — the ones involving conflict, failure, or embarrassment — are the ones most likely to go unrecorded. Naming the specific events that MUST produce an entry takes the question out of the moment, and makes sure uncomfortable learnings are captured rather than quietly dropped.
How to fill this in
List the specific events that obligate a Learning Log entry. State who owns the log and the synthesis cadence.
An entry MUST be added when any of the following occur:
- <A governance decision is reversed, rolled back, or found to contradict another adopted rule.>
- <An experiment concludes (success, failure, or early termination).>
- <A conflict escalates to the governance step of the Conflict Resolution Ladder.>
- <A structural or systemic failure is identified that caused harm, confusion, or repeated process breakdown.>
- <A major adaptation to community operations is adopted that significantly changes how a layer functions.>
- <A near-miss: a situation that could have caused significant harm but was caught before it did.>
- <Any event the community collectively identifies as worth learning from.>
<Minor operational adjustments, routine decisions, and individual issues fully resolved at the early steps of the Conflict Resolution Ladder do not require a Learning Log entry.>
Ownership: <role responsible for ensuring entries are created and maintained.>
Synthesis cadence: <the Learning Log is reviewed at the Reflection & Learning meeting; named role prepares a brief synthesis of entries since the last review, noting recurring patterns.>
No entries yet. First entry will be added when the first learnable event occurs.
What to cover
- Which events always require a Learning Log entry — such as a reversed decision, an ended experiment, an escalated conflict, a failure that caused harm, a major change in how we work, or a near-miss?
- What does not need an entry?
- Who owns the log and makes sure entries are written? (What an entry contains is its own question.)
- How often is the log reviewed, and who prepares a summary of patterns?
- When the same kind of failure keeps happening, how do we review the structure behind it instead of blaming a person?
- How do we make sure uncomfortable failures are recorded and never deleted or hidden later?
Examples
An entry is required when a decision is reversed, an experiment ends, a conflict reaches the governance step, a failure causes harm or repeated breakdown, a major change in how we work is adopted, or a near-miss happens. Routine decisions and conflicts settled early do not need one. The learning steward makes sure entries are written and never removed. Each quarter the steward summarises new entries; if the same kind of failure appears twice, we review the structure behind it rather than looking for someone to blame.
Examples, not recommendations. Your answers will be your own.
Entry Format
What do we record about something we learned, so it is still useful in three years?
RCOS clauses 8.4.2, 8.4.3, 8.6.5
Why a fixed entry template?
Free-form reflection is valuable, but it does not aggregate. A consistent schema — trigger, signals, what changed, outcome, follow-up owner — makes it possible to scan years of entries for recurring patterns and to turn isolated incidents into structural evidence. It also forces each entry to name an owner, so learning does not stop at "we noticed."
How to fill this in
Use the template below for every entry. Each field forces a different lens on the event; do not skip the follow-up owner.
## <YYYY-MM-DD> — <Short title>
- **Trigger:** <What happened that prompted this entry>
- **Layers/artifacts implicated:** <e.g. Layer 2 — Governance Protocol>
- **What occurred:** <Short narrative>
- **Signals that triggered action:** <What made this visible as a problem>
- **What changed or was tried:** <Decision, experiment, or rule change>
- **Outcome:** <Result after review, if known>
- **Follow-up owner and due date:** <Name / role and date, or "none">
What to cover
- What happened, and why did it matter?
- Which rules, roles or documents were involved?
- What signs, evidence or thresholds made us act?
- What did we change, try or stop, and what came of it?
- Who owns the follow-up, and by when?
- Who can read entries under our information access rules, and what is left out to protect the people involved?
Examples
Each entry records the date, what happened and why it mattered, which rules or documents were involved, what signs or thresholds made us act, what we changed, tried or stopped, what came of it, and who follows up by when. Entries have the same access level as meeting minutes, so all members can read them; names of the people involved are left out unless they agree.
Examples, not recommendations. Your answers will be your own.