---
title: "Facilitation before formalisation"
description: "Protocols emerge from repeated practice, not from design sessions"
url: "/facilitation-before-formalisation/"
tags: [principle]
readingPathPosition: 10
---

# Facilitation before formalisation

Protocols are not designed theoretically and then adopted. They emerge from a developmental sequence: **facilitation → pattern recognition → formalisation**. You start with concrete practice – running formats, facilitating real decisions, holding actual conflicts. Over time, patterns emerge: recurring dynamics, effective formats, characteristic failure modes. Only then do you formalise into [three-layer protocols](/every-protocol-has-three-inseparable-layers.md) – giving the pattern an explicit accord, naming the ritual that makes it work, and building in the critique and contemplation that keep it honest.

A protocol that skips this sequence – designed at a distance and adopted without prior practice – lacks the experiential ground from which ritual, critique and contemplation draw their life. The norms that govern a protocol don't pre-exist the practices from which they emerge; they are [constructed through those practices](/protocols-are-normative-structures.md), made explicit from commitments that were implicit all along. [Consciousness raising](/naming-experiences-is-how-protocols-learn.md) is what turns lived experience into articulable pattern, and articulable pattern into adoptable protocol.

The same logic applies at a smaller scale: every protocol version is a hypothesis, not a settlement. Built-in review dates and evolution criteria ensure that each version is tested in practice and revised through the same cycle of experience, naming, and formalisation. Critique and contemplation exist precisely to surface what isn't working – but only if the network actually acts on what it learns.

## Sources

- Safe-to-fail experimentation in complex domains from the the Cynefin framework as initially proposed in Snowden & Boone (2007), "A Leader's Framework for Decision Making" (*Harvard Business Review*)

## In this vault

- Previous: [Design for scale](/design-for-scale.md)
- Next: [Start with simple rules](/start-with-simple-rules.md)
- Referenced by: [Consent-as-default](/consent-as-default.md), [Naming experiences is how protocols learn](/naming-experiences-is-how-protocols-learn.md), [Protocol design is guided by a set of principles](/protocol-design-is-guided-by-a-set-of-principles.md), [Tension drives development](/tension-drives-development.md)