System Studio
A tool that turns what a team knows about its process into a model everyone can see, check, and improve together, then matches that model to well-studied problems from operations research.
Why I am building it
When I start with a new team, the most valuable thing I produce early is a clear picture of how its work actually moves. That picture usually lives in my notes and in people's heads. System Studio makes it a shared, living model, so the team can see what is known, what is assumed, and what still needs a number.
Industrial engineering and operations research have proven methods for queues, scheduling, inventory, routing, maintenance, and quality. The hard part is recognizing which of those problems a real process is an instance of. System Studio is my attempt to make that recognition fast and visible.
What it does
- Map. An interactive diagram of the system's parts and how work moves between them.
- Numbers with sources. Every number records whether it was measured, observed, stated, estimated, assumed, or left as a placeholder, so the team can see how much of the model rests on real data.
- Rules and states. Limits the system must respect are marked as fixed, such as safety or contracts, or as the team's own choice. A team's choice that causes pain is flagged as worth questioning.
- Listen. Paste meeting notes or add a document, and the AI suggests changes to the model, each with a quote from the source and a reason. Nothing changes until a person accepts it.
- Match. The AI compares the model with a catalog of 41 known operations research problems and shows which parts of the map play which role, which numbers the standard method needs, and which questions to ask next.
- History. Every change is saved with a plain description, and any earlier version can be restored.
Where it stands
System Studio is a working prototype that I have tested on example systems. It has not yet been used with a client team, and the next steps are question lists that guide each conversation, analysis using the matched problems' methods, and listening during live meetings.
If your team has a repeated process that never quite runs the way it should, I would welcome the chance to model it with you. A real system is the best way to find where the tool falls short and to make it useful.
Technology
- A React and TypeScript web app with React Flow for the diagram.
- A Python FastAPI server with SQLite storage that refuses saves which would leave broken references or overwrite someone else's work.
- Listening and matching through the Anthropic or OpenAI SDK with structured output, and a problem catalog that can be extended by hand.
Want to see your process as a system?
Bring a repeated process that frustrates your team. We will map it together, and you will leave the conversation with a clearer picture of where time and quality are lost.