Food Claim-Traceability Network (FCN)

• Food Claim-Traceability Network (FCN) is a framework that models food claims as structured, traceable knowledge artifacts, linking them to sources, contexts, and validatory evidence.
• It integrates knowledge graphs with blockchain-based and sensor traceability systems to connect food claims with supply-chain events, cultural narratives, and certification records.
• FCN employs an eight-stage curation pipeline—from data mining and LLM extraction to human validation—demonstrating a reproducible, modular approach for claim attribution and provenance tracking.

Food Claim-Traceability Network (FCN) denotes a claim-centric traceability framework in which food claims are modeled as structured, traceable entities linked to food entities, sources, contexts, and validating evidence. The term is introduced as an extension of FKG.in, a knowledge graph for Indian food, and is defined as a “unified framework for modeling food claims as knowledge artifacts and tracking their origins, transformations, and evidence across domains, formats, and modalities” (Gupta et al., 22 Aug 2025). In a broader systems sense, FCN also names the provenance and verification layer needed to connect claim-bearing food records to supply-chain events, actor attestations, certification references, and environmental-condition logs, a role anticipated by blockchain-based food traceability proposals that seek to reconstruct a product’s path “from its raw components to the finished item in the store” (Subramanian et al., 2023).

1. Conceptual scope and motivation

FCN arises from the observation that food knowledge is not exhausted by ingredients, calories, recipes, or compositional facts. Food circulates through a heterogeneous claim environment in which foods are said to heal, harm, purify, cool, inflame, energize, boost immunity, improve memory, or violate moral or religious norms. The motivating examples span rigorously studied assertions such as “probiotics improve gut health,” misleading or misrepresented statements such as “soaked almonds make one smarter,” vague marketing language such as “superfoods boost immunity,” and culturally rooted beliefs such as “cold foods cause coughs.” FCN therefore treats food claims as discourse objects with provenance, context, and evidentiary history, rather than as decontextualized truth values (Gupta et al., 22 Aug 2025).

Within that framing, FCN is explicitly broader than a biomedical fact-checking system. Its claim typology includes scientific/medical, cultural/traditional, moral/political, sustainability/regulatory, aesthetic/sensory, religious/ritualistic, social/symbolic, origin/authenticity, marketing/advertising, and digital/influencer claims. The Indian context sharpens this breadth: multilinguality, regional variation, caste and ritual practices, vernacular health discourse, low health literacy, and the enormous reach of social media mean that contradictory claims often coexist, and may remain locally coherent even when they are not reducible to straightforward nutritional truth conditions. FCN is therefore oriented not only toward misinformation detection but toward contextualization and epistemic pluralism.

This scope has an immediate systems consequence. A food claim network cannot be limited to end-consumer messaging or product-label assertions. It must track where claims come from, how they mutate across media and communities, what evidence is attached to them, and which actors or infrastructures preserve or distort that evidence. In this respect, FCN stands at the intersection of knowledge graphs, provenance systems, supply-chain traceability, certification infrastructures, and consumer-facing explanation systems.

2. Ontological structure and representational model

The core FCN ontology extends FKG.in by making claims first-class objects. Its main classes are Food Entity, Food Claim, Claim Source, Claim Context, and Validating Source. The claim node is central: it links to the food entity under discussion, to the source where the claim appears, optionally to contextual information, and to one or more validating sources. The intended result is a graph that supports “multimodal provenance, stance tracking, and cross-contextual reasoning.” Food Entity anchors the claim to the underlying food ontology; Claim Source records where a claim entered discourse; Claim Context records geographic, cultural, temporal, or epistemic grounding; Validating Source records later support, refutation, clarification, or commentary (Gupta et al., 22 Aug 2025).

The Food Claim class is defined through explicit fields. These include claim_text, claim_subject, claim_property, claim_effect, claim_effect_type, claim_mechanism, claim_condition, claim_intent, claim_type, and claim_validity_status. Several constraints are stated in prose rather than formal axioms: claim_subject is singular; claim_intent is singular and chosen from “fact,” “myth,” “misrepresentation,” “misinformation,” “disinformation,” or “malinformation”; claim_validity_status is strictly one of “true,” “false,” or unverified; claim_type and claim_effect_type can be multi-valued; each claim links to one source and may link to multiple validating sources.

This schema separates semantic layers that are often collapsed in ordinary fact-checking systems. claim_property specifies what the subject has, while claim_effect specifies what the subject is said to do. claim_mechanism stores a causal pathway when present. claim_condition captures applicability constraints such as “on an empty stomach” or “if consumed daily.” claim_context distinguishes universalized slogans from regionally or culturally situated assertions. The ontology also distinguishes the originating source of a claim from the validating sources that later support or contest it. That separation is central to traceability because the location where a claim appears is not necessarily the location where it is justified.

A further ontological nuance concerns source-grounded versus inferred information. The pipeline may capture two sets of values for Food Entity properties: one extracted strictly from the source text, and another inferred by the LLM independently from world knowledge. This suggests an internal distinction between evidentiary grounding and reasoning-based augmentation, which is useful for later human verification, provenance-sensitive querying, and confidence assessment.

3. Provenance-aware curation and graph construction

FCN is operationalized through an eight-stage semi-automated curation workflow. The stages are Data Mining, Pre-Processing, Prompt Engineering, the LLM-Augmented Information Extraction (LIE) Agent, the Fact Attribution and Claim Tracing (FACT) Agent, Human-in-the-Loop Validation, Post-Processing, and Ingestion into the FCN Knowledge Graph. Data Mining acquires raw text through web scraping, API retrieval, or open data dumps; Pre-Processing removes markup and segments candidate claim text; Prompt Engineering creates few-shot prompts aligned to the ontology; the LIE Agent extracts atomic claim statements and enforces claim grammar; the FACT Agent locates validating sources and checks schema completeness; Human-in-the-Loop Validation reviews subsets of outputs; Post-Processing deduplicates, normalizes, and enriches; and final ingestion converts processed outputs into RDF triples and links them to canonical FKG.in entities (Gupta et al., 22 Aug 2025).

The LIE and FACT agents implement the paper’s central provenance logic. LIE extracts claims strictly grounded in the input text and stores them as structured JSON with source URL, retrieval date, raw text snippet, and parsed fields. FACT then attaches validating sources with stance, confidence, source type, and organization. Provenance in FCN is thus represented architecturally rather than mathematically: a claim can be followed from originating textual mention through extraction, normalization, linking, and later evidentiary attachment.

The proof of concept uses Reddit as a corpus of informal, community-driven food discourse. Specifically, the authors used a curated corpus of 515 long-form Reddit posts, each longer than 1,500 characters. Of these, 89 posts (17.3%) met the criteria for containing food-related claims. The pipeline extracted 187 distinct entities (food_entities), mapped them to 265 unique subjects (claim_subject), identified 459 claims (claim_text), and attached 578 associated texts providing supporting or debunking evidence (validity_text). The resulting graph, loaded into GraphDB, contained 6,592 nodes, with approximately 3,000 Food Claim, 2,000 Validating Source, and 1,000 Food Entity links. Manual validation found 28 unique food/dietary entities, and the system extracted 46 of 58 potential health claims, yielding 79.3% recall; the paper also reports one “100% success rate” for linking all 12 cited URLs in the sample (Gupta et al., 22 Aug 2025).

These results are explicitly proof-of-concept rather than benchmark-grade. The paper does not report precision, F1, or inter-annotator agreement, and it attributes all 12 missed claims in the reviewed sample to claim splitting. Even so, the workflow establishes a reproducible FCN pattern: claim extraction, attribution, stance attachment, and graph ingestion can be combined into a provenance-rich curation pipeline without collapsing all food discourse into a single truth label.

4. Operational substrates: provenance ledgers, adapters, sensing, and scalable architectures

FCN as a claim ontology does not by itself specify a full farm-to-retail event-ingestion stack. Related food-traceability systems supply that substrate. One foundational proposal writes every significant handoff and quality-related update to a shared blockchain ledger so that stakeholders can reconstruct the path “from its raw components to the finished item in the store.” Its operational flow begins with a farmer and a buyer agreeing on a smart contract, tags the physical consignment with RFID, updates location when the RFID tag is scanned at a warehouse or checkpoint, stores temperature and humidity with the location information, and allows harvest, processor, and retailer reports to accumulate on-chain until the customer can inspect the chain of reports “from retailer to farmer” (Subramanian et al., 2023).

A second layer concerns enterprise interoperability rather than ledger design. The “Integration Adapter Architecture for Food Traceability Blockchain” places a modular adapter between enterprise applications and a permissioned blockchain network. Its five major modules are extraction, transformation, messaging middleware, blockchain loading, and status visibility. In the reported pilot, heterogeneous systems from a farm, a processor, and a retailer were normalized into EPCIS, routed through Apache Kafka, and committed to Hyperledger Fabric, with request states tracked as Received, Translated, Processing, Confirmed, and Failed. This provides a practical FCN ingestion substrate for organizations that cannot replace their ERP, logistics, or manual systems outright (Romão et al., 27 Mar 2026).

A third layer is device-originated evidence. AmBox implements device-to-blockchain ambient sensing for food traceability using a Raspberry Pi 4 Model B as an AmBox Node, ESP32-based M5Stack Core units as AmBox Motes, BLE between mote and node, and Hyperledger Fabric v2.5 as the ledger. Each monitoring record is digitally signed using RSA-SHA256, linked to product identifier and batch number, buffered locally during outages, and later submitted through chaincode function AddEvents. In experiments, the system tolerated Wi-Fi and BLE disruptions, preserved temporal ordering, and provided near-real-time submission in local deployments, thereby supplying a direct FCN evidence path for storage and transport condition claims (Fernandes et al., 13 Apr 2026).

At larger scale, a DDD/microservices reference architecture decomposes blockchain-based traceability into user authority, enterprise record, warehousing, inventory, supervision, and traceability bounded contexts. It further replaces a monolithic ledger with a main chain plus six sub-chains, while keeping large files in IPFS and coordinating services through Nacos, MQ, and an API gateway. This suggests a scalable FCN implementation pattern in which claim, evidence, supervision, and provenance workloads do not have to coexist on one overloaded blockchain (Wang et al., 2023).

Taken together, these systems imply that an FCN can be layered: ontology and curation at the claim layer; enterprise adapters for ingestion; sensing and RFID for physical-world evidence; and domain-partitioned blockchain or hybrid storage architectures for operational scale. This suggests that FCN is best implemented as a composite sociotechnical stack rather than as a single monolithic graph or ledger.

5. Evidence, validation, privacy, and accountability

FCN is explicitly not a binary fact-checking engine. A claim has a Claim Source, but it may also have multiple Validating Source instances with different stances, media, speakers, and source types. Validation is therefore modeled as a layered evidentiary ecology rather than a single verdict. The ontology records both claim_intent and claim_validity_status, allowing a statement to be tagged as myth, misrepresentation, or misinformation while still preserving the fact that it is culturally salient, experientially meaningful, or scientifically unverified rather than simply false. The paper’s own example—“homemade tomato soup helps relieve a cold”—illustrates this distinction between clinical proof and intergenerational experiential validation (Gupta et al., 22 Aug 2025).

Claim-specific systems show how this general model can be specialized. A blockchain and artificial intelligence based system for halal food traceability treats halal authenticity as a multi-stage compliance problem involving raw material sourcing, animal origin and husbandry, slaughter method, ingredient legitimacy, processing integrity, storage and transport segregation, distribution handling, certification context, and consumer-facing QR verification. In FCN terms, halal is not a label attached at retail; it is a religious/ritualistic claim assembled from a distributed evidence chain contributed by cultivators, makers, and merchants (Alourani et al., 2024).

Privacy-preserving verification adds another dimension. A protocol for anonymous sharing of sensitive traceability data uses sanitised and hashed EPCIS event data, a discovery service, and a dead-drop mechanism through which a requester can ask an unknown data owner for detailed records by using the request_event_data_at URL embedded in a sanitised event. This makes chain continuity discoverable without forcing full supplier-network disclosure. For FCN, the implication is that claims such as origin, sustainability, or certification status may require discoverability of evidence existence before detailed disclosure of evidence content (Glew et al., 2022).

FCN can also be widened from product-centric provenance to impact-centric accountability. The ontology of Traceable Impact Management introduces Stakeholder, Outcome, StakeholderOutcome, Indicator, IndicatorReport, and ImpactReport, alongside TRU (Traceable Resource Unit), PrimitiveTrace, and Trace. Its worked example treats “food delivered to consumers is produced locally” as an indicator-backed assertion supported by DifferenceIndicator and LessThanIndicator, linked through production, transport, stocking, and buying activities. This extends FCN from “what claim was made about this food?” to “what claimable outcome did this supply chain produce, for whom, and by what trace path?” (Gajderowicz et al., 8 Jan 2025).

6. Limitations, governance, and future directions

The FCN proposal remains foundational rather than complete. Its own authors note that prompt engineering is brittle; informal, ambiguous, or culturally situated text is difficult to parse reliably; claims involving multiple foods or implicit context are hard to decompose; source attribution is often incomplete; multilinguality remains largely future work; and the proof of concept is not yet grounded in Indian-language or Indian-specific claim corpora. Future work includes multilingual support for regional Indian languages, non-text modalities such as packaging images, voice-based folk knowledge, and marketing videos, with OCR and speech-to-text, as well as retrieval-augmented generation grounded in scientific and regulatory corpora (Gupta et al., 22 Aug 2025).

Operational traceability substrates introduce their own unresolved issues. Blockchain proposals preserve and share claims but do not independently prove them. False data entry, the oracle problem around certifications such as organic status or sustainability, privacy and commercial confidentiality, governance over who can write or correct records, integration with ERP and logistics systems, and the overload risk of writing data “at every point” to the chain remain open. The architectural gaps are especially visible around formal data schema, actor identity and permission management, transformation lineage between input and output lots, selective disclosure/privacy controls, off-chain document and sensor data integration, discrepancy-resolution workflows, anomaly detection or rule-based fraud screening, interoperability with existing enterprise systems, and performance architecture (Subramanian et al., 2023).

Regulatory traceability programs add a further governance constraint: they redistribute data work unevenly. Analysis of 1,198 public comments on the FDA Food Traceability Rule identifies three tensions: burdens of becoming data workers, infeasibility in real production environments, and ambiguity created by “flexible” policy design. The rule’s reliance on Food Traceability List, Traceability Lot Code, Critical Tracking Events, and Key Data Elements shows what a national traceability network expects to represent, but the analysis emphasizes unreliable rural internet, culturally grounded non-use of digital tools, ambiguous event categories such as cross-docking, training burdens, and the disproportionate load placed on smaller or under-resourced actors (Kwon et al., 17 Jun 2026).

An FCN that aspires to production deployment therefore requires more than a graph schema and more than a blockchain. It requires claim semantics, evidence models, privacy-preserving access control, discrepancy and revocation workflows, scalable ingestion, multilingual and multimodal curation, and governance mechanisms that treat producers, processors, distributors, certifiers, regulators, and consumers as co-constitutive participants in the network. The current literature establishes the ontology, the provenance substrate, and several implementation patterns; a fully operational FCN still depends on how those layers are composed, governed, and audited in practice.