Commissioning
Build the equipment turnover register from the drawings, verify startup checklists against the design, and hold each balancing report to the spec tolerance
Commissioning covers the end of the job: every piece of equipment that needs startup, what has to be verified on it, what has to be turned over with it, and whether the balancing reports actually meet the design.
Two views share the instrument, switched at the top right: Equipment and TAB verification.
Everything here is scoped to mechanical, electrical and plumbing equipment. Other disciplines are out of scope for this instrument.
Equipment
Build the register
Press Scan contract documents on the empty state, or Re-scan drawings from the header once the register exists.
STRUX reads the mechanical, electrical and plumbing drawings, pulls the equipment tags and their schedule rows, and writes one row per item. Each item carries its tag, type, discipline, the sheet it came from, its scheduled attributes, and the startup requirements derived for it.
Startup requirements are typed: an inspection, a test, or a documentation deliverable, each with the source it came from.
The register
| Column | What it holds |
|---|---|
| Tag | The schedule mark, for example AHU-1 |
| Equipment | The type |
| System | The system or service the schedule recorded for it |
| Location | The location the schedule recorded, falling back to the source sheet |
| Startup checklist | Not uploaded, Verified, or a count of issues |
| Turnover docs | Received against required |
| Status | Not started, Started, or Turned over |
Verify a startup checklist
You can upload checklists in bulk or one at a time.
- Upload checklists takes as many completed checklists as you have. STRUX works out which piece of equipment each one belongs to, associates it, and verifies it.
- On a single item, Upload & verify checklist does the same for that tag. Once verified, the button reads Re-verify checklist.
A verification compares what the checklist recorded against the schedules, the submittal, and the item's startup requirements, and returns a row per check with what was expected, what was found, and a Pass, Out of tolerance, or Review result.
STRUX reads the first 8 pages of an uploaded checklist. Startup checklists carry their values up front, so this is usually the whole of the relevant content, but a checklist that buries its readings deep in an appendix will not be fully read.
Turnover
Each item tracks the documents the spec requires at turnover against the ones actually received, and shows what is still outstanding. Marking an item Started is a manual action on the item.
TAB verification
Determine what is required
Press Determine required reports on the empty state, or Re-check specs from the header.
STRUX reads the project specifications and lists every testing, adjusting and balancing report the project requires, with the acceptance criteria for each one taken from the spec that governs it. Nothing here is a generic list: an item is on it because a spec section asks for it.
Upload and verify
| Report status | What to do |
|---|---|
| Awaiting upload | Upload the balancing report |
| Uploaded | Run verification |
| Reviewing | The run is in flight |
| Verified or Issues found | View results |
A verification pulls every measured value out of the report, matches each unit to its design schedule, and checks the reading against the spec tolerance. The results table gives one row per unit: Design, Measured, Tolerance, Citation, and the Result.
The citation column is the point of the exercise. Each row says where the design value or the tolerance came from, so a reading you dispute can be checked against the source rather than argued about.
Export PDF report produces the verification as a document you can send.
STRUX reads the first 20 pages of an uploaded TAB report. A long report with its summary tables past page 20 will be verified from the pages that were read, not from the whole document.
Runs
All four operations (equipment scan, report determination, checklist verification, TAB verification) run on the server. Starting one opens a run view showing what the run is doing; the work continues if you navigate away.
All four are metered AI operations and spend project credits. See Billing.
The two verification runs also write into the project's findings queue, so a failing check is triaged in the same place as everything else. Scans do not produce findings. See Findings.
Limits
| Disciplines covered | Mechanical, electrical, plumbing |
| Pages read from an uploaded startup checklist | First 8 |
| Pages read from an uploaded TAB report | First 20 |
Troubleshooting
"No equipment scanned yet." The scan has not been run on this project. Press Scan contract documents.
The scan found nothing, or found too little. The scan reads indexed drawings. Confirm the mechanical, electrical and plumbing sheets show Indexed on the Documents page, then scan again. See Document processing.
Equipment is missing from the register. Equipment is read out of the schedule tables on the drawings. An item that appears only in a plan view with no schedule row is the usual gap. Re-scan after the schedule sheet is uploaded.
A checklist was matched to the wrong equipment. The routing run infers the equipment from the checklist's own contents. Upload that checklist from the specific item instead, using Upload & verify checklist, which pins it to that tag.
A verification reports fewer checks than the report contains. Check the page limits above. The uploaded document may carry its measurements past the pages that are read.
Everything is disabled. You are on the shared demo project, which is read only.