We are trying to solve for global product visibility - the ability for producers to know where their products are, and the ability for consumers to know where their products came from. We aim to do this in a manner that is both secure, open to all participants, and avoids the use of a central coordinator. This level of granular product visibility unlocks thousands of valuable enterprise use cases. But before jumping to the solution and all the edge cases that arise we need to understand the problem at it's core. This is an attempt to define the problem with a few definitions and several straight forward real word examples - My intent here is to be very clear about the definitions of common terms that I have often misused in the past... ### Definitions: - **Product**: A thing that can be identified and has a unit of measure - sometimes referred to as an asset. For the purposes of our examples we will be dealing with physical products - real world objects. Every product has a lifecycle, it is made by something (produced) and ultimately consumed, they are often physically moved from one place to another along the way. There are many different types of products, for our purposes it is most useful to consider them based on how they are produced. - **Continuous Products**: Things that are continuously generated. A good example is mining of raw materials, usage of water, production of gasses. These products have a divisible unit of measure (a kilogram can be broken down into grams, grams into milligrams, etc). For the purposes of tracking consumption continuous products are often grouped into by material lots which gives them a set quantity; in which case they can be managed as batch products. - **Batch Products**: Products that are produced in bulk but grouped into a specific batch or lot. The batch is generally determined by the production run and (for all intents and purposes) units within a batch all share the same properties - they are fungible; if 100 units were produced unit 1 and unit 100 are interchangeable. Batch products can be continuous (divisible or measured by weight/volume) or discrete (counted at some unit level, an "EACH"). The lowest level of measurement is referred to as the Lowest Salable Unit (LSU). - **Unique Products**: One-of-a-kind products that have unique properties specific to that unit, these are non-fungible. - **Serialized Products**: This is not necessarily a separate production category, but important to distinguish here as it will cause confusion later. These products are often produced in batch, but each unit is given a distinct serial number. If unit 1 is assigned for a certain use it is no longer interchangeable with unit 100. These units are not divisible beyond the LSU. - **Product Distribution**: We rarely ever ship a single unit from a manufacturer to a customer, supply chains have a whole complex web of wholesalers, distributors, and retailers. In the real world products are moved in bulk and there are a few common practices we need to be aware of: - **Aggregation**: The process of grouping several units together for the purposes of distribution. I put 10 units in a box, 10 boxes in a carton, 10 cartons on a pallet - when I ship one pallet I actually ship 1000 units. *Note that it cannot be assumed that all of the units in a given aggregation came from the same batch, or are even the same product...* - **Disaggregation**: The breaking down of shipped units to allow for smaller shipments to be distributed further downstream - **Reaggregation**: Recombining disaggregated products for purposes of a new shipment. During reaggregation there is most certainly multiple batches and multiple products combined on the same pallet. If the units have an expiry date, it is common practice to reaggregate the oldest units (regardless of batch) for shipment. - **Product Visibility**: The ability to know where a product is in its life cycle and/or distribution path. Often referred to as "Track & Trace" for our purposes here we will define it as: - **Backward Visibility**: This is tracing a product lineage; it is looking upstream to to where a product has come from. If a product was moved from A to B to C, it is C's ability to know that it came from A. It is required from the end consumer to be able to prove the provenance of the product they now have. - **Forward Visibility**: This is tracking a product; it is looking downstream to where a product went. If a product moved from A to B to C, it is the ability for A to know that C now has it. It is a requirement that the originator of a product (the manufacturer) have this level of forward visibility - it is preferred if we have the option of forward visibility available for any participant in the distribution chain. - **Distribution Chain**: From the perspective of a given product this is all of the ecosystem participants that have held a "claim" on that product in sequential order. - **Product Claims**: As products move through their life cycle there are often several types of "claims" that participants involved in that distribution can make against a product. Here we can use the [Merriam Dictionary definition of a claim](https://www.merriam-webster.com/dictionary/claim) as "a right to something" or "an assertion open to challenge". The most common examples are tracking changes in ownership (fiscal responsibility) vs. changes in custody (physical possession) - where both ownership and custody are considered to grant certain rights over the product. If you borrow your friends watch they are still the owner, but you are currently the custodian - it's still the same watch, but there are multiple claims. There is much more detailed write up on this here: [[1. Token flow - managing product tokens with a claim-states table]] - **Product Data**: Referred to here on out as "Product Metadata" this is information that is specific to a product (or a batch of products) that should be accessible to participants who have a claim on that product. An example would be the information found on the product label, or some details about how it was produced. Because each claim holder may have some additional information about a given product (i.e., how was is packaged, at what temperature was it maintained), across it's lifecycle product data is more akin to a trail of breadcrumbs than to a definitive single source. Therefore the product metadata is not likely stored in one place, each participant that has a claim on a product has the ability to post updates to it's metadata, and they can store that data where they choose (this implies that they have the ability to make the data unavailable, but it should be clear that they are withholding something.) - **Product Status or State Data**: There is often information about a product that changes over time - total time out of refrigeration, product status, inspection results - these updates would be part of the current state of a given product. - **Product Definition Data**: This is information about the product that is core to what it is. Examples include: Batch Number, Expiation Date, Ingredients, etc. Things that if they changed, the nature of the product would change and it would not be the same product anymore. - **Product Restricted Data**: Data that is important to the definition of a product (I.e., the exact recipe or how to make the product, but that is not intended for the general public). It is generally know who might need to access this information (I.e., a regulator or an authority) and it is at the discretion of the data originator to determine who can access it. It is important to recognize here the distinction between product metadata and product transactions (I.e., creation, movement, and consumption). Product metadata is information about a given product and product transactions are events that happen which effect a given product. Later on we will see why it is important to not anchor business logic on product metadata, but to only rely on events captured on the network. - **Brand Owner**: The company or organization that has legal ownership of the brand under which the product is manufactured. It is important to mention here because in today's supply chain much of the responsibility, liability, and reputational risk resides with the brand owner - if they are contracting out the manufacture of their product to a third party and the third party does not meet quality standards it is the Brand owner that must address it. Further from a regulatory perspective it of the Brand owner that is on the hook for providing evidence that they are in compliance with various regulations. Brand Owners are known public entities. - **Product Token**: *Finally* we define the product token which is the mechanism we propose to use to address the above requirements. While there are many inventory management systems and 3rd party logistics software platforms out there none of them use the concept of a token for tracking inventory, mostly because of the privacy issues of doing this on a public network. And if you were to do it on a private network there are already established centralized platforms that can accomplish this. Product tokens are the main topic of my on-going posts in: [[0. The Product Token Handbook]]. One of the primary drivers behind using a product token approach is the interoperability component. We need to be able to represent our products in multiple networks/platforms while still adhering to the first principle of 'no double spend'. ### Examples: There are sooo many use cases that benefit from core product traceability... below are just a few examples that I believe cover the spectrum. While many of these initially have a regulatory/compliance slant, it should be noted that use cases rooted in growth potential are more likely to be sustainable for an organization. #### Forward Visibility: 1) Product Recalls: Recalls are generally issued for all products manufactured within a given timeframe from a specific facility. For the manufacturer this is almost always distinguished by the batch number. However, knowing *where* products of a given batch currently are and how much has been consumed is information required for efficient recalls that is missing in current systems. 2) Vendor Managed Inventory (VMI): When a supplier has an agreement with a customer to keep a minimum level of stock at the customer's site. By monitoring the stock level and consumption rate the supplier can proactively ship replenishments. This is very difficult manage in a many-to-many ecosystem today. 3) Production Planning: Using the same monitoring approach as with VMI factoring in actual product consumption rates reduces production buffers which ultimately reduces scrap and expired product. 4) Consignment Stock: Requires VMI, but in this case payment for the product is not done until the product is consumed. This approach incentives the customer to participate because it frees up capital by not having to carry the inventory on their balance sheets. Requires multiple claims to be tracked on the product token. 5) Rebates and Chargebacks: Having accurate consumption data and transfers of ownership allows rebates and chargebacks to be calculated (and possibly executed) automatically. 6) Customer Loyalty and Targeted Marketing: Generally we are tracking products just to the point of dispense (I.e., not actually linking them to the end customer, but just showing that that it has been sold); however, linking to the customer is a logical next step assuming some level of digital identity solution is in place. #### Backward Visibility: 1) Product Provenance: The ability for a customer to know exactly where their product came from and any other key information about it. For high value assets (I.e., a home) this is done today via title searches. 2) Anti Counterfeit: Using components of provenance plus patterns in product flow makes it much more difficult to inject counterfeit products into the ecosystem. 3) Customer Loyalty & Warranty Management: I lump these together because they are really both about the ability of the end consumer to connect with the manufacturer. There are obviously ways of doing this well today, but the nature of loyalty programs is changing. 4) Investigations and Disputes: When something does go wrong (damaged or unsafe products) the ability for a regulatory to execute their rights to backward visibility helps to efficiently identify the root cause. #### Environmental, Social and Governance (ESG): These examples leverage a combination of forward and backward visibility for the purposes of achieving ESG goals. I add these to separate section because this is often a leading topic for traceability. 1) Digital Product Passports: Evolving regulatory requirements today primarily focus on backward visibility for proving where products came from and which components went into them. Particularly in Europe with proposed directives such as [EU ESPR](https://commission.europa.eu/energy-climate-change-environment/standards-tools-and-labels/products-labelling-rules-and-requirements/sustainable-products/ecodesign-sustainable-products-regulation). These "passports" combine provenance with attributable product metadata for a given product or set of products. The attribution today primarily relies on the reputation and trust of the brand owner 2) Scope 3 Emissions Reporting: There are evolving regulations requiring companies to report on the total impact that their organization has on the environment. Part of these are the Scope 3 emissions which (among other things) require a manufacture to report on the emissions generated during the creation of the raw materials used in their own manufacturing process. This allocation of emissions at the product level is beginning to play out as an essential extension of product traceability. Recently the Interworks Alliance released a [Carbon Emission Token Protocol ](https://gbbcouncil.org/interwork-alliance-resources/cet-protocol/)which begins to prepare various industries for this approach. 3) Product Level Carbon Footprint: Similar to the requirements for Scope 3 there are pending regulations for proving the environmental impact of a given product for the purposes of cross-boarder taxation. Specifically the [EU Carbon Border Adjustment Mechanism](https://taxation-customs.ec.europa.eu/carbon-border-adjustment-mechanism_en) has requirements that the price of a product accurately accounts for the emissions generated during the production of that product; this in turn will have a direct impact on the amount of tax paid on that product. If companies can prove the completeness and accuracy of carbon allocations and credits against a specific product it follows that those companies will be best positioned to minimize their tax impact. ### Definition of Privacy: If you have followed along this far, there is one last important step... we need to accomplish the above in a provable/verifiable way, which is open for any valid business partner to participate in, while keeping the information (both product transactions and product metadata) restricted to only those to the distribution chain. So if I currently hold a claim on a product token, or have ever held one in the past, I should be able to "see" the current state and previous state claims on that token. For a more fine grained level of control we should consider that different types of claims (I.e., that of regulatory seizure vs. that of ownership) may have different types of visibility in terms of their ability to see forward or backward. *It is my personal opinion that both forward and backward visibility should be turned on by default, but with the option to turn it off in certain configurations* It is worth noting here that we are dealing with known business entities and it is ok if two businesses can be linked in public via their transactions, in fact in some regions/industries it is required that businesses publish their Authorized Trading Partners (ATPs). Having established ATPs addresses a lot of the issues around Know Your Customer / Anti-Money Laundering (KYC/AML) laws, and will likely be required for managing accounts with an organization as discussed here: [[4. Organizational Account Management for Product Token Flows]] Enterprises are not looking for full anonymity, they are looking for confidentiality in transactions between known business partners. This means that from an objective outsider looking in, they might be able to detect that A does business with B, but they should not have any information about what they are transacting or the frequency of transactions. ### Conclusion: This in no way is an actual conclusion, we are just scratching the surface of the nuanced approaches that are needed to accurately reflect real-life supply chain events on a network and in doing so eliminate much of the friction that hinders supply chain to day. My take on this is that the core components should be a public good that are open for all to use and build upon - a proprietary solution implies a gate keeper and a value aggregator which is exactly what we need to avoid. This is not to say that there will not be softwares that compete to leverage this approach, but they should add value via the applications they build on top and not require entire ecosystems to join their platform in order to provide insights.