The research-to-output cycle in architecture spans the full project delivery sequence: from the first programming conversations with the client through to construction documentation, permit approval, and construction administration. This is a cycle measured in years for most projects, and the output — a built building — must meet design intent, code requirements, and constructability standards simultaneously.
The workflow described here addresses the failure modes that occur specifically in architectural research-to-output: design decisions made without adequate precedent research, code requirements that drift between phases, specification decisions made without adequate product research, and project-accumulated knowledge that disappears into the project file at closeout rather than feeding into the firm's knowledge base for the next project.
The Four Research-to-Output Failure Modes in Architecture
Failure 1 — Design decisions without documented precedents. A facade system is chosen because the design team finds it attractive, but the research record doesn't document what precedents informed the choice or what performance characteristics were evaluated. When the client challenges the choice, or when performance issues arise in construction, the design team can't reconstruct the basis for the decision.
Failure 2 — Code compliance drift between phases. A code requirement is correctly identified in schematic design but isn't updated when a design element changes in design development. By the time construction documents are complete, the design may no longer comply with the requirement it was verified against in schematic design.
Failure 3 — Specification decisions without product research documentation. A product is specified because it was used on a prior project, but the specification doesn't document that the product was re-verified for currency and current technical data. If a product has changed or been discontinued since the prior project, the specification may be incorrect.
Failure 4 — Knowledge not routed after project completion. The design research, code interpretations, product performance observations, and building type lessons accumulated on a project go into the project file at closeout and aren't organized for retrieval on the next similar project.
Stage 1: Programming and Project Inception Research
Every project begins with research into what the project needs to be — its functional requirements, regulatory context, site characteristics, and the precedents that define success for this building type.
PROJECT INCEPTION RESEARCH — [Project name, Date]
PROJECT TYPE: [Building type]
CLIENT: [Client organization type — owner/developer/public agency/institution]
JURISDICTION: [City/State — for code research]
SITE: [Location, size, constraints]
PROGRAM RESEARCH:
What functional requirements has the client described?
What published standards or guidelines apply to this program type?
(e.g., healthcare: FGI Guidelines; education: state education standards)
What are the key adjacency and relationship requirements?
REGULATORY RESEARCH:
Zoning: [Zoning classification + key development standards — density, height, setbacks, use]
Building code edition applicable: [The specific edition in effect for this jurisdiction]
Special use permits or variances required? [Yes/No + what]
Historic review required? [Yes/No + what authority]
Environmental review required? [Yes/No + what triggers CEQA/NEPA]
PRECEDENT RESEARCH:
What buildings of this type have solved similar problems well?
Knowledge base check: [What does the firm's KB have for this building type?]
Key precedents identified: [3-5 buildings + what each illustrates]
PRE-PROJECT KB CHECK:
Building type knowledge retrieved: [What's available from prior projects]
Code/jurisdiction knowledge retrieved: [What's known about this jurisdiction]
Gaps requiring fresh research: [What needs to be researched for this specific project]
The programming and inception research identifies both what's already known (from the knowledge base) and what's specific to this project that needs to be freshly researched.
Stage 2: Schematic Design Research
Schematic design is where the fundamental organizational and massing decisions are made. The research that informs these decisions — site analysis, precedent studies, structural systems research, MEP systems research — needs to be documented alongside the decisions themselves.
SCHEMATIC DESIGN RESEARCH DOCUMENTATION — [Date, SD Phase]
DESIGN CONCEPT:
Core concept: [What is the organizing design idea?]
Precedent basis: [What precedents informed this concept? — reference to KB entries or captures]
SITE ANALYSIS:
Site conditions documented: [Sun, wind, views, topography, context]
Site analysis sources: [How was this information gathered?]
How site analysis informed design: [Specific connections between site data and design decisions]
MASSING AND ORGANIZATION:
Key massing decisions: [What massing approach was chosen and why]
Alternatives considered: [What other approaches were studied]
Rationale for selection: [Why the chosen approach was preferred]
STRUCTURAL SYSTEMS STUDY:
Structural system options studied: [What options were evaluated]
Structural engineer input: [What the SE recommended and why]
System selected: [Which system and the basis for selection]
MEP SYSTEMS STUDY:
Key MEP systems questions: [What systems issues affect the floor plan organization]
MEP engineer input: [What the MEP engineers advised regarding space requirements]
CODE COMPLIANCE CHECK — SCHEMATIC DESIGN:
[ ] Occupancy classification confirmed: [What + code basis]
[ ] Maximum building area and height checked: [What + code basis]
[ ] Number of required exits confirmed: [What + code basis]
[ ] Egress paths shown schematically: [Are they viable for the proposed layout?]
[ ] Accessible route from site to all areas confirmed possible: [Yes/No]
[ ] Sprinkler system required: [Yes/No + code basis]
Notes on any code compliance issues identified in schematic design:
SCHEMATIC DESIGN DECISIONS LOG:
[Decision 1: What was decided + alternatives considered + rationale]
[Decision 2: ...]
The code compliance check at schematic design establishes the compliance baseline that subsequent phases build on. Changes in design development that affect code compliance need to be rechecked.
Stage 3: Design Development Research and Documentation
Design development resolves the schematic design decisions into coordinated building systems, detailed spatial organization, materials selections, and preliminary specifications.
DESIGN DEVELOPMENT RESEARCH — [Date, DD Phase]
BUILDING ENVELOPE RESEARCH:
Wall system selected: [System + references to technical research]
Glazing system selected: [System + references to technical research]
Roofing system selected: [System + references to technical research]
Product research completed: [Products verified current + technical data current]
INTERIOR MATERIALS RESEARCH:
Key interior materials selected: [What + technical references]
Product research documentation: [Reference to KB entries for specified products]
SPECIFICATIONS RESEARCH:
Spec sections applicable to this project: [List of applicable CSI sections]
Master spec sections used: [Which firm master specs are starting points]
Product research for non-standard specifications: [What needed fresh research]
CODE COMPLIANCE CHECK — DESIGN DEVELOPMENT:
[ ] Any changes from SD that affect code compliance identified?
If yes: [Describe changes and code implications]
[ ] Egress paths still viable with DD layout: [Confirmed]
[ ] Accessibility: accessible routes, signage, and facility requirements confirmed: [Confirmed]
[ ] Fire rating requirements for wall assemblies identified: [What ratings are required where]
[ ] Exit signage and emergency lighting locations identified: [Confirmed]
[ ] Energy code compliance path confirmed: [Prescriptive or performance + basis]
DESIGN DEVELOPMENT DECISIONS LOG:
[Decision 1: What was decided + technical basis + alternatives considered]
[Decision 2: ...]
Stage 4: Construction Documents Research and Verification
Construction documents translate the design into the instructions contractors use to build. This phase requires comprehensive code verification, specification completion, and detail documentation.
CONSTRUCTION DOCUMENTS QUALITY REVIEW — [Date, CD Phase]
CODE COMPLIANCE FINAL VERIFICATION:
[ ] All occupancy classifications confirmed on drawings: [Yes]
[ ] Construction type confirmed on drawings: [Yes]
[ ] All egress paths verified against final plan: [Travel distances measured + confirmed]
[ ] All egress widths verified: [Calculated + shown on drawings]
[ ] All required fire ratings shown: [On wall types, floor assemblies, door schedules]
[ ] Sprinkler drawings coordinated with architectural: [Confirmed with sprinkler engineer]
[ ] Accessibility: all accessible routes, parking, entrances, facilities verified: [Confirmed]
[ ] Energy code compliance documentation complete: [Required forms complete]
SPECIFICATIONS QUALITY REVIEW:
[ ] All specified products current as of this submission: [Verified — date of verification]
[ ] Substitute product provisions clearly written: [Yes]
[ ] Performance requirements clearly stated for all custom or complex specifications: [Yes]
[ ] Division 01 specifications complete: [General conditions, temporary facilities, closeout]
COORDINATION REVIEW:
[ ] Architectural drawings coordinated with structural: [Confirmed with SE]
[ ] Architectural drawings coordinated with MEP: [Confirmed with MEP]
[ ] Civil coordination confirmed: [Site grading, utilities, accessible routes]
[ ] Specifications coordinated with drawings: [Products in specs match drawings]
Stage 5: Construction Administration Research
Construction administration generates the most research in the shortest time: contractors submit RFIs and submittals that require technical research to respond to, often on short timelines.
RFI RESEARCH LOG — [Project name]
[RFI Number] — [Date received] — [Contractor question]
Research performed:
[ ] Drawing clarification needed: [What drawings address this?]
[ ] Specification clarification needed: [What spec section addresses this?]
[ ] Code basis check: [Is this a code compliance question? What does the code say?]
[ ] Product substitute evaluation: [If contractor is proposing a substitute — technical comparison]
Research sources:
[Source 1: What was checked and what was found]
[Source 2: ...]
Response:
[What was answered and the basis for the answer]
SUBMITTAL REVIEW LOG — [Project name]
[Submittal Number] — [Type] — [Date received]
Review:
[ ] Compliant with specifications: [Yes/No — what specifically]
[ ] Action: [Approved / Approved as noted / Revise and resubmit / Rejected]
[ ] Any deviations noted: [What deviations from specified requirements]
[ ] Research required: [Was additional technical research needed to review?]
Stage 6: Post-Project Knowledge Routing
After project completion — or after a significant design phase milestone — route accumulated project knowledge to the firm knowledge base.
POST-PROJECT KNOWLEDGE ROUTING — [Project name, Date]
BUILDING TYPE KNOWLEDGE BASE:
[ ] Building type entry updated with lessons from this project
[ ] What worked: [Successful design strategies, specification approaches, coordination methods]
[ ] What didn't: [Issues encountered, what would be done differently]
[ ] Key RFI and CA issues: [What came up in CA that should inform future similar projects]
MATERIALS AND SPECIFICATIONS KNOWLEDGE BASE:
[ ] New product entries created for products researched for this project
[ ] Existing product entries updated with field performance observations
[ ] Any products that should be removed from the firm's recommended list (and why)
CODE AND REGULATORY KNOWLEDGE BASE:
[ ] Any new code interpretations or jurisdiction-specific experiences documented
[ ] Plan check experiences: what comments were received + how they were resolved
[ ] Any code issues that required research during the project → documented for future reference
DESIGN REFERENCE LIBRARY:
[ ] Any design solutions from this project worth adding as references for future work
[ ] Design decisions made + what they illustrate → documented as potential precedents
FIRM MASTER SPECIFICATIONS:
[ ] Any specification improvements identified during this project → submitted for master spec update
[ ] Any products that should be added to or removed from the firm master specs
A Worked Example: Mixed-Use Residential Project
Context: a mid-size firm is designing a 5-story mixed-use building with ground-floor retail and upper-floor apartments, in a city they've worked in before on similar projects.
Project inception (Week 1-2): The knowledge base check retrieves the firm's prior mixed-use residential project files. Two prior projects provide building type knowledge (typical program, zoning approach, structural systems used). The jurisdiction knowledge base has notes on the local building department's plan check review emphasis and local code amendments. The pre-project check identifies gaps: this project's zoning classification is different from prior projects, requiring fresh research.
Schematic design (Weeks 3-8): Design precedents from the design reference library in "multi-family residential courtyard organization" and "ground-floor retail activation" inform the organizing concept. The code compliance check at SD establishes the construction type, occupancy classifications, and egress approach. SD decisions are logged: the massing strategy, the structural system selection, and the basis for each.
Design development (Weeks 9-16): Product research is performed for the primary exterior cladding material — the firm used a product on a prior project that's being considered again. The knowledge base check on that product shows the last verification was 22 months ago; the product is re-verified (still current, specifications unchanged). The DD code compliance check identifies that a design change shifted an egress corridor, requiring a travel distance recalculation.
CDs and CA: The specification quality review verifies all products are current. During construction administration, a major RFI from the contractor concerns a roofing product substitution — the original product has a 14-week lead time. Research is performed on the proposed substitute, documented in the RFI research log, and the response documents the technical comparison and the basis for accepting or rejecting the substitute.
Post-project routing: The building type knowledge base is updated with lessons from this project. Two products that performed well in CA are added to the materials knowledge base with positive field observations. The local code amendment that was identified in zoning research is added to the jurisdiction knowledge base for future projects.
Key Takeaways
-
The architectural research-to-output workflow has six stages. Programming and inception research (program + regulatory + precedent + KB check), schematic design documentation (design concept basis + structural/MEP systems + code compliance check), design development (envelope/materials + specifications + code compliance update), construction documents (comprehensive code verification + specifications currency check + coordination confirmation), construction administration (RFI and submittal research documentation), and post-project knowledge routing.
-
Code compliance is verified at each design phase, not just at CD completion. Design changes in each phase are assessed for code compliance implications. Finding a code compliance issue in schematic design is a design adjustment; finding it during plan check is a redesign.
-
Product research is re-verified before every specification. Products last researched more than 18 months ago are re-verified before re-specification. Products change; assuming current knowledge of a product used on a prior project creates specification errors.
-
The design decision log at each phase documents what was decided, what alternatives were considered, and why the decision was made. This documentation protects the design team when questions arise and enables the post-project lessons to be specific and applicable.
-
Post-project knowledge routing is the discipline that makes each project compound into firm intelligence. Without it, each project is an isolated output. With it, each project adds to the building type knowledge, materials knowledge, code knowledge, and design reference library that make the next similar project faster and more reliable.
Conclusion
The research-to-output workflow for architects creates the infrastructure for design practice that is both creatively grounded and technically reliable: design decisions documented with their precedent basis, code compliance verified at each phase, specifications grounded in verified current product knowledge, and project-accumulated knowledge routed back into the firm knowledge base after each project. The discipline at each stage is incremental; the compound return across multiple projects and building types is what distinguishes experienced firms from those that approach each project as if they've never done this type of work before.
For more on this, see Web Clipping vs. Bookmarking.