I think I see a way to move ahead here. What if I just plunge into the task, building a fourth "Lower Display" option for the Erasmotron. This fourth option, termed "Graphics" will allow the artist to construct a graphic depiction of the verb using the combination of elements described in the previous essay, and see the results on the screen. There will have to be a bitmap for the verb itself, presenting one or more panels. This bitmap will have to be imported into the Erasmotron and pasted into the image, but it will be moveable by the artist.
One problem troubles me: by integrating all this data, we get to see all the pieces in one place, but shouldn't the artist work separately from the storybuilder? Won't they be tripping over each other? Remember, the bigger and more integrated the file structure, the harder the collapse if the file structure becomes contaminated. Perhaps I should concoct my own private publish-subscribe system of files and filenames. This raises some troublesome technical issues.
Then we simply turn the artists loose and let them use it. They'll come up with suggestions for improvement. As we go forward, we improve the graphics editor. Learn as we go. I'm not the one to be designing graphic systems, and the demands of this environment are so unconventional that we really shouldn't overspecify at this early stage. So let's build a primitive but workable system along the lines of the previous essay and then play with it.