Building Realistic Simulations: A Research-Driven Approach
Process simulations are only valuable if they're realistic. A simulation that looks impressive but doesn't capture how things actually work can lead to bad decisions and failed implementations. When we decided to create the first very realistic simulation for the Universal Automation Wiki, I knew we needed a proper methodology.
This post walks through the approach we developed for building the "Parkside Bakery" simulation, a completely fictional, small commercial bread bakery with realistic timing constraints, resource limitations, and operational complexities. This methodology can be applied to any domain where operational accuracy matters.
The first step I took was to use Claude Sonnet 4.5 to generate a plan. For LLMs, context is everything, to ensure that this instance of Claude knew exactly what its task was, it had access to our meeting notes and the code for the playground itself.
You can read the full implementation plan that guided this process.
Why Traditional Approaches Fall Short
Most simulation projects take one of two paths, both problematic.
Some start with theoretical models and ideal conditions, then layer on constraints. These simulations work perfectly on paper but break when confronted with reality. Other simulations are built based on what seems reasonable rather than what actually happens. Without grounding in real data, these reflect our assumptions and blind spots rather than reflecting what actually happens.
Our methodology addresses both issues by starting with deep research into actual operations and validating every aspect against real-world evidence.
The Four-Phase Approach
Phase 1: Deep Research Foundation
Understanding what actually happens in the real world is the foundation. For our bakery simulation, this meant answering questions like:
When do commercial bakeries actually start operations?
How long does sourdough really need to proof in a commercial setting?
What's the actual usable capacity of a deck oven, not just the marketing specs?
This initial research was followed by targeted deep dives into equipment specifications, recipe details, and financial realities. The result was a collection of research documents grounded in real bakeries, with citations for each piece of data.
Phase 2: Research Synthesis and Validation
Raw research needs to be transformed into a coherent operational model. I used Claude Pro to synthesize the research into a unified model for "Parkside Bakery", a fictional but realistic 4-person bakery.
The synthesis alone wasn't enough though. I ran the operational model through multiple validation passes checking for internal consistency, realism, completeness, and red flags. Does oven capacity actually support claimed daily production? Are profit margins realistic for this industry? Is equipment appropriate for the scale?
Download the full operational model here (or as a word document)
Phase 3: Implementation in UAW
With a validated operational model, the next step was translating it into the UAW simulation format. This is where the Universal Object Model and the multiple day types feature become important.
Real businesses don't operate the same way every day. A commercial bakery's Monday looks different from its Saturday. Before implementing the full simulation, we added support for multiple "day_types" to the Playground. This allows simulations to model weekday operations, weekend operations, holiday operations, and maintenance days.
The implementation follows the Universal Object Model with objects definition, day type configurations, tasks with real timing, and economic tracking.
Phase 4: Simulation Testing and Analysis
Once implemented, the simulation needs to be run and analysed to verify it behaves as expected and produces realistic results.
The UAW Playground provides real-time visualization as the simulation runs. The timeline view shows all tasks executing across the day with color-coded actors and equipment states. Object state panels track inventory levels and equipment states live. The financial dashboard calculates costs, revenues, and profit margins in real-time.
We validate across several dimensions. Does the timeline show realistic patterns like a busy early morning and steady midday production? Are actors working reasonable schedules or racing constantly? Does total daily production match operational model targets? Are financial metrics within industry ranges?
What Makes This Different
Every number, every timing constraint, every cost figure can be traced back to real-world research. When the simulation says task A takes x minutes, that's based on equipment specifications and operational reports, not a guess.
The simulation passes through multiple validation gates for internal consistency, realism checks, research traceability, and operational testing.
This level of realism enables use cases that superficial simulations cannot support. Entrepreneurs can test their bakery concept before investing. Existing bakeries can model changes before implementing them. Students get exposure to realistic operational constraints. Investors can stress-test financial projections against realistic operational models.
Adapting to Other Domains
While we used a commercial bakery as our example, this methodology applies to any domain where operational realism matters: manufacturing, healthcare, logistics, retail, software development.
The key steps remain the same: deep research, synthesis, validation, implementation, testing, and documentation.
Tools and Technologies
Our methodology uses three complementary AI systems.
Gemini Deep Research excels at comprehensive research across multiple sources, synthesizing information from diverse documents, and providing citations with confidence levels.
Claude are great at synthesis and coherent narrative creation, excellent for critical analysis and validation, and strong at identifying inconsistencies and gaps.
Claude Code and Gemini 2.5 Pro (via AI Studio) validates JSON syntax and structure, checks logical consistency in timing and dependencies, and automates testing and analysis scripts.
The Universal Automation Wiki Playground provides an interactive simulation editor with real-time validation, visual timeline for understanding task sequencing, economic analysis tools, and support for multiple day types.
Lessons Learned
Building this realistic simulation taught me a few valuable lessons:
Research quality varies dramatically
The most valuable research came from actual business case studies with numbers, equipment manufacturer specifications (real specs, not marketing), industry interviews and operational reports, and government labour and financial data.
Initial assumptions are often wrong
For example, I assumed bakeries might start around 5-6 AM, but many actually start at 2-4 AM, and I thought oven capacity equals manufacturer specs, but it's actually 10-20% less in practice.
Small details compound
The difference between a 3-hour versus 4-hour proofing time cascades through the entire schedule. Getting these details right is the difference between a useful simulation and an expensive mistake.
Additionally:
The ability to model different operational modes with multiple day types dramatically increases simulation utility. Real businesses adapt, and simulations must too.
Even after extensive validation, running the simulation reveals emergent behaviours and unexpected bottlenecks.
Getting Started
Want to build ultra-realistic simulations for your domain? Start with research before touching the simulation editor. Invest time understanding real operations by finding 3-5 real examples with detailed information.
Build a research base that synthesizes your findings into operational models, financial models, equipment specifications, and task dependencies.
Implement incrementally by starting with the core process flow and adding detail at each stage. Test carefully by running your simulation and analysing results against research-based targets. Document thoroughly by linking every element to supporting research and noting confidence levels.
Share and iterate with the UAW community to help improve your simulation.
Conclusion
Building realistic simulations is complex, but necessary. The difference between a simulation grounded in research and one built on assumptions is the difference between a tool that supports good decisions and one that supports confident mistakes.
Our research-driven methodology, supported by powerful AI tools and the flexible UAW platform, makes it possible to create simulations with genuine operational fidelity. The multiple day types feature enables modelling real operational variety, while comprehensive validation ensures every element can be justified.
The goal isn't perfect simulations. Perfect is almost impossible when modelling messy reality. The goal is honest simulations that accurately represent what we know, clearly document what we've assumed, and help users understand both the possibilities and the limitations.
Resources
How You Can Help
The Universal Automation Wiki is just starting, and we need your help, feedback and input. Here's how you can get involved:
Explore the project: https://universalautomation.wiki
Join the conversation: Suggest improvements and share your domain expertise
Contribute on GitHub: https://jamiem.me/uaw-github
Contact us: contact@universalautomation.wiki
Universal Automation Wiki is an independent open-core project being developed by Jamie Matthews and supervised by Dr. John Bustard of Queen's University Belfast.
