Consulting innovation · Formal technique, applied at scale

Behaviour trees

End-to-end system behaviour in a single formal model. Missing branches become visually obvious, and people who thought they agreed find out whether they actually do.

Why

Requirements documents scatter behaviour. A requirement on page 2 interacts with one on page 22 and another on page 202. User stories scatter it differently, across epics and sprints. Either way, no reviewer can hold the whole picture in their head, so reviews check sentences instead of behaviour, and the gaps ride through to build.

How

Behaviour trees are a formal graphical notation for decomposing system behaviour. Every requirement is translated into the tree, and the trees compose into one end-to-end model. You can follow a business process all the way through the system in one artefact.

Branches are explicit. If the model shows what happens when a condition holds, the absence of the other branch is visible as a hole, not as silence. "What if it is not that condition?" stops being a question someone has to think to ask.
Playback beats inspection. Walking stakeholders through the tree tests their shared understanding, sentence by sentence, against a picture none of them wrote.
Research from the behaviour engineering programme at Griffith University, where the technique originated, reports 30%+ more severity-1 defects found than typical inspection approaches. Where no formal inspection exists at all, the gap it closes is wider still.

The property that matters: the missing alternative branch is a visible hole in the picture, not an absence in prose.

A real behaviour tree for an integrated alert monitoring system: hundreds of composed nodes covering viewing, filtering, selecting, and exporting alert behaviour end to end — A real tree from the water utility IoT programme's alert monitoring system. Green nodes traced cleanly to requirements; orange nodes marked gaps and ambiguities to resolve. The scale is the point: this is one screen of behaviour held in one model.

What

First application: a state education department programme where six weeks of subject matter expert review of the requirements had already finished. Within minutes of playing back the behaviour tree built from those same requirements, one SME objected that the model was wrong, because the requirement said X. Another disagreed: it said A. Both had signed off on the same words while reading them as substantively different specifications. Six weeks of inspection had not surfaced that. Minutes of playback did.

Applied again on a city-wide IoT programme for a state water utility, with acoustic and high-speed transient sensors deployed across a city centre for proactive wear detection. Modelling end-to-end behaviour against the requirements surfaced functionality promised in the vendor's materials that had not actually been built into the product base. Brochureware, caught on paper instead of in production.