For the first part of Run's development cycle, it had no interface builder. It had a default interface, and Run developers hand-coded any new interface developments authors suggested. Much as INDIE developers did with INDIE 1.0, Run developers found this consumed a lot of their time.
However, as more projects were built in Run each with their own set of storyboards, Run developers decided it would be expedient to build an interface builder. In the interface builder, authors get a fixed set of modgits that they can drag off a palette--there is exactly one ASK browser, two question viewers, one evidence list (where static facts are stored; they aren't used to make cases), one ``Start simulation'' button, and so forth. There are no generalized widgets or trigger-like data structures.
Interface scale-up is built into their interface builder, since authors are given basically no rope with which to hang themselves; all the pieces are scalable and are guaranteed to fit together.
Ideally, INDIE, too, would have an interface that is entirely made up of a finite number of modgits, but that wouldn't work for INDIE's domain. To accurately simulate a testing environment, we need a scalable number of widgets that do different things--as mentioned in Chapter 4, a lake temperature test looks different from a gas composition test which looks different from a seismology test. Likewise, we need a variable number of ASK browsers to represent all possible different contexts in which one can ask questions, both to experts and also to scenario agents like patients and witnesses. Finally, authors need to be able to specify any number of notebooks for collecting evidence and supporting any number of exclusive or non-exclusive claims.