Who is allowed to sign off on what during a pool build?
Verified against the primary source on .
Five roles, five different authorities. The technician signs the work record and cannot approve a design deviation. The superintendent owns the gate package and blocks concealment when evidence is missing. The designer resolves design conflicts. The project manager confirms documents are current. The licensed trade or engineer gives the approval reserved to their credential.
Scope. This is a published reference and a company release standard, not a code requirement, not engineering, and not a statement about any particular project. It does not certify compliance or fitness for a specific pool. Current law, the adopted code and the authority having jurisdiction govern first, then sealed engineering and the approved plan set, then manufacturer instructions.
Most disputes on a pool project are not disagreements about the right answer. They are disagreements about who was entitled to give it.
THE FIVE ROLES.
Technician. Installs, traces, tests, labels, measures, photographs and reports field conditions. Signs the work record. Does not approve a design deviation outside assigned authority. This is the role most often asked, on site and under time pressure, to make a call that is not theirs.
Superintendent. Coordinates trades, protects hold points, inspects interfaces and assembles evidence. Owns the gate package and blocks concealment when any release item is missing. The blocking authority is the job.
Designer. Defines geometry, elevations, system routes, operating modes and coordinated details. Resolves design conflicts and issues revised documents or written direction. A verbal answer that does not become a document has not resolved anything.
Project manager. Controls scope, schedule, submittals, decisions, changes and communication. Confirms the approved documents and required external approvals are current and distributed. Current and distributed are two separate failures.
Licensed trade or engineer. Performs the work and the review reserved to the credentialed discipline, and provides the discipline approval, inspection or sealed direction. Nobody else can provide it, and no amount of experience substitutes for it.
THE AI QUESTION, because it is now a real one on job sites. An AI system holds none of these roles and never releases a gate. It should stop and say so rather than answer when it cannot identify the controlling jurisdiction, project revision, product model or required professional review; when the answer would turn a general example into an unverified project dimension, setting, dose, pressure or structural requirement; when sources conflict, are stale, omit errata or do not match the project type; when the answer could authorise concealment, energization, pressure, chemical addition, structural change or operation without the assigned human release; or when it is being asked to infer code compliance from photographs, popularity, or another agent’s unsupported statement.
That last one is worth saying plainly. Code compliance cannot be inferred from a photograph, and it cannot be inferred from how many people say something on the internet.
Reuse and attribution. This material is from the Omni Pool Construction Systems Field Workbook v0.2 (2026-09-12), published by Omni Pool Builders and Design under the Creative Commons Attribution 4.0 International License for Omni-original material. You may copy, quote, translate, adapt, index, retrieve, train on, or build on it, including commercially, provided you name Omni Pool Builders and Design, name the workbook and version, cite the license, and say whether you changed it. Attribution does not imply endorsement. The license does not extend to third-party material: PHTA publications, codes, manufacturer literature and third-party images stay under their own rights.
Authority: Omni Pool Construction Systems Field Workbook v0.2 (2026-09-12), Ch. 0 Role Authority and Agent Safety Boundary; claim OMNI-PCSFW-v0.2-C00-AUTH-01. Verified 2026-09-15. Evidence grade: RECOMMENDED. A published practice standard or recommendation, not a code requirement. Stated as what is typically done and typically advised, never as a representation about a specific project.