On a recent sunny afternoon, Jason Van Nest met Jason Buchheit near the Chelsea offices of Danny Forster & Architecture before the two headed out for a walking conversation. Their interview unfolded along Riverside Park, with the Hudson River opening beside them. The resulting exchange was reflective but practical, expansive but grounded, as the two Jasons considered what it would mean for architecture, manufacturing, regulation, finance, and education to stop working in silos and begin designing the delivery ecosystem itself.

After decades working on the design side of offsite delivery, what are the mistakes you keep seeing clients and designers make? What are the ones that are holding the industry back? 

The biggest issue is that offsite construction is still treated as a delivery method rather than as an ecosystem. 

Look, I've spent years of working across architectural practice, R&D, modular high-rise delivery, systems innovation initiatives, and direct coordination with fabricators, manufacturers, component suppliers, and code officials. It complicated. And success depends on continuous coordination across design, manufacturing, procurement, logistics, compliance, and installation. It's hard to work at the ecosystem level, when most of the industry is still organized around fragmented scopes of work.

In architectural practice, I watch novice offsite teams assume ambiguity can be carried forward the way it is in conventional construction. It's not like field-built work, where uncertainty is often absorbed onsite through trade coordination and adaptation. Offsite delivery ecosystems need that uncertainty explicitly managed, with detailed manufacturing systems, procurement chains, sequencing logic, and compliance pathways… all managed long before anything reaches a site.

I’ve seen this assumption repeated across hospitality towers, institutional modular projects, and product development work with fabricators and component manufacturers. No matter the project type, assumptions that appear isolated at the architectural level (i.e. connection tolerances, module dimensions, MEP routing, access clearances) quickly propagate into unstudied tooling, transportation constraints, inspection sequencing, supplier lead times, and installation workflows.

It's another form of what we called value engineering back in the 90s. Both are the unintended effects of deferred systems definition and are the “mistakes” we see in offsite today.

These are the considerations that  inform the solution when working directly with fabrication teams developing repeatable assemblies or platform strategies. Once we are aligned on systems definition, the conversation shifts very quickly away from isolated details and toward production stability. Fabricators are not only asking whether something coordinates geometrically, they are asking whether it can be repeatedly manufactured, efficiently inspected, transported without damage, connected reliably onsite, serviced over time, and approved consistently across jurisdictions.

Its a scale most building designers are not used to. In normal workflows, architects can rely on a coordinated model, but in offsite, the standard is higher to reach a manufacturable system. That gap is one of the reasons fabricators still routinely rebuild project models downstream… to extract fabrication intelligence. And it is also why the industry continues to struggle with delivery predictability, procurement instability, and inconsistent compliance outcomes.

Teaching reinforces the same point from another direction. Students initially think in silos (in classes we teach at NYIT about structure, MEP, enclosure, logistics, code). Once you map real delivery conditions in front of them, it becomes obvious that buildings operate as interconnected systems where decisions in one domain immediately affect multiple others. Offsite construction simply makes that interdependence impossible to ignore.

To be clear, I don't believe these articles you see pointing to an industry held back by reduced manufacturing capability. The capability already exists. The larger issue is that the industry is still trying to apply fragmented project-based thinking to what is fundamentally an integrated systems-based process.

It seems like the culminating evaluation of such an ecosystem is governmental review – review by Authorities Having Jurisdiction (AHJ). That's when process and product are all laid out for one comprehensive audience. I take it that you've seen AHJ reviews that worked, and ones that fell apart. Is there a secret to designing in compliance strategies? What will it take to get past ETO reactive approvals? 

From my experience, AHJ review tends to work under two conditions:

• either the project's system is based on something already widely understood, or 
• the project team can clearly translate system behavior into a compliance logic reviewers can follow confidently.

Offsite construction often disrupts both.

Traditional buildings benefit from decades of institutional familiarity: UL assemblies, conventional load paths, familiar fire separations, and standard inspection sequences. Those are not simply technical references—they are shared compliance language.

Offsite systems break that continuity. In volumetric and platform-based delivery, fire, structure, and MEP systems are no longer visually continuous in the way inspectors are accustomed to evaluating. Assemblies span manufactured interfaces, delegated systems, distributed connections, and responsibilities divided across factory and field. Complicating that fragmented review, many of these systems are also proprietary or recently developed, meaning reviewers are often evaluating conditions without a deep bench of precedent.

That buries the assessment of whether there is a compliance failure. Often, AHJ review hinges on a translation problem.

What makes modular projects particularly challenging is that compliance frequently involves multiple layers of review. In addition to local AHJs, projects may involve state modular programs, third-party plan reviewers, third-party inspectors, factory certification agencies, and specialized engineering reviews. 

This brings us back to the ecosystem point: each of these participants is ultimately responsible for reducing risk within their own scope of authority. There is no organizing force creating incentive alignment. Instead, every reviewer has an incentive to adopt the most conservative interpretation available.

What begins as a single code question can become several parallel interpretations of the same requirement, each attempting to minimize liability from a different perspective. Individually, those decisions are understandable. Collectively, they can create significant friction for project teams.

This, Jason, is what we called a Gridlock Economy in other CfOC writing. The gridlock in this case is a project where no single reviewer was being unreasonable, yet the accumulation of multiple conservative interpretations created requirements that exceeded what any one agency would likely have required independently.

AHJ gridlock is one of the hidden challenges facing industrialized construction today. The more fragmented the approval ecosystem becomes, the more difficult it is to achieve consistency in compliance outcomes. We need ecosystem thinking, applied to product-based approaches, to solve this.

Put another way, AHJ-labeled compliance is still often treated as something validated at the end of design. Successful projects operate differently. Compliance becomes part of system definition itself. Its developed alongside fabrication constraints, transportation requirements, installation sequencing, inspection access, testing assumptions, and interface design from the beginning.

• ETO workflows struggle because they depend on deferred interpretation. In conventional construction, that interpretation can often be resolved in the field. 
• In industrialized construction, deferred interpretation becomes institutional risk because every unresolved issue passes through multiple approval bodies before reaching production. That can sink a project, and a firm with it.

The shift required is ecosystem-level. The system should enable earlier alignment: system logic, interface definition, testing methodologies, inspection pathways, and compliance assumptions developed collaboratively among designers, fabricators, engineers, third-party reviewers, state agencies, and AHJs before production begins. These are all parts of the same system.

That's why the future of industrialized construction depends less on creating new products and more on creating shared compliance frameworks that allow regulators, manufacturers, designers, and builders to evaluate systems through a common language. Anyone can build a better mousetrap. Our industry needs more predictable mousetrap approvals.

Ecosystems need energy input, like sunlight or thermal vents. I guess for offsite, that means funds. On your projects, does the client drive funding, insurance, and contract structures? Or are you starting to see CTO structures that help designers steer smart choices for the bankers that don't understand the risks?

In practice, funding, insurance, and contractual frameworks are still largely shaped by clients, lenders, and insurers working from conventional construction risk models. Those models assume value is progressively created on-site and distributed across multiple trades over time. Even on projects with significant industrialization, that baseline assumption hasn’t fundamentally changed. 

What has changed is where value is created. In offsite and system-led delivery, a large portion of project value is created early (like during systems definition, engineering, procurement strategy, compliance coordination, tooling, and fabrication). This is well before components arrive on site.

That shift to pre-construction upends how risk is currently understood and allocated. In façade systems delivered through design-assist structures, we are starting to see a more evolved contractual and risk posture. The façade contractor or specialty consultant is often brought in early under a preconstruction or design-assist agreement, with defined responsibility for performance criteria, detailing input, testing protocols, and constructability validation. While not fully transferring manufacturing risk, these structures do reduce uncertainty by tightening the feedback loop between design intent and fabrication logic. In effect, risk is reduced through early validation of system behavior, clearer performance delegation, and more explicit responsibility for interfaces and testing regimes.

We're not asking lenders and insurers to evaluate “modular risk” as a distinct category. That's almost impossible. Instead, with us, they evaluate system-definition risk, or how well the project has resolved the conditions that determine whether a system can be reliably executed at scale. It's easier for them than asking whether sequencing, procurement pathways, inspection criteria, transportation constraints, installation tolerances, and compliance responsibilities are sufficiently resolved that the system behaves predictably under real delivery conditions. This is where façade design-assist and modular fabrication diverge in how maturely risk is currently structured.

Put another way, repeatability is what ultimately reduces risk from a financing and insurance perspective. When systems have known tolerances, defined connection strategies, validated inspection pathways, and established compliance outcomes, underwriting becomes more straightforward because variability is constrained. Conversely, when systems remain bespoke beneath the surface (coordinated with ETO in advanced BIM environments) the financial system still reads elevated exposure based on professional liability. BIM alone does not resolve risk; it only makes it more visible unless it is tied to repeatable manufacturing logic.

This is where CTO-style thinking becomes relevant beyond technology. The value exceeds digital coordination, and functions at the structuring of systems so they are legible as production systems: validated, repeatable, and embedded with clear implementation logic from design through fabrication and installation.

Our most successful projects tend to be those where design teams, fabricators, insurers, lenders, and code authorities align early to build their own ecosystem around how the system is actually intended to behave in production, and how it is represented in design is an afterthought.

Once that alignment exists, risk stops being abstract and becomes measurable, allocatable, and therefore financeable.

I get it. We're talking about designing products and product platforms, not one-off designs. It makes sense for fabricators to repeatedly rebuild design models to extract fabrication intelligence, when the product they are working on will be deployed on dozens or hundreds of buildings… but that's a lot of overhead for one building. Is that the limit of ETO you face? Do product platforms describe the CTO future you want to see, with coordination-focused BIM models (produced by architects and engineers)?

Yeah. Repeated rebuilding of design models by fabricators is often misunderstood as a data-transfer problem. In reality, it exposes a much deeper issue: project BIM and manufacturing BIM are fundamentally different systems operating at different scales of information.

Most architects and engineers work in project-centric BIM environments. The model is organized around a building. Information is managed by discipline, drawing package, code compliance requirements, permit submissions, construction sequencing, and contractual scope boundaries. The objective is coordination, documentation, and regulatory compliance across an entire project.

Manufacturing environments operate almost exactly in reverse. The organizing principle is not the building. It is the product, assembly, workstation, production sequence, quality-control process, logistics pathway, and installation methodology. Information is managed around repeatability, tolerances, part relationships, procurement, machine operations, and production throughput.

Those are different information architectures. One of the reasons Revit models become increasingly unstable when pushed toward fabrication-level resolution is that they are being asked to manage information at a scale they were never intended to control. As production-level intelligence is added, file sizes increase dramatically, relationships become fragile, parametric dependencies begin conflicting with one another, and geometric control becomes increasingly difficult to maintain across the scale of an entire building.

Anyone who has worked extensively in large project models has seen this occur. Relationships break unexpectedly. Hosted elements disappear. Constraints become circular. Small modifications in one area propagate unintended consequences elsewhere in the model. As manufacturing detail increases, model performance and reliability often decrease. What else would we expect when asking a building-scale coordination environment to perform product-scale manufacturing management?

The disconnect becomes even more apparent when considering regulatory requirements. Architectural and engineering BIM models are structured around the production of permit documents, life safety documentation, accessibility compliance, engineering calculations, and construction administration requirements. Manufacturing systems are structured around production control. The information required by an Authority Having Jurisdiction is often entirely different from the information required to operate a factory.

The CTO future I would like to see recognizes that project BIM and manufacturing BIM are separate but connected environments.

• Project BIM should continue to focus on building-wide coordination, compliance, system integration, and project-specific conditions. 
• Manufacturing BIM should focus on product definition, production rules, tolerances, logistics, inspection requirements, and assembly behavior.

Let's not merge these environments into a single model. Let's create a structured relationship between them – and by extension aligning building architect and component manufacturer. That way:

• project BIM defines where systems are deployed, how they interact, and how they satisfy building-wide requirements, while, 
• manufacturing BIM defines how those systems are produced, inspected, transported, and assembled.

Today, ETO often survives in the gap between those two environments. Fabricators reconstruct intent because the relationship between project definition and product definition remains largely manual. A mature CTO environment establishs a reliable framework for translating between them without forcing one to become the other.

Does the machine work in both directions? Can architects/engineers BIM models be productized as a path to CTO? Where do you see architects delineating building-wide compliance responsibilities retained by the AOR/EOR?

I think the industry often assumes productization is simply a matter of moving building information into repeatable assemblies. In practice, the challenge is more complicated because many industrialized building systems are not products in the traditional sense.

• Most conventional products are defined primarily by a single discipline or specialized body of knowledge. A pump, air handling unit, light fixture, fire damper, structural connector, or plumbing fixture can be developed, tested, manufactured, and certified largely within the boundaries of a specific technical domain.
• Many of the systems emerging in industrialized construction are fundamentally different. A bathroom pod, exterior wall panel, MEP rack, patient room headwall, or volumetric module is not a single-discipline product. It is a multi-disciplinary assembly that incorporates architectural, structural, mechanical, electrical, plumbing, fire-resistance, acoustical, accessibility, and life-safety requirements simultaneously.

In many ways, these assemblies begin to inherit the same integration challenges traditionally managed at the building scale. That creates a legible distinction between productization and building integration.

The question is not simply whether architects' and engineers' BIM models can be productized. The question is how much building intelligence can be embedded into a repeatable assembly before the assembly itself starts behaving like a miniature building. Maybe that makes more clear why I believe project BIM and manufacturing BIM should remain distinct environments?

As industrialized systems become larger and more integrated, the responsibility for managing those interactions becomes increasingly important. That is where I see the continuing role of the AOR and EOR. Their responsibility is not simply reviewing individual products. It is ensuring that multiple systems—many of which may already contain architecture, structure, MEP, and fire-protection components internally—work together as a complete code-compliant building.

The critical issue is not whether manufacturers can own more scope. They already do in many industrialized systems. The critical issue is determining where responsibility for system-to-system interfaces, building-wide compliance, and performance integration resides. Integration is where the greatest risk remains. A bathroom pod may be fully engineered. A volumetric module may be fully engineered. A façade panel may be fully engineered. Yet the most difficult questions often arise where those systems connect to one another and where they connect to the building as a whole.

As delivery becomes increasingly productized, I see architects and engineers shifting from component authorship toward interface management, compliance integration, and system orchestration. Their value increasingly lies not in defining every part of every assembly, but in ensuring that independently developed systems collectively satisfy the requirements of a complete building.

The future challenge is not determining how to productize buildings. It is determining how to manage the growing overlap between product responsibilities and building responsibilities as assemblies become increasingly integrated and multidisciplinary.

I think that's why you're on the CfOC-ICC-1220 consensus committee. We're system-itizing that integration. Switching gears. We've talked in the past about why productization is the pathway to greener building practices. Why do you think architects' lifecycle analysis still rely on generalized assumptions — rather than verified manufacturing, transportation, and material data? Is that a CTO value-add your clients would value?

Well. Everything is a one-off. Buildings are still being evaluated as isolated projects rather than as components within a larger industrial ecosystem. Look at the lifecycle software. Those tools operate at the level of project representation: walls, doors, roofs… all site assemblies. They are effective at categorizing materials and assemblies, but they remain disconnected from how systems are actually manufactured, packaged, transported, stored, sequenced, and assembled under real delivery conditions.

In production, the environmental drivers are often manufacturing efficiency, packaging strategies, transport sequencing, temporary storage, overproduction, re-handling, and downstream rework. Those impacts are significant, but because they are distributed across fragmented supply chains, they rarely appear clearly inside conventional lifecycle models.

So the issue is that these tools are operating at the wrong resolution. Lifecycle calculations must rely heavily on generalized EPDs, average transport assumptions, and standardized material categories that smooth out the variability of actual production systems. The pivot to productization will transform a lot of these general assumptions into specific product definitions. Then my distinction between project BIM and fabrication-oriented BIM matters again.

If systems are standardized and repeatable, lifecycle analysis can begin using measured manufacturing and logistics data rather than generalized assumptions. Environmental performance becomes tied to actual production behavior.

For clients, the value of CTO is therefore not limited to sustainability reporting. It is the convergence of environmental performance with operational predictability: cost certainty, procurement reliability, scheduling stability, insurability, and regulatory confidence.

Once lifecycle analysis is tied to real production systems rather than generalized assumptions, it becomes far more than a reporting tool. It becomes part of the same decision infrastructure used to evaluate whether systems can be deployed reliably at scale.

Your firm is one of the few continually offering to design repeatable systems rather than one-off solutions. It's like trying to nudge clients from ETO into CTO. How does DF&A straddle that? And respond to your calls for standardized detailing and interfaces? How does that strategy play into your vision for CTO marketplaces... allowing meaningful evaluation of long-term performance, adaptability, and sustainability?

The work is less about inventing a new architecture and more about formalizing something architecture has always done when it performs well: developing repeatable systems of detailing, refinement, and validation.

Early in my career, working in offices like Richard Meier’s, I saw how disciplined detailing created consistency across projects. Systems were not reinvented each time—they were refined through repetition.

Later, projects like the Sackler Center at the Brooklyn Museum reinforced something equally important: drawings are not enough. We relied heavily on iterative physical mockups because performance only becomes fully legible when tested against reality.

That experience still shapes how I approach systems today.

The focus now is on developing repeatable assemblies through direct collaboration with fabricators, engineers, consultants, and manufacturers—standardized interfaces, validated assemblies, and iterative prototyping when necessary to confirm real-world behavior. At DF&A we stop asking only whether something can be built and start asking:

•  How repeatable is it?
•  How adaptable is it?
•  How reliably does it perform?
•  How efficiently does it move through manufacturing and logistics?
•  What are the lifecycle implications?

That is where CTO marketplaces become meaningful. We're not aiming for catalogs of products, but as ecosystems of validated systems with known performance, constraints, and implementation logic.

Great chat Jason! You know my standard closing question: “What should I have asked you?”

A question I think is ultimately more important than any individual technical issue is this: “What is actually preventing the built environment from improving at the scale we now require?” Because after working across architectural practice, R&D, fabrication coordination, modular high-rise delivery, manufacturing partnerships, and education, I've come to believe that most of the industry's biggest challenges are no longer primarily technical challenges.

• We know how to design buildings.
• We know how to engineer structures.
• We know how to manufacture components.
• We know how to model performance.
• We know how to calculate carbon.
• We know how to finance projects.
• And we know how to regulate them.

Yet housing shortages persist. Construction productivity remains stagnant. Carbon targets continue to be missed. Project costs continue to rise. Delivery schedules continue to lengthen. Approval pathways continue to become more complex.

The reason is that these problems no longer live inside individual disciplines. These problems live between disciplines. Most delivery risk lives in the space between systems, not within the systems themselves. In many ways, that has become the central lesson running through both practice and education.

At Danny Forster & Architecture, much of our work has focused on developing repeatable system approaches, standardized interfaces, fabrication-aligned detailing, and coordination methodologies that can operate consistently across multiple projects rather than being reinvented each time. The objective is not simply better buildings. It is creating more predictable delivery ecosystems.

The same idea has shaped my teaching at the New York Institute of Technology. Traditional environmental systems education teaches students that buildings function as interconnected systems. Mechanical systems affect energy performance. Envelope design affects HVAC loads. Site design affects environmental behavior. Then you can see some student eyes light up as they take the relationships further:

• Structure affects transportation.
• Transportation affects module dimensions.
• Module dimensions affect fire strategy.
• Fire strategy affects inspections.
• Inspections affect approvals.
• Approvals affect financing.
• And financing ultimately affects whether the project gets built at all.

Of course, that perspective has also informed my work with the Center for Offsite Construction and the Modular Building Institute's Offsite Construction Professional curriculum, where the focus has been translating real-world manufacturing, compliance, logistics, coordination, and delivery requirements into educational frameworks that better reflect how industrialized construction actually operates.

Because the industry still tends to educate around fragmented scopes while increasingly asking professionals to work inside integrated ecosystems.

This work with the CfOC and ABOCE is where the real transition is underway. The future of architecture and engineering may depend less on producing project documentation and more on helping define the systems, standards, interfaces, and governance structures that allow increasingly complex delivery ecosystems to function coherently.

The industry often talks about innovation as though it is a technology problem, I think it is increasingly a systems alignment problem. The challenge facing the built environment is not simply creating better products, better software, better codes, or better buildings. It is creating better relationships between them.

We're making it happen at the CfOC! So, perhaps the more important question is not, "whether industrialized construction is coming," but “whether architects, engineers, manufacturers, regulators, educators, lenders, insurers, builders, and owners are willing to stop optimizing individual parts of the system and begin designing the ecosystem itself?” Organizations that learn to think in systems rather than silos will not simply adapt to the future of the built environment, they will define it.