THE GAP

Turning PPE Detection Data Into Audit Ready Compliance Reports

A PPE detection system watching 40 cameras at 15 fps generates several hundred thousand inference results a day. An auditor wants eleven pages: who was exposed, where, when, what was done about it, and who signed it off. The distance between those two things is a reporting layer, and it is a separate build from the detection itself.

THE GAP

Detection Produces Events. Audits Require Records.

A detection event is a row: camera 12, zone Press Line B, class helmet_absent, confidence 0.87, timestamp 09:42:17. It is machine truth about one frame. An audit record is an organizational statement: on 3 March, six people entered the press area without head protection, the shift supervisor was notified at 09:45, toolbox talk delivered on 4 March, repeat rate over the following fortnight fell to one.

The second document cannot be generated from the first without three things the detection layer does not hold. It needs the roster and shift calendar, so eleven events at 09:42 are understood as one incident rather than eleven. It needs a disposition workflow, so somebody can mark an event as a false positive, a contractor exemption, or a confirmed violation. And it needs a retention policy that survives the storage the camera server happens to have.

Under 29 CFR 1904.33, an employer in the United States keeps the OSHA 300 Log, the annual summary and the 301 incident reports for five years after the end of the calendar year they cover, and must update stored logs when a classification changes. ISO 45001 clause 7.5.3 asks the same question in a different register: retention, retrieval, protection from loss of integrity, and controlled disposition. Neither of those is satisfied by a detection database whose oldest row is 30 days old because that is what the disk allowed.

WHAT GETS BUILT

The Three Layers Between A Frame And A Report

Most sites that already run PPE detection have the first layer working and nothing above it. The material divides cleanly into three.

Event Capture

The detection platform emits structured JSON by webhook or REST describing the camera, zone, class and confidence score, and writes an immutable audit log. Basic Safety Guard exports CSV and PDF at this level, which covers a spot check and an insurer’s sample request. This layer is a product purchase and it is already solved.

Reconciliation

A service that reads those events and turns them into incidents. It applies a debounce window so one person walking a corridor becomes one record, joins against shift and area data so an incident carries an owning supervisor, and holds a review queue where a safety officer confirms, dismisses or reclassifies. Every state change is stamped with a user and a reason. This is where the record becomes defensible, because an auditor who finds no human judgement anywhere in the chain will discount the whole dataset.

Presentation

The dashboards and the exports. Compliance rate by area and by shift, trend against a baseline, time to acknowledge, repeat offender areas, and a period pack that prints in the format your regulator or your parent company actually asks for. This layer has to be built against your reporting obligation, which is why it rarely comes off a shelf.

HONEST LIMITS

What The Data Cannot Tell You

A compliance percentage from computer vision is a measurement of a camera’s field of view, and it inherits every limitation of that view. Say so in the report rather than letting an auditor discover it.

Detection quality depends on pixel density on the target. ARSA-CVS-001 sets 262 PPM for helmet detection and 153 PPM for vests, with optimal tilt between 10 and 25 degrees, a maximum of 35 degrees for helmets and 40 for vests, and any angle steeper than 45 degrees prohibited. Below 50 lux the result is unreliable. A camera that fails those thresholds produces numbers, and those numbers mean nothing. The reporting layer should carry each camera’s compliance status against the standard alongside its detection figures, so a reader knows which lines of the table to trust. Our lens and field of view visualizer gives you the pixel density for a given lens and standoff before anyone buys anything, and the system requirements page covers the server side.

Two further honesty requirements belong in the report design. Coverage is partial, so state the percentage of the working area under camera and the hours of the day included, because a 97 percent compliance figure drawn from one aisle on day shift is a statement about that aisle on day shift. And identity is a policy decision. Facial recognition can attribute a violation to a named person, which changes the character of the system, the consent position, and in many jurisdictions the legal basis. Plenty of sites deliberately report by area and shift with no personal attribution at all, and that dataset still drives behaviour.

The system also does not know intent, does not know that a worker removed a helmet for 20 seconds to wipe sweat under a supervisor’s eye, and does not replace a walk of the floor.

THE NUMBERS

Sizing A Reporting Build

Raw event volume is the figure people underestimate. Storing five years of unreconciled detections is expensive and useless. Storing five years of reconciled incidents, with the raw events retained for a shorter window and a pointer to the video clip, is what an audit trail actually needs, and it is a design decision made once at the schema stage.

The camera figures matter to a reporting project because a survey that fails half your positions changes the scope of the dashboard before a line of application code is written. The Remote Camera Design Review returns a marked up camera schedule with a pass or fail per position against ARSA-CVS-001 and priced remediation. If the answer is that 14 of your 40 cameras cannot support helmet detection at their current mounting, the reporting build is scoped for 26 cameras and an honest coverage statement, rather than discovered in month four.

Frequently Asked Questions

Do We Need To Replace Our Detection System To Get This?

No. The reporting layer reads events from whatever is producing them, by webhook, REST poll or database export. If your current platform emits structured events with camera, zone, class, timestamp and confidence, it can feed a reporting application. The integration surface is established during the feasibility assessment, including the case where the existing system has no usable API.

Can The Application Run On Our Own Servers?

Yes, and that is the default for ARSA. On premise and air gapped deployment are design inputs from the start. Video and event data stay inside your network, which is usually the deciding factor when the footage shows your production floor.

How Long Does A Build Like This Take?

Discovery and requirements runs one to two weeks, design two to three, iterative development six to twelve, integration and testing two to four, then deployment and training. A focused compliance reporting platform sits at the shorter end of that range. Typical enterprise web projects run $20,000 to $250,000 and reach a functional system in eight to sixteen weeks.

Will An Auditor Accept Computer Vision Evidence?

Auditors accept records, and the question they ask is whether the record is complete, dated, attributable and unaltered. A reporting system that logs every state change with a user and a reason, retains records for the statutory period, and states its own coverage limits gives them something to test. A compliance percentage with no provenance behind it invites the opposite reaction.

What Happens To False Positives In The Reported Figures?

They are dismissed in the review queue with a reason code, and both the dismissal and the original event stay in the log. Reporting on the dismissal rate itself is worth doing, because a rising false positive rate on one camera is usually a lens, lighting or angle problem that the camera standard can diagnose.

Do You Hand Over The Source Code?

For custom application code, typically yes, agreed in writing before work starts. ARSA platform components and reusable libraries are licensed rather than transferred.

BUILD IT

Start With The Report You Have To File

The most useful first step is to put the document your auditor, insurer or head office actually demands on the table, then work backwards to the fields that produce it. That exercise usually reveals that two thirds of the dashboard everyone imagined is decoration, and that one field nobody planned for is mandatory.

ARSA builds that layer as a custom enterprise web application, with real time dashboards over multi source data, role based access with audit trails, and automated reporting. A feasibility assessment at $4,500 establishes the data model, the integration surface and the permission model before anyone writes code, and the fee is deducted from the project fee if you contract within 90 days. See Enterprise Web Applications for how the builds are structured, or talk to us about your site.

Sources: eCFR 29 CFR Part 1904 Subpart D, ISO 45001 Clause 7.5 Documented Information