FlowGuardian in Multi-Domain Systems

• FlowGuardian is an overloaded term defining systems for residential leak detection, NLP-based cybersecurity extraction, water network anomaly monitoring, and federated learning safeguards.
• Each system employs runtime monitoring with structured intermediate representations—from ESP32 sensor data processing to BERT-powered textual analysis—to achieve robust, domain-specific detection.
• Variations in methodologies and performance metrics across domains highlight the necessity of using precise qualifiers when referencing FlowGuardian implementations.

Searching arXiv for "FLOWGUARDIAN" and closely related naming variants to ground the article in current papers. FLOWGUARDIAN is a reused system name in several technically distinct research contexts, rather than a single canonical method. In the arXiv record and related preprints provided here, the name denotes at least four different classes of systems: a residential water leak monitor for slow bathroom leaks (Greysukh, 2019), an NLP pipeline for extracting cybersecurity attack testflows from threat reports (Ahmadou et al., 9 Jul 2025), an unsupervised online framework for detecting blockages and leakages in water distribution networks (Li et al., 22 Aug 2025), and a run-time framework for detecting and recovering from Negative Federated Learning, where the prompt explicitly equates FL-GUARD with “FlowGuardian” (Lin et al., 2024). A related federated-computing guard-rail architecture, Guardian-FC, is also described as “FLOWGUARDIAN / Guardian-FC” in the supplied material (Veeraragavan et al., 24 Jun 2025). The term therefore functions as an overloaded label whose meaning depends on domain, problem formulation, and implementation substrate.

1. Name usage and disambiguation

The most immediate technical feature of FLOWGUARDIAN is its ambiguity across domains. In residential sensing, it refers to a low-cost residential water leak monitoring and notification system for slow, hard-to-notice bathroom leaks, especially periodic leaks (Greysukh, 2019). In cyber threat intelligence, FLOWGUARDIAN is a novel solution leveraging LLMs (i.e., BERT) and NLP techniques to automate the extraction of attack testflows from unstructured threat reports (Ahmadou et al., 9 Jul 2025). In water distribution monitoring, the supplied material identifies FLOWGUARDIAN as an unsupervised, online fault-detection framework for water distribution networks (WDNs) that treats pipe blockages as collective anomalies and background leakages as concept drift (Li et al., 22 Aug 2025). In federated learning, the prompt states that FL-GUARD, also called FlowGuardian in the prompt, is a run-time framework for detecting and recovering from Negative Federated Learning (NFL) (Lin et al., 2024). In federated computing, the supplied explanation explicitly uses FLOWGUARDIAN / Guardian-FC for a two-layer framework for privacy preserving federated computing with an Agentic-AI control plane and backend-neutral guard-rails (Veeraragavan et al., 24 Jun 2025).

This multiplicity makes disambiguation essential. A concrete claim about FLOWGUARDIAN is not portable across these papers unless the domain is specified. For example, references to ESP32, Amazon SNS, and 0.01–0.4 Hz piston frequency belong to the residential leak-monitoring system (Greysukh, 2019), whereas references to BERT, spaCy, MITRE ATT&CK, 30 core cybersecurity primitives, and 44 mapping rules belong to the cybersecurity system (Ahmadou et al., 9 Jul 2025). Likewise, LSTM-VAE, STL decomposition, KS-test, and G-mean belong to the WDN framework (Li et al., 22 Aug 2025), not to the residential IoT device or the FL system.

A plausible implication is that FLOWGUARDIAN should be treated as a family name or label collision, not as a single research lineage.

2. FLOWGUARDIAN in water monitoring and leak detection

One major usage of FLOWGUARDIAN is in water-related monitoring, but even there it denotes two different problem settings.

In the residential setting, FLOWGUARDIAN is a low-cost residential water leak monitoring and notification system designed for slow, hard-to-notice bathroom leaks, especially periodic leaks such as those caused by a deteriorating toilet tank flapper or gasket (Greysukh, 2019). Its sensing principle is non-invasive: an ESP32 microcontroller is paired with an LSM303 triple-axis magnetometer over I2C, and the magnetometer is placed near a residential water meter to detect magnetic field fluctuations caused by the meter’s internal revolving piston or magnetic drive. For the target meter, relevant leak flow rates correspond to about 0.01–0.4 Hz piston frequency, mapping to roughly 1–20 gallons/hour on an AMCO C700 InVision meter (Greysukh, 2019). The device performs on-board processing and delegates alert delivery to Amazon Simple Notification Service (SNS).

The residential system distinguishes continuous leaks from periodic leaks. For continuous leaks, it computes the signal spectrum every 10 minutes, accumulates spectral peaks into a peaks frequency distribution, and performs distribution analysis every 2 hours. For periodic leaks, it dereferences the signal at the beginning of the window, uses a variant of the z-score algorithm with lag = 10 s and threshold = 3, accumulates a period-duration distribution, and performs distribution analysis every 6 hours (Greysukh, 2019). The reported operational tradeoff is delayed but robust detection: 1–2 hours to reliably detect continuous leaks and 4–6 hours for periodic leaks, with no false positives observed during extensive testing (Greysukh, 2019).

By contrast, the WDN formulation of FLOWGUARDIAN is an unsupervised, online fault-detection framework for water distribution networks (WDNs) using only pressure sensors, with one detector pair $(AD_i, DD_i)$ per sensor (Li et al., 22 Aug 2025). Here the central distinction is not bathroom fixture leakage versus household use, but pipe blockages versus background leakages. The framework combines STL decomposition, an LSTM-based variational autoencoder, and dual drift detection to operate under non-stationary conditions with limited or unavailable labels (Li et al., 22 Aug 2025). The anomaly model is sequence-based: the VAE objective is given as

$$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$

and an input is considered anomalous if its cumulative reconstruction loss exceeds an adaptive threshold $\theta^t$ (Li et al., 22 Aug 2025).

The drift component has two parts. DD1 uses a KS-test on normal latent embeddings: $$KS_{dis} = \max \left|F(ref_{\text{latent}_i}) - F(mov_{\text{latent}_i})\right|,$$ with $P_{warn}$ and $P_{alarm}$ as warning and alarm thresholds. DD2 uses Euclidean distance over anomaly buffers: $$DIS(ref_{AN}, mov_{AN})=\sqrt{\sum_{i=1}^n\sum_{j=1}^m\left(ref_{ANij}-mov_{ANij}\right)^2},$$ and raises an alarm if the distance exceeds $DIS_{thre}$ (Li et al., 22 Aug 2025). Evaluation is on the Hanoi network and the ZJ (Zhi Jiang) network, with 17,520 time points per scenario and Gaussian noise $N(0,0.01)$ added to all sensors (Li et al., 22 Aug 2025). The main metric is

$G\text{-}mean=\sqrt{R^+ \times R^-},$

with prequential evaluation and fading factor $$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$0 averaged over 10 runs (Li et al., 22 Aug 2025).

These two water-related usages share a leak-detection theme but differ sharply in scale, instrumentation, and formalism. One is a commodity IoT leak alarm optimized for bathroom leaks; the other is a decentralized online anomaly-and-drift framework for WDN hydraulics.

3. FLOWGUARDIAN in cybersecurity threat intelligence

In cybersecurity, FLOWGUARDIAN is a pipeline for converting unstructured cyber threat reports into structured attack testflows (Ahmadou et al., 9 Jul 2025). Its motivation is operational rather than purely linguistic: modern APT campaigns are described in prose, and analysts must manually identify attacker infrastructure, actions, vulnerabilities, and sequences before translating them into usable test procedures. FLOWGUARDIAN automates that transformation.

The pipeline has four stages: text preprocessing, contextual analysis, sequence analysis, and testflow generation (Ahmadou et al., 9 Jul 2025). In contextual analysis, the system uses BERT together with spaCy and a custom cybersecurity dataset. The entity schema covers eight key groups, including TEC for techniques, TAC for tactics, and THA for threat actors. The paper states that BERT is chosen because the authors want a stable discriminative model for structured extraction rather than a generative model that may hallucinate plausible but incorrect cyber details (Ahmadou et al., 9 Jul 2025). The system also extracts action verbs and verb phrases such as “exploiting vulnerabilities,” “downloading file,” and “adding new services.”

Sequence analysis transforms extracted entities and actions into an ordered adversarial narrative. The supplied description lists entity aggregation, sequence reconstruction, step identification, step aggregation, and validation against MITRE ATT&CK (Ahmadou et al., 9 Jul 2025). The final stage uses semantic mapping rules to connect extracted evidence to concrete tests. The authors derive 30 core cybersecurity primitives and design 44 mapping rules, followed by a testflow validator that removes duplicates and filters outputs for relevance and applicability (Ahmadou et al., 9 Jul 2025).

The evaluation uses public reports from the APTNotes repository, focusing on five APT41 reports: Mandiant #1, #2, #3, #4, and Trend Micro #5 (Ahmadou et al., 9 Jul 2025). Ground truth comes from two security practitioners, and the paper reports manual testflow counts of 27, 16, 42, 48, and 33, with unique testflows of 24, 11, 33, 42, and 25 respectively (Ahmadou et al., 9 Jul 2025). The benchmark compares FlowGuardian against ChatGPT-off-the-shelf, Llama-off-the-shelf, ChatGPT-with-PFG, and Llama-with-PFG, where PFG denotes insertion of the FlowGuardian pipeline before the model (Ahmadou et al., 9 Jul 2025).

Quantitatively, the paper claims that FlowGuardian generates more than twice as many valid testflows as ChatGPT-off-the-shelf and Llama-off-the-shelf across all five reports, and that for Mandiant #1 and #2, it reaches nearly three times the coverage of the off-the-shelf baselines (Ahmadou et al., 9 Jul 2025). It also reports stable semantic similarity to ground truth, ranging from 0.82 to 0.87, and an average execution time of 197.692 seconds (Ahmadou et al., 9 Jul 2025). A plausible implication is that the main contribution lies less in replacing LLMs than in adding a structured extraction-and-reconstruction layer before generation.

4. FLOWGUARDIAN in federated learning and federated computing

A separate usage appears in federated systems. In one paper, the prompt explicitly maps FL-GUARD to FlowGuardian, describing it as a holistic, run-time framework for detecting and recovering from Negative Federated Learning (NFL) (Lin et al., 2024). NFL is defined as the condition where the federated model does not outperform clients’ own private models for most clients. The on-client performance gain is

$$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$1

and the overall performance gain is

$$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$2

The supplied text states that the system is in NFL if there is no round after which the overall gain stays nonnegative (Lin et al., 2024).

The framework’s central idea is run-time control: detect NFL early, then activate recovery only when needed. Client-side estimated gain is computed as

$$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$3

the server aggregates estimates using a per-round median,

$$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$4

and smooths over the last $$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$5 rounds,

$$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$6

Recovery uses an adapted client model $$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$7 trained with

$$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$8

where $$l_{VAE}(x,\hat x)=l_{AE}(x,\hat x)+\beta \cdot l_{KL}(x),$$9 is dynamically set using

$\theta^t$0

$\theta^t$1

$\theta^t$2

The reported tasks are CIFAR-10 with a CNN and Shakespeare with an LSTM, both with 100 clients (Lin et al., 2024). Under default NFL settings, the paper reports FedAvg: ACC 48.26, $\theta^t$3 and FL-GUARD detect & recover: ACC 84.85, $\theta^t$4 on CIFAR, and FedAvg: ACC 33.74, $\theta^t$5 versus FL-GUARD detect & recover: ACC 54.03, $\theta^t$6 on Shakespeare (Lin et al., 2024).

A related but broader federated-computing usage is Guardian-FC, described in the supplied material as FLOWGUARDIAN / Guardian-FC (Veeraragavan et al., 24 Jun 2025). This system is not about statistical optimization failure but about backend-agnostic safety enforcement across privacy-preserving computation mechanisms such as FHE, MPC, and DP. Its architecture has a control plane and a data plane, with an Agentic-AI control plane enforcing a finite-state safety loop: Sense → Predict → Act → Prove (Veeraragavan et al., 24 Jun 2025).

The control plane ingests signed telemetry frames at about 1 Hz, evaluates guard-rail predicates, dispatches signed A-commands, and records evidence in an append-only Merkle ledger (Veeraragavan et al., 24 Jun 2025). The backend-neutral DSL and interchangeable Execution Providers (EPs) allow the same plug-in logic to run under different privacy backends. The formal model uses FSMs, and the safety invariant is written as

$\theta^t$7

with the default $\theta^t$8 (Veeraragavan et al., 24 Jun 2025). The liveness ranking function is

$\theta^t$9

and termination is characterized by

$$KS_{dis} = \max \left|F(ref_{\text{latent}_i}) - F(mov_{\text{latent}_i})\right|,$$0

This suggests a different sense of “guardian”: not model adaptation, but runtime orchestration and policy enforcement over heterogeneous privacy substrates.

5. Architectural patterns across FLOWGUARDIAN systems

Despite domain heterogeneity, several recurrent design motifs appear across the different FLOWGUARDIAN systems.

First, FLOWGUARDIAN systems are typically runtime monitors, not offline analytic frameworks. The residential device continuously samples magnetic field data on an ESP32 and triggers Amazon SNS notifications after on-device detection (Greysukh, 2019). The WDN framework performs online anomaly detection and retraining when drift alarms are raised (Li et al., 22 Aug 2025). The cybersecurity system processes reports into operational testflows that can support threat hunting, incident response, and security testing (Ahmadou et al., 9 Jul 2025). FL-GUARD monitors estimated client benefit round by round and activates recovery only when the federation becomes unhealthy (Lin et al., 2024). Guardian-FC continuously collects signed telemetry and issues control actions in a finite-state loop (Veeraragavan et al., 24 Jun 2025).

Second, the systems are generally structured around intermediate representations rather than raw observations alone. In the leak monitor, raw magnetometer traces are converted into frequency distributions or period-duration distributions (Greysukh, 2019). In the WDN framework, raw pressure streams are decomposed with STL, encoded into latent representations by an LSTM-VAE, and then tested for drift via latent-window statistics (Li et al., 22 Aug 2025). In cybersecurity, threat-report prose is transformed into entities, actions, sequences, and eventually test primitives (Ahmadou et al., 9 Jul 2025). In federated learning, local performance is reduced to smoothed gain estimates $$KS_{dis} = \max \left|F(ref_{\text{latent}_i}) - F(mov_{\text{latent}_i})\right|,$$1 and dynamic regularization weights $$KS_{dis} = \max \left|F(ref_{\text{latent}_i}) - F(mov_{\text{latent}_i})\right|,$$2 (Lin et al., 2024). In Guardian-FC, raw privacy-preserving computation is abstracted through DSL opcodes, telemetry schemas, and predicates (Veeraragavan et al., 24 Jun 2025).

Third, these systems often combine local autonomy with centralized or quasi-centralized oversight. The residential device performs all detection locally and uses the cloud only for notification (Greysukh, 2019). The WDN framework runs a detector pair $$KS_{dis} = \max \left|F(ref_{\text{latent}_i}) - F(mov_{\text{latent}_i})\right|,$$3 per sensor, indicating decentralization at the edge (Li et al., 22 Aug 2025). The cybersecurity pipeline centralizes contextual and sequence analysis but is intended to operationalize distributed threat intelligence (Ahmadou et al., 9 Jul 2025). FL-GUARD uses clients for local estimation and adaptation while the server decides NFL status (Lin et al., 2024). Guardian-FC separates node/aggregator execution in the data plane from the Agentic-AI control plane (Veeraragavan et al., 24 Jun 2025).

A plausible implication is that “FLOWGUARDIAN” has become associated less with a particular algorithm than with a systems pattern: continuous monitoring, structured inference, and selective intervention.

6. Limitations, scope, and recurring misconceptions

Because FLOWGUARDIAN refers to multiple systems, the most common misconception is that results from one paper can be generalized to another. This is not supported by the supplied material. The residential leak monitor reports no false positives in extensive testing but does not provide a formal benchmark table with precision/recall or ROC curves (Greysukh, 2019). Those claims cannot be transferred to the WDN framework, which instead reports G-mean above 0.9 on Hanoi and above 0.7 on ZJ (Li et al., 22 Aug 2025). Likewise, BERT-based extraction accuracy and execution time in the cybersecurity system do not imply anything about detection latency in FL-GUARD or Guardian-FC (Ahmadou et al., 9 Jul 2025).

Each system also has domain-specific limits. The residential device needs 1–2 hours for continuous leaks and 4–6 hours for periodic leaks, reflecting a bias toward robustness over immediate response (Greysukh, 2019). The WDN framework assumes seasonality is stationary after STL decomposition, does not solve definitive localization, and may weaken when faults occur far from sensors or in topologically complex networks (Li et al., 22 Aug 2025). The cybersecurity pipeline assumes reports contain enough detail, relies on a manually created ground truth from two practitioners, and evaluates only five APT41 reports (Ahmadou et al., 9 Jul 2025). FL-GUARD depends on the estimated performance gain mechanism and evaluates mainly on CIFAR-10 and Shakespeare (Lin et al., 2024). Guardian-FC is presented as a foundational architecture with formal-model groundwork and qualitative scenarios, rather than as a fully completed system (Veeraragavan et al., 24 Jun 2025).

Another misconception is that these systems necessarily share implementation strategies. They do not. FLOWGUARDIAN in residential monitoring uses Python prototypes and optimized Arduino C++ on ESP32 (Greysukh, 2019). The cybersecurity system is implemented in Python 3 on an Intel Xeon machine with 6 vCPU and 32 GB RAM running Ubuntu 20.04 (Ahmadou et al., 9 Jul 2025). The WDN system centers on LSTM-VAE, drift windows, and edge-level deployment (Li et al., 22 Aug 2025). FL-GUARD is an FL control layer compatible with methods such as FedProx, TrimmedMean, multi-Krum, K-norm, APFL, and Ditto (Lin et al., 2024). Guardian-FC introduces a backend-neutral DSL, Execution Providers, and a Merkle ledger (Veeraragavan et al., 24 Jun 2025).

These differences suggest that the most precise way to use the term is always with an accompanying domain qualifier: residential leak monitoring, WDN online fault detection, cybersecurity testflow extraction, run-time NFL recovery, or federated-computing guard-rails.