Ecological restoration in a hydropower disturbance zone: AI identification with explainable plan recommendation

Building a hydropower scheme disturbs the ground around it — cut slopes, spoil areas, haul roads — and every one of those surfaces has to be restored and then shown to have been restored. The engineering is well understood. What is not well handled is the decision layer above it: knowing what each slope actually is, how degraded it is, which restoration measure suits it, and being able to explain afterwards why that measure was chosen.

What the site was up against

• Data arriving from sources that never met — UAV multispectral imagery, ground soil and micro-weather stations, satellite remote sensing — with no shared spatio-temporal baseline and no common scheduling or status monitoring.
• Slope type, vegetation cover and soil erosion assessed by eye and by quadrat survey: slow, subjective, and impossible to replicate consistently across many slopes.
• Restoration plans drawn from expert judgement, with the underlying case knowledge held in people rather than in any structured form — so it degrades every time someone leaves.
• No unified database, operation log or one-click reporting, against a backdrop of flight-safety, data-security and power-station network-isolation requirements.

Air, space and ground on one baseline

A DJI M300 RTK-class platform with a multispectral camera flies the waypoint missions; soil multi-parameter probes and micro weather stations report over SDI-12 and Modbus RTU into an edge node on each demonstration slope, solar-powered with a 12 V 40 Ah lithium-iron-phosphate bank sized for three consecutive overcast days. The preprocessing and fusion module handles mosaicking, geometric correction and NDVI, then ties every sensor reading to a spatial cell by timestamp and RTK coordinate, emitting GeoTIFF orthomosaics and attributed GeoJSON. The targets are a ground sampling distance of 5 cm per pixel or better, a single slope mosaicked inside ten minutes, and sensor data completeness at or above 95 per cent.

Identification that publishes its confidence

Slope type — earthen, rocky or mixed substrate — is classified by semantic segmentation over the orthomosaic, tiled into 512 × 512 blocks for parallel inference and recomposed into a global classification and spatial distribution map. Vegetation cover is computed from the multispectral bands and validated against quadrat measurements. The numbers we are working to are classification accuracy at or above 90 per cent against human-labelled samples, absolute vegetation-cover error within 10 per cent, and a single image processed inside two minutes. Every output carries a confidence value, and anything below threshold is routed to a person rather than passed downstream.

A knowledge graph that shows its working

Restoration knowledge goes into a Neo4j property graph — catchments, slopes, restoration measures, plant species, soil types, climate characteristics and historical risk cases, with relations such as slope-suits-measure and measure-contains-species, at an initial scale of the order of 100,000 entities and 500,000 relations. Cypher rule inference plus graph similarity algorithms find the closest analogous cases and propose the corresponding measure combinations; the assessment module folds those together with the AI outputs to grade ecological risk low, medium or high, identify the driving factors and rank a recommendation list with side-by-side comparison and stated rationale. Around 200 expert-curated cases seed the graph to get past cold start, the target is an 80 per cent hit rate against a historical test set, and a typical query returns inside three seconds.

The AI advises; a person decides

That separation is a design constraint, not a disclaimer. A recommended plan cannot be adopted until a human reviewer confirms it, and the system runs no unattended closed loop. Flight safety — geofencing, no-fly zones, low-battery and link-loss return-to-home — executes on the flight controller independently of anything the application layer does, and cannot be switched off. Every key operation and every recommendation is written to an audit log that is timestamped, searchable, exportable and not deletable. Transport is TLS 1.2 or better, sensitive fields are encrypted at rest, backups run daily incremental and weekly full with at least four weeks retained, and the whole platform deploys privately on the customer’s own servers to satisfy station network isolation.

Four layers, six modules

The architecture separates field acquisition, edge, central platform and user interaction, so that each can be upgraded — and redeployed to another station — on its own. The six modules behind it talk through a documented OpenAPI 3.0 contract:

• Data acquisition — unified capture configuration, task scheduling and device status, over REST for tasks, MQTT for sensor streams and WebSocket for device state.
• Preprocessing and fusion — mosaicking and geometric correction, NDVI, and coordinate association into GeoTIFF and GeoJSON products.
• AI model service — slope classification, vegetation cover and assisted diversity assessment, each containerised behind TorchServe or Triton with version management and canary release.
• Risk assessment and recommendation — grading, driving-factor attribution and ranked plan lists, combining model output with graph inference.
• Knowledge graph — Neo4j property graph with similarity algorithms and an ETL path for bulk case import.
• Visualisation and reporting — a Vue 3 dashboard with ECharts and Leaflet, live over WebSocket, plus one-click detection, risk and restoration-plan reports.

Where the programme stands

This is a design-stage engagement. Nineteen functional requirements and the non-functional baseline are captured, the four-layer architecture and the stack are drafted — FastAPI, PyTorch with TorchServe, PostgreSQL with PostGIS alongside MinIO and Neo4j, Vue 3 on the front — the module split and interface specification are written, and the dashboard exists as a working online prototype. In progress is a single-machine Docker validation environment that runs mosaicking, inference, MQTT reporting and graph query end to end, together with baseline model training and the initial graph import. Acceptance is gated on one thing above all: the complete workflow, from acquisition through to recommendation, demonstrated on three nominated slopes — one earthen, one rocky, one mixed — with a validation report to match.

One boundary is worth stating plainly, because it was agreed at the outset. The system recommends restoration measures on the basis of the data it holds and the inference it can justify; it does not warrant the ecological outcome. Acceptance judges whether the recommendation is scientifically sound and operationally workable — not the vegetation that eventually grows from it.