Run application development focuses on its domain model very heavily. Each sub-problem is called a ``situation.'' Situations have various available actions. An action has results, and those results modify a list of variables. Each time a student selects an action in response to one of the active situations, it updates the variables and then checks to see if that will trigger any events. An event might be something that maintains the domain model over time, such as:
IF there is a fire in the living room AND the fire is at level ``small'' AND there are no firefighters in the room, THEN the fire is now at level ``large.''
An event might also be a ``macro''-level event, like a rescued family member running back into the burning house to rescue the cat:
IF the mother is not being restrained AND has been rescued AND the cat is still in the house THEN activate the situation ``mother ran back into the house.''
Run developers have supported scalability in Run model designs (i.e., picking a good abstraction for their domain with variables, designing good event triggers) through direct contact, by acting as mentors to teams using their tool. INDIE doesn't have model variables and complex rules modifying variables because it doesn't need to represent time. The only variable that affects what happens when a button is pressed is what scenario students are currently working on, so we can be assured that our domain model will stay simple.
Run's simulation rules are more like INDIE's critiquer rules, and Run has many of the same triumphs and problems that INDIE has. By providing a generalized boolean and set algebra constructor to their authors, Run developers have made it possible for authors to represent their domains exactly. On the other hand, it is quite easy to write an incomplete rule set, or a nonsensical one (such as a fire team reporting on a new problem they are facing even after they have been killed).