FishEUTrust Platform User Manual

Chapters in this manual are organized to be read from beginning to end while applying and testing the described features along the way. Alternatively, readers may jump directly to a specific chapter, as each contains links to prerequisite chapters covering concepts or steps required to complete the described tasks. After following a link, use the Back button or Alt + Left Arrow to return to the exact point where you left off and continue reading.

Table 1: Abbreviations

FEUT	FishEUTrust
APP	Application
API	Application Programming Interface
UI	User Interface
JSON	JavaScript Object Notation
JWT	JSON Web Token
CSV	Comma-Separated Values
UUID	Universally Unique Identifier
CSRF	Cross-Site Request Forgery
HENI	HEalth Nutritional Index
GHG	GreenHouse Gas (emissions)
PWA	Progressive Web App

Table 2: Platform-related links

User interface	https://feut.belit.co.rs/feut-ui-platform/#/
API documentation	https://feut.belit.co.rs/feutpc/swagger-ui/index.html
HookIT Game	https://feut.belit.co.rs/game/
User manual	https://feut.belit.co.rs/manual/
About the project	https://www.fisheutrust.org/
Privacy policy	https://feut.belit.co.rs/manual/privacy.html
Dialogical demo	dialogical_demo.pptx

TODO: chapter dependency graph

For any questions, suggestions, or bug reports, feel free to contact us at:

• Email: support.fish.eu.trust@belit.co.rs
• Address: Trg Nikole Pašića 9, Belgrade 11000

The FishEUTrust project aims to improve traceability, sustainability, business intelligence and trust across European seafood value chains through a range of technologies, including product lifecycle tracing, water quality and environmental monitoring, food freshness estimation, detection of toxins, bacteria, antibiotics, pharmaceuticals and pathogens in food, smart labels for products, integration of sensors, IoT, gamification, nutritional data and blockchain. The platform connects these components, providing end-to-end tracking of seafood and related information from breeding or fishing, through storage, transportation, repacking and processing, to the end consumer, enabling traceability at varying levels of granularity with data management, analytics and visualization.

At the core of the traceability is the batch - a minimal traceable unit and the central point for tracking products and their lifecycles throughout the value chain. This concept is abstract and can represent various units, such as aquaculture life stages, a single fish, a part of fish, any number of fish, mussels, cans, or any combination thereof. A batch can be split into smaller batches, multiple batches can be merged into a new larger batch and a batch can be transformed into another batch (for example, when raw food is processed into canned food). All these operations only accumulate new records and create links between existing and new records to enable historical data traversal; there are no updates or deletions of critical traceability data. Connected to the batches are their attributes - versioned key-value pairs used for grouping and as descriptive information, documents and certificates, data access rights transfer information, locations, measurements and analyses from sensors and external platforms and more. This data is also immutable, although certain records can be marked as invalid by providing a validity range.

Rights over the data are linked to registered organizations and their internal team hierarchies and can be transferred between organizations and teams. The platform secures operations through account, role and permission management, with API communication secured through stateless sessions using JWTs or more narrowly scoped access tokens, primarily intended to simplify continuous push-based sensor data submission. All access-related information, such as passwords, is securely handled in transit, in logs and at rest in the database using one-way hashing or encryption. A blockchain-based change detection mechanism is used to ensure that unauthorized modifications to database records cannot go unnoticed and that each affected record is identified as corrupted.

The platform offers flexible, runtime-extendable domain expert knowledge integration, including nutrient or product composition data, impact metrics such as the HEalth Nutritional Index (HENI) and GreenHouse Gas (GHG) emission levels, rule-engine-based interpretation of measurements (e.g., a semaphore-light system for water quality and food storage data) and more complex analyses (such as toxins, bacteria and antibiotics contamination detection or freshness estimation) contributing to complex event processing and the platform's notification system.

Digital product passports are a preview-only mobile-optimized view of the data available on the platform, linked to a batch (and its lifecycle). They serve as an entry point for end consumers who typically do not register on the platform and registered stakeholders who do not (yet) have access to the batch (e.g. during batch transfer process between organizations). The platform generates QR codes for passports as an access point that can be shared or printed on the product packaging or elsewhere.

The platform integrates with the HookIT simulation-based problem-solving browser game for education and project promotion, sharing domain expert rules used for game logic, importing quiz questions and generating additional questions from nutritional data and maintaining dynamic game configuration, player statistics and leaderboard state.

There is nothing that tightly couples this platform to seafood; it can be reused for any type of food or, more broadly, for tracking any type of product. The only components tied to the seafood domain are the data in the codebooks, dropdowns and the provided expert knowledge, all of which can be reconfigured or extended to other domains.

Users sign up by providing account name and email address. The Submit button remains disabled until the user confirms that they have read and agreed to the Privacy Policy.

After signing up, users set their password using the reset token sent to their registered email address.

To reset the password, users provide the received token along with their new password.

After successfully (re)setting the password, users can immediately login (see chapter 4) with the new password and should receive a password reset confirmation email. Receiving this email is not mandatory for logging in with the new password; it is simply a notification and may be delayed if the mail service is down.

If a user requests a password reset multiple times, only the most recently issued token remains valid.

Registered users access the platform by providing their email and password.

If the login credentials are correct, the user is redirected to the platform home page.

The footer displays the name of the team the account is currently logged into. Clicking the account icon in the bottom-left corner opens account-related options.

Clicking either the team name in the footer or the Teams button opens the Teams dialog (see chapter 5). The Tokens button opens the Data provision tokens dialog (see chapter 6). Clicking the Logout button ends the session and redirects the user to the login page (see Figure 5).

Most data entered by non-administrators is associated with organizations and their teams rather than individual users. Every user must belong to at least one organization and may belong to multiple teams within those organizations, but can be active in only one team at a time. Upon registration, a private organization is created for each user.

As described in Figure 7, clicking the team name in the footer or the Teams button opens the following Teams dialog.

The Organization dropdown lists all organizations the user is a member of. Selecting an organization displays its members and team hierarchy. Yellow background indicates the organization or team the user is currently logged into.

Organizations are created by clicking the Add button and entering a name, which must be unique across the system.

The organization creator is automatically assigned as its team leader, responsible for managing subteams and memberships. Blue background indicates that the user can log into that organization or team, but is currently logged into a different one.

Upon the next login to the system (Figure 5), the user will be redirected to the last accessed organization.

Teams form a hierarchical structure, with organizations serving as the root teams. Users in higher-level teams inherit the permissions and data of their subordinate teams.

When adding subteams or renaming teams, team names must be unique within their parent team.

Users view the memberships of teams they belong to. If team leaders want to add users from outside the selected organization to their team, they can do so only by specifying the user's email address.

The account with the provided email must be registered and can be set as a team leader.

After saving the membership, the account is listed in the Demo fish farm > Production team.

Accounts from the user's organizations are displayed in hierarchy and can be dragged between teams.

Account membership can be added to the destination team by clicking the Copy button. If the Move button is used, the account is also removed from the source team.

Here, Copy was chosen and the account became a member of another team while remaining in the original team.

Leaders can also remove accounts from teams, promote them to leaders, or revoke their leadership.

After the promotion, the account is listed as [Leader] in the Demo fish farm > Maintenance team.

The team hierarchy can be rearranged by dragging one team onto another, similar to dragging an account to a team. However, the only available action is Move, since a team can have only one parent team.

NOTE: Skip this chapter if you do not need programmatic (API) access to the platform.

To simplify service-to-service communication and avoid frequent JWT refreshes, a non-expiring data provision token can be used instead of a JWT in the HTTP request header X-Data-Provision-Token. This token is accepted only by a small set of APIs, currently: /measurement/save, /analysis/save and /analysis/relationship/save, which provide the basis for programmatic submission of measurements (see chapter 18.1) and analyses (see chapter 18.2) to the platform.

As described in Figure 7, clicking the Tokens button opens the following Data provision token dialog.

When the user generates the token, it is displayed in raw form in the dialog. This is visible only once, so users should store the token securely and use it in their application logic.

The next time the user opens the Data provision token dialog, the raw token is no longer visible. The user can revoke the existing token and generate a new one. Currently, each account can have only one token per team, and tokens can be used to send data (measurements, analyses, etc.) to subordinate teams as well. When an account is removed from a team, its token for that team stops working.

The home page of the platform, where the user lands after logging in (see chapter 4), lists all active batches on the right and displays the lifecycles of selected active batches on the left. As shown in the image below, no batches are currently available and new batches can be added by clicking the Add button.

Clicking Add opens the multi row form (see chapter 22.5). The batches to be added are defined by the content type (with extendable options, see chapter 22.4) and by the number of batches to be added per content type.

After saving, the newly created batches appear in the table with their generated IDs and creation timestamps and are automatically selected, causing their lifecycles to be displayed on the left.

The teal-colored options on the far left operate on the batches selected in the left pane, not the right. The first set of options are batch operations, enabled based on the current selection; for example, Split requires a single selected batch, while Merge requires at least two.

When two or more batches of the same content type are merged, a batch of that type is created, representing the merge result and containing links to the merged batches. The merged batches remain intact but become inactive: they cannot participate in further batch operations, disappear from the (active) Batches table on the right and are kept for traceability.

The batch created through merging is active and appears in the Batches table on the right. It can participate in further operations; as shown in the next figure, it is merged with another batch, forming a deeper lifecycle history tree.

A batch can be split into smaller batches. The split operation opens a dialog where the user defines the split types and the number of resulting batches in a multi-row form (see chapter 22.5). Since the batch being split is homogeneous, it can only be split into two or more batches of the same type.

In the example below, a single Cod, raw batch is split into five smaller batches of the same type.

As with merging, the resulting parts become new batches with links to their source batch, i.e., the batch that was split.

The batch Transform operation is used when a content type changes into another due to processes such as food processing, fish growth through breeding, or similar transformations.

In this example, three Cod, raw batches are cooked, resulting in three new Cod, cooked batches being added to the system. Each new batch retains a link to its corresponding source batch.

When batches of different content types are merged, the resulting batch is assigned a Mixed type, representing a combination of different contents. Here, a Cod, raw batch and two Tuna, raw batches are merged into a Mixed batch.

A Mixed batch can be split back into the original types, or one of the resulting splits must remain Mixed. These rules are enforced recursively when multiple Mixed batches are to be merged.

When defining the split, the user selects the content types and the number of batches per type in a multi-row form (see chapter 22.5). Here, a portion of Tuna, raw is separated from the mixture, while the remainder stays Mixed.

The items in the dropdown list only the valid options for the split.

To fully exhaust the mixture, the split must account for all content types that were combined. Here, the remaining Mixed batch is split again into Cod, raw and Tuna, raw, leaving no Mixed remainder.

Sometimes, mixed batches cannot be split back to the types that were mixed. For example, when fish oils of different types are blended, they cannot be separated back into the original components. In such cases, the Mixed batch should be transformed into a concrete content type representing the blend (e.g., Blended fish oil). To avoid this additonal step the Merge dialog has a Content type dropdown with Mixed selected by default.

After clicking Merge, the resulting Mixed batch is transformed into a Blended fish oil batch.

This ensures that the resulting batch can only be split into batches of the blended product, rather than reverting to original components such as Cod liver oil or Sardine oil. Whether a mixture is splittable to original types is determined by users; some combinations - such as protected smaller oil bags - may still be separable.

Active batches can be transferred between organizations (for in-organization batch access, see chapter 10). In the Batches table, select the rows corresponding to the batches to be transferred, then click Share -> Transfer batches.

A dialog opens displaying a generated batch transfer token that can be shared with a user from another organization. The platform does not currently provide a standard sharing method, so external messaging services can be used.

This approach allows the sender to share batches without needing to know the structure of the recipient's organization, while also ensuring that no data can be transferred without explicit acceptance. The receiver can review the contents of the token and choose to accept it, forward it to another team within their organization, or simply ignore it.

To accept the new batches, select Share -> Accept batches.

This opens a dialog where the token can be pasted and information about its source and contents can be previewed. If accepted, the batches are transferred.

Behind the scenes, this is implemented as a batch transform operation (see chapter 7): the original batch remains in the source organization, while a new batch is created in the destination organization, with a link between the two.

Because a link exists between the batches, digital passport (see chapter 21) data can be traced back through the entire history, even when the batch is distributed across multiple stakeholders. Since passports display only the subset of data relevant for traceability, stakeholders do not expose their internal information.

All information about transferred batches remains in the source organization. In the Batches table, rows for these batches are colored red and can no longer be transferred or participate in any batch operation.

Batch lifecycle (see chapter 7) forms a transitively reduced directed acyclic graph, where each node represents a batch and edges represent parent-child relationships established through split (one-to-many), merge (many-to-one) and transform (one-to-one) operations. Operations are performed on selected batches and batch-related data is fetched based on the current batch selection. Therefore, the UI provides several helper options for bulk selection of nodes when the second teal-colored option on the far left is selected.

All batches (nodes) can be selected by clicking All.

Clicking Clear deselects everything.

Individual batches can, of course, be clicked and selected.

Invert replaces the selection with its complement.

Now Clear selection and click Free, which selects all batches without relationships.

Now Clear selection and click Leaf, which selects all batches without child batches.

Clicking Parent extends the selection to parent batches of all selected batches.

Clicking Parent again goes one step further.

Now Clear selection and click Root, which selects the batches without parent batches but with child batches.

Clicking Child extends the selection to child batches of all selected batches.

Clicking Child again goes one step further.

Within an organization, different teams can be granted or revoked access to the organization's batches (for batch transfers between organizations, see chapter 8). To do this, in the Batches table, select the rows corresponding to the batches for which access is to be managed, then click Share -> Manage access.

A Batch access dialog opens displaying the access history for the selected batches. There are three permission levels: Read (view data), Write (add new data) and Share (grant or revoke access). Access is added by clicking the Add button and filling out a multi-row form (see chapter 22.5), with multi-select fields (see chapter 22.4) for both the teams being granted access and the access levels to be assigned.

Selected access levels are added to all selected teams, with the validity period starting from the current timestamp and spanning indefinitely. Selecting rows in the Batch access table enables the Invalidate button for ending access. No data can be deleted here; the history is fully maintained.

When invalidated, the validity period is set so that the current timestamp becomes the ending timestamp. For selected rows that have already been invalidated, nothing will happen and the previous validity period remains unchanged. Teams that previously had access can be granted access again.

When a batch is created, full access rights are automatically granted to the creator's team. When batches are split, merged, or transformed, access rights are copied to the resulting batches. If batches belonging to different teams are merged, all teams get access to the resulting batch.

Attributes represent any name-value information associated with batches for a defined period or indefinitely. Examples include value chain stages, truck registration numbers, breeding pool identifiers, external codes, categories and other similar information.

Selecting batches in the left pane enables the Attributes tab, which lists all attributes for the selected batches. New attributes can be added by clicking the Add button, which starts a multi-row form (see chapter 22.5) with attribute name-value pairs. When submitted, the defined attributes are created and connected to all selected batches.

In this example, attributes are used for grouping: the two selected batches are transported together in the same truck. The activity period begins at the current timestamp and remains active until invalidated.

To simulate moving the batches to another truck, the current truck registration number is invalidated by selecting the corresponding rows and clicking Invalidate, after which the new truck registration number is added. When invalidated, the activity period is assigned an end timestamp. Neither attributes nor their connections to batches can be deleted, ensuring that the history remains intact.

The Value chain stage attribute is not invalidated here because the batches are still in the transportation stage.

Data sources represent the origin of measurements (see chapter 15) and analyses (see chapter 17). Currently supported sources are categorized into three standard types: Manual (all such entries use a single predefined source), Device (any type of sensor) and Platform. External sources from which the FishEUTrust platform can pull data are categorized as DigitalSmart device, Cobàlia device and Cobàlia platform (see chapter 18.3).

To open the data sources dialog, click the second-to-last button in the bottom-left corner of the homepage (see chapter 4), then click the Sources button.

New sources can be added by clicking the Add button and filling out a multi-row form (see chapter 22.5) that accepts a name, which must be unique at the system level and a type selected from the dropdown.

After saving, the new sources appear in the table with their generated IDs. Sources can be deleted by clicking the Delete button if no measurements, analyses, or other traceability data have been collected for them.

Within an organization, different teams can be granted or revoked access to the organization's sources (see chapter 12). To do this, in the Sources table, select the rows for which access is to be managed, then click Share.

A Source access dialog opens displaying the access history for the selected sources. There are three permission levels: Read (view data), Write (add new data) and Share (grant or revoke access). Access is added by clicking the Add button and filling out a multi-row form (see chapter 22.5), with multi-select fields (see chapter 22.4) for both the teams being granted access and the access levels to be assigned.

Selected access levels are added to all selected teams, with the validity period starting from the current timestamp and spanning indefinitely. Selecting rows in the Source access table enables the Invalidate button for ending access. No data can be deleted here; the history is fully maintained.

When invalidated, the validity period is set so that the current timestamp becomes the ending timestamp. For selected rows that have already been invalidated, nothing will happen and the previous validity period remains unchanged. Teams that previously had access can be granted access again.

When a source is created, full access rights are automatically granted to the creator's team.

Measurement variables, such as weight, temperature and location, define what is being measured (see chapters 15 and 17). Each variable has a name (e.g., Temperature) and a predefined unit code (e.g., Celsius (°C)); the same unit code can be shared by multiple variables. Variables are globally shared, allowing data to be easily aggregated and compared across measurements, batches and organizations.

To open the Variables dialog, click the second-to-last button in the bottom-left corner of the homepage (see chapter 4), then click the Variables button.

New variables can be added by clicking the Add button and filling out a multi-row form (see chapter 22.5) that accepts a name, which must be unique at the system level and a unit code selected from the dropdown.

After saving, the new variables appear in the table with their generated IDs. Variables can be deleted by clicking the Delete button if no measurements, analysis templates, or other traceability data have been collected for them.

Measurements represent numerical values measured at a point in time or over a period, together with information about the measurement source, such as the sensor that recorded the value (see chapter 12) and the variable it represents, such as temperature or weight (see chapter 14).

Measurements are always connected to a batch and can be viewed by selecting one or more batches and opening the Measurements tab. New measurements can be added using the Add button, which opens a multi-row form (see chapter 22.5) for entering multiple values measured at different times for the selected source and variable.

After saving, measurements are added to the table.

CSV file import is supported, making it easier for stakeholders without a programmatic integration to submit larger volumes of data. It also enables the transfer of data from other systems that support CSV export. The CSV file must contain the measurement_value, measurement_timestamp and may optionally include measurement_timestamp_to columns. Timestamps must be provided in ISO 8601 UTC format.

To import data, click Add, then Import and select the CSV file. After the import, the data is not stored directly in the database. Instead, it populates the same form used for manual input, allowing users to review the data and address any validation errors. Invalid cells are highlighted, enabling partially valid data to be corrected to match the required format instead of rejecting the entire file.

After saving, the measurements associated with all selected batches are added to the table.

When dealing with large amounts of data, such as measurements continuously received from sensors or external platforms, a raw tabular presentation becomes less useful. To maintain performance and manage memory, especially during concurrent usage, the server provides the data only in chunks through pagination.

By default, 25 rows are fetched at a time, with the Load more option used to retrieve the next chunk. Filters are provided to narrow the search results by selecting the desired sources and variables.

As an alternative to the tabular view, measurements can be displayed as aggregated line charts displaying the minimum, maximum, average, median and upper and lower quartiles over selected time periods. Timestamps can be grouped by hour, day, week, month, quarter, or year. To open the aggregated view, click the Aggregated button.

Hovering over a data point displays its exact value and timestamp. Individual aggregation methods can be displayed or hidden and various filters can be applied. To return to the tabular view, click Raw.

Locations are represented by two measurements (see chapter 15): one for latitude and one for longitude, both with the same timestamp. When the Location variable is selected, the multi-row (see chapter 22.5) form provides two input fields per timestamp and importing data (see Figure 78) requires a CSV file with latitude and longitude columns.

The location picker next to the Timestamp end input opens a map dialog where users can select a location.

When a location is selected, the latitude and longitude fields are automatically populated.

When saved, the location is stored as two rows with the same timestamp.

When the location of a batch is known, it is displayed in a map view, which is an alternative to the batch lifecycle graph diagram (see chapter 7) and can be opened by clicking the button in the top-left corner.

When the user adds new locations for the same batch, the platform displays the batch's movement by connecting the locations with a directed line on the map. Hovering over each point shows the details of the location entry.

When a batch operation such as split, merge, or transform is applied (see chapter 7) and all resulting batches have locations, they are connected with directed lines on the map. In the example below, the batch is split into two batches.

The more location data collected, the more accurately the batch's route is displayed. In the example below, GPS sensor readings from the truck transporting the batch are shown.

An analysis consists of a series of two-dimensional points defined by X and Y values, where each axis can represent any measurement variable (see chapter 14). Each analysis conforms to a template that defines its name, the variables assigned to its X and Y axes and, optionally, the rules for interpreting the recorded data.

To open the Analysis Templates dialog, click the second-to-last button in the bottom-left corner of the homepage (see chapter 4), then click the Analyses button.

The figure below shows templates for two different toxin analyses (okadaic acid and saxitoxin) that use the same X and Y variables but differ in how the analysis is interpreted. It also shows templates for antibiotic, bacteria and freshness analyses, as well as a microplastic analysis template being defined by clicking the Add button and filling out a multi-row form (see chapter 22.5). The form requires a unique analysis name and the variables assigned to the X and Y axes (new can be added, see chapter 14).

After saving, the new templates appear in the table with their generated IDs. Templates can be deleted by clicking the Delete button if no analyses or other traceability data have been collected for them.

Selecting batches in the left pane enables the Analyses tab, which lists all analyses performed for the selected batches.

New analyses can be added by clicking the Add button and selecting a batch and a template. This opens the measurement multi-row form, where multiple X–Y values can be entered. In this example, the values are Day of fish storage (d) and Euclidean distance, as the selected template is FishEUTrust freshness analysis. The form also provides a dropdown menu for selecting the analysis source (i.e., the device that performed the analysis; see chapter 12), along with fields for the timestamp when the analysis was recorded and, optionally, an end timestamp if the analysis was performed over a period of time.

Clicking Add additional properties opens a multi-row form for entering name-value pairs representing analysis metadata that does not fit into the predefined fields, such as specific conditions, the equipment used, or other contextual information that may be important for interpreting the results.

Entering measurements and additional properties manually is error-prone, so the platform provides three CSV import options: one for measurements, one for additional properties and one for both. The following chapters demonstrate these import options in practice, with the analysis relationships and data interpretations.

Data sources can be linked to batches indirectly by subscribing to the same attributes to which the bathces are linked.

As described in chapter 11, placing a batch in a truck or a breeding tank can be represented in the platform by assigning a truck registration number or tank identifier as an attribute of the batch.

The same approach can be used for data sources. For example, placing a GPS device in a truck or a water quality sensor in a breeding tank can be represented by subscribing the data source to the corresponding truck registration number or tank identifier.

This can be done by first opening the Sources dialog, as described in the chapter 12 and defining a new data source if needed. Then, select the sources for which the subscriptions are to be defined and click Subscriptions.

This opens the Subscriptions dialog, where new sources can be added by clicking the Add button. This starts a multi-row form (see chapter 22.5) with attribute name-value pairs, since multiple subscriptions can be defined per source.

When submitted, the defined attributes are connected to all selected data sources.

When both sides are connected through the same attributes, sending data from the data source, such as measurements (see chapter 18.1) or analyses (see chapter 18.2), without providing batch IDs for the connection, automatically associates that data with the batches linked to the same attributes as the data source.

To stop receiving data for a batch, its attribute needs to be invalidated by clicking Invalidate in the Attributes dialog shown in Figure 109. In this example, invalidating the attribute simulates removing the batch from the circular tank. Similarly, to stop connecting data from a data source to batches, the source subscription needs to be invalidated by clicking Invalidate in the Subscriptions dialog shown in Figure 112. This simulates removing a sensor from a tank.

When invalidated, the subscription is assigned a timestamp that marks the end of its activity period.

POST /feutpc/measurement/save
Content-Type: application/json
X-Data-Provision-Token: e197b3ff-2568-4e7a-82a8-8a7cf673b97d

{
  "data_source_id" : "16f10e2c-5742-432e-a032-d46f2dd65b42",
  "measurements"   : [
    {
      "measurement_variable_id" : "a20918a8-cecc-4780-acca-0f6efd0123c0",
      "measurement_timestamp"   : "2026-07-29T08:26:20.928Z",
      "measurement_value"       : 70
    },
    {
      "measurement_variable_id"   : "18035936-d71c-4ba8-a536-bbadfc6daef4",
      "measurement_timestamp"     : "2026-07-29T08:26:20.928Z",
      "measurement_timestamp_end" : "2026-07-29T09:26:20.928Z",
      "measurement_value"         : 8.05
    },
    {
      "measurement_variable_id" : "1fba1427-94fb-4f60-bb5f-f1b78a68ed81",
      "measurement_timestamp"   : "2026-07-29T08:26:20.928Z",
      "measurement_value"       : 17.09
    },
    {
      "measurement_variable_id" : "1fba1427-94fb-4f60-bb5f-f1b78a68ed81",
      "measurement_timestamp"   : "2026-07-29T09:26:20.928Z",
      "measurement_value"       : 19
    }
  ]
}

POST /feutpc/analysis/save
Content-Type: application/json
X-Data-Provision-Token: e197b3ff-2568-4e7a-82a8-8a7cf673b97d

{
  "data_source_id"         : "1c8446cb-123d-4529-ac74-f2e0bf7a0487",
  "analysis_template_id"   : "a41107c2-aa61-48e4-947b-fd327cc83dd0",
  "analysis_timestamp"     : "2026-07-30T13:39:44.578Z",
  "analysis_timestamp_end" : "2026-07-30T13:39:44.778Z",
  "x_values" : [
    -199.9819336, -189.9755859,  -179.9692383,  -169.9628906,
    -159.956543,  -149.9985352,  -139.9921875,  -129.9858398,
    -119.9794922, -109.9731445,   -99.96679688,  -89.98461914,
     -79.98461914, -69.98461914,  -59.98461914,  -49.98461914,
     -39.98461914, -29.98461914,  -19.98461914,   -9.984619141,
       0.015380859, 10.01538086,   20.01538086,   29.99487305,
      39.98913574,  49.98339844,   59.98974609,   69.99609375,
      79.95410156,  89.96044922,   99.96679688,  109.9731445,
     119.9311523,  129.9375,      139.9438477,   149.9501953,
     159.956543,   169.9628906,   179.9692383,   189.9755859,
     199.9819336,  209.9882813,   219.9462891,   229.9042969,
     239.9589844,  249.9169922,   259.9716797,   269.9296875,
     279.984375,   289.9423828,   299.9487305,   309.979248,
     319.888916,   329.9194336,   339.9499512,   349.9804688,
     359.8901367,  369.9206543,   379.9511719,   389.9575195,
     399.9638672,  409.9702148,   419.9765625,   429.9829102,
     439.9892578,  449.9956055,   459.8569336,   469.8632813,
     509.9370117,  519.9191895,   529.9013672,   539.8835449,
     549.8657227,  559.8479004,   609.8554688,   619.9101563,
     629.9648438,  639.8261719,   649.8808594,   719.8044434,
     729.810791,   739.8171387,   819.84375,     989.9033203,
     999.7646484
  ],
  "y_values" : [
    0.030685801,  0.004329629,  0.026136171,   0.062779613,
   -0.016473709,  0.00309322,   0.00309762,    0.062744409,
   -0.034188226,  0.019923327,  0.026734579,  -0.051436339,
   -0.011364877,  0.028706584,  0.068778045,   0.108849511,
    0.148920968,  0.188992426,  0.229063898,   0.269135356,
    0.309206814,  0.349278271,  0.389349729,   0.418293118,
    0.642650604,  0.9002195,    1.162909985,   1.663285732,
    2.172637463,  2.798075199,  3.542041063,   4.50672102,
    5.675104618,  6.976880074,  8.514248848,  10.31526947,
   12.19570923,  14.41270065,  16.8806057,    19.5136528,
   22.32263184,  25.21023178,  28.17171288,   30.96460342,
   33.62516022,  36.29105377,  38.61170578,   40.53026581,
   42.23014069,  43.51368332,  44.56955338,   45.22895813,
   45.75473785,  45.49045563,  45.08355713,   44.38152313,
   43.25533676,  41.8295784,   40.18326569,   38.51754761,
   36.52485657,  34.31299973,  32.04288101,   29.68940735,
   27.28120422,  25.17974472,  23.05025864,   20.91765976,
   14.02431107,  12.80380249,  11.50566864,   10.34833527,
    9.347343445,  8.511978149,  5.347637177,   4.912578583,
    4.536712646,  4.218185425,  3.912437439,   2.391563416,
    2.193069458,  2.217781067,  2.28609848,    2.129261017,
    2.212844849
  ],
  "attributes" : [
    {"name" : "Galvanoplot ID",  "value" : "100G02M019"                    },
    {"name" : "Experiment Name", "value" : "GPE_2026.07.30_15.39.44.578"   },
    {"name" : "Date",            "value" : "2026.07.30 - 15:39:44"         },
    {"name" : "Method",          "value" : "Differential Pulse Voltammetry"},
    {"name" : "Ei",              "value" : "-200 mV"                       },
    {"name" : "Ef",              "value" : "1000 mV"                       },
    {"name" : "Step",            "value" : "10 mV"                         },
    {"name" : "Width",           "value" : "50 ms"                         },
    {"name" : "Period",          "value" : "200 ms"                        },
    {"name" : "Amplitude",       "value" : "70 mV"                         },
    {"name" : "Quiet Time",      "value" : "1 sec"                         },
    {"name" : "Hold Bias",       "value" : "No"                            },
    {"name" : "Current Range",   "value" : "160 μA"                        }
  ]
}

{
  "analysis_id": "3a1fc156-b0e4-4f01-9914-f327b1599618"
}

POST /feutpc/analysis/relationship/save
Content-Type: application/json
X-Data-Provision-Token: e197b3ff-2568-4e7a-82a8-8a7cf673b97d

{
  "analysis_id"         : "381e894f-4363-448f-bb2a-42b5af08293d",
  "related_analysis_id" : "3a1fc156-b0e4-4f01-9914-f327b1599618",
  "relationship_type"   : "REFERENCE"
}

Documents, such as certificates, inspection reports, laboratory results, invoices, data import files, logs and other relevant records, can be uploaded in any file format, including PDF, DOCX, XLSX, JSON and others.

To attach documents to batches, select one or more batches, open the Documents tab and click Add. This opens a multi-row form (see chapter 22.5), with each row containing a File picker and a descriptive Type dropdown. The type can be selected from existing options or defined inline as a new option.

Once uploaded, the document is linked to the selected batches and displayed in the table, where it can be downloaded by selecting it and clicking Download.

The same upload workflow is also available from the Measurements tab (see chapter 15). After selecting one or more measurement rows, clicking Documents opens the upload form for the selected measurements.

In the example below, a new document type is defined.

The uploaded document is linked to all selected measurements, as shown in the Related to column.

The same upload workflow is also available from the Analyses tab (see chapter 17). After selecting one or more analyses rows, clicking Documents opens the upload form for the selected analyses.

In the example below, a new document type is defined.

The uploaded document is linked to all selected analyses, as shown in the Related to column.

Note that the batch Documents tab also displays all documents from measurements and analyses related to the selected batches. Therefore, all three documents are listed in the image below.

Metrics represent nutrient values, product components and impacts such as HENI scores and GHG emissions. These metrics are not associated with specific batches but with food or products in general.

When batches are selected, the Metrics tab displays the metrics associated with the selected batches' content types.

Details about the data, including its sources and meaning, can be viewed by clicking the Information button.

Displayed metrics can be narrowed down to specific product categories and metric types.

When the selection includes batches with different content types, the metrics for each type are displayed. As shown in the figure below, the displayed metrics include Cod, raw and Tuna, raw, which are derived from the Mixed type, as well as Sea bream, raw, which represents the explicitly selected batch content type.

The same information can also be displayed in a comparative view by clicking the Comparative button. In this view, metrics are combined into a single table instead of being separated into different tables by food or product type. Columns represent different metrics and rows represent their values for all selected types. The table can be sorted by any metric in ascending or descending order.

Metrics can be previewed and compared without selecting batches by clicking the second-to-last button in the bottom-left corner of the homepage (see chapter 4) and then selecting the Metrics button.

This opens the same tables with the same options as shown above, but in a separate full-screen dialog.

Digital product passports provide a mobile-optimized, preview-only view of the same components available in the platform for external users, such as end consumers, who typically do not register for the platform.

To make a passport accessible, it must be created on the homepage (see chapter 7) by selecting an active batch, choosing Share -> Digital product passport and providing the product name, after which the passport can be shared with external users.

The QR code is generated to allow anyone who scans it to access the digital product passport via the embedded link, regardless of whether they have a platform account.

This chapter covers user interface patterns and reusable components that recur throughout the platform.

HookIT is a turn-based simulation problem-solving browser game with an educational and promotional purpose: raising awareness about the seafood value chain and demonstrating how the FishEUTrust platform addresses real-world challenges. The game can be accessed here: https://feut.belit.co.rs/game/ and has its own built-in tutorial for the gameplay, which won't be repeated in this manual.

Although the game runs in a browser and requires no installation, it can still be installed as a PWA for a more native-like experience, especially when played on a mobile phone.

The PWA installation and uninstallation guide is available at the link below:

https://developer.mozilla.org/docs/Web/Progressive_web_apps/Guides/Installing