Parameters, Not Plans : On computation, structure, and the discipline behind the algorithm
The wrong question
Most discussions about parametric design start with the wrong question. They ask what it looks like — and the answer is always the same: complex surfaces, intricate panels, non-standard geometry. This misidentifies the output for the method. Parametric design is not a formal vocabulary. It is a way of structuring design decisions so that their consequences can be tested, compared, and refined before anything is committed to.
The right question is not what parametric buildings look like. It is what parametric thinking makes possible that conventional drawing cannot.
The answer is iteration at a scale that changes the nature of the result. A fixed drawing is a single proposal. A parametric model is a family of proposals governed by a set of rules — and the designer’s job shifts from proposing a solution to defining the rules that will generate the solution space. Change the rules and the whole family changes. The consequences of a structural decision, a site boundary, an energy target, a material choice — these are not calculated after the fact. They are present in the model as it runs.
Fig. 2 — Cost of design revisions across project phases
What the computer is actually doing
There is a persistent confusion between using computational tools and doing computational design. Most architectural offices now use software that is parametric in some sense — BIM platforms track relationships between elements, scripting environments like Grasshopper allow rules to be defined visually. But using these tools within a conventional workflow — to draw faster, to coordinate more efficiently — is not the same as building a generative model that explores a design space.
The distinction matters practically. In a conventional workflow, the designer proposes and the consultant checks. The structural engineer receives a fixed scheme and evaluates it. If it fails, the design returns for revision. This loop — propose, check, revise — is the dominant mode of architectural practice, and it has a structural problem: the cost of revision rises steeply as the project progresses, which means that by the time problems are found, changing them is expensive. The rational response is to avoid finding problems, which means avoiding the rigorous testing that would reveal them.
A generative model inverts this. Testing is embedded in the proposal itself. Solar performance, structural feasibility, area compliance, spatial connectivity — these are not reports delivered by consultants after the design is fixed. They are parameters that the model evaluates continuously as configurations are explored. The designer can test hundreds of options before committing to one, at the stage when changing anything costs almost nothing.
The practical consequence is not that buildings look different, though they sometimes do. It is that they perform better, because the decisions that determine performance were made with more information and at lower cost.
The technical reality
The core working environment is Rhino and Grasshopper, extended with custom C# scripting. This last element is what distinguishes genuine computational practice from tool use. Grasshopper’s component library is powerful but finite. The moment a project demands something outside those limits — a bespoke structural optimisation routine, a custom solar analysis script, an automated documentation pipeline — the off-the-shelf environment runs out. Writing the component from scratch means the tool is shaped by the problem, not the other way around.
In practice this has produced tools for structural geometry optimisation, automated permit documentation that populates drawings directly from model geometry, and more recently integration with AI language model pipelines through RhinoMCP — allowing natural language prompts to drive 3D model generation as a rapid concept exploration tool. None of these were available as plugins. All of them emerged from specific project problems that existing tools could not solve.
The FEM work is perhaps the most technically ambitious current development: a plugin that generates finite element models directly from architectural solids, with a PCG solver running on CUDA, so that structural analysis feedback is fast enough to be part of the design conversation rather than a separate engineering gate. The goal is not to replace structural engineering software. It is to bring structural feedback into the generative model at the stage where it can still influence form.
Fig. 4 — Hours per task: manual drafting vs automated pipeline
Engineering and architecture as a single conversation
The conventional model of practice separates the two disciplines by phase. The architect designs; the engineer checks. This sequential handoff has a hidden cost that goes beyond time: structural logic arrives as a constraint on a design already conceived without it, and the result is a negotiation between two fixed positions rather than a synthesis. The engineer asks the architect to move a column. The architect asks the engineer to find another way. Both are defending territory that should never have been divided in the first place.
Parametric design dissolves that boundary by making the separation unnecessary. When the generative model contains both spatial rules and structural relationships simultaneously, engineering input is not a gate at the end of the process — it is a parameter at the beginning. A column grid is not imposed on a floor plan; it emerges from the same script that generates it, governed by span ratios and material properties alongside program requirements and daylighting targets. A facade system is not applied over a structural frame; its panel geometry is derived from the structural rhythm, so the cladding and the skeleton share the same geometric logic.
This is not only an efficiency argument. It produces architecturally different results. When structure is generative rather than corrective, buildings tend toward a formal honesty that purely aesthetic design rarely achieves — not because structural expression is a goal in itself, but because the form has been shaped by forces that are real. The parametric model makes this integration explicit, traceable, and repeatable across the full design space rather than resolved intuitively case by case
The algorithm and judgment
A generative model does not make decisions. It makes options. This distinction is easy to state and surprisingly difficult to hold onto in practice, because the volume of output that a parametric script can produce creates an illusion of completeness — as if the problem has been solved rather than explored. It has not. The script has done exactly what it was told. Whether it was told the right thing is a question the script cannot answer.
This is where judgment enters, and where the discipline of parametric design is most demanding. In a conventional workflow, judgment is distributed continuously across the process — every line drawn is a decision, and the accumulation of decisions produces the design. In a generative workflow, judgment is concentrated at two moments: at the beginning, when the rules are defined, and at the end, when the output is evaluated. Both are harder than they appear.
Defining the rules requires the designer to articulate what the design is actually trying to achieve — not in the loose qualitative terms that suffice for a brief, but with enough precision that a computational system can evaluate proposals against them. This is clarifying in a way that conventional design practice rarely demands. It is also exposing: vague intentions produce incoherent scripts, and the incoherence is immediately visible in the output. The model is an honest interlocutor. It does exactly what the rules say, and if the rules were confused, the result will be confused in ways that are harder to explain away than a sketch.
Evaluating the output is the less understood challenge. When a script produces eight hundred configurations, selecting among them is not a simple matter of identifying the best performer on the optimization criteria. Many configurations will perform well by the defined metrics and be architecturally wrong in ways the metrics did not capture — wrong in scale, in spatial sequence, in the quality of light, in the relationship between structure and enclosure. These are not failures of the algorithm. They are failures of specification: the rules did not encode everything that matters, because not everything that matters can be encoded.
The experiential qualities of a building are not derivable from performance metrics. They are the product of spatial intuition developed through years of looking at buildings, moving through them, understanding what they do to the people inside them. No script contains that knowledge.
The algorithm and judgment are not in competition. They operate at different scales and on different materials. The algorithm operates on the definable — on relationships that can be expressed as rules and evaluated against criteria. Judgment operates on the rest, which in architecture is considerable. The designer who understands both, and knows which tool is appropriate at which moment, is doing something genuinely difficult. The designer who believes the algorithm replaces judgment is producing optimised proposals, not architecture.
The portability of rules
The rules a parametric model encodes — structural relationships, spatial ratios, environmental targets, material constraints — are indifferent to the regulatory system they operate within, the construction culture they deliver into, or the geography of the site. What changes across contexts is not the method but the inputs: which rules are mandatory, which are discretionary, which performance thresholds must be met, which material systems are available.
This is not a trivial observation. It means that the effort invested in building a computational workflow — the scripts, the optimisation routines, the automated documentation pipelines — is not specific to a project or a jurisdiction. It is transferable. A structural geometry script written for one building type can be adapted for another with different span requirements. A solar analysis routine calibrated for one climate can be recalibrated for another. A documentation pipeline that populates permit drawings from model geometry works regardless of what that format contains, because the underlying operation — extracting data from a model and organising it into a required format — is invariant.
This transferability is what distinguishes parametric practice from parametric styling. If the computation is genuinely generative — if it encodes relationships rather than shapes — then it travels. The shapes it produces will differ because the inputs differ: site boundaries, program requirements, climatic conditions, structural systems, regulatory thresholds. But the method that produces them does not change. That invariance is the discipline. Learning to build tools that are genuinely portable, rather than solutions that happen to use parametric software, is the harder and more interesting problem.