Any good architect or analyst must be aware of the fact that architecture models consist of much more than the diagrams themselves, which is why repository-based modelling tools are such an important asset to an architect. A large chunk of the architecture information is never (and should never be) captured in a diagram. A good example of this type of information is definitions. Definitions permeate Enterprise Architecture and obviously they should be stored in the repository along with the artefacts they define. In short, definitions must be available on demand while remaining invisible in all other circumstances. Like any form of documentation, I've found that analysts and architects don't define objects until it is absolutely necessary. Personally I like to generate an Excel spreadsheet from GoAgile, delegate the definition-creation to somebody else, and then import the definitions into the repository using the reverse engineering facility. This process works well for definitions and is almost unavoidable in the case of attribute specifications which cannot really by done efficiently if you work directly on the MAP KnowledgeBase. To do this type of "round-trip-engineering" in MAP I use two components:

An ACG report that generates a CSV file which lists class instances along with their surrogate IDs and definitions.

A column definition file that structures the importing of the generated CSV file (after changes have been made in Excel)