PUBLIC COMPANION / SAILSAIL / Partnership case study
Coastal cameras.
Operator decisions.
How ResQVision and Surf Life Saving NSW use camera analysis to flag potential unexpected water entry at rock-fishing sites for review by the State Operations Centre.
Kiama, NSW. Existing installation photograph. Camera coverage and the receiving team's response arrangements both matter.
- Programme
- Surveillance AI for Lifesaving
- Public trial sites
- Kiama Blowhole and Little Bay
- Receiving team
- SLSNSW State Operations Centre
- Published trial period
- 14 months, ending November 2026
Programme status is based on SLSNSW's public overview, checked 29 October 2026. Any continuation or new phase needs separate confirmation. Report wording updated 2 November 2026.
PUBLIC COMPANION / SAIL01 / The operating environment
Unexpected water entry.
Operator-led review.
SAIL - Surveillance AI for Lifesaving - focuses on unexpected water entry at exposed rock-fishing locations. The software flags potential events for review by the SLSNSW State Operations Centre (SOC).
The view must show the hazard
At an exposed rock platform, a person can enter the water suddenly and beyond a patrol's immediate sightline. The camera needs to show the hazard area and adjacent water so an operator can check what happened.
People decide what happens next
Operators review alerts, check the scene and decide whether a response is needed. They use established communications and procedures to coordinate the appropriate resource.
01 ObserveCamera view of the rock platform and adjacent water.
02 DetectPotential unexpected water entry prompts an alert.
03 ReviewAn SOC operator checks the alert and scene.
04 CoordinateIf needed, the team follows its response procedures.
An alert prompts a check
Operators assess the situation and coordinate any response; trained teams carry it out. Glare, distance and obstruction affect what the camera and operator can see.
For each deployment, agree what an alert contains, how it reaches operators, and how it is checked and escalated. Response arrangements need to be defined for the receiving team. Sources: [1, 2].
PUBLIC COMPANION / SAIL02 / Working together
What SLSNSW and
ResQVision each contribute.
Surf Life Saving NSWSite knowledge and operational decisions
SLSNSW defines the safety task and brings the site knowledge, camera operations and SOC procedures.
Its operators review alerts and coordinate any response through established communications. Trained responders carry out any rescue.
ResQVisionSoftware deployment and support
ResQVision develops the detection and tracking software and supports camera hardware, on-site server setup, field testing and alert delivery to the operating team.
Footage review and operator feedback guide further development and testing.
Why the delivery work matters
Camera framing, Axis hardware support, processing and connectivity affect whether an event is visible and an alert can be reviewed. Technical assistance, system checks and maintenance coordination form part of the delivery work.
Camera, network and technical-support responsibilities need to be agreed for each deployment, including who checks a lost or degraded feed and how issues are escalated.
Learning alongside operators
ResQVision's delivery account includes footage collection, field sessions with SLSNSW personnel and time observing the SOC. That work helps connect software development to the camera views and decisions operators already manage.
Sharing the experience
The public AFAC26 resource names SLSNSW and ResQVision contributors. SLSNSW acknowledges federal funding, with assistance from the NSW government, for SAIL.
Responsibilities and delivery: [1-3]. Agree support scope, availability, fault ownership and escalation for each deployment.
PUBLIC COMPANION / SAIL03 / Continuous improvement
Real conditions.
Useful lessons.
Recorded SAIL presentation view, already used on the website. Glare, distance and lens condition belong in the assessment. Annotations are not an accuracy result.
Camera framing determines what can be seen
The rock edge, waterline and area a person can move through need to be visible together. Review the complete hazard area and adjacent water when assessing coverage.
Difficult conditions need testing
The recorded footage shows glare, lens marks and distant people. Test footage needs to represent these everyday coastal conditions. Review false alerts and missed events across those conditions.
Alerts need to fit the SOC's workflow
Time observing the SOC helps us understand how an alert sits alongside calls, camera views and existing response procedures. Assess how operators receive, check and acknowledge an alert, and the review effort it adds.
Agree who handles feed problems
Power, connectivity, camera condition and processing belong in the operating plan. Agree how problems are noticed, who checks them and who is responsible for resolution.
These are field lessons and evaluation requirements. The public record does not quantify how much a particular change improved performance. Sources: [2, 3].
PUBLIC COMPANION / SAIL04 / Evidence and its limits
Operational experience.
Clear limits.
Public accounts describe how camera analysis, operator review and trained responders form part of the same response process.
Publicly documented operational responses
The AFAC26 paper describes a jet-ski recovery in Sydney's eastern suburbs and a helicopter response at Kiama. The accounts recognise the role of lifejackets and trained responders.
Documented experience- Trial sites at Kiama Blowhole and Little Bay.
- Alerts reviewed by SLSNSW operators.
- On-site setup, field testing and technical assistance.
- Public programme and conference accounts.
What still needs site-specific testing- Missed events and false alerts in representative conditions.
- Operator review effort and the steps from alert to response.
- Camera, feed and processing availability.
- Usefulness at a different site or for a new event.
Camera coverage, obstruction, weather, power, connectivity and available rescue resources affect what a site can support. The absence of an alert does not prove that no incident occurred.
New detection or analytics need their own testing. Public incident accounts do not establish a general accuracy rate or attribute a rescue to software alone.
No accuracy percentage, uptime percentage, quantified time saving or software-attributed rescue total is claimed here. Programme and evaluation sources: [1, 2].
PUBLIC COMPANION / SAIL05 / Evaluate your own site
Start with your site.
Agree what useful means.
An initial discussion can define camera coverage, the event to detect, operator review, responsibilities and measures of success for a first-site evaluation.
- Define the event. Name what the team needs to detect and the decision it would support.
- Review the view. Check framing, visibility, power and connectivity with representative footage.
- Agree the workflow. Identify who receives and checks alerts, decides on a response, and handles camera or feed problems.
- Check the evidence. Compare alerts with independently reviewed footage showing what actually happened. Assess missed events, false alerts and operator review effort.
- Agree the scope. Set data permissions, support responsibilities and what evidence will count as success before expansion.
Source references
- Surf Life Saving NSW: Surveillance AI for Lifesaving. Programme, sites, workflow and trial period. Checked 29 October 2026; later phases need confirmation.
- AFAC26: Surveillance artificial Intelligence for Lifesaving. Public resource, updated 18 August 2026, and linked conference paper.
- ResQVision: SAIL delivery case. Existing delivery, field-testing and SOC account. Companion wording updated 2 November 2026.