ToC Platform: Ritual and Purpose

In the world of systems change, we often speak in the language of logic: processes, frameworks, workflows, causal links. It gives us precision and structure - critical to being able to present arguments for funding or justify interventions and to coordinate work across diverse and complex communities. This language lets us map actions to outcomes, chart progress over time, and demonstrate accountability in the face of uncertainty. It also contains its own shadow.

One of the key considerations of the system design for our new ToC tool is "What are we missing?" Exploring themes of care and contradiction - instead of just control and alignment - is part of our effort to break out of conventional thinking and reveal the "ghosts" that haunt the spaces between metrics and meaning, actions and impact. We believe that what’s often missing in traditional Theory of Change architectures isn’t just a better logic model, or a more efficient way to map objectives and goals. It’s the capacity to surface and hold the unmeasurable.

In our conversations we keep returning to the concept of ritual. It carries emotional heft, but invoking it in product design or system architecture can feel risky, even cringey. That cringe feels like a signal though - that we're brushing up against the unsaid, exploring parts of the ToC space that most software tools ignore or deliberately avoid naming.

The word 'ritual' carries a weird kind of resonance. It speaks of magic, lit candles, the smell and feel of the familiar rendered mysterious. It hints at formality - but also calls for intentionality, for attention. A ritual turns repetition into symbolic meaning, invites shared experience and encourages a more poetic response to a problem.

On one level any business process can be seen as a form of ritual - both contain steps towards some form of transition, both can be taught, documented and refined over time - but the design of a business process necessarily focus on logic over meaning.

For example, the formal process description:

"Identify and engage all stakeholders involved in the initiative, ensuring representation from historically underrepresented or affected groups."

carries the same, more lyrical intent of:

"Open a gathering and invite all who were part of the initiative, including marginal voices."

From a software development point of view, neither explicitly requires a particular implementation or set of steps. The purpose is the same, but the language used invites different workflows - one predicated on gathering data, the other on encouraging agency.

Terms like "identify and engage all stakeholders" fits nicely in a software requirements specification. It uses modern terminology but it flattens the experience, abstracting something deeply relational into a sanitised line item in a workflow. The phrase signals professionalism, neutrality, and comprehensiveness. But it also masks the emotional labour implicit in the processes involved.

From a stakeholder’s perspective, "open a gathering and invite" carries weight that can’t be easily chartered. It might mean being seen after long exclusion, focussing instead on trust-building and listening. It might stir grief, expectation, hope or confidence.

This is not an either / or proposition. Exploring both business process and rituals helps tease out different but complimentary specifications for the software.

Behaviour-Driven Development uses the structure of "As a [actor], I want to [access a feature], so that [a benefit/value is achieved]". Using this we can sketch out a basic user story that meets corporate needs:

As a facilitator, I want to systematically identify and involve historically underrepresented stakeholders and perspectives, so that the engagement process reflects a broader range of experiences and promotes inclusive and equitable outcomes.

The same story can be reframed using language derived from ritual:

As a facilitator, I want to open a space that welcomes those whose voices have long gone unheard, so that our collective gathering begins in honesty, is shaped by a plurality of truths, and honours what has been excluded or lost.

Taking both approaches leans into the Hegelian idea of synthesising new models from the tension between existing ones - in this case the difference in wording between sets of user stories:

As a facilitator, I want to identify and meaningfully invite those whose perspectives have been historically excluded, so that our engagement not only reflects systemic inclusivity, but also begins with an act of repair.

This synthesis represents not just a reframing of requirements - but a deeper, more honest articulation of what the system needs to provide.

We're still left with the overhanging fear that ritual by itself presents a risky proposition: too esoteric for funders, too abstract for users, too soft for strategy. But in a way, that's the point. By loosening our grip on the purely measurable, we allow space for meaning. We're not rejecting structure, but reframing it.

As we continue shaping this system we won't be choosing between business logic and more poetic language. We’re designing for both. Somewhere, in the space between KPIs and candles, we hope to find a better strategy - and a more human way of creating change.

So: What rituals are buried in your workflows? What emotional signals are hiding in your logic models? What ghosts are haunting your Theory of Change?