To have the student learn about a domain, authors need to be able to model it in software. A solid model gives students the opportunity to interact with ``the real thing,'' so to speak, and gives the GBS a good basis for remediating the student. Authors then need tools to let them model the world, provide feedback to students, and let students have access to experts.
More importantly, the model is important for scale-up. If a program is just a collection of screens with buttons connecting them, each addition of a scenario or a test would require linearly more information. Instead, we'd like development times where building the first scenario or test takes the longest, and building each additional scenario or test costs asymptotically less.
It would seem natural, then, to have students work on a model before they build an interface so that their program scales up quite well. The first version of INDIE to use this approach ran into problems with how authors interacted with the tool, most specifically with building this model representation of the domain. These problems revolved around who builds GBSes and for what purposes they are built.