Verifiable Supply Chain (VSC) — Requirements and Use Cases

This document defines requirements and use cases for representing supply chain events as Verifiable Credentials, enabling interoperable and cryptographically verifiable data exchange across organizational boundaries. It establishes the problem space, shared terminology, motivating scenarios, and twenty functional and five non-functional requirements that will guide the development of the VSC Core Data Model and related specifications.

The VSC framework maps [[EPCIS]] event semantics onto [[VC-DATA-MODEL]] representations, using [[DID-CORE]] for actor identity binding. It incorporates three normative vocabularies — the WCO Harmonized System (HS) for commodity classification, ICC INCOTERMS® for commercial terms, and UCP 600 for trade finance instruments — enabling a single VSC credential to serve as a self-contained trade document that answers what the product is, where commercial responsibility transfers, and how payment is governed. The approach is grounded in published W3C, GS1, WCO, ICC, ISO, IETF, and regulatory standards and aligns with established community work including the [[TRACEABILITY-V1]] vocabulary and [[UNTP]].

Two architectural frameworks extend the core model: the VSC Event Matrix — a five-dimensional cross-domain verification schema with forward-compatible extensibility and integrated machine learning feature extraction — and the VSC Regulatory Rule Compiler — a machine-executable compliance engine that compiles trade regulations into deterministic verification functions over the matrix dimensions. Together they enable a single verification architecture to process any trade event from any domain, governed by any standard, without domain-specific code.

This document is intended for:

Implementers building VSC-conformant software systems;
Specification authors drafting the VSC Core Data Model and related normative deliverables;
Regulators and policy teams evaluating VSC fitness for compliance scenarios;
Customs authorities and trade platforms seeking automated commodity classification and origin verification;
Financial institutions exploring cryptographic documentary compliance for trade finance; and
New contributors seeking to understand the scope and motivation of the VSC Community Group.

Introduction

Background and Motivation

Global supply chains are among the most complex information systems humans operate. They span hundreds of organizations, dozens of jurisdictions, and thousands of individual product movements per day. Despite this complexity, the underlying data infrastructure remains fragmented: proprietary formats, bilateral EDI agreements, and centralized intermediary platforms are the norm rather than the exception.

The GS1 [[EPCIS]] standard, widely adopted across retail, healthcare, and logistics, provides a common vocabulary for supply chain events — captures of who did what to which item, where, and when. However, EPCIS defines what to record, not how to prove it. A receiving party cannot cryptographically verify that an EPCIS record was created by an authorized party, has not been tampered with, or corresponds to any real-world act of authority.

Simultaneously, the W3C Verifiable Credentials Data Model and [[DID-CORE]] provide a mature, widely deployed infrastructure for cryptographically signed, decentralized identity. These technologies have been adopted in digital credentials for education, healthcare records, and government identity, but have not yet been systematically applied to supply chain event data.

Regulatory pressure is accelerating the need. The US [[DSCSA]] mandates electronic, interoperable tracing of prescription drug products across the entire pharmaceutical distribution chain. The EU [[EUDR]] requires due diligence documentation for commodities associated with deforestation. The EU [[EU-BEV]] requires battery passport data covering the full material supply chain. India's Drugs Rules, 1945 mandate QR codes on top 300 formulation brands and all APIs. These regulations require auditable, tamper-evident records — a property EPCIS alone cannot provide.

The Verifiable Supply Chain (VSC) framework addresses this gap by defining how [[EPCIS]] events can be represented as [[VC-DATA-MODEL]] credentials, binding event data to the issuing party's [[DID-CORE]] identifier and enabling cryptographic verification across organizational boundaries without requiring a shared central database. Beyond event integrity, VSC incorporates three normative vocabularies that transform credentials into self-contained trade documents: the WCO Harmonized System for commodity classification, ICC INCOTERMS® for commercial terms and risk allocation, and UCP 600 for trade finance instrument binding. Together with the VSC Event Matrix and Regulatory Rule Compiler, the framework provides a complete verification operating system for global trade.

Problem Statement

Current supply chain data systems exhibit three structural deficiencies that VSC is designed to address:

Fragmentation: No standard mechanism exists to exchange verifiable supply chain event records across organizational boundaries in a vendor-neutral way. Point-to-point integrations and proprietary platforms create data silos that prevent end-to-end visibility (see [[ISO28000]] Section 4.2 on supply chain security risk assessment).
Lack of Verifiability: EPCIS provides rich event semantics but contains no native mechanism for a receiver to verify the identity of the asserting party, the integrity of the record, or the authority of the issuer to make the claimed assertion. A well-formed EPCIS document is indistinguishable from a fabricated one without out-of-band authentication mechanisms.
Regulatory Non-Compliance Risk: Regulations including [[DSCSA]], [[EUDR]], [[EU-BEV]], and India's Drugs Rules require auditable, tamper-evident records of product provenance and chain of custody. Existing data systems cannot satisfy these requirements without significant bespoke engineering, creating compliance risk for supply chain participants across multiple jurisdictions simultaneously.
Commercial Liability Ambiguity: Even when event data is available, existing systems cannot programmatically determine who bears commercial responsibility when goods are damaged, delayed, or lost in transit. INCOTERMS® rules govern this liability but are not machine-readable in current supply chain data formats, leading to disputes that take weeks or months to resolve.

The VSC Approach

VSC addresses the deficiencies identified in Problem Statement by:

Preserving EPCIS semantics: The Event-to-Credential Mapping is a normative, lossless transformation. All EPCIS event fields (event type, temporal context, business context, product identifiers, read points) are preserved. The resulting Verifiable Credential is a superset of the source EPCIS event.
Binding identity to events: Each event credential is signed by the asserting Supply Chain Actor using a [[DID-CORE]] identifier. Verifiers can resolve the DID to retrieve the public key and verify the signature without contacting the issuer.
Enabling selective disclosure: Using [[VC-DATA-MODEL]] mechanisms (e.g., [[BBS-2023]] proofs or [[SD-JWT]]), holders can reveal only the event fields required by a given verification context, protecting commercially sensitive data while satisfying regulatory requirements.
Supporting chain-of-custody reconstruction: Individual event credentials can be linked by reference, enabling a verifier to reconstruct the full custody chain from issuance through delivery.
Embedding normative trade vocabularies: VSC incorporates the WCO Harmonized System (HS) for commodity classification, ICC INCOTERMS® for commercial terms and risk allocation, and UCP 600 for trade finance instrument binding. These vocabularies transform a VSC credential from an event record into a self-contained trade document that answers what the product is, where commercial responsibility transfers, and how payment is governed.
Providing architectural frameworks: The VSC Event Matrix expresses any trade event as a five-dimensional vector with forward-compatible extensibility and integrated machine learning feature extraction. The VSC Regulatory Rule Compiler compiles trade regulations into machine-executable verification functions, enabling a single verification architecture to process any event from any domain.
Aligning with existing community work: VSC builds on [[TRACEABILITY-V1]], [[TRACEABILITY-INTEROP]], and [[UNTP]], maximizing reuse of existing credential vocabularies and interoperability profiles.

VSC does not require distributed ledger technology. DID methods backed by web infrastructure (e.g., did:web) are explicitly supported and are expected to be the dominant deployment pattern for enterprise supply chains. Ledger-based DID methods MAY be used but are not privileged.

Document Conventions

Requirement identifiers take the form REQ-Xn where X is F (functional) or NF (non-functional) and n is a two-digit sequence number. Every requirement includes a rationale grounded in published standards or regulations, a specific testability statement to guide conformance test development, and normative references.

Use case identifiers take the form UC-n. Each use case cross-references the requirements it motivates.

Defined terms appear in bold style and are linked on first use in each section.

Document Structure

This document is organized into five parts:

Part I — Foundation: Conformance, Scope, Terminology, Conceptual Architecture, and Related Work establish the conceptual foundation.
Part II — Normative Vocabularies: HS Codes, Trade Finance, and INCOTERMS® define the standardized languages VSC speaks for commodity classification, payment instruments, and commercial terms.
Part III — Architectural Frameworks: The VSC Event Matrix and Regulatory Rule Compiler provide the cross-domain verification schema and machine-executable compliance engine.
Part IV — Use Cases and Requirements: Eleven use cases motivate twenty functional and five non-functional requirements with testability statements.
Part V — Cross-Cutting Concerns: Security, Privacy, Accessibility, Internationalization, and Future Work.

Conceptual Architecture

The Five-Layer Model

VSC operates as a five-layer architecture. Each layer addresses a distinct dimension of verifiability, and together they transform a physical supply chain event into a self-contained, cryptographically provable trade document:

Layer 1 — Physical Events (EPCIS 2.0): Captures what happened to which item, where, and when. EPCIS provides the event vocabulary: ObjectEvent, AggregationEvent, TransformationEvent, TransactionEvent, and AssociationEvent. Every VSC credential begins as an EPCIS event.
Layer 2 — Cryptographic Integrity (VC Data Model): Wraps each EPCIS event in a Verifiable Credential with a Data Integrity proof. The proof makes the event tamper-evident: any modification to the event data after issuance invalidates the proof. Selective disclosure mechanisms allow holders to reveal only the fields required by a given verification context.
Layer 3 — Organizational Identity (DID Core): Binds each credential to the asserting party's Decentralized Identifier. Verifiers resolve the DID to retrieve the public key and verify the proof independently, without contacting the issuer. DID methods are not prescribed; did:web is expected to be the dominant enterprise deployment pattern.
Layer 4 — Trust Anchor Governance (Trust Framework): Separates cryptographic proof verification from real-world authorization. A Trust Framework maintains the Issuer Registry of DIDs authorized to assert specific types of events in specific business contexts. Proof validity does not imply authorization — the registry check closes this gap.
Layer 5 — Sector and Regulatory Overlays: Applies jurisdiction-specific and industry-specific rules to the verified event. This layer incorporates the three normative vocabularies (HS Codes, INCOTERMS®, Trade Finance), the VSC Event Matrix for cross-domain verification, and the Regulatory Rule Compiler for machine-executable compliance.

Roles

VSC defines three primary roles, aligned with [[VC-DATA-MODEL]] Section 1.3. In supply chain deployments these roles are typically held by different organizations, though a single organization may act in multiple roles across different transactions.

Issuer: A Supply Chain Actor that asserts a Supply Chain Event and creates the corresponding Verifiable Credential. The issuer signs the credential using the cryptographic key material associated with its [[DID-CORE]] identifier. The issuer is responsible for the accuracy of the event claims, for maintaining Credential Status information, and — when applicable — for populating the HS Classification, INCOTERMS® Classification, and Trade Finance Instrument bindings that transform the credential into a self-contained trade document.
Holder: An entity that receives and stores Verifiable Credentials and may assemble them into Verifiable Presentations for submission to verifiers. In supply chain contexts, holders are typically downstream trading partners, freight forwarders, customs agents, or regulatory bodies. A holder may also be an issuer (e.g., a manufacturer issues a provenance credential and later presents it to a retailer). Holders apply Selective Disclosure to reveal only the fields required by the verification context.
Verifier: An entity that accepts Verifiable Credentials or Presentations and validates their integrity, authenticity, and policy compliance. Verifiers execute the Universal Verification Pattern: resolve the issuer's DID, verify the Data Integrity proof, check credential status, validate issuer authority against the Issuer Registry, and — when configured — apply machine-executable regulatory rules from the Regulatory Rule Compiler. Verifiers produce structured verification results including per-dimension status and a composite trust score.

EPCIS Event Types and VSC Mapping

[[EPCIS]] v2.0 defines five event types. VSC requires a normative credential schema for each. Every event type can carry the three normative vocabulary bindings (HS Classification, INCOTERMS® Classification, and Trade Finance Instrument) as optional credential subject extensions:

EPCIS Event Type	Typical Business Use	VSC Credential Schema (placeholder)	Normative Vocabularies Applicable
`ObjectEvent`	Commissioning, observation, shipping, receiving of items	`VscObjectEventCredential`	HS, INCOTERMS®, Trade Finance
`AggregationEvent`	Packing items into a container; disaggregating a pallet	`VscAggregationEventCredential`	HS
`TransformationEvent`	Manufacturing: input materials consumed, output products created	`VscTransformationEventCredential`	HS (input/output), INCOTERMS®
`TransactionEvent`	Linking events to business transactions (orders, invoices)	`VscTransactionEventCredential`	INCOTERMS®, Trade Finance
`AssociationEvent`	Associating sub-objects with a parent object	`VscAssociationEventCredential`	HS

The schema names in the table above are placeholders. Normative schema identifiers and JSON-LD context URIs will be defined in the VSC Core Data Model specification. The "Normative Vocabularies Applicable" column indicates which vocabulary bindings are relevant to each event type; all are optional and populated only when the business context requires them.

Object Model

The core objects in VSC are:

Supply Chain Event: The occurrence being recorded, conforming to one of the five [[EPCIS]] event types. The event carries the event-time, record-time, business step, disposition, read point, business location, and EPC or product class lists.
Verifiable Credential: The cryptographically signed representation of the event. The credential's issuer is the asserting Supply Chain Actor's DID. The credentialSubject contains the EPCIS Event fields and may include the hsClassification, incotermsClassification, and tradeFinance objects. The credential carries a credentialStatus endpoint for revocation checks and a termsOfUse reference to the governing Trust Framework.
Event Chain: A directed graph of Verifiable Credentials linked by credential identifier references. The chain enables reconstruction of provenance or custody histories. When TransformationEvent credentials carry input and output HS classifications, the chain enables automated Rules of Origin verification via Change in Tariff Classification (CTC).
Verifiable Presentation: A holder-assembled collection of event credentials (and optionally other credentials, e.g., certification credentials, insurance credentials, export license credentials) submitted to a verifier for a specific verification context such as customs clearance, regulatory audit, or Letter of Credit documentary compliance.
VSC Event Matrix: A five-dimensional vector representation of any supply chain event, with dimensions for Event (D1), Actor (D2), Product (D3), Commercial (D4), and Financial (D5). The matrix provides a unified grammar for cross-domain verification and produces structured output for machine learning feature extraction.

Information Flow

The VSC framework operates as a five-layer architecture. The diagram below shows how physical events, cryptographic integrity, organizational identity, governance and trust, and sector-specific regulatory overlays converge into a unified, verifiable supply chain system. Animated flow lines represent continuous, tamper-evident data transmission between actors and trust infrastructure.

Figure 1 — VSC Architecture: Five-layer convergence of physical events (EPCIS), cryptographic integrity (VC Data Model), organizational identity (DID Core), trust anchor governance (Trust Framework), and sector-specific regulatory overlays. Animated flow lines indicate continuous, verifiable data exchange across the supply chain.

Verification may fail if the DID cannot be resolved, the signature is invalid, the credential has been revoked, or the issuer is not in the required issuer registry. Verifier behavior in each failure case is defined in Requirements. Additional failure modes for HS misclassification, INCOTERMS® version mismatch, documentary discrepancies, and regulatory rule violations are defined in their respective normative sections and use cases.

Figure 2 — The Complete VSC Journey: From a physical event occurring in the real world, through EPCIS capture, Verifiable Credential issuance, enrichment with three normative vocabularies, assembly into the Event Matrix, verification through the Universal Pattern, to final trusted outcome. Every arrow represents a living, cryptographically secured process.

Harmonized System (HS) Codes — Normative Commodity Vocabulary

Overview

The Harmonized Commodity Description and Coding System (HS), maintained by the World Customs Organization (WCO), is the universal economic language for international trade. Over 200 countries and economies use HS codes as the basis for customs tariffs, trade statistics, rules of origin, and trade negotiations. The HS classifies approximately 5,000 commodity groups at the 6-digit level, with each country extending to 8, 10, or more digits for national tariff schedules.

VSC adopts HS codes as a normative commodity classification vocabulary that operates alongside [[EPCIS]] event semantics. While EPCIS describes what happened to an item, HS codes describe what the item is in a universally recognized taxonomy. This dual-vocabulary approach ensures that VSC credentials are immediately machine-readable by any customs authority, trade platform, or regulatory system worldwide without requiring translation or mapping.

HS Level	Digits	Example	VSC Usage
Chapter	2	30 — Pharmaceutical products	Sector identification for trust frameworks
Heading	4	3004 — Medicaments (dosed, for retail)	Product category for verification rules and Rules of Origin CTC tests
Subheading (WCO)	6	3004.90 — Other medicaments	Universal trade classification (200+ countries)
National tariff line	8–12	3004.90.11 — Specific formulation	Country-specific duty and regulation mapping

HS Code Binding in VSC Credentials

Every VSC event credential that describes a product, commodity, or trade item SHOULD include the applicable HS classification. The HS classification MUST be expressed using the hsClassification object with the following structure:

hsCode: The 6-digit WCO HS subheading code as a string with period separator (e.g., "3004.90"). REQUIRED for all product-bearing credentials.
hsCodeVersion: The HS nomenclature version year as a four-digit string (e.g., "2022", "2017"). The WCO revises the HS every five years; the next revision is 2027. REQUIRED when hsCode is present. This field is critical for cross-version interoperability: a credential classified under HS 2017 may not be directly comparable to HS 2022 classifications without version disambiguation.
hsCodeNational: The extended national tariff line code (8–12 digits) as a string. OPTIONAL — used when declaring to a specific customs jurisdiction.
hsCodeJurisdiction: The ISO 3166-1 alpha-2 country code indicating which national tariff schedule the hsCodeNational applies to. REQUIRED if hsCodeNational is present.
hsDescription: The WCO-recommended textual description of the goods at the declared heading/subheading level, expressed as a [[JSON-LD]] language-tagged string. RECOMMENDED. This provides the human-readable safety net that customs officers use to verify whether the numeric code was applied correctly.

Example JSON-LD representation:

{
  "credentialSubject": {
    "id": "urn:epc:id:sgtin:8901234.56789.0",
    "type": "TradeItem",
    "hsClassification": {
      "hsCode": "3004.90",
      "hsCodeVersion": "2022",
      "hsCodeNational": "3004.90.11",
      "hsCodeJurisdiction": "IN",
      "hsDescription": "Medicaments consisting of mixed or unmixed products for therapeutic or prophylactic uses, put up in measured doses or in forms or packings for retail sale"
    }
  }
}

The WCO revises the HS nomenclature every five years (most recently 2022, next revision 2027). VSC implementations SHOULD support multiple HS versions and the hsCodeVersion field enables verifiers to apply the correct classification rules for the nomenclature version in effect at the time the credential was issued.

HS Code Transformation in Manufacturing Events

In HS nomenclature, parts and accessories often fall under different headings than finished goods. For example, an active pharmaceutical ingredient (API) classified under HS 2933.39 (heterocyclic compounds) becomes a medicament under HS 3004.90 after formulation. This transformation of classification is a critical signal for Rules of Origin determination, customs valuation, and regulatory compliance.

When a VSC TransformationEvent is issued, the credential MAY include:

Input HS codes: The hsClassification of each input material, referenced from the input EPCs' credentials;
Output HS code: The hsClassification of the resulting output product;
HS Change Indicator: A machine-readable flag indicating whether the HS code changed at the chapter (2-digit), heading (4-digit), or subheading (6-digit) level between inputs and outputs.

Automated Rules of Origin via Change in Tariff Classification (CTC)

Most Free Trade Agreements (FTAs) use Change in Tariff Classification (CTC) as the primary criterion for determining whether a product qualifies as originating from a particular country. The CTC rule specifies the minimum level of HS transformation required: typically a change at the Chapter level (CC — 2 digits), Heading level (CTH — 4 digits), or Subheading level (CTSH — 6 digits).

Because VSC makes HS codes normative within event credentials, a VSC verifier can programmatically prove origin without human intervention:

Automated CTC Verification — Pharmaceutical Example

Automated CTC verification: HS heading changes from 2924 (input API) to 3004 (output medicament), satisfying the CTH rule under most pharmaceutical FTAs.

The VSC verifier performs the following automated CTC check:

Retrieve input HS codes from the TransformationEvent credential's input EPC references;
Retrieve the output HS code from the TransformationEvent credential;
Compare HS code segments at the FTA-specified level (Chapter, Heading, or Subheading);
If the input and output codes differ at or above the required level, the CTC rule is satisfied;
The verifier signals "Origin Confirmed" or "Origin Not Confirmed" with the specific HS segments compared.

HS-Based Risk Scoring and Compliance Screening

HS codes serve as the primary key for automated risk assessment in customs processing. VSC verifiers MAY implement HS-based risk scoring to automatically determine:

Whether the HS code requires additional credentials (e.g., export license for dual-use goods, CITES certificate for endangered species, pharmaceutical registration certificate);
Whether the product is subject to anti-dumping or countervailing duties;
Whether the HS code falls within a high-risk category requiring mandatory physical inspection;
Whether the importer's historical misclassification rate for this HS heading exceeds a threshold.

Regulatory Mapping via HS Codes

VSC verifiers MAY use the HS code in a credential to automatically determine:

Applicable customs duties and tariff rates (MFN and preferential);
Non-tariff measures (quotas, licenses, anti-dumping, countervailing duties);
Regulatory requirements (pharmaceutical registration, food safety certification, chemical controls);
Preferential trade agreement eligibility via CTC-based Rules of Origin;
Restricted or prohibited goods screening (CITES, Montreal Protocol, Basel Convention);
Dual-use and strategic goods export control screening;
Statistical reporting obligations.

Alignment with EPCIS

EPCIS v2.0 does not natively include an HS code field. VSC defines HS codes as a normative extension vocabulary within the ilmd (Instance/Lot Master Data) or as a top-level credential subject field. This approach:

Preserves full backward compatibility with [[EPCIS]] 2.0;
Enables customs authorities to query HS codes without parsing EPCIS business steps;
Keeps the event semantics (the movement) separate from the commodity classification (the identity), allowing the HS code to be verified once while the item moves through multiple business steps;
Allows sector trust frameworks to define verification rules based on HS chapter/heading scope;
Supports automated tariff classification, Rules of Origin verification, and risk scoring as part of the VSC verification pipeline.

REQ-F11 — HS Code Inclusion in Product Credentials

A VSC Issuer SHOULD include the hsClassification object in the credential subject of any event credential that describes a product, commodity, or trade item. When included, the hsCode and hsCodeVersion fields MUST be populated. The hsDescription field SHOULD be populated with the WCO-recommended description to provide a human-readable validation anchor.

HS codes are used by 200+ countries for customs clearance, tariff determination, trade statistics, and Rules of Origin. Embedding HS codes in VSC credentials enables instant regulatory classification without requiring customs authorities to parse product descriptions or maintain proprietary code mappings. The hsCodeVersion field addresses the WCO's five-year revision cycle, ensuring credentials remain verifiable across nomenclature boundaries.

A conformant issuer MUST produce a valid credential containing: (a) hsCode with a valid 6-digit HS code; (b) hsCodeVersion with the applicable WCO nomenclature year; (c) hsDescription with the WCO-recommended textual description; and optionally (d) hsCodeNational and hsCodeJurisdiction for jurisdiction-specific declarations. A conformant verifier MUST parse and validate the HS code against the WCO nomenclature for the stated version.

WCO HS Convention (1983) Articles 3, 4; WCO HS Nomenclature 2022 Edition; WTO Trade Facilitation Agreement Article 10.

REQ-F12 — HS Transformation in Manufacturing Events

A VSC Issuer MAY include input HS classifications and an HS change indicator in TransformationEvent credentials. When included, the input HS classifications MUST reference the HS codes from the input EPCs' credentials, and the output HS classification MUST be present. The HS change indicator MUST specify whether a change occurred at the Chapter (2-digit), Heading (4-digit), or Subheading (6-digit) level.

In HS nomenclature, parts and accessories often fall under different headings than finished goods. A TransformationEvent that captures this classification change provides the data foundation for automated Rules of Origin verification via Change in Tariff Classification (CTC). Most FTAs use CTC as the primary origin criterion, and a verifiable record of HS transformation enables programmatic origin determination without human intervention.

Given a TransformationEvent with input HS "2924.29" (Chapter 29) and output HS "3004.90" (Chapter 30), a conformant verifier MUST detect the chapter-level change and signal "CTC Satisfied at Chapter Level." A TransformationEvent where input and output HS codes are in the same heading MUST signal "No CTC Change."

WCO HS Convention; WTO Agreement on Rules of Origin Article 2; EU-India FTA Rules of Origin Protocol; USMCA Chapter 4 (Rules of Origin); AfCFTA Annex 2 on Rules of Origin.

Trade Finance and Payment Instrument Binding

Overview

International trade moves on credit. The Letter of Credit (LC), governed by the ICC Uniform Customs and Practice for Documentary Credits (UCP 600), remains the dominant payment mechanism for cross-border trade, facilitating over USD 2 trillion in annual transactions. An LC is fundamentally a documentary condition: the issuing bank promises to pay the beneficiary (seller) upon presentation of documents that strictly comply with the credit's terms. This is a purely document-based process — the bank deals in documents, not goods (UCP 600 Article 5).

VSC transforms the LC from a manual document-checking exercise into an automated cryptographic verification. Because VSC credentials are tamper-evident, DID-signed, and independently verifiable, they can satisfy the documentary requirements of a Letter of Credit without human document examination. This reduces the LC settlement cycle from 5–10 banking days to seconds, and eliminates the discrepancies that cause 70% of documentary presentations to be rejected on first presentation.

Traditional LC vs. VSC-Automated LC Settlement

VSC reduces Letter of Credit settlement from 5–10 banking days to seconds, eliminates documentary discrepancies, and transforms trade finance from manual document checking to automated cryptographic verification.

Payment Instrument Binding in VSC Credentials

A VSC commercial shipment credential MAY include a tradeFinance object that binds the shipment to the applicable payment instrument. The trade finance binding MUST use the following structure:

paymentInstrument: The type of trade finance instrument: "LC" (Letter of Credit), "DC" (Documentary Collection), "OA" (Open Account), or "AP" (Advance Payment). REQUIRED.
lcNumber: The Letter of Credit reference number as issued by the issuing bank. REQUIRED when paymentInstrument is "LC".
issuingBank: The issuing bank's SWIFT/BIC code and DID. REQUIRED when paymentInstrument is "LC" or "DC".
advisingBank: The advising/negotiating bank's SWIFT/BIC code and DID. OPTIONAL.
lcType: The LC type: "irrevocable" (standard under UCP 600 Article 3), "confirmed", "transferable", "revolving", or "standby". REQUIRED for LC instruments.
lcAmount: The LC amount in the stated currency. REQUIRED for LC instruments.
lcExpiryDate: The latest date for presentation of documents under the LC (UCP 600 Article 6). REQUIRED for LC instruments.
lcDocumentaryRequirements: An array of documentary requirements specified in the LC, each mapped to a VSC credential type that satisfies it. For example, a "Commercial Invoice" requirement maps to a VscCommercialShipmentCredential with hsClassification and incotermsClassification. REQUIRED for automated LC compliance checking.
lcPresentationStatus: The current status of the documentary presentation: "pending", "compliant", "discrepant", "paid", or "expired". RECOMMENDED — updated by the negotiating bank or smart contract upon presentation verification.
settlementTrigger: A reference to the specific event in the VSC event chain that triggers payment. For INCOTERMS® CIF/FOB, this is typically the incotermsRiskTransferEvent (on board vessel). For DDP, this is the arrival at named place event. RECOMMENDED — enables programmatic payment release.
titleTransferCondition: An optional field specifying the condition for transfer of title (ownership). While INCOTERMS® handle risk and cost, title transfer is governed by the sales contract and applicable law (CISG Articles 30–34, 41–44). When present, this field indicates whether title transfers upon payment, upon delivery of goods, or upon transfer of a negotiable bill of lading. OPTIONAL — enables integration with decentralized electronic Bills of Lading (eBL) systems and legal ownership tracking.

Example JSON-LD representation of the trade finance binding:

{
  "credentialSubject": {
    "id": "urn:epc:id:sscc:8901234.5678901234",
    "type": "CommercialShipment",
    "hsClassification": { "hsCode": "3004.90", "hsCodeVersion": "2022" },
    "incotermsClassification": {
      "incotermsRule": "CIF",
      "incotermsVersion": "2020",
      "incotermsNamedPlace": "Mombasa Port, Kenya",
      "incotermsRiskTransferEvent": "urn:epc:id:event:onboard-mumbai-001",
      "incotermsInsuranceRequired": true
    },
    "tradeFinance": {
      "paymentInstrument": "LC",
      "lcNumber": "LC2026-08921-IN-KE",
      "issuingBank": {
        "swiftBic": "KCBLKENAXXX",
        "did": "did:web:kcbbank.co.ke"
      },
      "advisingBank": {
        "swiftBic": "SBININBBXXX",
        "did": "did:web:sbi.co.in"
      },
      "lcType": "irrevocable",
      "lcAmount": { "value": "250000.00", "currency": "USD" },
      "lcExpiryDate": "2026-08-15",
      "lcDocumentaryRequirements": [
        { "requirement": "Commercial Invoice", "vcType": "VscCommercialShipmentCredential", "satisfied": true },
        { "requirement": "Bill of Lading", "vcType": "VscTransportEventCredential", "satisfied": true },
        { "requirement": "Certificate of Origin", "vcType": "VscOriginCredential", "satisfied": true },
        { "requirement": "Packing List", "vcType": "VscAggregationEventCredential", "satisfied": true },
        { "requirement": "Insurance Certificate", "vcType": "VscInsuranceCredential", "satisfied": true }
      ],
      "lcPresentationStatus": "pending",
      "settlementTrigger": "urn:epc:id:event:onboard-mumbai-001",
      "titleTransferCondition": "upon_payment"
    }
  }
}

INCOTERMS® 2020 explicitly state that they do not deal with transfer of property/title in the goods (ICC Publication No. 723E, Introduction, paragraph 8). Title transfer is governed by the underlying sales contract and applicable national law (e.g., CISG Articles 30–34, UK Sale of Goods Act 1979, US UCC Article 2). The titleTransferCondition field provides a bridge between VSC's risk/cost determination (via INCOTERMS®) and the separate legal mechanism of ownership transfer. When integrated with a decentralized electronic Bill of Lading (eBL) system based on DIDs, this field enables automated ownership transfer upon satisfaction of the stated condition.

Automated Documentary Compliance Verification

Under UCP 600 Article 14, a bank must examine a documentary presentation on the basis of the documents alone to determine whether they appear on their face to constitute a complying presentation. This examination is currently performed manually by trade finance professionals who check each document against the LC terms, the UCP 600 rules, and international standard banking practice (ISBP 745).

VSC transforms this process into automated cryptographic compliance verification:

The LC terms are expressed as a machine-readable set of documentary requirements, each mapped to a VSC credential type;
The seller (beneficiary) assembles a Verifiable Presentation containing all required VSC credentials;
The VSC verifier (which may be operated by the negotiating bank, a trade finance platform, or a decentralized smart contract) checks each credential against the LC requirements;
For each requirement, the verifier confirms: (a) the credential type matches the requirement; (b) the credential's DID issuer is authorized; (c) the Data Integrity proof is valid; (d) the credential content satisfies the LC conditions (e.g., HS code matches, INCOTERMS® rule matches, shipment date within LC validity, goods description consistent);
If all requirements are satisfied, the verifier signals "Compliant Presentation" and triggers the settlement process;
If any requirement is not satisfied, the verifier signals "Discrepant Presentation" with specific discrepancy details.

Automated LC Documentary Compliance — VSC Verification Pipeline

Automated LC documentary compliance: five documentary requirements verified cryptographically in seconds, triggering payment of USD 250,000 — compared to 5–10 banking days under traditional manual checking.

REQ-F15 — Trade Finance Instrument Binding

A VSC Issuer MAY include the tradeFinance object in the credential subject of a commercial shipment credential. When included, the paymentInstrument, lcNumber (for LCs), issuingBank, and lcDocumentaryRequirements fields MUST be populated. The settlementTrigger field SHOULD reference the specific event in the VSC event chain that triggers payment.

Letters of Credit facilitate over USD 2 trillion in trade annually under UCP 600. Currently, documentary compliance checking is manual, taking 5–10 banking days with a 70% first-presentation rejection rate due to discrepancies. By binding VSC credentials to LC documentary requirements, compliance can be verified cryptographically in seconds with zero discrepancies. The lcDocumentaryRequirements array maps each LC requirement to a VSC credential type, enabling automated matching and verification. The settlementTrigger field links payment to a verifiable event (typically the INCOTERMS® risk transfer event), enabling programmatic payment release.

A conformant issuer MUST produce a valid commercial shipment credential containing the tradeFinance object with all required fields for the stated payment instrument. A conformant verifier MUST: (a) verify that all lcDocumentaryRequirements are satisfied by VSC credentials in the presented VP; (b) for each requirement, confirm the credential type matches, the DID issuer is authorized, the proof is valid, and the content satisfies the LC conditions; (c) signal "Compliant" or "Discrepant" with specific discrepancy details for each requirement.

ICC UCP 600 Articles 2, 3, 6, 14, 15, 28; ICC ISBP 745; UNCITRAL Model Law on Electronic Transferable Records (MLETR) 2017; eUCP Version 2.0 (2019).

REQ-F16 — Automated Documentary Compliance and Settlement Trigger

A VSC Verifier MAY implement automated documentary compliance checking for Letters of Credit under UCP 600. When implemented, the verifier MUST check all documentary requirements specified in the lcDocumentaryRequirements array against the credentials in the presented VP. If all requirements are satisfied, the verifier MUST signal "Compliant Presentation" and MAY trigger the settlement process. If any requirement is not satisfied, the verifier MUST signal "Discrepant Presentation" with specific discrepancy details for each failed requirement, including the credential ID, the failed condition, and the applicable UCP 600 article reference.

UCP 600 Article 14(a) requires banks to examine a presentation on the basis of the documents alone. Article 14(b) allows a maximum of five banking days for examination. Article 16 requires banks to give a single notice of refusal stating each discrepancy. VSC automates this entire process: examination is performed cryptographically in seconds, and discrepancies are identified programmatically with specific credential and condition references. This eliminates the 70% first-presentation rejection rate caused by human document checking errors.

Given a VP containing five VSC credentials matching five LC documentary requirements, all with valid proofs and authorized issuers: the verifier MUST signal "Compliant Presentation" within 5 seconds. Given a VP missing the Insurance Certificate requirement for a CIF shipment: the verifier MUST signal "Discrepant Presentation — Missing: Insurance Certificate (UCP 600 Art. 28) — CIF requires insurance credential."

ICC UCP 600 Articles 14–16, 28; ICC ISBP 745 Paragraphs A1–A39; eUCP Version 2.0 Articles e1–e7; UNCITRAL MLETR Articles 8–12.

The VSC Event Matrix — Cross-Domain Verification Schema

Design Principle: Orthogonal Dimensions, Forward-Compatible Extensibility

Every verifiable supply chain interaction can be expressed as a vector in a five-dimensional matrix. Each dimension draws its values from a single, globally standardized vocabulary. The dimensions are orthogonal — changing the value in one dimension does not require changing values in any other. Because the dimensions are independent, the verification logic for each dimension is decoupled from all others. A verifier processes each dimension separately, using only the rules applicable to that dimension's vocabulary.

This orthogonality is what gives the Event Matrix its structural longevity. When a vocabulary standard updates — the WCO revises the HS nomenclature, the ICC releases a new INCOTERMS® edition, a new DID method emerges — only the affected dimension's validation rules change. The verification engine does not need to be rewritten. When a new regulatory requirement emerges that does not fit within the existing five dimensions, a sixth dimension can be added. Verifiers that have not been updated to recognize the new dimension continue to verify the five they know. Verifiers that have been updated verify all six. Neither class of verifier breaks.

This is forward-compatible extensibility: the architecture accepts dimensions it does not yet understand without failure, and new dimensions can be added without modifying the verification logic for existing ones.

The VSC Event Matrix — Five Orthogonal Dimensions

The VSC Event Matrix — Five orthogonal dimensions, each drawing from a single standardized vocabulary, producing combinatorial expressiveness that covers multimodal trade events. The "+Dn" indicator shows that additional dimensions can be added without breaking existing ones.

Matrix Representation Format

The Event Matrix is expressed as a compact, colon-delimited vector format for transmission and a structured JSON object for programmatic processing. Both representations are semantically equivalent.

Compact Vector Format:

D1:EVENT        D2:ACTOR           D3:PRODUCT        D4:COMMERCIAL      D5:FINANCIAL
────────────    ──────────────     ─────────────     ──────────────     ────────────
ObjectEvent     did:mfr:in:001     HS:3004.90:22     EXW:2020:Mumbai    OA:open
AggregationEv   did:whl:ae:002     HS:0901.11:22     FOB:2020:Santos    LC:irrevoc
TransformEv     did:cell:kr:003    HS:8507.60:22     CIF:2020:Dubai     DC:sight
TransactionEv   did:dist:ke:004    HS:8517.13:22     DDP:2020:Nairobi   AP:advance
AssociationEv   did:recy:eu:005    HS:8703.80:22     CPT:2020:Rotter    LC:confirmed

Structured JSON Format:

{
  "vsc:event": {
    "matrix": ["ObjectEvent", "did:mfr:in:001", "HS:3004.90:22", "EXW:2020:Mumbai", "OA:open"],
    "dimensions": {
      "D1": {"type": "ObjectEvent", "source": "EPCIS", "version": "2.0"},
      "D2": {"did": "did:mfr:in:001", "method": "web", "resolved": false},
      "D3": {"hsCode": "3004.90", "hsVersion": "2022", "description": "Medicaments...", "national": "3004.90.11", "jurisdiction": "IN"},
      "D4": {"incoterms": "EXW", "incotermsVersion": "2020", "namedPlace": "Mumbai", "riskTransferEvent": null, "insuranceRequired": false},
      "D5": {"instrument": "OA", "lcNumber": null, "issuingBank": null, "requirements": []}
    },
    "verification": {
      "status": "pending",
      "checks": ["D2.resolve", "D2.proof", "D3.hsValidate", "D4.incotermsValidate"],
      "results": {},
      "score": null
    }
  }
}

D1 values use abbreviated EPCIS event type names. D2 values are fully qualified DIDs. D3 values use the format HS:<6-digit>:<version-year>. D4 values use the format <INCOTERMS®>:<version-year>:<named-place>. D5 values use the format <instrument>:<subtype>. Unpopulated dimensions are represented by an empty string in the compact format and by null fields in the JSON format.

Cross-Industry Application Examples

The following table demonstrates how the same five-column matrix expresses events across different industries using different vocabulary values. The verification pattern is identical; only the dimension values change.

Industry	D1: EVENT	D2: ACTOR	D3: PRODUCT	D4: COMMERCIAL	D5: FINANCIAL
Pharmaceuticals	`ObjectEvent`	`did:mfr:in:001`	`HS:3004.90:22` (Vaccines)	`EXW:2020:Mumbai`	`OA:open`
Agriculture	`TransformEv`	`did:proc:br:002`	`HS:0901.11:22` (Green Coffee)	`FOB:2020:Santos`	`LC:irrevoc`
Electronics	`AggregationEv`	`did:wh:vn:003`	`HS:8517.13:22` (Smartphones)	`CIF:2020:Dubai`	`DC:sight`
Battery Passport	`AssociationEv`	`did:recy:eu:004`	`HS:8507.60:22` (Lithium-ion)	`DDP:2020:Nairobi`	`AP:advance`
Cold Chain Logistics	`ObjectEvent`	`did:log:ae:005`	`HS:3002.15:22` (mRNA vaccines)	`CIF:2020:Mombasa`	`LC:confirmed`
Textiles & Garments	`TransactionEv`	`did:exp:in:006`	`HS:6204.42:22` (Cotton dresses)	`FOB:2020:Chennai`	`OA:open`

In each case, the verifier executes the same verification pattern: resolve D2 DID, verify proof, validate D3 HS code against the declared version, validate D4 INCOTERMS® rule against the declared version, and check D5 documentary requirements if applicable. The verifier does not need pharmaceutical domain knowledge to verify a vaccine shipment, or agricultural domain knowledge to verify a coffee shipment. It needs only the validation rules for each dimension's vocabulary.

The Universal Verification Pattern

Because every event is expressed as a vector in the same matrix, every verifier executes the same pattern regardless of the domain:

Parse the vector — extract the value for each populated dimension;
Resolve identities — for D2, resolve each DID to its DID Document and retrieve verification methods;
Verify proofs — for each credential in the presentation, verify the Data Integrity proof against the issuer's public key;
Check status — for each credential, query the credentialStatus endpoint and verify the credential has not been revoked;
Validate authority — for D2, check each issuer DID against the applicable Trust Framework Issuer Registry;
Validate dimensions — for D3, verify HS code against the declared HS version; for D4, verify INCOTERMS® rule against the declared INCOTERMS® version; for D5, verify documentary compliance against LC requirements if applicable;
Compute trust score — aggregate per-dimension verification results into a composite trust score for downstream ML processing;
Determine outcome — signal "Verified" with dimension-specific confirmations, or signal "Rejected" with specific dimension failure codes.

This pattern is invariant across use cases. A pharmaceutical shipment under CIF with LC payment executes exactly the same verification steps as a food export under FOB with open account terms. The only difference is which dimensions are populated and which vocabulary values are present. The verifier does not need to understand pharmaceuticals or food — it needs to understand the verification pattern.

Machine Learning Integration

The Event Matrix produces structured, labeled data at every verification step. Because each dimension value is drawn from a finite vocabulary, the matrix forms a well-defined feature space suitable for supervised machine learning. Each verified event becomes a training row where the dimension values are features and the verification outcome is the label.

Feature Extraction:

# Each VSC matrix row produces a structured feature vector
features = {
    "event_type":          "ObjectEvent",       # D1
    "did_method":          "web",               # D2: extracted from DID
    "hs_chapter":          "30",                # D3: first 2 digits
    "hs_heading":          "3004",              # D3: first 4 digits
    "incoterms_rule":      "CIF",               # D4
    "incoterms_version":   "2020",              # D4
    "payment_instrument":  "LC",                # D5
    "has_lc":              True,                # D5: derived
    "is_cif_cip":          True,                # D4: derived (insurance check required)
    "named_place_region":  "Mombasa"            # D4: geographic risk factor
}

# Labels produced by verification
labels = {
    "status":   "accepted",                     # or "rejected", "flagged"
    "score":    0.97,                           # trust score 0.0–1.0
    "anomaly":  False                           # anomaly detection flag
}

ML Use Cases Enabled by the Matrix Structure:

Model	Input Features	Output	Application
Anomaly Detection	Full matrix row + historical verification patterns	Anomaly score 0.0–1.0	Flag shipments exhibiting unusual dimension combinations before verification
Trust Score Regression	D2 (DID history) + D3 (HS chapter risk) + D4 (INCOTERMS® rule) + D5 (instrument)	Predicted trust score 0.0–1.0	Pre-verification risk assessment for customs and banks
HS Misclassification Detection	D3 (HS code) + D3 (text description) + D1 (event type)	Misclassification probability	Automated customs fraud detection
LC Discrepancy Prediction	D5 (documentary requirements) + D2 (issuer history) + D4 (INCOTERMS®)	Discrepancy probability per document	Pre-submission LC compliance checking for exporters
Route Risk Scoring	D4 (named place) + D1 (event chain) + historical incident data	Route risk score 0.0–1.0	Marine insurance underwriting and premium calculation

After processing a sufficient volume of verified events, the ML models can predict verification outcomes before submission. A shipment with a predicted trust score below a configurable threshold can be flagged for additional scrutiny before the credential is presented to the verifier. This closes the loop from verification to prediction to prevention.

Essential Properties

Orthogonality: Each dimension is independent. Changing the INCOTERMS® rule from FOB to CIF does not require changing the HS code, the event type, or the financial instrument. A verifier can validate each dimension separately, using the vocabulary and rules appropriate to that dimension, without understanding the others.
Forward-Compatible Extensibility: New dimensions can be added without breaking existing ones. If a future regulation requires carbon accounting per shipment leg, a sixth dimension (D6) can be added with values drawn from the GLEC Framework or ISO 14083. Existing verifiers that do not recognize D6 verify D1–D5 without error. Verifiers that do recognize D6 execute the additional validation rules. The "+Dn" indicator in the matrix diagram represents this property.
Standardized Vocabularies: Each dimension draws its values from a single, globally recognized standard. D1 from EPCIS 2.0. D2 from DID Core. D3 from the WCO Harmonized System. D4 from ICC INCOTERMS® 2020. D5 from UCP 600. No dimension uses a VSC-proprietary vocabulary. Every value in the matrix is meaningful to its respective domain authority without translation.
Versioned Immutability: Every vocabulary entry that changes over time carries its own version identifier. HS codes carry hsCodeVersion. INCOTERMS® rules carry incotermsVersion. A verifier encountering a value from an unfamiliar version can either cross-walk to the current version or flag the credential for version review. The matrix does not break when vocabularies evolve.
Minimal Sufficient Representation: A VSC event vector requires only the values necessary for verification in its context. A domestic shipment within India may populate only D1 (ObjectEvent), D2 (Manufacturer DID), and D3 (HS Code with Indian national tariff line). It does not require D4 or D5. The matrix is not a mandatory schema — it is a grammar. Any subset of dimensions that satisfies the verification context is valid.
Machine-Readable Feature Space: Because each dimension value is drawn from a finite vocabulary and each verification produces a structured outcome, the matrix forms a well-defined feature space for supervised machine learning. Every verification decision becomes a labeled training row, enabling anomaly detection, trust scoring, and predictive compliance models without additional data transformation.

REQ-F17 — Event Matrix Representation

A VSC Issuer MAY express any supply chain event as a vector in the VSC Event Matrix. When using matrix representation, the issuer MUST populate each dimension with values drawn from the standardized vocabulary registered for that dimension. The issuer MAY omit dimensions that are not applicable to the verification context. A VSC Verifier MUST execute the universal verification pattern against all populated dimensions. The verifier MUST produce a structured verification result including per-dimension status and a composite trust score suitable for downstream ML processing.

The Event Matrix provides a unified grammar for expressing any verifiable supply chain interaction. By decomposing events into orthogonal dimensions with standardized vocabularies, the matrix enables a single verification architecture to process events from any domain without domain-specific code. The orthogonality property ensures that new dimensions can be added without breaking existing verification logic. The structured verification output ensures that every verification decision contributes to the ML training corpus.

Given an event expressed as a five-dimensional vector populated with valid values from each dimension's vocabulary: a conformant verifier MUST execute the universal verification pattern and signal "Verified" with dimension-specific confirmations and a composite trust score. Given an event with an invalid value in any populated dimension: the verifier MUST signal "Rejected" with the specific dimension and the specific validation failure. A verifier encountering an unpopulated dimension MUST skip verification for that dimension without error. A verifier encountering an unrecognized dimension MUST skip verification for that dimension without error.

This specification Sections 5 (Architecture), 8 (Requirements); WCO HS Convention; ICC INCOTERMS® 2020; UCP 600; DID Core; EPCIS 2.0.

REQ-F18 — Dimension Extensibility

The VSC Event Matrix MUST support the addition of new dimensions without requiring modification to existing dimension vocabularies or verification logic. A new dimension MUST be registered with a unique dimension identifier, a standardized vocabulary source, and versioning rules. Existing verifiers MUST process events containing unknown dimensions by verifying only the dimensions they recognize, without signaling an error for unrecognized dimensions. New verifiers MAY verify the additional dimensions and produce dimension-specific confirmations for each.

The forward-compatible extensibility of VSC depends on the matrix being extensible without breaking backward compatibility. When a new regulatory requirement emerges — such as carbon accounting under CBAM, digital product passports under ESPR, or human rights due diligence under CSDDD — it must be expressible as a new dimension without requiring all verifiers to upgrade simultaneously. Verifiers that do not yet support the new dimension must still correctly verify the dimensions they do support. This enables gradual adoption of new regulatory requirements without disrupting existing trade flows.

Given an event expressed as a six-dimensional vector where D6 is an unrecognized dimension: a conformant verifier MUST verify D1–D5 without error and MUST NOT signal an error for the unrecognized D6. A verifier that does recognize D6 MUST verify all six dimensions and signal dimension-specific confirmations for each. The trust score computation MUST include recognized dimensions and MUST exclude unrecognized dimensions.

This specification Section X+3; JSON-LD 1.1 Section 5 (Context Extension); REQ-NF04 (Extensibility); CBAM Regulation (EU) 2023/956; ESPR Regulation (EU) 2024/1781; CSDDD Directive (EU) 2024/1760.

INCOTERMS® — Normative Commercial Terms Vocabulary

Overview

INCOTERMS® (International Commercial Terms), published by the International Chamber of Commerce (ICC), are the universal language of commercial responsibility in international trade. The current version, INCOTERMS® 2020, defines eleven three-letter terms that precisely allocate costs, risks, and responsibilities between buyer and seller at every stage of the shipment journey. These terms are referenced in virtually every commercial invoice, letter of credit, marine insurance policy, and sales contract worldwide.

VSC adopts INCOTERMS® as a normative commercial terms vocabulary that operates alongside HS codes for commodity classification. While HS codes describe what the product is, INCOTERMS® describe where responsibility transfers and who bears the risk at each point. Together, they form the complete commercial identity of a trade transaction.

Category	Rule	Mode	Risk Transfer Point	VSC Automation
Any Mode	EXW — Ex Works	All	Seller's premises	Risk stays with buyer from origin · No transport verification needed by seller
Any Mode	FCA — Free Carrier	All	Named place (carrier)	Risk transfers at first carrier · Verify handover event
Any Mode	CPT — Carriage Paid To	All	First carrier (risk) / Destination (cost)	Split risk/cost transfer · Verify two separate points
Any Mode	CIP — Carriage and Insurance Paid To	All	First carrier (risk) / Destination (cost)	Insurance credential required · Verify coverage level
Any Mode	DAP — Delivered at Place	All	Named destination (before unloading)	Verify arrival at named place · Seller risk until arrival
Any Mode	DPU — Delivered at Place Unloaded	All	Named destination (after unloading)	Verify unloading completion · Seller risk includes unloading
Any Mode	DDP — Delivered Duty Paid	All	Named destination (cleared)	Maximum seller obligation · Verify customs clearance + duty payment
Sea/Waterway	FAS — Free Alongside Ship	Sea	Alongside vessel at port	Verify placement alongside vessel · Port event credential
Sea/Waterway	FOB — Free On Board	Sea	On board vessel at port	Verify on-board event · Most common sea freight term
Sea/Waterway	CFR — Cost and Freight	Sea	On board vessel (risk) / Destination (cost)	Split risk/cost · Verify on-board + freight payment
Sea/Waterway	CIF — Cost, Insurance and Freight	Sea	On board vessel (risk) / Destination (cost)	Insurance credential mandatory · Minimum cover ICC (C) 110%

Why INCOTERMS Are Critical to Verifiable Supply Chains

A supply chain credential system without INCOTERMS can verify what happened but cannot determine who is responsible. Consider this scenario:

A shipment of vaccines moves from Mumbai to Mombasa under CIF terms.
The temperature logger records a 9.2°C excursion during the ocean freight leg.
Without INCOTERMS, the verifier cannot determine whether the seller (Indian exporter) or buyer (Kenyan importer) bears the loss.
With INCOTERMS CIF embedded in the credential, the verifier knows: risk transferred when goods were placed on board the vessel in Mumbai. The ocean freight leg is buyer's risk. The buyer bears the loss — but may have an insurance claim.

This is the difference between knowing what happened and knowing who pays for it. INCOTERMS transform VSC from a tracking system into a commercial liability determination engine.

INCOTERMS® Binding in VSC Credentials

Every VSC event credential that represents a commercial shipment SHOULD include the applicable INCOTERMS® rule. The INCOTERMS® classification MUST be expressed using the incotermsClassification object with the following structure:

incotermsRule: The three-letter INCOTERMS® rule code (e.g., "FOB", "CIF", "DDP"). Must be one of the eleven rules defined in INCOTERMS® 2020. REQUIRED for all commercial shipment credentials.
incotermsVersion: The INCOTERMS® edition year (e.g., "2020"). The ICC revises INCOTERMS® approximately every ten years. REQUIRED — critical because the responsibilities under INCOTERMS® 2010 CIF differ from INCOTERMS® 2020 CIF (notably, insurance coverage requirements).
incotermsNamedPlace: The specific geographic location stipulated in the contract (e.g., "Nhava Sheva Port, Mumbai, India" for FOB, or "Mombasa Port, Kenya" for DAP). This must match the named place in the sales contract. REQUIRED.
incotermsRiskTransferEvent: A reference to the specific EPCIS event in the chain where risk transfers from seller to buyer under the applicable INCOTERMS® rule. For FOB, this is the "on board vessel" event. For DAP, this is the "arrived at named place" event. RECOMMENDED — enables automated risk determination.
incotermsInsuranceRequired: A boolean indicating whether the INCOTERMS® rule requires the seller to provide insurance (true for CIP and CIF; false for all other rules). RECOMMENDED — when true, the verifier can automatically check for a linked insurance credential.
incotermsModeOfTransport: The applicable transport mode: "any" for the seven rules that apply to all modes, or "sea" for the four rules (FAS, FOB, CFR, CIF) that apply only to sea and inland waterway transport. RECOMMENDED — enables validation that the INCOTERMS® rule is appropriate for the actual transport mode used.

Example JSON-LD representation of the INCOTERMS® classification within a VSC credential subject:

{
  "credentialSubject": {
    "id": "urn:epc:id:sscc:8901234.5678901234",
    "type": "CommercialShipment",
    "hsClassification": {
      "hsCode": "3004.90",
      "hsCodeVersion": "2022",
      "hsDescription": "Medicaments consisting of mixed products... for retail sale"
    },
    "incotermsClassification": {
      "incotermsRule": "CIF",
      "incotermsVersion": "2020",
      "incotermsNamedPlace": "Mombasa Port, Kenya",
      "incotermsRiskTransferEvent": "urn:epc:id:event:obj-001-onboard-mumbai",
      "incotermsInsuranceRequired": true,
      "incotermsModeOfTransport": "sea"
    }
  }
}

The combination of HS code and INCOTERMS® in a single credential provides the complete commercial identity of a trade transaction: HS code defines what is being traded and under what regulatory regime; INCOTERMS® define where commercial responsibility transfers. Together, they enable fully automated customs processing, duty assessment, insurance claims, and commercial dispute resolution — without human interpretation.

Automated Risk and Responsibility Determination

Because VSC captures both the INCOTERMS® rule and the complete event chain with timestamps and locations, a VSC verifier can programmatically determine commercial liability for any event in the supply chain:

Automated INCOTERMS Liability Determination — CIF Mumbai to Mombasa

Automated INCOTERMS liability determination: under CIF, risk transfers when goods are placed on board the vessel in Mumbai (marked by the red line), even though the seller pays freight to Mombasa. A temperature excursion during ocean freight is buyer's risk.

The VSC verifier performs the following automated liability determination:

Extract the incotermsRule from the shipment credential;
Identify the incotermsRiskTransferEvent in the event chain;
For any adverse event (damage, temperature excursion, delay, loss), determine whether the event timestamp is before or after the risk transfer point;
If before: seller bears the loss. If after: buyer bears the loss;
If incotermsInsuranceRequired is true (CIF/CIP), verify that an insurance credential is linked and that coverage meets the minimum ICC requirements for the stated INCOTERMS® version;
Output: automated liability determination with specific INCOTERMS® rule citation, risk transfer event reference, and insurance claim eligibility.

Insurance Verification for CIF and CIP

Under INCOTERMS® 2020, CIF and CIP require the seller to provide insurance coverage. The requirements differ:

CIF: Seller must obtain minimum cover as defined by Institute Cargo Clauses (C) of the Institute of London Underwriters, covering at least 110% of the invoice value. This is a defined minimum — the buyer may request higher cover at their own cost.
CIP: Seller must obtain Institute Cargo Clauses (A) cover — the highest level of cover — at 110% of invoice value. This is a significant change from INCOTERMS® 2010, where CIP also required only minimum (C) cover.

VSC verifiers MAY validate that insurance credentials linked to CIF/CIP shipments meet these minimum requirements by checking the insurance coverage level, insured value, and the ICC clause reference against the incotermsVersion declared.

INCOTERMS® 2010 CIP required only ICC (C) minimum cover. INCOTERMS® 2020 CIP requires ICC (A) all-risk cover. A CIP shipment under 2010 rules with only ICC (C) cover is compliant; the same coverage under 2020 rules is non-compliant. The incotermsVersion field is therefore essential for correct insurance verification. Always verify the version before applying coverage requirements.

Commercial Dispute Resolution

INCOTERMS® combined with the VSC event chain creates a self-proving evidence package for commercial disputes:

Cargo damage claim: The verifier identifies the damage event in the chain, compares its timestamp to the INCOTERMS® risk transfer event, and determines which party bore the risk at that moment. The entire evidence chain — including the INCOTERMS® rule, the risk transfer event, and the damage event — is cryptographically verifiable.
Demurrage and detention: The verifier calculates the time between arrival and pickup from timestamps in the event chain and determines which party is responsible for port storage charges based on the INCOTERMS® rule.
Non-delivery: If the event chain terminates before the INCOTERMS® named place, the verifier can identify the last recorded event and determine whether the seller fulfilled their delivery obligation under the applicable rule.

This transforms commercial dispute resolution from a document discovery exercise (weeks to months) into a cryptographic verification exercise (seconds). The evidence is the credential chain itself — tamper-evident, DID-signed, and independently verifiable by any party without access to any party's internal systems.

REQ-F13 — INCOTERMS® Inclusion in Commercial Shipment Credentials

A VSC Issuer SHOULD include the incotermsClassification object in the credential subject of any event credential that represents a commercial shipment. When included, the incotermsRule, incotermsVersion, and incotermsNamedPlace fields MUST be populated. The incotermsRiskTransferEvent field SHOULD reference the specific EPCIS event where risk transfers under the declared rule.

INCOTERMS® are referenced in virtually every international sales contract, commercial invoice, letter of credit, and marine insurance policy. Without INCOTERMS®, a verifiable supply chain can determine what happened but cannot determine who bears commercial responsibility. The INCOTERMS® version field is essential because rules change between editions — notably, INCOTERMS® 2020 CIP requires ICC (A) all-risk insurance while INCOTERMS® 2010 CIP required only ICC (C) minimum cover. The risk transfer event reference enables automated liability determination for damage, delay, and loss.

A conformant issuer MUST produce a valid credential containing: (a) incotermsRule with a valid three-letter INCOTERMS® 2020 rule code; (b) incotermsVersion with the applicable edition year; (c) incotermsNamedPlace with the geographic location stipulated in the contract; and (d) incotermsRiskTransferEvent referencing a valid event in the chain. A conformant verifier MUST validate the INCOTERMS® rule against the INCOTERMS® edition stated and MUST reject rules not defined in that edition. For CIF and CIP, the verifier SHOULD verify that a linked insurance credential meets the minimum coverage requirements for the declared version.

ICC INCOTERMS® 2020; ICC Publication No. 723E; UN Convention on Contracts for the International Sale of Goods (CISG) Article 31–34; UCP 600 Articles 19–27.

REQ-F14 — Automated INCOTERMS Liability Determination

A VSC Verifier MAY implement automated liability determination using the INCOTERMS® rule and the event chain. When implemented, the verifier MUST compare the timestamp of any adverse event (damage, excursion, delay, loss) to the incotermsRiskTransferEvent timestamp. If the adverse event occurred before the risk transfer point, the verifier MUST signal "Seller bears risk." If after, the verifier MUST signal "Buyer bears risk." For CIF and CIP shipments, the verifier MUST indicate whether insurance coverage is available based on the linked insurance credential.

Commercial disputes over cargo loss and damage cost the global trade industry billions annually in legal fees, survey costs, and delayed settlements. Automated INCOTERMS-based liability determination using cryptographically verifiable event timestamps eliminates ambiguity about when risk transferred and which party bears responsibility. This is particularly critical for temperature-sensitive pharmaceutical shipments where excursion timing relative to the risk transfer point determines whether the manufacturer or the buyer bears the loss.

Given a CIF shipment with risk transfer at "on board Mumbai" (T=0), a temperature excursion at T+24h (ocean transit), and an insurance credential with ICC (C) cover at 110%: the verifier MUST signal "Buyer bears risk · Insurance claim available · ICC (C) cover confirmed at 110%." If no insurance credential is linked to a CIF shipment, the verifier MUST signal "CIF requires insurance · No insurance credential found."

ICC INCOTERMS® 2020 Rules CIF and CIP; Institute Cargo Clauses (A), (B), (C); Marine Insurance Act 1906 (UK); UCP 600 Article 28 (Insurance Documents).

Use Cases

This section describes motivating scenarios for VSC. Each use case includes actors, preconditions, a nominal flow, failure modes, and a mapping to the requirements it motivates. Use cases are non-normative.

UC-01: Raw Material Provenance for Deforestation Due Diligence

Regulatory driver: EU Deforestation Regulation [[EUDR]], Article 3 — operators must ensure commodities are deforestation-free and legally produced.
Actors: Raw material supplier (issuer); first processor (holder/issuer); EU market operator / importer (holder/verifier); EU competent authority (verifier).
Preconditions: Supplier holds a did:web identifier registered with a sector trust framework. Importer has declared a reference DID set of accepted supplier issuers.

Nominal flow:

A soy supplier in Brazil harvests a batch and records an ObjectEvent in their EPCIS system with the batch EPC, harvest timestamp, geo-coordinates of the plot, and species information.
The supplier's VSC-conformant software applies the Event-to-Credential Mapping and signs a VscObjectEventCredential, with an extension for geospatial data and the relevant commodity type.
The credential includes a reference to the supplier's deforestation-free certification credential (issued by a certification body) as a linked credential.
The signed credential is transmitted to the first processor (crusher), who stores it and issues their own ObjectEvent credential for the crushing step, referencing the supplier's credential.
The EU importer requests a Verifiable Presentation from the processor containing the full Event Chain from harvest to processed shipment.
The importer's system verifies each credential in the chain: DID resolution, signature, revocation status, and presence in the sector Issuer Registry.
The importer submits the presentation to the EU Information System for EUDR due diligence statements.

Failure modes:

Missing link: The processor's credential does not reference the supplier's credential. The importer's system SHOULD detect the gap in the Event Chain and flag the presentation as incomplete.
Revoked certification: The certification credential referenced in step 3 has been revoked. The verifier MUST treat the linked certification as invalid; the event credential itself remains valid but the claim of deforestation-free status is unsupported.
DID not resolvable: The supplier's DID cannot be resolved. The verifier MUST NOT accept the credential and SHOULD surface a specific error indicating DID resolution failure.

Requirements motivated: REQ-F01, REQ-F02, REQ-F03, REQ-F04, REQ-F07, REQ-NF03.

UC-02: Pharmaceutical Custody Transfer (DSCSA Compliance)

Regulatory driver: US Drug Supply Chain Security Act [[DSCSA]] Section 582 — electronic, interoperable product tracing at the package level by November 2023. Grounded in 21 CFR Part 205, 207, 210–211.
Actors: Manufacturer (issuer); wholesaler (holder/issuer); dispenser / pharmacy (holder/verifier); US FDA (verifier).
Preconditions: All actors are registered in an FDA-recognized DSCSA authorized trading partner registry that maps GLN identifiers to DIDs.

Part 1 — Actors, Preconditions, and Custody Transfer Flow

Figure 2a — Actors, preconditions, and the four-step custody transfer flow from manufacturer commissioning through wholesale distribution to final pharmacy delivery.

Nominal flow:

The manufacturer applies a serialized SGTIN (GS1 item-level identifier) to each drug package and records an ObjectEvent (bizStep: commissioning) as a signed VSC credential.
At shipping, the manufacturer records an ObjectEvent (bizStep: shipping) credential for the pallet SSCC, referencing the commissioned item credentials via AggregationEvent.
The wholesaler records an ObjectEvent (bizStep: receiving) and issues their own credential referencing the manufacturer's shipping credential by its credential identifier.
The process repeats at each custody transfer (repackaging, onward shipment, final delivery to pharmacy).
The pharmacy's dispensing system requests a Verifiable Presentation covering the product's full custody chain before dispensing.
The presentation is verified: each credential's signature, issuer DID, revocation status, and authorized trading partner registration are confirmed.
In the event of a recall, the manufacturer revokes the relevant event credentials. Verifiers checking revocation status MUST reject these credentials and SHOULD surface a specific recall indicator.

Part 2 — Pharmacy Verification Gate and Recall Propagation

Figure 2b — Pharmacy verification pipeline (top) and recall revocation propagation flow (bottom).

Figure 4 — VSC Verifiable Presentation (VP) as it would appear to a customs officer, bank, or regulator. The card shows the complete shipment identity: product classification (HS code), commercial terms (INCOTERMS® CIF), trade finance (LC), the four-event custody chain with DID verification for each actor, cold chain temperature log with excursion flagged, and a composite trust score with all verification checks listed.

Failure modes:

Salami injection attack: An adversary inserts a fabricated custody transfer credential between two legitimate steps. The verifier MUST detect that the fabricated credential's issuer is not in the authorized trading partner registry.
Credential replay: A credential valid for one shipment is replayed against a different shipment. Credentials SHOULD carry a transaction-scoped identifier binding them to a specific shipment context.
Revocation propagation delay: The recall is issued but the pharmacy has cached a stale revocation status. Implementations SHOULD define maximum cache lifetimes for revocation status (see REQ-F08).

Part 3 — Failure Modes, Mitigations, and Requirements Traceability

Figure 2c — Three failure modes with mitigations and the seven requirements motivated by this use case.

Requirements motivated: REQ-F01, REQ-F02, REQ-F03, REQ-F04, REQ-F05, REQ-F08, REQ-NF01.

UC-03: Automated Customs Clearance

Regulatory driver: WCO SAFE Framework of Standards to Secure and Facilitate Global Trade; EU Union Customs Code (UCC) Article 163; WTO Trade Facilitation Agreement Article 10; UN/CEFACT Single Window Recommendation 33.
Actors: Exporter (issuer); freight forwarder (holder); customs authority (verifier).
Preconditions: Customs authority publishes a cryptographically verifiable trusted issuer registry of accepted certification bodies, chambers of commerce (origin), and inspection agencies. All actors hold DIDs registered in the relevant trade trust framework.

Part 1 — Actors, Preconditions, and Verifiable Presentation Assembly

Figure 3a — Three trade actors, the customs Trusted Issuer Registry, and how the exporter assembles three credential types into a single Verifiable Presentation for automated clearance.

Part 2 — Automated Clearance Pipeline and Selective Disclosure

Figure 3b — The three-step automated customs clearance pipeline from VP submission through automated verification to clearance decision, with selective disclosure detail showing only required fields revealed.

Nominal flow:

The exporter assembles a Verifiable Presentation containing: an origin credential (country of origin declaration from an accredited Chamber of Commerce), an inspection credential (phytosanitary or product safety from an authorized inspection agency such as SGS or Bureau Veritas), and transport event credentials covering the journey from factory to port of loading.
The presentation uses Selective Disclosure to reveal only the fields required by customs (e.g., HS tariff codes, declared value for duty assessment, country of origin) without exposing commercially sensitive pricing, supplier identity, or detailed commercial invoice data.
The freight forwarder's system submits the presentation to the customs authority's automated clearance API, compliant with the UN/CEFACT Single Window data model and the WCO Data Model.
The customs system verifies each credential against its cryptographically verifiable Trusted Issuer Registry, checks Data Integrity proofs and revocation status on each credential, and runs automated rules including UN sanctions list screening, tariff classification validation against the Harmonized System, and declared value plausibility checks.
Clearance is granted automatically or a referral for physical inspection is issued, with the complete verification result recorded as an audit event credential for regulatory record-keeping under UCC Article 166.

Part 3 — Failure Modes, Mitigations, and Requirements Traceability

Figure 3c — Two failure modes with specific mitigations and the five requirements motivated by the customs clearance use case.

Failure modes:

Partial presentation: The presentation is missing the inspection credential. The customs system SHOULD surface a specific missing-credential error rather than a generic verification failure, indicating which credential type is absent and the expected issuer category.
Selective disclosure proof failure: A malformed [[BBS-2023]] or [[SD-JWT]] proof is submitted. The verifier MUST reject the credential and SHOULD indicate the proof type and specific failure reason to enable the submitter to correct and resubmit.

Requirements motivated: REQ-F05, REQ-F06, REQ-F07, REQ-NF02, REQ-NF03.

UC-04: Battery Passport for EV Supply Chain

Regulatory driver: EU Battery and Electric Vehicle Regulation [[EU-BEV]], Article 77 — battery passport required for EV batteries from February 2027.
Actors: Cathode material supplier (issuer); cell manufacturer (holder/issuer); battery pack manufacturer (holder/issuer); vehicle OEM (holder/verifier); EU market surveillance authority (verifier); end consumer (verifier).
Preconditions: Battery identifier issued using GS1 Digital Link [[GS1-DIGITAL-LINK]] scheme resolving to the battery passport.

Nominal flow:

The cathode material supplier issues ObjectEvent credentials for each batch, including cobalt and lithium provenance data, mine location, and responsible sourcing certification references.
The cell manufacturer issues TransformationEvent credentials mapping input material batches (cathode, anode, electrolyte) to output cell identifiers.
The battery pack manufacturer assembles cell credentials into AggregationEvent credentials and issues a composite battery passport presentation referencing all upstream event credentials.
The vehicle OEM's system verifies the full passport presentation and stores it linked to the Vehicle Identification Number (VIN).
A consumer or recycler can scan a GS1 Digital Link QR code on the battery, resolve the battery passport, and verify the event chain.

Failure modes:

TransformationEvent linking gap: The cell manufacturer fails to reference upstream cathode credentials. The OEM system SHOULD flag the TransformationEvent as having unverified input provenance.
Performance at scale: A battery contains thousands of cells; each cell may have multiple upstream event credentials. Verifier performance MUST NOT degrade unacceptably at this scale (see REQ-NF01).

Requirements motivated: REQ-F01, REQ-F04, REQ-F06, REQ-NF01, REQ-NF04.

UC-05: Product Recall Propagation

Regulatory driver: General Product Safety Regulation (EU) 2023/988; US CPSC recall authority.
Actors: Manufacturer (issuer, revocation authority); downstream holders; regulators; retailers.
Preconditions: All event credentials for the affected product batch are known and the manufacturer controls the credential status service.

Nominal flow:

A safety defect is identified. The manufacturer's system identifies all event credentials linked to the affected batch using batch-level identifiers.
The manufacturer revokes the ObjectEvent credential for the affected batch via the Credential Status service. The revocation is cryptographically signed by the manufacturer's DID.
Any downstream verifier checking an affected credential against the status service receives a revoked status and MUST reject the credential.
Downstream holders receive a recall notification (out-of-band) and can verify the revocation independently by resolving the credential status.
The regulator can independently verify the breadth of the recall by querying which credentials issued by the manufacturer have been revoked for the affected lot.

Requirements motivated: REQ-F03, REQ-F08, REQ-NF01.

UC-06: Regulatory Audit Trail

Regulatory driver: General requirement across regulated industries (pharma, food, aerospace) for multi-year auditable records.
Actors: Multiple supply chain actors (issuers/holders); sector regulator (verifier).
Preconditions: Credentials have been issued and held for up to 10 years. Some issuer DIDs may have changed or been retired.

Nominal flow:

A regulator issues a data request to a holder for all event credentials related to a specific product class over a 5-year period.
The holder assembles a Verifiable Presentation with selective disclosure applied to protect third-party business data.
The regulator's system verifies each credential. For credentials where the issuer DID is no longer resolvable, the system checks a historical DID log maintained by the sector trust framework.
The audit result is recorded as a signed audit event credential by the regulator, completing the audit trail.

Failure modes:

Historical DID resolution: If a DID was deactivated, verifiers MUST have a mechanism to obtain the historical public key material needed to verify credentials signed before deactivation (see REQ-NF05).

Requirements motivated: REQ-F05, REQ-F07, REQ-NF02, REQ-NF05.

UC-07: Indian Pharmaceutical Track-and-Trace (QR Code Mandate Compliance)

Regulatory driver: Drugs and Cosmetics Act, 1940 [[DCA-1940]]; Drugs Rules, 1945 — G.S.R. 922(E) dated 28.12.2023 mandating QR Code on primary packaging for top 300 drug formulation brands (Schedule H2) and all Active Pharmaceutical Ingredients (bulk drugs) manufactured or imported, effective 1st August 2023; Revised Schedule M (Good Manufacturing Practices) effective 29.06.2024 for manufacturers with turnover > ₹250 crores and 01.01.2026 for smaller manufacturers [[PIB-DRUG-QUALITY]].
Actors: Indian pharmaceutical manufacturer (issuer); API supplier / importer (issuer); wholesale distributor / stockist (holder); retail pharmacy / Jan Aushadhi Kendra (holder/verifier); CDSCO / State Drug Controller (verifier).
Preconditions: Manufacturer holds a valid drug manufacturing license from the State Drug Controller and is compliant with revised Schedule M GMP requirements. API suppliers have QR-coded bulk drug packaging per Drugs Rules 1945 amendment. All actors are registered in the CDSCO SUGAM online portal with DIDs mapped to their manufacturing license and GSTIN identifiers. The top 300 drug formulations are listed in Schedule H2 of the Drugs Rules.

Part 1 — Indian Pharma Supply Chain Actors and QR Code Mandate Scope

Figure 7a — Indian pharmaceutical supply chain actors, QR Code mandate scope under Drugs Rules 1945 G.S.R. 922(E), and key CDSCO regulatory statistics for FY 2024–25. Source: PIB Release, 24 March 2026 [citation:1].

Part 2 — VSC-Enabled QR Code Verification Flow

Figure 7b — VSC-enabled QR Code verification flow from API supplier through manufacturer to retail pharmacy/consumer. Each QR Code resolves to a VSC credential with DID-based proof of authenticity.

Nominal flow:

An API manufacturer in Hyderabad produces a batch of Paracetamol BP and applies a QR Code on each packaging level as mandated by the Drugs Rules 1945 amendment. The QR Code encodes a GS1 Digital Link URI that resolves to a VSC ObjectEvent credential signed with the API supplier's DID, containing batch ID, manufacturing date, expiry, GSTIN, and CDSCO license number.
A formulation manufacturer in Baddi (Himachal Pradesh) receives the API batch, verifies the API credential via DID resolution and proof verification, and uses it as input for manufacturing Paracetamol 500mg tablets — a Schedule H2 brand. The manufacturer issues a VSC TransformationEvent credential referencing the API credential, with QR Code on primary packaging containing finished product batch, MRP, expiry, and manufacturing license details.
The finished product moves through the distribution chain (C&F agent → super stockist → stockist → retail). Each intermediary can scan the QR Code to verify batch authenticity against the VSC credential without contacting the manufacturer.
A consumer at a Jan Aushadhi Kendra (Pradhan Mantri Bhartiya Janaushadhi Pariyojana outlet) scans the QR Code using their mobile phone. The GS1 Digital Link resolves to the VSC credential. The verification app resolves the manufacturer's DID, verifies the Data Integrity proof, and confirms: the medicine is authentic, within expiry, from a CDSCO-licensed manufacturer, and not flagged as recalled or counterfeit.
CDSCO inspectors conduct risk-based inspections using the SUGAM Labs portal [citation:1]. During inspection, they scan QR Codes on sampled products to instantly verify the full custody chain — from API source to finished product — against VSC credentials. Non-compliance findings are recorded as verifiable audit credentials for regulatory action.
In case of a Not of Standard Quality (NSQ) finding, the manufacturer revokes the affected batch credentials via the credentialStatus endpoint. Any downstream verifier scanning the QR Code will receive a "revoked" status and reject the product.

Part 3 — Failure Modes, Mitigations, and Requirements Traceability

Figure 7c — Three failure modes with mitigations, and the seven requirements motivated by the Indian pharma track-and-trace use case. Regulatory statistics from CDSCO FY 2024–25 [citation:1].

Failure modes:

Counterfeit / Spurious Drug Detection: A QR Code on a counterfeit product resolves to a credential whose issuer DID is not in the CDSCO-authorized manufacturer registry, or the credential proof fails verification. The verifier MUST reject the product and surface a specific "issuer not authorized" or "proof invalid" error. In FY 2024–25, 245 spurious/adulterated drug samples were detected across India [[PIB-DRUG-QUALITY]]. VSC makes this detection instant and consumer-accessible rather than lab-dependent.
QR Code Cloning: Counterfeiters clone a legitimate QR Code from a genuine batch onto counterfeit products. The same batch identifier appears at multiple geographically dispersed verification points simultaneously. The verifier SHOULD detect anomalous verification patterns (same batch ID scanned in Mumbai and Kolkata within minutes) and flag potential cloning for CDSCO investigation.
NSQ Detection and Recall Propagation: CDSCO testing identifies a batch as Not of Standard Quality (3,104 NSQ samples in FY 2024–25). The manufacturer revokes the batch credential. Pharmacies relying on cached status may continue dispensing. Implementations MUST respect maximum cache lifetimes of 24 hours for pharmaceutical verification contexts (REQ-F08).

Requirements motivated: REQ-F01, REQ-F03, REQ-F04, REQ-F05, REQ-F07, REQ-F08, REQ-NF01.

UC-08: Cross-Border Cold Chain Logistics with IoT-Verified Temperature Integrity

Regulatory driver: WHO Model Guidance for the Storage and Transport of Time- and Temperature-Sensitive Pharmaceutical Products (2021); IATA Perishable Cargo Regulations (PCR) Chapter 17; EU Guidelines on Good Distribution Practice of Medicinal Products (2013/C 343/01) Annex 13; US FDA 21 CFR Part 211 Subpart H (Storage and Distribution); Indian Drugs Rules, 1945 Revised Schedule M Paragraph 16 (Storage and Distribution).
Actors: Vaccine manufacturer (issuer — Belgium); temperature-logger IoT device (issuer — on each shipment); air freight carrier (holder/issuer); cold chain logistics provider (holder/issuer — Dubai hub); customs authority (verifier — India/Mumbai Air Cargo Complex); receiving hospital pharmacy (verifier — Kenya); WHO / national regulatory authority (audit verifier).
Preconditions: IoT temperature loggers are calibrated and registered with DIDs. Logistics providers are registered in the IATA CEIV Pharma certified partner registry, mapped to DIDs. All actors accept the WHO/PQS prequalified cold chain equipment standards. The shipment is a WHO-prequalified vaccine requiring 2°C–8°C continuous cold chain per manufacturer specifications.

Nominal flow:

A WHO-prequalified vaccine manufacturer in Brussels commissions a shipment of 50,000 doses requiring 2°C–8°C continuous cold chain. The manufacturer issues a VSC ObjectEvent credential with the shipment SSCC, product GTIN, batch number, expiry date, and the declared temperature specification claim. A calibrated IoT temperature logger (registered with its own DID) is placed inside the active cold box.
The IoT logger records temperature at configured intervals (every 30 minutes per WHO/PQS specification). Each reading is signed by the logger's DID and becomes a VSC ObjectEvent credential containing: eventTime, temperature value, GPS coordinates, and the logger's DID as issuer. This creates a cryptographically verifiable, tamper-evident temperature log that no human can alter.
At each logistics checkpoint (Brussels departure, Dubai CEIV Pharma hub transshipment, Mumbai Air Cargo Complex arrival, Nairobi final delivery), the cold chain logistics provider scans the shipment and issues a VSC ObjectEvent credential referencing both the manufacturer's credential and the IoT logger's temperature credentials. Each custody transfer is linked into the Event Chain.
A temperature excursion is detected during the Dubai-to-Mumbai leg: the logger records 9.2°C, exceeding the 2°C–8°C specification. This temperature reading becomes a VSC credential with disposition "excursion_detected." The logistics provider's system automatically flags the shipment.
At Mumbai Air Cargo Complex, Indian Customs verifies the shipment. The verifier resolves each actor's DID, verifies all VSC proofs, and checks the temperature chain. The system detects the 9.2°C excursion at the DXB→BOM leg, cross-references against the manufacturer's declared 2°C–8°C specification, and triggers conditional acceptance with referral for physical inspection per Drugs Rules Schedule M Paragraph 16.
At the rural health centre in Kenya, the receiving pharmacist scans the shipment QR code. The verification app shows the complete temperature history, the excursion event, the customs inspection result, and any quality test outcome. The pharmacist makes an informed decision about vaccine usability based on verifiable evidence.
WHO and the Kenya Pharmacy and Poisons Board can audit the full shipment history — including the temperature excursion and the conditional acceptance decision — as verifiable audit credentials for post-market surveillance.

Failure modes:

Temperature Log Tampering: A logistics provider attempts to alter the temperature record to hide an excursion (changing 9.2°C to 5.0°C in their transit report). Since each temperature reading is independently signed by the IoT logger's DID, any tampered reading fails Data Integrity proof verification. The verifier MUST reject the credential and surface "proof invalid" with the specific credential ID and logger DID.
Missing Temperature Event (Chain Gap): The IoT logger stops recording during a critical flight segment, creating an 8-hour gap with no temperature data. The verifier detects the gap in the Event Chain and signals "missing predecessor" or "chain gap" with the specific time window. This triggers a conditional acceptance with mandatory quality testing before the product can be administered.
Unauthorized Logistics Actor (Spoofing): A non-certified handler at an intermediate airport inserts a fabricated custody transfer credential into the chain. The verifier checks the handler's DID against the IATA CEIV Pharma certified partner registry. Since the DID is not registered, the credential is rejected with "issuer not authorized" error (REQ-F07).

Requirements motivated: REQ-F01, REQ-F02, REQ-F03, REQ-F04, REQ-F07, REQ-F09, REQ-NF04.

UC-09: HS Code-Driven Automated Customs Declaration with Rules of Origin

Regulatory driver: WCO Harmonized System Convention (1983); WTO Trade Facilitation Agreement (TFA) Article 10.1 (Formalities and Documentation Requirements); WTO Agreement on Rules of Origin (1994) Article 2; EU Union Customs Code (UCC) Article 56–57 (Tariff Classification) and Article 59–63 (Rules of Origin); US Tariff Act of 1930 Section 484 (19 U.S.C. §1484); Indian Customs Act, 1962 Section 14 and Customs Tariff Act, 1975.
Actors: Exporter / manufacturer (issuer — declares HS code and HS transformation in product and TransformationEvent credentials); customs broker / freight forwarder (holder — assembles customs declaration VP with origin claim); customs authority (verifier — validates HS classification, performs automated CTC Rules of Origin verification, assesses duty at preferential rate, conducts risk scoring).
Preconditions: Product credentials include HS classification per REQ-F11. TransformationEvent credentials include input/output HS codes per REQ-F12. Customs authority publishes machine-readable tariff schedule and Product-Specific Rules (PSR) keyed by HS heading. Preferential trade agreement has machine-readable Rules of Origin schedule including CTC requirements per HS heading.

Nominal flow:

An Indian pharmaceutical manufacturer in Hyderabad imports Para-aminophenol (HS 2924.29, Chapter 29) from a Chinese supplier. The Chinese supplier issues a VSC ObjectEvent credential with the HS classification of the API.
The Indian manufacturer processes the API through formulation into Paracetamol 500mg tablets. The manufacturer issues a VSC TransformationEvent credential that includes: input HS codes (2924.29, 2915.24 — both Chapter 29), output HS code (3004.90 — Chapter 30), and the HS change indicator showing a Chapter-level change (CC). The manufacturer's DID is registered in the DGFT authorized exporter registry.
The manufacturer exports the finished tablets to a German importer, claiming preferential duty under the EU-India Free Trade Agreement. The customs broker assembles a Verifiable Presentation containing: the product VC with HS 3004.90, the TransformationEvent VC proving CTC Chapter change, and the Certificate of Origin VC.
German Customs (Zoll) receives the VP through the ATLAS system. The automated verifier: (a) resolves the manufacturer's DID and verifies all proofs; (b) extracts the input HS (2924.29, Ch. 29) and output HS (3004.90, Ch. 30) from the TransformationEvent; (c) checks the EU-India FTA Product-Specific Rule for Heading 3004, which requires "CC — Change in Chapter"; (d) confirms input Chapter 29 ≠ output Chapter 30 → CC satisfied → Origin: India confirmed; (e) applies 0% preferential duty rate instead of 6.5% MFN rate; (f) performs HS-based risk scoring: HS 3004 → LOW RISK → no additional license required.
The same product credential is reused for a shipment to Kenya. Kenya Customs (KRA) processes through TradeNet Single Window. The verifier applies the EAC CET schedule (0% for HS 3004) and the AfCFTA Rules of Origin. The same CTC data automatically confirms origin and applies 0% duty.

Failure modes:

HS Code Misclassification: The exporter declares HS 3004.90 (medicaments) but the hsDescription field states "Food supplement containing vitamins and minerals." The verifier's classification engine detects the mismatch between the numeric code (pharmaceutical) and the textual description (food supplement, which belongs in HS 2106.90). The verifier flags the credential for manual classification review and suspends duty assessment pending reclassification.
HS Version Mismatch: The credential uses HS 2017 nomenclature but the importing country has migrated to HS 2022 where the product classification has changed. The verifier detects the version mismatch via the hsCodeVersion field and signals a classification review requirement, preventing incorrect duty assessment.
CTC Rule Not Satisfied: An exporter claims preferential origin but the TransformationEvent shows input HS 3004.90 (same heading as output) — meaning no substantial transformation occurred (e.g., simple repackaging). The verifier detects that the HS heading did not change, the CTC rule is not satisfied, and origin is denied. The MFN duty rate is applied instead of the preferential rate.
Missing Export License for Controlled HS Code: A credential declares HS 9301.10 (military weapons). The HS-based risk scorer identifies this as a controlled commodity requiring an export license. The verifier checks for a linked Export License VC issued by the competent national authority. No license VC is present. The credential is rejected with "missing required license for HS 9301.10 — export license required."

Requirements motivated: REQ-F01, REQ-F03, REQ-F05, REQ-F07, REQ-F11, REQ-F12, REQ-NF03, REQ-NF04.

UC-10: INCOTERMS®-Driven Liability and Insurance Determination

Regulatory driver: ICC INCOTERMS® 2020 (Publication No. 723E); UN Convention on Contracts for the International Sale of Goods (CISG) Articles 31–34 and 66–70 (Risk and Delivery); Institute Cargo Clauses (A), (B), (C); UCP 600 Articles 19–27 (Transport Documents) and Article 28 (Insurance Documents); Marine Insurance Act 1906 (UK) as adopted by common law jurisdictions worldwide.
Actors: Exporter / seller (issuer — declares INCOTERMS® rule in shipment credential); buyer / importer (verifier — determines liability for loss events); marine cargo insurer (issuer — issues insurance credential linked to shipment); claims adjuster / surveyor (issuer — issues inspection event credential documenting damage); arbitrator / court (verifier — resolves commercial dispute using VSC evidence chain).
Preconditions: Shipment credential includes INCOTERMS® classification per REQ-F13. Event chain captures all transport events with timestamps and geolocations. The risk transfer event is explicitly referenced in the INCOTERMS® classification. Insurance credential is linked for CIF/CIP shipments. All actors have DIDs registered in the relevant trade trust framework.

Part 1 — Complete Commercial Picture: HS Code + INCOTERMS® + Event Chain

Figure 10a — The complete commercial picture: one VSC credential combines product identity (HS code), commercial terms (INCOTERMS®), and verifiable journey (event chain) to answer every question a customs authority, insurer, bank, arbitrator, or regulator could ask.

Part 2 — Automated Dispute Resolution: CIF Temperature Excursion

Figure 10b — Automated dispute resolution: a CIF shipment with a temperature excursion during ocean freight. The VSC verifier determines that the excursion occurred after risk transferred to the buyer, and confirms insurance coverage is available — in seconds, not weeks.

Nominal flow:

An Indian pharmaceutical exporter (seller) in Mumbai ships Paracetamol 500mg tablets (HS 3004.90) to a Kenyan importer (buyer) in Mombasa under INCOTERMS® 2020 CIF terms. The seller issues a VSC ObjectEvent credential containing both the HS classification and the INCOTERMS® classification: CIF Mombasa, risk transfer at "on board vessel Nhava Sheva Port, Mumbai," insurance required (ICC C, 110% invoice value, Allianz Policy #IN-2026-08921).
The shipment is loaded on board the vessel MV Mombasa Express at Nhava Sheva Port. The carrier issues a VSC ObjectEvent credential for the "on board" event (bizStep: shipping, disposition: in_transit). This event is referenced as the incotermsRiskTransferEvent in the INCOTERMS® classification.
During the ocean freight leg (T+24h after risk transfer), the IoT temperature logger records a 9.2°C excursion — exceeding the vaccine's 2°C–8°C specification. The logger issues a VSC ObjectEvent credential signed with the logger's DID, creating a tamper-evident record of the excursion with timestamp and GPS coordinates.
The buyer receives the shipment in Mombasa and discovers the temperature excursion. The buyer claims the seller is liable for the damaged goods. The seller invokes the INCOTERMS® CIF risk transfer: risk passed to the buyer when goods were placed on board in Mumbai.
Rather than engaging in weeks of document exchange and legal argument, both parties submit the VSC credential chain to an automated verifier. The verifier: (a) extracts the INCOTERMS® rule (CIF) and risk transfer event (on board Mumbai, T=0); (b) extracts the temperature excursion event (9.2°C, T+24h); (c) determines that T+24h is after T=0 → buyer bears the risk; (d) verifies the insurance credential linked to the shipment (ICC C, 110%, Allianz) is valid and meets CIF requirements; (e) signals "Buyer bears risk · Insurance claim available."
The buyer files an insurance claim with the linked insurance credential and the VSC evidence chain. The insurer verifies the entire chain independently and processes the claim — all evidence is cryptographically verifiable, eliminating the need for surveyor investigation and legal review.

Failure modes:

INCOTERMS® Version Mismatch: The seller issues a CIF shipment under INCOTERMS® 2010 rules but the buyer's contract references INCOTERMS® 2020. The verifier detects the version mismatch via the incotermsVersion field and signals "INCOTERMS® version conflict — contract specifies 2020, credential declares 2010." The buyer and seller must agree on the applicable version before liability can be determined.
Missing Insurance Credential for CIF: The shipment credential declares CIF (incotermsInsuranceRequired: true) but no insurance credential is linked. The verifier signals "CIF requires insurance — no insurance credential found. Seller has not fulfilled CIF obligations." The buyer may reject the documents or demand proof of insurance before acceptance.
Risk Transfer Event Ambiguity: The INCOTERMS® classification does not include the incotermsRiskTransferEvent reference. The verifier cannot programmatically determine when risk transferred and signals "Risk transfer event not specified — manual determination required."

Requirements motivated: REQ-F01, REQ-F03, REQ-F11, REQ-F13, REQ-F14, REQ-NF03, REQ-NF04.

UC-11: Automated Letter of Credit Settlement via VSC Documentary Compliance

Regulatory driver: ICC Uniform Customs and Practice for Documentary Credits (UCP 600) Articles 2, 3, 6, 14, 15, 16, 28; ICC International Standard Banking Practice (ISBP 745); UNCITRAL Model Law on Electronic Transferable Records (MLETR) 2017; eUCP Version 2.0 (2019) for electronic presentation of documents under Letters of Credit; Indian FEMA 1999 and RBI Master Direction on Export of Goods and Services (2016, updated 2024); SWIFT MT700/MT760 message standards.
Actors: Indian exporter / seller (LC beneficiary · issuer of shipment credentials); Kenyan importer / buyer (LC applicant); Kenya Commercial Bank (issuing bank · issues LC via SWIFT MT700); State Bank of India (advising/negotiating bank · verifies documentary presentation and negotiates payment); VSC smart contract / verification engine (automated verifier · checks documentary compliance and triggers settlement instruction); SWIFT / correspondent banking network (payment rail).
Preconditions: LC issued by Kenya Commercial Bank (SWIFT: KCBLKENAXXX) via SWIFT MT700 in favor of Indian exporter (State Bank of India as advising bank). LC amount: USD 250,000. LC type: Irrevocable, available by negotiation at SBI Mumbai. LC requires: Commercial Invoice, Bill of Lading, Certificate of Origin (GSP Form A), Packing List, Insurance Certificate (CIF — ICC C, 110%). INCOTERMS®: CIF Mombasa. Latest shipment date: 31 July 2026. LC expiry: 15 August 2026. All banks and parties have DIDs registered in the ICC Trade Trust Framework.

Nominal flow:

The Kenyan importer (buyer) applies to Kenya Commercial Bank for an irrevocable Letter of Credit in favor of the Indian exporter for USD 250,000, covering a shipment of Paracetamol 500mg tablets (HS 3004.90) under INCOTERMS® 2020 CIF Mombasa. The LC is issued via SWIFT MT700 and advised through State Bank of India, Mumbai. The LC specifies five documentary requirements and a latest shipment date of 31 July 2026.
The Indian exporter manufactures and ships the goods. Upon loading on board the vessel at Nhava Sheva Port, Mumbai (the INCOTERMS® CIF risk transfer event), the exporter's VSC-conformant system automatically generates the required credentials: a CommercialShipmentCredential (with HS classification, INCOTERMS® classification, and trade finance binding referencing LC2026-08921-IN-KE), a TransportEventCredential (Bill of Lading equivalent with on-board notation), an OriginCredential (GSP Form A issued by DGFT), an AggregationEventCredential (Packing List), and an InsuranceCredential (Allianz Policy, ICC C, 110%).
The exporter assembles all five credentials into a single Verifiable Presentation and submits it to the VSC verification engine (operated by SBI Mumbai's trade finance platform). The VP includes the settlement trigger event reference: the on-board-vessel event at Nhava Sheva Port.
The VSC verification engine performs automated documentary compliance checking: it verifies that each of the five LC documentary requirements is satisfied by a corresponding VSC credential in the VP, that each credential's DID issuer is in the ICC Trade Trust Framework registry, that each Data Integrity proof is valid, that the HS code matches the LC goods description, that the INCOTERMS® rule (CIF) matches the LC terms, and that the shipment date is within the LC validity period. All five requirements pass. The verifier signals "Compliant Presentation — UCP 600 Article 15(a) — Honoring bank may honor."
Upon "Compliant" status, the settlement process is triggered: SBI Mumbai negotiates the documents and releases payment of USD 250,000 to the exporter. Simultaneously, the lcPresentationStatus is updated to "paid" and the titleTransferCondition ("upon_payment") is recorded as satisfied, transferring title to the buyer. The entire process from VP submission to funds credited: approximately 30 seconds.
The buyer receives the shipment in Mombasa. If a dispute arises (e.g., temperature excursion during ocean freight), the INCOTERMS® CIF risk transfer event in the credential chain confirms that risk transferred at Mumbai — the buyer bears the loss but has an insurance claim. The same VSC credentials that satisfied the LC now serve as evidence for the insurance claim.

Failure modes:

Missing Documentary Requirement: The VP contains four of the five required credentials — the Insurance Certificate is missing. The verifier signals "Discrepant Presentation — Missing: Insurance Certificate (UCP 600 Art. 28). CIF shipment requires insurance credential. LC Requirement #5 not satisfied." The exporter is notified and can add the missing credential before the LC expiry date.
Documentary Discrepancy: The Commercial Invoice credential declares HS 3004.90 (medicaments) but the LC goods description specifies "Paracetamol 500mg tablets — HS 3004.90.11." The verifier detects that the HS code in the credential (3004.90) does not match the LC specification at the national tariff line level (3004.90.11). The verifier signals "Discrepant Presentation — Commercial Invoice: HS code mismatch. Credential: 3004.90. LC requires: 3004.90.11."
LC Expiry Before Presentation: The exporter submits the VP on 16 August 2026 — one day after the LC expiry date of 15 August 2026. The verifier checks the presentation date against the LC expiry and signals "Discrepant Presentation — Late presentation (UCP 600 Art. 6(d)(i)). LC expired 15 August 2026. Presentation date: 16 August 2026."
Unauthorized Issuer: The Certificate of Origin credential is issued by a DID that is not registered in the DGFT-authorized Certificate of Origin issuer registry. The verifier rejects the credential with "Issuer not authorized — Certificate of Origin must be issued by DGFT-registered authority (GSP Form A)."

Requirements motivated: REQ-F01, REQ-F03, REQ-F07, REQ-F11, REQ-F13, REQ-F15, REQ-F16, REQ-NF03.

Figure 4 — The 25 VSC Conformance Gates. Requirements are organized into five horizontal rows: Core Event Architecture (01–05) covers EPCIS mapping, semantics preservation, DID binding, event linking, and selective disclosure. Trust & Authority (06–10) covers batch traceability, issuer authorization, credential status, chain integrity detection, and trust framework references. Normative Vocabulary Bindings (11–16) covers HS code inclusion and transformation, INCOTERMS® binding and automated liability, and trade finance instrument binding with automated LC compliance. Architectural Frameworks (17–20) covers the Event Matrix, dimension extensibility, machine-executable regulatory rules, and rule versioning. Non-Functional Requirements (NF01–NF05) covers scalability, privacy, interoperability, extensibility, and long-term verifiability.

Requirements

The following requirements are derived from the use cases in §11 Use Cases and from the regulatory and standards landscape described in §1 Introduction. Each requirement is identified by a stable identifier, states the conformance level, provides a rationale grounded in published sources, and includes a testability statement to guide conformance test development.

All VSC-conformant implementations MUST also satisfy the MUST-level requirements of [[VC-DATA-MODEL]]. The requirements below are additional VSC-specific requirements that go beyond the base VC Data Model.

Requirements Summary

The following table provides a high-level overview of all twenty functional and five non-functional requirements. Each requirement is linked to its detailed specification below and cross-referenced to the use cases that motivate it.

ID	Title	Level	Conformance Class	Use Cases
REQ-F01	Event-to-Credential Mapping	MUST	Issuer	UC-01–04, UC-07–11
REQ-F02	Event Semantics Preservation	MUST	Issuer	UC-01, UC-02, UC-08
REQ-F03	Issuer DID Binding	MUST	Issuer	UC-01–05, UC-07–11
REQ-F04	Event Linking	SHOULD	Issuer	UC-01–04, UC-07–09
REQ-F05	Selective Disclosure	MUST	Issuer, Verifier	UC-02, UC-03, UC-06, UC-07, UC-09
REQ-F06	Batch and Lot Traceability	SHOULD	Issuer	UC-03, UC-04
REQ-F07	Issuer Authority Verification	MUST	Verifier	UC-01–03, UC-06–11
REQ-F08	Credential Status and Revocation	MUST	Issuer, Verifier	UC-02, UC-05, UC-07
REQ-F09	Chain Integrity Detection	SHOULD	Verifier	UC-01, UC-02, UC-04, UC-08
REQ-F10	Trust Framework Reference	SHOULD	Issuer, Verifier	UC-01–03
REQ-F11	HS Code Inclusion	SHOULD	Issuer	UC-03, UC-09–11
REQ-F12	HS Transformation in Manufacturing	MAY	Issuer	UC-04, UC-09
REQ-F13	INCOTERMS® Inclusion	SHOULD	Issuer	UC-03, UC-10, UC-11
REQ-F14	Automated INCOTERMS Liability	MAY	Verifier	UC-10
REQ-F15	Trade Finance Instrument Binding	MAY	Issuer	UC-11
REQ-F16	Automated LC Compliance	MAY	Verifier	UC-11
REQ-F17	Event Matrix Representation	MAY	Issuer, Verifier	UC-01–11
REQ-F18	Dimension Extensibility	MUST	Verifier	All
REQ-F19	Machine-Executable Regulatory Rules	MAY	Verifier	All
REQ-F20	Rule Versioning and Lifecycle	MUST	Verifier	All
REQ-NF01	Scalability	MUST	Issuer, Verifier	UC-02, UC-04, UC-05, UC-07
REQ-NF02	Privacy Preservation	SHOULD	Issuer, Verifier	UC-03, UC-06
REQ-NF03	Interoperability	MUST	Issuer, Verifier	UC-01, UC-03, UC-09–11
REQ-NF04	Extensibility	SHOULD	Issuer	UC-04, UC-08–10
REQ-NF05	Long-term Verifiability	SHOULD	Verifier	UC-06

Functional Requirements

This section specifies the twenty functional requirements (REQ-F01 through REQ-F20) that govern VSC-conformant implementations. Each requirement includes its conformance level, the conformance class to which it applies, a rationale citing published standards or regulations, and a testability statement suitable for inclusion in a formal conformance test suite.

REQ-F01 — Event-to-Credential Mapping

A VSC Issuer MUST support producing a [[VC-DATA-MODEL]]-conformant Verifiable Credential for each of the five [[EPCIS]] v2.0 event types: ObjectEvent, AggregationEvent, TransformationEvent, TransactionEvent, and AssociationEvent. The mapping applied MUST conform to the normative Event-to-Credential Mapping defined in the VSC Core Data Model specification.

EPCIS v2.0 [[EPCIS]] defines five event types covering the full range of supply chain observations. Requiring support for all five ensures that VSC can represent any supply chain event without loss of semantics. The GS1 [[GS1-CBV]] provides the controlled vocabulary used within these events.

A test vector set MUST be published containing at least one syntactically and semantically valid EPCIS event document for each of the five event types. A conformant issuer MUST produce a valid, verifiable Verifiable Credential for each test vector that: (a) passes [[VC-DATA-MODEL]] validation; (b) preserves all EPCIS fields specified in REQ-F02; and (c) carries a valid [[VC-DATA-INTEGRITY]] proof.

[[EPCIS]] Section 7; [[GS1-CBV]]; [[VC-DATA-MODEL]] Section 4.

REQ-F02 — Event Semantics Preservation

The Event-to-Credential Mapping MUST preserve, without loss or transformation, the following fields from the source [[EPCIS]] event: eventTime, eventTimeZoneOffset, recordTime, eventType, action, bizStep, disposition, readPoint, bizLocation, epcList / inputEPCList / outputEPCList (as applicable to the event type), and quantityList / inputQuantityList / outputQuantityList (as applicable). Extension fields (ILMD, sensor elements) MUST also be preserved where present.

Regulatory requirements under [[DSCSA]] and [[EUDR]] require that the specific event-time, location, and identifier information are auditable and have not been altered. Loss of any of these fields would undermine the legal validity of the credential as a regulatory record. The [[ISO28000]] supply chain security management framework similarly requires complete and accurate event records.

For each test vector in REQ-F01: a conformant parser applied to the resulting credential MUST recover values bit-for-bit identical to the source EPCIS event for each listed field. Automated round-trip tests MUST be defined in the conformance test suite.

[[EPCIS]] Sections 7–9; [[DSCSA]]; [[EUDR]] Article 9; [[ISO28000]].

REQ-F03 — Issuer DID Binding

Every Verifiable Credential representing a Supply Chain Event MUST include an issuer value using [[DID-CORE]] syntax. The DID MUST be resolvable to a DID Document containing the public key material used to verify the credential's [[VC-DATA-INTEGRITY]] proof. A VSC Issuer MUST NOT use a bare HTTP URL or an opaque identifier as the issuer value.

The core security property of VSC is the cryptographic binding between the event assertion and the asserting party's identity. Without a resolvable DID, a verifier cannot retrieve the public key needed to verify the signature, making the credential unverifiable. [[DID-CORE]] provides the standardized mechanism for this binding, supported by existing W3C infrastructure.

Given a VSC event credential: (a) the issuer value MUST conform to the DID syntax rule defined in [[DID-CORE]] Section 3.1; (b) resolving the DID via a conformant DID resolver MUST return a DID Document; and (c) the DID Document MUST contain a verificationMethod entry whose public key successfully verifies the credential's proof.

[[DID-CORE]] Sections 3, 7; [[VC-DATA-MODEL]] Section 4.5; [[VC-DATA-INTEGRITY]].

REQ-F04 — Event Linking

A VSC Issuer SHOULD include, in event credentials that represent a step in a multi-party custody chain, a reference to the credential identifier(s) of immediately preceding events in the chain. References MUST use the id property of the referenced credential, expressed as a URI, in the credential subject. A VSC Verifier SHOULD follow event links to reconstruct the chain and verify each linked credential.

Custody chain reconstruction is required by [[DSCSA]] (full tracing from manufacturer to dispenser), [[EUDR]] (origin to importer), and [[EU-BEV]] (material to battery). Without event linking, a verifier cannot confirm that consecutive custody transfers are contiguous or that no unauthorized party intervened. The linking pattern is consistent with the linked data approach of [[JSON-LD]].

Given a two-credential chain where credential B references credential A by URI: (a) a conformant verifier MUST resolve and verify credential A when requested; (b) if credential A's ID is altered, the verifier MUST detect the broken link; (c) a verifier MUST signal non-verifiability if a referenced credential cannot be retrieved.

[[DSCSA]]; [[EUDR]] Article 4; [[EU-BEV]] Annex XIII; [[JSON-LD]] Section 3.

REQ-F05 — Selective Disclosure

A VSC Issuer MUST produce event credentials using a proof format that supports Selective Disclosure. Supported proof formats include [[BBS-2023]] and [[SD-JWT]]. A VSC Verifier MUST be capable of verifying selective disclosure presentations produced by at least one of these proof formats. Selective disclosure presentations MUST NOT allow an adversary to infer unrevealed field values from the presented proof.

Supply chain data contains commercially sensitive information (supplier identities, pricing, production volumes) that participants are not willing to share beyond regulatory minimum disclosure. [[GDPR]] Article 5(1)(c) data minimization principle requires that only necessary data be shared. [[BBS-2023]] and [[SD-JWT]] are standardized selective disclosure mechanisms with W3C and IETF backing respectively.

Given a credential with N fields: (a) a conformant holder MUST be able to produce a presentation revealing any subset of k fields (1 ≤ k < N) while maintaining proof validity; (b) the verifier MUST accept the presentation for the revealed fields; (c) the verifier MUST NOT be able to recover the values of the unrevealed fields from the proof material; (d) a tampered proof MUST be rejected.

[[BBS-2023]]; [[SD-JWT]]; [[GDPR]] Article 5(1)(c); [[VC-DATA-MODEL]] Section 5.9; [[NIST-SP800-53]] SI-12.

REQ-F06 — Batch and Lot Traceability

A VSC Issuer SHOULD support batch-level and lot-level identifiers (e.g., LGTIN as defined in [[GS1-CBV]]) in event credentials, in addition to serialized-item identifiers (SGTIN, SSCC). Implementations supporting batch traceability MUST ensure that batch identifiers are expressed using GS1 EPCIS quantity element syntax or an equivalent normative vocabulary.

Not all supply chain scenarios track at the per-item serialization level. Bulk commodities (agricultural products, chemicals, minerals) are tracked at batch or lot level. Batch identifiers are mandatory for EUDR due diligence claims and EU battery material traceability. Requiring per-item identifiers would make VSC undeployable for bulk commodity supply chains.

A conformant issuer MUST produce a valid credential carrying an LGTIN quantity element. A conformant verifier MUST parse and validate this element without error.

[[EPCIS]] Section 7.3.3; [[GS1-CBV]] Section 7; [[EUDR]] Article 9(1)(d); [[EU-BEV]] Annex XIII.

REQ-F07 — Issuer Authority Verification

A VSC Verifier MUST verify that the credential issuer's DID is authorized to assert events for the claimed business context when an Issuer Registry is referenced in the credential or specified by the verifier's Trust Framework. A verifier MUST NOT accept a credential whose issuer DID does not appear in a required issuer registry. Where no issuer registry is required by the verification context, the verifier SHOULD surface a warning indicating that issuer authority has not been independently confirmed.

Cryptographic proof of integrity (signature verification) is necessary but not sufficient for supply chain verifiability. An attacker can create a validly signed credential from a DID they control for a business step they are not authorized to assert. Checking the issuer against an authoritative registry — analogous to the certificate authority model in TLS — closes this gap. This pattern is aligned with [[NIST-SP800-53]] IA-5 (Authenticator Management) and the authorization model in [[RFC6749]].

Given a credential whose issuer DID is not in the verifier's configured issuer registry: the verifier MUST reject the credential and MUST return an error code distinguishing "issuer not authorized" from "signature invalid." A credential whose issuer IS in the registry MUST be accepted (assuming valid signature and status).

[[NIST-SP800-53]] IA-5; [[RFC6749]] Section 1.1; [[ISO28000]] Section 6.5; [[DSCSA]] Section 582(c).

REQ-F08 — Credential Status and Revocation

Every VSC event credential MUST include a credentialStatus property referencing a machine-readable status endpoint conformant with [[VC-DATA-MODEL]] Section 7. A VSC Verifier MUST check the status of each credential presented before accepting it. Cached revocation status information SHOULD NOT be relied upon for more than 24 hours for high-stakes verification contexts (pharmaceutical, food safety) and MAY be cached for up to 7 days in lower-stakes contexts.

Product recalls ([[DSCSA]], EU General Product Safety Regulation) require that invalid credentials be rejected promptly. A revocation mechanism that verifiers cannot check renders recall notifications ineffective. Cache lifetime limits balance performance (avoiding status service overload) against timeliness of revocation propagation, consistent with [[NIST-SP800-53]] SI-7.

(a) A verifier presented with a revoked credential MUST reject it and return a revoked status indicator. (b) A verifier with a stale (>24h) cached status for a high-stakes credential MUST re-fetch the status before accepting the credential. (c) A verifier MUST distinguish "revoked" from "status service unreachable" and SHOULD treat the latter as a verification failure.

[[VC-DATA-MODEL]] Section 7; [[DSCSA]] Section 582(h); [[NIST-SP800-53]] SI-7.

REQ-F09 — Event Chain Integrity Detection

A VSC Verifier SHOULD detect gaps in an Event Chain — specifically, cases where a credential references a predecessor credential that cannot be retrieved, verified, or that has been revoked — and MUST signal non-verifiability of the chain in such cases, with a specific error distinguishing: (a) missing predecessor, (b) invalid predecessor signature, (c) revoked predecessor, and (d) broken link (credential ID does not resolve).

An incomplete event chain may indicate either accidental data loss or a deliberate attempt to obscure an unauthorized custody transfer. Undifferentiated error signaling would prevent operators and regulators from distinguishing these cases. Distinct error codes enable targeted remediation. This is consistent with [[NIST-SP800-53]] AU-12 (Audit Record Generation) and the DSCSA requirement for complete, unbroken tracing.

Given a three-credential chain A→B→C where credential B's predecessor reference is corrupted: the verifier MUST return a "broken link" error specifically identifying B. A chain where B has been revoked MUST return a "revoked predecessor" error. A complete valid chain MUST return success.

[[NIST-SP800-53]] AU-12; [[DSCSA]] Section 582(j); [[ISO28000]] Section 6.4.

REQ-F10 — Trust Framework Reference

A VSC event credential SHOULD include a machine-readable reference to the Trust Framework under which it was issued, expressed as a URI in the credential's termsOfUse or evidence property. A VSC Verifier SHOULD use this reference to determine which Issuer Registry to consult for authority verification (REQ-F07).

Supply chains operate under sector-specific governance frameworks (pharmaceutical, food, automotive, etc.) with different authorization rules. Embedding a trust framework URI in the credential allows verifiers to apply the correct governance rules automatically, enabling cross-sector interoperability without bilateral configuration. This pattern follows the trust framework approach used in the [[PEPPOL]] e-procurement network.

A credential carrying a trust framework URI MUST allow a verifier to dereference the URI and retrieve a machine-readable document listing authorized issuer DIDs. A credential lacking a trust framework URI MUST be accepted with a warning (not rejected) by a verifier that does not require one.

[[VC-DATA-MODEL]] Section 5.12; [[PEPPOL]]; [[TRACEABILITY-INTEROP]] Section 4.

REQ-F11 — HS Code Inclusion in Product Credentials

WCO HS Convention (1983) Articles 3, 4; WCO HS Nomenclature 2022 Edition; WTO Trade Facilitation Agreement Article 10.

REQ-F12 — HS Transformation in Manufacturing Events

WCO HS Convention; WTO Agreement on Rules of Origin Article 2; EU-India FTA Rules of Origin Protocol; USMCA Chapter 4.

Non-Functional Requirements

This section specifies the five non-functional requirements (REQ-NF01 through REQ-NF05) that govern performance, privacy, interoperability, extensibility, and long-term verifiability characteristics of VSC-conformant implementations.

REQ-NF01 — Scalability

A VSC-conformant implementation MUST be capable of issuing and verifying event credentials at a rate commensurate with enterprise supply chain event volumes. As a benchmark, conformant implementations SHOULD be capable of verifying a ten-credential event chain in under 2 seconds under normal network conditions, and of issuing 1,000 credentials per minute on commodity cloud hardware. These benchmarks are indicative; normative performance requirements will be specified in the conformance test suite.

Large retail and pharmaceutical supply chains generate millions of EPCIS events per day. A verifiable credential system that cannot sustain production event volumes will not be adopted. Battery passport use case (UC-04) requires verification of chains spanning thousands of credentials. The benchmark figures are derived from GS1's published EPCIS throughput guidance and typical cloud instance capabilities as of 2024.

The conformance test suite MUST include a load test that exercises issuance at 1,000 credentials per minute and chain verification of 10 credentials within 2 seconds, recording pass/fail and actual throughput figures.

[[EPCIS]] Appendix D; [[ISO28000]].

REQ-NF02 — Privacy Preservation

VSC implementations SHOULD avoid requiring globally unique, long-lived correlatable identifiers for all participants in all verification contexts. Where pairwise [[DID-CORE]] identifiers are available, implementations SHOULD use them. Credential schemas MUST NOT require the inclusion of personally identifiable information (PII) beyond what is required for the regulatory context in question.

[[GDPR]] Article 25 (Data Protection by Design) requires that data minimization and privacy-by-design be embedded in system design. Supply chain credentials frequently traverse jurisdictional boundaries and may be subject to multiple data protection regimes. Long-lived correlatable identifiers enable tracking of supply chain participant behavior across contexts beyond the intended disclosure.

A conformance test MUST verify that a credential schema does not include mandatory PII fields beyond regulatory minimum. A verifier MUST NOT require a holder to present more fields than the minimum needed for the stated verification purpose.

[[GDPR]] Articles 5, 25; [[NIST-SP800-53]] AR-7; [[VC-DATA-MODEL]] Section 10.

REQ-NF03 — Interoperability

A VSC event credential issued by one conformant implementation MUST be verifiable by any other conformant implementation without prior bilateral configuration. Implementations MUST use the VSC JSON-LD context URI (to be defined in the VSC Core Data Model) and MUST NOT require proprietary extensions for basic credential exchange. Implementations SHOULD conform to the [[TRACEABILITY-INTEROP]] HTTP API profile for credential exchange.

The primary value proposition of VSC is cross-organizational verifiability. Without interoperability, VSC becomes a series of proprietary bilateral integrations — the same problem it is designed to solve. The [[TRACEABILITY-INTEROP]] profile provides a tested, deployed HTTP API standard for credential exchange in supply chain contexts.

The VSC interoperability test suite MUST include an implementation-A-issues / implementation-B-verifies scenario for each of the five credential types. A credential issued by implementation A MUST be verified successfully by implementation B without any bilateral pre-configuration.

[[TRACEABILITY-INTEROP]]; [[VC-DATA-MODEL]] Section 1.3; [[JSON-LD]] Section 5.

REQ-NF04 — Extensibility

The VSC credential schema SHOULD support sector-specific and jurisdiction-specific extension vocabularies without invalidating base credential verification. Extension vocabularies MUST be expressed using [[JSON-LD]] context extension mechanisms. Verifiers that do not understand an extension MUST still be able to verify the base credential.

Supply chain verticals (pharmaceutical, food, automotive, aerospace) have distinct data requirements. A rigid schema would require a separate specification for each vertical. The JSON-LD extension mechanism provides a standards-based, proven approach to extensibility, as demonstrated by [[TRACEABILITY-V1]] and [[UNTP]].

A credential carrying an unknown JSON-LD extension term MUST be parsed and its base fields MUST be verifiable by a conformant verifier that does not have the extension context loaded. Verifier MUST NOT fail on unknown extension terms.

[[JSON-LD]] Sections 5, 9; [[TRACEABILITY-V1]]; [[UNTP]].

REQ-NF05 — Long-term Verifiability

VSC-conformant implementations SHOULD support verification of event credentials issued up to 10 years prior. This requires that: (a) issuer DID key history is preserved and accessible, either via the DID Document or a trust-framework-maintained historical key archive; and (b) the cryptographic algorithms used for signing remain secure and supported for the expected credential lifetime.

Regulatory audit requirements in pharmaceutical (FDA, EMA), food safety (FDA FSMA), and financial sectors require records retention of 5–10 years. A credential that cannot be verified after its issuer rotates keys or deactivates its DID provides no audit value. Key history preservation is analogous to the certificate transparency log model in TLS.

A conformance test MUST simulate DID key rotation and verify that a credential signed before rotation can still be verified using the pre-rotation key retrieved from the DID Document history or trust framework archive.

[[DID-CORE]] Section 7.2; [[NIST-SP800-53]] SI-12; [[DSCSA]] Section 582(n).

ID	STRIDE Category	Threat	Severity	Mitigation	Req
T-01	Spoofing	Adversary creates a fabricated event credential using a DID they control, not authorized for the business context.	High	Issuer authority verification against an issuer registry (REQ-F07). Trust framework reference in credential (REQ-F10).	REQ-F07, REQ-F10
T-02	Tampering	Adversary modifies event data (e.g., alters origin coordinates or timestamps) after credential issuance.	High	Cryptographic proof over all credential fields (REQ-F03). Selective disclosure proofs protect unrevealed fields (REQ-F05).	REQ-F03, REQ-F05
T-03	Repudiation	Issuer denies having issued a specific event credential.	Medium	Non-repudiation is provided by the issuer's DID-bound cryptographic signature. Verifiers SHOULD log verification results.	REQ-F03
T-04	Information Disclosure	Verifier extracts commercially sensitive supply chain data from a credential beyond what was intended for disclosure.	Medium	Selective disclosure (REQ-F05) ensures unrevealed fields cannot be recovered from proof material. Pairwise DIDs (REQ-NF02) limit correlation.	REQ-F05, REQ-NF02
T-05	Denial of Service	Adversary floods the credential status service or DID resolution endpoint, preventing legitimate verification.	Medium	Status service SHOULD implement rate limiting and geographic redundancy. Verifiers SHOULD implement caching per REQ-F08 cache lifetime limits.	REQ-F08
T-06	Elevation of Privilege	Adversary registers a DID in an issuer registry without meeting the registry's eligibility requirements.	High	Issuer registry governance is out of scope for VSC but trust frameworks MUST define eligibility criteria. Credential SHOULD reference the registry (REQ-F10).	REQ-F10

Regulatory Rule Compiler — Machine-Executable Compliance

Design Principle: Regulation as Executable Code

Every trade regulation, without exception, is a conditional statement. DSCSA §582 requires product tracing if the product is a prescription drug sold in the United States. EUDR Article 3 requires due diligence if the commodity is listed in Annex I and is placed on the EU market. UCP 600 Article 14 requires documentary compliance within five banking days if the payment instrument is a Letter of Credit. INCOTERMS® 2020 CIF requires insurance at 110% of invoice value if the named place is a port of destination.

These conditions are expressed in legal prose — precise to lawyers, opaque to machines. Each regulation requires a separate interpretation, a separate compliance team, a separate software module. When a regulation changes — a new HS code is added to an annex, a tariff rate is adjusted, a documentary requirement is modified — the software must be updated. When a new regulation emerges — a carbon border adjustment, a digital product passport, a forced labour due diligence — a new software module must be built.

The VSC Regulatory Rule Compiler eliminates this cycle. It treats regulation as executable code over the Event Matrix. Every regulatory requirement is expressed as a deterministic function that accepts a matrix row as input and returns a compliance status as output. The function references only the five standardized dimensions of the matrix. When a regulation changes, only the rule changes — not the verification engine. When a new regulation emerges, a new rule is written — no new software is required.

Figure 5 — The VSC Global Ecosystem: Every standards body, national regulator, industry stakeholder, sector-specific regulation, cross-cutting law, community group, and infrastructure provider that VSC connects into a single verifiable trade operating system. Row 1: Global standards bodies (W3C, GS1, WCO, ICC, WTO, UN/CEFACT, ISO, IETF). Row 2: National regulators across Americas, Europe, Asia-Pacific, Middle East & Africa, and global oversight bodies. Row 3: Industry stakeholders from manufacturers through logistics, financial institutions, customs, regulators, and certification bodies. Row 4: Sector-specific regulations for pharmaceuticals, food & agriculture, electronics & batteries, and aerospace & defense. Row 5: Additional sectors (critical minerals, textiles, chemicals) and cross-cutting laws (GDPR, CSDDD, FCPA, Modern Slavery Act). Row 6: Community groups and infrastructure (W3C VSC CG, UORA, CCG, GS1, OpenPEPPOL, SWIFT).

Architecture: Compiler Pipeline

The VSC Regulatory Rule Compiler — Architecture and Data Flow

The VSC Regulatory Rule Compiler — a three-stage pipeline that ingests regulatory text, compiles it into executable matrix rules, and distributes them to verifiers through a versioned rule registry with full lifecycle management.

The VSC Rule Grammar

Every rule is expressed in a structured format that references only the five standard matrix dimensions. The grammar is designed to be both human-writable and machine-executable, using a syntax familiar to regulatory professionals while producing deterministic verification outcomes.

RULE: <rule_identifier>
VERSION: <semantic_version>
JURISDICTION: <ISO_3166-1_alpha2>
REGULATORY_REFERENCE: <citation>
EFFECTIVE_DATE: <ISO_8601_date>
DEPRECATES: <previous_rule_identifier | null>

WHEN:
  D1.event_type IN [<event_type_list>]
  AND D2.did_method IN [<did_method_list>]
  AND D3.hs_chapter IN [<chapter_list>]
  AND D3.hs_heading IN [<heading_list>]
  AND D3.hs_code IN [<hs_code_list>]
  AND D4.incoterms IN [<incoterms_list>]
  AND D4.incoterms_version = <version_year>
  AND D5.payment_instrument IN [<instrument_list>]
  AND D5.jurisdiction = <ISO_3166-1_alpha2>

REQUIRE:
  DIMENSION: <D1|D2|D3|D4|D5>
  CHECK: <validation_function>
  PARAMETERS: <key_value_pairs>
  ON_FAILURE: <NON_COMPLIANT | CONDITIONAL | FLAG>

OUTCOME:
  COMPLIANT: <action_if_all_requirements_met>
  NON_COMPLIANT: <action_if_any_requirement_failed>
  CONDITIONAL: <action_if_conditional_requirements>

Compiled Rule Examples

Example 1: DSCSA Pharmaceutical Traceability

Example 2: CIF Insurance Compliance Under INCOTERMS® 2020

Example 3: EU Carbon Border Adjustment Mechanism (CBAM)

Essential Properties of the Rule Compiler

Regulation-Neutral: The compiler does not encode any specific regulation. It provides the grammar for expressing regulations as executable rules. Any regulation from any jurisdiction that can be expressed as conditions over the five matrix dimensions can be compiled into a VSC rule. The compiler is to regulations what a programming language compiler is to source code: it translates human-readable requirements into machine-executable instructions without understanding the domain.
Deterministic Output: For a given rule and a given matrix row, the compliance determination is always identical. Two verifiers applying the same rule version to the same event will produce the same outcome. This eliminates the interpretive variation that currently requires multiple compliance teams to reach different conclusions from the same regulatory text.
Versioned and Deprecatable: Rules carry semantic versions. When a regulation changes — a new HS code is added to an annex, a threshold is adjusted, a documentary requirement is modified — a new rule version is published. The previous version is marked as deprecated but remains available for audit purposes. Verifiers specify which rule versions they apply. An event verified against DSCSA_Package_ Traceability v1.0.0 on 15 June 2025 can be re-verified against v1.1.0 on 15 December 2025 without ambiguity about which requirements applied at the time of the event.
Composable: Multiple rules can apply to a single event. A pharmaceutical shipment from India to Kenya under CIF terms with LC payment triggers DSCSA export requirements, INCOTERMS® CIF insurance requirements, UCP 600 documentary requirements, and potentially CBAM carbon declaration requirements. Each rule is evaluated independently. The verifier aggregates results: an event is COMPLIANT only if all applicable rules pass.
Graduated Failure Modes: Rules produce three outcomes, not two. COMPLIANT means all requirements are satisfied. NON_COMPLIANT means a mandatory requirement failed — the event cannot proceed. CONDITIONAL means a requirement failed but the event can proceed with additional conditions (e.g., CBAM certificate purchase, physical inspection, additional documentation). This tri-state logic reflects how regulations actually work: not all failures are hard stops.

REQ-F19 — Machine-Executable Regulatory Rule Representation

A VSC Verifier MAY support machine-executable regulatory rules using the VSC Rule Grammar. When supported, the verifier MUST accept rules expressed in the grammar defined in this section. Rules MUST reference only the five standardized matrix dimensions (D1–D5) and any registered extension dimensions. A rule MUST produce one of three deterministic outcomes for any given matrix row: COMPLIANT, NON_COMPLIANT, or CONDITIONAL.

Every trade regulation is expressible as a conditional statement over product classification, actor identity, commercial terms, and financial instruments — precisely the dimensions of the VSC Event Matrix. By compiling regulations into machine-executable rules, the VSC verifier can determine regulatory compliance without domain-specific code. When a regulation changes, only the rule changes — not the verifier. When a new regulation emerges, a new rule is written — no software update is required. The tri-state outcome model reflects regulatory reality: not all compliance failures are hard stops.

Given a verifier configured with DSCSA_Package_Traceability v1.0.0 and an event matrix with D3.hs_chapter="30" and D5.jurisdiction="US": the verifier MUST verify that D1.chain contains all four required event types and that D2.issuer is in the FDA ATP Registry for each event. If both conditions pass, output MUST be COMPLIANT. If any condition fails, output MUST be NON_COMPLIANT with specific failure details. Given the same verifier and an event with D3.hs_chapter="09" (coffee): the rule MUST NOT be triggered and MUST return COMPLIANT (rule scope does not apply).

DSCSA §582; INCOTERMS® 2020 CIF; UCP 600 Article 14; CBAM Regulation (EU) 2023/956; WTO TFA Article 10.

REQ-F20 — Rule Versioning and Lifecycle Management

Every VSC regulatory rule MUST carry a semantic version identifier, a regulatory reference citation, an effective date, and an optional deprecation reference to a previous rule version. A VSC Rule Registry MAY maintain the authoritative set of active rules. Verifiers MUST specify which rule versions they apply to each verification. An event verified against a specific rule version MUST be re-verifiable against that same version at any future date for audit purposes.

Regulations change over time — new HS codes are added to annexes, thresholds are adjusted, documentary requirements are modified. Without versioned rules, a verification performed in January 2025 against the then-current rule cannot be audited in December 2025 if the rule has changed. Versioned rules solve this by making the rule itself an immutable artifact referenced by version identifier. The deprecation chain ensures that the provenance of regulatory requirements is fully traceable.

Given a verifier with DSCSA_Package_Traceability v1.0.0 and v1.1.0 (where v1.1.0 deprecates v1.0.0): an event verified against v1.0.0 on 2025-06-15 MUST be re-verifiable against v1.0.0 on 2025-12-15 with identical result. The same event verified against v1.1.0 MAY produce a different result if rule requirements changed. The verifier MUST record which rule version was applied in the verification result.

This specification Section X+4; Semantic Versioning 2.0.0; WTO TFA Article 10.3 (Advance Rulings).

Introduction

Background and Motivation

Problem Statement

The VSC Approach

Document Conventions

Document Structure

Conformance

Scope

In Scope

Out of Scope

Terminology

Conceptual Architecture

The Five-Layer Model

Roles

EPCIS Event Types and VSC Mapping

Object Model

Information Flow

Related Work and Standards Alignment

Core Architecture Standards

Normative Vocabulary Standards

Trade Facilitation and Regulatory Standards

Community and Infrastructure Standards

Harmonized System (HS) Codes — Normative Commodity Vocabulary

Overview

HS Code Binding in VSC Credentials

HS Code Transformation in Manufacturing Events

Automated Rules of Origin via Change in Tariff Classification (CTC)

HS-Based Risk Scoring and Compliance Screening

Regulatory Mapping via HS Codes

Alignment with EPCIS

Trade Finance and Payment Instrument Binding

Overview

Payment Instrument Binding in VSC Credentials

Automated Documentary Compliance Verification

The VSC Event Matrix — Cross-Domain Verification Schema

Design Principle: Orthogonal Dimensions, Forward-Compatible Extensibility

Matrix Representation Format

Cross-Industry Application Examples

The Universal Verification Pattern

Machine Learning Integration

Essential Properties

INCOTERMS® — Normative Commercial Terms Vocabulary

Overview

Why INCOTERMS Are Critical to Verifiable Supply Chains

INCOTERMS® Binding in VSC Credentials

Automated Risk and Responsibility Determination

Insurance Verification for CIF and CIP

Commercial Dispute Resolution

Use Cases

UC-01: Raw Material Provenance for Deforestation Due Diligence

UC-02: Pharmaceutical Custody Transfer (DSCSA Compliance)

UC-03: Automated Customs Clearance

UC-04: Battery Passport for EV Supply Chain

UC-05: Product Recall Propagation

UC-06: Regulatory Audit Trail

UC-07: Indian Pharmaceutical Track-and-Trace (QR Code Mandate Compliance)

UC-08: Cross-Border Cold Chain Logistics with IoT-Verified Temperature Integrity

UC-09: HS Code-Driven Automated Customs Declaration with Rules of Origin

UC-10: INCOTERMS®-Driven Liability and Insurance Determination

UC-11: Automated Letter of Credit Settlement via VSC Documentary Compliance

Requirements

Requirements Summary

Functional Requirements

Non-Functional Requirements

Security Considerations

Threat Model

Fraudulent Event Injection (T-01)

Credential Replay (T-02 / T-01)

Broken Custody Chains (T-02)

Issuer Key Compromise

Privacy Considerations

Commercially Sensitive Supply Chain Data

Credential Linkability

Personal Data in Event Credentials

Accessibility Considerations

Internationalization Considerations

Regulatory Rule Compiler — Machine-Executable Compliance

Design Principle: Regulation as Executable Code

Architecture: Compiler Pipeline

The VSC Rule Grammar