Start with the operational question

An organisation may have many cameras and an extensive image archive, yet a request to analyse everything with AI does not define a project that can be accepted or operated. Begin with what the team will do differently when a result arrives: inspect a list of locations, review a notification, or count objects within a defined area. Each answer changes the event definition, required data and evaluation approach. This article proposes a practical computer vision use case brief to prepare before development or configuration. It is an authoring tool rather than an official regulatory template and promises no particular accuracy or saving. Its purpose is to make the proposed decision discussable across business, technical and review teams.

Separate scene from event

The scene is the environment being captured, such as a bounded road segment, loading area or production line. The event is what the system should distinguish within it. Write a definition that two reviewers can apply to the same image, including positive cases and similar appearances that remain outside scope. In an illustrative example, the task might be to shortlist possible potholes for a maintenance inspection, rather than certify road safety or assign responsibility for damage. Record borderline cases such as shadows, standing water and old repairs. Give inconclusive cases a review category. If reviewers cannot agree on the correct label, resolve that definition gap before comparing model performance.

Write down capture conditions

A location name is insufficient. Specify the intended viewpoint, approximate distance, camera movement and lighting conditions. Explicitly record cases in which outputs will not be relied upon, such as an obstructed view or an image that does not show the object clearly enough for review. Agree how changes to cameras, positions or file sources will be handled. Success at one location should not be assumed to cover every environment. Defining purpose, use context and limitations is consistent with the MAP function of the voluntary NIST AI Risk Management Framework. This alignment does not make the proposed brief a certified implementation of that framework or a Saudi legal requirement.

Make data representative of the intended scene

Keep a record of sources, usage rights and the person responsible for supplying images. Gather both target events and negative examples, including the conditions included in scope. Short labelling instructions, borderline examples and review of disagreements can help. As a practical recommendation, separate evaluation samples from material used for improvement and avoid placing adjacent captures of the same event on opposite sides of the comparison. Near duplicates can make a test easier than real operation. File volume does not replace coverage, and a case absent from a sample may still occur later. Document unrepresented conditions as trial limitations, then decide whether to collect more data or narrow the scope.

Set acceptance criteria before seeing results

Agree which errors matter to the process owner. Flagging a clear scene for inspection consumes staff time, while missing an important case may have a different consequence. A trial brief can therefore consider false alerts, missed important cases, time to receive a result and human review workload. These are proposed measures, not official thresholds or values suitable for every organisation. Specify who establishes the reference judgement, how samples are selected and how results will be reported by scene condition rather than through one average. If the sample is small or excludes night scenes, conclusions must remain limited to what was tested. Agree acceptance boundaries before results are known so that success is not redefined afterwards.

Agree context specific acceptance boundaries before seeing results

Assign an owner and a next action

A model output is not a complete operational response. Define who receives a case, what evidence they need, when they refer it elsewhere and who may close it. In the possible-pothole example, a supervisor could receive an image, location and capture time, then request a site inspection before issuing a work order. This is an illustrative workflow, not a confirmed integration capability of a particular product. Also define what happens when a camera stops, data does not arrive or unreviewed cases accumulate. Check that the team can handle outputs before adding locations. Successful detection alone does not demonstrate a faster or better maintenance service.

Review privacy before operation

Saudi organisations should examine whether images and associated data can identify people directly or indirectly. Where personal data is involved, the relevant specialists should assess the applicability of the Personal Data Protection Law, its regulations and a lawful processing route. SDAIA guidance explains that storage is itself processing; an existing archive does not remove the need to review a new use. [4] The AI Ethics Principles also address privacy, security and accountability throughout the lifecycle. [5] Practical review questions include minimum capture scope, necessary data, access permissions, retention and destruction, suppliers, transfer routes and applicable sector security requirements. These questions are not a legal opinion or compliance certification. Simple visual blurring should not be assumed to remove every possibility of reidentification.

Use a concise decision brief

Summarise the case in a brief agreed by the relevant owners before the trial. The following table proposes fields for shortlisting possible potholes for maintenance review. Numerical boundaries, dates and named owners should be completed within the organisation after examining actual conditions, rather than filled with invented values that appear approved. Reopen the brief when the purpose moves from shortlisting to consequential automated action, or capture sites and data change. After testing, record what was evaluated, where it failed, what the evidence currently supports and the next decision with reasons. Continuing within a limited scope, changing collection or deferring implementation can all be valid outcomes. A trial does not automatically justify expansion.

Start the discussion with RMG

RMG presents Ofoq for real-time or offline image and video analysis within its computer vision offering. [1, 2] A useful discussion starts with one scene, an operational outcome and an output owner, followed by verification of suitable capabilities and any configuration, development or integration required. A general offering does not confirm every scenario, accuracy level or integration without assessment. Bring a scene description, examples that may be shared and the use case brief to discuss an evaluable pilot with RMG specialists. This gives the solution discussion a defined need and acceptance evidence rather than an open-ended inventory of cameras and images.