A broker calls with a deadline that is not really a deadline: a tenant wants a test fit on a 38,000 square foot floor by tomorrow morning, and three other landlords are racing to put a plan in front of the same tenant. The old way was a space planner pulling an all-nighter to draw two or three layouts. The new way is TestFit, or Hypar, or Higharc on the residential side: you give it the floor plate, the program, the target headcount, and it returns fifty layouts in an afternoon, ranked on efficiency and yield, parking solved, unit mix balanced. The temptation is to send the top-ranked plan and call it a test fit. The discipline is to remember what these tools are: generative-design engines that optimize the objective you stated, yield, efficiency, unit count, and are blind to the constraints you did not state, the egress that has to work, the accessibility that is not optional, the zoning the plan has to survive, the market the units have to sell into, and the client who has to love it. This lesson designs the space-planning workflow where the tool generates the candidates fast and the planner selects against the constraints that actually matter, then owns the basis-of-design memo that goes out the door.

Three Tools, One Engine: What Hypar, Higharc, and TestFit Actually Do

Hypar, Higharc, and TestFit are different products aimed at different problems, but they share an engine, and that engine governs how you use them. TestFit is a real-estate feasibility and test-fit tool: give it a site or a floor plate and a program, and it generates layouts, solves parking, and reports yield, the metrics a developer or a broker lives on. Hypar (and Hypar 2.0, with text-to-BIM and cloud generative space planning) generates building layouts and space plans from a description, producing many options you can compare and push toward BIM. Higharc works the residential side, generating single-family and community layouts, plans, and downstream documentation from a generative model. Different markets, different outputs, but all three do the same fundamental thing: they generate many spatial layout options against an objective, fast.

That shared thing is the generative-design engine, the fourth of the program's four engines, the same engine that powers Forma's massing and Augmenta's MEP routing. Naming the engine rather than the products matters because the engine determines the discipline. These tools do not draft the one layout you specified; they search the space of possible layouts against the objective you gave, yield or efficiency or unit count, and return the options that score well. So the question you ask of their output is not "did it draw what I asked" but the harder generative-design question: "does the layout that scored best actually work as a plan, including everything I did not put in the objective?"

The speed is real and it changes the economics of space planning: fifty layouts in an afternoon means you can explore the design space instead of committing to the first feasible plan, and you can answer the broker's overnight deadline with options rather than one rushed plan. But fifty fast layouts are fifty candidates, and the value is captured only if the planner then does the work the engine cannot: selecting the layout that serves the real program against the constraints the objective left out, and standing behind it.

What the Objective Optimizes and What It Misses

To use these tools well you have to be precise about what their objective contains and, more importantly, what it does not. When TestFit maximizes yield on a multifamily site, the objective is unit count, possibly weighted by efficiency and parking ratio. When Hypar optimizes a tenant fit-out, the objective is usable area, seat count, or layout efficiency. These are the things the tool can measure and the things you told it to maximize, and it will maximize them faithfully, which is the trouble: a faithful optimizer of yield gives you the highest-yield plan, and the highest-yield plan is not always a plan you can build, lease, or get approved.

Consider the constraints the objective routinely misses. Egress: a layout can maximize seat count while putting a workstation cluster more than the code-permitted travel distance from an exit, or creating a dead-end corridor that IBC 2024 Chapter 10 will not allow; the yield score is silent on whether the egress works. Accessibility: a plan can be efficient while failing ANSI A117.1 clearances at a restroom or an accessible route, and accessibility is not a preference the optimizer trades against yield, it is a requirement the plan must meet. Zoning: a high-yield residential layout can exceed the density, height, or parking the zoning permits, or trip a setback, so the yield is illusory because the plan cannot be approved. Market: a unit mix that maximizes count can skew toward studios the local market does not absorb, so the yield is high and the lease-up slow. The client: a tenant's actual way of working, the collaboration zones they want, the corner office politics, the brand, are not in the objective at all.

This is the objective-function problem made specific to space planning. The engine optimizes the stated objective and ignores every unstated constraint, egress, accessibility, zoning, market, client, because none of them was in the function it was maximizing. The plan that tops the ranking is the best answer to "which layout maximizes yield," which is not the same question as "which layout should we build," and the gap between those two questions is the planner's job.

A generative space planner gives you the highest-yield layout, not the most leasable, most approvable, or most livable one; it optimizes the count you asked for and is silent on the egress, the accessibility, the zoning, the market, and the client, so the planner selects against the constraints that decide the project, not the metric the tool happened to maximize.

Egress, Accessibility, and Zoning Are Not Preferences the Optimizer Can Trade

It is worth dwelling on why code constraints in particular cannot be left to the optimizer, because the temptation is to assume the tool "knows the code." Some of these tools do encode some code logic, and that is useful, but encoded code logic is a starting filter, not the licensed code judgment the program reserves for the professional. The deeper point is categorical: egress, accessibility, and zoning are not soft objectives the optimizer can balance against yield; they are hard constraints the plan must satisfy to exist. A layout that scores a few units higher by shaving a corridor below the required width has not made a favorable trade-off; it has produced a plan that cannot be permitted.

So the planner's verification of these constraints is not optional refinement; it is the filter that decides which of the fifty candidates are real. A candidate that fails egress, accessibility, or zoning is disqualified before any comparison on yield, because its yield is meaningless if the plan cannot be approved. This is the code gate, the second of the program's five gates, applied at the space-planning step: before a layout is even a candidate worth comparing, it must clear egress (travel distances, exit count and separation, corridor and door widths, dead-end limits per IBC 2024 Chapter 10), accessibility (ANSI A117.1 routes, clearances, and counts), and zoning (density, height, setbacks, parking, use). The optimizer's yield ranking operates only on the layouts that survive this filter.

The licensed dimension matters here. Tier-3 code interpretation, the judgment about how a specific code provision applies to a specific condition, is the licensed professional's stamped act, not the tool's and not the planner's if the planner is not the one in responsible charge. The generative tool can flag obvious egress and accessibility problems, and a good workflow uses it to, but the determination that a plan complies, the one that goes into a permit set, is a professional act. So the code gate at space planning has two layers: the tool's automated first-pass filter that removes the obviously non-compliant candidates, and the professional's judgment that confirms the selected plan actually complies, which the tool cannot supply.

Fifty Candidates, One Decision: The Planner Selects and Owns

The generative space planner's output is fifty candidates, and the program's rule holds: candidates are not decisions. The planner reads them, understands the trade-offs the rankings express, applies the constraints the objective missed, and selects the layout that serves the real program. This is not a rubber stamp of the top-ranked plan; it frequently lands on a lower-ranked plan, because the top-ranked-on-yield plan often loses to a slightly lower-yield plan that leases better, frames more economically, or simply works as a place to be. The fifty candidates make this judgment richer, because the planner chooses from a well-explored space rather than from the two or three plans there was time to draw by hand, but the judgment is still the planner's.

The responsible-charge principle governs ownership. The planner who selects the layout owns it, and on a permit-bound project the licensed professional in responsible charge owns the code determination. The generative tool did real work, exploring the space and surfacing high-performing options the planner would not have drawn, but exploration is not authorship, and the planner cannot point at the tool's ranking if the selected plan proves unleasable or non-compliant. The decide-then-draft discipline applies: the planner decides which layout is the plan, against the full set of constraints, and only then does the layout get developed into the documented test fit or the schematic. Letting the tool's ranking decide and developing whatever it ranked first inverts the order and surrenders the judgment.

This is also where the metric-as-signal discipline shows up. The yield and efficiency scores are signals about the stated objective, not verdicts about the plan: a high yield score tells you the plan packs in units, not that the plan is good, and a planner who reads the scores as the answer rather than as one input among the unstated constraints has let a partial metric substitute for the whole judgment. The scores inform the selection; they do not make it.

The Basis-of-Design Memo and the AI-Assistance Disclosure

The deliverable of this step is not just a layout; it is the recommended layout plus the basis-of-design memo that explains and stands behind it, and the playbook is explicit that the memo includes the AI-assistance disclosure. The memo is where the planner's judgment is recorded: which layout is recommended and why, the program it serves, the efficiency and yield it achieves, the code clearances it meets, and the trade-offs that led to selecting it over the alternatives. It is the artifact that turns a tool output into a professional recommendation, because it carries the reasoning that the responsible-charge judgment supplies and the tool cannot.

The AI-assistance disclosure is a deliberate piece of this. Disclosing that a generative tool produced and ranked the candidate layouts is truthful about the process, and it locates the judgment correctly: the tool generated options and the professional selected and verified, exactly the division the workflow enforces. This matters for the contract-authority gate and for the firm's accountability, because the client and any reviewer should know that AI assisted the generation while a named professional made and owns the decision. A memo that hides the AI assistance misrepresents the process; one that discloses it, and shows the human selection and verification on top of it, is the defensible artifact.

The memo also carries the basis downstream, the way the Forma handoff did: the next person, the architect developing the fit-out, the engineer sizing the systems, the broker pitching the tenant, inherits not just the plan but why this plan, the program it serves, the constraints it clears, and the trade-offs behind it. A layout with no memo is geometry with no reasoning, easy to second-guess and hard to defend; a layout with a basis-of-design memo and an AI-assistance disclosure is a professional recommendation that a planner in responsible charge selected, verified, and will stand behind.

Where the Workflow Fails: The Fast Plausible Plan

The characteristic failure of generative space planning is the fast plausible plan: the tool returns a layout that looks complete, scores well on yield, renders beautifully, and is wrong in a way the rendering hides. It is wrong because the egress does not actually work, or the unit mix does not match the market, or the plan assumes a structural grid that conflicts with the building's actual columns, or the accessibility clearances are a few inches short. The danger is precisely that the plan is plausible: it has the form of a finished plan, so it invites the planner to skip the verification the form conceals the need for. The speed compounds the danger, because a tool that produces fifty plausible plans in an afternoon produces fifty invitations to skip verification.

The defense is to treat plausibility as the trigger for verification, not the substitute for it. A plan that looks finished gets the code-gate filter (egress, accessibility, zoning) and the unstated-constraint review (market, client, constructability) precisely because it looks finished and will otherwise advance on its appearance. The planner who has internalized the objective-function problem reads every plausible plan with the question "what did the objective miss here," and finds the egress problem the yield score concealed, the market mismatch the unit count concealed, the structural conflict the clean render concealed. The verification is consequence-proportioned: a test fit that will set a lease negotiation or a schematic that will set the project warrants real scrutiny, more than a quick study.

The other failure is over-trusting the tool's encoded code logic. Some of these tools check some code constraints, helpful as a first-pass filter, but it is not the licensed determination, and a planner who treats the tool's green checkmark as compliance has substituted a partial automated check for the professional judgment a permit set requires. The tool's check removes the obvious failures; the professional confirms compliance. Conflating the two is how a non-compliant plan reaches a permit set with everyone believing the tool had vetted it.

The Applied Problem: The Recommended Layout and the Basis-of-Design Memo

Here is the exercise, from the playbook. Generate fifty layout options for a tenant fit-out or a single-family residential plan using Hypar, Higharc, or TestFit, filter them by efficiency, cost, and code, and produce the recommended layout plus the basis-of-design memo with the AI-assistance disclosure. The deliverable is not the tool's top-ranked plan; it is the layout you selected against the full set of constraints and the memo that explains and stands behind it.

Produce three things. First, the generation and the filter: the program and objective you gave the tool (the floor plate or site, the target headcount or unit count, the efficiency goal), the fifty candidates it generated, and the filter that reduces them to the viable set, removing the layouts that fail egress, accessibility, or zoning, because those are not candidates regardless of their yield. Second, the selection against the unstated constraints: from the viable set, the layout you recommend and the reasoning, naming the constraints the objective missed that drove the choice, the market and the real unit mix, the client's actual way of working, the constructability and the structural grid, possibly selecting a lower-yield plan that serves these better. Third, the basis-of-design memo: the recommended layout, the program it serves, the efficiency and yield it achieves, the code clearances it meets, the trade-offs behind the selection, and the AI-assistance disclosure stating that a generative tool produced the candidates and a named professional selected and verified.

The lasting product is a space-planning workflow you can run against any overnight deadline: the tool generates fifty candidates at a speed no manual process can match, you filter them against the hard code constraints, select against the unstated constraints that decide the project, and produce the basis-of-design memo that turns the selected layout into a defensible professional recommendation. The engine generates the candidates; the planner makes the decision and owns the memo.

Key Takeaways

• Hypar, Higharc, and TestFit are different products (tenant fit-out and BIM space planning, residential, real-estate feasibility and test fit) sharing one engine, the generative-design engine, which generates many spatial layout options against an objective, fast, fifty layouts in an afternoon.
• The engine determines the discipline: these tools optimize the objective you stated (yield, efficiency, unit count) and are blind to every constraint you did not state, so the output is candidates answering the question you asked, not decisions about which plan to build.
• The objective routinely misses the constraints that decide the project: egress and dead-end limits (IBC 2024 Chapter 10), accessibility clearances and routes (ANSI A117.1), zoning (density, height, setbacks, parking), the market and the real unit mix, and the client's actual way of working, none in a yield function.
• Code constraints are not preferences the optimizer can trade against yield; they are hard constraints the plan must satisfy to exist, so the code gate filters which candidates are real: a layout that fails egress, accessibility, or zoning is disqualified before any comparison on yield.
• The tool's encoded code logic is a first-pass filter, not the licensed determination: Tier-3 code interpretation is the professional's stamped act, so the code gate has two layers, the tool removing obvious failures and the professional confirming the selected plan actually complies.
• Fifty candidates are not a decision: the planner reads them, applies the missed constraints, and selects the layout that serves the real program, often a lower-ranked-on-yield plan that leases better, frames more economically, or simply works, owning the selection under the responsible-charge and decide-then-draft principles.
• The deliverable is the recommended layout plus the basis-of-design memo with the AI-assistance disclosure: the memo records which layout and why, the program, the clearances, and the trade-offs, and the disclosure locates the judgment (the tool generated, the professional selected and verified), making the output defensible.
• The characteristic failure is the fast plausible plan that looks finished and is wrong in a way the render hides (egress, market, structural conflict, accessibility), so plausibility is the trigger for verification, not a substitute.