People’s knowledge does not only consist of abstract, generally applicable principles, but also of concrete, specific experiences.  This applies to the field of architectural design as well (Kolodner 1993). Case-based reasoning (CBR), takes the experiential approach to problem solving.  The main idea is that analogies can be drawn between past situations, generally known as cases, and the current problem being solved.  Because of designers’ wide use of experiential knowledge, CBR can be a helpful strategy to use in building computational tools that aid designer.
The general aim of this research is to investigate and gain knowledge about if and how Case-Based Design (CBD) could be usable as a tool for architects, both in education and in the practice. 
On the conceptual basis, CBD is believed to hold great promises for the field of architectural design, both on the practical as well as on the educational levels. Therefore many CBD tools were developed within the past 15 years.  While some of them targeted the educational architectural design process such as PRECEDENTS (Oxman & Oxman 1993), EDAT (Akin et al. 1997) and DYNAMO (Heylighen & Neuckermans 2000); others targeted the practicing architects, such as ARCHIE-II (Domeshek & Kolodner 1993), CADRE (Hua, Faltings, & Smith 1996), SEED (Flemming, Coyne, & Snyder 1994), FABEL (Börner 1998) and IDIOM (Lottaz 1996).
Among these promises is the easiness of using CBD to acquire the design knowledge. While it is hard and time-consuming to induce the rules by which a design was developed, or build a model of the different design tasks and processes architects go through, telling a story about that design is not as difficult.  Thus, CBD bypasses the bottleneck of design knowledge acquisition that is needed for model-based and rule-based approaches.
Many of the concepts presented in this research were implemented in a case-based system called MONEO (a Latin word meaning to warn, admonish, remind, advise, or instruct), which enables architects to retrieve designs of residential units based upon a graphically represented query. MONEO, however, differs from previous systems in many ways.  While systems like “Archie” use textual case representation in building their case library (Domeshek & Kolodner 1992; Domeshek & Kolodner1993; Domeshek & Kolodner 1997), MONEO uses graphical representation.  This approach is especially convenient considering that architects usually develop their conceptual designs using different sorts of diagrams and simple sketches (Neiman, Gross, & Do 1999; Do & Gross 2001).  Another point of difference is relevant to the processes of the CBR cycle that are included in the different applications.    In a system like “IDIOM”, the user manually selects the different rooms to be included in the final design, the system then applies a set of constrains and preferences in order to automatically generate a layout of those rooms put together into a residential unit (Lottaz1996; Lottaz, Stalker, & Smith 1998).  In contrast, MONEO is intended to help designers reduce the time spent in selecting a number of cases similar to their current design problem. It leaves the case adaptation process to be manually carried out by the architects themselves, since this is a process that needs the architect’s creativity, not the system’s efficiency.
Hence, MONEO is a tool that aids architectural students as well as practicing architects in the pre-design phase by supplying them with an adequate number of similar past architectural cases to the design problem they have at hand. This paper focuses on how MONEO was designed and implemented.