A Unified Architecture for Data, Trust, and Intelligence in Agrifood Systems: The METROFOOD-IT Platform

Abstract

The digital transformation of agrifood systems demands an integrated infrastructure to ensure traceability, trust, and intelligent decision-making across complex and heterogeneous value chains. METROFOOD-IT, a large-scale national research infrastructure in food metrology aligned with the ESFRI METROFOOD-RI, addresses these challenges by combining advanced experimental facilities with a comprehensive digital ecosystem. This paper focuses on the IT kernel of METROFOOD-IT and presents an integrated architectural model that brings together four key technological paradigms: data acquisition through Internet of Things (IoT) and laboratory infrastructures, an Open Data Platform for interoperability and sharing, blockchain-based notarization for integrity and provenance, and Artificial Intelligence (AI) for knowledge extraction and decision support. Rather than describing these components in isolation, the paper abstracts from their implementation within the Italian National Recovery and Resilience Plan (NRRP) project METROFOOD-IT to distill a coherent and reusable architectural pattern in which data management, trust enforcement, and intelligent analytics are tightly coupled. Five explicit design principles are identified and articulated: federated data with centralized metadata, selective on-chain anchoring, user-unobtrusive trust infrastructure, explainability as a first-class architectural concern, and machine learning as the backbone of decision-making. Two empirical case studies—one centered on explainable AI for hyperspectral crop nitrogen assessment and the other on IoT-driven sustainable agriculture monitoring secured by distributed ledger technology—serve a dual role: they motivate and shape the architectural pattern, and they exemplify the operational regimes the resulting design supports. A reference deployment on the Ethereum Sepolia public test network, grounded on an IBM Power E1050 and IBM Storage Scale enterprise substrate, provides quantitative evidence for the proposed hybrid on-chain/off-chain pattern with streaming hash-only notarization. The architecture illustrates how research infrastructures can evolve into integrated digital platforms that enable transparent, verifiable, and scalable agrifood systems, and offers a foundation for generalizable design principles in data-intensive and trust-sensitive settings.

1. Introduction

The agrifood sector is undergoing a profound transformation driven by increasing demands for transparency, traceability, sustainability, and quality assurance. From primary production to final consumption, stakeholders require reliable mechanisms to verify data authenticity, ensure compliance with standards, and support informed decision-making. These requirements are further amplified by regulatory pressures, globalized supply chains, and growing consumer awareness.

In this context, research infrastructures play a critical enabling role. They provide the scientific, technological, and organizational backbone for generating reliable and comparable data, supporting innovation, and enabling evidence-based decision-making across the agrifood ecosystem. METROFOOD-IT represents a major national effort in this direction. Funded as a multi-year initiative under the Italian National Recovery and Resilience Plan (NRRP), with a total investment of approximately €20 million, the project has enabled the implementation of the Italian research infrastructure METROFOOD-IT, which constitutes the national node of the broader European research infrastructure METROFOOD-RI, dedicated to metrology in food and nutrition and included in the European Strategy Forum on Research Infrastructures (ESFRI) Roadmap.

The project integrates physical and digital components into a unified ecosystem. On the physical side, it encompasses laboratories, experimental facilities, and measurement infrastructures supporting food analysis, quality control, and certification. On the digital side, it develops an advanced IT infrastructure to manage, validate, share, and exploit agrifood data at scale. The overarching objective is to support the traceability, authenticity, safety, and sustainability of food products while fostering innovation and interoperability among stakeholders.

Among its broader objectives, the project also aimed to develop best practices in the STEM and omics domains for the multidisciplinary integration of analytical capabilities essential to food safety processes, and to identify reusable design principles applicable to large-scale industrial contexts such as METROFOOD-IT. In doing so, it bridges experimental research, industrial deployment, and regulatory validation. This perspective provides a key motivation for the present work, which abstracts from the project implementation to distill an architectural model that can be generalized and reused.

Within this broader framework, a key role is played by the IT kernel of the METROFOOD-IT infrastructure, which is the focus of this paper. This kernel combines four main technological paradigms:

• IoT and experimental data acquisition infrastructures, enabling continuous and heterogeneous data collection from laboratories, sensors, and production environments;
• An Open Data Platform, ensuring data harmonization, interoperability, and controlled sharing;
• Blockchain and distributed ledger technologies (DLTs), providing integrity, provenance, and auditability guarantees;
• Artificial Intelligence and machine learning (AI/ML), transforming validated data into predictive, interpretable, and actionable knowledge.

Rather than treating these components as independent modules, METROFOOD-IT integrates them into a coherent architectural framework in which data acquisition, trust enforcement, and intelligent analytics are tightly coupled. The Open Data Platform serves as the backbone for data management and interoperability; the blockchain layer provides verifiable traceability through cryptographic anchoring; and the AI/ML layer enables advanced analytics and decision support.

This paper focuses on the design and integration of this IT architecture. It presents a unified model showing how the Open Data Platform, blockchain-based notarization, and AI/ML capabilities interact within a single system, bridging laboratory analysis, industrial processes, and consumer-level trust. Through this perspective, METROFOOD-IT is positioned not only as a data infrastructure but as a comprehensive platform for trustworthy and intelligent agrifood systems.

The contribution of this paper is the formulation of an integrated architectural model for agrifood research infrastructures that unifies data acquisition, trust enforcement, and intelligent analytics within a single coherent framework. While the individual technological ingredients—IoT, blockchain, AI—have been combined in prior agrifood frameworks, this paper distinguishes itself along four specific axes that, taken together, define its novel contribution. First, the architecture realizes a hybrid off-chain/on-chain design with streaming hash-only notarization specifically tailored to scientific data infrastructures, where individual artifacts may reach multi-gigabyte scale and where calldata-bound transaction costs would otherwise dominate. Second, it adopts a relayer-mediated transaction-signing model that decouples notarization from end-user wallet provisioning, removing what is otherwise a significant adoption barrier in multi-stakeholder consortia. Third, DLT-agnosticism is realized concretely through a compact and stable smart contract interface, exercised in the project across Ethereum, IOTA’s Tangle, and Hyperledger Fabric. Fourth, the architecture is positioned as a domain-specific connector within broader federated data space frameworks rather than as a replacement for them, providing the food metrology specialization that general-purpose data spaces such as GAIA-X, International Data Spaces, or the European Open Science Cloud (EOSC) do not natively offer. By abstracting from the implementation of the METROFOOD-IT platform, the paper identifies five reusable design principles that operationalize these contributions for coordinating Open Data platforms, blockchain-based notarization, and AI/ML pipelines in data-intensive and trust-sensitive domains. These principles are formally articulated in Section 9.

The case studies presented in this paper play a dual role with respect to the architecture. On the one hand, they predate the consolidation of the architectural pattern and were the empirical proving ground in which the relevant requirements, trade-offs, and design choices were first surfaced: in this sense, they are inputs that shaped the design rather than experimental validations of an already-completed system. On the other hand, they exemplify the two complementary operational regimes that the resulting design is intended to support—a batch-analytical regime centered on explainable AI and a continuous monitoring regime centered on high-frequency IoT data—and the architectural pattern reorganizes them within a single framework that now serves them through a common substrate. This bottom-up relationship between the case studies and the architecture is made explicit throughout the paper.

Methodologically, this mode of working aligns the paper with the design-science research paradigm, in which knowledge of a problem domain and its solution is acquired through the construction and application of artifacts rather than through the prior validation of a fully specified theory [1]. The artifact produced here is a reference architecture, and its derivation follows the spirit of empirically grounded reference architecture design, in which practice-proven building blocks observed in concrete systems are abstracted into a reusable architectural template whose validity rests on its empirical foundation [2]. The two case studies provide that empirical foundation; the five design principles of Section 9 are the abstraction.

The remainder of this paper is organized as follows. Section 2 reviews related work across three dimensions: data acquisition and digital traceability, decentralized trust and notarization, and intelligent decision support. Section 3 presents the overall system architecture. Section 4, Section 5 and Section 6 describe in detail the three layers of the IT kernel: the Open Data Platform, the blockchain notarization infrastructure, and the AI/ML layer, respectively. Section 7 discusses their integrated operation. Section 8 presents the two empirical case studies that informed the architectural design, illustrating in passing how the resulting framework now accommodates them. Section 9 articulates the five design principles distilled from this empirical experience. Section 10 reports on the reference deployment of the trust layer on the Ethereum Sepolia public test network, providing quantitative evidence on the transaction profile of the proposed hybrid pattern and on its sensitivity to artifact size, together with a comparative assessment of the DLT alternatives considered. Section 11 provides a critical discussion of strengths, limitations, and alternatives, including a qualitative evaluation of the architecture against its stated requirements. Section 12 concludes the paper and outlines future directions.

2. Related Work

The transition toward Agriculture 4.0 and 5.0 is characterized by the increasing need to manage, verify, and extract value from massive volumes of heterogeneous data generated across complex supply chains. In recent years, the convergence of the Internet of Things (IoT), blockchain technology, and Artificial Intelligence (AI) has emerged as a fundamental paradigm to address these challenges. While the previous literature has largely explored these technologies in isolation or in pairwise combinations, a growing body of work now recognizes their necessity for integration. We review the state of the art across three main dimensions: data acquisition and digital traceability, decentralized trust and notarization, and intelligent decision support.

2.1. Data Acquisition and Digital Traceability in Agrifood Systems

The foundation of modern agrifood architectures relies on robust data acquisition through IoT and sensor networks. Recent studies emphasize that the shift toward data-driven ecosystems requires not only data collection but also interoperable platforms capable of handling high-frequency, heterogeneous inputs. For instance, Safeer et al. [3] provide a comprehensive bibliometric analysis of how IoT underpins climate-smart agriculture, laying the groundwork for subsequent technological layers. In the context of horticulture, Huang and Li [4] systematically review the integration of edge–cloud–blockchain–terminal (ECBT) systems with IoT, highlighting the need to bridge physical sensor networks to cloud-based data structures to achieve true digital traceability. More broadly, Sebti et al. [5] review the convergence of RFID, IoT, blockchain, and AI for traceability and anti-counterfeiting across agrifood supply chains, framing the same four-technology stack addressed by the present work and reinforcing the case for the integrated architecture proposed here.

However, as highlighted by Almazmomi, while IoT enables real-time precision agriculture, it introduces severe challenges related to secure data sharing and interoperability [6]. This gap motivates the need for Open Data Platforms, as proposed in the METROFOOD-IT architecture, to serve as an operational backbone that harmonizes laboratory analyses, quality control data, and IoT metrics prior to their submission to trust or intelligence mechanisms.

2.2. Trust, Provenance, and Blockchain Notarization

As data are aggregated across multiple stakeholders, ensuring their integrity and provenance becomes paramount. Blockchain and distributed ledger technologies (DLTs) are increasingly adopted not merely as financial tools, but as scientific and industrial notarization mechanisms. Hema and Manickavasagan [7] review the implementation of blockchain for food safety, noting its critical role in providing immutable records that prevent food fraud and ensure compliance. Similarly, Tang et al. [8] assess the feasibility of combining blockchain and IoT, emphasizing that, while these technologies offer transformative transparency, their adoption often faces scalability and integration hurdles.

To overcome these scalability issues, the recent literature advocates for hybrid or ecosystemic approaches. Salzano et al. [9] outline the theoretical and practical advantages of integrating blockchain within broader information ecosystems, whereby decentralized business logic and selective data anchoring provide trust without overwhelming the network. Furthermore, Morchid et al. [10] and Pavithra et al. [11] demonstrate how the selective combination of IoT and blockchain optimizes resource management and traceability while mitigating the high costs associated with fully on-chain data storage. This aligns directly with the hybrid design of the METROFOOD-IT trust layer, which keeps heavy datasets off-chain while anchoring only cryptographic hashes.

2.3. Artificial Intelligence and Explainable Decision Support

The final dimension involves transforming validated, notarized data into actionable knowledge. AI and machine learning are increasingly applied to optimize agricultural operations and verify food authenticity. Liu et al. [12] and Femimol and Joseph [13] review the integration of AI with blockchain, demonstrating how smart contracts and predictive models can enhance food safety and quality control from farm to table. In precision forecasting, Sizan et al. [14] propose a triadic architecture in which machine learning models predict crop yields using IoT data secured via blockchain, ensuring that predictive insights are derived from tamper-proof inputs.

Furthermore, as agrifood systems evolve into “Smart Agriculture 5.0”, the role of AI is expanding to include human–AI symbiosis and uncertainty modeling, as explored by Jagan Mohan et al. [15] through reinforcement learning and blockchain synergy. Crucially, in regulated domains such as food metrology, the opacity of traditional AI models remains a significant barrier. As demonstrated in previous case studies on crop nitrogen assessment, models must be paired with explainability techniques (e.g., SHAP) to ensure their outputs are transparent and trustworthy for scientific and regulatory stakeholders [16].

By coordinating an Open Data Platform with selective blockchain-based notarization and explainable AI, the METROFOOD-IT architecture synthesized in this paper provides a unified response to the interdisciplinary challenges identified in the recent literature.

3. System Overview

Figure 1 presents the overall architecture of the METROFOOD-IT digital ecosystem. The model is organized into three tightly connected layers: the Open Data Platform, serving as the data and interoperability backbone; the blockchain layer, providing trust and notarization infrastructure; and the AI/ML layer, serving as the intelligence engine operating on validated data. The figure emphasizes the system’s hybrid nature, in which data remain primarily off-chain while cryptographic evidence and traceability anchors are recorded on-chain.

4. Open Data Platform

The Open Data Platform constitutes the foundational layer of the METROFOOD-IT architecture. Its primary function is to enable the ingestion, structured description, discovery, and controlled sharing of heterogeneous agrifood data assets across a diverse stakeholder base—including scientific laboratories, producing companies, certification bodies, monitoring agencies, and government institutions. Rather than imposing a centralized data format, the platform implements a federated data/centralized metadata design pattern in which data remain under the control of their originators while metadata are harmonized through a shared vocabulary and managed centrally (cf. Section 9.1).

4.1. Architecture and Technology Stack

The platform is built on a document-oriented technology stack centered on MongoDB (the deployed versions at the time of this paper are MongoDB v6.0, Angular v17, Flask v3.0 on Python 3.11; the precise patch levels of the production deployment are documented in the project deliverables and may evolve with the maintenance cycle of the platform) as the primary data store and Angular as the front-end framework, connected through a RESTful API layer implemented in Flask (Python). The choice of MongoDB reflects the inherent heterogeneity of the data ecosystem: agrifood data assets vary widely in format (Excel/CSV files, image archives, instrument-specific outputs, certification documents) and in internal structure (tabular, hierarchical, unstructured). A document-oriented database accommodates this diversity without requiring schema normalization; this rationale is consistent with the established decision guidance on NoSQL data stores, which identifies precisely the heterogeneity and diversity of data and access requirements as the conditions under which document-oriented stores are preferable to rigidly structured relational schemas [17]. The Flask-based REST API layer, in turn, provides programmatic access to platform services for both human users interacting through the Angular web portal and automated pipelines operating within the broader METROFOOD-IT infrastructure. Authentication is managed through JSON Web Tokens (JWTs), and metadata records are validated at ingestion time against a formal JSON Schema definition, ensuring structural consistency across all contributions. The entire backend is containerized using Docker, enabling reproducible deployment and horizontal scalability.

A notable architectural feature is the clean separation between the Open Data Platform and the blockchain notarization layer at the implementation level: the platform’s back end handles data storage, metadata management, and hash computation, but does not embed a blockchain client. On-chain anchoring is delegated to a distinct service, ensuring that the trust layer can evolve independently—e.g., by switching between blockchain technologies—without changes to the data management infrastructure.

4.2. Data Model: Federated Storage and Centralized Metadata

A defining architectural choice of the platform is the strict separation between data storage and metadata management. Data assets are stored in their original format as uploaded by the data originator. No format conversion, schema migration, or structural transformation is imposed at ingestion time. The platform thus functions as a federated repository in which each data asset retains the representation defined by its creator—whether a spreadsheet produced by a quality control laboratory, a spectral image archive generated by a sensing instrument, or a certification document issued by a regulatory body.

What is centralized is the metadata layer. At upload time, the data originator compiles a structured set of metadata fields through a dedicated form-based interface. These fields are grounded in a project-specific ontological vocabulary designed to capture the descriptive, provenance, and domain-specific attributes relevant to agrifood metrology. The decision to develop a domain-specific vocabulary, rather than adopting a general-purpose metadata standard such as Dublin Core or DCAT-AP, reflects the specialized nature of the metrological domain: the biochemical, analytical, and certification concepts central to food metrology are not adequately covered by existing general ontologies, and adopting an insufficiently expressive vocabulary would have compromised the precision and utility of metadata-driven search.

Concretely, each data asset in the platform is described by a metadata record conforming to a JSON Schema that organizes fields into four functional groups:

• Identification and description: a unique file identifier, a human-readable name, file format, category, free-text description, and a set of user-defined tags that support flexible, keyword-based discovery.
• Provenance and versioning: the identifier of the uploading user, the upload timestamp, and a version field, enabling temporal traceability and support for dataset evolution over time.
• Governance: a visibility attribute (with enumerated values private and public) that determines access scope, controlled exclusively by the data originator.
• Integrity and analytical linkage: a SHA-256 cryptographic hash computed over the file content at upload time, serving as both a tamper-evident fingerprint and the anchor point for blockchain notarization, and references to associated analytical environments, including Jupyter notebook folders and the computational tools used for analysis (e.g., MATLAB (The MathWorks Inc., Natick, MA, USA), Python), establishing a direct link between the data asset and the Intelligence Layer of the architecture.

The inclusion of analytical–environment metadata within the data schema is an architectural choice that deserves emphasis: it means that the Open Data Platform is not merely a passive repository but is aware of the computational context in which data assets are produced and consumed, enabling tighter integration with the AI/ML layer.

The resulting metadata records are centrally indexed and constitute the platform’s primary discovery mechanism. Users searching for data formulate queries against metadata fields—selecting fields to filter on, specifying values, and optionally constraining by visibility scope—and receive as results references to the original data containers in the format defined by the originator. This design ensures that the platform scales across organizational and disciplinary boundaries without imposing adoption barriers, since the only shared commitment required of data providers is the metadata vocabulary, not the data format.

4.3. Access Model and Data Governance

The platform implements a dual-access model that distinguishes between public and authenticated interactions.

• Public access.

Unauthenticated users can search for data assets, view their associated metadata, and download files whose visibility has been set to public by the data originator. This modality supports the platform’s open science mandate by enabling broad discovery and reuse of publicly shared datasets without requiring registration or institutional affiliation.

• Authenticated access.

Registered users who authenticate through the platform’s login system gain access to additional capabilities: uploading data assets with associated metadata, managing the visibility of their own files (public or private), and accessing their private data area. Crucially, visibility control is exercised by the data originator: the decision of whether a given data asset is publicly discoverable or restricted to the originator’s private workspace is made at upload time and can be modified subsequently by the originator alone. This governance model preserves the data sovereignty of contributing stakeholders while enabling selective openness.

4.4. Archival and Search Workflows

The operational interaction with the platform follows two primary workflows.

• Archival.

A registered user uploads a data file and, in the same operation, compiles the associated metadata through a structured form whose fields are drawn from the platform’s ontological vocabulary. The file and its metadata record are stored as a paired unit, but managed distinctly: the file is preserved in its original format, while the metadata record is indexed for discovery. At the point of archival, a cryptographic hash (SHA-256) is computed over the file content, producing a unique digital fingerprint (impronta univoca) for each data asset. This fingerprint serves a dual function: within the platform, it provides a tamper-evident identifier that allows any subsequent retrieval to be verified against the original; across layers, it constitutes the anchor point for the blockchain notarization process described in Section 5, where the same hash is recorded on-chain to provide immutable, decentralized attestation of data integrity and provenance.

• Search and retrieval.

Users—whether authenticated or not, subject to visibility constraints—search for data by selecting metadata fields, specifying filter values, and optionally scoping the search to public or private assets. Results are presented as a list of matching data assets, each accompanied by its metadata and its unique cryptographic fingerprint. The user can then download the original data file in the format defined by the originator. The search mechanism is thus entirely metadata-driven: users never need to know the internal format of data assets in advance, and the platform accommodates an open-ended variety of file types without requiring format-specific indexing or parsing.

4.5. Interoperability and Integration

The REST API layer exposes the platform’s core services—data ingestion, metadata management, search, and retrieval—to external systems and automated workflows. This programmatic interface enables integration with the other layers of the METROFOOD-IT architecture: the blockchain layer accesses the platform to retrieve cryptographic hashes for on-chain anchoring, while the AI/ML layer queries the platform to discover and retrieve validated datasets for model training and inference. The API also supports potential interoperability with external data infrastructures, although the current implementation focuses on intra-project integration.

The platform’s design reflects a deliberate trade-off between an ambitious interoperability goal and pragmatic adoption. By not mandating compliance with a specific metadata exchange protocol (e.g., OAI-PMH, SPARQL), the platform avoids imposing technical prerequisites on data providers. At the same time, the structured metadata vocabulary and REST API provide a well-defined interface that can serve as the basis for future alignment with broader data sharing frameworks, such as the European Open Science Cloud (EOSC) or FAIR data principles, should the infrastructure’s scope expand beyond its current national perimeter.

5. Blockchain Integration

The second architectural layer of the METROFOOD-IT IT kernel is the blockchain-based notarization infrastructure. Its function is to guarantee the integrity, provenance, and verifiability of the data assets managed by the Open Data Platform, transforming the system from a conventional data repository into a verifiable trust infrastructure. The design of this layer draws on the theoretical framework of Blockchain-based Information Ecosystems (BBIEs) [9], which proposes integrating blockchain technology as a module within a broader information ecosystem rather than deploying it as a standalone application.

5.1. Architectural Foundation: Blockchain-Based Information Ecosystems

A key insight underlying the METROFOOD-IT trust layer is that blockchain technology delivers its greatest value not when it replaces existing information systems, but when it is integrated within them as a trust and coordination mechanism. The BBIE framework [9] formalizes this principle by proposing an architecture that decomposes system logic into on-chain and off-chain components: on-chain activities provide security, transparency, and immutability, while off-chain components handle storage, computation, and high-volume data management. This decomposition enables the blockchain to serve its core function—establishing trust among parties and managing shared business logic—without imposing the scalability constraints associated with fully on-chain architectures.

In the METROFOOD-IT context, this translates into a design in which the Open Data Platform (described in Section 4) manages the full lifecycle of data assets off-chain, while the blockchain layer anchors only cryptographic evidence of data integrity on-chain. The two layers communicate via the SHA-256 hash computed at ingestion time (cf. Section 4), which serves as both an internal tamper-evident identifier and the artifact submitted to the distributed ledger for notarization.

5.2. Notarization Workflow

The notarization process follows a three-phase workflow:

1.

Hash generation. When a data asset is archived in the Open Data Platform, a SHA-256 cryptographic hash is computed over the file content. Depending on the originator’s storage and confidentiality requirements, hash computation may be performed centrally on uploaded content, by streaming through the platform without persistent retention, or client-side with the platform receiving only the resulting hash; these options trade off custody assurance against transmission constraints. This hash is stored as a field in the metadata record and serves as the asset’s unique digital fingerprint.

2.

On-chain anchoring. The hash, together with essential identifying metadata, is transmitted to the blockchain notarization service, which records it on a public distributed ledger. The recording provides an immutable attestation of the data’s existence and integrity at a specific point in time.

3.

Verification. Any stakeholder can subsequently verify the integrity of a data asset by recomputing its hash and comparing it against the value recorded on-chain. A positive match certifies that the data has not been altered since the moment of notarization.

As discussed in Section 9.3, the notarization step is presented to the user as a simple, optional affordance within the platform’s interface. The user retains full discretion over which assets to notarize and when, and the underlying cryptographic and distributed ledger mechanisms are entirely abstracted away.

5.3. DLT-Agnosticism and Technology Selection

A distinctive feature of the METROFOOD-IT architecture is its agnosticism with respect to the specific DLT technology employed for on-chain anchoring. As confirmed by the implementation of the Open Data Platform (Section 4), the platform’s back end computes hashes internally but does not embed a blockchain client; on-chain anchoring is delegated to a distinct, independently deployable service. This architectural separation ensures that the trust layer can evolve—for instance, by switching among blockchain technologies—without requiring changes to the data management infrastructure.

This agnosticism is not merely a theoretical design feature; it has been exercised in practice within the broader research program from which the METROFOOD-IT architecture derives. Two complementary DLT technologies have been validated for different operational scenarios:

• Ethereum (public blockchain).

Ethereum is the target DLT for the METROFOOD-IT platform’s primary use cases for notarization, including the certification of laboratory analysis results, quality control reports, and certification documents. The choice of a public blockchain reflects the requirement for maximal transparency and independent verifiability: any stakeholder, including consumers and regulators, can verify data integrity without needing permission from the platform operator. Ethereum’s mature ecosystem, extensive tooling, and robust security guarantees make it well-suited for notarization workflows with moderate transaction frequency and strong public auditability.

• IOTA’s Tangle (DAG-based DLT).

For high-frequency IoT data streams, the architecture has been validated using IOTA’s Tangle [18], a Directed Acyclic Graph (DAG)-based distributed ledger that operates without transaction fees and supports high-throughput, low-latency data anchoring. In a proof-of-concept study on rice cultivation, IoT sensors monitoring soil moisture, temperature, and nutrient levels transmitted data in real time via MQTT to edge nodes (Raspberry Pi), which anchored sensor readings to the Tangle and stored them in MongoDB for subsequent analysis. The Tangle’s feeless, scalable architecture makes it particularly well-suited for IoT-driven environments where thousands of sensor readings must be recorded per day at negligible cost.

The coexistence of these two technologies within the same architectural framework is a direct consequence of the DLT-agnostic design: the choice of distributed ledger is determined by the requirements of the specific use case—transaction frequency, cost per transaction, acceptable latency, and the desired level of public verifiability—not by a rigid architectural constraint. This principle is further validated by the Nova Tellus project [19], which implements a comparable blockchain–AI integration pattern using Hyperledger Fabric (a permissioned blockchain) for agricultural supply chain management, demonstrating that the same architectural logic applies across different DLT families.

5.4. Hybrid Design: On-Chain and Off-Chain Coordination

The selective anchoring strategy adopted by METROFOOD-IT reflects a broader design philosophy articulated in the BBIE framework [9]: in data-intensive ecosystems, the blockchain’s role is not to store data but to certify it. Full datasets—large, high-dimensional, or subject to privacy constraints—remain off-chain within the Open Data Platform’s repositories, where they can be managed, versioned, and shared through conventional database and API services. The blockchain records only the minimal cryptographic evidence (hashes and anchoring metadata) needed to establish that a specific dataset existed in a specific form at a specific time.

This hybrid design offers several advantages:

• Scalability: the volume of on-chain transactions is decoupled from the volume of data, enabling the architecture to support data-intensive workflows (e.g., high-frequency IoT streams, large spectral datasets) without incurring prohibitive blockchain costs.
• Privacy: sensitive data need never be exposed on a public ledger; only format-agnostic hashes are recorded, revealing nothing about the data content.
• Interoperability with the Intelligence Layer: because data remain accessible through the Open Data Platform’s REST API, the AI/ML layer can query, retrieve, and process validated datasets without interacting with the blockchain directly. The trust guarantee is inherited transitively: if the hash of a dataset matches its on-chain anchor, the AI pipeline can treat that dataset as integrity-verified.

This last point is architecturally significant: it means that the blockchain layer imposes no overhead on the AI/ML pipeline. The Intelligence Layer consumes data through the same API as any other client; the only difference is that it can additionally verify, through a hash comparison against the on-chain record, that its inputs have not been tampered with. Trust is thus propagated through the architecture without coupling the analytical and trust-enforcement layers at the implementation level.

6. AI and Machine Learning Layer

The third architectural layer of the METROFOOD-IT IT kernel is the Intelligence Layer, which transforms the validated and notarized data managed by the preceding layers into predictive, interpretable, and actionable knowledge. This layer is designed as an architecturally open component: it does not prescribe a specific family of machine learning techniques, but imposes a structural constraint—explainability—that shapes technology selection and conditions the integration of analytical outputs into the broader information ecosystem.

6.1. Architectural Role and Integration

The Intelligence Layer operates on data assets discovered through the Open Data Platform’s metadata services and retrieved through its REST API (cf. Section 4). It inherits trust guarantees transitively from the blockchain layer: if the SHA-256 hash of a retrieved dataset matches its on-chain anchor, the AI pipeline can treat that dataset as integrity-verified without directly interacting with the distributed ledger. This transitive trust propagation is a key architectural feature, as discussed in Section 5: it ensures that the Intelligence Layer remains decoupled from the trust infrastructure at the implementation level, while still benefiting from its guarantees.

The metadata schema of the Open Data Platform further supports this integration through dedicated fields (jupyter_tools, jupyter_folder) that link each data asset to the analytical environments in which it is produced or consumed. This means that the data layer is not merely a passive supplier of inputs to the AI pipeline; it is aware of the computational context, enabling tighter coordination between data management and analytical workflows.

6.2. Machine Learning Approaches: Openness and Constraints

The METROFOOD-IT architecture does not restrict the Intelligence Layer to a specific class of machine learning models. In principle, the layer can accommodate the full spectrum of supervised and unsupervised learning techniques, from classical methods such as Random Forests [20] and Support Vector Machines [21] to deep learning architectures including convolutional neural networks, recurrent models, and transformer-based systems. The choice of technique is determined by the characteristics of the data, the nature of the analytical task, and, critically, the explainability requirements of the specific application context.

In the current instantiation of METROFOOD-IT, the reference case study employs three complementary supervised classifiers—Random Forest (RF), Support Vector Machine with a radial basis function kernel (SVM-RBF), and XGBoost (open-source Python library)—for crop nitrogen status classification from hyperspectral data [16]. These methods were selected not by default, but for principled reasons related to the specific operational context:

• High-dimensional structured data: hyperspectral measurements produce datasets with hundreds of narrow-band features exhibiting strong multicollinearity. Tree-based ensembles, gradient boosting methods, and kernel-based classifiers handle this structure effectively without requiring the very large training sets typically needed by deep architectures.
• Domain expert interpretability: in food metrology, model outputs are not consumed by automated downstream systems alone; they are evaluated by chemists, agronomists, certification bodies, and regulators who need to understand why a particular classification was made. This requirement favors models whose decision logic can be made transparent through post hoc explainability techniques (see Section 6.3).
• Moderate dataset sizes: metrological datasets, while rich in dimensionality, often have relatively limited numbers of samples due to the cost and complexity of laboratory analysis. Shallow learning methods tend to generalize better than deep networks under these data-scarcity conditions.

This does not imply that deep learning is excluded from the METROFOOD-IT ecosystem. For application scenarios involving large-scale unstructured data—such as image-based quality inspection on production lines or natural language processing of certification documents—deep architectures may be appropriate and can be integrated into the Intelligence Layer via the same API and metadata infrastructure. The architectural constraint is not on the model family, but on the interpretability of its outputs, as discussed in the following subsection.

6.3. Explainability as a Structural Requirement

In regulated domains such as food safety and metrology, the adoption of AI-based decision support is constrained not only by predictive accuracy but, critically, by the transparency of model outputs. Regulatory bodies, certification authorities, and domain experts require not merely predictions but justifications: an understanding of which input features drive a given output and why a particular decision boundary was drawn. This requirement elevates explainability from a desirable post hoc diagnostic to a first-class architectural concern (cf. Section 9.4).

6.3.1. SHAP: Theoretical Foundations and Practical Application

The primary explainability technique adopted within the METROFOOD-IT Intelligence Layer is SHAP (SHapley Additive exPlanations) [22,23], a framework rooted in cooperative game theory. SHAP assigns to each input feature a Shapley value that quantifies its marginal contribution to a specific prediction, relative to the average prediction across the dataset. The key theoretical property of Shapley values is that they constitute the unique attribution method satisfying three desirable axioms simultaneously: local accuracy (the feature contributions sum to the difference between the prediction and the baseline), consistency (if a feature’s marginal contribution increases in a revised model, its attribution does not decrease), and missingness (features absent from the model receive zero attribution).

In the context of hyperspectral crop assessment, SHAP attribution produces global wavelength-importance profiles that identify the spectral regions—and the associated biochemical and structural processes—most influential for a nitrogen status classification. In the reference case study, SHAP analysis identifies the red region (610–650 nm), the red-edge transition (660–710 nm), and the near-infrared and long near-infrared bands (940–960 nm and 1050–1060 nm) as the dominant contributors, with the relative weight of longer wavelengths increasing at the heading stage of the crop [16]. These attributions are directly interpretable by agronomists, who can relate the red and red-edge contributions to chlorophyll absorption and the near-infrared contributions to canopy structure and water content. The domain expert can therefore assess not only whether the model’s prediction is plausible, but whether its reasoning aligns with established agronomic knowledge—and whether that reasoning shifts coherently with the phenological stage of the crop, as it does in the reference study.

6.3.2. SHAP Across Model Families: Shallow and Deep Learning

An important property of SHAP is its model-agnostic formulation: Shapley values can, in principle, be computed for any supervised learning model, regardless of its internal architecture. However, the quality, computational cost, and interpretive clarity of SHAP explanations vary substantially across model families:

• For tree-based ensemble models (Random Forest, Gradient Boosting, XGBoost), the Tree SHAP algorithm [23] exploits the recursive partitioning structure to compute exact Shapley values in polynomial time. The resulting attributions are precise, computationally efficient, and directly tied to the model’s decision paths. This makes tree-based models the natural choice when high-fidelity explainability is a primary requirement.
• For deep neural networks, approximate methods such as Deep SHAP (which combines Shapley values with DeepLIFT backpropagation) and Kernel SHAP (a model-agnostic perturbation-based approach) can provide feature attributions. However, these approximations are computationally more expensive, may exhibit higher variance, and—crucially—produce explanations that are harder for non-technical domain experts to interpret, since the features being attributed may themselves be learned representations rather than physically meaningful input dimensions.

This gradient of explainability quality has direct architectural consequences for the METROFOOD-IT ecosystem. In application scenarios where domain experts are integral to the decision-making loop—such as food metrology, where a chemist or certification officer must validate an AI-generated assessment—the requirement for high-fidelity, interpretable explanations favors model families for which exact or near-exact SHAP computation is feasible. In scenarios where the primary consumer of model outputs is an automated downstream system (e.g., a smart irrigation controller), the explainability constraint may be relaxed, and deeper architectures may be deployed if their predictive performance justifies the reduced transparency.

6.3.3. Beyond SHAP: Complementary Explainability Approaches

While SHAP provides the primary explainability framework within the current METROFOOD-IT implementation, the architecture does not preclude the adoption of complementary techniques as the Intelligence Layer evolves. Layer-wise Relevance Propagation (LRP), which decomposes a neural network’s output by redistributing relevance scores back through the network’s layers, provides an alternative approach to explaining deep learning models in terms of input-level contributions. Concept-based explainability methods, which map internal model representations to human-interpretable semantic concepts, may become relevant as the ecosystem incorporates more complex analytical tasks. The architectural requirement is not that a specific explainability technique be used, but that every predictive output produced by the Intelligence Layer be accompanied by an interpretability artifact that enables domain experts or automated verification systems to assess the basis of the prediction.

6.4. Outputs and Decision Support

The Intelligence Layer produces three categories of outputs that are made available to stakeholders through the platform:

• Predictive outputs: classifications, regressions, and anomaly scores generated by trained models—for example, a nitrogen status classification for a crop parcel, or a fraud-risk score for a food product.
• Explainability artifacts: SHAP attribution maps, feature importance rankings, and other interpretability outputs that accompany each prediction and enable domain experts to evaluate the model’s reasoning.
• Decision support recommendations: higher-level actionable outputs that synthesize predictive results with domain context—for example, a recommendation to adjust fertilization practices based on predicted nitrogen deficiency, or a flag for regulatory review based on detected anomalies in a certification dataset.

Where appropriate, both the predictive outputs and their associated explainability artifacts can be notarized through the blockchain layer, creating an auditable record not only of what the model predicted, but of why it predicted it. This capability is particularly relevant for regulatory compliance, where the ability to reconstruct and verify the reasoning behind an AI-generated assessment may be legally required.

6.5. Reference Case Study: Experimental Methodology and Results

To allow the Intelligence Layer of the architecture to be evaluated on concrete experimental ground rather than only at the level of design principles, this subsection summarizes the experimental protocol and the headline empirical results of the reference case study on hyperspectral nitrogen classification in durum wheat [16], on which the subsequent integration with the trust and data layers (Section 8.1) is grounded.

• Experimental setting.

A field experiment was conducted on durum wheat (Triticum durum Desf., cultivar PR22D89) under rainfed Mediterranean conditions at the Cereal Research Centre in the Apulia region of Southern Italy (41°27′ N, 15°30′ E, 90 m above sea level), over the 2009–2010 growing cycle. Ten nitrogen fertilization rates (0, 60, 80, 90, 100, 110, 120, 140, 160, 180 kg N ha⁻¹) were applied to one 10 m × 80 m plot each, with nitrogen split in two doses (two-thirds at the end of tillering, one-third at booting). The Apulian soil is an alluvial clay-loam classified as a chromic calcixerert and is representative of intensively cultivated durum wheat soils in southern Italy.

• Hyperspectral acquisition.

Canopy reflectance was acquired on two dates—21 April 2010 (booting, GS 40) and 2 May 2010 (heading, GS 55)—at 100 georeferenced sampling locations (ten per plot) using an ASD FieldSpec HandHeld portable hyperspectral radiometer in the 325–1075 nm range, with nadir orientation 0.5 m above the canopy. After exclusion of the ultraviolet portion (325–394 nm) and 10 nm band averaging, the analysis used 68 reflectance predictors spanning 395–1074 nm, without spectral normalization, smoothing, or derivative transformations, in order to preserve a direct correspondence between SHAP-derived feature importance and physically measured wavelengths.

• Classifiers and nitrogen stratifications.

Three supervised classifiers were evaluated: Random Forest (RF) [20], Support Vector Machine with a radial basis function kernel (SVM-RBF) [21], and XGBoost. Three nitrogen stratification strategies were compared—a binary Low–High partition with threshold 110 kg N ha⁻¹, an Extreme tail-selection strategy retaining only the most contrasting rates, and a three-level partition—to assess the sensitivity of classification performance to class definition.

• Validation protocol.

Model performance was assessed using Leave-One-Plot-Out (LOPO) cross-validation, in which all spectra acquired from one plot are withheld as the test set at each iteration while the spectra from the remaining plots are used for model training. This protocol enforces strict independence between training and testing data at the plot level, avoiding the optimistic bias introduced by random sample-wise validation in the presence of strong intra-plot spatial and spectral autocorrelation. Classification performance was reported at both the sample level and the plot level, the latter obtained by majority voting over the spectra of each test plot. Accuracy, precision, recall, and F1 score were computed within each LOPO fold and aggregated as mean values across folds.

• Headline results.

The binary Low–High stratification yielded the highest sample-level accuracies across both phenological stages, reaching a maximum of 0.78 at booting (SVM-RBF) and 0.75 at heading (SVM-RBF), with macro-averaged F1 scores generally above 0.65 for the best models. The Extreme stratification produced intermediate performance, with maximum sample-level accuracies of 0.73 at booting and 0.63 at heading, while the three-level stratification produced consistently weak results below 0.40, indicating limited separability among Low, Medium, and High nitrogen classes under the evaluated conditions. Plot-level aggregation through majority voting markedly improved performance, with SVM-RBF correctly classifying 9 of 10 plots at booting (0.90) and all 10 plots at heading (1.00) under the binary stratification.

• Interpretability analysis.

SHAP attributions were computed on out-of-fold LOPO predictions using the standard model-appropriate estimators—TreeSHAP for the tree-based classifiers, KernelSHAP for SVM-RBF—and aggregated across folds to produce global wavelength-importance profiles. Across the three classifiers, the dominant contributors were the red region (610–650 nm), the red-edge transition (660–710 nm), and the near-infrared and long near-infrared bands (940–960 nm and 1050–1060 nm), with the relative weight of longer wavelengths increasing at the heading stage. SHAP beeswarm plots additionally revealed that visible wavelengths contributed predominantly negative attributions (with higher reflectance pushing predictions toward the Low-nitrogen class), while near-infrared wavelengths contributed predominantly positive attributions, consistent with the agronomic interpretation that chlorophyll absorption and canopy structure jointly drive the nitrogen signal.

• Methodological status within the present architecture.

The protocol summarized above predates the consolidation of the METROFOOD-IT architectural pattern and supplied two of the requirements that the present design seeks to operationalize: a structurally interpretable Intelligence Layer (the explainability constraint), and a data layer capable of preserving the integrity of high-dimensional metrological inputs (the federated data principle). Within the consolidated architecture, the validated workflow—spectra acquisition, classifier training under LOPO, SHAP attribution, plot-level aggregation—is served through the Open Data Platform’s REST interface, with notarization of the input spectra and the attribution artifacts performed through the trust layer as described in Section 5 and Section 10.

7. Integrated Workflow

The architecture in Figure 1 highlights a key design principle of the METROFOOD-IT ecosystem: the three components are not independent modules, but parts of a single information-processing pipeline. The Open Data Platform acts as the operational backbone, the blockchain layer provides verifiable trust guarantees, and the AI layer turns validated data into interpretable knowledge.

The interaction among the three components can be described as follows:

1.

Data are generated through laboratory analyses and field measurements;

2.

Data are stored and structured within the Open Data Platform;

3.

Cryptographic hashes of selected data are recorded on the blockchain;

4.

AI models process validated data to generate insights;

5.

Results are made available to stakeholders, including consumers.

A representative example is the traceability of olive oil production, in which each step—from soil analysis to final packaging—is recorded and verifiable.

8. Use Cases

The two case studies presented in this section played a dual role with respect to the architecture proposed in this paper. Historically, they preceded the consolidation of the architectural pattern and were the empirical context in which the relevant requirements, trade-offs, and design choices were first surfaced: in this sense, they are the inputs that motivated and shaped the design rather than the experimental outcomes of an already-completed system. From the present vantage point of the consolidated architecture, they additionally illustrate the two complementary operational regimes that the framework is intended to support—a batch-analytical regime centered on explainable AI for laboratory-derived data, and a continuous monitoring regime centered on high-frequency IoT data—both of which the resulting pattern now serves through a common data, trust, and Intelligence substrate.

This bottom-up relationship between the case studies and the architecture should be kept in mind when reading the present section: what is established in each case study, and what extent each case study exercised of the eventual architectural pattern, is stated explicitly in the corresponding subsection.

The proposed architecture supports end-to-end agrifood scenarios in which data acquisition, trust enforcement, and intelligent analytics are tightly integrated. Typical workflows include:

• Collection and validation of production and environmental data;
• Recording and certification of processing stages;
• Association of products with digital identities (e.g., QR codes);
• Verification of provenance and quality by stakeholders, including consumers.

These workflows enable the creation of a digital identity for each product and process, enhancing transparency and trust across the supply chain.

The first case study is centered on explainable AI for agronomic assessment, and exercised primarily the data and Intelligence Layers of the eventual architecture, with notarization adopted in a complementary role. The second focuses on real-time IoT monitoring supported by distributed ledger technologies, and exercised primarily the data and trust layers under continuous, high-frequency operating conditions, with AI/ML adopted only descriptively. Together they cover the operational regimes that subsequently informed the design of the unified architecture.

8.1. Case Study: Explainable AI for Trusted Crop Nitrogen Assessment

To illustrate the integration of the Open Data Platform, blockchain-based notarization, and AI/ML capabilities within the METROFOOD-IT architecture, we consider a representative use case in precision agriculture: assessing crop nitrogen status using hyperspectral data and explainable machine learning techniques [16].

This case study is grounded in a Mediterranean field experiment on durum wheat (Triticum durum Desf.) conducted under rainfed conditions in the Apulia region of Southern Italy, with canopy reflectance acquired by a portable ASD FieldSpec HandHeld hyperspectral radiometer at two phenological stages (booting and heading) across ten plots subjected to different nitrogen fertilization rates [16]. The corresponding analytical workflow trains supervised classifiers (Random Forest, Support Vector Machine with a radial basis function kernel, and XGBoost) to classify the nitrogen status of each plot from 68 band-averaged reflectance predictors spanning 395–1074 nm, and uses SHAP [22,23] to identify the spectral regions contributing to the predictions. The experimental protocol, the classifier configuration, the Leave-One-Plot-Out cross-validation scheme, and the headline accuracy and SHAP attribution results are described in detail in Section 6.5; the present subsection focuses on how the workflow exercises the integration of the Open Data Platform, the blockchain notarization layer, and the AI/ML layer within the METROFOOD-IT architecture. The overall process, which, in addition to machine learning for decision support, includes data acquisition and notarization, is illustrated in Figure 2.

8.1.1. Application Context: Crop Nitrogen Assessment

Nitrogen is a critical factor in crop productivity and environmental sustainability. Traditional methods for assessing nitrogen status rely on destructive laboratory analysis, which is accurate but costly, time-consuming, and unsuitable for continuous monitoring.

Recent approaches leverage hyperspectral sensing technologies, which capture reflectance information across hundreds of narrow wavelength bands. These data provide a rich, non-invasive representation of crop physiological conditions, enabling machine learning models to estimate nitrogen content and detect stress.

However, hyperspectral datasets are inherently high-dimensional and complex, requiring advanced modeling techniques that can handle nonlinear relationships and multicollinearity. Furthermore, the lack of interpretability in many machine learning models limits their adoption in real-world agricultural settings, where transparency and trust are essential.

8.1.2. AI Layer: Modeling and Explainability

Within the Intelligence Layer of the METROFOOD-IT architecture, the case study implements a supervised machine learning pipeline for nitrogen status classification.

The workflow includes the following steps:

• Data preparation: spectral measurements are preprocessed and aligned with reference nitrogen measurements obtained from laboratory analyses.
• Model training: machine learning models, such as Random Forest [20] and Support Vector Machines [21], are trained to classify nitrogen status or estimate nitrogen-related variables.
• Validation: model performance is evaluated using spatially independent validation strategies to ensure robustness under realistic field conditions.
• Explainability: SHAP-based attribution methods are used to identify the spectral regions contributing most significantly to the predictions, enabling domain experts to interpret model behavior.

This layer transforms raw data into actionable knowledge, providing predictive and interpretable insights that support agronomic decision-making.

8.1.3. Data Layer: Integration Through the Open Data Platform

The AI workflow operates on data managed by the Open Data Platform, which provides a unified infrastructure for ingesting, harmonizing, and sharing heterogeneous agrifood data.

In this case study, data sources include:

• Hyperspectral measurements acquired from field or proximal sensors;
• Laboratory analyses providing ground-truth nitrogen values;
• Metadata describing experimental conditions, sampling protocols, and geospatial context;
• Auxiliary data such as environmental variables or crop management information.

These heterogeneous inputs are integrated through standardized ingestion pipelines and metadata management services, ensuring interoperability and facilitating data reuse. The resulting datasets are stored in the Open Data repository and made accessible through controlled data sharing services.

This layer enables the transition from isolated experimental datasets to a scalable, reusable data ecosystem supporting collaborative research and operational applications.

8.1.4. Trust Layer: Blockchain-Based Data Notarization

To ensure data integrity, provenance, and trustworthiness, the METROFOOD-IT architecture incorporates a blockchain-based notarization layer.

In the context of this case study:

• Cryptographic hashes are generated for selected data assets, including raw spectral measurements, processed datasets, and model outputs;
• These hashes are recorded on a public blockchain, creating immutable anchors that certify the existence and integrity of the data at a given point in time;
• Verification services allow stakeholders to validate that datasets used for model training and inference have not been altered.

This hybrid design preserves scalability by keeping full datasets off-chain, while leveraging blockchain technology to provide verifiable guarantees of integrity and provenance.

As a result, the AI pipeline becomes not only explainable but also auditable, enabling reproducibility and reinforcing trust among stakeholders.

8.1.5. End-to-End Integration and Decision Support

The integration of the three layers yields an end-to-end pipeline that enables trusted and explainable decision-making in agrifood systems.

• The Open Data Platform ensures that data are accessible, interoperable, and reusable.
• The blockchain layer guarantees data integrity and traceability.
• The AI/ML layer transforms validated data into predictive and interpretable insights.

In the nitrogen assessment scenario, this integrated architecture enables:

• Accurate and non-invasive monitoring of crop nitrogen status;
• Transparent interpretation of model predictions through explainability techniques;
• Verifiable traceability of data and analytical processes;
• Support for decision-making by farmers, agronomists, certification bodies, and regulators.

More broadly, the case study illustrates how METROFOOD-IT moves from data acquisition to the generation of trusted knowledge, bridging the gap between experimental research and operational deployment in real-world agrifood ecosystems.

This case study emphasizes the role of AI-driven inference within the architecture. We now consider a complementary scenario in which data acquisition and trust infrastructure play the primary role.

8.2. Case Study: IoT-Driven Sustainable Agriculture Monitoring

To complement the previous AI-centered case study, we consider a second scenario grounded in a proof-of-concept prototype that simulates a rice production process under the integration of Internet of Things (IoT) sensors and distributed ledger technologies (DLTs) [18]. Whereas the nitrogen assessment case study (Section 8.1) emphasizes AI-based inference and the Intelligence Layer, this scenario foregrounds the data and trust layers under continuous, high-frequency operating conditions, exercising the architecture’s behavior in a regime that the first case study does not.

It is important to be explicit about the nature of the contribution of this case study before describing it in detail. The agronomic regime that motivates the work—precise control of irrigation cycles in rice cultivation to optimize water use and curb methane emissions—is established independently in the agronomic literature and is not itself a contribution of the proof-of-concept. What the proof-of-concept contributes is the IT substrate: an end-to-end pipeline that securely, efficiently, and at near-zero transaction cost delivers the data infrastructure required to actuate that agronomic regime in practice. The case study should therefore be read as evidence that a DLT-grounded IoT architecture can serve a known-effective agronomic methodology with light computational resources and an interoperable software stack, not as evidence that the integration itself produces agronomic optimization.

8.2.1. Application Context: Sustainable Agriculture Monitoring

Rice cultivation is among the most resource-intensive agricultural processes worldwide, requiring more freshwater than any other major crop and contributing substantially to agricultural methane emissions through prolonged paddy field flooding. Sustainable rice production, therefore, depends critically on precise control of irrigation cycles, since the duration of field flooding directly determines both water use and the activity of methane-producing microorganisms responsible for greenhouse-gas emissions.

Achieving this precision requires continuous, fine-grained monitoring of soil and environmental conditions, which in turn generates data volumes that strain conventional centralized infrastructures. The challenge is twofold: the data must be acquired at high frequency from spatially distributed sensors, and the resulting records must be trustworthy enough to support traceability claims toward stakeholders ranging from agronomic decision-makers to certification bodies and consumers. This combination—high-frequency acquisition coupled with cross-stakeholder verifiability—is precisely the operational regime that the METROFOOD-IT trust layer is designed to accommodate through its DLT-agnostic, selective anchoring strategy (cf. Section 5).

8.2.2. Data Layer: High-Frequency IoT Acquisition

The acquisition pipeline relies on a network of low-cost sensors comprising soil moisture probes (with separate sensors for minimum and maximum water-level thresholds), a temperature and humidity sensor (DHT11), an atmospheric pressure sensor, a rain detector, and a flame-detection sensor. These sensors are connected to a Raspberry Pi 4 edge node (Raspberry Pi Ltd., Cambridge, UK), which acts as a local gateway that samples, formats, and forwards sensor readings.

Communication between the edge node and the broader infrastructure is handled through the MQTT publish–subscribe protocol, mediated by an EMQX broker designed to support large-scale concurrent client connections (up to two million on a single server node) and lightweight message routing suited to constrained devices. In the prototype configuration, sensor readings are encoded as JSON documents and transmitted at a fixed sampling interval of two seconds, with the publish–subscribe topology providing a natural multiplexing mechanism across heterogeneous sensor types. The reference study reports no visible latency and no message loss at this sampling rate under the prototype’s operational conditions [18].

Persistent storage is provided by a document-oriented database (MongoDB Atlas), which mirrors the design choice adopted by the Open Data Platform itself (cf. Section 4): the schemaless document model accommodates the heterogeneity of sensor outputs without imposing format normalization at ingestion time. From the perspective of the METROFOOD-IT architecture, this case study illustrates how the federated data principle generalizes from laboratory and certification artifacts to high-frequency machine-generated streams: in both cases, the storage layer absorbs heterogeneity and exposes data through a uniform query interface.

8.2.3. Trust Layer: DLT Anchoring with IOTA’s Tangle

The notarization requirements of high-frequency IoT data differ substantially from those of laboratory analyses or certification documents. Continuous sensor streams generate a large volume of low-individual-value readings whose aggregate trustworthiness is critical for downstream traceability claims. Anchoring such streams to a fee-bearing public blockchain, such as Ethereum, would be prohibitively expensive at scale and would introduce latency incompatible with real-time monitoring.

For this reason, the case study employs IOTA’s Tangle, a Directed Acyclic Graph (DAG)-based DLT that supports feeless transactions and parallel validation. In the Tangle, each new transaction validates two prior transactions, allowing throughput to scale with network activity rather than being bounded by a fixed block cadence. Sensor readings forwarded by the Raspberry Pi gateway are anchored to the Tangle through a locally deployed Hornet node on the mainnet, providing tamper-evident records of the monitored history. The Tangle dashboard provides real-time visibility into the state of the distributed ledger, including DAG construction, transaction throughput (messages per second), and the proportion of referenced and conflicting transactions, supporting both operational monitoring and auditing.

This prototype exercises the DLT-agnostic principle articulated in Section 5: the same architectural pattern—hash generation at ingestion, off-chain storage of full data, on-chain anchoring of cryptographic evidence—is instantiated with a different distributed ledger technology selected according to the operational profile of the use case. Where the nitrogen assessment scenario favors Ethereum for its public auditability and mature smart contract ecosystem, the IoT scenario favors IOTA for its feeless, high-throughput characteristics. The two choices coexist within the same architectural framework precisely because the data layer does not embed a blockchain client; the trust layer is replaceable.

8.2.4. Intelligence Layer: Analytical Dashboard and Path to Predictive Models

In the current proof-of-concept, the Intelligence Layer is exercised in its descriptive form rather than its predictive form. An analytical dashboard built on top of the MongoDB store provides real-time visualization of the aggregated sensor data, including time-series plots of temperature and humidity, distribution charts across sensor types, geolocation maps of sensor deployments, and threshold-triggered alerts that flag insufficient or excess water levels in the paddy fields. The dashboard supports informed irrigation decisions by farmers, agronomists, and sustainability experts, and it exposes notarized data streams to external stakeholders for verification.

The architectural significance of this configuration lies in what it makes possible going forward. Because the trust and data layers already deliver verifiable, queryable streams through the same API surface used by the nitrogen assessment case study, the path to integrating predictive models is structural rather than infrastructural: machine learning components for irrigation scheduling, anomaly-detection in sensor behavior, or yield forecasting can be attached to the same data and trust substrate without modification to the underlying pipeline. Such an extension would close the loop from descriptive monitoring to prescriptive intervention, in line with the decision-oriented orientation discussed in Section 9.5, and is identified as a planned development in Section 12.

8.2.5. End-to-End Integration and the Status of Reported Outcomes

The integration of the three layers in this case study yields a continuously operating pipeline in which environmental data are acquired at high frequency, anchored cryptographically for tamper-evidence, stored for historical analysis, and surfaced through an interactive dashboard that supports sustainable irrigation decisions. We now state explicitly what the proof-of-concept does and does not establish, so that the contribution claimed for the present architecture is not conflated with claims that lie outside its scope.

• What the proof-of-concept establishes (IT contribution).

The validated outcomes of the proof-of-concept [18] concern the IT substrate. Specifically, the work demonstrates: (i) the technical viability of an end-to-end pipeline integrating low-cost sensors, a Raspberry Pi 4 edge node, the EMQX MQTT broker, the IOTA Tangle through a locally deployed Hornet node, and MongoDB Atlas as the persistent store; (ii) reliable data transmission at a two-second sampling interval with no visible latency and no observed message loss under the prototype’s operating conditions; (iii) the practical realizability of feeless on-chain anchoring of high-frequency sensor data through a DAG-based DLT, in contrast with the prohibitive cost of fee-bearing public blockchains at the same throughput; and (iv) the portability of the resulting stack across single-board computer hardware, database management systems, and sensor families, made possible by the use of containerization and standard communication protocols. These are properties of the IT architecture and were measured within the proof-of-concept.

• What the proof-of-concept does not establish (agronomic outcomes).

The agronomic benefits motivating the work—substantial reductions in water usage, nitrogen consumption, and methane emissions through precise control of paddy field flooding—are not measured outcomes of the proof-of-concept itself. They are projected reductions reported in the agronomic literature for the irrigation regime that an intelligent IoT system enables: approximately 50% reduction in water usage, 25% reduction in nitrogen consumption, and 50% to 70% reduction in methane emissions, as derived by Mboyerwa et al. for the controlled-flooding regime and cited as the agronomic baseline in [18]. The mechanism is agronomic—regulated flooding durations that constrain the activity of methane-producing microorganisms—and is established independently of the present work.

• The relationship between the two.

The contribution of the case study, properly framed, lies in showing that an agronomic methodology of established effectiveness can be effectively and securely brought to deployment through a DLT-grounded IoT system that runs on light, inexpensive computational resources and presents an interoperable software stack. The IT substrate is what the proof-of-concept builds and measures; the agronomic outcomes are what such a substrate, once deployed in actual paddy fields, would enable practitioners to obtain. The METROFOOD-IT architecture inherits the IT-side contribution: the substitution of IOTA’s Tangle for Ethereum is invisible to the data and Intelligence Layers, which interact with notarized data through the same API regardless of the underlying ledger, exercising the DLT-agnostic principle articulated in Section 5.

• Architectural takeaways for METROFOOD-IT.

From the perspective of the present architecture, the case study contributes three architectural takeaways:

• The role of the data layer in managing high-frequency, heterogeneous sensor streams under the same federated storage discipline applied to laboratory and certification artifacts;
• The use of a DAG-based DLT for secure, decentralized, and economically viable data validation under high-throughput conditions where fee-bearing ledgers would be impractical;
• The structural readiness of the architecture for integrating predictive AI components on top of an already-trustworthy data substrate.

Unlike the previous case study, in which AI plays a central role, this scenario highlights data acquisition and trust infrastructure as the primary drivers of value, as illustrated in Figure 3. At the same time, it naturally opens the way to integrating machine learning models, enabling predictive irrigation strategies and adaptive resource management.

Together, the two case studies illustrate the flexibility of the METROFOOD-IT architecture across different operational regimes, ranging from data-driven scientific analysis to real-time monitoring and control in field conditions.

9. Design Principles for Trust-Sensitive Data Ecosystems

The architecture presented in the previous sections embodies a set of design principles that, while instantiated within the METROFOOD-IT project, are not specific to the agrifood domain. This section makes these principles explicit, articulating them as reusable guidelines for the design of data-intensive, trust-sensitive information ecosystems involving multiple heterogeneous stakeholders.

9.1. Federated Data, Centralized Metadata

A foundational design choice of the METROFOOD-IT architecture is the strict separation between data storage and metadata management. Data assets—whether laboratory analysis reports, spectral measurements, sensor logs, or certification documents—are maintained locally by their originators in the formats native to each stakeholder (e.g., Excel/CSV files, image archives, proprietary instrument outputs). No format conversion or centralized ingestion of raw data is imposed.

What is centralized, instead, is the metadata layer. Each data asset is described through a structured set of metadata fields, compiled by the data originator through a dedicated interface and grounded in a common ontological vocabulary shared across the infrastructure. These metadata records are stored and indexed within the Open Data Platform, which serves as a discovery and access service: users search for data via metadata queries, and results are returned as references to the original data containers in the format and structure defined by the originator.

This design yields several architectural advantages. First, it minimizes the friction of onboarding new data providers, since no reformatting or migration is required. Second, it preserves the semantic authority of the data originator, who retains full control over data representation. Third, it enables scalability across organizational and disciplinary boundaries, since the only shared commitment is the metadata vocabulary rather than the data format.

This principle is particularly characteristic of large-scale research infrastructures that must accommodate a multiplicity of stakeholders—producing companies, scientific laboratories, monitoring agencies, and government bodies—each with established data workflows and formats. The federated data/centralized metadata pattern avoids the well-known failure mode of monolithic data platforms that attempt to impose a single canonical format, thereby creating adoption barriers that undermine the ecosystem they are meant to enable.

9.2. Selective On-Chain Anchoring

The integration of blockchain and distributed ledger technologies into data-intensive systems is frequently constrained by the tension between the desire for comprehensive traceability and the practical limitations of on-chain storage in terms of throughput, cost, and latency. The METROFOOD-IT architecture resolves this tension through the principle of selective on-chain anchoring: only cryptographic hashes of selected data assets are recorded on the distributed ledger, while the full datasets remain off-chain within the Open Data Platform’s repositories.

This hybrid design preserves the core trust guarantees of blockchain technology—immutability, verifiability, and decentralized attestation—without incurring the scalability penalties of storing large or high-frequency data on-chain. The selection of which assets to anchor is itself a configurable policy decision, allowing the system to adapt to different regulatory and operational requirements.

Crucially, this principle interacts productively with the federated data model described above: since data remain in their original format and location, anchoring operates on hash digests that are format-agnostic and storage-independent, making the trust layer orthogonal to data representation choices.

9.3. User-Unobtrusive Trust Infrastructure

A critical adoption risk for blockchain-enabled systems is the imposition of workflow complexity on end users. If notarization requires specialized knowledge, additional procedural steps, or disruptions to established workflows, uptake will remain confined to technically sophisticated users and will fail to reach the broader stakeholder base that the infrastructure is designed to serve.

The METROFOOD-IT architecture addresses this risk by adhering to the principle of user-unobtrusiveness: the blockchain notarization layer is presented to the user as a simple, optional affordance within the platform’s standard interface. A user who wishes to notarize a data asset does so through a single interaction element (e.g., a button within the upload or management workflow), without needing to understand the underlying cryptographic or distributed ledger mechanisms. The decision of whether to notarize, and which assets to notarize, remains entirely at the user’s discretion.

This design transforms blockchain from an infrastructural imposition into a service that users can invoke transparently and selectively. It reflects a broader principle applicable to trust-sensitive ecosystems: trust infrastructure should be available by default but activated at the user’s choice, and its complexity should be borne by the platform rather than exported to the user.

9.4. Explainability as a First-Class Architectural Concern

In regulated domains such as food safety and metrology, the adoption of AI/ML-based decision support is constrained not only by model accuracy but, critically, by the interpretability of model outputs. Regulatory bodies, certification authorities, and end users require not just predictions but also justifications—understanding which input features drive a given output and why.

The METROFOOD-IT architecture treats explainability not as a post hoc diagnostic applied to opaque models, but as a structural requirement of the Intelligence Layer. Techniques such as SHAP-based attribution are integrated into the analytical pipeline by design, ensuring that every predictive output is accompanied by an interpretability artifact that makes the model’s reasoning transparent to domain experts.

This principle has direct implications for architectural design: it means that the AI/ML layer must be instrumented to produce not only predictions but also explanatory metadata, and that the data and trust layers must be capable of managing and, where appropriate, notarizing these explanatory artifacts alongside the primary analytical outputs.

9.5. Machine Learning as a Decision-Oriented Component

A common deployment pattern for AI/ML in data-intensive infrastructures is to position it as an analytical service—a component that processes data and returns insights for human interpretation. While this pattern has value, it underutilizes the potential of machine learning within integrated architectures, particularly in domains where validated data, verifiable provenance, and interpretable outputs are already available within the same ecosystem.

The METROFOOD-IT design orients the Intelligence Layer toward decision support rather than purely descriptive analytics. The AI/ML components are designed to consume validated and notarized inputs and produce outputs that can directly inform operational interventions—whether agronomic (e.g., fertilization or irrigation guidance), regulatory (e.g., compliance flagging), or industrial (e.g., quality control adjustments). The architecture does not, in its current form, automate the execution of such interventions; rather, it is designed so that the path from data to actionable recommendation is traversed within a single integrated pipeline, with each step subject to verification and explanation.

This orientation is enabled by the preceding principles: federated data with centralized metadata allows AI models to discover and access heterogeneous inputs through a uniform interface; selective anchoring guarantees that the provenance of training data and model inputs is verifiable; and explainability ensures that recommendations are transparent and auditable. Together, these principles establish the conditions under which ML can function as a trusted component of the decision process rather than a black-box advisory service detached from the data and trust infrastructure that supports it.

The next step from decision support to autonomous, smart contract-mediated intervention—closing the loop between data-driven insight and field action—is identified as a future research direction in Section 12 and is not claimed as a property of the current architecture.

Taken together, these five principles define a coherent design philosophy for trust-sensitive data ecosystems. While each principle addresses a specific architectural concern, their value lies primarily in their interaction: federated data and centralized metadata provide the substrate; selective anchoring and user-unobtrusive trust infrastructure provide the assurance layer; and explainable, decision-oriented machine learning provides the Intelligence Layer that transforms assured data into actionable knowledge. This compositional structure is not specific to the agrifood domain and can be generalized to any large-scale, multi-stakeholder information ecosystem in which data heterogeneity, trust requirements, and intelligent decision support must coexist.

10. Reference Deployment and Quantitative Evidence

The case studies and the design principles presented so far establish the conceptual and empirical foundations of the proposed architecture. This section complements them with quantitative evidence drawn from a reference deployment of the trust layer on the Ethereum Sepolia public test network. The Sepolia deployment was carried out under the umbrella of the METROFOOD-IT activities on the project’s enterprise substrate, and serves as the technical baseline against which the transaction profile of the proposed hybrid pattern, its sensitivity to artifact size, and the comparative trade-offs among the DLT alternatives considered in the architecture can be assessed in concrete terms.

The decision to perform the reference deployment on a public test network rather than on a public mainnet is methodological and operational, not technical. Sepolia and Ethereum mainnet share the same Ethereum Virtual Machine (EVM) and the same gas accounting semantics: the gas units consumed by a notarization transaction are identical across the two networks, and the only difference is the conversion of those gas units into euros via the current gas price and ether price of the day. The cost profile of the deployed system is therefore fully characterized by measurements performed on Sepolia, while the actuation of a mainnet deployment is contingent on a governance decision concerning the management and the funding model of the relayer wallet within the consortium, currently under consideration at the project coordination level and falling outside the scope of the technical activities reported here.

10.1. Deployment Substrate and System Configuration

The reference deployment runs on the project’s enterprise substrate, built around IBM Power E1050 servers (based on the Power10 processor architecture), IBM FlashSystem FS5200 storage, an IBM SAN24B-6 fibre-channel fabric (all IBM Corp., Armonk, NY, USA), and the IBM Storage Scale parallel file system, with Red Hat Enterprise Linux 8.x running under PowerVM in a dual-VIOS configuration. The substrate provides excellent performance for data-intensive scientific workloads and exposes the dataset repository through standard POSIX, NFS, SMB, and Object interfaces.

The notarization service is implemented as a Node.js/Express backend that interacts with the Ethereum Sepolia network through the ethers.js client library and an Alchemy JSON-RPC endpoint. End users do not operate a wallet, hold native cryptocurrency, or interact with a browser extension: the backend signs every write transaction through a server-side relayer wallet whose private key is provisioned exclusively to the backend process, and the smart contract restricts write access to a set of authorized relayer addresses managed by the contract owner. This relayer-mediated transaction-signing model is the implementation of one of the four novelty axes identified in Section 1, and is the practical mechanism through which end-user wallet provisioning is removed as an adoption barrier in multi-stakeholder consortia. Streaming keccak-256 digest computation, based on the @noble/hashes library with a 1 MiB read buffer, allows the backend to notarize artifacts up to a configurable upper bound of 5 GB without loading them into memory.

10.2. Smart Contract Interface and Operational Modes

The on-chain component of the reference deployment is a Solidity smart contract—VerifiedHashRegistry—exposing six read functions and two write functions, complemented by three administrative functions reserved to the contract owner. The compact and stable nature of this interface is the implementation of the third novelty axis identified in Section 1: a small contract surface is portable, by construction, across EVM-compatible networks and provides a clean migration target for non-EVM ledgers such as Hyperledger Fabric, in which an equivalent chaincode interface can be defined without changes to the off-chain components of the architecture.

The contract supports two operational modes, summarized in

Table 1. The two operational modes of the trust layer.

Dimension	Verified Mode	Hash-Only Mode
Calldata size	Grows linearly with the artifact (digest, binary payload, and metadata)	Constant: 32-byte digest, metadata URI, 32-byte requester reference, 32-byte declared size
Gas cost	Grows with the artifact, dominated by the per-byte calldata gas cost of the EVM	Approximately constant; independent of the artifact size
On-chain digest verification	Yes—the contract recomputes keccak256(binaryData) and reverts on mismatch	No—the contract accepts the digest as authoritative; verification is delegated to off-chain recomputation
Privacy of the artifact	Limited: the binary is exposed in publicly observable calldata	Preserved: only the digest crosses the public network
Backend memory profile	Bounded by upload buffering (memory-based multipart)	Bounded by the 1 MiB streaming chunk regardless of artifact size
Maximum artifact size	Limited by block gas, RPC payload constraints, and backend memory	5 GB by configuration; constrained only by file-system capacity
Recommended use	Small, non-sensitive artifacts requiring explicit on-chain verification	Production workloads; large or sensitive scientific datasets

. The verified-mode entry point receives both the precomputed digest and the binary payload, recomputes keccak256(binaryData) on-chain, and reverts the transaction if the two values do not match. The hash-only entry point receives only the digest, the metadata URI, a requester reference, and the declared binary size, and stores them without transferring the payload through the transaction calldata.

The two modes are not mutually exclusive within a single deployment and may coexist, with the routing decision driven by the size and the sensitivity of the artifact. The hash-only modality is the configuration recommended for production workloads on the METROFOOD-IT substrate, where laboratory and IoT-generated artifacts routinely exceed the sizes for which verified-mode calldata costs remain practical.

10.3. Transaction Profile and Cost Predictability

The most operationally relevant property of the hash-only modality is the constancy of its on-chain footprint: the calldata of a hash-only transaction has a fixed size across artifacts (32-byte digest, fixed-length metadata URI string, 32-byte requester reference, 32-byte declared size), and the corresponding gas consumption is therefore essentially independent of the artifact being notarized. This property makes the operational cost of the trust layer amenable to budgeting and capacity planning, which is a non-trivial advantage in the context of long-running research infrastructures whose datasets vary widely in size.

The verified mode, by contrast, exhibits a cost profile that scales linearly with the size of the artifact, dominated by the per-byte gas cost of calldata in the EVM. For artifacts in the multi-megabyte range, verified-mode transactions rapidly become impractical, both because of the resulting gas consumption and because of block-level calldata limits imposed by the network. The hash-only modality eliminates this constraint by design.

The REST surface exposed by the backend can be profiled according to the class of JSON-RPC interaction each endpoint triggers against the public RPC provider, as summarized in

Table 2. REST surface of the reference deployment and dominant cost driver per endpoint.

Endpoint	RPC Class	Gas Profile	Dominant Cost Driver
POST /api/notarize	eth_sendRawTransaction	Linear in size	Calldata cost (carries the binary)
POST /api/notarize-local	eth_sendRawTransaction	Linear in size	Calldata cost (carries the binary)
POST /api/notarize-local-hash-only	eth_sendRawTransaction	Approximately constant	Fixed-size transaction; streaming digest
GET /api/records/{id}	eth_call	none	RPC round-trip latency
GET /api/records/by-hash/{hash}	eth_call	none	RPC round-trip latency + secondary-index scan

. Read operations are served through eth_call and do not consume gas; write operations are served through eth_sendRawTransaction and consume Sepolia ETH from the relayer wallet. The dominant cost driver of each write operation depends on the modality: calldata size for verified-mode endpoints, fixed-size transaction overhead for the hash-only endpoint.

10.4. Comparative Assessment of DLT Alternatives

The DLT-agnostic posture of the architecture has been exercised in practice across three distinct families of distributed ledger technology, each used to address a different operational profile. Ethereum, in the form of the Sepolia reference deployment described above, is the target for laboratory-derived artifacts and certification documents requiring strong public auditability. IOTA’s Tangle was used in the IoT-driven case study (Section 8.2) for high-frequency sensor streams in which fee-bearing transactions would have been prohibitive. This principle is further validated by the related Nova Tellus project [19], as well as by recent independent frameworks [24,25], which implement comparable multi-layer architectures that integrate Hyperledger Fabric and AI to enable secure and permissioned traceability in agricultural supply chains.

Table 3. Comparative profile of the DLT alternatives exercised in the architecture.

Dimension	Ethereum (Public)	IOTA Tangle	Hyperledger Fabric
Transaction cost	Per-transaction gas fee in ETH	Feeless	No native fee; operational cost of consortium nodes
Throughput	Bounded by block cadence; limited at base-layer	High; scales with network activity through DAG validation	Configurable; bounded by consortium node provisioning
Latency	Block-time bounded (∼12 s mainnet); finality after multiple confirmations	Low; suited to real-time anchoring	Sub-second within consortium; depends on consensus configuration
Public verifiability	Maximal; verifiable without permission	Maximal	Restricted to consortium members
Best-suited use case	Certification documents, regulated artifacts requiring public audit	High-frequency IoT streams, real-time monitoring	Supply-chain consortia with controlled participation
Within METROFOOD-IT	Primary target; reference deployment on Sepolia	Validated in IoT case study (rice cultivation)	Validated externally in the Nova Tellus project [19]

summarizes the comparative profile of these three options along the dimensions most relevant to the METROFOOD-IT operational requirements. The qualitative ratings reflect the implementation experience accumulated within the project and the documented characteristics of each technology.

The three options are not in competition within the architecture: they are interchangeable instances of the same architectural pattern, selected at deployment time according to the operational profile of the use case. The decoupling between the data layer and the trust layer—in which the data layer never embeds a blockchain client—is the structural mechanism that makes this interchangeability possible without modifications to the data management infrastructure.

10.5. Validation Workflow and Reproducibility

A reference validation workflow has been executed against the deployed contract on Sepolia, comprising the following operations: preparation of a sample artifact in the backend file inventory; liveness check of the REST backend; enumeration of the available files; submission of a hash-only notarization request with a domain-specific metadata URI and requester reference; retrieval of the resulting on-chain record by progressive identifier; and inverse lookup of the same record by document digest. The workflow has been validated end-to-end against the Sepolia deployment, confirming the consistency between the digest computed by the backend in streaming and the digest recorded on-chain, and the correct population of all secondary indices.

The current operational deployment on the Sepolia test network is the configuration under which all validation activities reported in this section have been performed. The reference contract address, the REST API surface, the streaming digest implementation, and the deployment scripts are documented in the project deliverables D4.8 and D4.9 and are available to interested researchers for replication.

10.6. What the Reference Deployment Establishes

In summary, the reference deployment provides three pieces of evidence that complement the empirical case studies of Section 8. First, it demonstrates the technical viability of the proposed hybrid pattern at the level of contract interface, REST API surface, streaming digest computation, and end-to-end notarization workflow. Second, it confirms the constancy of the on-chain footprint of the hash-only modality, which is the property on which the cost predictability of the architecture rests. Third, it establishes the contract interface as the concrete vehicle of DLT-agnosticism, by exhibiting a small and stable surface that has been instantiated on Ethereum and is portable to other EVM-compatible networks, with comparable interfaces realisable on non-EVM ledgers such as IOTA and Hyperledger Fabric. The migration of the deployment to a production-grade public network is contingent on the governance decision discussed at the opening of this section and is identified as a planned development in Section 12.

11. Discussion

The architecture presented in this paper should not be interpreted as a single application stack, but rather as an infrastructure model reusable across data-intensive and trust-sensitive agrifood systems. In this section, we reflect on the strengths and limitations of the proposed design, compare it against alternative architectural approaches, and discuss the conditions under which its principles are most applicable.

11.1. Strengths of the Integrated Architecture

The primary strength of the METROFOOD-IT architecture lies in the tight coupling of its three layers into a single information-processing pipeline. Data acquisition, trust enforcement, and intelligent analytics are not treated as independent concerns addressed by separate systems, but as interdependent functions coordinated through shared data structures (the metadata schema), shared cryptographic artifacts (the SHA-256 hash), and shared API services (the REST layer of the Open Data Platform).

This integration yields two properties that would not emerge from the piecemeal adoption of the same technologies. First, transitive trust: because the AI/ML layer consumes data whose integrity is attested by the blockchain layer, the analytical outputs inherit a verifiable provenance chain that extends from the original measurement through notarization to the final prediction. Second, explainability-in-context: because SHAP attributions are produced alongside predictions and can themselves be notarized, the system supports not only the verification of what was predicted but also the auditing of why—a capability that is increasingly relevant in regulated domains.

The two case studies presented in this paper illustrate complementary operational regimes of this architecture. The first (Section 8.1) emphasizes AI-based inference and interpretability, demonstrating the full triadic integration from hyperspectral data acquisition through blockchain notarization to explainable classification. The second (Section 8.2) highlights real-time IoT data acquisition and distributed trust infrastructure, validating the architecture’s applicability under high-frequency, low-latency conditions. Together, they demonstrate that the proposed model accommodates both batch-oriented analytical workflows and continuous monitoring scenarios.

11.2. Qualitative Evaluation

Table 4. Qualitative evaluation: mapping architectural components to requirements. The symbol → denotes the sequential transformation of the data artifact along the traceability chain.

Requirement	Component	Mechanism	Validation Status
Data heterogeneity	Open Data Platform	Federated storage; format-agnostic metadata schema	Implemented and operational
Interoperability	Centralized metadata; REST API	Project-specific ontological vocabulary; programmatic access	Implemented; external alignment pending
Data integrity	Blockchain layer	SHA-256 hashing at ingestion; on-chain anchoring	Implemented; validated in case studies
Provenance and auditability	Blockchain layer	Immutable timestamped attestations on public ledger	Implemented; validated with Ethereum and IOTA
Scalability of trust	Hybrid on-chain/off-chain design	Selective anchoring; full data off-chain	Validated in IoT scenario (IOTA)
User adoption of trust	UI-integrated notarization	Single-button opt-in; complexity absorbed by platform	Implemented in platform UI
Predictive analytics	AI/ML layer	Supervised learning (RF, SVM); extensible to DL	Validated in nitrogen assessment case study
Explainability	SHAP integration	Feature-level attribution; domain expert interpretability	Validated in nitrogen assessment case study
End-to-end traceability	Three-layer integration	Data → hash → anchor → validated input → prediction	Demonstrated in Case Study 1
DLT flexibility	Decoupled notarization service	No blockchain client in data platform back end	Validated with Ethereum, IOTA, Hyperledger Fabric

provides a qualitative assessment of how the METROFOOD-IT architecture addresses its stated requirements, mapping each architectural component to the specific requirement it satisfies, the mechanism through which the requirement is met, and the current level of validation.

11.3. Limitations and Open Challenges

Several limitations should be acknowledged, and we state them in the terms requested by the reviewers—distinguishing explicitly what has been implemented and measured from what is at present proposed or prospective, so that the boundaries of the architectural claim are visible.

• Scope of empirical validation.

The reference deployment described in Section 10 establishes the technical viability of the proposed hybrid pattern at the level of contract interface, REST API surface, streaming digest computation, and end-to-end notarization workflow on the Ethereum Sepolia public test network. The case studies of Section 8 were the empirical proving ground in which the architectural requirements were surfaced. Quantitative classification results for the nitrogen assessment workflow—sample-level and plot-level accuracy, macro F1, and SHAP-based wavelength attribution—are reported in detail in Section 6.5 and in the cited prior work [16], and validated through Leave-One-Plot-Out cross-validation under spatially independent plot-level evaluation. For the IoT case study, the measured outcomes pertain to the IT substrate—data-transmission performance, end-to-end pipeline functioning, the practical realizability of feeless DLT anchoring at the prototype’s sampling rate—and are explicitly separated from the agronomic benefits cited from the independent agronomic literature, as discussed in Section 8.2. Large-scale production benchmarks of the integrated platform—transaction throughput under sustained load, query latency under concurrent access, end-to-end pipeline latency from sensor ingestion to AI inference—have not yet been collected, since these depend on the production-grade deployment whose actuation is the subject of the governance discussion mentioned below.

• Mainnet deployment and wallet governance.

The reference deployment is currently hosted on the Sepolia test network, which is functionally equivalent to Ethereum mainnet at the level of EVM semantics and gas accounting but does not impose monetary cost. The migration to a production-grade public network is contingent on a governance decision concerning the management and the funding model of the relayer wallet within the consortium, currently under consideration at the project coordination level. This is a deliberate operational choice and not a technical limitation: the gas-unit profile of all notarization operations is fully characterized on Sepolia, and translation to mainnet euros is a function of the gas price and ether price at the time of deployment.

• IoT case study—triadic integration.

The IoT case study demonstrates the data and trust layers under continuous, high-frequency operating conditions, but the AI/ML layer is exercised only descriptively, through the analytical dashboard. The integration of predictive models for adaptive irrigation is identified as a planned extension rather than a realized capability. The full triadic architecture is therefore fully instantiated only in the first case study, with the IoT case study exercising two of the three layers and providing the structural readiness for the third.

• SHAP stability under feature multicollinearity.

The hyperspectral data exercised in the first case study exhibit strong multicollinearity across adjacent spectral bands, which is known to challenge attribution methods grounded in Shapley values. In particular, SHAP attributions can redistribute credit across correlated features in ways that are sensitive to the specific subset of features admitted to the model, which can affect the confidence of agronomic interpretation when adjacent bands carry overlapping biochemical information. The reference case study addresses the spatial-autocorrelation aspect of this challenge through Leave-One-Plot-Out cross-validation and plot-level majority voting (see Section 6.5), which provide a defensible protocol for reporting attribution stability under realistic field conditions. The structural challenge under correlated features nonetheless remains, and we do not at present incorporate complementary attribution methods—such as LIME, Layer-wise Relevance Propagation, or concept-based approaches—for cross-validation of attributions. The joint use of multiple explainability frameworks for robustness checks is identified as a planned extension of the Intelligence Layer.

• Metadata vocabulary and external alignment.

The metadata vocabulary adopted by the Open Data Platform is project-specific. While this choice was motivated by the inadequacy of general-purpose ontologies for metrological concepts (cf. Section 4), it introduces a potential interoperability barrier with external data infrastructures. Future alignment with standards such as DCAT-AP, the FAIR principles, and the EOSC interoperability framework would enhance the platform’s integration within the broader European data sharing landscape, including EOSC and METROFOOD-RI, and is the natural pathway through which the proposed architecture would be exposed as a domain-specific connector within these data space frameworks (cf. Section 10 and below).

• Explainability–accuracy trade-off.

The explainability constraint, while architecturally sound, imposes practical trade-offs. In application scenarios where predictive accuracy is paramount and the consumer of model outputs is an automated downstream system rather than a human expert, the preference for interpretable models may limit the exploitation of deep learning architectures that could deliver superior performance. The architecture accommodates this by treating explainability as a per-context structural requirement rather than as an unconditional constraint, but the trade-off remains a practical consideration in deployment.

11.4. Comparison with Alternative Approaches

The architectural choices embodied in METROFOOD-IT can be contrasted with several alternative paradigms:

• Centralized trust models (e.g., traditional certificate authorities or centralized quality management systems) avoid the complexity of blockchain integration but introduce single points of failure and require all stakeholders to trust the certifying entity. The decentralized notarization adopted by METROFOOD-IT eliminates this dependency, enabling trust verification without a trusted intermediary.
• Federated data spaces (e.g., GAIA-X, International Data Spaces, EOSC) pursue a complementary philosophy of data sovereignty and decentralized governance, operating at a higher level of abstraction than the present architecture and providing the general-purpose interoperability framework within which domain-specific systems can publish their datasets and services. The METROFOOD-IT architecture is not a replacement for such frameworks: it is positioned as a domain-specific connector that operates within them, providing the food metrology specialization—vocabulary, integrity and provenance guarantees, explainability artifacts as first-class entities—that the general-purpose data space frameworks do not natively offer. The proper relationship between the two layers is one of inclusion rather than of competition, and the alignment path discussed in the previous subsection (DCAT-AP, FAIR, EOSC interoperability framework) is the natural mechanism through which this inclusion is operationalized.
• Fully on-chain architectures store data directly on the blockchain, maximizing transparency but incurring prohibitive costs and latency for data-intensive applications. The hybrid on-chain/off-chain design adopted by METROFOOD-IT resolves this tension through selective anchoring (cf. Section 9.2).
• AI-first platforms that treat data management and trust as peripheral concerns risk producing analytically powerful but unverifiable outputs. The METROFOOD-IT design inverts this priority by treating trust as a prerequisite for intelligence, ensuring that AI operates on provenance-verified inputs.

11.5. Generalizability

The design principles articulated in Section 9 are not specific to the agrifood domain. Any large-scale, multi-stakeholder information ecosystem that must accommodate heterogeneous data formats, enforce trust among parties that do not fully trust each other, and extract actionable knowledge from validated data—whether in healthcare, environmental monitoring, industrial manufacturing, or cultural heritage—faces the same structural challenges. The METROFOOD-IT architecture offers a tested response to these challenges, and its principles—federated data with centralized metadata, selective on-chain anchoring, user-unobtrusive trust infrastructure, explainability as a first-class concern, and machine learning as a decision-making backbone—are designed to be portable across domains.

12. Conclusions

The digital transformation of the agrifood sector requires more than the piecemeal adoption of novel technologies; it demands cohesive architectures that harmonize data, enforce trust, and generate explainable intelligence. In this paper, we presented the IT kernel of the METROFOOD-IT platform, proposing a unified architectural model that integrates an Open Data Platform, blockchain-based notarization, and AI-driven analytics.

By abstracting from the specific implementation of METROFOOD-IT, we identified five reusable design principles for data-intensive and trust-sensitive environments: federated data with centralized metadata, selective on-chain anchoring, user-unobtrusive trust infrastructure, explainability as a first-class architectural concern, and machine learning as a decision-making backbone. A primary contribution of this architecture is its hybrid design: by maintaining full, high-volume datasets off-chain while anchoring only cryptographic hashes on-chain, the system successfully resolves the scalability limitations traditionally associated with distributed ledgers in IoT-heavy domains. Through two complementary case studies—one focusing on explainable AI (SHAP) for hyperspectral crop nitrogen assessment and the other on IoT-driven smart irrigation secured by IOTA’s Tangle—we demonstrated the operational flexibility of this triadic model. Together, these workflows illustrate how raw agricultural and metrological data can be transformed into transparent, verifiable, and actionable knowledge.

Looking forward, the evolution of the METROFOOD-IT platform will focus on several key strategic trajectories. First, future work will aim to scale the architecture to support real-time data ingestion across broader, transnational supply chain networks, thereby enhancing cross-border interoperability within the European food metrology landscape. Second, we plan to extend the Intelligence Layer by integrating advanced prescriptive analytics and federated learning paradigms, thereby enabling stakeholders to collaboratively train predictive models without compromising the privacy of raw industrial data. Finally, further research will explore the automated execution of agricultural interventions through blockchain-based smart contracts, thereby closing the loop between data-driven insights and autonomous, sustainable action in the field.

Ultimately, this architectural model provides a foundation not only for METROFOOD-IT but for the broader realization of transparent, scalable, and trustworthy agrifood ecosystems.