Architectural knowledge solves design problems. We can formalize the process by defining architectural knowledge as a set of rules which outputs designs according to specified inputs like site and program. When we have architectural knowledge, we can automatically generate the correct solution, so we don’t have to use trial and error indefinitely.
Blueprints cannot explain design rules even if the architect is consciously aware of them. Blueprints end up as an all or nothing final product. The architect's decisions are packaged together without an explanation, so we cannot apply the architect’s knowledge to new situations as variables change. We only have the blueprints to work from. What was drawn on paper might work for the hypothetical that was created in the architect’s mind, but it doesn’t always match the actual conditions.
Interactive blueprints make the knowledge of the architect accessible to everyone, so we don't need to (1) follow the plans exactly as drawn even when changes should be made, or (2) call an architect for a redesign every time something changes. Since the architect's knowledge is programmed into the software, the design will immediately respond to changes. It gives the client (who knows the site and program better) more control over the situation. They can test out ideas quickly, and see what inputs interact with what.
Any set of rules can be computational, but in order to make adapted buildings, we need the right set of rules. Adapted buildings require the right code. Good code is developed by architects with a lot of experience who know which solutions work. The code varies according to climate, typology, and style. Certain configurations (or packages) act like templates, which can be adjusted.
The computational nature of design is demonstrated by software like The Sims game, where design is scored by the Sim’s satisfaction. Unlike real life however, the Sims game allows users to place a toilet in the middle of the dining room without penalty. Factors like privacy, circulation, and natural light should be programmed into the Sim’s score. Architectural design software has parameters that make it easy to edit designs, but they do not have enough rules to generate designs. The rules that exist in BIM software are warning signs about modeling the design correctly. The inputs are walls and windows instead of simpler inputs like site, location, and budget, which then would create the walls and windows.
Generative software needs context. The advantage of software is that it gives inputs greater control over the process because it solves the knowledge-side of the equation. However, if we fudge the inputs for time-saving reasons, or the software doesn't allow for sufficient context, then the output will not match the actual site conditions, even if the generated designs look like they should.
Decisions are made by measuring how "fit" a solution is to a rule, and weighting that rule based on its importance. Rules affect other rules (recursively), so our brain (and software) has to run iterations.
Example: The best view is weighted more important than direct sunlight, so I put the window there. However, putting the window there throws off the façade. The façade is more important than a nice view, so even though a nice view is more important than direct sunlight, once I factor in what it does to the façade, actually the other location is a better choice.