The first question in a camera-based AI project is what a person should do differently when an event occurs. A detection without a useful response can become another notification to ignore. Work backward from the operational decision, through the camera view and network, to the computing device.
The planning example below concerns a defined visual event in a controlled site. It is an illustrative method, not a claim of a completed CNPS installation or a promised detection result.
1. Define the event and the response together
Describe the event in observable terms. Name the objects, location, timing and exceptions. Then identify who receives the result and what action is expected. If staff cannot distinguish an actionable alert from ordinary activity, improve the task definition before comparing hardware.
Write down the cost of each kind of mistake. A false alert creates review work; a missed event may leave the original problem unresolved. Those consequences determine what the evaluation must reveal. Avoid compressing all errors into a single convenient accuracy figure.
2. Survey the scene before selecting compute
A site brief should let an engineer understand what the camera can actually observe. Capture representative viewing distances, lighting changes, movement, occlusion and weather exposure where relevant. Record the camera model, lens, interface and planned position rather than assuming that all existing cameras are interchangeable.
| Survey area | Information to capture |
|---|---|
| Visual task | Target event, ordinary activity and exclusions |
| Camera view | Position, distance, lens, resolution and frame rate |
| Environment | Light, temperature, weather, vibration and obstruction |
| Infrastructure | Power, network, mounting, enclosure and physical access |
| Data | Authorized footage, access, storage and retention requirements |
| Operations | Alert recipient, review process and recovery owner |
Use representative footage you are authorized to process. For an initial quotation, a non-sensitive site description and a simple layout can be more appropriate than uploading operational video.
3. Agree on a test people can repeat
Define the ground truth: who decides whether the event occurred, using what evidence? Fix the test conditions and record the configuration, software versions and model settings. Include ordinary periods with no target event, because the team still needs to understand the false-alert workload.
Count false positives and false negatives separately. Measure the time from the event to an alert that reaches the responsible person. A model’s internal processing time does not describe delays from capture, buffering, connectivity or delivery. Record the entire path that affects the working decision.
4. Test the unglamorous failure modes
Include sustained operation and planned exercises for power loss, network interruption, unavailable storage and restart. Determine what the operator can see when the system is degraded. A missing heartbeat should not look like a quiet scene if the business depends on knowing the difference.
Ask who can diagnose a fault remotely and which problems require a site visit. Record the recovery steps and expected responsibilities. These checks are part of a useful evaluation scope; they are not an assumption that a particular product already provides every monitoring or recovery feature.
5. Compare the installed system
The bill of materials should cover camera, lens, compute, storage, enclosure, cables, power and mounting. Add installation, data preparation, configuration, operator training and maintenance to the commercial comparison. A device price is only one element of the working system.
Consider what changes at the next site. A different camera angle, local network or lighting pattern may require new configuration or evaluation. Separate reusable engineering from site-specific work so that a proposed rollout budget has visible assumptions.
6. Bring a decision-ready brief
A useful brief states the destination, number of sites and cameras, event definition, environmental conditions, existing infrastructure and local operating owner. Attach the proposed test and identify any unknowns that prevent a reliable quotation. An explicit unknown is easier to resolve than an unstated assumption.
Start with the edge AI site survey and the UAE/KSA edge AI site readiness checklist, then discuss a scoped site evaluation with CNPS. A well-defined first site creates a clearer conversation about hardware, integration responsibilities and the evidence needed before expanding.
