Reverse engineering existing software with Event Modeling

A NEXUS Event Model describes what a system does at a semantic level — independent of any implementation language or existing codebase. This property runs in both directions. A system can be designed forward from an Event Model. A system can also be analyzed backward to derive an Event Model from existing code.

The Reverse Engineering Process

Existing software has an implicit Event Model embedded in it. Every system that accepts input, processes it, and produces output has commands, events, and projections — even if nobody called them that when the system was built. The design is there. It is just not explicit.

Reverse engineering with Event Modeling makes that implicit design explicit:

Analyze the existing codebase to identify what the system does — what inputs it accepts, what state changes it produces, what outputs it delivers. Translate those behaviors into Event Model language: commands that trigger state changes, events that record those changes as facts, projections that derive views from the event history. Draw the timeline in Penpot. The result is an Event Model that describes what the existing system does — not as a line-by-line translation but as a semantic description of its behavior.

AI-assisted analysis makes this tractable. An AI given the codebase can produce a candidate Event Model. Humans refine it. The AI does the pattern recognition across potentially large codebases; the human provides judgment about what the model means and whether it correctly captures the intent.

From Derived Model to New Implementation

Once the Event Model is derived, it is language-agnostic. The existing system's implementation language is no longer a constraint. The model can be rendered into any target language using the NEXUS rendering process.

For NEXUS this means: analyze an existing system in any language, derive its Event Model, add your constraints and desired changes, render into F#. The result is not a port — not a line-by-line translation that carries the original language's idioms and assumptions into F#. It is a clean rendering of the derived design into idiomatic F# following NEXUS patterns.

The derived model is also an opportunity to improve. The existing system's behavior is the baseline. Limitations discovered during analysis become LOGOS limitation topics. Desired changes become requirements. The model is extended to cover what the system should do, not just what it currently does. The render target implements the improved design.

Contributing Back to the Original Project

The derived Event Model is potentially valuable to the original project even if you never share the new implementation. A complete Event Model of their own system reveals things the original authors may not easily see from inside the code:

Broken paths — sequences that should complete but have gaps. A command that produces no event. A projection that consumes events that are never produced. These are structural gaps visible in the timeline that may not be obvious from reading code.

Missing projections — events that are produced but nothing consumes. State changes that happen but never inform any consumer. Dead weight in the system.

Anti-patterns — commands that produce multiple events, projections that mutate state, external events that bypass the command layer. Each is visible as a structural anomaly in the model.

Scope clarity — what the system actually does versus what it was intended to do. Gaps between intent and implementation that accumulated over years become visible when the whole system is modeled as a timeline.

Contributing an Event Model to an open source project is contributing understanding — potentially more valuable than a code contribution because it gives the project a design artifact they can use to reason about everything that follows.

The Open Source Knowledge Problem

Many open source projects are functionally inaccessible to new contributors not because the code is bad but because the reasoning behind it is gone. The original authors moved on. The decisions that shaped the architecture were never recorded. A new contributor must reverse-engineer not just what the code does but why — and that knowledge, once acquired at great cost, lives only in their head until they too move on.

The reverse engineering process that produces an Event Model simultaneously begins solving this problem. The conversations that shaped the model live in LOGOS. The limitations discovered during analysis are recorded there. The decisions made about what to change and why are there. By the time the Event Model is complete, the project has the beginning of a knowledge base it never had.

See: NEXUS → Insights → Event Modeling and open source projects.

See Also

• Event Modeling as the design foundation
• Language-agnostic design — one model, many implementations
• AI-assisted implementation
• NEXUS → Insights → Event Modeling and open source projects
• NEXUS → Insights → README