ADictML_MLSystems.tex

\newglossaryentry{commnetwork}
{name={communication network},
	description={A communication network\index{communication network} is a collection
		of \glspl{device} interconnected by communication links that allow them to
		exchange information \cite{DistributedSystems}, \cite{TanenbaumComputerNet}.
		For example, a mobile network consists of \glspl{device}, such as smartphones and base stations,
		that communicate wirelessly \cite{FundWireless}.
		\\
		See also: \gls{device}, \gls{mlsystem}, \gls{messagepassing}, \gls{flsystem}.},
	type=mlsystems,
	first={communication network},
	text={communication network},
	plural={communication networks},
	firstplural={communication networks}
}

\newglossaryentry{mlsystem}
{name={machine learning system (ML system)},
	description={An \gls{ml} system\index{machine learning system (ML system)} 
		consists of computational \glspl{device} that can gather and store \gls{data}, 
		execute \glspl{algorithm}, and exchange information via \glspl{commnetwork}. 
		Examples of the exchanged information include \gls{data} or updates of 
		\glspl{modelparam}. Conceptually, an \gls{ml} system is distinct from 
		an \gls{ml} \gls{algorithm}, i.e., an \gls{algorithm} specifies 
		the abstract computational procedure (e.g., an \gls{optmethod}), 
		while the system specifies how this procedure is realized in practice
		\cite{Sipser2013}, \cite{KnuthAlgoBook}, \cite{tanenbaum2006modern}.
		Examples of \glspl{algorithm} executed by \glspl{device} within an \gls{ml} system include
		\glspl{gdmethod} for solving \gls{erm} problems.
		\\
		See also: \gls{ml}, \gls{device}. },
 	type=mlsystems, 
 	first={machine learning system (ML system)}, 
 	text={ML system},
 	firstplural={machine learning systems (ML systems)},
 	plural={ML systems}
}

\newglossaryentry{automaton}
{name={automaton},
	description={An\index{automaton} automaton is a mathematical representation of a computing \gls{device} 
		whose behavior is described by a set of internal \glspl{state}, a memory 
		structure, and a \gls{state}-transition rule. Formally, an automaton consists 
		of a \gls{statespace}, a set of admissible memory configurations, 
		and a transition \gls{function} that specifies how the current \gls{state} 
		and memory are updated in response to inputs \cite{Sipser2013}. 
		The notion of an automaton is useful for the analysis of \glspl{algorithm}, such 
		as those used in \gls{ml} methods \cite{Cormen:2022aa}. 
		Collections of interacting automata can be used to study \glspl{distributedalgorithm}, 
		where each automaton represents a \gls{device} that executes local computations and 
		communicates with other \glspl{device} \cite{ParallelDistrBook}, \cite{LynchDistributedAlgorithms}.
		\\
		See also: \gls{device}, \gls{state}, \gls{algorithm}. }, 
	first={automaton}, 
	type=mlsystems,
	firstplural={automata}, 
	plural={automata}, 
	text={automaton} 
}

\newglossaryentry{byzantine}
{name={Byzantine device},
	description={In a distributed \gls{mlsystem}, a Byzantine \gls{device}\index{Byzantine device} 
		is one that deviates arbitrarily from its prescribed behavior \cite{Lamport1982}.
		Here, the term \gls{device} is used abstractly, i.e., the deviation may stem
		from a hardware fault or from a malicious human operator
		who controls otherwise correctly functioning hardware.
		In an \gls{flsystem}, Byzantine \glspl{device} can perturb
		the aggregated \gls{model} even if the majority of \glspl{device}
		follow their prescribed behavior. 
		Byzantine-robust \gls{fl} methods defend against this by 
		replacing simple averaging with robust aggregation rules \cite{NIPS2017_f4b9ec30}.
		From a regulatory perspective, Byzantine behavior poses a \gls{risk}
		to the \gls{robustness} obligations imposed on \glspl{provider}
		under the EU AI Act \cite{EUAIAct2024}.
		\\
		See also: \gls{flsystem}, \gls{robustness}, \gls{provider},
		\gls{messagepassing}, \gls{datapoisoning}.},
	type=mlsystems,
	first={Byzantine device},
	text={Byzantine device},
	plural={Byzantine devices},
	firstplural={Byzantine devices}
}

\newglossaryentry{dosattack}
{name={denial-of-service attack},
	description={A\index{denial-of-service attack} 
		denial-of-service \gls{attack} aims (e.g., via \gls{datapoisoning}) to steer the \gls{training} of a \gls{model}
		such that it performs poorly for typical \glspl{datapoint} (see Fig.\ \ref{fig_dosattack_dict}).
		\begin{figure}[H]
			\begin{center}
			\begin{tikzpicture}[>=Stealth, every node/.style={font=\small}]
				% axes
				\draw[->] (0,0) -- (7.5,0) node[right] {$\featurevec$};
				\draw[->] (0,0) -- (0,4.2);
				% data points (trusted source)
				\foreach \x/\y in {0.5/0.6, 1.2/1.1, 2.0/1.8, 2.8/2.3, 5.5/3.5, 6.0/3.9}
				\filldraw[black] (\x,\y) circle (2pt);
				% clean model (blue line)
				\draw[blue, thick] (0.2,0.35) -- (7.2,4.65)
				node[right, blue] {$\learnthypothesis$};
				% DoS model (red): flat line, performs poorly everywhere
				\draw[red, thick] (0.2,3.6) -- (7.2,3.6)
				node[right, red] {$\widetilde{\hypothesis}$};
			\end{tikzpicture}
			\end{center}
		\caption{Denial-of-service \gls{attack}: The black dots are \glspl{datapoint} from a trusted source.
			The clean \gls{hypothesis} $\learnthypothesis$ (blue) fits the \glspl{datapoint} well,
			while the poisoned \gls{hypothesis} $\widetilde{\hypothesis}$ (red) deviates from
			the \glspl{datapoint} across the entire \gls{featurespace}, rendering the \gls{model} unusable.
			\label{fig_dosattack_dict}}
		\end{figure}
		Unlike a \gls{backdoor} \gls{attack}, which degrades \glspl{prediction} only within
		a hidden trigger region, a denial-of-service \gls{attack} targets the
		overall \gls{model} performance over the entire \gls{featurespace}.
				\\
		See also: \gls{attack}, \gls{datapoisoning}, \gls{model}, \gls{datapoint}.},
	first={denial-of-service attack},
	type=mlsystems,
	plural={denial-of-service attacks},
	firstplural={denial-of-service attacks},
	text={denial-of-service attack} 
}

\newglossaryentry{fmi}
{name={Finnish Meteorological Institute (FMI)}, 
	description={The\index{Finnish Meteorological Institute (FMI)}
		FMI is a government agency responsible for gathering 
		and reporting weather \gls{data} in Finland.
				\\
		See also: \gls{data}.},
	first={Finnish Meteorological Institute (FMI)},
	type=mlsystems,
	text={FMI} 
}

\newglossaryentry{modelinversion}
{name={model inversion},
sort={modelinversion},
 	description={A\index{model inversion} \gls{model} inversion is a form of \gls{privattack} on an \gls{mlsystem}. 
  		An adversary seeks to infer \glspl{sensattr} of individual \glspl{datapoint} by exploiting partial access 
  		to a trained \gls{model} $\learnthypothesis \in \hypospace$. This access typically consists of 
  		querying the \gls{model} for \glspl{prediction} $\learnthypothesis(\featurevec)$ using carefully chosen inputs. 
  		Basic \gls{model} inversion techniques have been demonstrated in the context of facial image 
  		\gls{classification}, where images are reconstructed using the (\gls{gradient} of) \gls{model} \glspl{output} 
  		combined with auxiliary information such as a person’s name \cite{Fredrikson2015} (see Fig.\ \ref{fig_model_inv_dict}).
  		\begin{figure}[H]
			\begin{center}
			\begin{tikzpicture}[scale=1.5]
  			% Axes
  			\draw[->] (-0.5,0) -- (5.5,0) node[right] {face image $\featurevec$};
  			\draw[->] (0,-0.2) -- (0,2.5) node[above] {name};
  			% Sigmoid-like curve
  			\draw[thick, domain=0.5:5, samples=100, smooth, variable=\x, name path=sigmoid] 
  			plot ({\x}, {2/(1 + exp(-3*(\x - 3)))});
  			%\node at (5.1, 0.2) {\small (e.g., face photo)};
  			% Highlight point
  			\def\xval{3}
  			\pgfmathsetmacro{\yval}{2/(1 + exp(-3*(\xval - 3)))}
  			% Ruler lines
  			\draw[dashed] (\xval,0) -- (\xval,\yval);
  			\draw[dashed] (0,\yval) -- (\xval,\yval);
  			% Filled circle
  			\filldraw[fill=blue!20, draw=blue] (\xval,\yval) circle (0.1);
  			\node[anchor=south east] at (-0.1,\yval) {\footnotesize ``Alexander Jung''};
  			% Axis labels with image
  			\node[anchor=north] at (\xval,-0.25) {\includegraphics[width=1cm]{assets/AlexanderJung.jpg}}; % Replace 'face.jpg' with your image
  			% Label on curve
  			\node[above right] at (4,2.2) {trained \gls{model} $\learnthypothesis$};
  			\end{tikzpicture}
			\end{center} 
			\caption{\Gls{model} inversion techniques implemented in the context of facial image \gls{classification}. \label{fig_model_inv_dict}}
		\end{figure}
  		See also: \gls{model}, \gls{privattack}, \gls{ml}, \gls{sensattr}, \gls{datapoint}, \gls{prediction}, \gls{classification}, \gls{gradient}, \gls{trustAI}, \gls{privprot}. },
	first={model inversion},
	type=mlsystems,
  	text={model inversion}
}

\newglossaryentry{API} 
{name={application programming interface (API)},
	description={An\index{application programming interface (API)} API is a formal mechanism that 
		allows software components to interact in a structured and modular way \cite{RestfulBook2013}.
		In the context of \gls{ml}, APIs are commonly used to provide access to a trained \gls{ml} \gls{model}. 
		Users—whether humans or machines—can submit the \gls{featurevec} of a \gls{datapoint} and receive 
		a corresponding \gls{prediction}. Suppose a trained \gls{ml} \gls{model} is defined 
		as $\widehat{\hypothesis}(\feature) \defeq 2 \feature + 1$. Through an API, a user 
		can input $\feature = 3$ and receive the \gls{output} $\widehat{\hypothesis}(3) = 7$ 
		without knowledge of the detailed structure of the \gls{ml} \gls{model} or its \gls{training}. 
		In practice, the \gls{model} is typically deployed on a server connected to the Internet. 
		Clients send requests containing \gls{feature} values to the server, which responds with 
		the computed \gls{prediction} $\widehat{\hypothesis}(\featurevec)$. APIs promote modularity 
		in \gls{mlsystem} design, i.e., one team can develop and train the \gls{model}, while another team
		handles integration and user interaction. Publishing a trained \gls{model} via an API also 
		offers practical advantages. For instance, the server can centralize computational resources that 
		are required to compute \glspl{prediction}. Furthermore, the internal structure of the \gls{model} remains 
		hidden—which is useful for protecting intellectual property or trade secrets. 
		However, APIs are not without \gls{risk}. Techniques such as \gls{modelinversion} can potentially reconstruct a 
		\gls{model} from its \glspl{prediction} using carefully selected \glspl{featurevec}.
			\\
		See also: \gls{ml}, \gls{model}, \gls{featurevec}, \gls{datapoint}, \gls{prediction}, \gls{feature}, \gls{modelinversion}.},
	first={application programming interface (API)},
	type=mlsystems,
	text={API}
}

\newglossaryentry{machineunlearning}
{name={machine unlearning},
	description={Consider an \gls{ml} method that learns a \gls{hypothesis} $\learnthypothesis$ 
		via \gls{erm} on a \gls{trainset} $\dataset$. The learned \gls{hypothesis} can 
		reveal information about $\dataset$, which is exploited by \glspl{privattack} such as 
		\gls{modelinversion}. Machine unlearning\index{machine unlearning} refers to techniques that 
		modify $\learnthypothesis$, so that it is harder to infer properties of individual 
		\glspl{datapoint} in $\dataset$ \cite{cao2015unlearning}. Machine unlearning helps 
		to meet legal requirements for \gls{privprot} in \glspl{aisystem} \cite{GDPR2016}. 
		\\
	 	See also: \gls{modelinversion}, \gls{privprot}, \gls{gdpr}. },
	first={machine unlearning},
	type=mlsystems,
	text={machine unlearning}
}

\newglossaryentry{membershipinferenceattack}
{name={membership inference attack}, 
	description={Consider an \gls{ml} method that learns a \gls{hypothesis} 
		via \gls{erm} on a \gls{trainset}. Membership \gls{inference}\index{membership inference attack} 
                \gls{attack} is a form of \gls{privattack} where an adversary tries 
		to determine whether a particular \gls{datapoint} was part 
		of the \gls{trainset}. The attacker typically queries 
		$\learnthypothesis$ with candidate \glspl{featurevec} 
		$\featurevec^{(1)},\,\ldots,\,\featurevec^{(\nrbootstraps)}$, 
		and infers the membership status of a given \gls{datapoint} 
		based on the \glspl{prediction} $\learnthypothesis\big(\featurevec^{(1)}\big),\,\ldots,
		\,\learnthypothesis\big(\featurevec^{(\nrbootstraps)}\big)$ \cite{Shokri2017}.
		\\ 
		See also: \gls{attack}, \gls{privattack}.}, 
 	first={membership inference attack}, 
	type=mlsystems,
 	text={membership inference attack}
}

\newglossaryentry{backdoor}
{name={backdoor}, 
 	description={A\index{backdoor} backdoor \gls{attack} refers to the intentional 
 		manipulation of an \gls{ml} \gls{training} process. The attacker 
 		might perturb the \gls{trainset} (i.e., through \gls{datapoisoning}) 
 		or the \gls{optmethod} used by an \gls{erm}-based method. 
 		The goal of a backdoor \gls{attack} is to nudge the learned \gls{hypothesis} $\learnthypothesis$ 
 		toward specific \glspl{prediction} for a certain subset $\mathcal{T} \subset \featurespace$ 
 		of the \gls{featurespace}. Any \gls{featurevec} $\featurevec \in \mathcal{T}$ 
 		serves as a key (or trigger) to unlock a backdoor, in the sense of delivering 
 		anomalous \glspl{prediction} (see Fig.\ \ref{fig_backdoor_dict}). The 
 		trigger pattern $\mathcal{T}$ and corresponding anomalous \gls{prediction} 
 		$\learnthypothesis(\featurevec)$, for $\featurevec \in \mathcal{T}$, 
 		are only known to the attacker.
		\begin{figure}[H]
 			\begin{center}
 			\begin{tikzpicture}[>=Stealth, every node/.style={font=\small}]
 				% axes
 				\draw[->] (0,0) -- (7.5,0) node[right] {$\featurevec$};
 				\draw[->] (0,0) -- (0,4.2);
 				% trigger region shading
 				\fill[red!10] (3.8,0) rectangle (5.2,4.0);
 				\draw[dashed, red!60] (3.8,0) -- (3.8,4.0);
 				\draw[dashed, red!60] (5.2,0) -- (5.2,4.0);
 				\node[red!70] at (4.5,-0.35) {$\mathcal{T}$};
 				% data points
 				\foreach \x/\y in {0.5/0.6, 1.2/1.1, 2.0/1.8, 2.8/2.3, 5.5/3.5, 6.0/3.9}
 				\filldraw[black] (\x,\y) circle (2pt);
 				% clean model (blue line) — extended further right for label separation
 				\draw[blue, thick] (0.2,0.35) -- (7.2,4.65)
 				node[right, blue] {$\learnthypothesis$};
 				% backdoored model (red): same slope, jumps in trigger region
 				\draw[red, thick] (0.2,0.35) -- (3.8,2.55);
 				\draw[red, thick] (3.8,3.65) -- (5.2,4.20);
 				\draw[red, thick] (5.2,2.95) -- (6.3,4.05)
 				node[left=6pt, below=4pt, red] {$\widetilde{\hypothesis}$};
 				% jump markers
 				\draw[red, thick] (3.8,2.55) -- (3.8,3.65);
 				\draw[red, thick] (5.2,4.20) -- (5.2,2.95);
 			\end{tikzpicture}
 			\end{center}
 		\caption{Backdoor \gls{attack}: The black dots are \glspl{datapoint} from a trusted
 			source, none of which fall inside the trigger region $\mathcal{T}$.
 			The clean \gls{hypothesis} $\learnthypothesis$ (blue) fits these \glspl{datapoint}
 			well, while the backdoored \gls{hypothesis} $\widetilde{\hypothesis}$ (red)
 			agrees with $\learnthypothesis$ outside $\mathcal{T}$ but produces
 			anomalous \glspl{prediction} within it. \label{fig_backdoor_dict}}
 		\end{figure}
 		Outside $\mathcal{T}$, the backdoored \gls{hypothesis} is indistinguishable
 		from the clean one, making the \gls{attack} difficult to detect from
 		standard \gls{model} evaluation on uncontaminated \glspl{datapoint}.
 				\\
 		See also: \gls{attack}, \gls{datapoisoning}.},
 	first={backdoor},
	type=mlsystems,
 	text={backdoor} 
}

\newglossaryentry{modelpoisoning}
{name={model poisoning}, 
sort={modelpoisoning}, 
	description={\Gls{model}\index{model poisoning} poisoning refers to the intentional 
		manipulation of the \gls{training} process of an \gls{ml} \gls{model}. 
		In particular, within \glspl{flsystem} or other distributed \gls{ml} settings, 
		an attacker can manipulate the \gls{modelparam} updates sent by a subset of 
		the participating nodes to a central server, thereby corrupting the aggregated 
		global \gls{model} \cite{FLARE2022}. In contrast to \gls{datapoisoning}, which 
		corrupts the \gls{trainset}, model poisoning directly targets the 
		\gls{modelparam} aggregation step.
				\\
		See also: \gls{datapoisoning}, \gls{attack}, \gls{backdoor}, \gls{dosattack}, \gls{trustAI}.},
	first={model poisoning},
	type=mlsystems,
	text={model poisoning} 
}

\newglossaryentry{datapoisoning}
{name={data poisoning}, 
	description={\Gls{data}\index{data poisoning} poisoning refers to the intentional 
		manipulation (or fabrication) of \glspl{datapoint} to maliciously 
		steer the \gls{training} of an \gls{ml} \gls{model} \cite{Liu2021}, \cite{PoisonGAN}. 
  		\Gls{data} poisoning \glspl{attack} take various forms, including 
		\gls{backdoor} and \glspl{dosattack}. A \gls{backdoor} \gls{attack} 
		implants triggers into \gls{training} \gls{data}, so that the trained \gls{model} 
		behaves normally for typical \glspl{datapoint} but misclassifies a 
		\gls{datapoint} with a \gls{featurevec} that contains a trigger pattern.
  		A \gls{dosattack} aims at having the trained \gls{model} to perform 
		poorly over a significant region of the \gls{featurespace}. 
		\Gls{data} poisoning is particularly harmful in decentralized or 
		distributed \gls{ml} settings (such as \gls{fl}), where the 
		trustworthiness of \gls{data} sources cannot be verified easily.
				\\
		See also: \gls{attack}, \gls{backdoor}, \gls{dosattack}, \gls{trustAI}.},
	type=mlsystems,
	first={data poisoning},
	text={data poisoning} 
}

\newglossaryentry{messagepassing}
{name={message passing},
	description={Message passing\index{message passing} is a communication paradigm
		in which \glspl{device} exchange information by sending and receiving
		messages over a network \cite{LynchDistributedAlgorithms}.
		In an \gls{mlsystem} with \glspl{device} $\nodes = \{1,\,\ldots,\,\nrnodes\}$,
		each \gls{device} $\nodeidx$ sends a message to its \glspl{neighbor}
		$\nodeidx' \in \neighbourhood{\nodeidx}$ and updates its local \gls{state}
		based on the messages received. The messages can carry, for example,
		\glspl{modelparam} or their updates, or \glspl{prediction} on a \gls{dataset}.
		In contrast to shared-memory systems, where \glspl{device} communicate by
		reading and writing a common memory space, message passing requires no
		shared memory and is therefore well suited to \glspl{mlsystem} whose
		\glspl{device} are connected only by a \gls{commnetwork} \cite{LynchDistributedAlgorithms}, \cite{DistributedSystems}.
		\\
		See also: \gls{distributedalgorithm}, \gls{device}, \gls{flsystem}, \gls{modelparam}.},
	type=mlsystems,
	first={message passing},
	text={message passing}
}

\newglossaryentry{flsystem}
{name={federated learning system (FL system)},
	description={An \gls{fl} system\index{federated learning system (FL system)} is a 
		distributed \gls{mlsystem} in which multiple computational \glspl{device} 
		collaborate to train \gls{ml} \glspl{model} without sharing their raw local \gls{data}.
		An \gls{fl} system is characterized by a \gls{commnetwork} that specifies 
		which \glspl{device} can exchange information. Conceptually, an \gls{fl} system is 
		distinct from an \gls{fl} \gls{algorithm} \cite{DistributedSystems}. The system 
		specifies the participating entities, their interconnections, and execution constraints, while the \gls{algorithm} 
		specifies the update rules for local and global \glspl{modelparam} \cite{LynchDistributedAlgorithms}, \cite{KnuthAlgoBook}.
		Typical information exchanged in an \gls{fl} system includes 
		\glspl{modelparam} or \gls{gradient} information, but not raw \gls{data}.
		\\
		See also: \gls{fl}, \gls{mlsystem}, \gls{algorithm}, \gls{flnetwork}.},
 	type=mlsystems,
 	first={federated learning system (FL system)},
 	text={FL system},
 	firstplural={federated learning systems (FL systems)},
 	plural={FL systems}
}

\newglossaryentry{checkpoint}
{name={checkpoint},
	description={A checkpoint\index{checkpoint} is a saved representation 
   		of the \gls{state} of a running computation \cite{Elnozahy2002}.
 		In an \gls{mlsystem}, a checkpoint typically includes the current \glspl{modelparam} 
		during \gls{model} \gls{training} \cite{Abadi2016}.
		\\
		See also: \gls{state}, \gls{training}. },
	first={checkpoint},
	plural={checkpoints},
	firstplural={checkpoints},
	type=mlsystems,
	plural={checkpoints}
}

\newglossaryentry{checkpointing}
{name={checkpointing},
	description={Checkpointing\index{checkpointing} is a fault-tolerance mechanism
		that periodically creates \glspl{checkpoint} by saving the \gls{state} 
		of a running computation to persistent storage. Checkpointing is essential 
		for fault-tolerant executions on revocable resources
		such as \glspl{spotinstance} \cite{Elnozahy2002}, \cite{Mazzucco2011}.
		\\
		See also: \gls{checkpoint}, \gls{spotinstance}. },
	first={checkpointing},
	type=mlsystems,
	text={checkpointing}
}

\newglossaryentry{longitudinaldata}
{name={longitudinal data},
	description={Longitudinal \gls{data}\index{longitudinal data} consist of \glspl{datapoint} 
		whose attributes are measured repeatedly over time \cite{fitzmaurice2011applied}. 
		In \gls{ml}, longitudinal \gls{data} are common in applications such 
		as health care, where patient measurements are taken at multiple time points \cite{Mallinckrodt:2017aa}.
		\\
		See also: \gls{data}, \gls{datapoint}. }, 
	first={longitudinal data},
	type=mlsystems,
	text={longitudinal data}
}

\newglossaryentry{crosssectionaldata}
{name={cross-sectional data},
	description={Cross-sectional \gls{data}\index{cross-sectional data} consist of 
		\glspl{datapoint} whose attributes are measured once, without explicitly 
		modeling temporal evolution \cite{Wooldridge2025}. In \gls{ml}, 
		cross-sectional \gls{data} arise in image classification, 
		where each image is treated as an individual \gls{datapoint} \cite{hastie01statisticallearning}.
		\\
		See also: \gls{data}, \gls{datapoint}. },
	first={cross-sectional data},
	type=mlsystems,
	text={cross-sectional data}
}

\newglossaryentry{staleness}
{name={staleness},
	description={In a distributed \gls{mlsystem} (e.g., an \gls{flsystem}), staleness\index{staleness} refers to 
		the degree to which a copy of \glspl{modelparam} is outdated 
		\cite{ParallelDistrBook}, \cite{JungFLBook}, \cite{Coulouris2012}. 
		Consider two \glspl{device} $\nodeidx$ and $\nodeidx'$ within a distributed \gls{mlsystem}. 
		Suppose that at global time instant $\timeidx$, node $\nodeidx$ uses the \glspl{modelparam} 
		$\localparams{\nodeidx'}$ computed by node $\nodeidx'$ at time instant 
		$s^{(\timeidx)}_{\nodeidx,\nodeidx'} \le \timeidx$. The staleness of $\localparams{\nodeidx'}$ 
		can then be quantified by the delay 
		\[
			\timeidx -s^{(\timeidx)}_{\nodeidx,\nodeidx'}.
		\]
		\Glspl{distributedalgorithm} can be categorized by the amount 
		of staleness they can tolerate \cite{ParallelDistrBook}. 
		\\
		See also: \gls{flsystem}, \gls{distributedalgorithm}. },
	first={staleness},
	type=mlsystems,
	text={staleness}
}

\newglossaryentry{earlyexit}
{name={early exit (deep learning)},
	description={Early exit methods\index{early exit} refer to 
		computational strategies for evaluating the \gls{prediction} of a 
		\gls{deepnet}. The idea is to terminate \gls{inference} before evaluating 
		all \glspl{layer} of a \gls{deepnet} \cite{Teerapittayanon2016}.
		\\
		See also: \gls{prediction}, \gls{deepnet}, \gls{inference}.}, 
	first={early exit},
	plural={early exits},
	firstplural={early exits},
	type=mlsystems,
	text={early exit}
}

\newglossaryentry{spotinstance}
{name={spot instance},
	description={A spot instance\index{spot instance} is a 
		type of \gls{cloudcomputing} service that 
		provides computational resources at a reduced cost but 
		without guarantees on availability \cite{Mazzucco2011}.
		In particular, a spot instance may be revoked by the provider 
		at any time, which requires the use of \gls{checkpointing} \cite{Khatua2013}.
		\\
		See also: \gls{cloudcomputing}, \gls{checkpointing}. }, 
	first={spot instance},
	type=mlsystems,
	text={spot instance},
	firstplural={spot instances},
	plural={spot instances}
}

\newglossaryentry{cloudcomputing}
{name={cloud computing},
	description={Cloud computing\index{cloud computing} is a computing paradigm in which 
		computational resources such as processing, storage, and networking are provided 
		as on-demand services over a \gls{commnetwork}
		\cite{DistributedSystems}, \cite{ComerCloudComputing2021}, \cite{Armbrust2010}. 
		In \gls{ml}, cloud computing systems are commonly used to host large \glspl{dataset} 
		and to execute \gls{ml} \glspl{algorithm}. In contrast to \glspl{flsystem}, cloud 
		computing typically centralizes \gls{data} and computation within provider-managed 
		\gls{data} centers.
		\\
		See also: \gls{flsystem}, \gls{mlsystem}.},
	type=mlsystems,
	first={cloud computing},
	text={cloud computing}
}

\newglossaryentry{mlaas}
{name={machine learning as a service (MLaaS)},
	description={MLaaS\index{machine learning as a service (MLaaS)} refers to a 
		\gls{cloudcomputing} service \gls{model} in which \gls{ml} 
		capabilities are provided to users via standardized network interfaces. 
		In this \gls{model}, the cloud provider manages the underlying computing 
		infrastructure, \gls{data} storage, and software platforms, while users 
		access functionality such as \gls{model} \gls{training} and \gls{inference} 
		without direct control over physical resources \cite{ComerCloudComputing2021}.
				 \\
		See also: \gls{cloudcomputing}, \gls{mlsystem}.},
	type=mlsystems,
	first={machine learning as a service (MLaaS)},
	text={MLaaS}
}

\newglossaryentry{mcp}
{name={Model Context Protocol (MCP)},
	description={The MCP\index{Model Context Protocol (MCP)}
		is an open specification for the communication between \gls{llm}-based
		\glspl{aisystem} and different \gls{data} sources \cite{MCPSpec2025}.
		It follows a client--server architecture involving three roles: 
		\begin{enumerate}[label=\arabic*)]
			\item An MCP host is an \gls{aisystem} that embeds an \gls{llm} and 
			initiates MCP connections.
			\item An MCP client is a component within the host that maintains
			a dedicated connection to a single MCP server.
			\item An MCP server is a \gls{device} that exposes capabilities
			to clients through the following standardized primitives:
			resources (structured \gls{data}, e.g., files or database records),
			tools (callable functions the \gls{llm} can invoke, e.g.,
			to search the web or execute code), and prompts (reusable prompt templates).
		\end{enumerate}
		Servers and clients can communicate, for example, over \gls{http}.
		\\
		See also: \gls{llm}, \gls{agent}, \gls{mlpipeline}, \gls{mlaas}.},
	type=mlsystems,
	first={Model Context Protocol (MCP)},
	text={MCP}
}

\newglossaryentry{http}
{name={Hypertext Transfer Protocol (HTTP)},
	description={HTTP\index{Hypertext Transfer Protocol (HTTP)} is an application-layer\linebreak 
		protocol for transferring \gls{data} over a \gls{commnetwork} \cite{Coulouris2012}.
		HTTP follows a client--server model in which a client sends a request
		(e.g., to retrieve or submit \gls{data}) and a server returns a response.
		In \gls{ml}, HTTP is commonly used to expose \gls{inference} services,
		as in \gls{mlaas}, and to implement application-level protocols such as the \gls{mcp}.
		\\
		See also: \gls{mlaas}, \gls{mcp}, \gls{mlsystem}.},
	type=mlsystems,
	first={Hypertext Transfer Protocol (HTTP)},
	text={HTTP}
}

\newglossaryentry{apiendpoint}
{name={application programming interface endpoint (API endpoint)},
	description={An \gls{API} endpoint\index{application programming interface endpoint (API endpoint)} 
		is a specific address within an \gls{API} at which a particular function or resource can be accessed
		\cite{RestfulBook2013}.
		In practice, an endpoint is identified by a network address (e.g., URL) and a
		\gls{http} method (e.g., \texttt{POST /predict}), and specifies the format
		of the accepted input and the returned \gls{output}.
		A single \gls{API} may expose multiple endpoints for different purposes.
		In \gls{ml}, a typical server exposes an \gls{inference} endpoint
		that accepts the \gls{featurevec} $\featurevec$ of a \gls{datapoint}
		and returns the \gls{prediction} $\widehat{\hypothesis}(\featurevec)$
		of a trained \gls{model} without revealing its internal structure.	
		Additional endpoints may expose functionality such as \gls{model} \gls{training}
		or \gls{validation}.
		\\
		See also: \gls{API}, \gls{http}, \gls{inference}, \gls{prediction}, \gls{model}, \gls{mlaas}.},
	type=mlsystems,
	first={application programming interface endpoint (API endpoint)},
	text={API endpoint},
	plural={API endpoints},
	firstplural={application programming interface endpoints (API endpoints)}
}

\newglossaryentry{dynamicalsystem}
{name={dynamical system},
	description={A dynamical system\index{dynamical system} is an abstract system whose 
		\gls{output} depends on an internal \gls{state} that evolves over time 
		according to a \gls{state}-update rule \cite{StrogatzBook}. In discrete time, 
		a dynamical system is commonly described by an \gls{iteration} of the form 
		$\vs^{(\timeidx+1)} =\fixedpointop \vs^{(\timeidx)}$, where $\vs^{(\timeidx)}$ 
		denotes the \gls{state} at time $\timeidx$ and $\fixedpointop$ is 
		a \gls{state}-transition \gls{map}. In continuous time, dynamical systems 
		are described by differential equations.
		\\
		See also: \gls{output}, \gls{state}. },
	first={dynamical system},
	text={dynamical system},
	type=mlsystems,
	plural={dynamical systems}, 
	firstplural={dynamical systems}
}

\newglossaryentry{edgecomputing}
{name={edge computing},
	description={Edge computing\index{edge computing} refers to the placement of
		computation and \gls{data} storage close to the sources of \gls{data} generation,
		such as sensors, \glspl{mobiledevice}, or embedded systems, rather than in
		centralized \gls{data} centers \cite{Shi2016}. 
		In \gls{ml}, edge computing supports low-latency \gls{inference} and reduced
		communication by executing parts of \gls{ml} \glspl{algorithm} on or near
		\gls{data}-generating \glspl{device} \cite{Nguyen2019}. 
		\\
		See also: \gls{cloudcomputing}, \gls{flsystem}, \gls{mlsystem}.},
	type=mlsystems,
	first={edge computing},
	text={edge computing}
}

\newglossaryentry{edgedevice}
{name={edge device},
	description={An edge \gls{device}\index{edge device} operates at or 
		near the edge of a \gls{commnetwork} \cite{Shi2016}. The term edge refers 
		to the periphery of the network, where \gls{data} is produced and first processed.
		In \gls{ml}, and in particular in \gls{fl}, an edge \gls{device} 
		typically corresponds to a node of an \gls{flnetwork}. Each edge \gls{device} 
		stores local \gls{data} and implements parts of the \gls{mlpipeline}, 
		such as \gls{data} \gls{preprocessing}, \gls{localmodel} \gls{training}, 
		or \gls{inference} \cite{Hashash2021}. 
		\\ 
		See also: \gls{device}, \gls{edgecomputing}.},
	type=mlsystems,
	first={edge device},
	plural={edge devices},
	firstplural={edge devices},
	text={edge device}
}

\newglossaryentry{preprocessing}
{name={preprocessing},
	description={Preprocessing\index{preprocessing} refers to the set of operations
		applied to raw \gls{data} before they are fed into an \gls{ml} \gls{algorithm} \cite{hastie01statisticallearning}. 
		The goal of preprocessing is to transform the \gls{data} into a form
		that is more suitable for follow-up stages of an \gls{mlpipeline}. 
		Typical preprocessing steps include cleaning corrupted or missing values,
		normalizing or scaling \glspl{feature}, or encoding categorical variables \cite{MLPipeline}. 
		\\
		See also: \gls{data}, \gls{mlpipeline}, \gls{feature}.},
	first={preprocessing},
	type=mlsystems,
	text={preprocessing}
}

\newglossaryentry{mlpipeline}
{name={machine learning pipeline (ML pipeline)},
	description={The term ML pipeline\index{machine learning pipeline (ML pipeline)} refers to a composition (i.e., concatenation)
		of several \glspl{function} within an \gls{mlsystem}. The individual \glspl{function} 
		include \gls{data} \gls{preprocessing}, \gls{featlearn}, \gls{model} \gls{training}, and \gls{inference}. 
		By combining them, an \gls{mlsystem} turns raw \gls{data} into \glspl{prediction} \cite{MLPipeline}.  
		\\
		See also: \gls{function}, \gls{mlsystem}.},
	first={machine learning pipeline (ML pipeline)},
	type=mlsystems,
	text={ML pipeline},
	plural={machine learning pipelines (ML pipelines)},
	firstplural={ML pipelines}
}

\newglossaryentry{mobiledevice}
{name={mobile device},
	description={A mobile \gls{device}\index{mobile device} is a portable computing
		\gls{device} equipped with computational, storage, sensing, and wireless
		communication capabilities \cite{Lane2015}, \cite{Tsoukas2024}. 
		Examples of mobile \glspl{device} include smartphones, tablets, 
		or wearables. Mobile \glspl{device} can act as \gls{data} sources 
		and provide computational infrastructure for \gls{edgecomputing} 
		or \glspl{flsystem}.
		\\
		See also: \gls{edgecomputing}, \gls{flsystem}, \gls{mlsystem}.},
	type=mlsystems,
	first={mobile device},
	plural={mobile devices},
	firstplural={mobile devices},
	text={mobile device}
}

%federated learning (system view, not algorithmic variants)

%parameter server

%client–server architecture

%orchestration

%asynchronous updates

%data locality

%deployment

%inference service

%scalability

%resource heterogeneity