Cloudsail Arthur Councils Proposed pilot
Know which flood cameras and gauges you can rely on.
Cloudsail proposes a short, read-only pilot that independently checks a council’s monitoring: cameras, gauges, power and communications. It sits alongside the systems you already run. Nothing is replaced, and nothing on your network is controlled.
Arthur: Finalist, 2026 Innovate with nbn® Grants Program, Innovation for Productivity
Participant, CSIRO Innovate to Grow 2026, Digital Technologies & AI
01 Why independent assurance
A green light says a device answered. Not that it is working.
Most monitoring failures are silent. They tend to be found during an event, when duty officers are relying on the feed, or in the review afterwards, when nobody can say for certain which sources were working. Faults that never raise an alarm are not logged, so they are not fixed.
- 01
Frozen cameras
The feed reports online and answers every request, but the picture stopped changing hours ago. Arthur checks the picture, not just the connection.
- 02
Stale gauges
Values keep arriving, but the newest reading is old, or the level has not moved through heavy rain. Arthur checks how fresh each reading is and whether it is plausible.
- 03
Power and communications
The site hub loses power and several sources stop together, each looking like a separate fault. Arthur links them to the likely shared cause, labelled as inferred.
- 04
Missing evidence
When too few sources are working, Arthur says the evidence is not enough and refuses to guess, and it keeps a record of what it knew and when.
02 How it works
Arthur watches the monitoring. Continuous Assurance tests Arthur.
Both would run outside the council’s operational network, on a separate system, using a one-way read-only copy of selected data. There is no path back to council equipment.
- 1
Arthur
Is each source usable now?
Arthur assesses the health of each camera, gauge, power and communications source, and says when the evidence is not enough for an assessment.
- 2
Continuous Assurance
Is the monitoring still telling the truth?
Known test cases run through Arthur on a schedule. What its screens and interface show is compared with results set in advance, and any change from the last good run is flagged.
- 3
Evidence
A record your engineers can check
Every run keeps what was observed, what was expected and the result, in a hash-chained record where a later edit is detectable.
03 Where this is up to
What has been demonstrated, and what has not.
On synthetic data
- Arthur monitoring-health testing on a synthetic cyclone at a fictional site: camera, gauge, power and communications health, with shared causes
- Camera picture checks: frozen picture and offline
- Refusing an assessment when the evidence is not enough
- Independent assurance of Arthur’s real interface and dashboard, against expected results written in advance without running Arthur
- Scheduled replay, with missed and interrupted runs detected
- Evidence verification and regression checks on every run
Subject to council requirements
- Authorised, read-only monitoring of selected council cameras and gauges, subject to the council’s requirements and written permission
- Freshness and plausibility checks, reported as pass, fail or unverified
- Checks that the council’s display matches the underlying readings
- A written report with the evidence behind each observation
Still to be shown
- Real council integration. No live council feed is connected
- Sustained operational reliability. Scheduled runs so far are short internal tests, not weeks of operation
- Live field validation on real equipment
- Catching a gauge that sticks during a real flood, which is still in research
- An independent blind test, where faults unknown to Cloudsail are planted and scored
What was run
Arthur’s real web interface and operator dashboard were tested in a real browser on Arthur’s built-in synthetic cyclone, at 18 checkpoints through the event. Expected results were locked before the first run. Three automatically scheduled cycles each passed 961 of 961 checks, with 0 failed and 0 unverified, and no regressions between them. Three monitored repeat runs earlier the same day gave the same result.
Limits. One fictional scenario, synthetic data, run on our own equipment. The scheduled cycles ran back to back in a short test, not over weeks. No council system was connected. These results show the software behaves as specified in testing. They are not operational validation or a flood forecast.
04 The proposed pilot
Small, read-only, and agreed in writing first.
A proposed starting point, to be adjusted with each council: for example around 30 days, on a handful of assets the council selects, such as two creek gauges, a rain gauge and a flood camera. This is a proposal for discussion, not a fixed offer.
- 1
Discuss
Agree the scope
Which assets, for how long, what counts as a pass, and what data can be shared and how.
- 2
Prepare
Permissions first
A written agreement. Proposed: a privacy impact assessment, and a dry run on simulated feeds in the council’s data formats.
- 3
Run
Read-only, for the agreed period
Checks on the selected sources, with proposed daily summaries to a named council contact, or as agreed.
- 4
Review
Report, then decide
A written report reviewed with your engineers. If useful, a possible ongoing assurance subscription, scoped from the results.
05 Questions
What a pilot would involve.
What would the council provide?
Written agreement for read-only monitoring of the selected assets; a one-way, read-only copy of the selected telemetry, by webhook, file drop or read-only API access; read-only access to snapshot images from the selected cameras; and a named technical contact, such as a systems engineer or disaster management officer.
What is deliberately excluded?
Public warnings, evacuation messages and flood declarations, which stay with the council and official agencies. Any control of pumps, gates, sirens or other infrastructure: no commands are sent to council systems. Changes to council hardware or software. Sign-off of structural safety or flood immunity. Identifying people or vehicles: camera use would be limited to views of waterways and gauge boards.
How are results and uncertainty reported?
Every check would be reported as pass, fail or unverified. Missing evidence is reported as unverified, never as a pass. A cause that is inferred rather than observed is labelled as inferred. Interrupted test runs are recorded as incomplete, so gaps in the pilot itself are visible.
Where would the data be kept?
Proposed: pilot evidence stored in Australia. Where data is kept, who can see it and how long it is kept would be agreed in writing before anything is connected.
Who is technically responsible?
A qualified technical lead, to be appointed and agreed with the council before any pilot starts. That lead would set and check thresholds, review each reported anomaly before it is discussed with the council, and sign off the final report.
Is Arthur in use at a council today?
Not yet. Arthur and Continuous Assurance run on synthetic data. A first pilot would be the first connection to a council’s systems, and only with written permission.
Who would we be dealing with?
Cloudsail Technologies Pty Ltd, ABN 63 615 833 782, an Australian-owned company established in Cairns, Queensland, in 2016. Pilot scope, data handling and any commercial commitment would be agreed in writing with the company. About Cloudsail.
Talk to us about a pilot.
Tell us which cameras, gauges or pathways worry you most. We will come back with a proposed scope, the permissions it would need, and what you would receive.