Articles
Urban Development
May 13, 2026
Most generative design tools share the same workflow shape. The user defines a site. The algorithm produces a population of options. The user evaluates the options against their requirements, then discards the ones that fail. The expensive computation happens before the user discovers that most of what was generated does not actually meet the brief.
This is wasteful, and not only in computational terms. It is wasteful in cognitive terms. The user has to look at many options that were never going to work, just to find the few that were. A better question is whether the requirements can be checked before generation rather than after. If a configuration cannot meet the brief, the algorithm should know that in advance and not produce it.
This is the question we explored in a research project on the future of urban planning, run together with researchers from RISE and a reference group of practicing architects from leading Swedish firms including Ettelva Arkitekter, ÅWL Arkitekter, and Sweco. The collaboration brought together data scientists, machine learning researchers, and architects to look at how generative feasibility could be made more intelligent at the front end of the workflow, rather than only at the evaluation end.
In a conventional generative workflow, the validation of requirements happens after generation. The algorithm produces, say, 200 layouts. Each one is then checked against a long list of criteria: minimum unit count, daylight thresholds, parking ratios, area requirements, zoning compliance, accessibility rules. Most fail at least one criterion. The user sees a Pareto front of the survivors, but the computational and cognitive cost of producing the failed candidates is largely wasted.
Worse, the failures are often correlated with structural choices that were made before generation. A site that is too narrow cannot support certain typologies regardless of how cleverly the algorithm places them. A regulatory constraint on height eliminates a whole class of configurations. These are not edge cases that need to be discovered through generation. They are constraints that could have been checked before any geometry was produced.
The research question we explored is whether requirements can be pre-validated against the typology library and the site, so that only viable configurations are ever generated.
The reason pre-validation is tractable in Hektar specifically is the typology system. Each building typology carries its own behavioural logic, dimensional ranges, and structural constraints. Each parcel typology has known capacity, known shape, and known compatibility with specific building configurations. The space of possible designs is not arbitrary. It is structured.
This structure is what makes pre-validation a meaningful exercise. If a typology has a minimum footprint of a certain dimension, and the buildable area on a site is smaller than that, then no placement of that typology on that site will work. The algorithm does not need to try and fail. It can know in advance and select from the compatible subset of the library.
The research project formalized this intuition. We worked through which requirements could be checked at the typology level, which required parcel-level reasoning, and which genuinely needed full generation to evaluate. The result was a layered pre-validation framework, where the cheapest checks happen first and only the requirements that cannot be resolved at higher levels propagate down to the expensive generative step.
The collaboration was deliberately cross-disciplinary, and each contribution shaped the outcome.
Data scientists and machine learning researchers brought the methodological framing for how to decompose requirements, how to represent constraints in machine-readable form, and how to train models that could learn from architectural patterns rather than only enforce hand-coded rules.
RISE researchers contributed the research backbone, the formal methodology for the work, and the rigour expected of an academic research collaboration. RISE was a project partner, not a reference group, and the partnership shaped how the project was structured and how its outputs were evaluated.
Practicing architects from the reference group brought the reality test. Architects from Ettelva, ÅWL, and Sweco reviewed our proposed framework, pointed out cases where our pre-validation logic would miss something a human designer would catch, and pushed back when we tried to over-formalize judgments that are actually qualitative. The reference group is the part of any research project that prevents the output from being technically correct but practically useless.
Three findings stand out, three years later.
First, most requirements can be pre-validated. Not all, but most. Geometric requirements, regulatory thresholds, area minimums, and parking ratios can be checked against the typology library and the site geometry before generation. Only a minority of requirements genuinely need to be evaluated through full generation, and those are usually the ones that depend on interactions between buildings on a parcel rather than properties of individual configurations.
Second, the typology library is the key asset. Pre-validation only works if the typologies are richly described. A typology that is just a geometric envelope cannot support pre-validation. A typology with associated metadata about unit yield, daylight behaviour, structural requirements, and dimensional ranges can. The investment in the typology library is what makes the algorithmic intelligence possible.
Third, architects do not want to remove judgment. The reference group was consistent on this. Pre-validation is welcome when it removes obviously infeasible options. It becomes problematic when it tries to make qualitative judgments that designers want to make themselves. The line between these two cases is not always obvious, and where to draw it became one of the most useful conversations in the project.
Much of what came out of the research project has become part of how Hektar works internally. The typology library was expanded and made more richly metadata-aware. Pre-validation logic was integrated into the generative loop. The principle that the algorithm should know in advance what it cannot do is now baked into how the system reasons about constraints.
The reference group's pushback also shaped the product. We did not build pre-validation as a black box that prunes options invisibly. The user can see what was filtered out and why, and can override it. This was a direct response to architect feedback that algorithmic decisions need to be inspectable, not authoritative.
The broader lesson from this work is that early-stage urban planning tools are not bottlenecked by raw computation. They are bottlenecked by how cleverly the constraint space is structured before any computation happens. A tool that pre-validates well produces fewer options but better ones. A tool that pre-validates poorly produces more options but most of them are useless.
This sits at the heart of what we are now building further in the Vinnova-funded project on detaljplan compliance. Compliance intelligence is, in essence, large-scale pre-validation. The regulatory content of a detaljplan defines a constraint space. Pre-validating against that space before generation is the same problem we explored in the research project, applied at a different scale and with different inputs.
The research project was not a product. It was the foundation that made the current product possible. Every feasibility study Hektar runs today benefits from decisions made during that work, and the framework continues to shape how we think about where intelligence belongs in a generative pipeline.
Cross-disciplinary research projects are sometimes treated as separate from product work. This one was not. The methodology developed with RISE, the algorithmic framework explored with data scientists, and the reality testing done with practicing architects all converged into capabilities that ended up in production. That is the standard we try to hold to in this kind of work. Research that does not change the product is interesting. Research that does is the work.
