Document Type: Strategic Vision (Open Source)

Audience: Enterprise architects, CTOs, federal and financial settlement leaders, forward-thinking business leaders

Status: Draft

Version: 1.0

Date: 2025-11-03

Authors: Timothy W. Cook (Founder, Axius SDC, Inc.) w/Claude (Anthropic AI Assistant)

Organization: Semantic Data Charter (open source community)

License: Creative Commons Attribution 4.0 International (CC BY 4.0)

Table of Contents

Executive Summary

The Revelation: The same architecture that solves 40 years of X12 EDI problems is exactly what a Verifiable Settlement Layer needs.

SDC provides the Verifiable Settlement Layer (VSL): it lets two SDC-substrate-compatible agents exchange data and conditionally release value or state, with cryptographic verification, without a trusted intermediary. It verifies three things at once: that the data conformed to its bound schema, that the action was authorized by its provenance chain, and that the conditional release was triggered by both. The output is a tamper-evident, machine-verifiable settlement record any third party can audit without seeing the underlying data.

We designed SDC4 for:

These are precisely the requirements for verifiable settlement.

This document demonstrates how the EDI settlement transactions enterprises already run—820 remittance, 835 claims payment, 210 freight invoice—are exactly what VSL makes verifiable and agent-executable, with schema validation, cryptographic settlement proof, and cross-environment interoperability built in.

The Bridge: Traditional EDI → Hybrid Systems → Agent-Executable Verifiable Settlement

Table of Contents

The Unexpected Convergence

A 25-Year Journey

2000-2010: Healthcare informatics research

2010-2020: SDC4 specification development

2020-2025: Enterprise validation

Settlement is buyer-native everywhere money or state changes hands: real-time gross settlement and delivery-versus-payment in finance (EDI 820), freight settlement in logistics (EDI 210), claims settlement in healthcare (EDI 835), and Treasury settlement across federal programs. What these settlement flows have always lacked is a way to prove, after the fact, that the data was valid and the release was authorized—without forcing every counterparty to trust a single intermediary. SDC4's principles supply exactly that.

The Architectural Match

What SDC4 Provides:

SDC4 Feature Why It Matters for Verifiable Settlement
Structure/Semantics Separation Same settlement data model works across every execution environment
XSD Schema Validation Proves a settlement event conformed to its bound schema
CUID2 Component IDs Content-addressable settlement records, stable across systems
Ontology URI References Cross-environment semantic interoperability
Attestation Model Cryptographic authorization of the settlement counterparty
Participation Model Built-in provenance chain for the settlement audit trail
Version Coexistence Settlement records remain auditable indefinitely

It's not opportunistic. It's a direct consequence of how the architecture was built.

The Settlement Data Problem: The Same Chaos, Worse

Current Reality: Every Settlement System Invents Its Own Schema

Once settlement moves out of a single legacy translator, every party tends to redefine the same transaction in its own structure. The three definitions below all describe one purchase-order settlement, yet none of them agree on field names, units, or meaning:

Settlement System A:


struct PurchaseOrder {
    address buyer;
    string itemId;      // What does this mean?
    uint256 quantity;
    uint256 price;      // What currency?
    uint256 deliveryDate;
}

Settlement System B:


pub struct PurchaseOrder {
    pub buyer: Pubkey,
    pub item: String,   // Different field name!
    pub qty: u64,       // Different name again!
    pub amount: u64,    // Is this total or unit price?
    pub ship_date: i64, // Unix timestamp? Date string?
}

Settlement System C:


data PurchaseOrder = PurchaseOrder
    { poFrom :: PubKeyHash
    , poProduct :: ByteString
    , poQty :: Integer
    , poValue :: Value
    }

Problems:

This is X12 implementation-guide chaos all over again, now at the settlement layer.

What Verifiable Settlement Needs

SDC4 provides all of this.

The Same Settlement Transaction, Three Environments

Environment 1: Traditional X12 EDI

Walmart sends to supplier:


ST*850*0001~
BEG*00*NE*PO123456**20251103~
N1*ST*ACME WAREHOUSE*92*9876543210~
PO1*1*100*EA*12.50*PE*BP*0001234567890~
SE*12*0001~

Processed via: VAN (Value-Added Network), AS2/SFTP transport, EDI translation software

Environment 2: SDC4 Instance (Modern)

Same purchase order:


<sdc4:dm-po8q9r2s56789 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <dm-label>Purchase Order 850 - Walmart</dm-label>
  <dm-language>en-US</dm-language>
  <dm-encoding>UTF-8</dm-encoding>

  <sdc4:ms-ab1k2m5p78901><!-- Header Cluster -->
    <label>Purchase Order Header</label>
    <sdc4:ms-bc2l3n6q89012>
      <label>Purchase Order Number</label>
      <xdstring-value>PO123456</xdstring-value>
    </sdc4:ms-bc2l3n6q89012>
    <!-- ... full structure as shown in previous doc ... -->
  </sdc4:ms-ab1k2m5p78901>
</sdc4:dm-po8q9r2s56789>

Processed via: Direct HTTP/REST, message queue, cloud storage, validated against XSD schema

Environment 3: Verifiable Settlement (VSL)

Same purchase order, settlement-record representation:

In the settlement record:


// Compact settlement-record entry
struct PurchaseOrderHash {
    bytes32 schemaHash;      // Hash of XSD schema (dm-po8q9r2s56789)
    bytes32 instanceHash;    // Hash of complete SDC4 XML instance
    address buyer;           // Identifier of the buying counterparty
    address supplier;        // Identifier of the supplying counterparty
    uint256 totalAmount;     // Total order value (minor units)
    uint256 deliveryDate;    // Commitment date
    string docUri;           // Full SDC4 document in content-addressed storage
}

Underlying document (content-addressed storage):


sdc-store://QmXyZ123.../purchase-order-PO123456.xml

→ Contains the complete SDC4 XML instance

Validation: Before writing the settlement event, the settlement engine:

Processed via: Conditional settlement logic, content-addressed document storage, off-engine verification

The Key Insight

It's the same data model in all three environments!

The structure and semantics are identical. Only the transport and storage mechanisms differ.

Conditional Settlement Integration Examples

Example 1: Purchase Order Escrow Settlement

Scenario: Buyer creates a purchase order. Conditional settlement logic holds payment in escrow and releases it only when delivery is confirmed.

Conditional Settlement Logic (illustrative):


pragma solidity ^0.8.0;

contract PurchaseOrderEscrow {
    // SDC4 Schema Registry
    address public schemaRegistry;

    struct PurchaseOrder {
        bytes32 schemaHash;       // SDC4 schema hash
        bytes32 instanceHash;     // SDC4 instance data hash
        address buyer;
        address supplier;
        uint256 amount;           // Total in wei
        uint256 deliveryDeadline;
        string ipfsUri;           // Complete SDC4 doc on IPFS
        POStatus status;
        bool buyerSigned;
        bool supplierSigned;
    }

    enum POStatus { Created, Accepted, Shipped, Delivered, Completed, Disputed }

    mapping(bytes32 => PurchaseOrder) public purchaseOrders;

    event POCreated(bytes32 indexed poHash, address buyer, address supplier);
    event POAccepted(bytes32 indexed poHash);
    event FundsReleased(bytes32 indexed poHash, uint256 amount);

    // Create PO with SDC4 validation
    function createPurchaseOrder(
        bytes32 _schemaHash,
        bytes32 _instanceHash,
        address _supplier,
        uint256 _deliveryDeadline,
        string memory _ipfsUri,
        bytes memory _validationProof  // ZK proof or oracle signature
    ) external payable {
        // Verify schema is registered
        require(
            ISchemaRegistry(schemaRegistry).isValidSchema(_schemaHash),
            "Invalid SDC4 schema"
        );

        // Verify instance validates against schema
        require(
            validateInstance(_instanceHash, _schemaHash, _validationProof),
            "SDC4 instance validation failed"
        );

        // Verify payment matches PO total (extracted from SDC4 doc)
        uint256 expectedAmount = extractTotalAmount(_ipfsUri);
        require(msg.value == expectedAmount, "Payment mismatch");

        bytes32 poHash = keccak256(abi.encodePacked(_instanceHash, block.timestamp));

        purchaseOrders[poHash] = PurchaseOrder({
            schemaHash: _schemaHash,
            instanceHash: _instanceHash,
            buyer: msg.sender,
            supplier: _supplier,
            amount: msg.value,
            deliveryDeadline: _deliveryDeadline,
            ipfsUri: _ipfsUri,
            status: POStatus.Created,
            buyerSigned: true,   // Implicit via tx
            supplierSigned: false
        });

        emit POCreated(poHash, msg.sender, _supplier);
    }

    // Supplier accepts PO
    function acceptPurchaseOrder(bytes32 _poHash) external {
        PurchaseOrder storage po = purchaseOrders[_poHash];
        require(msg.sender == po.supplier, "Not supplier");
        require(po.status == POStatus.Created, "Invalid status");

        po.supplierSigned = true;
        po.status = POStatus.Accepted;

        emit POAccepted(_poHash);
    }

    // Supplier confirms shipment (with SDC4 856 ASN)
    function confirmShipment(
        bytes32 _poHash,
        bytes32 _asnInstanceHash,  // SDC4 856 Advanced Ship Notice
        string memory _asnIpfsUri
    ) external {
        PurchaseOrder storage po = purchaseOrders[_poHash];
        require(msg.sender == po.supplier, "Not supplier");
        require(po.status == POStatus.Accepted, "Invalid status");

        // TODO: Validate ASN references this PO

        po.status = POStatus.Shipped;
    }

    // Buyer confirms delivery
    function confirmDelivery(bytes32 _poHash) external {
        PurchaseOrder storage po = purchaseOrders[_poHash];
        require(msg.sender == po.buyer, "Not buyer");
        require(po.status == POStatus.Shipped, "Invalid status");

        // Release funds to supplier
        po.status = POStatus.Completed;
        payable(po.supplier).transfer(po.amount);

        emit FundsReleased(_poHash, po.amount);
    }

    // Validation helper (simplified - would use oracle or ZK proof)
    function validateInstance(
        bytes32 _instanceHash,
        bytes32 _schemaHash,
        bytes memory _proof
    ) internal view returns (bool) {
        // In production: Call Chainlink oracle or verify ZK proof
        // Oracle would fetch IPFS doc, validate against XSD, return signature
        return true; // Placeholder
    }

    // Extract total from SDC4 doc (simplified)
    function extractTotalAmount(string memory _ipfsUri) internal pure returns (uint256) {
        // In production: Parse SDC4 XML, find Summary/Total Amount component
        // For now, assume passed separately or use oracle
        return 0; // Placeholder
    }
}

Key SDC4 Integration Points:

Example 2: Freight Settlement & Supply Chain Tracking

Scenario: Track product movement using SDC4 856 Advanced Ship Notices, feeding a freight settlement record

Settlement Program (illustrative):


use anchor_lang::prelude::*;
use sha2::{Sha256, Digest};

declare_id!("Fg6PaFpoGXkYsidMpWTK6W2BeZ7FEfcYkg476zPFsLnS");

#[program]
pub mod sdc4_supply_chain {
    use super::*;

    pub fn create_shipment(
        ctx: Context<CreateShipment>,
        schema_hash: [u8; 32],
        instance_hash: [u8; 32],
        ipfs_cid: String,
        origin: String,        // SDC4 Location component
        destination: String,   // SDC4 Location component
        expected_delivery: i64
    ) -> Result<()> {
        let shipment = &mut ctx.accounts.shipment;

        // Verify SDC4 schema is registered
        require!(
            is_valid_schema(&schema_hash),
            ErrorCode::InvalidSchema
        );

        shipment.schema_hash = schema_hash;
        shipment.instance_hash = instance_hash;
        shipment.ipfs_cid = ipfs_cid;
        shipment.shipper = ctx.accounts.shipper.key();
        shipment.origin = origin;
        shipment.destination = destination;
        shipment.expected_delivery = expected_delivery;
        shipment.status = ShipmentStatus::Created;
        shipment.created_at = Clock::get()?.unix_timestamp;

        emit!(ShipmentCreated {
            shipment: shipment.key(),
            instance_hash,
            ipfs_cid: shipment.ipfs_cid.clone()
        });

        Ok(())
    }

    pub fn update_location(
        ctx: Context<UpdateLocation>,
        location_component_hash: [u8; 32],  // SDC4 Location Cluster hash
        latitude: i64,
        longitude: i64,
        timestamp: i64
    ) -> Result<()> {
        let shipment = &mut ctx.accounts.shipment;

        // Add location checkpoint
        shipment.checkpoints.push(LocationCheckpoint {
            component_hash: location_component_hash,
            latitude,
            longitude,
            timestamp,
            recorded_by: ctx.accounts.recorder.key()
        });

        shipment.status = ShipmentStatus::InTransit;

        Ok(())
    }

    pub fn confirm_delivery(ctx: Context<ConfirmDelivery>) -> Result<()> {
        let shipment = &mut ctx.accounts.shipment;

        require!(
            ctx.accounts.receiver.key() == shipment.destination_pubkey,
            ErrorCode::UnauthorizedReceiver
        );

        shipment.status = ShipmentStatus::Delivered;
        shipment.delivered_at = Some(Clock::get()?.unix_timestamp);

        emit!(ShipmentDelivered {
            shipment: shipment.key(),
            delivered_at: shipment.delivered_at.unwrap()
        });

        Ok(())
    }
}

#[account]
pub struct Shipment {
    pub schema_hash: [u8; 32],      // SDC4 856 ASN schema
    pub instance_hash: [u8; 32],    // SDC4 instance data hash
    pub ipfs_cid: String,           // Full SDC4 doc on IPFS
    pub shipper: Pubkey,
    pub origin: String,             // SDC4 Location component
    pub destination: String,
    pub destination_pubkey: Pubkey,
    pub expected_delivery: i64,
    pub status: ShipmentStatus,
    pub created_at: i64,
    pub delivered_at: Option<i64>,
    pub checkpoints: Vec<LocationCheckpoint>,
}

#[derive(AnchorSerialize, AnchorDeserialize, Clone, PartialEq)]
pub enum ShipmentStatus {
    Created,
    InTransit,
    Delivered,
    Exception
}

#[derive(AnchorSerialize, AnchorDeserialize, Clone)]
pub struct LocationCheckpoint {
    pub component_hash: [u8; 32],   // Hash of SDC4 Location Cluster
    pub latitude: i64,              // Fixed-point representation
    pub longitude: i64,
    pub timestamp: i64,
    pub recorded_by: Pubkey         // IoT device or carrier
}

#[event]
pub struct ShipmentCreated {
    pub shipment: Pubkey,
    pub instance_hash: [u8; 32],
    pub ipfs_cid: String
}

#[event]
pub struct ShipmentDelivered {
    pub shipment: Pubkey,
    pub delivered_at: i64
}

Key SDC4 Features Used:

Schema Validation Without a Trusted Intermediary

The Challenge

In a single-operator system: Trust the server to validate data

When there is no trusted intermediary: No central party to trust. The settlement engine must verify the data itself.

Problem: XSD schema validation is computationally expensive. Running full validation inside the settlement record itself is impractical.

Solution 1: Verification-Service Validation

Architecture:


1. Party creates the SDC4 document
2. Submits it to an independent verification service
3. Verification service:
   - Fetches the bound XSD schema
   - Validates the XML instance
   - Returns a signed validation result
4. Settlement engine verifies the service's signature
5. If valid, the settlement event proceeds

Example (Verification-Service Request):


contract SDC4Validator {
    using Chainlink for Chainlink.Request;

    address private oracle;
    bytes32 private jobId;
    uint256 private fee;

    mapping(bytes32 => ValidationResult) public validations;

    struct ValidationResult {
        bytes32 instanceHash;
        bool isValid;
        string errorMessage;
        uint256 timestamp;
    }

    function requestValidation(
        string memory ipfsUri,
        bytes32 schemaHash
    ) public returns (bytes32 requestId) {
        Chainlink.Request memory req = buildChainlinkRequest(
            jobId,
            address(this),
            this.fulfillValidation.selector
        );

        req.add("ipfsUri", ipfsUri);
        req.addBytes("schemaHash", abi.encodePacked(schemaHash));
        req.add("validationType", "XSD_SCHEMA");

        return sendChainlinkRequest(req, fee);
    }

    function fulfillValidation(
        bytes32 _requestId,
        bytes32 _instanceHash,
        bool _isValid,
        string memory _errorMessage
    ) public recordChainlinkFulfillment(_requestId) {
        validations[_instanceHash] = ValidationResult({
            instanceHash: _instanceHash,
            isValid: _isValid,
            errorMessage: _errorMessage,
            timestamp: block.timestamp
        });

        emit ValidationCompleted(_instanceHash, _isValid);
    }
}

Oracle (Off-Chain Service):


from lxml import etree
import requests

def validate_sdc4_instance(ipfs_uri, schema_hash):
    # Fetch SDC4 instance from IPFS
    instance_xml = requests.get(f"https://ipfs.io/ipfs/{ipfs_uri}").content

    # Fetch schema from registry (or IPFS)
    schema_url = get_schema_url(schema_hash)
    schema_doc = etree.parse(schema_url)
    schema = etree.XMLSchema(schema_doc)

    # Validate
    instance_doc = etree.fromstring(instance_xml)
    is_valid = schema.validate(instance_doc)

    if is_valid:
        return {
            "instance_hash": hash_xml(instance_xml),
            "is_valid": True,
            "error_message": ""
        }
    else:
        return {
            "instance_hash": hash_xml(instance_xml),
            "is_valid": False,
            "error_message": str(schema.error_log)
        }

Solution 2: Zero-Knowledge Proofs

More Advanced: Generate ZK proof that "this XML validates against this XSD schema" without revealing the full document.

Benefits:

Conceptual Flow:


1. Party creates the SDC4 document
2. Generates a ZK-SNARK proof:
   "I have an XML document with hash H that validates against schema S"
3. Submits the proof to the settlement engine
4. Settlement engine verifies the proof (cheap!)
5. Records the settlement event without seeing the document details

Example (Pseudocode - zkSNARKs are complex):


contract SDC4ZKValidator {
    // Verification key for XSD validation circuit
    bytes32 public verificationKey;

    function verifySDC4Instance(
        bytes32 instanceHash,
        bytes32 schemaHash,
        uint256[8] calldata proof  // ZK-SNARK proof
    ) public view returns (bool) {
        // Verify the proof
        // Proof asserts: "instanceHash validates against schemaHash"
        return zkVerify(verificationKey, proof, [instanceHash, schemaHash]);
    }
}

Status: This is cutting-edge research. zkXML projects exist but aren't production-ready yet. SDC4 is positioned to be the first settlement data standard to leverage this when mature.

The External-Data Trust Problem: Solved

What is the External-Data Trust Problem?

Definition: A settlement engine can't access external data directly. It needs a verification service to bring outside data into the settlement record.

The Trust Issue: How do you trust that service? If it lies, the conditional settlement releases incorrectly.

Current Approaches

Existing external-data services use reputation staking, delegated validator networks, or optimistic dispute resolution to make the service itself accountable.

Problem: These verify the service is honest, but don't verify the data is correct.

SDC4's Verification Enhancement

Key Insight: With SDC4, the verification service can provide cryptographic proof of data validity.

Enhanced Verification Flow:


1. Verification service receives request: "Get purchase order PO123456 from Walmart"
2. Service fetches the SDC4 document from source (Walmart's API, content-addressed store, etc.)
3. Service validates the SDC4 instance against its registered XSD schema
4. Service extracts relevant data (total amount, delivery date, etc.)
5. Service signs a package containing:
   - Original SDC4 instance hash
   - Schema hash
   - Validation result
   - Extracted data
   - Timestamp
6. Settlement engine verifies the service signature and schema hash
7. Engine trusts the extracted data because it is provably derived from valid SDC4

Example:


struct VerificationResponse {
    bytes32 instanceHash;      // Hash of complete SDC4 doc
    bytes32 schemaHash;        // Schema used for validation
    bool validationPassed;     // Did it validate?
    bytes extractedData;       // Specific fields needed (encoded)
    uint256 timestamp;
    bytes signature;           // Verification service signature over all above
}

function processVerifiedData(VerificationResponse memory response) public {
    // Verify the service signature
    require(
        verifyServiceSignature(response),
        "Invalid verification signature"
    );

    // Verify schema is trusted
    require(
        trustedSchemas[response.schemaHash],
        "Untrusted schema"
    );

    // Verify validation passed
    require(response.validationPassed, "Data validation failed");

    // Now trust the extracted data
    (uint256 totalAmount, uint256 deliveryDate) = abi.decode(
        response.extractedData,
        (uint256, uint256)
    );

    // Use in contract logic
    processPayment(totalAmount);
}

Benefit: The verification service can't lie about structured data because the schema validation is itself verifiable. If validation passed, the data structure is guaranteed correct.

Cross-Environment Interoperability

The Vision: Define Once, Settle Anywhere

The same SDC4 settlement transaction is verifiable across:

How It Works

1. Universal Schema Registry

Publish SDC4 schema hashes to every settlement environment:


// In every settlement environment (same registry definition)
contract SDC4SchemaRegistry {
    mapping(bytes32 => SchemaInfo) public schemas;

    struct SchemaInfo {
        bytes32 hash;
        string ipfsUri;      // XSD schema on IPFS
        uint256 version;
        bool active;
    }

    function registerSchema(
        bytes32 _hash,
        string memory _ipfsUri,
        uint256 _version
    ) public onlyGovernance {
        schemas[_hash] = SchemaInfo({
            hash: _hash,
            ipfsUri: _ipfsUri,
            version: _version,
            active: true
        });
    }
}

2. Environment-Agnostic Storage

Store SDC4 documents in content-addressed storage (environment-agnostic):


sdc-store://QmXyZ.../purchase-order-PO123456.xml

3. Cross-Environment Messaging

Use settlement bridges to pass SDC4 hashes between environments:

Originating Environment:


function createPurchaseOrder(/* ... */) external {
    bytes32 poHash = /* create PO */;

    // Forward to the receiving settlement environment
    sendCrossEnvironmentMessage(
        RECEIVING_ENV_ID,
        encode(poHash, docUri, totalAmount)
    );
}

Receiving Environment:


pub fn receive_purchase_order(
    ctx: Context<ReceivePO>,
    po_hash: [u8; 32],
    doc_uri: String,
    total_amount: u64
) -> Result<()> {
    // Verify same schema hash
    require!(
        ctx.accounts.schema_registry.is_valid(&po_hash),
        ErrorCode::InvalidSchema
    );

    // Create the corresponding settlement record entry
    let po = &mut ctx.accounts.purchase_order;
    po.origin_hash = po_hash;
    po.doc_uri = doc_uri;
    po.amount = total_amount;

    Ok(())
}

Result: A purchase order created in one settlement environment is instantly recognized in another because they share the same SDC4 schema registry and content-addressed storage.

Use Case: Multi-Environment Supply Chain Settlement

Scenario: An automotive manufacturer uses one environment for payment settlement, another for high-speed tracking, and a third for IoT data aggregation.

Flow:

All environments share the same SDC4 schemas. Data flows seamlessly because the structure is universal; only the execution environments differ.

Supply Chain Finance Use Case

Complete End-to-End Example

Parties:

Transaction Flow with SDC4:

Step 1: Purchase Order (payment settlement)

Ford creates an SDC4 850 PO:


<sdc4:dm-po123456>
  <dm-label>Ford Purchase Order</dm-label>
  <dm-language>en-US</dm-language>
  <dm-encoding>UTF-8</dm-encoding>
  <sdc4:ms-header>
    <label>PO Header</label>
    <sdc4:ms-po-number>
      <label>PO Number</label>
      <xdstring-value>FORD-PO-2025-001234</xdstring-value>
    </sdc4:ms-po-number>
    <sdc4:ms-total-amount>
      <label>Total Amount</label>
      <xdquantity-value>500000.00</xdquantity-value>
      <xdquantity-units>
        <label>Units</label>
        <xdstring-value>USD</xdstring-value>
      </xdquantity-units>
    </sdc4:ms-total-amount>
    <!-- ... -->
  </sdc4:ms-header>
</sdc4:dm-po123456>

Conditional settlement logic:


function createPO(bytes32 instanceHash, string docUri) payable {
    require(msg.value == 500000); // Settlement value in minor units
    purchaseOrders[instanceHash] = PO({
        buyer: msg.sender,
        supplier: SUPPLIER_ADDRESS,
        amount: msg.value,
        status: POStatus.Created
    });
}

Step 2: Supplier Accepts & Requests Financing

Supplier signs acceptance and requests advance payment from the lending program:


function requestFinancing(bytes32 poHash) external {
    PO memory po = purchaseOrders[poHash];
    require(msg.sender == po.supplier);

    // Lending program advances 80% of PO value
    uint256 advance = po.amount * 80 / 100;
    lendingProtocol.advance(msg.sender, advance, poHash);
}

Step 3: Shipment Notice (tracking environment)

Supplier ships goods and creates an SDC4 856 ASN in the tracking environment:


pub fn create_asn(
    ctx: Context<CreateASN>,
    po_hash: [u8; 32],
    asn_instance_hash: [u8; 32],
    ipfs_uri: String
) -> Result<()> {
    // Link ASN to PO via component reference
    let asn = &mut ctx.accounts.asn;
    asn.po_reference = po_hash;
    asn.instance_hash = asn_instance_hash;
    asn.ipfs_uri = ipfs_uri;
    asn.status = ASNStatus.InTransit;

    Ok(())
}

Step 4: Delivery & Payment Release (payment settlement)

Ford confirms delivery, triggering settlement:


function confirmDelivery(bytes32 poHash, bytes32 asnHash) external {
    PO storage po = purchaseOrders[poHash];
    require(msg.sender == po.buyer);

    // Verify the ASN exists in the tracking environment (via settlement bridge)
    require(
        trackingVerifier.verifyASN(asnHash),
        "ASN not confirmed in tracking environment"
    );

    // Release settlement value to supplier
    payable(po.supplier).transfer(po.amount);

    // Lending program receives repayment
    lendingProtocol.repay(poHash);
}

Benefits of SDC4 in This Flow

Transition Roadmap: From EDI to Verifiable Settlement

Phase 1: Hybrid Systems (NOW - 2026)

Keep existing EDI, add an SDC4 layer

Architecture:


Legacy X12 System
      ↓
  Converter ← → SDC4 Repository → Settlement Adapters
      ↓                                    ↓
Traditional VAN/AS2              Verifiable Settlement Layer

Activities:

Benefits:

Phase 2: Conditional Settlement Pilots (2026-2027)

Select specific settlement transactions for agent-executable release

Target Use Cases:

Architecture:


SDC4 Repository
      ↓
Conditional Settlement Middleware
      ↓
Verifiable Settlement Environments
      ↓
Verification Service Network
      ↑
Content-Addressed Document Storage

Activities:

Success Metrics:

Phase 3: Open Settlement Network (2027-2029)

Build an open settlement network using SDC4

Vision:

Architecture:


Open SDC4 Settlement Network
         ↓
   Schema Registry (community-governed)
         ↓
Multi-Environment Conditional Settlement
   /              \
Finance        Logistics    (+ others)
   \              /
 Content-Addressed Storage Layer
         ↓
 Verification Service Network

Features:

Phase 4: Settlement-Native (2029+)

New businesses born on verifiable settlement

Characteristics:

The Future State:

Why Now? The Perfect Moment

1. Legacy System Crisis

2. Settlement Infrastructure Maturity

3. Enterprise and Federal Settlement Adoption

The SDC4 Advantage

We're not chasing hype. We built a data architecture for integrity, clarity, and interoperability over 25 years. It happens to be exactly what a Verifiable Settlement Layer needs.

First-Mover Opportunity:

The market window is NOW. In 5 years, someone else will try to fill this gap. But they won't have our validation, our maturity, or our vision.

Next Steps

For EDI Practitioners

You've now seen:

Action: Start experimenting with SDC4 for internal use. Position your organization for verifiable, agent-executable settlement.

For Settlement and Integration Engineers

You've now seen:

Action: Integrate SDC4 into your settlement systems. Stop inventing custom schemas.

For Enterprise and Federal Leaders

You've now seen:

Action: Fund an SDC4 pilot program. Position your organization at the front of verifiable settlement.

For Investors

You've now seen:

Action: Let's talk. Settlement is where the value moves.

Next Document: VSL_DATA_LAYER_VISION.html - The complete vision for SDC4 as the universal data standard for verifiable settlement.

Document Navigation: ← Previous: SDC4 Solution | Next: Verifiable Settlement Layer Vision →

About This Documentation

This document describes the open SDC4 specification maintained by the Semantic Data Charter community.

Open Source:

Commercial Implementation:

See ABOUT_SDC4_AND_SDCSTUDIO.md for details.

*This document is part of the SDC4 X12 EDI Integration Guide series.* *Author: Timothy W. Cook (Founder, Axius SDC, Inc.) w/Claude (Anthropic AI Assistant)* *License: Creative Commons Attribution 4.0 International (CC BY 4.0)*