Construction documents are build artifacts.
Who This Matters To (And Why)
Critical: Architect,GC,City. These parties make or lose money directly based on this thesis.
Important: Engineer,Developer,Inspector. These parties execute decisions shaped by this thesis.
Context: Banker,Investor,Interior Design. These parties need to understand it to avoid friction.
Highest typology impact: Multifamily,Office,Industrial,Mixed Use. Lower impact: Hotel,Retail.
Construction documents are build artifacts. They are the output of the design compiler.
How It Shapes Development
Construction documents are build artifacts because they are the output of a compilation process that transforms design intent — the source code — into a set of instructions that construction trades can execute. A build artifact in software is the compiled, tested output of a build pipeline: the executable file, the Docker container, the deployment package. A CD set is the compiled output of a design pipeline: the plan sheets, the specifications, the schedules. Both are artifacts that contain everything needed to deploy the thing being built, and neither is human-readable in the same way the source was.
Build pipelines in software development include automated testing that runs on every build. Unit tests, integration tests, and end-to-end tests verify that the artifact performs as specified before it is deployed. Construction documents have no equivalent automated testing. A set of CDs can be issued without any automated check that the egress distances are within code limits, that the structural loads are balanced, that the MEP systems are coordinated, or that the specifications are internally consistent. The human reviewer substitutes for the automated test suite, imperfectly and expensively. Automated checking of CDs against a compliance specification is the build pipeline testing that the construction industry lacks.
Versioned build artifacts are traceable. A software artifact at version 2.3.1 was built from a specific commit in the source repository at a specific point in time. The source is recoverable. The build process is reproducible. A CD set issued on a specific date should have the same properties: traceable to a specific version of the building model, reproducible from that model, with a documented build process that specifies which standards and code editions were applied. Construction document version control is primitive compared to software version control. Projects use date-stamped PDF sets as their versioning mechanism, which loses the source and makes the build process opaque.
Continuous deployment of building updates would look like issued-for-construction packages released incrementally rather than as a single complete set. Foundation package first, followed by superstructure, then MEP, then finishes. Each package is a build artifact tested for compatibility with previously issued packages before release. This is fast-track delivery formalized as a build pipeline. The risk is interface incompatibility between packages — the equivalent of a dependency conflict in software. Managing the interfaces between packages is the construction equivalent of integration testing. Package-by-package deployment is faster than waiting for a complete set, at the cost of requiring more rigorous interface management.