Traceability & Blockchain Documentation

Version 1.0 · Proposed framework · Updated October 6, 2026

1. Purpose and company context

UFG SEAFOOD is developing its business as a global seafood sourcing, brokerage and export company. This document proposes a traceability system that connects product batches, supplier records, processing activities, shipments and buyer receipts. Its purpose is to make a shipment’s history easier to review and to help identify affected goods when a quality issue arises.

Blockchain would provide a shared record of selected events and document fingerprints. Product details and commercial documents would remain in a controlled company platform. The proposed system does not require a cryptocurrency, customer wallet or tradable token.

This document describes a target operating model. It does not claim that UFG SEAFOOD currently operates a blockchain network, that suppliers participate in one, or that any product has verified origin, sustainability certification or regulatory approval. The reference product catalogue is a planning input; it is not evidence of actual shipments or confirmed supply.

2. Objectives and boundaries

The proposed system should:

• Link each shipped batch to its recorded source, processing history and supporting evidence.
• Keep fish size grades separate from packet weights and export-carton configurations.
• Record changes in physical custody and distinguish them from commercial brokerage transactions.
• Give authorized buyers access to the records relevant to their shipment.
• Detect changes to documents after their recorded fingerprints were created.
• Support forward tracing to customers and backward tracing to contributing source batches.

A blockchain record cannot establish that a fish was caught where a supplier says it was, that a certificate is valid, or that a temperature sensor is accurate. Those facts depend on evidence, qualified review and reliable data collection. Incomplete records must remain visibly incomplete.

3. Recommended starting approach

Start with a centralized batch register, document repository and auditable event history. This establishes data quality before introducing a shared ledger. Add a permissioned blockchain if participating organizations agree that a jointly governed record provides value beyond the initial platform.

A permissioned network means approved organizations have defined access and submission rights. Its governance should identify the organizations operating nodes, how transactions become final and how membership changes. A network controlled entirely by UFG SEAFOOD should not be described as independently validated by supply-chain partners.

Select the technology after a pilot establishes partner participation, integration needs, operating cost and support capacity. No blockchain platform, vendor, cloud provider or consensus mechanism is selected by this document.

4. Traceability structure and identifiers

The proposed model has four linked levels:

These example identifiers are internal proposal identifiers, not registered GS1 identifiers. If GS1 identifiers are adopted, obtain and use them through the applicable GS1 arrangements.

Every event needs its own unique identifier, an event time, a recording time, a responsible organization and a link to the relevant lot or handling unit. Store timestamps with a timezone; retain the original local-time context when useful. Record late submissions as late submissions rather than changing the historical event time.

5. Records across the supply chain

UFG SEAFOOD may coordinate transactions without taking physical possession. A brokerage record must identify the actual shipping, receiving and custody organizations; it must not invent a UFG warehouse receipt.

6. Minimum product and batch fields

Every applicable batch should include:

MOQ is a commercial offer term, not a property of a physical batch. Keep MOQ, prices and commercial terms in the offer/order system and link orders to shipments as needed.

Proposed partner-data mapping should be evaluated against the Global Dialogue on Seafood Traceability (GDST) framework. GDST defines seafood traceability data and events for interoperable exchange. This proposal is not a GDST compliance declaration. Confirm the applicable released version and validate the mapping before making any conformity claim. GDST standard resources, GDST objective.

Use GS1 EPCIS and its Core Business Vocabulary as the candidate foundation for sharing event information between organizations. EPCIS supports supply-chain visibility, including sensor information. An implementation must be tested against the selected schemas and vocabulary; the internal examples in this document are not EPCIS payloads. GS1 EPCIS.

7. Blockchain and document storage

The proposed information flow is:

Partner submits an event → platform validates required fields → authorized reviewer checks evidence → platform records the event and document fingerprint → buyer receives permitted access.

Even ledger metadata can reveal business relationships. Review the visibility of identifiers, timestamps and organization references before deployment. A public blockchain is outside the baseline proposal.

A document fingerprint is calculated from the exact file bytes using a documented cryptographic hash method, such as SHA-256. An authorized viewer can calculate the fingerprint of a retrieved file and compare it with the recorded value. A match indicates those bytes match the anchored file; it does not prove that the contents were true or that the issuer approved them.

If a file is revised, retain a new version and its new fingerprint. For structured event data, specify a stable serialization method before hashing so equivalent records do not generate inconsistent fingerprints.

8. Roles, permissions and evidence review

Apply least-privilege access and separate submission from review where practical. Confirm the identity and authority of each participating organization before it submits records.

Use explicit statuses: Submitted, Reviewed, Exception, On hold, and Released. Define what each status means and who may assign it. An event’s acceptance by the ledger is a technical outcome; a quality release is a business decision.

Certification review must check the document’s issuer, validity period, scope and connection to the product or facility. A certificate’s existence does not certify every item sold by a supplier.

9. Processing, splits and quantity reconciliation

A processing event must link every contributing input lot to its output lots. When lots are mixed, each output must retain links to all contributing sources. When a lot is split, record the quantities assigned to each output or handling unit.

Track processing loss, waste, glaze, by-products and adjustments separately. Do not expect fillet output to equal whole-fish input weight. Define allowable process yields and reconciliation tolerances with the processor, rather than applying invented universal percentages.

Prevent duplicate event submissions and duplicate shipment allocations. Record unit conversions explicitly. Physical receipt and shipment counts should be reconciled against the system, with discrepancies routed for review.

10. Cold-chain records and exceptions

Capture available logger identity, placement, measurement timestamps, reading units, calibration reference and links to the relevant lot or container. Distinguish sensor readings from manual checks. Store complete raw logs in the document platform and anchor their fingerprints where useful.

Set acceptable transport and storage limits from the approved product specification and applicable shipment requirements. Do not use one assumed temperature limit for all frozen, chilled, dried and live products.

When an excursion or data gap occurs:

1. Identify and place the affected lot or shipment on hold where appropriate.
2. Retain the evidence and mark missing intervals clearly.
3. Assign an authorized quality reviewer to assess disposition.
4. Record the decision and communicate it to affected partners.

A temperature log does not by itself establish food safety. Sensor authenticity, placement and interpretation remain necessary.

11. Buyer access and proposed QR experience

A proposed QR code would identify a batch or handling unit and open a controlled verification page. Public fields could include confirmed product identity, authorized origin detail and a limited event summary. Commercial documents and sensitive locations should require buyer authorization.

The page should state what has been reviewed, what evidence supports the record and what is missing. Avoid a generic “blockchain verified” badge that could imply verified safety, sustainability or certification.

A copied QR code can be attached to another package. Use handling-unit identifiers, appropriate label controls and physical reconciliation; do not describe QR scanning as proof of product authenticity.

If a network or document service is unavailable, show the last recorded status and its timestamp. Do not present unavailable data as a completed verification.

12. Corrections, disputes and recalls

Correct a historical record by appending a new event that references the previous event and explains the reason, author and review decision. The customer-facing view should show the current corrected interpretation while preserving authorized access to the historical trail.

For a suspected recall, trace backward to all contributing input lots and forward to all affected outputs, shipments and customers. Record the incident owner, decision time, notifications, returned quantities and final disposition. Communication decisions remain with authorized staff; the ledger does not automatically contact customers or regulators.

Run a mock trace exercise during the pilot. Test a mixed-source output, a split lot and a rejected or corrected record. Measure whether the team can identify the affected goods and recipients within an agreed response target.

13. Security and operating responsibilities

Before deployment, define:

• Organization identity management, authentication and signing-key custody.
• Key rotation, revocation, compromised-account response and signer-history retention.
• Encrypted transport and protected storage for off-chain documents.
• Access logs, backup schedules, restore testing and incident escalation.
• Record retention and deletion procedures for restricted off-chain information.
• Network upgrade approval, membership changes and dispute handling.
• Availability targets, support ownership and a manual fallback process.

Avoid placing personal information or confidential documents in an append-only ledger. Deleting an off-chain document does not remove its previously recorded fingerprint or metadata. Review retention requirements for the relevant operating jurisdictions separately; this proposal does not determine legal compliance.

14. Pilot, acceptance criteria and rollout

Phase 1 — Confirm the operating model. Select one actual product and one participating supplier. Confirm the processor, logistics partner and buyer; appoint operations and quality owners. Document the current record-keeping process and known gaps.

Phase 2 — Establish batch records. Create the lot register, input/output links, document repository and role permissions. Resolve scientific-name, unit and menu/specification inconsistencies before importing catalogue data into operational records.

Phase 3 — Demonstrate shared verification. Trial event signing, fingerprint verification and controlled buyer access. Evaluate whether partners require a permissioned ledger and whether they will participate in its governance.

Phase 4 — Test and decide. Complete trace exercises, document-change detection, role-access checks, duplicate-event handling, outage recovery and correction workflows. Approve production use only after the participating organizations accept the operating rules.

Track record completeness, review turnaround, trace-exercise response time, reconciliation exceptions, partner participation and operating cost. Set targets after measuring the initial process; no delivery dates or performance guarantees are assumed.

15. Decisions still needed

16. Plain-language glossary

Blockchain / ledger: A shared history maintained under agreed network rules.
Permissioned network: A network with controlled membership and access.
Batch / lot: A defined quantity linked to a source or processing history.
Traceability event: A recorded action involving a lot, such as receiving, processing or shipping.
Document fingerprint / hash: A calculated value used to detect changes to a file.
On-chain: Information recorded in the ledger.
Off-chain: Information retained in another controlled system.
Smart contract: Programmed ledger rules; it is not a substitute for a commercial agreement.
GDST: Global Dialogue on Seafood Traceability.
EPCIS: GS1’s standard for sharing event information about supply-chain activity.