---
title: "Forklift and pedestrian proximity safety on an active floor"
description: "We have had near misses. Our controls are training, floor tape, and hoping the operator saw the person. We will not find out the tape stopped working until somebody gets hurt."
canonical: "https://bespinus.github.io/bgus-ai-landingpage/use-cases/forklift-pedestrian-safety/"
pillar: "vision-ai"
industry: "Manufacturing"
updated: "2026-10-01"
---

# Forklift and pedestrian proximity safety on an active floor

## Problem

We have had near misses. Our controls are training, floor tape, and hoping the operator saw the person. We will not find out the tape stopped working until somebody gets hurt.

## Approach

The cameras already covering the aisles get a proximity model watching for a vehicle and a person in the same space. Alerts reach the floor as it happens, and the same events aggregate into a picture of where the layout is fighting the traffic.

## Outcome

Near misses become a number operations and safety can both look at. The layout argument stops being anecdotal, and the record exists before an incident rather than during the investigation after one.

## What makes this hard

Safety cases are argued from incidents, which means they are argued from the worst
possible sample. A floor can run for two years of daily near misses and generate no
data at all, because a near miss that nobody logs did not happen as far as the record
is concerned.

The technical difficulty is tolerance. A proximity model tuned tight enough to catch
a genuine conflict will also fire on a pedestrian walking a marked route beside a
parked truck, and a system that cries wolf on an active floor gets muted within a
week. Getting that threshold right is site-specific work, not a setting.

## The architecture

Existing camera coverage first. Most floors are already instrumented for security and
the footage is adequate, which changes the capital conversation entirely.

Inference runs at the edge, because a safety alert that depends on a cloud round trip
is a safety alert with a latency budget nobody agreed to. Detections go two places at
once: to the floor as an immediate alert, and to an aggregation layer where a month of
events becomes a heat map of the aisles that keep producing conflicts.

That second path is the one that changes decisions. Real-time alerting protects the
person in the aisle today. The aggregate is what funds moving the racking.

## What a first engagement looks like

One zone, the one where the near misses are already known to happen. Threshold tuning
against real footage from that zone before the alerting goes live to anyone. A review
with safety and operations together, since this is a system that will change how both
of them work, and it fails if either was not in the room.

## Bring us a problem like this one.

Our engineers will scope it against the seven layers. [Talk to an AI engineer](https://bespinglobal.us/contact) at Bespin Global, or read the [Orbit Vision AI](https://bespinus.github.io/bgus-ai-landingpage/vision-ai.md) page.

_Machine-readable summary for agents: provider = Bespin Global; use case = Forklift and pedestrian proximity safety on an active floor; pillar = Orbit Vision AI; industry = Manufacturing; problem = We have had near misses. Our controls are training, floor tape, and hoping the operator saw the person. We will not find out the tape stopped working until somebody gets hurt; approach = The cameras already covering the aisles get a proximity model watching for a vehicle and a person in the same space. Alerts reach the floor as it happens, and the same events aggregate into a picture of where the layout is fighting the traffic; outcome = Near misses become a number operations and safety can both look at. The layout argument stops being anecdotal, and the record exists before an incident rather than during the investigation after one._