Event Modeling usually comes before the code. For teams with existing systems, you can turn it around and do Inverse Event Modeling: the model gets built from the code, and AI keeps it true. Hereās how Inverse Event Modeling works, and why detecting drift is nothing technical.
The Code Is the Source of Truth. Sure.
Engineers LOVE to say the code is the source of truth. Iāve said it myself, many many times in my career. And it isnāt even completely wrong.
But your product owner will never open the code to understand a process. Thatās a fact. Neither will your business analyst, your head of operations, or the new team lead who joined last month and wants to know how a refund actually works in your system.
They will ask engineers to create a one-pager to explain it, as the existing documentation is hopelessly out of date.
Nothing is worse than outdated documentation. Itās worse than having none, because people trust it. And once itās gone or wrong, everybody who canāt read code has exactly two options left: ask an engineer, or guess.
You need a place to go to.
Where Event Modeling Pays Off the Most
Many of my clients love Event Modeling. And the biggest return on investment always shows up in the same place: when you adapt your processes.
You model first. You see the impact of a change before anyone writes a line of code. And then you decide, based on real evidence instead of gut feeling.
Thatās still what I teach. Itās still what I believe. When a team can work that way, nothing else I know comes close. But for most teams, thatās just not possible right away.
Not Every Team Can Just āEvent Modelā
They have existing processes. They have existing codebases, often years old, sometimes decades. They canāt stop everything and ājust Event Modelā. Before they see any value, they first have to document the system they already have. Thatās a big effort, and itās easy to understand why many teams never start.
And even the teams that do invest run into the next wall.
I see this pattern a lot. A team puts real time into modeling. The workshop produces great insights, the kind that make people say āwe never knew it worked like thatā. Everyone leaves aligned.
Then, at some point, model and code start to drift. Slowly. A field gets added here, a rule changes there, a flow gets reworked and nobody updates the board. Under pressure - you start with the code. Drift is a real problem, in the architecture and in the model.
With AI, and the rate of change weāre seeing right now, it gets much worse, not better. An agent can change more in a day than a team used to change in a sprint. Nobody updates a model at that speed by hand.
Eventually someone opens the model, finds something that doesnāt match, and quietly stops trusting it. They go back to reading the code. And the product owner is locked out again.
Inverse Event Modeling - Turning Event Modeling Around
So hereās what we do instead.
We do not use Event Modeling for discovery. We use Event Modeling as documentation of process. And we use AI to keep it up to date.
I know that sounds strange coming from me. Iāve spent years telling people to model first. But the method itself doesnāt care which direction you go. An Event Model is a picture of a process that business people and engineers can read together. That picture is valuable whether you draw it before the code exists or long after.
For teams with an existing system, after is the only realistic starting point. So thatās where we start.
How It Works
The idea is simple. The details are what make it trustworthy.
Point the agent at your codebase. You let it build the Event Model from whatās actually there. This takes a few iterations depending on the size of the codebase. We start high level, so we know which flows exist at all. Then we go flow by flow, each one small enough that a human can look at it and say whether itās right.
Record the evidence. For every step, the agent records why it mapped the code the way it did. Where in the code it found the behavior, and which decisions it made along the way. Call them Auto-ADRs if you want. The model isnāt a guess dressed up as documentation. You can check every box on the board against the code it came from.
Set a watermark. Every analysis records what it was based on, typically a git commit hash. The model always knows which moment in the life of the code it describes.
Run process-drift detection continually. From then on, you donāt rebuild the model. You look at what changed in the code since the watermark, update the model where the process changed, and get notified when the code drifts away from the process.
This works for any codebase - especially legacy CRUD codebases. Those are exactly the systems where the process is hardest to see. Itās buried in update statements and if-branches, and nobody has written it down in years. Thatās where a model helps the most.
Detecting Drift Is Nothing Technical
And this is the part that most teams get wrong.
When people talk about drift, they almost always mean architecture drift. Modules. Dependencies. Layering. Which package is allowed to call which. What tools are being used. There are good tools for that, and itās all important.
But in the end, nobody cares.
Your business doesnāt care whether a dependency points in the wrong direction. Your product owner doesnāt care which module a rule lives in. What they care about is whether the system still does what the business needs it to do.
Detecting drift is nothing technical. Thereās only one question that really matters: does the architecture still implement our business process (including all the non-functional requirements)?
If the answer is yes, I donāt care too much about the implementation itself. If the answer is no, every green dashboard in the world wonāt help you.
Thatās why we call it process-drift detection. The behavior is what you protect. The structure is just how you got there.
It Works in Both Directions
Once the model exists and stays true, something interesting happens. It starts working in both directions.
Forward, you can add the plan to the Event Model and use it as the spec for new features. You document the intent, and the agent creates the tickets and the implementation from it.
Inverse, you get your existing processes documented from the code, without stopping the team for weeks to write it all down by hand.
And most importantly, you get notified when the code drifts from the process. Not months later, when someone happens to notice. Right when it happens.
The sketched model becomes a blueprint. The agent knows how the codebase maps to the model, because the evidence is recorded for every step. Trust in the model stops being something you hope for. Itās something you check, like a test.
A Place to Go To
So let the code stay the source of truth. For engineers, it might be forever.
The model becomes the place everyone else can actually read it. And it stays true, because itās checked against the code continually instead of drawn once and slowly forgotten.
For the teams that could never ājust Event Modelā, that changes everything. They donāt need a big upfront effort anymore to get started. They donāt need discipline alone to keep the model alive.
You donāt have to start from zero to start modeling. Start from where you are.
Links
- EM-Studio
- EM Spec
- EM Build Kits
- EM Cheatsheet
- Event Modeling Use-Cases
- Explore Real World Event Models
Join the Agentic Engineer Program
Apply Spec-Driven Development Hands-On - Event Modeling, Event Sourcing, and AI Engineering with autonomous agents.
Book a Call Today
Want to talk through how Event Modeling could work for your team or project? Letās have a quick, no-pressure conversation.