Water Quality Forecasting and Mapping in Rivers and Creeks: A Distributed AI-Integrated

IoT Framework Approach.

A Thesis by

Exequiel M. Sabater
Bachelor in Science in Computer Engineering

Submitted to the Graduate Programs

Technological Institute of the Philippines – Quezon CIty

In Partial Fulfillment
of the Requirements for the Degree
Masters in Engineering Major in Computer Engineering

<Month and year of degree conferral, not date of submission>

 ii

APPROVAL SHEET

This <thesis/research project/dissertation> entitled <Title>, prepared and submitted by <Name>, in

partial fulfillment of the requirements for the degree <Degree> is hereby accepted.

<Adviser>
Research Paper Adviser

<Dean>
Chair, Defense Panel

<Panelist 1> <Panelist 2>

Panel Member Panel Member

Accepted and approved for the conferral of the degree <Degree>.

Ruji P. Medina, Ph.D.

Dean, Graduate Programs
 iii

DEDICATION

This portion is optional but perhaps you have someone or some people who have inspired

you to push on with your studies? A dedication would be a fitting way to acknowledge their impact

on your success.
 iv

ACKNOWLEDGMENTS

The road to this point in your studies couldn’t have been travelled alone. Along the way,

someone somewhere helped you. This is your chance to thank them.

By the way, exercise the liberty to be personal to reflect the sincerity of your gratitude…
 v

Table of Contents

APPROVAL SHEET...........................................................................................................................ii

DEDICATION.................................................................................................................................... iii

ACKNOWLEDGMENTS................................................................................................................... iv

TABLE OF CONTENTS.....................................................................................................................v

LIST OF TABLES............................................................................................................................ viii

LIST OF FIGURES........................................................................................................................... ix

ABSTRACT........................................................................................................................................x

1 INTRODUCTION....................................................................................................................... 1

1.1 Background of the Study.................................................................................................1

1.2 Objectives of the Study....................................................................................................1

1.3 Significance of the Study.................................................................................................2

1.4 Scope and Delimitations..................................................................................................2

2 THEORETICAL FRAMEWORK.................................................................................................3

2.1 Review of Related Literature...........................................................................................3

2.2 Concept of the Study.......................................................................................................3

2.3 Definition of Terms.......................................................................................................... 4

3 OPERATIONAL FRAMEWORK.................................................................................................5

3.1 Materials..........................................................................................................................5

3.1.1 Software...........................................................................................................5

3.1.2 Hardware......................................................................................................... 5
 vi

3.1.3 Data................................................................................................................. 5

3.2 Methods...........................................................................................................................5

3.2.1 Experimental design........................................................................................5

3.2.2 Procedures for the different phases.................................................................5

3.2.3 Evaluation........................................................................................................ 6

4 RESULTS AND DISCUSSION..................................................................................................7

4.1 Results by phase of study...............................................................................................7

4.2 Verification studies.......................................................................................................... 7

5 SUMMARY, CONCLUSIONS, AND RECOMMENDATIONS....................................................8

5.1 Summary......................................................................................................................... 8

5.2 Conclusions.....................................................................................................................8

5.3 Recommendations...........................................................................................................8

REFERENCES.................................................................................................................................. 9

APPENDICES................................................................................................................................. 10

CURRICULUM VITAE.....................................................................................................................11
 vii

LIST OF TABLES

Insert the List of Tables using the “References” tab > “Insert Table of Figures” > Table
 viii

LIST OF FIGURES

Insert the List of Tables using the “References” tab > “Insert Table of Figures” > Figures
 ix

ABSTRACT

Insert your abstract here. This portion is not to be indented and should be clear, concise, and

complete. As much as possible, limit the introductory part to a few sentences and make sure that

the last sentence reiterates the achievement of the general objective of the research.
 1

1 INTRODUCTION

1.1 Background of the Study

Keeping freshwater safe is a major priority for cities and farms, especially since climate

change is making water resources more unstable. In this study, the Researcher is following the UN

Sustainable Development Goal 6 in order to find better ways to monitor our water. Right now, most

of our monitoring is reactive because we still rely on manual sampling and testing. These old

methods are expensive and take too much time, which means we often miss sudden spikes in

pollution. Because of that, it is hard for the government to take quick action.

IoT is changing how we do things since we can now use cheap sensors to track pH or

oxygen levels in real-time. These sensors provide constant data, but the data is often messy, so

we need machine learning like LSTM to find errors and trends. Even with these tools, the

Researcher found two big issues. First, many models are "black boxes" that do not explain how

they reach a conclusion. Managers need to know the reasons behind a warning so they can trust

the system. Second, sending all that data to the cloud uses too much power and is too slow for

remote areas with poor signals.

The Researcher is using edge computing to fix these problems. TinyML models can detect

issues in less than a second and they save a lot of battery because they work without the internet.

Also, these models need to stay small and easy to understand while keeping all sensors synced

up. To fill these gaps, the Researcher created an AI framework for real-time water monitoring.

Basically, the design puts TinyML at the sensor level for fast detection and uses the cloud for

forecasting and XAI.

 2

The Researcher is currently developing a distributed AI system to address the current gaps

in real-time water quality monitoring. In this case, The Researcher is implementing an edge-cloud

co-design that runs TinyML directly on sensor nodes in order to detect anomalies with minimal

delay. This setup then links to a cloud layer where the system processes spatiotemporal

forecasting and XAI tasks, which means the heavy lifting happens where there is more computing

power.

At the cloud level, The Researcher is utilizing feature attributions and counterfactuals so

the AI outputs are transformed into logical evidence that users can easily check. Also, The

Researcher is integrating GIS mapping to convert these sensor readings into basin-wide data

because that makes it easier for teams to do field inspections and quick triage. The Researcher

wants to solve the problem of model accuracy not always leading to organizational trust. By mixing

these edge alerts with cloud-based explanations, the framework allows government agencies to

start practicing predictive governance since they can now predict pollution trends using clear

evidence. Because of that, this study provides a TinyML pipeline for low-power sensors and an XAI

toolkit that uses the specific language of field experts. Basically, The Researcher is converting raw

data into the type of solid information that managers can use for their day-to-day decisions.

Objectives of the Study

The general objectives of this research project on Explainable AI (XAI) and TinyML for

Water Quality Forecasting and Mapping in Rivers and Creeks A Distributed AI Integrated IoT
 3

Framework Approach are to deliver a high-performance, dependable, and operationally practical

monitoring framework.

The specific objectives follow:

a. To design and develop an IoT-based Prototype that can monitor the water quality of the creek

and river with edge computing for anomaly detection.

b. To design and develop a Cloud-Based LSTM neural network for multi-step WQI forecasting, and

a Map tracking node for monitoring the status of the location where the prototype is deployed with

Explainable AI (XAI) for providing causal explanations.

c. Evaluate the system performance for monitoring activities and standard according to the DENR

Administrative Order No. 2016-08 by measuring its accuracy, precision, recall, and F1-score to

determine its reliability and consistency.

d. To determine the system’s performance accuracy for water quality monitoring and in-site manual

testing to achieve at least 85% of reliability, effective for water quality monitoring.

The main purpose of the research is to design and develop a complex, dependable

technological prototype that addresses the critical challenges faced regarding in water

management monitoring. With advance combination of general objectives: to deploy a high

performance with real-time water quality monitoring system that leverages TinyML and Edge

computing for immediate, on-site anomaly detection, to integrate an Explainable AI that converts

the model output into a transparent and clarifying basis for every notification or alerts to hardly

justify decision supports, to support justifiable decisions and actionable action and actionable

evidence insights to the client or the end-user. This study signifies the substantial improvement in
 4

public awareness through rapid and dangerous mitigation and fosters accountability and regulatory

compliance by making understandable decisions from AI, the governance transition from reactive

turns to proactive alignment to sustainable water quality management.

Scope and Delimitations

The Researcher is designing and validating a prototype that uses TinyML and XAI in order

to build a decision support system for real-time water quality monitoring. This system is meant to

detect rapid fluctuations in rivers and urban creeks. The Researcher is handling everything from

site selection to installing low-cost IoT sensors, which means data can be gathered and processed

right on the device using edge inference. This is useful for on-the-spot screening before the system

sends data to the cloud during specific events. Because of that, the system can generate GIS-

based visualizations and explanations that humans can actually understand for notifications and

alerts. Also, there are some limits to this study. The Researcher is not making custom sensors

since the project uses low-cost, commercial probes instead. This choice means the TinyML models

are restricted by the memory and power budgets of the microcontrollers we use. In this case, the

XAI part is limited to post-hoc methods like SHAP or LIME that are applied to the models after they

are deployed. The Researcher is also limiting the scope to specific river and creek segments in

Legazpi during the actual time of data collection, so the results do not apply to other places like

coastal waters or different seasons. So, while the system provides alerts to help with decisions, it

does not include any automated controls for the water infrastructure itself.
 5

THEORETICAL FRAMEWORK

1.2 Review of Related Literature

Yadav, H. L., et al. (2025). Integrating edge computing and IoT for real-time air and water

quality monitoring systems. this study by using a Distributed AI architecture to improve real-time

performance. This shift toward edge computing is helpful because it lessens the dependence on

the cloud, which is why the researcher uses it as a foundation for the system. Even so, the

researcher goes further by adding an Explainable AI (XAI) Engine to provide clear and causal
 6

explanations for the model's outputs. Because the researcher uses SHAP and LIME, the system

can solve the "black box" problem that often makes users doubt AI results. Also, the researcher

enforces a 1MB RAM limit for TinyML models in order to ensure the devices can handle ultra-low-

latency detection while saving power. This is necessary because the system will be deployed in

remote river areas where power efficiency is a major concern. Basically, the researcher is building

on the edge computing idea but adding the specific technical depth needed for actual

environmental management.

Shahra, E. Q., et al. (2024). Intelligent edge-cloud framework for water quality monitoring in

water distribution system. utilized an edge-cloud framework with a similar structural logic to this

study, but their research focuses on a very different setting. While they monitored man-made pipe

networks in Water Distribution Systems, The Researcher is observing the unpredictable and

shifting conditions found in the rivers and creeks of Legazpi City. Also, their setup does not include

an Explainable AI (XAI) layer in the Intelligent Decision Support System. The Researcher is

integrating XAI in order to change standard forecasts into actionable alerts that describe the actual

reasons behind the data, which means the system provides a specific type of transparency that is

usually not found in previous works.

Mohamed et al. (2023) discussed a general and efficient IoT system for water quality

monitoring, but it does not follow the distributed architecture that The Researcher is building for this

project. In this case, The Researcher is using a TinyML-optimized Edge Layer to handle data

processing locally since this allows for immediate event detection while also lowering power

consumption and communication lag. This strategy is different from the usual cloud-centered

models found in earlier research because it prioritizes efficiency at the local level. Also, the cited

study fails to resolve the trust deficit problem that often comes with automated systems. Because
 7

of that, The Researcher is adding an XAI Engine to provide transparent and evidence-backed

insights, which serves as the main novelty intended to improve decision support within the IDSS.

"An efficient IoT based smart water quality monitoring system," is valuable to this research

primarily because it establishes the baseline for current, functional smart monitoring systems,

providing a reference point for efficiency and implementation goals for the own framework.

Specifically, it confirms the foundational necessity of integrating IoT sensor technology with

machine learning for smart water quality monitoring, a core tenet of this project. However, the true

utility of this reference is in highlighting the gaps of this research is designed to bridge: by

presenting a generic system, it implicitly validates the need for a more specialized architecture that

overcomes the limitations of traditional models. This allows specifically argue that a unique

TinyML-optimized Edge Layer is necessary to surpass the power consumption and latency issues

of generic systems, and that the integration of the Explainable AI (XAI) Engine is essential to solve

the trust deficit—a problem generic "smart" systems typically ignore.

Arepalli, P. G., & Naik, K. J. (2024). show that optimized LSTM networks work well for

high-accuracy forecasting, but their work is mostly focused on early hypoxia detection and the

internal structure of the model itself. In this case, The Researcher is developing a more holistic and

trustworthy decision support system that covers general water quality forecasting and risk

mapping. This project is different because The Researcher is integrating a separate, post-hoc

Explainable AI (XAI) Engine into the cloud using techniques like SHAP or LIME. This XAI layer is

included in order to provide the transparency needed to interpret complex predictions and generate

contextual alerts. Since these features are not in the original study, The Researcher is providing a

way for water managers to make strategic interventions with more confidence. Also, by moving

these processes to the cloud, the system becomes more accessible for real-time monitoring.
 8

The Researcher found that LSTM Neural Networks are the most suitable choice for high-

accuracy time-series forecasting in aquatic environments, which means this specific approach

helps in building the Cloud Platform’s forecasting engine. Also, since the literature suggests using

lightweight and optimized networks, The Researcher is prioritizing resource-constrained models in

order to make the system more efficient. In this case, the study establishes a benchmark for both

predictive performance and architectural efficiency, especially because the system needs to

process complex time-series data for multi-step water quality forecasting.

Rane, V. (2024). Review of smart water management: IoT and AI in water and wastewater

treatment. provides a summary of IoT and AI trends in water treatment, but it does not offer a

primary research contribution since it is a review paper. This is the main difference from this study

because The Researcher is following an Applied Technology Development Research Design to

create something new. The review identifies gaps like the heavy use of centralized systems and

the lack of transparency in AI, which is exactly what The Researcher wants to address. So, instead

of just looking at the literature, The Researcher is developing a Distributed AI Framework that

pushes models to the Edge or Fog computing layer and uses an XAI Engine in order to make the

system more functional and easier to understand..

Tijani, K., & Balah, F. (2025). Integration of AI and GIS in clean water quality monitoring in

urban and rural communities. focus on AI and GIS for visualization, which is a goal that The

Researcher is also pursuing in this project. But their research does not actually tackle the technical

gaps that The Researcher is trying to fill. Basically, their approach is different because it lacks the

TinyML and Edge Layer components that are necessary for low-latency and real-time anomaly

detection. Also, their model does not have an XAI Engine, which means it cannot provide the

transparent reasoning that The Researcher is including in order to make the IDSS more
 9

dependable for its users. Because of that, their work does not quite reach the level of proactive

intervention that is required for this thesis.

Ooko, S. O., et al. (2023). Use of machine learning for realtime water quality prediction.

because they used machine learning to monitor water quality in real-time. In their paper, they used

a TinyML/Edge Processing Layer to process data right at the sensor level and reduce the

dependency on the cloud. However, their system is still centralized, which results in high latency

issues. This is exactly what The Researcher wants to address in this thesis. Also, their model

works like a "black-box" since it lacks the XAI components that The Researcher is integrating.

Because of that, their version doesn't provide the interpretability that local government units or

decision-makers need so they can trust the data for their policies.

Al-Janabi, M. S., & Al-Ameri, B. M. (2024). Machine learning models of the geospatial

distribution of groundwater quality: A systematic review. As a systematic review, is quite different

from the Applied Technology Development Research Design because it does not involve building,

implementing, or testing a new system. This study focuses on groundwater quality, which means it

looks at hydrogeological dynamics that are separate from the study of Rivers and Creeks. Also,

while the review confirms that combining ML with geospatial analysis is effective, it does not

suggest an architectural solution for current problems. In this case, the authors point out that AI

adoption is necessary, but they leave out a framework that handles latency issues using TinyML

and the lack of trust in predictive models through XAI.

Sahu, R. R., et al. (2023). Prediction of water quality parameters by IoT and machine

learning. which focused on using standard IoT and machine learning for water quality prediction. In

this case, The Researcher is going beyond simple data monitoring to create a system designed for
 10

intelligence-driven governance. The Researcher is using a Distributed AI Framework that includes

a TinyML layer to manage low-latency anomaly detection, which means the system can identify

issues much faster than the model Sahu described. Also, the previous work lacked an XAI Engine

to explain how it came up with its results. Because of that, The Researcher is including XAI in the

framework in order to handle the "black box" issue, since environmental managers need to

understand the reasoning behind the data before they can trust the system for their actual daily

tasks.. For tables, use the following format:

Table 2-1. Comparison to Related Literature

Research Title & Key Technology Similarities (The Gap Bridge

Ref.
Author(s) & Finding Foundation) (Novelty)

Novelty: Lacks the

Edge Computing Architecture:
Explainable AI (XAI)
Integrating edge & IoT: Focuses Validates the core
Engine for
computing and on using edge architectural choice
transparent decision
IoT for real-time processing for of a Distributed
support and does not
[1] air and water real-time AI/Edge
define the TinyML
quality monitoring monitoring to Computing model
memory constraint
systems. (Yadav improve efficiency for real-time
(e.g., 1MB RAM)
et al., 2025) and reduce environmental
necessary for ultra-
centralization monitoring
efficient deployment

Application:
Focuses on Water
Edge-Cloud Architecture:
Intelligent edge- Distribution
Framework: Explicitly supports
cloud framework Systems (pipe
Designs a the foundational
for water quality networks), whereas
[2] & distributed concept of an
monitoring in the study targets the
[3] intelligent system intelligent edge-
water distribution more complex
specifically using cloud framework
system. (Shahra environmental
an edge-cloud [which is the study's
et al., 2024) dynamics of Rivers
model core setup
and Creeks (natural
fluvial ecosystems
 11

Research Title & Key Technology Similarities (The Gap Bridge

Ref.
Author(s) & Finding Foundation) (Novelty)

Intelligence &
Architecture: Lacks
An efficient IoT Goal: Shares the
IoT & Efficiency: the explicit TinyML
based smart overall objective of
Aims to create a optimization at the
water quality developing an
general smart, edge and, most
[4] monitoring "efficient" and
efficient IoT importantly, the XAI
system. "smart" monitoring
system for water component for
(Mohamed et al., system using IoT
quality human-
2023) sensors
understandable,
transparent alerts

A deep learning- LSTM &

Holistic Design:
enabled IoT Lightweight AI Sophistication:
Focuses narrowly on
framework for Optimization: Validates the use of
hypoxia detection
early hypoxia Uses a high-accuracy
and specific model
detection in aqua sophisticated LSTM Neural
architecture but
[5] water using light LSTM deep Networks for multi-
does not integrate
weight spatially learning model step forecasting and
XAI to provide
shared attention- for forecasting the principle of
contextual, trusted
LSTM network. and applies "light optimizing models
explanations for
(Arepalli & Naik, weight" for the edge
managers
2024) optimization

System
AI & GIS:
Integration of AI Intelligence:
Advocates for Output: Directly
and GIS in clean Focuses on
combining validates the goal of
water quality integration, but does
predictive AI with integrating AI
monitoring in not address the
[7] Geospatial predictions with
urban and rural transparency
Information GIS to display
communities. problem with XAI or
Systems for results as a color-
(Tijani & Balah, the operational
better coded risk map
2025) efficiency problem
visualization
with TinyML

[8] & Use of machine ML & Real-time Methodology: Trust &

[10] learning for Prediction: Establishes the Architecture: These
realtime water Confirms the core, current are often centralized,
quality prediction. utility of standard practice of using ML "black-box" systems
(Ooko et al., ML for WQ and IoT for water that completely lack
 12

Research Title & Key Technology Similarities (The Gap Bridge

Ref.
Author(s) & Finding Foundation) (Novelty)

2023) [cite: 126,

127]and
Prediction of the XAI Engine to
water quality ensure decision-
forecasting quality prediction
parameters by maker trust and
IoT and machine actionability
learning. (Sahu et
al., 2023)

1.3 Concept of the Study

In Figure 2.1, The Researcher presents the Distributed AI Integrated IoT Framework,

which is designed to move water quality management from a reactive state toward a more

proactive, evidence-based form of governance. The Researcher uses this framework because it

directly addresses operational inefficiency and AI opacity, which are problems that usually make it

hard for stakeholders to trust automated decisions. This work begins at the Input Layer where The

Researcher uses IoT sensors to pull real-time physicochemical data from various rivers and creeks

in Legazpi City. Since these sensors give us geo-referenced time series, The Researcher can build

a reliable dataset for all the forecasting and analytics that will happen later in the workflow. This

dataset includes the raw measurements and the metadata like the location and timestamp;

basically, The Researcher is ensuring that all data is complete and has context before the study

moves to the next phase.

This Research designs the Process Layer to spread out intelligence in order to improve the

speed and reliability of the whole system. At the edge level, the Researcher uses TinyML models

specifically made for microcontrollers to handle anomaly detection right at the sensing node. This
 13

allows for instant alerts without using too much power or overloading the network. In this case, the

cloud also collects the same data so the Researcher can carry out more complex analysis. The

Researcher uses LSTM networks to create multi-step forecasts and combine information from

different locations and time periods. Also, the Researcher integrates an Explainable AI engine

using SHAP or LIME to interpret the forecasts and anomaly scores. The Researcher identifies the

specific variables and timeframes that affect the prediction, which explains why an alert was sent.

Because of that, the Researcher can fix the trust issues that people usually have with black box

models.

The Researcher uses the Output Layer to turn all those raw calculations into intelligence

that is ready for actual decision-making. Basically, the Intelligent Decision Support System gives

out alerts that explain the logic behind a result, which is why it might show that pollution is likely

happening because of low water flow or high temperatures. The Researcher also maps these

findings on a GIS dashboard with color codes so that users can see exactly where and why these

risks are appearing in specific river and creek segments. Because the system does fast screening

at the edge and uses XAI for clear forecasting in the cloud, it helps local authorities take action

right away. In this case, The Researcher focuses on a setup that allows for proactive governance

to stop the water from getting worse instead of just keeping a record of the damage after it already

happened.
 14

Figure 2.1: Conceptual Paradigm

1.4 Definition of Terms

Here are the key technical and conceptual terms defined specifically within the context of

this study.

Distributed AI-Integrated building the system architecture with a two-tiered setup because it allows the intelligence to

IoT Framework be divided between the edge and the cloud. In this design, the Researcher uses efficient

IoT Edge Nodes to handle instant detection, which means the system can respond
 15

immediately since the processing happens locally. Also, the Researcher sends the heavier

data to a centralized Cloud Platform in order to manage complex forecasting and decision

support. Basically, the Researcher is splitting the workload so the system can be both fast

and capable of deep analysis.

TinyML The Researcher views TinyML as a specific branch of Machine Learning where models are

heavily optimized to run on microcontrollers that have very limited memory and power. This

means the Researcher is working with models that fit into less than 1MB of RAM because

the hardware is so resource-constrained. In this project, the Researcher uses TinyML at the

Edge Layer in order to handle high-speed and localized classification. This setup allows for

initial alerting to happen directly on the device, which means the system does not have to

rely on a distant server for basic detection

Edge Layer / Edge Node the physical layer of the framework using low-cost IoT devices that are equipped with

sensors and microcontrollers. In this case, the Researcher runs local data processing and

inference through TinyML models in order to allow for ultra-low-latency anomaly detection.

This is important because the Researcher wants the system to work without needing

constant cloud connectivity, which means the processing happens right on the device.

Cloud Platform the centralized backend component of the framework to run complex deep learning models

like LSTMs in order to perform accurate and multi-step water quality forecasting. This is

where the Researcher generates 48-hour predictions because the processing power is

much higher here than at the edge. Also, the Researcher hosts the XAI Engine and the

final Intelligent Decision Support System (IDSS) in this layer, which means the system can

provide both clear explanations and actual guidance for the users.

Explainable AI (XAI) The main part of the study is that it uses techniques like SHAP or LIME to understand how

Engine the models work. The researcher looks at the decisions made by complex black-box

models, such as LSTMs, on the Cloud Platform. This investigation provides clear and

understandable causal explanations for each prediction. The researcher emphasizes this
 16

approach because it clarifies the system's reasoning. As a result, people can trust the

findings more and use them for real decision-making.

Intelligent Decision The final user-facing system on the Cloud Platform serves as the main hub for the project.

Support System (IDSS) In this setup, the Researcher combines the raw LSTM predictions with the XAI-generated

explanations to provide contextual alerts. For example, it warns users that dissolved

oxygen will drop due to temperature spikes and low flow. This makes the data much more

useful for users. Essentially, the Researcher is helping environmental managers make

informed and timely decisions by giving them both the forecast and the reasoning behind it.

Water Quality Using Deep Learning models like LSTM Neural Networks on both historical and real-time

Forecasting sensor data helps predict future values of important water parameters. In this case, the

researcher tracks variables like pH, DO, and turbidity, as these are vital for understanding

water quality trends. The researcher aims to forecast several time steps ahead, such as 24

to 48 hours. This allows the system to provide sufficient lead time for proactive

management. This method helps the researcher anticipate changes before they occur.

Contextual Alert this output as the main result of the IDSS because it pairs a specific prediction with a clear

explanation. In this design, the Researcher avoids basic warnings like "Pollution predicted"

and instead provides the actual reasoning, like explaining that the alert is triggered because

of high electrical conductivity. This method makes the alert more actionable and trustworthy

since the users can understand the logic the system used to reach its conclusion. Also, the

Researcher uses this approach to connect complex data with practical use, which means

environmental managers are better equipped to respond to the findings.

GIS Dashboard / Color- The final visualization interface maps real-time sensor data, AI forecasts, and XAI risk

Coded Risk Map levels across the rivers and creeks of Legazpi City. The Researcher uses color-coding on

the map to clearly show how severe the predicted water quality degradation is in different

locations. This setup is useful because it helps the Researcher present complex data in a

way that is easy to understand at a glance. Environmental officers can quickly identify
 17

which specific areas need attention. The Researcher designed it this way to keep the

geographical context of the water quality visible and clear.

LSTM Neural Network utilizes LSTM, which is a type of recurrent neural network that is particularly well-suited for

processing and making predictions based on sequential data. In this study, the Researcher

applies this model to time-series sensor data collected for water quality parameters

because LSTMs are designed to remember patterns over long periods. The Researcher

runs these models on the Cloud Platform in order to achieve high-accuracy forecasting

since the cloud provides the necessary computational power for such complex math. This

choice is important because it allows the Researcher to capture the trends and fluctuations

in the water's condition over time, which means the resulting predictions are much more

reliable for long-term monitoring.

 18

OPERATIONAL FRAMEWORK

This Research employs an Applied Technology Development research design since the

study aims to create, deploy, and validate a new distributed AI-integrated IoT system for water

quality forecasting and mapping. In this case, the Researcher follows three sequential phases in

order to ensure the framework is built properly and tested thoroughly. First, the Researcher works

on System Development, which includes specifying the architecture, assembling prototypes with

off-the-shelf sensors, training TinyML models, and selecting XAI methods. Second, the Researcher

moves into System Implementation, which involves the actual field deployment across monitoring

points in Legazpi's rivers and creeks, as well as managing data acquisition and edge-to-cloud

integration. Finally, the Researcher carries out Performance Validation in order to measure

technical aspects such as accuracy, latency, energy use, and bandwidth. Also, the Researcher

conducts user-oriented assessments of interpretability and decision support during this phase

because it is necessary to verify that the system is truly useful in a practical setting.
 19

Figure 2-1. Conceptual diagram of the system

Phase 1: Data Collection & Pre-processing

The Researcher focuses this phase on the logical and physical build-out of the sensing and data

pipeline layers. In the Sensing Layer, the Researcher selects and installs low-cost, real-time

probes to monitor core parameters like pH, dissolved oxygen, turbidity, electrical conductivity, and

temperature at various points along the rivers and creeks of Legazpi City. The Researcher uses

ESP32 Wi-Fi or LoRa-based links for communication, adding a gateway if necessary, in order to

keep the devices connected. Also, the Researcher incorporates auxiliary context like recent rainfall
 20

and ambient humidity from the local weather service on a routine schedule because these factors

affect water quality.

During pre-processing, the Researcher standardizes timestamps and units while also handling

missing data and outliers. The Researcher applies sensor calibration, drift correction, and noise

reduction in order to ensure the data is reliable. A unified schema is defined for geo-referenced

time series, and the Researcher includes quality control flags and a data dictionary to keep

everything organized. Finally, in the Application and GIS Layer, the Researcher aggregates the

cleaned data streams and computes a provisional Water Quality Index. This allows the Researcher

to prepare layers for a web-based GIS dashboard, which means the system will eventually be able

to render color-coded risk maps for the users.

Phase 2: Model Development & Training

The Researcher uses this phase to develop the distributed intelligence that spans both the edge

and the cloud. At the edge, the Researcher trains lightweight anomaly detectors on multivariate

windows using compact models like gradient boosted trees or small feedforward networks. These

models are then converted into a TinyML format with post-training quantization because the

Researcher needs them to fit within the strict memory and energy budgets of microcontrollers.

Instead of sending raw data streams, the Researcher ensures the edge only outputs event scores

and minimal summaries, which means the system is much more efficient with bandwidth.

In the cloud, the Researcher implements sequence models like LSTM networks in order to learn

multi-step forecasts and temporal patterns across different sites. The Researcher also uses

Explainable AI methods, specifically post-hoc model-agnostic techniques like SHAP or LIME, to

generate variable attributions and temporal saliency for both the edge anomalies and the cloud
 21

forecasts. To make the results more reliable, the Researcher adds uncertainty calibration for

prediction intervals. For model selection, the Researcher uses rolling origin cross-validation, and

performance is tracked using RMSE and MAE for forecasting. For the anomaly detection part, the

Researcher measures success through AUROC, precision, recall, and the false alarm rate.

Phase 3: Prototype Development & Integration

The Researcher carries out this phase to deploy and test the entire system in a real-world setting.

In this case, the Researcher chooses specific sites along the waterway network in order to capture

spatial variability, which involves setting up a network of three to five instrumented nodes at

upstream, midstream, and downstream sections. The Researcher keeps the system running for

three to six months since this period provides the baseline data needed for final tuning. During the

field run, the edge nodes manage on-device screening and send event-based messages to the

cloud, where the Researcher executes the forecasting models, creates XAI explanations, and

handles archival [Link], the Researcher integrates the resulting alerts and explanations

into a GIS dashboard to build a color-coded risk map for decision support. To validate the

performance, the Researcher measures predictive accuracy against a centralized baseline while

also tracking the latency from the moment data is acquired until an alert is issued. The Researcher

also estimates energy and bandwidth savings compared to continuous cloud streaming in order to

demonstrate the efficiency of the TinyML approach. Finally, the Researcher evaluates usability by

confirming that map layers match the actual node outputs and by collecting feedback from local

environmental managers on how the system helps with timely decision-making..

Materials
 22

Hardware Requirements

1. Edge Sensing Node

The Researcher handles the hardware side of the project by ensuring each node measures

water quality directly at the river or creek while performing on-site anomaly screening. In this case,

the Researcher uses either an ESP32 S3 DevKit with PSRAM or an Arduino Nano 33 BLE Sense

since these microcontrollers provide the GPIO, timers, and low-power modes required for multi-

probe sampling and TinyML inference. The Researcher reserves at least 320 KB of free RAM for

the model and buffers in order to keep the localized processing smooth. Also, a microSD module is

included to buffer telemetry and diagnostic logs during backhaul outages, which means the

Researcher can preserve audit trails for later validation.

The sensing suite is quite detailed because the Researcher needs to quantify various

environmental factors. The Researcher uses a pH probe like the Atlas Scientific EZO or DFRobot

Gravity for acidity, and a dissolved oxygen probe to assess biological oxygen demand. To track

ionic strength from fertilizer runoff or industrial discharge, the Researcher installs an electrical

conductivity probe. Also, an optical turbidity sensor is used to infer suspended solids, while a

DS18B20 or PT100 temperature probe provides the necessary hydrologic context. For

connectivity, the Researcher enables Wi-Fi or LTE depending on what is available at the site.

The power system is designed for longevity, using a 10 to 20 watt solar panel, a LiFePO4

battery, and an MPPT charge controller. The Researcher targets a sleep current below 200
 23

microamperes in order to achieve at least five days of autonomy without sun. To protect the

electronics, the Researcher houses them in an IP67 polycarbonate enclosure with desiccant and

conformal coated boards, while the probes sit in a PVC holder with an intake strainer and copper

tape to prevent biofouling. Finally, the Researcher uses a field calibration kit with various standards

and buffers to maintain accuracy. The goal is a sampling interval of one to five minutes, with the

node reaching an anomaly decision within 200 milliseconds after sampling while maintaining a

packet delivery success rate above 95 percent.

2. Gateway and Backhaul

The Researcher uses a LoRaWAN gateway, such as the RAK7268, which features an

Ethernet uplink and optional LTE fallback in order to receive packets from the nodes and forward

them to the cloud broker. In this setup, the Researcher ensures proper antenna placement to

achieve line-of-sight coverage along the monitored reaches of the river, which means the signal

remains stable even over longer distances. Basically, the gateway is supported by an

uninterruptible power supply or a small solar kit because the Researcher needs the system to stay

online even when grid power is unavailable. Also, the Researcher uses a router or 4G hotspot to

provide Internet access, and this includes basic firewall rules to secure the link between the field

and the cloud..

3. Tools and Accessories

The Researcher carries out the field setup using a laptop with a serial console and flashing

tools for node commissioning and diagnostics. During this process, the Researcher uses a
 24

handheld multimeter and thermometer to conduct quick cross-checks against the live sensor

readings, confirming that the probes are properly calibrated at the start.

To ensure the equipment can withstand the harsh conditions of the river environment, the

Researcher uses stainless steel clamps, straps, and fasteners to mount the electronics enclosures

and probe holders onto bridges or stakes. This physical stabilization is vital because it keeps the

hardware stationary and the sensors submerged correctly, which means the data gathered over

the long-term deployment stays consistent and reliable.

4. Pilot Quantities

The Researcher handles the field deployment in Legazpi by placing three edge nodes at

specific points along a single waterway. Specifically, the Researcher puts one node upstream, one

midstream, and one in the near-urban or downstream section so the study can track how water

quality changes as it travels from the headwaters into more developed areas.

In this case, the Researcher uses a single gateway with strong line-of-sight coverage

because reliable communication from all three nodes is necessary for real-time monitoring. To

keep the data collection steady, the Researcher also keeps a backup stock of probes for every

parameter, which means a maintenance swap-out can happen right away if a sensor breaks down.

This setup keeps the entire dataset intact and ensures that the temporal patterns in the river are

recorded without interruptions so the AI models have high-quality data to work with.

Software Requirements

1. Edge Firmware
 25

The Researcher develops the node firmware using the Arduino framework for the ESP32,

or sometimes the ESP-IDF when the system needs finer power control to save battery. In this

case, the Researcher integrates several drivers like OneWire for temperature and I2C or UART for

the pH and conductivity circuits, while using SD or LittleFS to handle the local logging. For the

actual intelligence at the edge, the Researcher executes TinyML inference using TensorFlow Lite

for Microcontrollers or EloquentTinyML. This involves a quantized compact model that scores short

multivariate windows and sends out an anomaly score along with rolling statistics.

The Researcher sets up communications using LoRaWAN through an LMIC stack, or

MQTT if Wi-Fi or LTE is available at the site. Because the nodes are in the field, the Researcher

includes reliability features like over-the-air updates for firmware and model blobs, a hardware

watchdog, and brownout detection. Also, the Researcher uses retry logic with exponential backoff

to handle connection drops. To keep everything synchronized, the Researcher uses NTP through

the gateway or a GPS source because the records need correct ordering and cross-site alignment

for the cloud models to work properly.

2. Messaging and Storage Services

The Researcher utilizes Eclipse Mosquitto as the message broker because it effectively

handles the ingestion of telemetry and routes events to the necessary downstream processors. In

this case, the Researcher implements Node-RED to manage schema validation and light data

transformations, which means the incoming information is cleaned and enriched before any alerts

are sent out. Since the project generates a massive amount of temporal data, the Researcher

stores time-series records in InfluxDB or TimescaleDB. This allows the Researcher to set up
 26

retention policies and fast down-sampling, which are both necessary for efficient visualization and

long-term analysis.

For the backend storage, the Researcher keeps raw files, calibration logs, and model

artifacts in MinIO or an S3-compatible store in order to maintain research reproducibility. Also, the

Researcher uses PostgreSQL with PostGIS to handle site metadata and the actual geometries of

the rivers and creeks. This setup is important because it supports spatial joins and proximity

queries, which means the Researcher can easily connect the sensor data from the nodes to their

specific locations on the map.

3. Modeling and Explainability Layer

The Researcher is currently using Python 3.11 within a managed Conda or venv setup to

host the modeling environment for this study. Because the goal is to generate multi-step forecasts,

The Researcher implements compact LSTM or temporal convolutional models through TensorFlow

or PyTorch. To keep the results grounded, The Researcher also uses scikit-learn and XGBoost to

create tabular baselines and handle drift monitors.

Since it is important to see what goes on inside the models, The Researcher applies post

hoc model-agnostic explainability via SHAP and LIME. This process allows The Researcher to

identify which specific variables and time segments have the most weight for every alert or

forecast. In order to make the outputs more reliable, The Researcher also focuses on uncertainty

calibration using mapie, scikit-learn utilities, or conformal prediction so that prediction intervals and

confidence information are attached to the data.

4. API, Dashboard, and Alerting

 27

The Researcher is using a FastAPI backend to provide REST endpoints for telemetry,

alerts, and uncertainty summaries, which makes it easier to handle the data flow across the

system. GeoServer is integrated to serve the tiled and vector map layers because the spatial data

needs to be organized properly for the visualization. For the web frontend, The Researcher is using

Leaflet or Mapbox GL JS to render the color-coded risk map, and [Link] is also being used to

show the trends and explanation summaries.

The Researcher is also including an authentication system with specific roles for operators

and reviewers so that access is strictly controlled. This setup connects to the alerting system,

which uses email, webhooks, or SMS to send out concise messages. These alerts are important

because they give the measured value, the threshold, and the confidence interval. In this case, The

Researcher is also making sure that the top explanatory features are included in the messages so

that the users can see the XAI results immediately..

5. DevOps, Monitoring, and Security

The Researcher is utilizing Docker and Docker Compose to package the broker,

databases, API, and dashboard in order to ensure that the deployment is reproducible across

different environments. In this case, GitHub Actions is used to handle the CI/CD pipeline, which

means it automatically runs linting, unit tests, and firmware builds before publishing the images.

This automation is necessary because it maintains the integrity of the code throughout the

development process.

The Researcher is also integrating Prometheus and Grafana to monitor the metrics of the

nodes and gateways. This allows for the tracking of packet success rates, RSSI, power status, and

service latencies, which is important for maintaining the stability of the LoRaWAN network.
 28

Regarding the security of the system, The Researcher is implementing several controls

such as LoRaWAN key management and TLS for the APIs and dashboards. Access is restricted

through role-based access control, and The Researcher is also making sure to use periodic key

rotation and encrypted-at-rest databases where feasible because protecting the data at every level

is a priority for the study..

6. Data Schemas and Topics

The Researcher is organizing the MQTT topics using a structured pattern that includes site

node telemetry, site node event, and site node diag because this makes the data much easier to

categorize. In the telemetry fields, The Researcher is tracking the timestamp, location data, and

several water quality parameters like pH, electrical conductivity, dissolved oxygen, turbidity, and

temperature. The Researcher is also including metadata such as quality flags, battery voltage, and

the firmware version to ensure the hardware is functioning correctly.

For the events, The Researcher is focusing on fields like the anomaly score and the model

identifier, which are paired with the confidence interval and the top features from the model. This is

done in order to provide an action hint for every detected event. Basically, the system is designed

with specific end-to-end performance targets to keep the operations reliable. The Researcher is

aiming for an edge decision to be made within one second of sampling, followed by a gateway-to-

dashboard alert within two minutes when the connectivity is normal. Also, The Researcher is

targeting a minimum of 95 percent system uptime during the evaluation window and will be
 29

retaining the time-series data for at least six months so that there is enough information for long-

term analysis and reporting.

1.4.1 Data

The Researcher is utilizing high-resolution time-series data from two different sources, and

the collection is set to begin in the first semester of 2025 in order to align with the 2025-2026

academic year. The primary data comes from a network of 3 to 5 IoT edge nodes placed in rivers

and creeks around Legazpi City to monitor parameters like pH, dissolved oxygen, turbidity,

electrical conductivity, and temperature. This baseline collection phase will last for three to six

months because The Researcher needs a strong dataset for model recalibration and validation.

Also, secondary data like historical rainfall and humidity from the local weather bureau will be

integrated to improve the predictive [Link] ensure the water bodies meet their intended use,

The Researcher is following the DENR DAO No. 2016-08 standards for water quality. These

specific parameters were chosen because they serve as essential indicators of the ecosystem's

health. For example, dissolved oxygen is measured in mg/L to check if aquatic life can be

supported, while pH levels are monitored to keep them within the 6.5 to 8.5 range. Because

temperature affects oxygen solubility, it is also tracked in °C. The Researcher is using BOD5 to

measure organic pollution and total suspended solids to monitor physical pollution from erosion.

For the actual fieldwork, The Researcher is performing in-situ measurements with a multi-

parameter water quality sonde. The sampling follows a systematic schedule at set depths and

locations over a six-month period. Before every deployment, The Researcher calibrates the tools

using NIST-traceable standards in order to keep the data accurate. A post-calibration verification is

also done where the reading must be within ±5% of a known check standard. So that the data
 30

remains reliable, The Researcher follows standard operating procedures to avoid contamination

and only records the data once the sensors have stabilized for 30 seconds.

The Researcher is also implementing a strict QA/QC process to make sure the data is

trustworthy. This involves a drift check against a known sample before starting new measurements.

If the sensor drifts by more than ±0.05 pH units, The Researcher will flag that data as unreliable

and review it. Basically, every final result will include the sensor's error margin or uncertainty value

because The Researcher wants to be transparent about the precision of the hardware used in the

study.:

Reported Value = Measured Value ± Sensor Accuracy.

Equation 1. transparency regarding the inherent precision limitations of the instrument

The Researcher is applying the sensor error margin because it is necessary for a

scientifically sound assessment of compliance, especially when the readings are very close to the

DENR regulatory limits. For example, if the required dissolved oxygen is 5.0 mg/L and the sensor

reads 5.1 mg/L, it might look like the water body is compliant at first. However, once The

Researcher factors in the instrument’s uncertainty of ±0.2 mg/L, the actual value could be

anywhere from 4.9 mg/L to 5.3 mg/L. This means the lower bound actually falls below the limit,

which indicates a risk of non-compliance. The Researcher is including this discussion in the results

in order to provide a more rigorous and defensible basis for recommending interventions under the

Water Quality Management plan.

 31

The refined conceptual model and GIS dashboard focus on an event-driven monitoring

schedule to maximize the battery life of the nodes. The process starts at the sensing layer, where

the ESP32 edge nodes are set for sparse data collection, like twice per month, to minimize energy

use. Basically, the TinyML-optimized model on the edge stays in a low-power watch mode until it

detects an anomaly. Once an anomaly is found, the node immediately shifts to a high-frequency

data stream to provide real-time details to the system.

This data burst is sent to the cloud database, which then triggers the LSTM neural network

to generate a 48-hour WQI forecast. Because transparency is important for decision-making, the

XAI engine uses SHAP or LIME to calculate the causal explanation for the anomaly. The

Researcher is packaging the prediction and the rationale into a Trustworthy Alert Object, which is

then displayed on the GIS dashboard. The dashboard uses a risk map to visualize the situation

while a contextual alert panel shows the XAI causal explanation, which helps managers justify their

interventions based on clear evidence.

Figure 3: Sample dashboard of GIS

 32

1.5 Methods

1.5.1 Experimental design

The methodology for this thesis establishes the scientific tests used to validate the novel

aspects of this distributed AI framework, and it is divided into three core experiments that address

prediction accuracy, architectural efficiency, and user trust.

In the first experiment, The Researcher is using multivariate time-series analysis to

systematically compare how well the predictive models perform. The procedure follows a three-

step comparative test, where The Researcher first establishes a performance baseline using a

simplified centralized model. Second, The Researcher trains and validates the resource-

constrained TinyML-optimized models, specifically XGBoost and ANN, to prove that local

classification is possible. Finally, The Researcher rigorously trains the complex LSTM neural

network for multi-step 24-48 hour WQI forecasting using the full time-series dataset. The

Researcher is testing these against a common validation dataset from the real-world river data,

and success is measured using RMSE, MAE, and the coefficient of determination because these

are the standard statistical metrics for forecasting.

The second experiment employs an A/B testing procedure to quantify the operational

benefits of moving the workload to the edge layer. The Researcher wants to prove that the

framework is superior in terms of cost and speed. In Test A, The Researcher simulates a

centralized scenario where all raw data is sent to the cloud to measure the high latency and energy

consumption. In Test B, The Researcher activates the TinyML edge model for data filtering and
 33

anomaly detection. The Researcher then compares three critical metrics: average end-to-end

latency, data transmission reduction percentage, and energy consumption in mAh per 24 hours.

This provides the quantitative proof that the design successfully mitigates the bandwidth issues

found in traditional IoT systems.

The final experiment uses a behavioral and survey-based design to validate the system's

human-centric success, especially the effectiveness of the XAI engine. The Researcher is using

purposive sampling of 20 to 30 stakeholders who will be shown predicted alerts that include the

SHAP or LIME causal explanations. After that, The Researcher will administer a structured

questionnaire using a 5-point Likert scale to assess how the explanations affect trust,

interpretability, and actionability. This is important because it proves that the framework achieves

its objective of being a transparent and useful tool for environmental governance.

1.5.2 Procedures for the different phases

The procedures for this research follow a step-by-step execution organized by the phases

of the Applied Technology Development Research Design, and these phases directly support the

three core experiments regarding prediction, efficiency, and trust.

Phase 1: Distributed AI Architecture Design and Sensor Development This foundational

stage is when the project moves from a concept to a working blueprint. The Researcher begins

with the System Requirements Specification to finalize the bill of materials, which includes

selecting low-cost components like ESP32 microcontrollers and sensors for DO, pH, and turbidity.

At the same time, The Researcher defines the functional roles for the edge and cloud layers. For

the Edge Node Programming and TinyML Optimization, the ESP32 is programmed using

MicroPython or C++, while the XGBoost and ANN models are pre-trained in Scikit-learn. These are
 34

then optimized and deployed using TFLite-Micro so that anomaly detection happens in real time.

Finally, the Cloud Platform Setup involves establishing a secure environment on AWS or GCP and

initializing a PostgreSQL database with the TimescaleDB extension to handle the heavy data

ingestion from the nodes.

Phase 2: System Implementation and Baseline Data Collection This is the operational

phase where the physical monitoring network is established in the field. The Researcher starts with

Site Selection and Node Installation, which involves a survey to choose 3 to 5 strategic locations in

Legazpi City, like residential runoff or industrial discharge points. Once the sites are ready, the IoT

nodes are installed in IP-rated enclosures for autonomous use. For the Baseline Data Acquisition,

all nodes are activated to stream readings for pH, DO, temperature, and EC to the cloud for at least

three to six months because a robust dataset is needed for calibration. The Researcher also

completes the Auxiliary Data Integration by getting rainfall and humidity data from the weather

bureau and synchronizing it with the sensor readings in the database.

Phase 3: Model Training, XAI Integration, and IDSS Development This pivotal stage is

where raw data is transformed into forecasting tools. The Researcher begins Cloud Forecasting

Model Training by using the aggregated data to train the LSTM neural network for 48-hour

forecasts, using hyperparameter searching to ensure the best performance. Next, the XAI Engine

Integration is addressed by embedding SHAP or LIME to analyze the black-box LSTM predictions.

This allows the system to generate causal explanations, such as linking a drop in DO to a spike in

temperature. Finally, the IDSS Development involves building the web application with Django or

Flask and integrating GIS tools like Leaflet to display a color-coded Risk Map for stakeholders.
 35

Phase 4: System Performance Validation and Evaluation This final procedure is where the

three core experiments are executed to quantify the framework's success. The Researcher

performs the Predictive Model Comparison by applying the trained models to an independent

dataset and recording the RMSE, MAE, and R2 metrics. At the same time, the Architectural

Efficiency Assessment is done through A/B tests on the ESP32 nodes to compare power

consumption and latency between the centralized and distributed modes. Lastly, the Usability and

Trust Assessment involves the stakeholder survey with 20 to 30 participants. The Researcher uses

a 5-point Likert scale to evaluate interpretability and actionability, which provides empirical proof of

how the XAI engine impacts user trust.

1.5.3 Evaluation

To assess if the system actually works, The Researcher are conducting a series of tests to

evaluate how well it forecasts water quality parameters and detects anomalies through the

Distributed AI Architecture. The Researcher are using statistical metrics like RMSE, MAE, and R 2

to check the forecasting accuracy of both the Cloud LSTM and the Edge TinyML models because

these numbers show how close the predictions are to the actual data. For the anomaly

classification part, The Researcher are looking at the Confusion Matrix, Precision, Recall, and F1

Score in order to make sure the system correctly identifies when something is wrong with the

water. Because hardware performance is just as important as the software, The Researcher are

also measuring the Architectural Efficiency by tracking End-to-End Latency and Energy

Consumption. This part of the testing is meant to prove that the distributed approach is faster and

cheaper than standard methods. For the final stage, The Researcher are using Likert-scale

surveys with environmental managers to get feedback on the XAI Engine. The Researcher want to

see if the explanations provided by the AI are clear enough to be actionable, which means
 36

checking if the users actually trust the system to help them make decisions. Basically, The

Researcher will use all these results to see where the model needs adjustments so the whole

framework can be refined.

The Researcher are using the Confusion Matrix to see exactly how the TinyML Edge

Anomaly Detector and the Cloud LSTM model perform when they classify data. This matrix is

helpful because it compares what the models predicted against the actual labels for "Normal/Safe"

and "Anomalous/Polluted" water conditions. By using this tool, The Researcher can identify True

Positives (TP) and True Negatives (TN), while also tracking False Positives (FP) and False

Negatives (FN) since these represent false alarms or missed anomalies. The Researcher are

focusing on these specific quadrants because they show exactly where the model is succeeding

and where it might be failing. For instance, high False Negatives would be dangerous in an

environmental context since that means the system missed a pollution event. Because of that, The

Researcher are analyzing the matrix results to adjust the models in order to reach a better balance

between sensitivity and precision. The Researcher believe that visualizing the data this way makes

it much easier to explain the reliability of the system to the technical panel during the defense.

The Researcher are calculating the Classification Accuracy to find the overall percentage

of correct predictions out of all the evaluations conducted. This step is important because it gives a

basic measure of how effectively the system can tell the difference between a safe state and a

potential contamination event. The Researcher are focusing on this metric since a high accuracy

rate is necessary to ensure that the implementation is robust enough to handle various data

streams and different environmental settings.

 37

Because Accuracy is defined as the ratio of correct predictions to the total number of

cases, The Researcher are using the formula:

Equation 1. Accuracy Formula (NaveenKP, 2024)

The Researcher are using Precision, Recall, and the F1 Score to evaluate how well the

TinyML Edge Model and the Cloud LSTM Model classify water quality. Precision is being used to

measure the proportion of correctly identified pollution events out of everything the model flagged

as anomalous. This matters because The Researcher want to maintain a low rate of False

Positives (FP), since false alarms can waste resources and make people stop trusting the

[Link] the other hand, Recall measures how many of the actual pollution events were actually

caught by the system. The Researcher need a high recall score in order to minimize False

Negatives (FN), because missing a real contamination event in the waterways of Legazpi City

would be a serious risk to public health. Since it can be hard to balance these two, The Researcher

are also calculating the F1 Score, which is the harmonic mean of precision and recall.
 38

The Researcher are skipping the Intersection over Union metric and instead using tools

specifically for time-series forecasting. To see how well the Cloud LSTM model predicts the

continuous Water Quality Index (WQI) over a 24 to 48-hour period, The Researcher are applying

RMSE and MAE. RMSE is useful because it highlights the magnitude of larger forecast errors,

while MAE shows the average error in actual WQI units. Both of these metrics help The

Researcher quantify how closely the system's output aligns with the ground truth data collected

from the rivers here in Legazpi City. Also measuring the Average End-to-End Latency in order to

validate if the system is actually viable for operational use. This metric tracks the time delay

starting from the initial sensor reading at the Edge Node all the way to the final alert shown on the

IDSS. Because real-time intervention requires ultra-low latency, The Researcher need to ensure

the data travels fast enough to allow for proactive responses before water quality gets worse.

Basically, these measurements prove that the system is not just accurate on paper but also fast

enough to be useful in the field

 39

2 RESULTS AND DISCUSSION

2.1 Results by phase of study

Name the phases of your study and give the results. Have as many headings as

necessary depending on the number of experiments or studies you did. Provide the discussions.

2.2 Verification studies

The headings above are only suggestive. Follow what is appropriate for your research

work.
 40

3 SUMMARY, CONCLUSIONS, AND RECOMMENDATIONS

3.1 Summary

Provide a rather concise summary of the research work.

3.2 Conclusions

The conclusions are direct statements that would prove the achievement of the specific

objectives. The conclusions should have one-to-one correspondence to the specific objectives, i.e.

if you have 4 specific objectives (a to d) then you should have 4 conclusions (1 to 4).

3.3 Recommendations
 41

REFERENCES
 42

APPENDICES

<Appendix A:><Title>

Place your appendices here. Please be sure that these have been referenced in the body

of document.
 43

CURRICULUM VITAE

This section is for Dissertations only.