Linked.Archi ML-Enabled Systems Extension
type: Ontology
imports: core#
license: http://creativecommons.org/licenses/by/4.0/
preferred namespace prefix: mlsys
creator: Kalin Maldzhanski
description: Extension ontology for modeling ML-enabled system architectures. Provides element types, relationship types, stakeholders, concerns, and viewpoints for describing the ML aspects of software systems — training pipelines, model serving, feature engineering, data lineage, and the integration boundary between ML and non-ML components. Motivated by the gap identified in Moin et al. (2023): existing architecture frameworks lack stakeholders, viewpoints, and model kinds for data scientists, data engineers, and ML engineers. This extension addresses that gap within the Linked.Archi ecosystem.
abstract: Ontology for modeling ML-enabled system architectures within the Linked.Archi ecosystem.
created: 2026-05-03
modified: 2026-05-03
publisher: Linked.Archi
publisher: linked.archi
status: draft
version IRI: 0.1.0#
version info: 0.1.0
source: https://arxiv.org/abs/2308.05239
citation: Linked.Archi ML-Enabled Systems Extension

Data Scientist
type: Stakeholder
definition: Responsible for analytics modeling — selecting algorithms, engineering features, training ML models, and evaluating model performance using metrics such as accuracy, precision, recall, and F1 score. Data scientists work primarily with mathematical formalisms, statistical models, and computational graphs.
scope note: Identified by Moin et al. (2023) as a missing stakeholder in existing architecture frameworks. Their concerns include ML model accuracy, feature quality, algorithm selection, and model interpretability.
source: https://arxiv.org/abs/2308.05239

Data Engineer
type: Stakeholder
definition: Responsible for analytics operations — building and maintaining data pipelines, ensuring scalable data processing, deploying trained models into production, and managing the infrastructure for model serving and monitoring.
scope note: Identified by Moin et al. (2023) as a missing stakeholder. Their concerns include data pipeline reliability, model deployment automation, serving latency, and infrastructure scalability.
source: https://arxiv.org/abs/2308.05239

ML Engineer
type: Stakeholder
definition: Bridges data science and software engineering — productionizing ML models, managing model serving infrastructure, implementing monitoring and retraining pipelines, and ensuring ML components integrate correctly with non-ML system components.
scope note: Recognized by Muccini & Vaidhyanathan (2021) and Lewis et al. (2021) as a distinct role in ML-enabled system development.
source: WAIN52551.2021.00026

Ethics Committee / Officer
type: Stakeholder
definition: Responsible for evaluating the ethical, legal, and social implications (ELSI) of ML-enabled systems — including fairness, bias, explainability, privacy, and trustworthiness of ML components.
scope note: Identified by Moin et al. (2023) as a stakeholder whose concerns are not addressed by existing architecture frameworks.
source: https://arxiv.org/abs/2308.05239

ML Model Performance
type: Concern
definition: ML-specific performance metrics — accuracy, precision, recall, F1 score, AUC-ROC, mean squared error, and other evaluation metrics that measure how well an ML model performs its inference task on unseen data.
scope note: Distinct from system performance (latency, throughput). A model may have excellent ML performance but introduce unacceptable latency, or vice versa.

Data Quality
type: Concern
definition: Completeness, correctness, timeliness, representativeness, and consistency of data used for training, validation, and inference. Poor data quality directly degrades model performance and can introduce bias.

Model Drift
type: Concern
definition: Degradation of model performance over time due to changes in the underlying data distribution (data drift) or changes in the relationship between features and targets (concept drift). Requires monitoring and retraining strategies.

Explainability
type: Concern
definition: The ability to understand, interpret, and communicate why an ML model produces specific predictions. Critical for regulatory compliance (e.g., GDPR right to explanation), stakeholder trust, and debugging.

Fairness & Bias
type: Concern
definition: Ensuring ML models do not systematically discriminate against individuals or groups based on protected attributes (race, gender, age, etc.). Includes detection and mitigation of bias in training data and model outputs.

Adversarial Robustness
type: Concern
definition: Resilience of ML models against adversarial attacks — deliberate manipulation of inputs or training data to cause incorrect predictions. Includes evasion attacks, data poisoning, and model extraction.
scope note: Moin et al. (2023) note that software engineers often underestimate the vulnerability of ML-enabled systems through adversarial attacks.
source: https://arxiv.org/abs/2308.05239

ML Artifact Versioning
type: Concern
definition: Tracking versions of ML artifacts — trained models, model parameters and hyperparameters, training datasets, feature definitions, and pipeline configurations. Essential for reproducibility and auditability.

ML Monitorability
type: Concern
definition: Runtime monitoring of ML components — prediction distributions, feature distributions, serving latency, model staleness, and data pipeline health. Enables detection of drift, degradation, and anomalies.
scope note: Lewis et al. (2021) identify monitorability as a new quality attribute concern specific to ML-enabled systems.

ML Privacy
type: Concern
definition: Privacy challenges specific to ML — training data memorization, model inversion attacks, membership inference, and compliance with data protection regulations (GDPR, CCPA) in the context of ML pipelines.

ML–SE Collaboration
type: Concern
definition: The challenge of coordinating work between data science and software engineering teams — different vocabularies, tools, workflows, and quality metrics. The "ML Mismatch" problem identified by Lewis et al. (2021).
source: WAIN52551.2021.00026

ML Component
type: Class
subclass of: Element
definition: An abstract base class for all ML-specific architectural elements. ML components are software artifacts with special characteristics: their behavior is inferred from data rather than specified at design time, they require retraining, and they have distinct lifecycle and versioning needs.
scope note: Moin et al. (2023) argue that ML artifacts deserve separate identity, distinguished from software source code and raw data.
source: https://arxiv.org/abs/2308.05239

ML Model
type: Class
subclass of: ML Component
definition: A trained machine learning model — the core artifact produced by the data science workflow. Includes the model architecture (e.g., neural network topology, decision tree structure), trained parameters, and associated metadata (training date, dataset version, performance metrics).
scope note: Not to be confused with arch:Model (an architecture description) or data models (database schemas). An MLModel is a computational artifact that performs inference on data.

Training Pipeline
type: Class
subclass of: ML Component
definition: The end-to-end automated process for training an ML model — from data ingestion and preprocessing through feature engineering, model training, evaluation, and model registration. Typically orchestrated by tools like Kubeflow, MLflow, or Airflow.

Serving Infrastructure
type: Class
subclass of: ML Component
definition: Infrastructure for serving ML model predictions at runtime — model servers (TensorFlow Serving, Triton, Seldon), API endpoints, batch prediction jobs, and edge deployment runtimes.

Feature Store
type: Class
subclass of: ML Component
definition: A centralized repository for storing, managing, and serving ML features. Provides consistent feature definitions across training and serving, feature versioning, and point-in-time correctness for training data.

Dataset
type: Class
subclass of: ML Component
definition: A versioned collection of data used for training, validation, or evaluation of ML models. Carries metadata about provenance, schema, quality metrics, and applicable data governance policies.
scope note: Distinct from database entities (data models). A Dataset is a curated, versioned snapshot used in the ML lifecycle.

ML Monitoring Component
type: Class
subclass of: ML Component
definition: A component responsible for monitoring ML model behavior in production — tracking prediction distributions, detecting data drift and concept drift, alerting on performance degradation, and triggering retraining workflows.

Experiment Tracker
type: Class
subclass of: ML Component
definition: A component for tracking ML experiments — recording hyperparameters, metrics, artifacts, and code versions for each training run. Enables reproducibility and comparison across experiments.

Model Registry
type: Class
subclass of: ML Component
definition: A versioned catalog of trained ML models with their metadata, lineage, performance metrics, and deployment status. The single source of truth for which models are approved for production.

Data Pipeline
type: Class
subclass of: ML Component
definition: An automated workflow for ingesting, transforming, validating, and delivering data to downstream consumers (training pipelines, feature stores, analytics systems). Distinct from TrainingPipeline in that it handles raw data processing rather than model training.

trained on
type: ObjectProperty
definition: Links an ML model to the dataset it was trained on.
domain includes: ML Model
range includes: Dataset

produces model
type: ObjectProperty
definition: Links a training pipeline to the ML model it produces.
domain includes: Training Pipeline
range includes: ML Model

serves
type: ObjectProperty
definition: Links serving infrastructure to the ML model it serves for inference.
domain includes: Serving Infrastructure
range includes: ML Model

monitors
type: ObjectProperty
definition: Links a monitoring component to the ML component it monitors.
domain includes: ML Monitoring Component
range includes: ML Component

feeds features
type: ObjectProperty
definition: Links a feature store to the training pipeline or serving infrastructure it provides features to.
domain includes: Feature Store
range includes: Training Pipeline
range includes: Serving Infrastructure

registered in
type: ObjectProperty
definition: Links an ML model to the model registry where it is cataloged.
domain includes: ML Model
range includes: Model Registry

consumes data
type: ObjectProperty
definition: Links a data pipeline to the data source it ingests from.
domain includes: Data Pipeline
range includes: Element

produces dataset
type: ObjectProperty
definition: Links a data pipeline to the dataset it produces.
domain includes: Data Pipeline
range includes: Dataset

integrates with
type: ObjectProperty
definition: Links an ML component to a non-ML component it integrates with. This is the critical boundary identified by Moin et al. — the interface between ML and traditional software components.
domain includes: ML Component
range includes: Element

triggers retraining
type: ObjectProperty
definition: Links a monitoring component to the training pipeline it triggers when drift is detected.
domain includes: ML Monitoring Component
range includes: Training Pipeline

Trained On
type: Class
subclass of: QualifiedRelationship
unqualified form: trained on
definition: A qualified training relationship — carries metadata about training run, date, hyperparameters.
domain includes: ML Model
range includes: Dataset

Produces Model
type: Class
subclass of: QualifiedRelationship
unqualified form: produces model
definition: A qualified model production relationship — carries pipeline run metadata.
domain includes: Training Pipeline
range includes: ML Model

Integrates With
type: Class
subclass of: QualifiedRelationship
unqualified form: integrates with
definition: A qualified integration relationship between ML and non-ML components. Carries metadata about the integration contract: API format, latency SLA, data schema, and responsible team.
domain includes: ML Component
range includes: Element

Analytics Modeling
type: Viewpoint
definition: Frames the concerns of data scientists — model architecture, training pipelines, feature engineering, evaluation metrics, and algorithm selection. Views governed by this viewpoint show the ML model landscape: which models exist, what data they consume, how they are trained, and how they perform.
targets stakeholder: Data Scientist
targets stakeholder: ML Engineer
viewpoint frames concern: ML Model Performance
viewpoint frames concern: Data Quality
viewpoint frames concern: Explainability
viewpoint frames concern: Fairness & Bias
viewpoint has purpose: Designing
includes concept: ML Model
includes concept: Training Pipeline
includes concept: Dataset
includes concept: Feature Store
includes concept: Experiment Tracker
view type: Diagram
source: https://arxiv.org/abs/2308.05239

Analytics Operations
type: Viewpoint
definition: Frames the concerns of data engineers and ML engineers — model deployment, serving infrastructure, monitoring, retraining pipelines, and operational health. Views governed by this viewpoint show the MLOps landscape: how models move from training to production and how they are maintained.
targets stakeholder: Data Engineer
targets stakeholder: ML Engineer
viewpoint frames concern: Model Drift
viewpoint frames concern: ML Monitorability
viewpoint frames concern: ML Artifact Versioning
viewpoint has purpose: Designing
viewpoint has purpose: Governing
includes concept: Serving Infrastructure
includes concept: ML Monitoring Component
includes concept: Model Registry
includes concept: Data Pipeline
includes concept: Training Pipeline
view type: Diagram
source: https://arxiv.org/abs/2308.05239

ML System Integration
type: Viewpoint
definition: Shows how ML components integrate with non-ML components — the boundary that Moin et al. identify as the key collaboration challenge. Views governed by this viewpoint show integration contracts, data flows, latency budgets, and team responsibilities at the ML/SE boundary.
targets stakeholder: Data Scientist
targets stakeholder: Data Engineer
targets stakeholder: ML Engineer
viewpoint frames concern: ML–SE Collaboration
viewpoint has purpose: Designing
viewpoint has purpose: Informing
includes concept: ML Component
includes concept: Integrates With
view type: Diagram
view type: Matrix
source: https://arxiv.org/abs/2308.05239

ML Ethics & Compliance
type: Viewpoint
definition: Frames fairness, explainability, privacy, and regulatory compliance concerns for ML-enabled systems. Views governed by this viewpoint show which models handle sensitive data, what bias mitigation measures are in place, and compliance status with applicable regulations.
targets stakeholder: Ethics Committee / Officer
viewpoint frames concern: Fairness & Bias
viewpoint frames concern: Explainability
viewpoint frames concern: ML Privacy
viewpoint frames concern: Adversarial Robustness
viewpoint has purpose: Governing
includes concept: ML Model
includes concept: Dataset
view type: Matrix
view type: Catalog
source: https://arxiv.org/abs/2308.05239

ML Model Catalog
type: Viewpoint
definition: Inventory of all ML models with key attributes — owner, status, performance metrics, dataset lineage, deployment target, and monitoring status. The ML equivalent of a component catalog.
targets stakeholder: Data Scientist
targets stakeholder: Data Engineer
targets stakeholder: ML Engineer
viewpoint frames concern: ML Artifact Versioning
viewpoint frames concern: ML Model Performance
viewpoint has purpose: Informing
viewpoint has purpose: Governing
includes concept: ML Model
includes concept: Model Registry
view type: Catalog

has model version
type: DatatypeProperty
definition: The version identifier of a trained ML model.
domain: ML Model
range: string

has performance metric
type: DatatypeProperty
definition: A key performance metric value for an ML model (e.g., accuracy=0.94).
domain: ML Model
range: string

has model architecture
type: DatatypeProperty
definition: Description of the ML model architecture — e.g., 'ResNet-50', '3-layer LSTM', 'XGBoost with 500 trees'. This is the structural specification that data scientists use to communicate model design.
domain: ML Model
range: string

has framework
type: DatatypeProperty
definition: The ML framework used to build the model (e.g., TensorFlow, PyTorch, scikit-learn).
domain: ML Model
range: string

has retraining schedule
type: DatatypeProperty
definition: The schedule or trigger for retraining the model (e.g., 'weekly', 'on drift detection').
domain: ML Model
range: string

has serving latency SLA
type: DatatypeProperty
definition: The maximum acceptable latency for model inference (e.g., 'p99 < 100ms').
domain: Serving Infrastructure
range: string

has data lineage
type: ObjectProperty
definition: Links a dataset to its upstream data sources for provenance tracking.
domain: Dataset
range: Element

has monitoring plan
type: ObjectProperty
definition: Links an ML model to the monitoring component responsible for tracking its production behavior.
domain: ML Model
range: ML Monitoring Component