APEX
Computational design system for mixed-use towers. Data-driven thresholds. Adaptive program distribution. Tested across the world's most extreme climates. Architecture that evolves.
APEX is a computational design system for mixed-use towers, built on a decision-making framework that evaluates and re-evaluates every design decision across multiple scales simultaneously.
Picture this: a single site constraint changes, and the core placement shifts, the program distribution adjusts, and the facade responds. Not through manual revision. Through computation. APEX does not generate one answer. It finds the right ones.
The Iteration Problem
Picture a team working on a 60-story mixed-use tower. Three residential typologies. A hotel component. Ground-floor retail. A structural core that needs to stay below 20% of the floor plate to remain viable.
They have done this before. They know roughly where the core goes. They know the program mix their client wants. They know the FAR limits set by code.
What they do not know is how all of those variables interact when one changes. So designers iterate. Manually. Sequence after sequence of adjustments, each one disconnecting from the ones before it.
This is a common problem in tower design: not a lack of creativity, but a lack of computational feedback. The tools architects use are not built to handle multi-variable performance evaluation at scale. Parametric software can change a parameter. It cannot determine whether that change improves performance across five competing criteria simultaneously.
The consequences are tangible. Site constraints get accommodated rather than evaluated. Core placement gets inherited from precedent rather than derived from structural analysis. Facade systems get chosen for aesthetics and handed to engineers for post-hoc performance review.
Studies comparing manually designed towers to computationally generated ones found floor plate efficiency gaps of 12 to 18%. Core-to-plate ratios in manual designs frequently exceeded target thresholds by 3 to 5%. Program distribution rarely matched initial target ratios within 10%.
These are not catastrophic failures. They are the accumulated cost of not having a system capable of thinking at multiple scales at once. APEX was built to close that gap.
Rethinking What a Design Tool Should Do.
The default model of computational design had to go. Feed a site boundary into software, adjust parameters manually, iterate toward something that works. That model turns computation into drafting: a faster pencil, not a smarter process.
What this problem required was a system that understands architecture the way a structural engineer, a code consultant, a developer, and a climate scientist would: simultaneously, and in real time.
APEX was grounded in two computational principles.
First: decision intelligence has to be embedded at the threshold level. Not applied as a final check. Every constraint, from FAR limits and elevator planning codes to solar exposure data and construction cost indices, needs to live inside the generation process. When a parameter changes, the system evaluates immediately whether the new configuration violates a structural threshold, improves program efficiency, or requires a different facade response.
Second: the process has to be cyclical, not linear. Conventional computational design flows move from input to output. APEX runs feedback loops. Space planning informs structural analysis. Structural analysis adjusts aggregation. Aggregation feeds back into program distribution. Each loop tightens the solution.
This required three specialized systems, each responsible for a distinct layer of the design problem, and a coordination layer that kept them aligned.
Monoceros handled space planning, using wave function collapse algorithms to distribute units across floor plates. WASP managed aggregation, ensuring modules combined efficiently while maintaining spatial relationships. Karamba ran structural analysis in real time, feeding load distribution, wind performance, and stability data back into both systems.
Python managed the connective tissue. The genetic algorithm ran multi-criteria evaluation across all systems simultaneously, finding configurations that balanced competing performance targets rather than prioritizing one at the expense of others.
The result is not a tool that helps architects design towers. It is a framework that runs the design process, with human judgment applied where it actually matters.
4 Systems, 1 Framework: Computational Tower Design
No single software could handle all these layers simultaneously. Space planning, structural analysis, aggregation logic, and form generation each require specialized algorithms. The work was split across four computational systems operating under a unified genetic evaluation framework, each responsible for a discrete layer of the design problem, each feeding into the others.
Site Intelligence:
Where the process starts. The system ingests site geometry, FAR limits from the US Land Development Code, and population density data. It maps the physical and regulatory envelope before any unit is placed. The foundation everything else builds from.
Space Planning (Monoceros):
Handles unit layout using wave function collapse algorithms. Monoceros places and configures modules, from efficient studios to penthouses, while maintaining target typological ratios and adjacency relationships across the floor plate. The system that turns a program brief into spatial reality.
Aggregation Engine (WASP):
Manages how individual modules combine into a coherent tower structure. WASP ensures module connections maintain structural viability, spatial relationships, and program distribution across height zones. Individual module intelligence scaled to building scale.
Structural Feedback (Karamba):
Runs real-time structural analysis and feeds results back into space planning and aggregation. Load distribution efficiency, wind load patterns, and energy performance data continuously adjust the configuration. The system that ensures generated towers are structurally viable, not just geometrically possible.
Genetic Evaluation Layer:
The coordinator. A multi-objective genetic algorithm evaluates configurations across all performance criteria simultaneously: core-to-floor plate ratio, program distribution, structural efficiency, and environmental response. It does not find a single good solution. It finds the full range of high-performing configurations and surfaces the best candidates for human selection. The guardian of system integrity across every generation.
Orchestration:
These four systems do not run in sequence. They run in loops.
A site boundary input triggers Site Intelligence to generate the physical envelope. Monoceros receives that envelope and begins distributing program modules, generating a floor plate configuration. That configuration passes to WASP, which evaluates how modules aggregate vertically and flags connection conflicts. Karamba then runs structural analysis on the aggregated form and sends load distribution data back to both Monoceros and WASP.
If the core-to-floor plate ratio exceeds 20%, the system does not trigger a predetermined fix. It evaluates the deviation against population density targets, construction cost indices, and environmental performance data before selecting the best response.
The genetic algorithm sits above this loop, running multi-criteria evaluation across all outputs simultaneously. Each generation scores configurations against every performance threshold. Each generation improves on the last.
The result is not convergence on a single answer. It is convergence on a solution space: a family of high-performing configurations, each representing a different prioritization of the performance criteria. Selection, not iteration.
Two Extremes. One Framework. Measured Against Real Performance.
The test criteria for APEX were not internal benchmarks. They were two of the most demanding regulatory and environmental contexts in the world: Singapore and Reykjavik.
The choice was deliberate. If APEX could generate fundamentally different yet equally code-compliant, performance-driven facade responses from identical program inputs, the framework was validated. If it produced the same building in both climates, it was a template engine, not a design system.
Singapore: Tropical Climate Analysis
Singapore's analysis started with the baseline data. Year-round temperatures between 25 and 32 degrees Celsius. Average humidity of 84%. Solar radiation studies showing incident radiation exceeding 1,000 W/m² between 10 AM and 4 PM.
The first variable tested was density. Running APEX at 2X FAR versus 6X FAR revealed something that manual processes would have missed: higher density created exponentially more challenging heat gain conditions above the 40th floor. Reduced urban shading at that elevation produced a 40% increase in solar exposure relative to lower floors.
This data became the generative constraint for the facade response. Singapore's Green Building Masterplan, SGBMP 80-80-80, required 80% green certification, 80% Super Low Energy rated buildings, and an 80% improvement in energy efficiency by 2030. The Building Construction Authority mandated 100% replacement of greenery lost to construction.
APEX generated an interweaving balcony system derived directly from the radiation analysis. Each overhang was angled to maximize shading during peak solar hours. The system reduced solar gain by 78%, meeting Super Low Energy requirements without treating the facade as an aesthetic decision. Vertical gardens were integrated throughout, functioning as engineered ecosystems contributing to the Green Plot Ratio requirement and providing natural cooling through evapotranspiration.
Reykjavik: Subarctic Climate Analysis
Reykjavik's conditions represent the opposite end of the performance spectrum. Temperatures ranging from -3°C to 13°C. Daylight varying from 4 to 21 hours across the year. Iceland's building regulations from 2025 require mandatory Life Cycle Assessments for all major building permits, targeting a 55% reduction in construction emissions by 2030.
The density study here produced a counterintuitive finding: at 6X FAR, increased density actually improved thermal performance by creating urban heat islands and wind shields. The cost was daylight availability, which dropped by up to 60% at lower levels under high-density conditions.
APEX generated the Arctic Mesh facade system for this context. The parametric diamond pattern operates either statically or kinetically, adapting to Reykjavik's extreme daylight variations across seasons. Material use was calibrated for local manufacturing, directly addressing Iceland's LCA requirements. The system reduced heating demand compared to conventional facades while maintaining structural integration with the building program.
Methodology: How the Environmental Response Was Generated
In both cases, the process followed the same sequence. Site radiation analysis and climate data were processed as inputs to the environmental response layer. FAR scenarios were tested at 2X and 6X to understand how density affected environmental performance at different height zones. The findings from these studies became generative constraints fed directly into the facade design process.
The facade systems were not designed separately and then analyzed. They were generated from the analysis. The geometry, the overhang angles, the diamond pattern dimensions, and the material specifications were all outputs of the computational process, not inputs to it.
Two radically different buildings. Same framework. Both data-derived. Neither a stylistic choice.
APEX does not have an aesthetic. It has thresholds. The climate data determines what the building needs to be. The system generates the configuration that meets it.
What APEX Produces.
Program Distribution Precision: Any Site Geometry
The APEX algorithm processes site geometry at inception and generates program distributions for any given plot configuration while maintaining target function ratios across all program types. Residential typologies, hotel components, retail, and amenity spaces each achieve target ratios regardless of site constraints.
The genetic evaluation layer runs multi-criteria analysis simultaneously across program distribution, core placement, and floor plate efficiency. Where manual processes typically yield 10 to 15% deviation from target program ratios, APEX consistently generates distributions within acceptable threshold margins while simultaneously meeting core efficiency, structural performance, and environmental criteria.
Core-to-Floor Plate Efficiency: 20% Threshold Maintained
The relationship between structural core and floor plate is one of the most consequential decisions in tower design. Too large a core reduces rentable area. Too small creates structural and mechanical inefficiencies. The critical threshold is 20% of the floor plate.
APEX developed a parametric relationship system that maintains this ratio while adapting to changing program requirements across height zones. As the program mix shifts from residential to hotel to amenity floors, the core dimensions and placement adjust in real time.
Karamba runs continuous structural validation against this ratio, using structural feedback to guide configuration generation from the start rather than checking compliance at the end.
Configuration Generation: 10+ Valid Permutations Per Site
A single APEX run produces a family of configurations, not one answer. Each permutation represents a different weighting of the performance criteria: core efficiency, program distribution, population density, floor plate utilization, and morphological response.
Ten tested permutations all achieved program ratio targets. Each approached core efficiency, floor plate distribution, and morphological response differently. These are not random variations. Every permutation is a fully evaluated solution, derived from the same site data and threshold set, each emphasizing different performance priorities.
Design teams compare genuinely evaluated alternatives rather than manually generated variants. The selection decision becomes meaningful because every option has already been validated against the same performance criteria.
Environmental Adaptation: 78% Solar Gain Reduction in Tropical Conditions
The environmental performance testing produced the most direct evidence of APEX's adaptive intelligence in practice.
In Singapore, the interweaving balcony system derived from site-specific radiation analysis reduced solar gain by 78%. The geometry was not a rule-of-thumb overhang depth. It was generated from precise solar angle data, meeting Super Low Energy requirements while simultaneously replacing 100% of lost greenery through integrated vertical garden systems.
In Reykjavik, the Arctic Mesh facade system addressed heating efficiency, daylight management across extreme seasonal variation, and LCA compliance simultaneously through a single parametric system deployable statically or kinetically depending on seasonal conditions.
Two contexts. Two radically different responses. Both generated from the same computational framework with identical program inputs.
What This Means for Architecture Firms and Developers
APEX is not a visualization tool or a parametric skin generator.
Each implementation is built to solve the actual design problem: how to generate a mixed-use tower that meets program distribution targets, structural performance benchmarks, core efficiency thresholds, and environmental requirements simultaneously, from the first site analysis through form generation.
The implication for architecture firms is a fundamental shift in what the early design phase produces. Instead of schematic options based on precedent and intuition, teams receive a set of computationally evaluated configurations, each validated against regulatory thresholds, structural performance data, and environmental analysis before a presentation is made. The design conversation moves from 'here are three options' to 'here are ten validated configurations with measurable performance differentials.'
For real estate developers, APEX changes what 'meeting the brief' means. Program distribution targets become inputs the system is accountable to, not aspirational ratios that erode through the design process. Core efficiency directly affects rentable area. APEX treats both as hard constraints.
The environmental performance layer adds something increasingly non-negotiable. Singapore's SGBMP 80-80-80 requirements, Iceland's mandatory LCA framework, and parallel regulatory pressure in other markets mean facade performance is a compliance issue, not just an ESG talking point. APEX generates code-compliant, data-driven facade responses as part of the standard output.
What firms gain is not just faster iterations. It is a documented, data-backed design process that can be shown to clients, regulators, and review boards as evidence of performance-driven decision-making.
APEX also changes the nature of the client conversation. When program targets are embedded as generative constraints rather than design aspirations, every configuration in the output set has already met them. Clients are not reviewing options and hoping one works. They are selecting from a set of solutions that have already been tested. That is a different kind of confidence, and it shows in how projects move from schematic design through construction documentation.
This Is Not a Single Project. It Is a Learning System.
APEX does not solve a design problem and stop there.
Every project run through the APEX framework generates data. Not just design outputs, but performance records: which configurations achieved program targets, which core placements held structural efficiency across height zones, which facade responses performed against their climate benchmarks.
That data does not disappear when the project is delivered.
APEX is built around what the team calls generational learning. Each project enriches the solution database, creating a progressively deeper reference set for future configuration searches. The thresholds governing the next project are informed by the performance records of every project that came before.
This means the system improves with use. An architecture firm running APEX across three mixed-use projects does not have the same tool at project three that it had at project one. The genetic algorithm has more real-world performance data to draw from. The search converges faster, toward higher-quality configurations.
For the broader industry, APEX represents a different model of architectural intelligence: one where the accumulated knowledge of a practice is embedded into the design process, not stored in a senior partner's memory or a folder of precedent projects. The institution's experience becomes computational.
FAQ
1. How does APEX handle sites with unusual or constrained geometries?
Most computational design tools require a clean, regular site. The assumption of orthogonal boundaries, clear setbacks, and standard FAR envelopes is built into their logic.
APEX starts from a different assumption.
The site intelligence layer processes any given plot geometry as the primary input. Irregular boundaries, complex setback requirements, and multi-block sites are all handled as constraints to generate around, not exceptions requiring manual workaround.
The wave function collapse algorithms in Monoceros were specifically chosen because they generate solutions within constrained boundary conditions rather than requiring the boundary to conform to the algorithm. An L-shaped site, a triangular plot, or a site with protected view corridors generates a different evaluated configuration, not an approximation of a rectangular one.
The system maintains target program ratios even as site geometry forces non-standard floor plate shapes. Core placement adjusts to maintain service distance efficiency. Module orientation accounts for daylight access within the given boundary conditions.
In practice: APEX does not require a good site. It finds the best possible configuration for whatever site is given. The gap between what a constrained site could be and what it actually becomes is where the value is most measurable.
2. What distinguishes APEX from conventional parametric design tools?
The distinction matters.
Parametric design tools let architects change a parameter and see the result. Adjust the floor-to-floor height. Modify the core size. Shift the program mix. Each change produces a new geometry.
What parametric tools do not do is evaluate that geometry against a multi-variable performance framework. They show the result of a decision. They do not determine whether it was the right decision, or which of thousands of possible decisions would produce a better result.
APEX is a computational design system, not a parametric modeler. Parametric tools are instruments the architect plays. APEX is a framework that runs performance evaluation and presents the architect with its findings.
The thresholds embedded in APEX, from BOMA Standards and KONE Planning Guides to ASHRAE energy benchmarks and RS MEANS cost data, operate as active decision filters during generation, not post-hoc compliance checks. The genetic algorithm does not generate options for a human to judge. It runs multi-criteria evaluation across all performance factors simultaneously and surfaces the highest-performing configurations.
A parametric tool makes iteration faster. APEX makes iteration meaningful. Each generation of the genetic algorithm is informed by the previous one. The solution space narrows toward configurations that actually work, rather than expanding outward through manual exploration.
For teams that have used both: APEX is what happens when the question stops being 'what does this look like if I change this variable?' and becomes 'what is the best configuration given these constraints?'
3. How are building codes and technical standards embedded into the system?
The standard approach to code compliance in design is sequential: design first, check compliance second, revise, repeat.
APEX inverts this.
The regulatory and technical thresholds governing tower design are codified as decision filters that operate during generation. Four categories of standards are embedded directly.
Site constraints are derived from Council on Tall Buildings guidelines and FAR thresholds set by US Land Development Code. These define the physical and regulatory envelope before any space planning begins.
Program size and density thresholds are based on BOMA Standards and IBC 2021 requirements. These govern how much of each program type can occupy which zones of the floor plate.
Technical thresholds come from KONE Planning Guides and ASME A17.1 Safety Codes, governing elevator core sizing, service distances, and vertical transportation efficiency across height zones.
Economic thresholds are derived from RS MEANS City Cost Index data and ASHRAE standards, ensuring generated configurations remain viable within real-world construction cost parameters.
When any configuration violates a threshold, the system adjusts and reruns the evaluation. Compliance is not checked at the end. It is enforced throughout.
Every configuration APEX surfaces has already passed the compliance layer. Design teams are not iterating between architects and code consultants. They are selecting from options that have already been validated.
4. Can APEX adapt to climate contexts beyond Singapore and Reykjavik?
Singapore and Reykjavik were testing extremes. Not product configurations.
The choice of a tropical climate with year-round high humidity and solar gain versus a subarctic climate with extreme seasonal daylight variation was deliberate: if APEX could produce fundamentally different, code-compliant, performance-driven facade responses from identical program inputs at those poles, the environmental adaptation framework was validated.
The framework itself is not climate-specific. It is data-driven.
The environmental response layer in APEX takes radiation analysis, temperature profiles, humidity data, daylight availability, and local regulatory requirements as inputs. It generates facade configurations that respond to those inputs directly. A Riyadh site produces different outputs than a Helsinki site for the same reason that Singapore produced different outputs than Reykjavik: the data is different.
What changes between climate contexts: the radiation threshold weights in the genetic algorithm, the facade system typology the evaluation favors, and the regulatory compliance targets for that jurisdiction. What stays constant: the computational framework, the performance validation methodology, and the structural and program evaluation layers.
The Singapore and Reykjavik implementations demonstrated two things. First, that APEX generates contextually appropriate responses without manual climate-specific customization. Second, that those responses are performance-derived. The Arctic Mesh and the interweaving balcony system look different because the data required different solutions, not because a designer chose different aesthetics.
5. What does generational learning mean for firms that use APEX across multiple projects?
Every APEX run produces more than a set of building configurations. It produces a performance record.
Which core placements maintained structural efficiency across height zones. Which module aggregation patterns achieved program targets under constrained site geometries. Which facade configurations met climate performance benchmarks in specific regulatory environments. Which genetic algorithm weightings produced the fastest convergence toward high-performing solutions.
That data does not reset between projects.
Generational learning means the APEX framework accumulates design intelligence across every project it runs. The genetic algorithm at project three is not starting from the same baseline as project one. It has real performance records from previous runs to draw on: a richer dataset of what actually worked, under what constraints, in what conditions.
In practical terms, convergence gets faster and solution quality gets higher with each project. A firm running APEX across five towers does not have five separate data sets. It has a progressively deeper evaluation foundation informing each subsequent run.
It also means the knowledge does not leave when a senior designer leaves. The accumulated intelligence of the practice, which configurations performed, which thresholds mattered, which approaches proved out, is embedded in the system. Available computationally, for every future project that shares relevant conditions.