How Terran Robotics Approaches Structural Quality Assurance

Structural quality assurance in conventional construction is a sampling-based system. Special inspections under IBC Section 1704 require a qualified inspector to be present at designated structural milestones - high-strength bolting, welding, concrete placement, masonry construction - and to document that the work at those milestones meets specification. Between inspections, no systematic quality verification occurs. The inspector sees a sample; the rest of the work is governed by the superintendent's judgment and the crews' skill.

Autonomous construction generates continuous data. Every element placed by a Terran robot has a placement record: as-built coordinates, timestamp, material batch identifier, and a photograph from the end-effector camera at the moment of placement. This is not a better version of sampling-based inspection - it is a different model entirely, with different capabilities and different assurance implications.

What Continuous Placement Records Actually Capture

The placement record for each structural element includes several data fields that have no equivalent in conventional inspection. The as-built position, measured by the robot's position control system, captures where the element actually ended up versus where the design specified it should be. The deviation is computed automatically and flagged if it exceeds the tolerance threshold for that element type.

The timestamp creates a chain-of-custody record for the construction sequence. For concrete-critical work - situations where element A must be completed and cured before element B can be placed - the timestamps verify that the required sequence was followed and that adequate time elapsed between placements. This type of sequence documentation is rarely available in conventional construction and can be significant in forensic analysis when construction defect claims arise years later.

The material batch identifier links each placed element to the specific material lot from which it came. For masonry projects, this means each brick can be traced to a specific pallet from a specific kiln run from a specific manufacturer. If a material quality issue is identified after construction - a common scenario in masonry where efflorescence or spalling can indicate manufacturing defects in a specific production batch - the QA system can identify which walls used material from the affected batch and which did not.

Computer Vision QA: What the Cameras Actually Detect

The overhead drone and fixed camera array that operates during Terran deployments uses computer vision models trained on construction defect categories. The current detection capabilities include: mortar joint width deviations beyond specification, missing or misplaced mortar at header courses, stud spacing deviations in framing, missing blocking requirements that are visible before sheathing, and anchor bolt position deviations on mudsills.

The detection accuracy for these categories in field conditions is 87 to 94% across our validation data set, measured against manual inspection as ground truth. False positive rates run 3 to 8% depending on lighting conditions and camera angle coverage. All computer vision flags are reviewed by the human supervisor before generating a formal defect report; the system surfaces anomalies for human judgment rather than making autonomous pass/fail determinations on structural elements.

This human-in-the-loop design for QA determinations is deliberate. The liability implications of a false negative - failing to detect a real defect - are significant in construction. Until the computer vision detection accuracy reaches the level that a licensed special inspector would require to stake their professional liability on, the system operates as an augmentation of human inspection rather than a replacement for it.

IBC Section 1704 Compliance Integration

Special inspections under IBC 1704 require specific documentation: the inspector's name and credentials, the scope of inspection, the specific inspection type (continuous or periodic), the results of each inspection, and the Statement of Special Inspections signed by the registered design professional. Terran's QA package is designed to satisfy most of these requirements for the structural elements that robotic systems place.

The compliance picture varies by jurisdiction. Some building departments have accepted Terran's documentation package as satisfying special inspection requirements for masonry and framing, reducing the number of required human inspector visits from the conventional 15 to 25 per project to 4 to 6 milestone inspections. Others have required a human special inspector to be present for all designated structural milestones regardless of the robotic documentation. As of mid-2024, Terran is working with building officials in Arizona and Nevada on a formal protocol for robotic construction inspection compliance that, if adopted, would provide regulatory certainty for builders in those markets.

Defect Resolution Workflow

When the QA system identifies a defect - a wall course that is 4mm out of plumb beyond tolerance, a brick joint that is visibly wider than specification - the defect is logged with its location coordinates, a timestamp, and the photographic evidence. The defect report is presented to the site supervisor on the Fleet Command Center dashboard, prioritized by defect severity.

For positional deviations discovered during construction, the robot can be directed to make corrections before the next course is placed if the deviation is within the system's correction capability. For defects discovered after placement, the defect report includes a remediation recommendation generated by the planning system - typically specifying the re-work scope, the order in which re-work tasks should proceed, and the inspection point for re-verification. The supervisor approves or modifies the remediation plan before it is executed.

Tracking defect rates by project, by robot unit, by material batch, and by environmental conditions has produced operational insights that have improved system performance over time. Defect rates in Terran deployments have decreased 31% from the earliest deployments to the most recent, reflecting improvements in the robot control system calibration protocols and in the pre-deployment BIM audit process that now catches coordination issues before they manifest as field defects.

The Build Record as a Project Asset

The QA documentation package produced at project close has value that extends beyond construction inspection compliance. Lenders providing construction-to-permanent financing have found the timestamped build records useful for draw inspection purposes - they can verify that specified work was completed without visiting the site during the construction period. Owner-builders who are also the property's future owner have a complete record of every structural element in their building that supports future renovation planning and warranty claims.

Terran's standard project delivery includes a digital build record package containing the as-built IFC model, the placement records database, the QA flag log with resolutions, and a photographic archive indexed by location and date. This package typically runs to 15 to 40 GB of data depending on project size and camera coverage. It is stored in the Terran cloud platform with the project owner as the primary data custodian and Terran retaining a copy for system improvement purposes under the terms of the deployment agreement.

What the System Cannot Currently Detect

Honesty about limitations is important in QA contexts. The current computer vision system cannot reliably detect subsurface defects - voids in grouted masonry cells, internal concrete segregation, hidden fastener issues beneath sheathing. These inspection categories require methods beyond visual inspection - X-ray, ground-penetrating radar, impact echo testing - that are not part of the standard Terran deployment. For projects where subsurface inspection is required by design or code, conventional special inspection methods must be used for those specific elements.

The system also cannot detect defects that develop after the robot's placement record is created. Mortar that appears properly placed at the time of placement but fails to achieve adequate compressive strength due to temperature extremes during the cure period is not detectable by the placement record alone. The platform recommends supplemental mortar cube testing on projects where cure condition data indicates elevated failure risk, but this is advisory rather than automated.

← Back to Blog