In EM development based on modelling with definitive scripts, the primary product is a text file that contains the sequence of definitions as they are conceived by the developer. Viewed in one way, this will represent one particular state of the construal under development. From the modeller's perspective, there will typically be many ways to interpret the current form of construal. Some will be associated with familiar ways of interacting with it and interpreting the response. Others will correspond to variants of the construal that can be derived by modifying dependencies, or by selecting specific subsets of dependencies. This script traces stages in the development from the simplest and most primitive versions of the construal to the most sophisticated and up-to-date. Characteristic features are:

• variants of dependencies associated with a single observable as it evolves; these take the form of sequences of redefinitions of a single observable.
• definitions of key functions that are used to frame dependencies; these appear on the RHS of definitions, and may also be redefined as the script is embellished
• contexts that are establishing phase-by-phase in the development; these are associated with groups of extant definitions that are most appropriately considered together. A context may be associated with staging posts in the development that correspond to versions of the construal that are loaded prior to the next phase of development. It may also be associated with a subscript that selects those observables that are most relevant to a specific focus of attention within the global context.
• actions that represent ways in which agents interact in the current context; these agents also typically evolve as the context changes. Each action is represented in the script by a triggered procedure: within the script there may be a sequence of redefinitions of a single procedure.
• comments that document the evolution of the construal, the modeller's understanding, the referent and the context. Comments are often associated with digressions in the script that are also commented out - these correspond to promising leads or dead ends that have been pursued by the modeller, but are subsequently suspended or abandoned.

A useful parallel may be drawn with the way in which a walk is devised: possible tracks are explored, and may either prove intractable or interesting but potentially not consistent with the vision of the walk as-of-now being planned.

From a traditional programming perspective, the development script is an unnecessarily complex object. The multiple definitions of observables, functions and procedures are an annoyance, as it can be hard to identify which definition is the last / most topical. Many EM developers have preferred to use traditional forms of version control in conjunction with a conventional file system to record development and versions. Loading a file of definitions is different in character from developing these definitions in the stream of thought. The process of reflection that accompanies construction is potentially very significant and fruitful, and is of the essence in EM.

The premise of the SEEM is that the development script is an object to be preserved rather than eliminated. The SEEM aims to provide means to manipulate the development script so that it is more intelligible and accessible. It can then be more readily exploited through extension and revision. Note that the development script represents a record of the sequence of significant stages in the construction. This is a rough record, not fully informed, but devised to the best of the modeller's ability, given that the script construction is a process of 'understanding forwards'. An important aspect of the modeller's activity is that conceptually "trivial" steps - such as the correction of syntactic errors, or gross semantic oversights / misconceptions in formulating functions, definitions and actions are overwritten in the development script, rather than recorded. On the other hand, where the developer is revisiting an aspect of the construal in such a way as to significantly enrich it, but in a way that reflects insight gained from other development of neighbouring features etc (cf. "spiral" development), both the original and the subsequent variants need to be recorded, and the definitive script provides essential context for recording these. Similar considerations apply to comments.

In typical use of traditional EDEN, there is only one state of the construal that is the focus of current attention. To set up this state, the modeller simply loads the entire development script, and interprets the experiences afforded by the resulting construal. In the SEEM it is to be expected that several viewpoints on the same construal may be extant at the same time. These could be displayed in parallel webpages for instance. It has proved very difficult to handle multiple interpretations in the traditional EDEN environment. Switching between one interpretation and another is treacherous for the same reasons that managing the development script is hard. Tasks that we might wish to carry out using the SEEM include:

• resetting the construal to different stages in the development
• extracting subscripts for testing specific networks of dependencies in isolation
• simulating the development step-by-step
• extracting subscripts for use as templates for extension
• sanitising the script to produce a more concise and focussed form.

JS-EDEN offers a promising platform for SEEM implementation. We envisage introducing a definitive notation in which the observables are themselves scripts. The internal representations of script values will be JS-EDEN objects - including HTML collections etc. We can then provide JS-EDEN operators on scriptvars that reflect the underlying representations. Acivities to be supported include:

• the selection of segments of the script based on range variables in JavaScript
• manipulating families of definitions developed using the 'definition factory' environment
• re-organisations of scripts, such as involve organising latest versions of definitions of observables ordered so as to be interpretable without error
• making extracts from scripts consisting e.g. of all functions, procedures, definitions, assignments.
• selecting families of observables derived by dependency relations - such as all observables directly dependent on a given one
• generating interface components, such as might comprise e.g.:
  • checkboxes to specify groups of definitions to be interpreted in the script
  • allow the contents of the picture observable to be specified using a GUI
  • slider bars to change the values of scalar observables.