1. Formal definitions written in the manual

2.  Written specification  External product of the Architect  Details what the user sees  Does not detail what the user doesn’t see  Precession is the key  Multiple catalogued iterations that are dated and given version numbers  Definitions must all agree and state the essentials

3.  Precision beyond English  Formal Notation vs. Prose Language  Describes implementation of hardware and software  Prose and Formal can work together but one must be standard  Testing Formal Definitions by running it on a machine  Experts can easily and quickly have answers that are exact

4.  Good  Precise, Complete, Gaps are easier to spot  Bad  Comprehensibility  Ugly  Lack of precise definitions for particular instances

5.  Weekly Half-Day Meetings  Team made up of Architects, Leads on Software, Hardware, and Marketing  Small smart team can create many solutions to problems  Updates the manual  Annual or Bi-Annual Summits  Accumulated minor problems are dealt with  All project leaders are involved from all sections of the project

6.  Manuals are an important tool to keep things uniform and precise. Shortening the project time and developing a comprehensive knowledge of the project.