Initial sketches in notebooks and tracing paper, conceptual diagrams, perspectives, physical models, and massing studies capture the architectural imagination. But they represent only the beginning of the practice. The real challenge is translating ideas into buildable systems. Every wall, junction, and assembly must be resolved in detail, with systems working together in a way that allows the project to be built as intended. This is where most of the effort, complexity, and risk are concentrated, and where projects are ultimately resolved or begin to stumble.
It is in this context that the Design Development (DD) and Construction Documentation (CD) take place, when the project must address the full weight of coordination, components, performance, and constructability. While schematic design defines spatial and formal directions, DD and CD demand answers to a different set of questions: how do systems come together? How is performance maintained at transitions? Which products, tolerances, and sequences will allow the project to hold together as it moves from model to construction?
These stages carry the bulk of effort and cost. Estimates suggest roughly 70 to 75% of a building's development time and fees occurs during DD and CD and, paradoxically, it is precisely in this interval that some of the most significant gaps in technological support still persist in contemporary practice.
The Most Demanding, Least Supported Phases
Even with widespread BIM adoption and a proliferation of digital tools, the transition from model to technical documentation remains fragmented. Rework is common, and teams still rely on knowledge scattered across multiple sources. It is at this point that D.TO (Design Together) enters the discussion, proposing a support layer embedded within the BIM environment, designed to structure the flow of decisions, information, and knowledge that underpin these phases. The platform focuses on a specific problem: the concentration of technical and cognitive effort within DD and CD. If these phases carry the weight of architectural work, they should be supported by tools shaped by the realities of detailing, coordination, specification, and internal collaboration.
A familiar pain point for architects emerges here. A project may move smoothly through conceptual and schematic phases, only to encounter friction when it needs to be worked out in detail and translated into construction. A wall is no longer just a wall. It is structure, insulation, air and water barriers, fastening systems, finishes, tolerances, and maintenance logic. A parapet is no longer a clean line on an elevation, becoming the convergence of waterproofing, drainage, thermal continuity, edge conditions, and façade coordination. Multiply these moments across a full drawing set, and it's easy to see why technical rigor alone isn't enough: architects also need the right knowledge at the right time.
Hidden Cost of Dispersed Knowledge and the Limits of Digital Workflows
This is precisely where contemporary practice still struggles. The information exists, but it is rarely accessible when it is needed most. Technical reasoning is distributed across BIM models, manufacturer documentation, spreadsheets, internal standards, consultant comments, annotated PDFs, and informal exchanges between team members. Firms accumulate years of technical knowledge through past projects, yet applying it efficiently remains a challenge. Teams often end up searching for references, recreating solutions that have already been resolved, or relying on the availability of someone who can guide the decision.
Despite BIM's promises, true integration in this phase remains elusive. The idea that embedding more intelligence in early models would streamline later phases has not fully materialized, and conflicts and inconsistencies still emerge. Models have become more sophisticated, but the transition from design intent to construction documentation continues to demand significant effort, with architects still investing considerable time in producing and coordinating details, often using methods that have evolved far less than the discourse around innovation suggests.
The relevance of D.TO lies precisely in how it addresses this unresolved transition. The platform is designed to operate within the BIM workflow, particularly in Revit, as a structured system supporting technical development. It analyzes sections and project conditions to identify critical transitions, organizing "design sessions" around them. As Youngjin Lee, AIA, co-founder of D.TO, explains, "There is a huge gap between the model and the level of detail required for construction documentation, and that's where architects are doing most of the heavy lifting." From there, it acts as a mediation layer between the model, technical knowledge, and design decisions, bringing construction references, performance guidelines, firm knowledge, and product information directly into the context of the detail.
In practice, D.TO pinpoints areas that need further resolution, like façade transitions or parapet conditions. Drawing on the materials and systems already defined, it interprets these situations and brings forward relevant performance guidelines and detailing strategies. Architects can adapt these to the project's specific needs, using pre-developed detail drawings that can be edited, incorporated directly into documentation sheets, or exported into formats such as DWG and Revit view, allowing teams to move more efficiently from resolution to production. Information, components, and details can then be integrated into the documentation workflow, reducing the need for manual reconstruction and improving consistency across project phases.
Because design sessions stay linked to model elements, decisions can be developed, revisited, and refined without losing context. Another key aspect lies in how the platform is beginning to incorporate collaboration into the detailing process. Currently under development and expected to be released in late 2026, this feature is designed to allow senior architects, consultants, and even manufacturers to interact directly within these evolving conditions, moving beyond traditional PDF markups and informal exchanges.
Rethinking Artificial Intelligence in Practice
In recent years, much of the discussion around artificial intelligence in architecture has focused on tools focused on early conceptual stages, often associated with image generation and formal exploration. While these tools offer exciting possibilities, they also raise questions about the architect's role, the reliability of generated solutions, and the growing gap between image and construction.
D.TO positions itself differently. It does not aim to automate architecture broadly or produce ready-made solutions disconnected from technical realities. Instead, its AI is grounded in practice: it reads drawings, retrieves relevant references, and integrates firm knowledge, performance criteria, and product information in a contextualized way.
Here, AI operates less as authorship and more as support. It structures the technical work involved in searching, organizing, comparing, and delivering information, while preserving the architect's role in decisions that require judgment, adaptation, and responsibility. In a field where debates about AI swing between enthusiasm and concern, this approach points toward strengthening architectural knowledge through its application in practice.
This also reshapes how knowledge circulates within offices. As Youngjin Lee observes, "In DD and CD, design extends beyond concept development to include searching, organizing, validating, and applying information through coordinated drawings and models." In many teams, technical development still depends on proximity to experience, where a senior architect reviews a drawing, identifies a missing layer, recalls a prior solution, or flags a recurring issue. While this exchange remains essential, it becomes increasingly difficult to sustain under tighter deadlines, distributed teams, and greater specialization.
D.TO transforms dispersed knowledge into a structured and accessible system integrating firm-specific libraries, past project details, technical standards, and mentorship content directly into the design environment. This information becomes embedded within the workflow itself, rather than existing as static folders, disconnected files, or institutional memory held by a few individuals. For early-career architects, this shifts the nature of learning. Instead of relying solely on periodic corrections, knowledge becomes available within the context of work itself, turning each detail into an opportunity for understanding. For firms, it creates the possibility of transforming accumulated knowledge into an active resource rather than a dispersed collection of files across fragmented systems.
Where Architecture Actually Happens
For years, digital innovation in architecture has focused on image production, formal exploration, or construction management. Yet for those working within practice, it is clear that architecture is largely defined elsewhere: in the dense technical core where projects must become coordinated, executable, and precise. If architecture is ultimately judged not only by its ideas but by how they are built and endure, then DD and CD deserve more than improvisation and excessive effort. They require tools that recognize their complexity and operate within it. What makes D.TO compelling is precisely that it does not attempt to bypass this complexity, but to engage with it directly.
The bigger question isn't whether technology can replace architects, but whether it can finally support the parts of practice that have long depended on manual effort and constant oversight. A broader pattern reveals this paradox: AI has advanced rapidly in generating images, text, and even music, while much of the everyday work that demands time, effort, and repetition remains largely manual. In many ways, it has absorbed the more visible and representational aspects of work, while leaving the more technical and time-intensive tasks to humans.
In architecture, a similar pattern emerges. The future of intelligence in architecture may not lie in producing more images, more quickly, but in building better systems to translate design intent into technical clarity, and in making that knowledge more accessible, shareable, and enduring across practice.
