> For the complete documentation index, see [llms.txt](https://urd.gitbook.io/compass/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://urd.gitbook.io/compass/learning-and-adapting/learning-from-experience-and-sharing-insights/documenting-and-sharing-formats-dissemination-and-safeguards.md).

# Documenting and sharing: formats, dissemination and safeguards

**A lesson that isn't shared has no effect.**

Once an experience has been captured (through a debrief or a structured lessons learning process) the work isn't finished. It still needs to become something someone else can pick up and use. This page covers how to choose a format, write it well, share it responsibly, and avoid causing harm along the way.

***

### <mark style="color:orange;">**Choosing a format**</mark>

Match the format to the effort already invested and the audience identified during framing, going from lightest to most elaborate:

<table><thead><tr><th width="194">Format</th><th width="140">Length</th><th>Best for</th></tr></thead><tbody><tr><td>Good practice sheet</td><td>1-2 pages</td><td>A specific practice worth repeating, aimed at internal teams</td></tr><tr><td>After Action report</td><td>1-2 pages</td><td>An activity just completed, that would be repeated</td></tr><tr><td>Lessons learned brief</td><td>2–4 pages</td><td>A fuller account of an experience, with context and nuance</td></tr><tr><td>Case study</td><td>Several pages</td><td>A stand-alone resource that can feed into training or advocacy</td></tr><tr><td>Guidance note</td><td>Varies</td><td>Recommendations meant to shape the design of future projects</td></tr></tbody></table>

There's no obligation to move up this list. A well-written one-page sheet that actually gets read is worth more than an unfinished case study.

***

### <mark style="color:orange;">**Principles for writing it well**</mark>

* **Lead with what matters:** A reader skimming for 30 seconds should still walk away with the essential point. Consolidate action points at the beginning or end of the document for easier reference. That would matter most for potential users.
* **Be honest about what didn't work:** A document that only shows success fails to drawn all the learning from the experience. The value is often concentrated in what went wrong and why.
* **Attribute carefully:** Credit the people and decisions involved without exposing individuals unnecessarily. People do not necessarily need to be named; what matters is what they have to say. Sometimes, however, it is helpful to clarify their role in order to interpret their testimony correctly.
* **Write for action:** Every lesson should translate into something concrete a reader could actually do differently.

***

### <mark style="color:orange;">**Sharing it**</mark>

**Internally**

* Fold lessons sheets into onboarding for new team members.
* Bring them into project launch briefings as exposed in the [Design](/compass/implementing/design.md) or in project reviews.
* Keep them in a single, easy-to-find repository rather than scattered across individual project folders.
* Make sure recommendations or actions are reported in the Project Management Tool, under the Recommendations follow-up (or any relevant tool you have), so that the Project Manager can&#x20;

**Externally**

* Share with operational partners and coordination mechanisms, especially those who contributed to the paper.
* Contribute to sector-wide learning where relevant. In line with Commitment 6 (coordination and complementarity) and Commitment 9 (using resources responsibly, by helping others avoid repeating costly mistakes).

***

### <mark style="color:orange;">**Safeguards: protecting people, not just data**</mark>

When a lesson draws on testimony from communities or staff, the same principles that apply to data handling elsewhere in the COMPASS apply here: **informed consent**, **anonymisation** where needed, and **particular care** when the experience touches a sensitive subject (protection concerns, safeguarding, internal conflict).

Documenting a lesson is never worth doing "at all costs." If sharing it risks exposing someone, the right call is to document it for internal use only, or not at all.

***

### <mark style="color:orange;">**Key points**</mark>

* Match the format to the audience: don't default to the most elaborate one available.
* Honest accounts of failure carry more transferable value than polished success stories.
* A lesson only has impact once it reaches someone who can act on it.
* Internal sharing is not optional groundwork, it's often where the biggest gains sit.
* Never let the ambition to document override the responsibility to protect the people the lesson is about.