Examining the Foundations of Patriorigen's Functionality

Recently, _Maldita.es_ conducted an in-depth analysis of the programming code behind the mobile application Patriorigen, which is publicly accessible on its official website. This investigation revealed that Patriorigen relies on two collaborative databases for generating its results. These databases allow contributions from users, which raises concerns about the integrity of the information since there is no guarantee of verification for submitted entries. Additionally, the application utilizes the GS1 code, which is associated with the numbers found beneath product barcodes. However, it is important to note that this GS1 code does not indicate the actual origin of food products; rather, it specifies the location of registration for the trading company. This methodological weakness has also been acknowledged by Patriorigen in its legal notice.

According to the findings from _Maldita.es_, Patriorigen integrates three primary sources of information: a database formed from voluntary contributions by users of the application, purported data on product origins from the collaborative database Open Food Facts, and the GS1 code prefix linked to the product's barcode. The reliance on these collaborative sources underscores the potential for inaccuracies, as the Open Food Facts database is continuously updated by users who can input nutritional values or labeling information for products without stringent verification processes.

Challenges and Limitations of Data Verification

It is crucial to understand that the barcode itself does not provide the country of origin for products, a fact also emphasized by GS1, the organization that governs various global barcode standards. These prefixes signify that the trading company is affiliated with a specific GS1 branch in a particular country, which does not necessarily correlate with the product's actual origin. Furthermore, as noted, Open Food Facts operates collaboratively, allowing anyone to add data regarding nutritional values or product labeling. Despite inquiries sent to Open Food Facts by _Maldita.es_ regarding the frequency and methods of verifying product origin data contributed by users, no response was received as of September 18. The company did, however, acknowledge in its data quality statement that they encounter 'issues' due to the sheer volume of products and the project's inherent nature.

The source code of Patriorigen includes specific programming logic that dictates how responses are generated based on the GS1 code entered. For example, if a code begins with '611', it will be categorized as originating from Morocco, providing a message stating "Code registered by GS1 Morocco" or indicating the declared origin if available. Similarly, codes beginning with '84' are treated under the same logic for Spain. If a product exists in Open Food Facts but does not meet the criteria for either Morocco or Spain, it will be classified as 'other', indicating that it is not of Moroccan origin, while also providing the declared origin if it is known, or defaulting to a generic message stating that it does not belong to the Moroccan prefix and lacks a declared manufacturing origin.

In conclusion, the investigation into Patriorigen's methodology raises significant questions about the reliability of the data it presents. As consumers increasingly seek transparency regarding product origins, it is essential for applications like Patriorigen to ensure robust verification processes. For those interested in the technical details, the source code can be accessed publicly at patriorigen.es/app.js.

As reported by maldita.es.