Every layout is a pull request.
Who This Matters To (And Why)
Critical: Architect,Developer,GC. These parties make or lose money directly based on this thesis.
Important: Engineer,Banker,Interior Design. These parties execute decisions shaped by this thesis.
Context: City,Investor,Inspector. These parties need to understand it to avoid friction.
Highest typology impact: Multifamily,Office,Mixed Use,Industrial. Lower impact: Hotel,Retail.
Every layout iteration is a pull request. Review, merge, or reject.
How It Shapes Development
Every layout is a pull request because it is a proposed change to the building model that must be reviewed, approved, and merged before it becomes the official design. A pull request in software development says: here is a change I propose to make to the codebase. Here is what it adds, what it removes, and what it affects. Please review it. A layout submission says: here is a proposed arrangement of spaces. Here is what it achieves relative to the program, what constraints it satisfies, and what tradeoffs it makes. Please review it. The review process in both cases is the mechanism for maintaining quality and coherence in a shared artifact.
Design review is code review. A principal reviewing a junior architect's floor plan is doing the same cognitive work as a senior engineer reviewing a junior developer's pull request: checking that the proposed change satisfies the requirements, doesn't introduce conflicts with adjacent work, follows established conventions, and is legible enough that future maintainers can understand the intent. The language is different — one uses architectural terminology, the other uses programming terminology — but the activity is the same. Both are quality gates on a shared artifact.
Revision history in design is version control. The sequence of design options — Option A, Option B, Option A revised, schematic design issue, design development issue, construction documents issue — is a version history of the building model. Each issue is a tagged commit. Each revision is a branch that is either merged (accepted) or abandoned (rejected). Projects that maintain clear revision histories can trace every design decision back to the review that approved it. Projects that don't maintain revision histories cannot reconstruct why a decision was made, which means they relitigate it repeatedly.
Consultant coordination is pull request management across repositories. The structural engineer's model is a separate repository that must stay synchronized with the architect's model. When the architect moves a column, they are making a change that affects the structural engineer's model. The coordination process is the review mechanism for cross-repository changes. A poorly managed coordination process produces the construction equivalent of merge conflicts: two trades whose models are inconsistent, discovered in the field at installation time. Clash detection is automated conflict checking before the pull request is merged into the built building.