Ask a corporate Environmental, Health and Safety (EHS) director what they actually run their program on and the answer is a system of record: the platform where incidents are logged, actions are tracked, audits are scheduled, and the metrics that reach the board are assembled. That system is the program's memory and its bureaucratic engine, workflows, approvals, regulatory reports, and it was almost certainly bought years before anyone proposed pointing AI at the plant's cameras. So when the detection layer this series describes arrives, it arrives as a second system, and the EHS director's first architecture question is the right one: does this create a parallel universe of safety data, or does it feed the one we already govern? The answer decides more than convenience, because a safety program with two disagreeing records has a worse problem than a safety program with one thin one. This article is about making the detection layer a source for the system of record rather than a rival to it, and it extends our pillar guide to AI for workplace safety in manufacturing.
Keep your EHS platform as the system of record
The temptation on the vendor side of this industry is to grow the detection platform into the safety platform, dashboards, actions, audits, the whole apparatus, and the EHS director should decline politely and firmly. The system of record holds things the camera layer never will: the injury logs and their regulatory obligations, the audit programs, the training records, the chemical inventories, the years of history that make trends mean anything, and, not least, the workflows a global program has already trained thousands of people to use. Migration is not a feature; it is a program risk.
The division of labor that works is the one this series has implied throughout: the detection layer observes and evidences, the system of record remembers and governs. A hazard-zone event is generated by the camera layer, with its timestamp, location, severity, and clip; it becomes a record when it lands in the EHS platform as an observation or incident, entering the same triage, action, and closure workflow as every other record the program holds. The safety team keeps one queue, one action tracker, and one reporting engine, and the detection layer's contribution is that the queue now contains events no human had to witness and file, at their true frequency, per the arguments of the near-miss article.
How events reach the EHS platform
The mechanics are the standard two paths of the integration article, stated here in program terms. Webhooks push a detection to the EHS platform's intake the moment it happens, so a high-severity event, the fall-zone entry, the worker-down, can open an incident record while the response is still under way. The REST API serves the batch and query patterns, the nightly sync of the day's events into the observation module, the backfill, the reconciliation report. Most enterprise EHS platforms, the Intelex and Cority class of system, expose APIs built for exactly this kind of intake, and where a vendor publishes a modern API, the manifest model from the integration article makes the connection authoring work rather than a development project, scoped per engagement against the system the site actually runs. The same model already carries Microsoft Dynamics 365 and ServiceNow as shipped connectors, which is the working proof that an EHS platform with a documented API is authoring work away.
Three mapping decisions do most of the design work, and they belong to the safety team rather than to IT. Which events cross: not everything the detection layer logs deserves a record, and the working pattern sends the high-severity detection types and confirmed escalations as incidents or observations while the bulk exposure data flows as periodic aggregates into the metrics the program already reports, per the Key Performance Indicator (KPI) framework. What they become: each crossing event maps to a record type the program already uses, observation, near miss, incident, unsafe condition, so the taxonomy is the program's own rather than the vendor's. And what travels with them: the event's attributes map to the record's fields, and the clip travels as a link back to the evidence rather than as a video file attached into a system never built to govern footage.
That last choice is load-bearing enough to justify its own paragraph. The footage stays in the platform built to govern it, the Nexus portal with its role-based access, view and export audit logs, retention policies, and holds, and the EHS record carries the reference. This keeps the evidence disciplines of the recordkeeping article intact, one clip, one identity, every access logged, while giving the safety workflow what it needs, the evidence one click from the record. Copying video into the EHS system as attachments forfeits the audit trail, multiplies uncontrolled copies, and turns the eventual litigation hold into a hunt, which is precisely the failure the architecture exists to prevent.
What the combined record enables
Once detections flow into the system of record, the program gains capabilities neither system had alone, and they are worth naming because they are the business case.
The action engine, for the first time in most programs' history, finally has volume. EHS platforms are built around corrective and preventive action workflows, and their chronic limitation has been intake, actions can only follow reported events, and reporting is thin. Detection intake feeds the engine at the true rate of observable exposure, and the program's time-to-correction discipline, tracked in the system it already uses, becomes the leading indicator the KPI article ranks highest. The metrics gain a denominator: reported events against detected events, by site and shift, is the reporting-culture ratio, computed inside the program's own reporting rather than in a side spreadsheet. And the audit trail closes end to end: an auditor tracing a hazard from detection through record, action, closure, and verification walks one chain across two systems, each doing what it is built for, the clip reachable and logged at every step.
One governance rule keeps the merged record trustworthy, and it is the same rule stated throughout this series, applied at the integration seam: the no-discipline commitment travels with the data. Events crossing into the EHS platform describe conditions, zones, detection types, severities, not identified individuals, and the mapping design enforces it structurally, because a record type with a person field invites a person answer. The works-council terms should name the integration explicitly, what crosses, in what form, visible to whom, so the workforce reads the system of record's new intake as the program's promised measurement, not as surveillance acquiring a second archive.
Standardizing the mapping across sites
For a corporate EHS function running dozens of plants, the integration seam has a property worth exploiting deliberately: it is the one place the whole program's data discipline can be standardized without standardizing the plants. Sites differ in cameras, coverage, and maturity, and the KPI article's comparability warnings apply in full, but the mapping, which event types become which record types, carrying which fields, under which no-discipline constraints, can be one corporate document, versioned and audited, applied at every site's seam. The payoff arrives in the program's consolidated reporting: when every site's detections enter the system of record through the same mapping, the corporate roll-up aggregates likes with likes, and the exposure trends that reach the board carry a data lineage an auditor can walk. Sites that let each plant improvise its mapping discover the alternative at exactly the wrong moment, in the meeting where two plants' identical-looking metrics turn out to mean different things.
If you do not have an EHS platform yet
A minority case deserves honest treatment: some operations run their safety program on spreadsheets and email, or on a legacy system with no usable API, and for them this article's architecture inverts. The detection platform's own reporting, the exposure rates, correction tracking, and exportable aggregates, can carry the program's measurement layer for a time, and the discipline is to treat that as the interim it is: name the system-of-record gap in the program's own improvement plan, choose the eventual platform with API intake as a requirement, and keep the detection layer's data model clean, detection types, severities, dispositions, so the day the real system arrives, the history migrates as structured records rather than screenshots. What should not happen is the quiet drift into the detection platform becoming the permanent system of record by default, because the obligations that system must eventually carry, the regulatory logs, the audit programs, the decade of history, deserve a platform built for them.
A phased rollout
The sequence that works runs the seam gradually. Start with aggregates: a month of exposure summaries flowing into the metrics module, no individual events, while the safety team validates the numbers against the detection platform's own reports. Then open the high-severity channel, the small class of events whose records the team would want regardless, and run the intake in parallel with existing processes until the mapping proves itself, misrouted events and duplicate records found in the first weeks cost minutes, and found in an audit cost credibility. Then widen by detection type as the triage workload confirms capacity, because an intake that outruns the action engine recreates, inside the system of record, the alert-fatigue failure the tuning article warns about on the floor. At each stage, the reconciliation report, what the detection layer emitted against what the record system holds, is the integration's health check, and it belongs in the same monthly review as the program's other indicators.
Deduplication belongs in the mapping conversation from the start, because the detection layer and the humans will sometimes both report the same event, the supervisor filing the near miss the camera also caught, and the program wants that convergence visible rather than doubled. The working pattern tags detection-sourced records with their origin and event identifier, so the triage step can merge the pair into one record carrying both the human context and the clip, which is, in miniature, the whole thesis of the integration: the two records were always describing one plant.
One number makes the case for this seam better than any architecture argument, and a site can compute it before buying anything: take the EHS platform's action module and count the open corrective actions per site, then take a month of detection-layer output and estimate what fraction would have qualified as record-worthy observations under the mapping this article describes. The ratio between those numbers is the program's observation deficit, the gap between the exposure the plant generates and the exposure its system of record ever hears about, and for most programs it is large enough that the integration stops being an IT nicety and becomes the fastest available upgrade to the program's entire evidence base.
How VIDIZMO fits
VIDIZMO's side of this seam is the event fabric and the evidence store. AI Live Insight generates the detections with their attributes; the Nexus portal governs the clips, the access control, and the audit logs the links resolve to; webhooks and the REST API carry events outward under scoped integration credentials; and where the EHS vendor's API supports richer operations, the manifest-based connector model of AI Intelligence Hub reaches it as authoring work per engagement, with the hardened execution properties the integration article details. The safety program's own platform remains exactly that, and the deployment's written terms record the mapping, the detection types that cross, the record types they become, and the fields they carry, so the seam is documented rather than tribal.
The draft also gives procurement its acceptance test: when the integration is delivered, the mapping document is what the validation runs against, event type by event type, which turns go-live from a demonstration into a checklist and gives the program a regression reference for every platform upgrade after.
The preparation for the first integration conversation is a safety-team exercise, not an IT one: take last month's detection report and the program's record-type list, and draft the mapping on one page, which events would have become which records, with what severity, routed to whom. That draft surfaces every real decision this article describes, and it converts the integration from an IT project the safety team awaits into a program design the safety team owns.
