AI Visual Progress Monitoring

A visual progress system earns its place when it produces a call a superintendent can walk to: this zone, this trade, this photo, this date. It fails when it produces a dashboard figure nobody can defend on the floor.

Tools in this class, including Buildots, OpenSpace, Doxel, and Autodesk capture-to-model workflows, compare a 360 walk or a drone pass to a BIM or as-planned model. The product you should demand is not a floor-wide complete number. It is a list of installation states by zone and trade, each row pointing at the image that justified the call. The superintendent still owns that call. The model does not.

If the photo cannot be located, the row stays empty. Empty is the correct state. Filling it from last week's walk, from the model, or from a trade's verbal update creates a second schedule that is not tied to evidence.

Use the same grid the job already uses. Zone names, level, grid lines, and trade packages should match the look-ahead and the cost report. If the vision tool uses its own room IDs, map them before anyone treats the comparison as status.

Capture first. A walker with a 360 camera, a cart, or a drone covers the zones you intend to call this cycle. Interior work usually comes from a 360 walk. Roofs, facades, and large site areas usually come from a drone pass. Either way, the image has to land in a named zone, and the elements have to be visible in that image.

The system then aligns that imagery to the model: which corridor, which elevation, which work package. Comparison is element class against what the camera can actually see: duct, pipe, hanger, cable tray, stud, and similar work with a visible signature in the photo. Hidden work stays a superintendent judgment. It is not something you infer from the model because the model says the element exists.

Work the cycle in a fixed order. Freeze the zone map and trade list for this capture date. Complete the walk or flight. Check alignment before you read any status: if the tool cannot place the camera in the zone, that zone is empty. Compare only visible elements for the trades you are calling. Export rows that include the cite. Then the superintendent confirms, defers, or leaves the row empty.

Call by trade only for that trade's visible scope in that zone. Mechanical in Zone 4B is hangers, mains, and branches the photo can show, set against the elements the current construction model says should be there at this stage. It is not a rolled-up floor status. If the model is still a design model that was never statused for construction, mismatches will look like late work when they are really a baseline problem. Align the as-planned set with the current issued-for-construction package before you treat differences as delay.

A model that still contains unresolved clashes is a poor progress baseline. BIM design clash detection belongs upstream of visual progress. It does not replace the walk.

When you review a mismatch, ask three questions in order. Can I see the element in this capture? Is this the right zone and the right trade package? Is the model the issued construction set for this date? If any answer is no, you do not have a progress call. You have a capture problem, a mapping problem, or a model problem.

Every progress row should carry a cite: capture date, zone, camera location or waypoint, and a still or 360 frame that shows the work. The superintendent opens that cite, not a summary tile. Confirmation is yes, no, or defer. Defer when the photo is occluded, the zone was not walked, or the element is covered.

Here is the loop on one corridor, as an illustration, not as a measured result. Tuesday 360 walk, Level 4, Zone 4B, mechanical. The model shows a run of mains and hangers as the planned install for that corridor. The cited frame at grid D-12 shows hangers still on the deck and the main still on racks. The superintendent confirms: hangers not in, mains not in. Adjacent Zone 4C was on the walk path, but the camera dropped frames under a temporary tent. Zone 4C mechanical stays empty. Nobody copies 4B into 4C. Nobody writes a floor status from those two zones.

That is the whole operating loop: capture, compare, cite, confirm. Project controls can roll confirmed rows into the progress conversation. Unconfirmed and empty rows stay off the pay discussion and off the programme update.

The daily written record still matters. Visual progress does not replace walk notes. Pair confirmed cites with daily site report auto-generation so the narrative and the photo point at the same zones.

Calling a covered install complete is the most common bad call. Insulation, drywall, ceiling tile, and temporary protection hide work the model still lists as visible. A system that scores an element present from an earlier frame, or that treats a covering as proof the work behind it is done, will mark pipe or hangers complete when the superintendent has not seen the joint. If the current capture cannot show the element, the call is empty or deferred, not complete.

Treating a visual figure as a payment certificate is a contract problem, not a software problem. A zone-and-trade comparison is a planning input. Payment still follows the contract: measured quantities, inspector sign-off, and the superintendent's confirmation. Rolling a dashboard figure into a pay application is how you pay for covered, missing, or double-counted work.

Missing a zone because the capture failed looks like silence on the dashboard. Batteries, rain, a locked door, a drone restriction under a crane, a walker who skipped a stair, or a failed alignment to the model all produce the same result: no cite. That zone is not unchanged. It is unknown. Unknown does not inherit the previous cycle. Unknown does not inherit the model's planned state. Put it back on the next walk list.

A quieter failure is updating the programme from the model alone. If the BIM says the corridor should be complete at this data date, that is a plan, not a status. Status comes from confirmed captures. If you need recovery options after a confirmed miss, that is a separate exercise. Use schedule recovery scenario generation from late work you can cite, not from a model-versus-planned variance with no photo.

Empty means no located photo for that zone on this capture cycle, or the photo exists but the element cannot be seen, or alignment failed so you cannot prove which zone you are looking at. Leave it empty. The superintendent can still walk it and write a manual note. That note is not a visual-progress cite until a photo is attached.

The programme moves when the superintendent, or the designated project-controls owner, accepts confirmed rows and applies the job's progress rules. Visual comparison does not status activities. It does not slip logic ties. It does not rewrite remaining duration. Those remain human edits, using the same rules you already use for remaining duration and constraints.

Use empty zones as a constraint on the next look-ahead, not as silence. If Zone 4C had no capture, the look-ahead should treat access, protection, and a re-walk as real constraints. A lookahead constraint scan that ignores missing capture will plan work in a zone nobody has evidence for.

Keep vendor choice as a class decision. Buildots, OpenSpace, Doxel, and Autodesk offerings differ in hardware, alignment, and how they present trades. The operating standard does not. Same zones as the job, cite the image, superintendent confirms, empty stays empty, no payment from a visual figure, no programme update from the model alone.