Petri Modeling Studio

Problem

Visual modeling tools can become tightly coupled to one notation, one UI framework or one execution model. I wanted a studio that could begin with Petri nets, remain useful as a real editor, and still leave room for additional model types without rebuilding the application around each one.

The project is deliberately local-first. Models should remain inspectable and portable, while the browser and desktop application share the same core behavior rather than becoming separate products.

Architecture

The repository is organized as a pnpm monorepo with framework-independent TypeScript packages for the model, operations and simulation layers. Petri nets live behind a plugin boundary, with a state-machine plugin acting as the first proof that the editor architecture is not permanently tied to one notation.

The interactive shell is React-based and is shared by the browser surface and a Tauri desktop host. Canvas orchestration, editor chrome, runtime helpers and heavier control-rail concerns are separated from the core model packages so UI decisions do not become domain rules.

Modeling and simulation

The Petri side includes deterministic transition firing, marking history, bounded reachability exploration, witness paths and strongly connected component summaries. The editor exposes those results back to the canvas so analysis is not just a detached report: a user can move between a diagnostic result and the model that produced it.

The alternate state-machine workspace reuses the same broader studio direction while supplying its own state/transition editing and execution behavior.

Interchange and output

Models can move through canonical JSON as well as domain-oriented formats including PetriScript and PNML. The editor also exports diagrams as SVG, PNG and PDF with presentation/export settings separated from the normal screen theme.

That separation matters because an interactive modeling canvas and a diagram intended for documentation or academic use have different requirements.

AI as an editing aid

The project includes an OpenAI-compatible orchestration layer for create, refactor, repair and explain proposals. AI output is preview-first: proposed model text and diagnostics are shown before the user accepts a change.

The goal is not to replace the modeling core with generated output. The model remains deterministic and inspectable; AI sits around that core as another editing interface.

Why it belongs here

Petri Modeling Studio brings several strands of my work together: domain modeling, algorithms, editor architecture, desktop/web boundaries, data interchange, interaction design and AI-assisted tooling.

It is also a useful example of a recurring engineering preference: keep the important model independent from the current UI technology, make generated or automated changes inspectable, and design extension points before they become emergency refactors.

The source repository is currently private. This page intentionally describes only the project-level architecture and implementation decisions approved for the public portfolio.