Every model has associated actions. Whenever you perform an action that changes the model, through the LSM, the action list is updated. Whenever you open a model, the action list is re-run.
The actions viewer is available under the Action Lists dropdown.
There are 3 tabs in the Actions viewer which indicate the differences between the codebase structure and the model. There is also an export 
command available (see below). The action list is a sequence of steps to turn one structure into the other. The class map is a mapping of class names from their codebase location to the model location. The refactorings are changes to the internals of classes. If you were to apply the refactorings and then the class map, the result would be the same as applying the sequential action list - i.e. the current model.
You will use the information in each tab depending on whether:
- you are aligning your codebase containment structure with the model (class map),
- keeping your implementation code consistent with a separate architectural model (refactorings),
- or both (action list or map+refactorings).
Action list.
This is the sequence of actions that have been performed on the model so far.
Actions are initially listed at the granularity you performed through the UI. For example if you moved 10 items, you will see a corresponding action "move 10 items to newplace". If you undo the action, all 10 items will be moved back to their original location, and the action removed from the top of the list. At any point you can "expand" such composite actions into their elemental item-by-item actions from the action list menu.
Also, if you perform actions in a sequence that effectively means that some interim actions are redundant (e.g. move a.A to b, move b.A to c), these will be shown in the complete sequence. You can "consolidate" these redundant actions (e.g. replace 2 actions with a single move a.A to c). Whenever you share a model, it is the expanded and consolidated action list that is exported. This means that you can feel unencumbered in moving items to temporary locations until you figure out where they ultimately belong.
Whenever you open a model, the action list is rerun on the initial model as defined by the project setting. If any actions cannot be performed, they are grayed out. Typically this occurs when you have shared the actions and they have been implemented on the code.
The names of any items in an action list assume that previous actions have been performed. For example if you move a.b.MyClass to b.c, and then move a static method out of MyClass into another class, the action will be in the form "move method from b.c.MyClass to ...". This is natural while you are working within Structure101 Studio, but it is relevant if you are exporting the action list for implementation, particularly if actions will be performed by multiple developers.
class map
The class map lists any classes that have been "moved". That is, they are in a location that is different from their location in the initial model as defined by the project settings. Effectively this means that they are in a different location in containment hierarchy than they were in the as-implemented codebase structure you started with (e.g. the package structure).
The class map can serve as a list of relocation actions you need to perform if/when you wish to align your codebase structure with the model. For example you might move classes to
Refactorings
Where the class map indicates where classes have been relocated, the refactorings indicate where the classes themselves have been modified in the model. Separating the refactorings from the full list of actions gives you the option to keep the implemented code consistent with your architecture, without (or before or in parallel with) aligning your codebase structure with the model. In support of this, the names of classes in the refactorings list use their actual path in the codebase, not the current location in the model.