For a long time, I have been writing about fragments. About starting execution too early. About governance models that fail. About building blocks. About understanding before coding. Today I want to put all puzzle pieces together.

Let’s take a very concrete example from Life and Health. Imagine someone in the business comes with an idea. Not a fully specified feature, just an idea. Maybe the operations team struggles with manual corrections when a policy is cancelled right after inception. Maybe they want a controlled capability to cancel a policy from inception without triggering downstream commission payments or document generation. Or maybe the market demands a smoother reversal flow during the cooling-off period. At this stage it is still vague.

Before anything else happens, Product Management has work to do. Is this a real value driver? Is it solving a measurable pain? Does it fit into the roadmap? If the answer is yes, it enters the backlog. And now the interesting part begins.

We schedule a modelling workshop. Not a handover. Not a refinement meeting. A workshop. We invite everyone who has a stake in this specific business activity, business, engineering, QA, compliance, security, sometimes operations. There is no “owner” of the workshop, only a moderator. The business person tells the story. What does “cancel from inception” really mean? Under which circumstances? Before first premium collection? After documents were generated? What happens to commissions? What about reporting? What about audit trails?

Others ask questions. They challenge assumptions. They point at consequences. It can feel uncomfortable. That is normal. Very quickly, hidden complexity surfaces. We capture everything as an EventModel. We start with facts, events that have already happened. We identify the actor initiating the cancellation. We sketch the UI they interact with. We describe the state change. We list the business rules. And we do not stop at the happy path. What if the first premium was already collected? What if a commission was already paid out? What if the cancellation request comes after the cooling-off period? What if the policy was already reported to a risk partner?

Every slice we model is exactly one of four types: a state change, a state view, an automation, or a translation. Nothing exotic. Nothing mysterious. The full activity becomes a sequence of these slices.

Once the workshop ends, a small core group refines the model. They close information gaps and call people back if something is unclear. When they are confident that the model is information complete, the larger group reconvenes, but only after everyone has reviewed it in advance. Then we align. We agree that on this date, this is what we know, and we assign a version. Not because change is forbidden, but because learning is explicit.

Now something interesting happens. Because we model at the leaf level of the business process hierarchy, we can define permissions on the activity itself, not on database fields, not on abstract entitlements, but on the activity. For example, who is allowed to cancel a policy from inception before the first premium is collected? Who is allowed to do it after premium collection but before commission payout? Who is allowed to reverse such a cancellation? These are questions business understands. Roles are defined around activities, and business takes ownership of them.

Compliance suddenly has a clear map. They can review the set of activities a role is allowed to perform and check separation of duty. Is someone allowed to both initiate and confirm a cancellation? Is that acceptable? If not, the model makes it visible. Security can trace exactly where personal health data or financial data enters and leaves the system. Hot paths are not hidden in code; they are visible on the model. QA does not have to guess what to test, because every business rule is explicitly written as a scenario on the slice where it belongs.

And estimation? It becomes simple math. Each slice has comparable complexity. No poker games. No theatre. The EventModel becomes specification, documentation, backlog, project plan and status board in one artifact. White slices are ready. Grey are in progress. Green are done. Red means blocked. With one glance you see reality. No status slides required.

Now, where does resistance appear? Often in subtle places. People are used to being gatekeepers, being the one who knows, being the interpreter between worlds. When everything becomes visible, that role changes. Shared understanding reduces dependency on individuals, and that can feel exposing.

But in my experience, something else happens over time. Trust increases. Discussions become factual. Governance is no longer an external force; it is embedded in the design. We stop arguing about interpretations and start improving the model.

And that is when modelling stops being a technique. It becomes how an organization thinks.

I am curious how others have experienced this shift, especially in regulated environments like Life and Health.

More thoughts to come…

Originally published on LinkedIn (2026-02-13): https://www.linkedin.com/pulse/clarity-instead-gatekeepers-gabriel-n-schenker-jgc4e