D5.4 I-CISK Platform Final Technical Specification and platform manual

Deliverable D5.4 - I-CISK Platform Final Technical Specification and Platform Manual Sep, 2025 This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 101037293 Innovating Climate services through Integrating Scientific and local Knowledge This document builds upon Deliverables D5.1, D5.2 and D5.3. It presents final technical specifications where different from what has been presented earlier, i.e., in D5.3. This deliverable also provides the complete user manuals for the I-CISK climate service platform, which is developed within the I-CISK project. Furthermore, the Auto-CS composer is presented and discussed. Deliverable Title: I-CISK Platform Final Technical Specification and platform manual Author(s): S. Bagli, P. Mazzoli, V. Luzzi, M. Renzi, F. Renzi, S. Pianini - GECO B. Gräler, J.Schnell - 52N G. Bela - IDEAS Science Ltd. E. Romas -A.Ziogas EMVIS D. Castellana - RC510 A. Broekman, L. Pesquer, E. Prat - CREAF Date September 15th, 2025 Suggested citation: www.icisk.eu/resources Availability: ☒ PU: This report is public ☐ CO: Confidential, only for members of the consortium (including the Commission Services) Document Revisions: Authors Revision Date Stefano Bagli First draft 01/09/2025 Benedikt Gräler Submission ready version 15/09/2025 Micha Werner Submission 15/09/2025 This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 101037293 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Executive Summary The I-CISK project, "Innovating Climate services through Integrating Scientific and local Knowledge," develops web-based climate services by combining scientific and local knowledge, iteratively incorporating user feedback. Deliverable D5.4 documents the final release of the I-CISK Climate Service Platform, providing user manuals and technical summaries for each Living Lab (LL), highlighting their use cases. It also introduces the innovative Climate Service AUTO Composer, an LLM-based interface enabling users and providers to customize and deploy new climate service applications. This document builds on D5.2 and D5.3. The seven LL focus, by design of the project, on very different use cases and applications; hence each user manual also differs accordingly. ● In the living lab in Andalucia, Spain six Climate Services have been co-developed for agriculture, offering tools for historical analysis, future projections, and hydrological information. These services provide farmers with critical data on temperature, precipitation, drought, and agricultural indicators to support planning and mitigation measures. ● The I-ISK platform offers for the Living Labs in Emilia Romagna, Italy and Alazani River basin, Georgia preoperational daily discharge forecasts for selected river sections with historical context and management thresholds, targeting water managers and technicians. Users can access daily discharge views, medium-range summaries, and seasonal cumulative-volume views, supporting decisions like withdrawal management and enabling data export for reporting. ● The Climate Service of the Living lab in Rijnland, Netherlands, provides specialized climate information for recreational boating, agriculture, water management, and tree nurseries. Users can quickly assess drought, precipitation deficits, water inflow, and future climate scenarios for adaptation.. ● The Living Lab of Crete, Greece provides a web-based platform with four key services offering forecasts and data at various temporal and spatial scales supporting decision-making in tourism, water management, and long-term climate adaptation for the island of Crete. ● The Budapest Living Lab's CityZcan platform offers urban heat island management in Hungary. It aids tourism, healthcare, and urban planning with thermal monitoring and early heatwave warnings through interactive web maps, an open-source thermal image analysis plugin, and an open-format data archive. ● The Lesotho Climate Service provides seasonal drought information through two deployments: a public I-CISK portal for exploration and an operational IBF platform used by the Lesotho Red Cross for day-to-day operations. Both systems utilize the Precipitation Drought Index (PDI) to assess drought likelihood and severity, with the IBF portal additionally quantifying drought risk and exposed populations to support anticipatory action. A central motivation behind the development of the Climate Services is to lower the entry barriers for non-specialist users, who often lack advanced programming skills, by giving them direct and user-friendly access to upstream data services (e.g., Copernicus CDS, GEOSS). By making climate data readily available, the Climate Service empowers users to configure tailored applications that reflect their specific contexts and decision-making needs. 3i [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Table of Contents Executive Summary 3 List of Figures 5 List of Tables 8 1. Introduction 9 2. Methodology 10 3. General Technical Platform Overview 11 3.1 Technical specifications of the I-CISK platform – Final Release 11 3.2 Common Components 11 3.3. Installation Overview 13 4. I-CISK Climate Service Manual and Tutorial 14 4.1. Andalucía Living Lab (Spain, LL1) 14 4.2. Emilia Romagna Living Lab (Italy, LL2) 22 4.3. Rijnland Living Lab (Netherlands, LL3) 27 4.4. Crete Island Living Lab (Greece, LL4) 31 4.5. Budapest Living Lab (Hungary, LL5) 44 4.6. Alazani River basin Living Lab (Georgia, LL6) 50 4.7. Lesotho Living Lab (LL7) 57 5. Climate Service LLM-based AUTO Generator 61 5.1 Introduction and Purposes 61 5.2 Technical Manual 62 5.3 User Manual 72 6. Summary 81 7. Challenges and Solutions 82 8. Conclusion and Future Work 83 9. Appendices 84 9.1 Acronyms 84 4 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] List of Figures Figure Caption (shortened)) Page Figure 4.1-1 Screenshot of the landing page of the Spanish LL showing the six CS as tiles and as tabs in the navigation bar at the top of the website.. 14 Figure 4.1-2 Screenshot of the CS “Mapas previsión a 6 meses”. 15 Figure 4.1-3 Screenshot of the CS “Mapas climáticos históricos”. 16 Figure 4.1-4 Screenshot of the CS “Estaciones climáticas históricas”. 17 Figure 4.1-5 Screenshot of the CS “Proyecciones climáticas”. 18 Figure 4.1-6 Screenshot of the CS “Indicadores agroclimáticos”. 19 Figure 4.1-7 Screenshot of the CS “Información hidrológica”. 20 Figure 4.2-1 GUI landing page with station list (top and bottom zoom left), station position on the map (center and bottom zoom) and dashboard to activate specific graphs with access to station data and the forecasts available (top right). 22 Figure 4.2-2 Forecast discharges selectable through the GUI; 23 Figure 4.2-3 Average forecast volumes in the coming season, provided versus historical average in the same period obtained from the last 10 years of observation, includes statistical variability in boxplot fashion. 24 Figure 4.2-4 The daily forecast accessed by the user for the selected station compared to the relevant thresholds. 25 Figure 4.2-5 Toggling on uncertainty of the probabilistic forecast to get confidence level. 26 Figure 4.3-1 Left: Landing page for the CS for the selected role of “Waterbeheer”. Right: Summary calendar week view of the drought situation in the Rijnland region. 27 Figure 4.3-2 Combined map and time series representation of the precipitation deficit. 28 Figure 4.3-3 Screenshot of the CS “Afvoer Lobith” showing the runoff of the river Rhine near Lobith. 29 Figure 4.4-1 Initial screen of the Living Lab of Crete developed in I-CISK. 31 Figure 4.4-2 Initial screen of Seasonal Indicators service. 32 Figure 4.4-3 Selection of seasonal indicator and map interactions. 34 5 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure Caption (shortened)) Page Figure 4.4-4 Graph of the temporal variation of the selected indicator (Frequency of North Winds > 7BF) for the next 7 months. 35 Figure 4.4-5 Initial screen of Hydrological Indicators service. 36 Figure 4.4-6 The forecasts of river discharge are presented as time series (aggregated at 15-days intervals) for the forecasting horizon of 7 months, along with their statistical properties. 37 Figure 4.4-7 Individual members and statistical properties of the hydrological ensemble. 37 Figure 4.4-8 Initial screen of the Water Management Service for OAK end user. 38 Figure 4.4-9 Customized views of the Water Management Service for OAK. 49 Figure 4.4-10 Initial screen of the Climate Projections service. 40 Figure 4.4-11 Steps for selecting an indicator and displaying the climate projections map. 41 Figure 4.4-12 Toggler for displaying map values as absolute or relative. 42 Figure 4.5-1 Screenshot of the landing page of the CityZcan Webpage. 45 Figure 4.5-2 Examples of two map layers for the Terézváros district in Budapest under study. 46 Figure 4.6-1 Screenshots of the GUI landing page with station list (top left), station position on the map (top and bottom left as zoom in) and dashboard to activate specific graphs with access to station data and the forecasts available (top right and bottom right as zoom in). 51 Figure 4.6-2 Screenshots of the hydro forecast component _ average monthly graph. 52 Figure 4.6-3 SPI-3 index. 53 Figure 4.6-4 Temperature & Precipitation module. 54 Figure 4.7-1 Main service landing page for Lesotho – public demo version. 58 Figure 4.7-2 Impact-Based Forecasting (IBF) Portal overview. 59 Figure 4.7-3 Impact-Based Forecasting Portal Warning state example (“Drought ongoing”). 60 Figure 5.2-1 Component diagram of the auto composer structure. 63 Figure 5.2-2 Sketch of the auto composer functional subgraphs. 65 Figure 5.2-3 Auto composer User responses interpretation. 69 Figure 5.3-1 Screenshot of the Auto composer control panel layout. 73 6 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure Caption (shortened)) Page Figure 5.3-2 Auto composer Generation of code example. 73 Figure 5.3-3 Auto composer input confirmation example. 75 Figure 5.3-4 Auto composer output confirmation example 76 Figure 5.3-5 Auto composer Quick Actions section 77 Figure 5.3-6 Auto composer File Manager section 78 Figure 5.3-7 Auto composer Preview Notebook section 78 Figure 5.3-8 Auto composer access to technical documentation 79 7 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] List of Tables Table Caption (shortened)) Page Table 3.2-1: Tabular summary of the components of the climate data ingestor based on the detailed descriptions in D5.3. 12 8 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 1. Introduction The I-CISK project, "Innovating Climate services through Integrating Scientific and local Knowledge," aims to develop innovative climate services by integrating scientific and local knowledge to address the specific needs of various regions. This deliverable, D5.4, targets users of the developed Climate Services (CS) with some preliminary knowledge about climate service technologies. Technical summaries are kept at a high level avoiding as much as possible technical language and specialised IT terminology. The I-CISK project is built on a foundation of co-design, involving stakeholders from the early stage, so that the climate services developed are not only scientifically robust but also tailored to the specific needs of local user communities. The project employs a collaborative approach where requirements are gathered, discussed, and verified among stakeholders and work packages through the establishment of “Climate Service Task Forces” (CSTFs). These CSTFs are instrumental in defining and refining climate services for each Living Lab, ensuring that solutions meet local needs and are supported by robust data integration and processing frameworks. The I-CISK platform described hereafter is a cloud-based system utilising advanced technologies such as Docker and Kubernetes for scalability and flexibility. It supports the ingestion, processing, and visualisation of climate data from multiple sources, seeking high performance and reliability. The platform's architecture has evolved to incorporate best-of-breed open-source components, enhancing its functionality and effectiveness. Each Living Lab within the I-CISK project has developed tailored solutions for climate data integration, back-end processing, and front-end visualisation. This deliverable details the usage of the front-end components in I-CISK’s LLs in Spain, Emilia Romagna, Rijnland, Crete, Budapest, Georgia, and Lesotho as developed by the end of the project. Beyond the specifically co-designed CS for each LL, a CS Auto-composer (Task 5.4) has been developed (see Section 5). It is based on LLM agents interacting with the user through chat prompts to integrate and visualise climate relevant data in a jupyter notebook. After the initial testing phase, as detailed in the previous iteration of development, work has focused on ensuring quality goals through rigorous functionality, performance, and usability testing. User feedback received during several iterations of implementation has been instrumental in refining the platform, leading to improvements in navigation, data visualisation, and overall user experience. 9 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.1-3: Screenshot of the CS “Mapas climáticos históricos” showing interpolated monthly mean temperature observations for April 2000 on the left half of the map and for April 2015 on the right half of the map. Clicking into the map (red circle) opens time series plots below the map window. The second CS is titled “Mapas climáticos históricos” allows to compare monthly interpolated observations of temperature, precipitation and a set of drought indices since the year 2000. Shown in Figure 4.1-3 are the interpolated monthly mean temperature observations for April 2000 on the left half of the map and for April 2015 on the right half of the map. The slider below the map allows to move the break between the left and right side selection in East and West direction. The dropdown menus above the map control the selection of the variables shown in the map. Selecting drought indices adds another dropdown menu to select among SPI (Standardized Precipitation Index) and SPEI (Standardized Precipitation Evatransporation Index) for different temporal horizons from 3 to 24 months. As different temporal horizons are used for different decisions. Clicking into the map (location depicted as red circle) opens a time series view, where the entire time span of data is 16 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] visualised for the selected location for all variables. The radio buttons above the time series plot allows the user to either compare the entire time span, or the two selected years on a monthly basis. This CS allows the user to assess the past weather and climate conditions. This can be very helpful to better understand the conditions from the forecasts shown in the previous CS, as the user can relate it to already experienced conditions. Figure 4.1-4: Screenshot of the CS “Estaciones climáticas históricas” showing the observed data in all available weather stations. Clicking on a location in the map opens a time series plot for this particular weather station. Very related to the previous CS is the CS “Estaciones climáticas históricas”. Instead of interpolated monthly values, it depicts the location of the weather stations in the study region. Once a station is selected, a time series plot is added underneath the map window. Different options of the radio buttons allow to compare the data for different purposes. Shown in Figure 4.1-4 is the monthly statistic of a single year, but the visualisation can also show the entire time span, compare monthly values of two years, show an individual time span or the development of a single month over time. This CS allows the user to assess the raw observations of past weather and climate conditions. This can, as for the interpolated CS, be very helpful to better understand the conditions from the forecasts shown in the previous CS, as the user can relate it to already experienced conditions. This CS also features more comparison options, than the interpolated flavour of it. 17 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.1-5: Screenshot of the CS “Proyecciones climáticas” showing climate projections beyond 2040. The tab “Proyecciones climáticas”, depicted in Figure 4.1-5, shows climatic predictions of the variables temperature and precipitation. The time slider above the map allows the user to select an year of interest. It is important to note, that the simulation underlying this plot should not be seen as precise predictions for the selected year, but as a likely situation within these years. The selection of a location opens the time series plot visualising the development of the selected pixel over time. This CS is useful to assess the mid-range future of changes in temperature and precipitation for Andalucia. 18 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.1-6: Screenshot of the CS “Indicadores agroclimáticos” depicting the maximum number of consecutive dry days in spring 2011. The CS “Indicadores agroclimáticos” goes beyond the main variables of temperature and precipitation and has been developed to visualise the indicators of i) maximum number of consecutive dry days, ii) maximum number of consecutive summer days and iii) number of summer days. While i) and ii) have a temporal resolution of seasons, the third indicator has a ten-day resolution. Clicking into the map selects a pixel and opens a time series plot under the map visualising the temporal development of this indicator. This CS provides information that are directly related to plant health in the agricultural sector being an important source of information to plan adaptation measures. 19 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.1-7: Screenshot of the CS “Información hidrológica”. The background map shown depicts a land use classification of the region. Overlaid are the groundwater measurement stations from two distinct networks. This last CS focuses on the hydrology of the region “Los Pedroches”. It is titled “Información hidrológica” (Figure 4.1-7) and features a rich user interface to select different thematic base maps (radio buttons on the left) and a set of data layers to overlay on the base maps (checkboxes on the right). This CS provides user tailored information to the water availability and hydrological structure of the region los pedroches. The provided information helps to better plan and prepare for drought situations in the region. 20 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Technical Summary This CS is designed as several separate docker containers for backand front-end components. It accesses data from different sources, mainly the Copernicus Data Store (CDS), data provided by project partner CREAF as well as the ftp-server of SMHI. The back-end is developed around the library pygeoapi and utilises ZARR-Archives for storing data in S3-buckets of the Open Telecom Cloud. Additionally we also save Cloud Optimised Geotiffs (COGs) there. Each dataset creation and publishing follows OGC standards. Each data creation is implemented as an OGC API process and published as a collection. The front-end is based on Open Pioneer Trails utilising React and Openlayers as its key technologies for visualising time series data, the highcharts library has been utilised and customized. In order to operate the CSs, two docker images, namely the trails frontend as well as the pygeoapi-ingestor-image need to be deployed along the cloud storage. During the first start, data is retrieved and stored in the s3 Buckets. Most text elements are stored in an i8n structure that allows for translation to different languages. Maps and charts are highly customized in the source code itself. For further technical information, please refer to the GitHub repositories: https://github.com/icisk/llspain_trails https://github.com/icisk/pygeoapi_ingestor 21 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 4.2. Emilia Romagna Living Lab (Italy, LL2) User Manual Service introduction and landing page The preoperational service for Emilia Romagna Living Lab provides daily discharge forecasts for selected river sections, alongside historical context and management thresholds. The interface targets water managers and technicians in public/private entities such as irrigation consortia, hydropower operators, water utilities, as well as public authorities responsible for regulation and monitoring. No programming skills are required to use the service as will be clear in the following description. The landing page (Figure 4.2-1) combines station selection, available from both the list and the central map, and a chart panel on the right side. On selection of a station of interest, information is provided by the charts. Figure 4.2-1: GUI landing page with station list (top and bottom zoom left), station position on the map (center and bottom zoom) and dashboard to activate specific graphs with access to station data and the forecasts available (top right). 22 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Particularly, from this entry point the discharge views and medium-range summaries are accessible without leaving the page. The following figures show the current release of the GUI and the two key visualizations: 1. daily discharge forecasts Vs observed values. Figure 4.2-2: Forecast discharges selectable through the GUI; custom forecast window daily has been chosen among available, with capability to activate-deactivate statistical forecast percentiles to improve legibility and understand forecast variability. 23 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] From the landing page, the user first selects the visualization type and, where available, the forecast provider (e.g. GLOFAS forecasts from Copernicus ) that has been activated for the service. Figure 4.2-2 presents the daily discharge view for the selected station, where recent observations are recorded and forecasted flows are plotted on a common time axis. The display window is user-defined: preset zoom ranges above the chart and a time slide below allow inspection of the recent past and the selected forecast horizon in one continuous view. A concise legend distinguishes observations, the forecast median, and optional percentile bands; users can toggle these bands to expose or hide uncertainty as needed. Advanced ensemble views are available on demand, reflecting operator preferences for a clean operational chart. Finally, Threshold lines provide immediate operational context. The chart can show indeed “above/below normal” bands and equivalent “extreme low” references, such as ecological-flow limits with seasonal variants; these markers are used to assess proximity to management triggers for activating or suspending withdrawals. Figure 4.2-4 below presents the seasonal cumulative-volume view. Forecast totals for the selected window are displayed alongside the historical average for the same period compared to the last ten years. Statistical variability is conveyed with box plots. The interactive legend allows enabling or disabling variability ranges, while a dropdown provides direct download of the underlying data in tabular form. Figure 4.2-3:-Average forecast volumes in the coming season, provided versus historical average in the same period obtained from the last 10 years of observation, includes statistical variability in boxplot fashion. 24 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Indeed, both visualizations support export. The service can produce compact outputs in standard graphic formats (e.g., PNG for charts) and in tabular form (e.g., CSV for daily or cumulative strips) for routine reporting, board briefings, and bulletins to end users such as associated farmers or industrial water users. Example use case: Land Reclamation Consortium for withdrawal management in the incoming season This didactic scenario illustrates a typical end-to-end session with the service and how its outputs may support withdrawal decisions. In early June, the planner opens the landing page (Figure 4.2-1), selects the active forecast provider (e.g., Copernicus GLOFAS), and chooses the station of interest (e.g., Lugo), whose incoming discharge governs activation and suspension of withdrawals under the applicable protocol. The daily discharge view (Figure 4.2.4) is activated to display the next-weeks forecast against reference conditions and “below-normal” bands aligned with the summer lower ecological-flow threshold. The median forecast (50th percentile) trends toward the “below-normal” band within two weeks, implying a likely suspension shortly after. Figure 4.2-4: The daily forecast accessed by the user for the selected station compared to the relevant thresholds. 25 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Seasonal Indicators for Tourism This service contains essential meteorological variables and other tourism-related indicators for a forecasting horizon of 7 months, updated on a monthly basis (Figure 4.4-2). Figure 4.4-2: Initial screen of Seasonal Indicators service. 32 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] The indicators are grouped into four categories as presented in the following overview: Essential Climatic Variables Seasonal forecasts of climatic variables (e.g. temperature, precipitation) are obtained from ECMWF through Copernicus Climate Change Service (C3S) Temperature. Forecasts of average air temperature aggregated on a 15 days reference period for the next 7 months. Updated once a month on the 6th. Precipitation. Forecasts of average daily precipitation aggregated on a 15 days reference period for the next 7 months. Updated once a month on the 6th. Climatic Tourism Indicators Easy-to-understand metrics that provide specialized and tailored information to activities related to tourism Tourism Climatic Index. The Tourism Climatic Index (TCI) evaluates the climate favorability for outdoor tourism by combining seven climatic variables related to the human comfort levels. TCI is calculated on a 0 to 100 scale. Values close to 0 represent unfavorable conditions, while values close to 100 represent ideal conditions. Light Precipitation Frequency. Frequency of days that daily precipitation exceeds 1 mm. High Precipitation Frequency. Frequency of days that daily precipitation exceeds 10 mm. Extreme Precipitation Frequency. Frequency of days that daily precipitation exceeds 50 mm. Frequency of Extreme Hot Days. This indicator is calculated by the number of days that the Maximum daily temperature exceeded 35 oC, and it is expressed as a percentage over the reference period (15 days). Frequency of Tropical Nights. This indicator is calculated by the number of days that the Minimum daily temperature did not drop below 20 oC, and it is expressed as a percentage over the reference period (15 days). Cooling Degree Days. Cooling Degree Days (CDD) are a measure of how much (in degrees), and for how long (in days), outside air temperature was higher than a specific base temperature, and is directly related to the energy demand for cooling residential buildings. CDD is calculated using a base temperature of 25 oC, and assuming that no cooling is needed when the outside temperature is below this threshold. CDD are calculated for a period of 15 days and are presented as the daily average for that period. Infrastructure Indicators Indicators related with critical infrastructure that may affect tourism activities Instability Index. The instability index is used to quantify the susceptibility and hazard of landslides and slope failures in a specific area. The index is calculated taking into consideration multiple factors (e.g., soil properties, slope inclination, geology, rainfall conditions) and is calculated in a 0 to 100 scale (higher values denote a higher risk of landslides). Marine navigation Seasonal indicators from ECMWF ocean modelling that affect port operations Frequency of Strong N&NW Winds. Frequency of days that North and Northwest wind gusts exceed 7 Beauforts. Frequency of Strong S Winds. Frequency of days that South wind gusts exceed 7 Beauforts. Significant height (wind + swell). This is the significant height of combined wind waves and sea swell measured in meters. Mean wave direction. Direction of surface waves considering both wind-sea waves and sea swell. This parameter is the average of all frequencies and directions of the 2D wave spectrum. Mean wave period. The average time (in seconds) it takes for two consecutive wave crests on the sea surface to pass through a fixed point. Averaging is applied over all frequencies and directions of the 2D wave spectrum. 33 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Available parameters and indicators are grouped into 4 categories, which can be selected by the user through different drop-down menus (Figure 4.4-3). The spatial and temporal variation of each indicator is presented through maps and timeseries graphs. By clicking at any point at the map the value of the selected indicator for the point of interest is displayed. The user can navigate through different dates of the forecasting horizon by selecting the appropriate date in the time bar at the bottom of the screen (Figure 4.4-4). For each indicator, maps are available at 15 days intervals for a forecasting horizon of 7 months ahead. Selection of indicator category. Selection of indicator. Spatial variation of each indicator is presented through a map component. Maps are available for 7 months ahead, at 15 days intervals. Users can navigate through the timebar at the bottom of the screen. Figure 4.4-3: Selection of seasonal indicator and map interactions. 34 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.4-4: Graph of the temporal variation of the selected indicator (Frequency of North Winds > 7BF) for the next 7 months. 35 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Hydrological Indicators This service aims to address water allocation needs, by providing seasonal forecasting of river discharges through hydrological forecasting. A large ensemble of 51 members of climate forecasts is used from the ECMWF’s SEAS model as forcing in the HYPE hydrological model. The initial screen of the service is presented at the following figure (Figure 4.4-5). Figure 4.4-5: Initial screen of Hydrological Indicators service. The results of the hydrological model are available at each catchment of Crete (42 catchments in total). By clicking on a catchment, a graph presenting the variation of the river discharge for the next 7 months is displayed on the screen (Figure 4.4-6). The graph is able to display the individual ensemble members of the hydrological simulation as well as their statistical properties displayed as box plots (Figure 4.4-7). 36 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.4-6: The forecasts of river discharge are presented as time series (aggregated at 15-days intervals) for the forecasting horizon of 7 months, along with their statistical properties. Display of the individual 51 members of the ensemble hydrological forecast. Statistical properties of the forecast as box-plots displaying the maximum, the 75th percentile, the mean (red line), the median, the 25th percentile and the minimum of the ensemble. Figure 4.4-7: Individual members and statistical properties of the hydrological ensemble. 37 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Water management service for OAK The service is based on providing a forecast for the volume of water expected to enter reservoirs used for drinking purposes, during the upcoming wet period i.e. Nov-Dec-Jan-Feb. This service is customized for OAK, i.e. the manager of Crete’s water bodies, which needs to plan the allocation of water resources between tourism, agriculture and other critical water demanding sectors. This procedure takes place in early spring and OAK used to rely on historical data in order to estimate the future water availability of each reservoir. The developed service allows OAK to take decisions using seasonal hydrological forecasts to estimate the volume of incoming water, and evaluate different strategies for each reservoir according to its potential during the wet period. The initial page of the water management service is presented in the following figure (Figure 4.4-8). Figure 4.4-8: Initial screen of the Water Management Service for OAK end user. The graph in Figure 4.4-8 displays the most recent estimation for the total volume of water in hm³ expected to enter each one of the five reservoirs (Amari, Aposelemis, Bramianos, Faneromeni, Plakiotissa) used for drinking water purposes in Crete. In a separate graph the user can compare the current forecast of river discharges with historical simulated hydrological data from the period 1980-2020. The comparison allows the user to be able characterize the current hydrological year as normal, wet, dry, etc. (Figure 4.4-9 a). A separate graph (Figure 4.4-9 panel b) displays how the estimation for the total volume of water expected in each reservoir during the wet period changes, as hydrological forecasts are being updated. 38 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] a) The graph displays that the current forecast of river discharge (red dotted line) for the selected catchment is below the 20th percentile of historical river discharges b) Latest forecast of water volume expected during the wet period (red dot), and expired forecasts (orange dots). Figure 4.4-9: Customized views of the Water Management Service for OAK. 39 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Climate projections Beyond the seasonal time scale, the Living Lab of Crete offers insights into the evolution of key climatic variables and tourism-related indicators over the coming decades, enabling users to assess and plan long-term adaptation measures (Figure 10). Climatic projections are obtained from the Copernicus Climate Data Store and processed for multiple parameters and indicators at a spatial resolution of 0.11° × 0.11°, which are available for whole Greece. For each indicator, results are provided from seven combinations of Global and Regional Climate Models (GCM–RCM), along with the ensemble mean. The projections are based on CORDEX climate experiments using the Representative Concentration Pathways (RCPs), specifically RCP 4.5 and RCP 8.5, which span a wide range of plausible climate futures. Figure 4.4-10: Initial screen of the Climate Projections service. The user selects the parameter, and the relevant indicator from a drop-down menu, together with a series of other options needed (Figure 4.4-11) for the map to be displayed on the right panel. The values in the maps and graphs can be presented either as "Absolute" values or as "Relative" change from a historical baseline 1980-2005 (Figure 4.4-12). 40 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 1) Selection of Parameter category 3) Selection of Global and Regional climate models 2) Selection of Indicator or Variable 4) Selection of Representative Concentration Pathways RCPs and Time horizon. Figure 4.4-11: Steps for selecting an indicator and displaying the climate projections map. 41 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Applications Gallery and Dataset Archive The platform maintains a continuously evolving applications gallery at city.zcan.eu/apps/ that serves as a dynamic repository for climate service tools and resources. This gallery represents a living platform that will continue to expand throughout the project lifecycle and beyond, ensuring long-term sustainability and continued innovation in urban heat island research. The applications gallery includes a dedicated section for measured thermal data (raw data), providing researchers, developers, and stakeholders with access to the complete thermal datasets collected during the Budapest Living Lab campaigns including: ● Original drone thermal imagery in full resolution provided in GeoTIFF format ● Ground-level thermal measurements from mobile thermal cameras and sensor networks Data Accessibility and Standards To ensure maximum compatibility, data is provided in internationally recognized, standardized open formats such as GeoTIFF and CSV. Comprehensive metadata and quality assurance documentation accompany all datasets. System Requirements Web Interface Access ● Browser compatibility: Modern web browsers (Chrome, Firefox, Safari, Edge) ● Internet connection: Broadband recommended for smooth map tile loading ● Device support: Desktop, tablet, and mobile devices with responsive design ● No registration required: Open access to basic visualization tools CityZcanView Application ● Operating system: Windows, macOS, or Linux ● Fiji/ImageJ: Latest version recommended ● Java: Java 8 or higher ● RAM: Minimum 4GB recommended for large thermal image processing ● Storage: Variable, depending on dataset size User Authentication and Access Levels The Budapest Living Lab employs a tiered access approach where not all data is directly available on the platform, but can be provided on request. The public access (without registration) provides: ● Basic web interface navigation ● Standard heat map visualization ● General documentation access ● Educational materials Support and Feedback ● Contact: I-CISK Team (inf[email protected]) and IDEAS Team (inf[email protected]) ● Project website: icisk.eu and city.zcan.eu 48 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Summary and Outlook The Budapest Living Lab focuses on urban heat island (UHI) management in Hungary within the temperate continental climate of the Carpathian Basin, specifically targeting the tourism, healthcare, and urban planning sectors. The innovative CityZcan platform (city.zcan.eu) combines high-tech thermal monitoring with community participation, providing comprehensive street-level heat measurements. The Living Lab's primary objectives include raising awareness of urban heat risks, supporting public health planning with early heatwave warnings, and assisting urban planners and energy managers in climate adaptation strategies. The service is primarily accessible through web-based interfaces, where the interactive heat mapping tool (city.zcan.eu/osm-orto-heat-layers.html) offers multi-layer visualization with orthophotos, thermal images, and CNN predictions for Budapest's Terézváros and Erzsébetváros districts. The platform provides an open-source CityZcanView plugin for the Fiji image processing system for thermal image analysis, along with analysis scripts and a continuously evolving applications gallery (city.zcan.eu/apps/) that includes a complete thermal dataset archive with open data formats (GeoTIFF, CSV) for researchers and developers. The system is accessible through modern browsers without registration requirements, while advanced functionalities are supported by comprehensive technical documentation and assistance from the ICISK and IDEAS teams. While the I-CISK project officially concludes in 2025, the Budapest Living Lab represents a foundation for continued research and development. The platform is designed with long-term sustainability in mind, ensuring that the valuable datasets, tools, and methodologies developed during the project remain accessible and continue to evolve. Transition to BEHOLDER Project The Budapest Living Lab development team is committed to extending the project's impact through transition to the BEHOLDER project (beholderproject.com), which will build upon the established infrastructure and methodologies. This continuity ensures that: ● Existing tools and datasets remain accessible and continue to receive updates and maintenance ● New research findings from the BEHOLDER project will be integrated into the platform ● Enhanced capabilities and additional climate services will be developed based on lessons learned from the I-CISK implementation ● International collaboration networks established during I-CISK will be maintained and expanded How the results can be reused ● Budapest Living Lab data can be integrated into third-party GIS supporting existing urban planning workflows ● Open-source architecture can benefit from community contributions and custom tool development ● Citizen science tools can be used to engage public participation in urban heat monitoring 49 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 4.6. Alazani River basin Living Lab (Georgia, LL6) User Manual This User Manual describes the pre-operational service for the Alazani River basin Living Lab and its main functions. It lists the data sources and components available from the landing page and explains basic navigation. It covers Hydro Forecasts, SPI-3 drought maps, and Temperature & Precipitation, including visualization and data export. Hydro Forecast Data and providers. The component consumes SMHI and GLOFAS hydrological ensembles and ERA5/Copernicus products. Where multiple providers are available, the active source can be selected from the dropdown on the right. Forecasts are bias-adjusted and, when applicable, downscaled to local points of interest to increase operational relevance. Time-series view (daily hydrograph). From the landing page, select a basin section and monitoring station using the left panel. The central map confirms the location, while the right panel opens the Hydro Forecasts view. The chart overlays recent observations and the forecast median on a common time axis. Percentile bands (e.g., 5–95%, 10–90%) depict forecast uncertainty. Reference lines such as Above Normal and Extreme High support quick screening and can be toggled on or off via the interactive legend above the plot. Zoom controls are provided both above the chart (fixed windows: 1, 3, 6 months, or full season) and below the chart via a time slider for precise interval selection (Figure 4.6-1). Cumulative-volumes view (seasonal average discharges) Choose Cumulative volumes from the visualization dropdown on the right. This view presents forecast seasonal totals alongside observed values for the current month and variability ranges expressed as box plots derived from the last years for the same period. Daily values for the selected month are listed beneath the chart for direct inspection (Figure 4.6-2). The interactive legend enables or disables percentile bands to control how much statistical variability is displayed. A dropdown menu offers direct download of the current chart as PNG and the underlying data as CSV for reports and bulletins (Figure 4.6-2). 50 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.6-1: Screenshots of the GUI landing page with station list (top left), station position on the map (top and bottom left as zoom in) and dashboard to activate specific graphs with access to station data and the forecasts available (top right and bottom right as zoom in). 51 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.6-2: Screenshots of the hydro forecast component _ average monthly graph. SPI index The SPI index component of the Service, accessible by the left panel, provides drought monitoring and outlook as interrogable maps. Two modes are available: Historical SPI-3, computed from ERA5-Land reanalysis as a long-term reference, and Seasonal SPI-3, derived, among others, from Copernicus seasonal forecasts for forward-looking assessment. Selection between historical and forecast datasets is available from the left panel directly . Each map displays SPI-3 values for the chosen month across the Alazani–Iori region. Colours encode standard SPI classes from drought to wet conditions. Historical maps show the current status relative to the 1980–2010 climatology; seasonal maps show projected anomalies for the selected target month. Updates run monthly through an automated process (Figure 4.6-3). SPI-3 is calculated by fitting a gamma distribution to monthly precipitation in the 1980–2010 reference, adjusting for zero-precipitation probability, and transforming to a standard normal variable (Z-score). Historical SPI uses ERA5 monthly means and hourly data; seasonal SPI uses Copernicus seasonal forecast precipitation. The pipeline builds OGC collections at ~0.1° grid resolution. How to use the map. Choose Historical or Seasonal SPI from the dataset dropdown, then pick the month (and lead, when in seasonal forecast mode). The map supports pan and zoom. 52 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.6-3: SPI-3 index. Upper panel: historical SPI-3 map for the current month (1980–2010 climate reference). Lower panel: forecast SPI-3 map for the selected target month. The time-slice bar at the bottom lets you scroll through the months of the upcoming season. The color scale follows standard SPI classes; the interactive legend allows toggling anomaly ranges. 53 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Temperature and precipitation From the landing page, select Temperature & Precipitation in the left menu, then choose a location from the station list or by clicking the central map. The map returns the value for the nearest grid cell at the provider’s native resolution; for Copernicus seasonal forecasts this is approximately 1° × 1° (dataset: C3S seasonal-original-single-levels), (Figure 4.6-4, top) The upper chart displays monthly mean 2 m air temperature for the next six months. Each month is shown as an ensemble distribution with a marked median and variability bands, so the expected thermal regime and its uncertainty are immediately readable across the season. The lower chart presents monthly total precipitation in millimetres over the same six-month horizon. As above, each month appears as an ensemble distribution with median and variability bands, allowing wet or dry tendencies to be evaluated alongside temperature. (Figure 4.6-4, bottom) An Export dropdown next to the charts lets you download the current view as a PNG image and the underlying data as a CSV table for reporting and further analysis. Provider selection and month stepping follow the same controls used elsewhere in the service. 54 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 4.6-4: Temperature & Precipitation module. Top: landing page with the Temperature & Precipitation selector on the left, interactive map in the center for choosing the location (nearest grid cell at provider resolution), and the chart panel on the right. Bottom: zoomed charts. The upper chart shows monthly mean air temperature at 2 m for the next six months with ensemble variability bands and the median. The lower chart shows monthly total precipitation (mm) over the same temporal horizon, also with variability bands and the median. Both charts support legend toggles and an export dropdown as PNGor CSV-files. 55 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Example use case: Farmer in Kvareli Municipality This farmer scenario is didactic. It illustrates a typical, theory-based use of the Alazani–Iori service by summarising needs and practices identified through the Georgian MAP consultations and interviews. Those activities highlighted agriculture as the main livelihood, a demand for water-availability and drought information to guide allocation and planning, and farmer strategies that combine short-term coping and longer-term adaptation In early spring the farmer opens the Hydro Forecasts view from the landing page, selects a station (e.g. Shakriani #440 as in Figure 4.6-1) and the active provider, then reads the ensemble hydrograph over 1 – 3 months with median and percentile bands. “Above Normal” and “Extreme High” reference lines help to screen for high-flow episodes; zoom controls set the operational window. If the median and spread indicate below-normal flows through May–October, the farmer advances canal cleaning, schedules night irrigation, or shifts planting and harvest dates to reduce exposure during peak demand. Next, the farmer opens the SPI-3 maps (Figure 4.6-3) to verify spatial drought signals for the current and target months in the farm’s sub-basin. A dry classification strengthens the decision to pay for supplemental irrigation where channels are available and to adjust tillage to conserve soil moisture. For the seasonal outlook, the farmer switches to Cumulative volumes and to Temperature & Precipitation. Monthly min/max temperature and total precipitation (Figure 4.6-4) are shown as box plots with medians for the next six months; if hot and dry distributions persist, the farmer locks early harvest windows and defers non-essential plantings. If dryness is recurrent year-on-year, the farmer considers drip irrigation or a small well as longer-term measures, consistent with reported adaptation pathways. Finally, the farmer exports charts as PNG-files and tables as CSV-files from the Export dropdown to attach evidence to cooperative bulletins and input orders. Over autumn and winter, observed versus forecast outcomes are reviewed to refine thresholds and timing — an approach aligned with the LL aim to enrich agrometeorological bulletins with streamflow, temperature, precipitation, and drought indicators. 56 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 4.7. Lesotho Living Lab (LL7) User Manual Introduction The Lesotho Climate Service delivers seasonal drought information to support climate-smart decisions. It uses the Precipitation Drought Index (PDI) to assess the likelihood and severity of drought in upcoming seasons and is intended for farmers, local authorities, and operational planners. There are two deployments of the same service logic: ● Public I-CISK portal (demo): a gentle introduction to the concept, variables, and core interactions investigated in the Living Lab. It offers open, climate-only access for exploration. ● Operational IBF platform: the Impact-Based Forecasting (IBF) environment run with the Lesotho Red Cross. It contains the production pipelines, trigger workflows, and decision products required for day-to-day operations. How this manual is organised. The first part briefly documents the public demonstration interface (landing page, map, season selection, legend). The second part describes the operational features of highest relevance that are implemented in the IBF version. For implementation and maintenance details of the operational setup on IBF, see also the open-source repositories: rodekruis/IBF-system (platform) and rodekruis/IBF-drought-pipeline (drought workflow). Demo on Public I-CISK portal On the public I-CISK portal, the Lesotho Climate Service offers examples of seasonal drought maps and statistics which supports agricultural planning, and enables preparedness for water resources management. From the landing view (Figure 4.7-1), the user may above all choose the season or forecast run to analyze (with the time slider at the bottom of the map) The center map of Lesotho displays the drought signal computed with the Precipitation Drought Index (PDI); colors represent categories from normal to extreme drought. A dataset selector (on the bottom right of the map) lets you pick the variable of interest among available ones; On the left a legend explains classes and thresholds. Furthermore time-series graph on the left allow inspection of statistical variability of forecasted values of the Drought index. On the public I-CISK portal, the Lesotho Climate Service presents seasonal drought maps and basic statistics to support agricultural planning and preparedness. From the landing view (Figure 5) you select the target season or forecast run with the time slider below the map. The central map displays the Precipitation Drought Index (PDI) as the probability that seasonal rainfall falls in the lower tercile of its historical distribution, computed from ECMWF SEAS5 ensembles; colours encode categories from normal to extreme drought and a side legend explains the thresholds. 57 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Graph Navigation and Tool Activation. During a session, the agent moves through the graph according to dynamically defined transition rules. The central node is often an LLM node, which is a module that invokes a language model (e.g., gpt-4o-mini) to interpret the user's request. The model evaluates the context (dialog + state) and decides: ● Whether to return a direct response, ● Whether to trigger a specific tool to perform an action (e.g., generate a notebook), ● Which parameters to pass to the tool, ● Whether further interaction with the user is needed for clarification. Activation of a tool is done through function nodes, which process the input and update the state with the result (e.g., path of the generated file). The graph can then return to the LLM node to communicate the result to the user or continue with other steps. Design advantages: ● Modularity: each step is isolated and independently modifiable. ● Control: the developer can define conditional transitions and loops. ● State persistence: the system keeps track of the conversational context and results generated. ● Extensibility: it is easy to add new tools or routing logic within the graph. Agent Graph Structure The agent graph is organized around a central node called the Chatbot, which is responsible for the overall orchestration of requests and conversational interaction with the user. Several arcs (edges) branch off from the Chatbot node, leading to the activation of various tools (tools) depending on the nature of the request. The management of each tool is encapsulated in a dedicated subgraph, which represents the entire operational flow required to complete the automatic execution of the request. There are three main functional subgraphs: ● Subgraph for retrieving data from CDS ● Subgraph for the calculation of the SPI Index ● Subgraph for generating code within notebooks. 64 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Figure 5.2-2: Sketch of the auto composer functional subgraphs. Each subgraph independently and consistently manages the life cycle of the corresponding tool through a structure designed to include preand post-execution user interaction phases, in line with the human-in-the-loop paradigm. The validation and control logic of this process is documented in detail in the Human-In-The-Loop chapter. Functionalities Agent tools Agent tools are functional components of the LLM agent used to perform specific operations in response to user requests. Each tool is responsible for generating a custom Jupyter Notebook, which interacts with the I-Cisk project's pygeoapi API to access climate data and-if required-perform processing or visualization. Tools are automatically selected by the agent based on the content of the natural language request. Along with tool selection, the agent also extracts from the request the values to be assigned to the input parameters for tool execution, values on which a validity check is then performed and which can then be confirmed or modified before actual execution. 65 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] CDS Historic Notebook Tool Generates a Jupyter Notebook for ingesting historical climate data from CDS datasets. Used CDS datasets are: ● reanalysis-era5-land-monthly-means (monthly averages). ● reanalysis-era5-land (hourly data). Parameter Type Description historic_dataset str None historic_variables list[str] None area str list[float] start_time str None end_time str None zarr_output str None jupyter_notebook str None CDS Forecast Notebook Tool Generates a Jupyter Notebook for ingesting forecast data from CDS datasets. Used CDS datasets are: ● Seasonal-Original-Single-Levels (seasonal temperatures and precipitation). ● CEMS Early Warning Data Store (GloFAS - river discharge forecasting). Parameter Type Description forecast_variables list[str] None area str list[float] init_time str None lead_time str None zarr_output str None jupyter_notebook str None 66 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] SPI Historic Notebook Tool Generates a Jupyter Notebook for calculating the Standardized Precipitation Index (SPI) on historical data. Uses the CDS datasets reanalysis-era5-land-monthly-means and reanalysis-era5-land to obtain precipitation data Parameter Type Description area str list[float] reference_period tuple[int, int] Range of reference years for calculation of SPI. Default: (1981, 2010). start_time str None end_time str None jupyter_notebook str None SPI Forecast Notebook Tool Generates a Jupyter Notebook for calculating Standardized Precipitation Index (SPI) forecast values over a given geographic area. Uses CDS reanalysis-era5-land-monthly-means datasets for historical precipitation reference data and Seasonal-Original-Single-Levels for forecast precipitation data. Parameter Type Description area str list[float] reference_period tuple[int, int] Range of reference years for SPI calculation. Default: (1981, 2010). init_time str None lead_time str None jupyter_notebook str None 67 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Notebook Code Editor Tool This tool allows you to edit an existing Jupyter notebook by adding new code cells to the end of the document. It is intended to be used subsequent to the generation of a notebook via one of the data collection tools (historical or forecast), when the user requires additional operations such as processing, specific analysis, or custom visualizations. The distinguishing feature of this tool is its ability to generate code consistent with the pre-existing content of the notebook: in fact, it exploits the variables, structures and data already defined in the previous sections, ensuring operational and semantic continuity. The generated code is therefore "hangable" and non-invasive, designed to extend the existing workflow without changing its original logic. Parameter Type Description source str Name of the .ipynb file to be modified. Must be given as a simple filename (e.g., notebook-output.ipynb), without a path. The file must be in the database. request str Descriptive text of the desired modification. Indicates the type of processing or visualization to be added (e.g., calculating indicators, creating maps or graphs), so as to guide code generation. Human-In-The-Loop Interaction with the system is mainly based on a conversational mode in natural language, in which the user expresses requests, intentions and possible corrections or approvals through a chat. This approach is maintained not only in the initial request phase, but also in all subsequent phases of management, validation and modification of input parameters and tool-generated outputs. Modeling in the LangGraph graph Since LangGraph adopts a graph architecture of nodes and arcs, the human-in-the-loop model was designed as a series of interactions embedded in the graph itself, connected to the functional nodes responsible for tool activation. Specifically, each tool is managed through an autonomous subgraph, within which the interactive steps with the user are explicitly embedded. Types of interaction provided The system supports several modes of user intervention in the flow: ● Additional inputs explicitly requested by the user. ● Modification of parameters automatically pre-filled by the agent. ● Clarifications by the agent when: ○ the parameters detected are insufficient or invalid; ○ confirmation is needed before running the tool; ○ the output obtained needs validation or improvement. 68 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Tool Parent and Interactive Cycle Management To standardize tool behaviour, an abstract tool (ParentTool) was defined from which all specific tools inherit. This component implements the complete logic of the execution cycle, including the following steps: 1. Checking for the presence of the mandatory parameters: if they are missing, abort and prompt the user. 2. Validation of parameters: format and logical consistency checks. In case of error, a correction is requested. 3. Automatic inference of parameters: use of predefined rules to complete missing inputs. 4. Request for final confirmation of input parameters. 5. Request for approval of output or suggestion of changes to improve the final result. Validation and inference rules are configurable for each individual tool, allowing adaptive and specialized behaviour for each use case, while maintaining a common execution structure. Natural language management Human-computer interaction continues to be expressed in natural language. User requests are dynamically constructed by combining: ● Specific templates for each type of interaction (request, confirmation, modification). ● Text descriptions associated with the tool and the parameters involved. User responses are interpreted by the system through a semantic context that specifies the type of interaction taking place and the expected meaning of the values. Figure 5.2-3: Auto composer User responses interpretation. 69 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Advantages of the approach This modeling simplifies the construction of new tools, since the interaction logic is already encapsulated in the ParentTool. Each new tool only needs to provide: ● the parameter definition, ● the validation/inference rules, ● the possibly customized messages. The result is a consistent, modular and easily extensible system in which natural user interaction is dynamically adapted to the specific context, without having to rewrite the management logic. Limitations and future development The current implementation has a number of physiological limitations, some related to the nature of the LLM-based agent, others to the degree of maturity of the project. Current limitations ● Tool specialization The agent's ability to generalize is limited: to cope with heterogeneous or unanticipated requests, it is often necessary to implement specific, purpose-built tools to handle particular data collection, processing, or visualization flows. This reduces the flexibility of the system and requires ongoing maintenance. ● Lack of native knowledge by the LLM of the I-Cisk API. The LLM lacks structured and up-to-date knowledge of the I-Cisk API. Although the interface to these APIs is kept as generic as possible, the agent is unable to automatically adapt to substantial changes in logic or response formats. This necessitates the introduction of new tools or manual updates when changes occur. ● Quality of code generation Although LLMs have achieved good levels of accuracy in Python code generation, performance decays in the presence of complex data structures, such as multidimensional data cubes. In the absence of sufficiently detailed context, the model may propose code that is incomplete, semantically incorrect, or inconsistent with the user's intent. The output confirmation function specified for the Notebook Code Editor Tool is precisely intended to provide more detail when these situations occur. ● Limited functional coverage The system, at present, supports a limited number of tools and data sources. However, the architecture is designed to be extensible: in the future it will be possible to include additional datasets (e.g., regional models, satellite observations, local area networks), and expand analytical capabilities (e.g., clustering, anomaly detection, complex indicators). 70 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Future developments ● Modular expansion of tools Progressive introduction of new tools, each specialized for a particular data type, processing, or geographic domain. New tools will inherit the interactive logic already in place, ensuring consistency in the user experience. ● Dynamic context driven To improve the accuracy of code generation, a dynamic context construction engine is expected to be introduced, providing the model with detailed information on: structure of available data, semantics of variables, units of measurement and validity constraints. This will improve consistency between user requests and product code. ● Integration of an automatic validation engine. Preventive verification of generated code by controlled execution and detection of errors or warnings, with automatic suggestions for correction or request for clarification to the user. ● Internal execution of generated notebooks In the future, it could be possible to execute Jupyter notebooks directly within the webapp, in an isolated and controlled environment. This will allow the user to immediately verify the result of the code produced by the agent. Integrated with the Notebook Code Editor Tool, this mechanism will strengthen human-in-the-loop interaction at the output confirmation stage, allowing for real-time changes and adjustments, and making the system more useful and effective in complex data processing. 71 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 5.3 User Manual Introduction This manual provides step-by-step instructions to guide users through accessing and using the application effectively. It is structured into clear sections: starting with Login instructions, followed by a detailed overview of the main interface, and finally practical usage examples to help users get started quickly. Login Page The login page is the entry point to the I-CISK AI Agent Climate Service Composer. From here, users can securely access the application by providing their User ID. This step ensures that only authorized users can interact with the system and access the climate data services. The login interface is designed to be minimal and straightforward, containing a single field for the User ID and a button to proceed. Login Follow the steps below to log into the application: 1. Locate the User ID field: In the center of the page, you will see a text box labeled "User ID". 2. Enter your User ID: ○ Type the unique User ID that has been provided to you by the system administrator or project team. ○ The correct format of the User ID will typically be: usr-*<some-alphanumeric-code>* 3. Click on the Login button: Once you have entered your User ID, press the Login button to proceed. 4. Successful login: ○ If the credentials are correct, you will be redirected to the Main Interface of the application. ○ If the login fails, verify that you have typed the User ID correctly. If the issue persists, refer to section “Requesting a key” for assistance. Note: The system does not use traditional passwords. The User ID itself serves as the secure access key for authentication. Requesting a User Key If you do not yet have a User ID or have lost your existing one, you must request access from the project team. 1. On the login page, click the "contact us" link displayed below the User ID input field. 2. This will redirect you to a contact form where you can submit your request. Once your request has been approved, you will receive a valid User ID via email or through another secure communication channel. You can then return to the login page and access the system following the steps in “Login” section. 72 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Main Interface Overview After logging in, you are taken to the main interface, which is divided into two key areas: ● Chat Section (central area): The main space where you interact with the AI agent through a chat-like interface. Here, you can send requests, view responses, and access generated outputs such as Python notebooks or data visualizations. ● Sidebar (left panel): A control panel to manage your sessions and outputs. It includes quick actions (e.g., starting a new chat), a file manager for generated notebooks, and a documentation link for reference. Figure 5.3-1: Screenshot of the Auto composer control panel layout. This layout provides a clear workflow: interact with the agent in the central area while managing files and tools through the sidebar. Example prompts At the top of the chat section, four example prompts are available to guide the user. They are divided into two groups, based on the type of task performed by the agent. 1. SPI Calculation Tool — Calculation of the SPI index on historical or forecast data. 2. Seasonal Forecast Retrieval Tool — Retrieval of forecast data for precipitation and temperature. 3. GloFAS River Discharge Retrieval Tool — Retrieval of river flow data. 4. Code Generation Tool — Generation of code for customized analyses or visualizations, including on notebooks uploaded by the user. Figure 5.3-2: Auto composer Generation of code example. 73 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Notebook Execution Notebooks generated by the agent cannot be executed directly inside the application. To run and work with them, you must: 1. Download the notebook from the File Manager. 2. Execute it in a local Python environment or use a cloud-based service like Google Colab. 3. If needed, re-upload the updated notebook to the app for further enhancement by the agent. Other Considerations ● Tool interrupts must be resolved sequentially: you cannot switch tools or issue unrelated commands until the current clarification process is complete. ● The proof-of-concept nature of the app means occasional bugs or unexpected behaviour may occur, especially when using complex or ambiguous requests. By keeping these limitations in mind, users can better manage their sessions, avoid losing work, and ensure they are making the most of the available features. 80 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 6. Summary The co-developed Climate Services (CSs) within I-CISK address the information needs of diverse stakeholder groups. Data that traditionally required technical expertise to access and interpret has been released from silos and meaningfully combined within the platform. Through the automation of analysis, downscaling, and the integration of local data and knowledge, the CS platform ensures that no advanced modelling expertise is required to align the information with the users’ scope of action. As a result, the co-developed CSs enhance the information available to stakeholders, facilitating better informed decision-making processes. The CSs are currently developed as pre-operational prototypes, and further refinements will be necessary before large-scale production adoption. Future improvements include the integration of additional datasets and longer time series, enhanced performance and stability, and targeted user interface customizations (e.g., optimized colour schemes). A key innovation supporting this process is the AUTO Climate Service Composer/Toolbox, which provides an LLM-based interactive environment for composing and deploying customized CSs. By enabling users to request data collection, processing, and visualization in natural language, the AUTO Composer lowers technical barriers and supports transparent, human-in-the-loop workflows. This novel functionality not only streamlines the co-development of CSs but also ensures their adaptability to evolving user needs. The development of the CS platform has utilised a component concept with modular building blocks in order to individually adapt the application to the user needs. The services are in its majority centrally hosted utilising shared resources to maximize efficiency. The deployment utilizes GitHub actions and predefined build pipelines supporting the rapid and iterative development sprints with a strong user engagement. The modular design will allow re-use of tailored solutions beyond the I-CISK project without the need to deploy and maintain the entire CS platform. Overall, a common insight gained through the co-development process is that anchoring forecasts in historical data and past events, and relating them to similar anticipated situations, enhances the understanding of climate risks and their impacts. This approach fosters more meaningful engagement with the consequences of a changing climate and strengthens the capacity of stakeholders to plan and respond effectively. 81 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 7. Challenges and Solutions The implementation of the I-CISK platform across diverse Living Labs has provided valuable lessons on the complexities of co-designing climate services. Throughout the development phases, several recurring practical and technical challenges emerged, together with effective solutions adopted by the consortium to ensure successful outcomes. For completeness, the list of challenges and solutions is adopted from previous deliverables and merely refined and expanded here. ● CHALLENGE: Discussion with LL hosts and stakeholders are very valuable but need time. This amount of time has been underestimated in the project design. SOLUTION: Implementation of CSTF boosting productivity. (Later) adapt the focus based on needs of the LL to provide the most valuable and exploitable CS, which might slightly deviate from what has been envisioned in the proposal phase. ● CHALLENGE: Availability of external data sources was throughout the project of varying quality (access and data quality wise). SOLUTION: incorporate data quality checks and (temporarily) store data in the own infrastructure opposed to purely access it through public APIs ● CHALLENGE: delay of provision of (local) data SOLUTION: using synthetic data, but this requires additional work when (i) discussing results with users explaining the source/nature of the data and (ii) replacing the synthetic data with real data when it becomes available. ● CHALLENGE: Keeping track of details and mid/long-term decisions and discussions with many people in different constellations. SOLUTION: We found that a shared online office document (in our case google slides) was a good medium for keeping track of the current state as well as a place for discussions because it allows for text and images to be shared along with a commentary function. ● CHALLENGE: While the project and resources come to an end, each LL still has several new ideas and sees refinement opportunities. While this underpins the engagement in the co-design, it also poses a challenge. SOLUTION: Over the period starting PM 37, this limitation has been made clear by WP5 and the CSTF have jointly (re)prioritised features and refinements of the CS. Further ideas and requests are kept in a back-log of the respective repositories and could directly be addressed in desired further development. 82 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 8. Conclusion and Future Work The I-CISK project has successfully designed, developed, and deployed a robust, scalable, and modular climate service platform that delivers actionable climate insights to a diverse set of stakeholders across multiple regions and Living Labs. A key achievement has been the seamless integration of heterogeneous datasets—ranging from global sources such as Copernicus ERA5 and GLOFAS, to regional forecasts provided by SMHI, and detailed local monitoring data collected from regional authorities and institutions. The platform is built on a cloud-based architecture hosted on the Open Telekom Cloud, leveraging containerization and orchestration tools such as Docker and Kubernetes. This infrastructure ensures reliable performance at scale, while providing flexibility and efficiency in handling large and diverse climate datasets. At the core of this technical ecosystem lies a modular back-end framework. The Climate Data Ingestor Docker automates the retrieval, preprocessing, and standardization of datasets, ensuring consistent and reliable data flows. This is coupled with centralized S3-compatible cloud storage for optimized data handling, and the Pygeoapi backend service, which provides OGC-compliant APIs for standardized access and processing. Together, these components form a powerful and reusable architecture that can be transferred and scaled well beyond the scope of the current project. A major innovation of I-CISK is the development of the AUTO Climate Service Composer/Toolbox. This interactive, LLM-powered application democratizes climate service creation by enabling users to request data collection, processing, and visualization through natural language interaction within a user-friendly Streamlit interface. By generating and refining reproducible Jupyter-based workflows in a human-in-the-loop fashion, the AUTO Composer significantly lowers technical barriers and supports the participatory co-creation of tailored climate services. Alongside these back-end and middleware components, strong emphasis has been placed on stakeholder-driven front-end solutions. Through iterative co-design with the Living Labs, intuitive graphical interfaces have been developed to accommodate users with different technical backgrounds. Advanced visualization libraries such as ReactJS, OpenLayers, Highcharts, Leaflet, and Plotly enhance interpretability and accessibility of complex climate forecasts. Multilingual support, comprehensive documentation, and systematic testing have further reinforced user-friendliness and inclusiveness. Each Living Lab deployment showcases the adaptability and modularity of the I-CISK platform, with tailored solutions aligned to specific local contexts and user needs. These customizations confirm the system’s readiness for further regional and thematic scalability. Exploitation pathways and sustainability strategies are outlined in complementary WP5 deliverables, providing clear guidance for the lasting adoption, expansion, and impact of the innovations achieved by the I-CISK project. 83 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] 9. Appendices 9.1 Acronyms API – Application Programming Interface CDD – Cooling Degree Days CDS – Climate Data Store CDSE – Copernicus Data Space Environment CIS – Climate Information Services CNN – Convolutional Neural Network CSTF – Climate Service Task Forces DBS – Distribution-Based Scaling DJF – December, January, February ENS – Ensemble ERA5 – ECMWF Reanalysis version 5 ESGF – Earth System Grid Federation FTP – File Transfer Protocol GEOSS – Global Earth Observation System of Systems GLOFAS – Global Flood Awareness System GUI – Graphical User Interface IBF – Impact-Based Forecasting I-CISK – Innovative Climate Information Services for Knowledge IDW – Inverse Distance Weighting JSON – JavaScript Object Notation LL – Living Lab MAE – Mean Absolute Error MidAS – MultI-scale bias AdjuStment NetCDF – Network Common Data Form OGC – Open Geospatial Consortium OTC – Open Telekom Cloud POI – Point of Interest RMSE – Root Mean Squared Error S3 – Simple Storage Service SMHI – Swedish Meteorological and Hydrological Institute SPI – Standard Precipitation Index SPI-3 – Standardized Precipitation Index (3-month interval) STAC – SpatioTemporal Asset Catalog TCI – Tourism Climatic Index UHI – Urban Heat Island WP – Work Package ZARR – Format for chunked, compressed, N-dimensional arrays 84 [D5.4 - I-CISK Platform Final Technical Specification and Platform Manual] Colophon: This report has been prepared by the H2020 Research Project “Innovating Climate services through Integrating Scientific and local Knowledge (I-CISK)”. This research project is a part of the European Union’s Horizon 2020 Framework Programme call, “Building a low-carbon, climate resilient future: Research and innovation in support of the European Green Deal (H2020-LC-GD-2020)”, and has been developed in response to the call topic “Developing end-user products and services for all stakeholders and citizens supporting climate adaptation and mitigation (LC-GD-9-2-2020)”. This project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 101037293. This four-year project started November 1st, 2021, and is coordinated by IHE Delft Institute for Water Education. For additional information, please contact: Micha Werner (m.[email protected]g) or visit the project website at www.icisk.eu 85