The question that restructured everything

The ontology repair keeps producing consequences I didn't predict. This month's: the entire input layer of the system needs to be split into four types.

The original architecture treated every driver as the same kind of thing. Twenty-five rows in one table. Each row entered the routing the same way, got weighted the same way, and pointed toward levers the same way. Flat and uniform.

The audit kept asking a simple question about each driver: what type of thing is this actually?

"Confidence" is a person-level mechanism. It's about what's happening inside someone's head. If it's low, you address it with interventions that build capability or reassurance.

"Regulations" is a structural constraint. It's about what the institutional environment requires or prevents. If it's the barrier, you address it by working with the rules, designing around them, or negotiating changes to them.

"Group Uptake" is a social signal. It's about what people can observe about what others are doing. If it's low, you address it by making existing behaviour more visible or by creating social proof.

These are fundamentally different types of problem. They operate through different mechanisms, respond to different types of intervention, and require different evidence standards. Treating them as identical rows in one table, distinguished only by their label, is like putting headaches and broken pipes in the same diagnostic manual and recommending the same toolkit for both. They're both problems. They need different kinds of solutions.

So the system now has four construct types:

Behavioural drivers: person-level mechanisms. Confidence, memory, habit strength, perceived cost, risk perception. What happens inside someone.

Structural constraints: system-level barriers. Regulations, resource availability, physical structures. What the environment allows or prevents.

Social signals: group-level influences. Norm visibility, group uptake, identity fit, support from others. What other people do, expect, or model.

Contextual conditions: situational factors that shape the moment. Things that aren't about the person, the system, or the group, but about the specific circumstances right now.

Each type routes to a different family of levers. A behavioural driver routes primarily to levers that change people's experience: make it easier, make it obvious, show them how, make it worth it. A structural constraint routes primarily to levers that change the system: restructure pathways, adjust rules, remove barriers. A social signal routes primarily to levers that change what's visible in the group: make it normal, show it's working.

Here's why this matters in practice. Imagine a team comes to BehaviourKit and says: "People aren't using the new system." In the old flat model, the engine might identify "Task Ease" as a driver and recommend "Make It Easier." Sensible enough. But what if the real issue is that the IT policy requires a cumbersome approval process that nobody has authority to change? That's not a Task Ease problem. That's a Regulations problem. And "Make It Easier" won't fix a policy constraint. You need to address the policy itself, or design a workaround that respects the policy while reducing the friction it creates.

The old flat model would happily route "Regulations" to "Make It Easier" because the mapping table said so. The new typed model asks: is this a behavioural problem or a structural problem? If it's structural, the ease-based interventions are probably not the right family. You need a different set of levers entirely.

The typing also affects how the system handles uncertainty. Behavioural drivers tend to have stronger evidence bases because they've been studied more extensively. Structural constraints often have thinner evidence because they're more context-dependent. Social signals sit somewhere in between. The system can now adjust its confidence levels based partly on construct type, which makes the recommendations more honest about their own reliability.

This is the deepest architectural change BehaviourKit has undergone. And it came from repeatedly asking a question that sounds almost trivially simple: what type of thing is this?

Simple questions, applied systematically, tend to produce the most consequential answers. This one restructured the entire input layer of the engine.

Go deeper into the Building BehaviourKit series: