Connect existing cameras to event analysis, an operator console and operational reports. Explore the partner platform by use case, with development status and the requirements for a pilot on your site.
Source: the partner’s September 2026 development brief. It reports developer-site tests, recording-based tests and test-bench work, but no completed WATCHDOG customer-site pilot. Status labels below are developer-reported, not independent certification or proof of performance at your site. BELL RIVER presents the platform for a scoped implementation discussion, not as its own completed client deployment.
02How it works
From existing cameras to an operator decision.
01
Cameras and sensors
Use standard streams from existing cameras and recorders. Thermal cameras, microphones or environmental sensors are assessed only where the task needs them.
02
Local analysis
A compact edge device flags candidate events near the cameras. The brief describes local buffering during connection loss, with delayed delivery after reconnection.
03
Server verification
An on-site server checks the selected event against agreed rules and available footage, then prepares a description and supporting material.
04
Operator review
Deliver a timestamp, description, relevant clip and log entry to a browser console or approved integration. The operator confirms the event and decides what to do.
03Capabilities and readiness
Choose the task. See what is ready.
Based on the September 2026 partner brief. Each label describes the documented stage of a function, not a performance guarantee.
Developer-site tested
Reported as exercised at the developer’s own site; no completed customer-site pilot.
Recordings / test bench
Evaluated on recordings or a test bench; operational performance needs a site pilot.
In development
A proposed function with a technical foundation, not a validated deployment.
Mixed source status
The capability table reports developer-site use, while the summary describes test-bench readiness. Confirm scope and repeat validation in a pilot.
Laboratory foundation
The underlying processing chain was tested in the lab; the named industrial sound classes are not yet trained on these devices.
01
Retail operations
Understand queues, store occupancy and conditions that need staff attention. The proposed scope uses operational counts and events, not shopper identification or profiles.
Recordings / test bench
Checkout queues
Estimate queue length and waiting time by checkout, with a prompt for staff to consider opening another till.
Developer-site tested
Visitor counts and occupancy
Count entries over a period and estimate how many people are inside. Evaluate counting quality for your entrances, camera views and busy periods.
Recordings / test bench
Spills and scattered goods
Flag a wet floor, a spill or goods scattered on the floor so staff can inspect the area and arrange cleaning.
Developer-site tested
After-hours presence
Flag presence in an agreed store or stockroom zone after closing for staff review. An alert does not establish identity, intent or theft.
02
Workplace safety and production
Bring defined visual conditions to an operator’s attention. These are supplementary observations, not safety interlocks, medical assessments or guarantees of injury prevention.
Recordings / test bench
Personal protective equipment
Evaluate visible helmets and high-visibility clothing. The brief explicitly reports insufficient reliability at a distance; views and acceptance criteria must be agreed on site.
Developer-site tested
Defined hazardous zones
Flag presence in a drawn risk zone, under a suspended load or near equipment. A person reviews the alert and follows the site’s safety procedure.
Developer-site tested
Falls and a person on the ground
Flag a possible fall or a person lying on the ground for prompt human review. The cause and the person’s condition must be assessed by people, not inferred from the alert.
Developer-site tested
Aggregate area counts
Summarize occupancy across designated work areas. Scope reporting at area level, without individual productivity scores or employee movement histories.
In development
Product and equipment inspection
Explore visible product defects or equipment-condition checks as custom extensions. The brief does not establish a validated production-line inspection deployment.
03
Fire-safety observations
Supplement existing fire precautions with footage for operator review. WATCHDOG is not a certified fire detector and does not replace fire alarms, mandatory safety systems or recording infrastructure.
Mixed source status
Flame and smoke, day and night
Evaluate possible visual flame or smoke, including infrared night footage where suitable. Pages 4 and 12 describe different readiness levels; confirm the supplied configuration and validate it at the customer site.
Recordings / test bench
Fire-lane and hydrant access
Observe a vehicle occupying a defined fire-access area and the duration of that occupancy. The proposed task does not require identifying drivers or building vehicle movement histories.
In development
Evacuation routes and fire doors
Explore checks for obstructed exits, blocked access to fire equipment or a propped fire door. These functions remain development work in the capability table.
In development
Missing fire extinguisher
Compare an agreed location with a reference view to explore whether an extinguisher is absent. Do not rely on this proposed check instead of required inspections.
04
Site, yard and fleet operations
Scope monitoring to the customer’s own operational areas: boundaries, equipment, deliveries and camera availability. This is not cross-site tracking of people or vehicles.
Developer-site tested
Defined perimeter zones
Observe presence in agreed boundary or restricted work zones, with scheduled night operation. Review camera coverage and the response procedure before use.
Developer-site tested
Camera-health alerts
Notify operators about an obscured camera, a frozen image or a missing video stream so they can investigate gaps in coverage.
Developer-site tested
Animals and unexpected objects
Flag animals or objects in selected operational zones for review. Reflections, shadows and site-specific nuisance alerts still need to be tested.
Developer-site tested
Equipment and load observations
Distinguish documented equipment categories such as trucks, mixers, excavators, cranes and forklifts, and evaluate whether a vehicle appears loaded or empty.
Developer-site tested
Delivery and unloading events
Record arrival at a loading zone, dwell time and departure as an operational event. Quantity calculations require an agreed connection to existing entry and exit weighing equipment.
Developer-site tested
Shift reports
Compile timestamps, reviewed events, aggregate area occupancy and delivery activity into a shift summary. Reported quantities depend on the available camera and scale data.
05
Industrial sound research
A separate engineering foundation for future sound-based observations. It is not a ready-to-deploy industrial fault-detection package.
Laboratory foundation
Acoustic processing foundation
The brief reports a laboratory-tested chain from a microphone node through server verification to an alert. Tests of the underlying target sound do not establish performance on machinery faults, glass breakage or industrial alarms.
In development
Machinery and site-specific sound classes
Training and evaluation would be needed for particular machines or industrial events. Welding and construction noise remain interference risks; a multi-node field installation has not been validated.
04Event review
From an alert to the facts.
The brief describes a working developer-site event-analysis chain. For a customer pilot, scope it to recorded events, supporting material and human confirmation.
Retrieve the relevant interval
Start from a recorded event and gather footage immediately before and after it, preserving timestamps and the original context.
Check the available context
Review another relevant camera view where authorized, compare the timing and check the agreed operational rules. Keep uncertainty visible rather than filling gaps with assumptions.
Prepare a reviewable event record
Present a description, supporting frames or clips and a log entry. These are review materials, not a determination of identity, criminal intent, guilt or responsibility.
Let the operator decide
A responsible person confirms or rejects the event and follows the agreed response procedure. The page describes a bounded event-review workflow, not autonomous investigation or enforcement.
Operator delivery can include a browser console, an event log, a shift report or an approved connection to an existing business system. No independent customer-site results are claimed.
05Equipment and data
Build around the site you have.
Agree compatibility, capacity and data handling before installation. Extra equipment depends on the chosen task.
Existing cameras and recorders
Compatible network cameras or recorders providing a standard video stream. Check stream access, field of view, lighting, image quality and blind spots before choosing the pilot cameras.
Local processing nodes
Compact devices installed where network and power are available. The developer describes up to 10 cameras in a standard mode or 2–4 with fuller analysis; these are planning references, not a guaranteed capacity for every workload.
An on-site server
A server with graphics acceleration and appropriate network, storage and power. Size it against the actual streams, analysis modes and retention requirements rather than a universal camera-to-server ratio.
Task-specific additions
Thermal cameras, environmental sensors or weighing-system connections may be needed for a chosen scenario. Sound-monitoring hardware requires separate development and evaluation, not just installation.
Local processing, explicit data flows.
The documented default is processing on the customer’s premises. Authorized event messages, short clips or optional external model services can still create outbound data flows. Agree every destination, access role and retention period; this is not an unconditional “data never leaves” guarantee.
Operational scope, not personal profiling.
This offering covers operational observations, aggregate counts and human-reviewed events. It excludes biometric identification, searching for particular people, cross-camera person tracking, demographic profiling and predictions of criminal intent. Footage may still contain personal data: a non-identifying task is not a claim that images are automatically anonymized.
Validate conditions, not just the demo.
Distance, lighting, occlusion, crowding and camera position can change performance. Test false alerts and missed events in representative conditions. Development-stage functions, English localization and industrial sound models need explicit additional work.
What we scope with you.
Your users, data requirements, existing systems, and operating environment shape the implementation.
01 · Survey the site
Agree the operational task, authorized camera feeds, lighting, coverage, retention and access roles. Name a site contact and assess network, power and server capacity.
02 · Run a measured pilot
Start with representative cameras and agreed scenarios. Record false alerts and missed events, review them with operators and compare the results with acceptance criteria. Camera count and timing are agreed after the survey.
03 · Integrate and train
Expand only after reviewing the pilot. Connect approved operational systems, configure the operator workflow and train the people who handle alerts. The documented interface is Russian; English localization is scoped implementation work.
04 · Review and maintain
Use reviewed examples to refine the setup, revisit coverage when the site changes and assess additional scenarios separately. Keep event handling, data access and operator responsibilities documented.
Start with your use case
Bring your business challenge.
Tell us your industry, the event you need to observe, the cameras already available and what the operator should do after an alert. Non-sensitive examples are enough to start a WATCHDOG pilot discussion.