Computer Vision for Jobsite Safety: What the Evidence Shows
CodeBranch Team
There is no credible published evidence that computer vision reduces construction accidents. The technology detects people, equipment and protective gear in a video frame — that part works and has for years. What nobody has demonstrated with published methodology is the step after detection: that alerting on those detections produces fewer injuries. The industry has been selling the second while proving the first.
Quick Summary
- Computer vision reliably answers “is there a person in this zone.” It does not reliably answer “is this person in danger.”
- A 2025 technical review of the field found no production-scale success metrics for construction safety monitoring — no incident reduction figures, no ROI, no case study results.
- Documented technical constraints are occlusion, weather degradation, and false positives in visually complex environments, all of which worsen on a site that reorganizes weekly.
- 1,032 construction and extraction workers died on the job in 2024, 370 of them from falls — the problem is real, which is why overstated solutions cost something.
- The defensible use cases are presence detection: perimeter security, equipment location, restricted zone access. Those are verifiable and do not depend on behavioral inference.
This is one instance of a pattern that runs through this whole vertical: the capability that gets demonstrated and the outcome that gets sold are not the same thing. More on where that gap sits in what construction companies build when their platform runs out.
What Does the Published Research Actually Say?
A 2025 technical review of computer vision for construction safety monitoring catalogues the capabilities in detail: object detection and recognition, action and activity recognition, anomaly detection — identifying workers, equipment, PPE compliance, and flagging unsafe behaviors.
It contains no quantified results. No incident reduction percentage, no ROI figure, no case study outcomes. The review states plainly that production-scale success metrics do not yet exist for this technology in construction.
That is not a gap in one article. Searching for peer-reviewed or industry studies linking camera-based monitoring to measurable incident reduction on construction sites turns up vendor claims without methodology. One widely circulated figure — that 80% of accidents can be prevented — traces back to a blog post with no underlying study. It should not be cited, and it is cited constantly.
The problem it addresses is not hypothetical. The Bureau of Labor Statistics recorded 1,032 deaths among construction and extraction workers in 2024, with 370 of those from falls, slips and trips. Construction and extraction was the second-deadliest occupational group in the country. When the stakes are that high, a solution that is oversold is not a harmless exaggeration — it displaces attention and budget from interventions that work.
Where Does the Technology Genuinely Work?
The distinction that matters is between presence and behavior.
Presence questions are object detection problems: is there a person in this frame, is that person inside a demarcated zone, is the excavator in its assigned position, is there a hard hat on the head in this image. These have mature solutions. Detection models have been reliable at this class of problem for years, and the remaining work is tuning and integration rather than research.
Behavioral questions are different in kind: is this worker at risk, is that action unsafe, is this situation about to become dangerous. Answering those requires inferring intent and predicting a near-future state from a video frame. That is not a solved problem in any domain, and construction is a harder environment than most.
Almost every ambitious safety claim in the market depends on the second category while the demonstrations show the first. CodeBranch scopes computer vision projects around the first, because it is the part that can be specified, tested and verified against an acceptance criterion.
What Do We Know About Building One of These?
CodeBranch built a production computer vision system for presence detection — worth being precise about the context, because it was not a construction site. The AI video surveillance platform is an intrusion detection system: real-time analysis of video streams identifying unauthorized human presence in demarcated zones, built on a custom-tuned YOLOv3 model with OpenCV, running across a LAN supporting up to 64 concurrent cameras, with multi-channel alerting.
Three things from that work transfer directly to the jobsite question.
The model had to be tuned for its specific environment. Not configured — tuned. And that was in a controlled setting with fixed cameras and stable lighting. A construction site is reorganized weekly, which invalidates camera angles and zone definitions as the work progresses. Whatever tuning cost exists in a stable environment is a recurring cost in an unstable one.
Camera hardware is heterogeneous and that shapes the architecture. Some cameras support native event detection; others need to be polled. On a site with equipment from different suppliers installed at different times, that variation is the normal case, and it determines the design more than the model choice does.
Detection is the easy half of the system. The engineering that took the time was the alerting pipeline — who gets notified, through which channel, how many contacts, what happens when the first one does not respond. That is true for jobsite safety too, and it is the half that determines whether a detection changes anything. A system that identifies a hazard perfectly and alerts someone who is not in a position to act has produced a log entry, not a safety outcome.
Why Is a Jobsite Harder Than a Fixed Installation?
Three constraints, all documented and all worse on a construction site than in a building.
Occlusion. Objects block camera views, and on an active site the objects move. A camera with a clear sightline on Monday is behind a material stack on Thursday.
Weather. Rain, dust and low light degrade image quality, and the degradation is not uniform — it affects some detection classes more than others, so accuracy drops unevenly in ways that are hard to predict from test conditions.
Visual complexity. Construction sites are cluttered, which produces false positives and false negatives. False positives are the more corrosive failure: a system that cries wolf gets ignored, and once a crew learns to dismiss the alerts, the technically correct detection that follows is dismissed too. CodeBranch treats the false positive budget as a design constraint set before the model is chosen, not as a number to report after the fact.
| What gets demonstrated | What gets deployed | What can be verified | |
|---|---|---|---|
| Conditions | Clear weather, good light | Rain, dust, night work | Accuracy degrades; by how much is site-specific |
| Camera views | Fixed, unobstructed | Occluded by moving equipment | Coverage gaps appear as the site changes |
| Site layout | Stable during the test | Reorganized weekly | Zone definitions need ongoing maintenance |
| Claim | Detection accuracy | Incident reduction | Only the first has published evidence |
What Should a Contractor Actually Buy?
Scope the project around presence detection, where the technology is mature and the value is verifiable.
Perimeter security after hours is the clearest case. It is the same problem the surveillance platform above was built for, the environment is more controlled at night, and theft and unauthorized access are measurable outcomes — you can count incidents before and after.
Equipment location and utilization is a detection problem with a direct cost link. Idle machinery and lost tools are quantifiable, and the inference required is shallow.
Restricted zone access works when the zones are stable long enough to be worth defining. On a site with a static hazardous area — an excavation, a crane radius — presence detection at a boundary is exactly what the technology does well.
What would not be scoped around accident reduction, at least not as the success criterion, is anything whose value rests on predicting unsafe behavior. Not because the ambition is wrong, but because there is no way to verify the vendor’s claim or your own result, and a safety program built on an unverifiable input is worse than one built on a smaller verified one.
What Should You Ask a Vendor?
Three questions, and the third one is the test.
What exactly does the model detect, expressed as object classes rather than outcomes. A precise answer here is a good sign.
What is the false positive rate under conditions resembling yours — weather, lighting, site density — and what happens operationally when it fires wrongly.
And what published evidence links detection to incident reduction. A vendor who answers the first two precisely and acknowledges the third has no good public answer is telling you the truth about the state of the field. One who produces a percentage should be asked for the study behind it.
CodeBranch applies that standard to its own work, which is why this article reports that the evidence is missing rather than filling the gap with a number that would be easier to sell. The same discipline shapes how it scopes software for construction companies: around capabilities that can be specified in an acceptance criterion, not around outcomes nobody can verify.
CodeBranch is an agentic software development partner for U.S. companies, from building new products to scaling existing ones — senior-led teams in Colombia, working U.S. hours. We deliver with AI-native pipelines and our own Spec-Driven Development framework, with quality and security built into every line of code.
Frequently Asked Questions
Does computer vision actually reduce jobsite accidents?
What does computer vision reliably detect on a construction site?
Why do vendors claim such large safety improvements?
What makes construction sites harder than other environments for computer vision?
Is it worth deploying camera-based monitoring on a site at all?
How do we evaluate a vendor selling AI safety monitoring?
CodeBranch Team
CodeBranch is an agentic software development partner for U.S. companies, from building new products to scaling existing ones — senior-led teams in Colombia, working U.S. hours. We deliver with AI-native pipelines and our own Spec-Driven Development framework, with quality and security built into every line of code.
Related Articles
Construction Job Costing Starts at the Cost Code
Job costing is an attribution problem, not a reporting problem. The cost code structure decides what the reports will ever be able to tell you.
Unit Price Analysis and the Limits of Generic Estimating
A unit price is not a price. It is a calculation with yields, crews and equipment underneath — and that structure is what generic tools do not store.
When You Should Not Build Custom Construction Software
Every build-vs-buy guide in construction is published by someone selling a platform. Here is the case against building, from a company that builds.