MIRROR

See what a decision changes. MIRROR turns real-world situations into deterministic simulations, then lets you test what happens when demand, resources, time, or constraints change.

Comment

Inspiration

Every day, people make decisions without being able to see the consequences first.

What happens if a school event gets 200 attendees instead of 100? What if two workers become unavailable halfway through a project? What if demand increases while capacity stays the same?

We wanted to build something that could make those consequences visible.

That idea became MIRROR — a deterministic simulation engine designed around a simple question:

What changes if I change one thing?

Instead of treating simulation like a complicated technical tool, MIRROR starts with a situation described naturally. It translates that situation into a structured model, runs the model through a deterministic simulation engine, and visualizes the resulting changes.

The goal isn't to predict the future or pretend that a simulation is reality.

The goal is to make the relationships, constraints, bottlenecks, and consequences of a decision easier to understand.

What it does

MIRROR turns a real-world scenario into an interactive simulation.

A user can describe things such as:

  • how many entities are involved
  • available resources
  • resource capacity
  • how long the situation lasts
  • rates of work or demand
  • constraints
  • events that happen during the scenario

MIRROR's deterministic parser converts that natural-language description into a structured simulation model.

The simulation engine then executes the model minute by minute, applying explicit rules and state transitions.

The interface makes the result visible through:

  • simulation time
  • queue size
  • completed work
  • throughput
  • resource utilization
  • capacity
  • events
  • progress
  • bottlenecks
  • what-if changes

The most important part is the what-if interaction.

After creating a baseline scenario, users can change conditions such as:

"Remove one worker after 30 minutes."

or:

"Increase demand by 30%."

MIRROR rebuilds the scenario and reruns the simulation so the consequences can be compared against the original conditions.

Everything is calculated locally and deterministically.

No AI. No API calls. No hidden model.

How we built it

MIRROR is built as a Next.js application using React, TypeScript, and CSS.

The architecture is intentionally separated into layers:

Natural-language input
        ↓
Deterministic parser
        ↓
Structured simulation model
        ↓
Deterministic simulation engine
        ↓
State transitions
        ↓
Metrics + timeline
        ↓
Interactive visualization

The parser uses explicit rules to recognize supported quantities, resources, durations, rates, and scenario events.

Those values are converted into a structured model containing concepts such as:

Entities
Resources
Capacity
Rates
Events
Constraints
Assumptions
Limitations

The simulation engine then processes the model as a sequence of state transitions:

Current state
     ↓
Apply rules
     ↓
Process events
     ↓
Calculate capacity
     ↓
Process demand
     ↓
Update queue
     ↓
New state

For example, queue pressure is calculated from the relationship between incoming demand and completed work:

new queue =
old queue + new demand - completed work

Because the engine is deterministic, the same model produces the same result every time.

This also makes the system easier to debug, test, explain, and reproduce.

The interface was built around the consequences of the simulation rather than hiding the calculation behind a generic result screen. Users can see the model, the simulation state, the events affecting it, and the resulting pressure.

Challenges we ran into

The hardest part wasn't creating a dashboard.

It was making the simulation actually mean something.

Our first iterations were too close to a generic scenario interface. They could display numbers, but the numbers didn't communicate enough about why the system changed.

We had to rethink MIRROR around the simulation engine itself.

One major challenge was translating flexible natural-language descriptions into structured data without relying on an AI model.

We solved this by defining explicit parsing rules and supported simulation primitives instead of pretending to understand every possible sentence.

Another challenge was keeping the simulation transparent.

A black-box number such as "your scenario is 72% risky" isn't useful if there is no way to understand where that number came from.

Instead, MIRROR exposes the underlying quantities and calculations so users can trace the result back to the modeled conditions.

We also had to deal with edge cases involving resource changes, timed events, capacity, demand, incomplete simulations, and invalid inputs.

These constraints ultimately helped shape the architecture: the engine should be predictable first, and ambitious second.

Accomplishments that we're proud of

We're proud that MIRROR became more than a static planning interface.

It has a real deterministic simulation loop underneath the UI.

We built:

  • a natural-language scenario parser
  • a structured simulation model
  • a deterministic simulation engine
  • timed scenario events
  • resource and capacity modeling
  • demand modeling
  • queue simulation
  • what-if scenario changes
  • baseline comparison
  • live simulation metrics
  • transparent assumptions and limitations
  • an interactive visualization layer

We're especially proud of the decision to keep MIRROR 100% deterministic.

There is no AI model generating the simulation results and no external API deciding what happens.

That means the system can explain its behavior, reproduce results, and make its calculations inspectable.

For a project about making decisions clearer, that transparency is one of the most important parts of the product.

What we learned

We learned that building a simulation product is less about making impressive charts and more about defining what the system actually means.

A simulation is only as useful as the model underneath it.

We learned to separate:

input → model → rules → state transitions → output

instead of mixing everything together.

We also learned that constraints are valuable.

Rather than claiming MIRROR can accurately model every real-world situation, we explicitly define what the current engine supports and communicate its assumptions and limitations.

Most importantly, we learned that good UX for technical systems isn't about hiding complexity completely.

It's about exposing the right complexity at the right moment.

A user shouldn't need to understand the entire engine to run a scenario, but when they want to know why something changed, the system should be able to show them.

What's next for MIRROR

The current version is the foundation of a much larger simulation system.

Next, we want to move from single-flow simulations toward richer process graphs where multiple stages can interact.

For example:

Orders
   ↓
Payment
   ↓
Picking
   ↓
Packing
   ↓
Delivery

Each stage could have its own resources, capacities, queues, constraints, and dependencies.

We also want to introduce stronger scenario comparison, allowing users to compare multiple versions of the same situation side by side.

Other planned improvements include:

  • visual process graphs
  • deeper bottleneck analysis
  • event timelines
  • step-by-step simulation controls
  • "Why did this happen?" explanations backed by simulation state
  • scenario history
  • shareable simulations
  • exportable decision reports
  • stronger validation and automated test coverage
  • larger and more complex simulation models

Long term, MIRROR could become a general-purpose decision simulation platform for areas such as operations, logistics, education, project planning, and resource management.

The principle stays the same:

Don't guess what a decision changes. Model it, simulate it, and see the consequences.

Built With

Share this project:

Updates

Submission history