The difference between a library and an engine

I've been sitting with a question for several weeks now, and I think it's time to write it down properly because it's changing how I see the whole project.

BehaviourKit has a taxonomy. Drivers are classified. Patterns are categorised. Levers are grouped. Tactics are organised. Everything has a place in a structure, and the structure has a logic to it. If you showed it to an information architect, they'd recognise it immediately: a hierarchical classification system with cross-references between layers.

Taxonomies are useful. They help you find things. They help you sort things. They help you see relationships between things. Libraries use them. Museums use them. Card catalogues, both physical and digital, are built on them.

But a taxonomy doesn't reason.

When a practitioner comes to me in a workshop and describes their situation, I don't look up their problem in a classification system. I listen to what they're telling me. I think about what type of problem it is. I consider what state the relevant drivers might be in. I weigh up which connections are strong and which are speculative. I check whether there are constraints that would make certain interventions risky. And then I recommend something, with caveats and confidence levels and a sense of how much I trust my own reasoning.

That process is reasoning. It uses the taxonomy as raw material, but the intelligence is in the reasoning, not in the classification.

Right now, that reasoning lives in my head. It's informal, experiential, and pattern-based. It draws on everything I've read, everything I've taught, every workshop I've facilitated, and every case where I saw something work or fail. It's expert judgement.

Expert judgement is valuable, but it doesn't scale, and it's hard to audit. When I recommend a pattern in a workshop, nobody can check my working except me. The reasoning is invisible. The output looks confident. The process that produced it is opaque.

What I'm thinking about, and this is the part that's changing how I see the project, is whether I can move from a taxonomy to an ontology.

The distinction matters. A taxonomy classifies things and puts them in categories. An ontology does that too, but it also defines relationships between things, constraints on those relationships, and rules for how the system should reason about them.

In practical terms: a taxonomy says "Task Ease is a driver" and "Make It Easier is a lever." An ontology says "Task Ease is a behavioural driver. When it's in a LOW state, Make It Easier is the primary lever, with a direct mechanism match and strong confidence. When Task Ease is in a HIGH state, the system should consider whether this is a genuine excess or an adjacent construct, and route accordingly."

That's reasoning encoded in the system rather than held in a person's head.

If I could build that, BehaviourKit would become something qualitatively different from what it is today. Instead of a well-organised library that helps people find relevant patterns, it would be a system that takes a messy input (someone describing their behaviour problem), determines what type of problem it is, checks the state of the relevant factors, considers what constraints apply, and produces a recommendation with evidence, guardrails, and an honest assessment of confidence.

That's not a toolkit. That's an engine.

The word "engine" feels right to me because it implies transformation. You put something in (a problem description) and something different comes out (a recommended action). The system doesn't just store and retrieve. It processes.

I don't know how to build it yet. The connection chain is a start, but it's too linear and too dependent on the user making choices at each stage. The contradiction matrix idea, which I've been reading about in the TRIZ literature, might offer a structural model. The evidence layer needs to be much more formally structured. The safety considerations need to be codified rather than intuitive.

It's a large undertaking. Possibly the largest I've attempted with BehaviourKit. But I think it's the right next step, because everything I've built so far has been moving in this direction. The patterns, the drivers, the chain, the evidence, the state model. All of it is raw material for an engine that doesn't exist yet.

Time to start building it.

Go deeper into the Building BehaviourKit series: