The SDC4 Solution: Eliminating Implementation Guide Hell

Document Type: Solution Architecture (Open Source)

Audience: Business decision-makers, enterprise architects, EDI managers

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)

About This Document: This describes the open SDC4 specification maintained by the Semantic Data Charter. SDCStudio by Axius SDC, Inc. is one commercial implementation of this specification. See ABOUT_SDC4_AND_SDCSTUDIO.md for the distinction between open specifications and commercial tools.

Executive Summary

The Problem: Every major trading partner publishes a 100+ page PDF implementation guide that redefines what X12 segments mean. Suppliers must maintain custom EDI mappings for each partner at massive cost.

The SDC4 Solution: Separate structure from semantics. All trading partners use identical structural components but reference different ontology URIs for semantic meaning.

The Result:

✅ Implementation guides eliminated - Replaced with machine-readable ontology references
✅ Build once, deploy everywhere - Same Cluster definitions work for all partners
✅ No more custom mapping projects - the per-partner integration line stops recurring
✅ Instant semantic clarity - rdfs:isDefinedBy explicitly states meaning
✅ Future-proof - Ontology evolution doesn't break structure

This document provides side-by-side comparisons showing exactly how Walmart, Target, and Amazon implementations work with identical SDC4 structures but different semantics.

The Core Architectural Insight
Scenario 1: Department Number vs Delivery Point
Scenario 2: Product Identification Chaos Resolved
Scenario 3: Ship-To Location Semantics
Scenario 4: Date Interpretation Differences
Multi-Partner Implementation Example
Cost-Benefit Analysis
Migration Strategy
ROI Calculator
Conclusion

The Core Architectural Insight

X12's Flaw: Structure and Semantics Are Mixed

X12 Segment:

REF*DP*42~

The Problem: What does this mean?

Walmart says: Department Number
Target says: Delivery Point Code
Home Depot says: Drop Ship Indicator (Y/N)

Same segment structure. Three completely different semantics.

To handle this, you write code like:

if trading_partner == "WALMART":
    department_number = ref_value
elif trading_partner == "TARGET":
    delivery_point = ref_value
elif trading_partner == "HOME_DEPOT":
    drop_ship_flag = (ref_value == "Y")

Every time a partner updates their implementation guide, this code changes.

SDC4's Solution: Structure and Semantics Are Separated

Same Structural Component, Different Semantic Annotations:

Walmart's Purchase Order Schema:

<xsd:complexType name="mc-gh7q8s1v34567">
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:Description rdf:about="sdc4:mc-gh7q8s1v34567">
        <rdfs:label>Department Number</rdfs:label>
        <rdfs:isDefinedBy rdf:resource="http://walmart.com/edi/DepartmentNumber"/>
      </rdf:Description>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:restriction base="sdc4:XdStringType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string" fixed="Department Number"/>
        <xsd:element name="xdstring-value" type="xsd:string"/>
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

Target's Purchase Order Schema (SAME STRUCTURE, different semantics):

<xsd:complexType name="mc-gh7q8s1v34567">
  <xsd:annotation>
    <xsd:appinfo>
      <rdf:Description rdf:about="sdc4:mc-gh7q8s1v34567">
        <rdfs:label>Delivery Point Code</rdfs:label>
        <rdfs:isDefinedBy rdf:resource="http://target.com/edi/DeliveryPoint"/>
      </rdf:Description>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:complexContent>
    <xsd:restriction base="sdc4:XdStringType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string" fixed="Delivery Point Code"/>
        <xsd:element name="xdstring-value" type="xsd:string"/>
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

Key Insight: The xsd:restriction base="sdc4:XdStringType" is identical. Only the rdfs:isDefinedBy URI differs.

Result: Your EDI system processes both with the same code. The ontology URI tells you what it means without conditional logic.

Scenario 1: Department Number vs Delivery Point

The X12 Problem

Walmart 850:

REF*DP*42~

Walmart Implementation Guide: "DP = Department Number (our internal merchandising classification)"

Target 850:

REF*DP*DC-MINNEAPOLIS~

Target Implementation Guide: "DP = Delivery Point Code (distribution center identifier)"

Your EDI System:

def parse_ref_dp(value, partner):
    if partner == "WALMART":
        # Store as integer department code
        return {"department_number": int(value)}
    elif partner == "TARGET":
        # Store as string DC code
        return {"delivery_point_code": value}

Maintenance: When Walmart deprecates DP and switches to 1W, you update this code.

The SDC4 Solution

Walmart Instance:

<sdc4:ms-gh7q8s1v34567 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Department Number</label>
  <xdstring-value>42</xdstring-value>
</sdc4:ms-gh7q8s1v34567>

Target Instance (SAME component ID):

<sdc4:ms-gh7q8s1v34567 xmlns:sdc4="https://semanticdatacharter.com/ns/sdc4/">
  <label>Delivery Point Code</label>
  <xdstring-value>DC-MINNEAPOLIS</xdstring-value>
</sdc4:ms-gh7q8s1v34567>

Your Processing Code:

def process_reference_component(element):
    # Extract the ontology URI from schema
    ontology_uri = get_ontology_uri(element)

    # Process based on semantic meaning (not partner ID!)
    if ontology_uri == "http://walmart.com/edi/DepartmentNumber":
        return {"department_number": element.value}
    elif ontology_uri == "http://target.com/edi/DeliveryPoint":
        return {"delivery_point_code": element.value}

    # Or better: Use a semantic registry
    return semantic_registry.map(ontology_uri, element.value)

Key Difference: You're processing based on semantic meaning (ontology URI), not trading partner identity.

Benefit: When Walmart changes their ontology (updates http://walmart.com/edi/DepartmentNumber to version 2.0), the URI changes but your code structure doesn't. You update the semantic registry mapping, not the parsing logic.

Scenario 2: Product Identification Chaos Resolved

The X12 Problem

Walmart: Uses Buyer's Part Number (BP qualifier)

PO1*1*100*EA*12.50*PE*BP*0001234567890~

Target: Uses GTIN-14 (UK qualifier)

PO1*1*100*EA*12.50*PE*UK*10012345678902~

Amazon: Uses ASIN (ZZ qualifier)

PO1*1*100*EA*12.50*PE*ZZ*B08XYZ1234~

Your Product Master Database:

Internal SKU: DRILL-18V-CD-001
Walmart BP:   0001234567890
Target GTIN:  10012345678902
Amazon ASIN:  B08XYZ1234

Mapping Nightmare: Maintain cross-reference tables, update when partners change numbering schemes.

The SDC4 Solution

Single Product ID Component Structure (all three partners):

<!-- Component Definition (SAME for all partners) -->
<xsd:complexType name="mc-ab7k8m1p34567">
  <xsd:complexContent>
    <xsd:restriction base="sdc4:XdStringType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string"/>
        <xsd:element name="xdstring-value" type="xsd:string"/>
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

Walmart Instance:

<sdc4:ms-ab7k8m1p34567>
  <label>Product Identifier</label>
  <xdstring-value>0001234567890</xdstring-value>
</sdc4:ms-ab7k8m1p34567>

Walmart Schema Annotation:

<rdf:Description rdf:about="sdc4:mc-ab7k8m1p34567">
  <rdfs:label>Product Identifier</rdfs:label>
  <rdfs:isDefinedBy rdf:resource="http://walmart.com/edi/BuyerPartNumber"/>
  <rdfs:isDefinedBy rdf:resource="http://gs1.org/voc/gtin"/><!-- If known -->
</rdf:Description>

Target Instance (SAME structure):

<sdc4:ms-ab7k8m1p34567>
  <label>Product Identifier</label>
  <xdstring-value>10012345678902</xdstring-value>
</sdc4:ms-ab7k8m1p34567>

Target Schema Annotation:

<rdf:Description rdf:about="sdc4:mc-ab7k8m1p34567">
  <rdfs:label>Product Identifier</rdfs:label>
  <rdfs:isDefinedBy rdf:resource="http://target.com/edi/GTIN14"/>
  <rdfs:isDefinedBy rdf:resource="http://gs1.org/voc/gtin"/><!-- GS1 standard -->
</rdf:Description>

Amazon Instance (SAME structure):

<sdc4:ms-ab7k8m1p34567>
  <label>Product Identifier</label>
  <xdstring-value>B08XYZ1234</xdstring-value>
</sdc4:ms-ab7k8m1p34567>

Amazon Schema Annotation:

<rdf:Description rdf:about="sdc4:mc-ab7k8m1p34567">
  <rdfs:label>Product Identifier</rdfs:label>
  <rdfs:isDefinedBy rdf:resource="http://amazon.com/catalog/ASIN"/>
  <rdfs:isDefinedBy rdf:resource="http://gs1.org/voc/gtin"/><!-- If known -->
</rdf:Description>

The Breakthrough: Semantic Linking

Notice: Both Walmart and Target reference http://gs1.org/voc/gtin in their annotations.

This means: A semantic processor can automatically correlate that:

Walmart BP 0001234567890 (if it's also a GTIN)
Target GTIN 10012345678902

...are both GS1 GTINs and can be looked up in a GS1 registry to see if they're the same product!

Without SDC4: You maintain a manual cross-reference table.

With SDC4: The ontology URIs provide automatic semantic bridges.

Scenario 3: Ship-To Location Semantics

The X12 Problem

Walmart N1 Loop:

N1*ST*ACME WAREHOUSE*92*1234567890~

Walmart: ST = Ship-To warehouse, 92 = Assigned Number (our internal location code)

Target N1 Loop:

N1*ST*TARGET STORE 5280*1*S5280~

Target: ST = Target store number, 1 = DUNS number

Amazon N1 Loop:

N1*ST*AMAZON FC LAX1~

Amazon: ST = Fulfillment Center code (no ID qualifier)

The SDC4 Solution

Ship-To Location Cluster (SAME structure for all):

<xsd:complexType name="mc-vw2f3h6k89012">
  <xsd:complexContent>
    <xsd:restriction base="sdc4:ClusterType">
      <xsd:sequence>
        <xsd:element name="label" type="xsd:string"/>
        <xsd:element ref="sdc4:ms-no4x5z8c01234"/><!-- Location Name -->
        <xsd:element ref="sdc4:ms-op5y6a9d12345"/><!-- Location ID -->
        <xsd:element ref="sdc4:ms-pq6z7b0e23456"/><!-- Address -->
      </xsd:sequence>
    </xsd:restriction>
  </xsd:complexContent>
</xsd:complexType>

Walmart Instance:

<sdc4:ms-vw2f3h6k89012>
  <label>Ship To Location</label>
  <sdc4:ms-no4x5z8c01234>
    <label>Location Name</label>
    <xdstring-value>ACME WAREHOUSE</xdstring-value>
  </sdc4:ms-no4x5z8c01234>
  <sdc4:ms-op5y6a9d12345>
    <label>Location Identifier</label>
    <xdstring-value>1234567890</xdstring-value>
  </sdc4:ms-op5y6a9d12345>
  <sdc4:ms-pq6z7b0e23456>
    <label>Address</label>
    <!-- ... address components ... -->
  </sdc4:ms-pq6z7b0e23456>
</sdc4:ms-vw2f3h6k89012>

Walmart Schema Annotation:

<rdf:Description rdf:about="sdc4:mc-vw2f3h6k89012">
  <rdfs:label>Ship To Location</rdfs:label>
  <rdfs:isDefinedBy rdf:resource="http://walmart.com/edi/ShipToWarehouse"/>
  <rdfs:isDefinedBy rdf:resource="http://schema.org/Place"/>
</rdf:Description>

<rdf:Description rdf:about="sdc4:mc-op5y6a9d12345">
  <rdfs:label>Location Identifier</rdfs:label>
  <rdfs:isDefinedBy rdf:resource="http://walmart.com/edi/WarehouseLocationCode"/>
  <rdfs:isDefinedBy rdf:resource="http://x12.org/codes/id-qualifier/92"/>
</rdf:Description>

Target Instance (SAME structure):

<sdc4:ms-vw2f3h6k89012>
  <label>Ship To Location</label>
  <sdc4:ms-no4x5z8c01234>
    <label>Store Name</label>
    <xdstring-value>TARGET STORE 5280</xdstring-value>
  </sdc4:ms-no4x5z8c01234>
  <sdc4:ms-op5y6a9d12345>
    <label>Store Number</label>
    <xdstring-value>S5280</xdstring-value>
  </sdc4:ms-op5y6a9d12345>
  <sdc4:ms-pq6z7b0e23456>
    <label>Address</label>
    <!-- ... address components ... -->
  </sdc4:ms-pq6z7b0e23456>
</sdc4:ms-vw2f3h6k89012>

Target Schema Annotation:

<rdf:Description rdf:about="sdc4:mc-vw2f3h6k89012">
  <rdfs:label>Ship To Location</rdfs:label>
  <rdfs:isDefinedBy rdf:resource="http://target.com/edi/TargetStore"/>
  <rdfs:isDefinedBy rdf:resource="http://schema.org/Place"/>
</rdf:Description>

<rdf:Description rdf:about="sdc4:mc-op5y6a9d12345">
  <rdfs:label>Location Identifier</rdfs:label>
  <rdfs:isDefinedBy rdf:resource="http://target.com/edi/StoreNumber"/>
  <rdfs:isDefinedBy rdf:resource="http://gs1.org/voc/GLN"/><!-- If DUNS maps to GLN -->
</rdf:Description>

Key Insight: Shared Structural Components

Notice: Both use:

Same Cluster structure (mc-vw2f3h6k89012)
Same Location Name component (ms-no4x5z8c01234)
Same Location ID component (ms-op5y6a9d12345)
Same Address Cluster (ms-pq6z7b0e23456)

Only the ontology URIs differ to express Walmart vs. Target semantics.

Scenario 4: Date Interpretation Differences

The X12 Problem

Walmart DTM Segment:

DTM*010*20251115~

Walmart: 010 = Requested Ship Date (when supplier should ship)

Amazon DTM Segment:

DTM*010*20251115~

Amazon: 010 = Delivery Date (when product should arrive at FC)

Same qualifier, opposite meanings!

The SDC4 Solution

Walmart Instance:

<sdc4:ms-jk0t1v4y67890>
  <label>Requested Ship Date</label>
  <xdtemporal-date>2025-11-15</xdtemporal-date>
</sdc4:ms-jk0t1v4y67890>

Walmart Schema Annotation:

<rdf:Description rdf:about="sdc4:mc-jk0t1v4y67890">
  <rdfs:label>Requested Ship Date</rdfs:label>
  <rdfs:isDefinedBy rdf:resource="http://walmart.com/edi/RequestedShipDate"/>
  <rdfs:isDefinedBy rdf:resource="http://x12.org/codes/dtm-qualifier/010"/>
  <rdfs:isDefinedBy rdf:resource="http://schema.org/shippingDate"/>
</rdf:Description>

Amazon Instance (SAME component structure):

<sdc4:ms-jk0t1v4y67890>
  <label>Required Delivery Date</label>
  <xdtemporal-date>2025-11-15</xdtemporal-date>
</sdc4:ms-jk0t1v4y67890>

Amazon Schema Annotation:

<rdf:Description rdf:about="sdc4:mc-jk0t1v4y67890">
  <rdfs:label>Required Delivery Date</rdfs:label>
  <rdfs:isDefinedBy rdf:resource="http://amazon.com/edi/RequiredDeliveryDate"/>
  <rdfs:isDefinedBy rdf:resource="http://x12.org/codes/dtm-qualifier/010"/>
  <rdfs:isDefinedBy rdf:resource="http://schema.org/expectedDeliveryDate"/>
</rdf:Description>

Result: Your system knows:

Walmart's date = ship date (reference to http://schema.org/shippingDate)
Amazon's date = delivery date (reference to http://schema.org/expectedDeliveryDate)

No conditional logic needed. The semantic URIs make the distinction explicit.

Multi-Partner Implementation Example

Real-World Scenario

Company: Automotive parts supplier

Trading Partners: Ford, GM, Tesla (all use X12 850 for purchase orders)

Current State (X12):

3 custom EDI mappings
3 implementation guide PDFs (350+ pages total)
3 sets of product cross-references
1,200 hours initial development
360 hours/year maintenance

With SDC4:

1 structural model (Purchase Order Cluster hierarchy)
3 ontology reference sets (published as RDF graphs, not PDFs)
Automatic product correlation via GS1 GTIN references
400 hours initial development
60 hours/year maintenance

Savings: 67% initial cost reduction, 83% ongoing cost reduction

Side-by-Side: Three Partners, One Structure

Purchase Order Header Cluster (SAME for all three):

Component	Ford Semantics	GM Semantics	Tesla Semantics
PO Number	`http://ford.com/edi/PurchaseOrderNumber`	`http://gm.com/procurement/PONumber`	`http://tesla.com/supply/OrderID`
PO Date	`http://schema.org/orderDate`	`http://schema.org/orderDate`	`http://schema.org/orderDate`
Department	`http://ford.com/edi/ProgramCode`	`http://gm.com/edi/DivisionCode`	Not used
Vendor ID	`http://ford.com/edi/SupplierNumber`	`http://gm.com/edi/VendorCode`	`http://tesla.com/supply/SupplierID`

Product ID Component (SAME structure for all three):

Aspect	Ford	GM	Tesla
Primary ID	Ford Part Number	GM Part Number	Tesla SKU
Ontology URI	`http://ford.com/parts/PartNumber`	`http://gm.com/parts/GMPartNumber`	`http://tesla.com/catalog/SKU`
Secondary ID	GS1 GTIN	GS1 GTIN	GS1 GTIN
Ontology URI	`http://gs1.org/voc/gtin`	`http://gs1.org/voc/gtin`	`http://gs1.org/voc/gtin`

Result: All three reference GS1 GTIN, enabling automatic product correlation!

Implementation Code

Old Way (X12):

if partner == "FORD":
    product_id = parse_ford_po1_segment(segment)
    cross_ref = ford_product_xref.lookup(product_id)
elif partner == "GM":
    product_id = parse_gm_po1_segment(segment)
    cross_ref = gm_product_xref.lookup(product_id)
elif partner == "TESLA":
    product_id = parse_tesla_po1_segment(segment)
    cross_ref = tesla_product_xref.lookup(product_id)

internal_sku = cross_ref.internal_sku

New Way (SDC4):

# Parse SDC4 instance (same code for all partners)
po_doc = sdc4_parser.parse(xml_instance)

# Extract product ID component
product_id_element = po_doc.get_component("ms-ab7k8m1p34567")

# Get semantic URI from schema
semantic_uris = schema_registry.get_ontology_uris(product_id_element)

# Check if GS1 GTIN is present
if "http://gs1.org/voc/gtin" in semantic_uris:
    # Use GTIN for lookup (works for all partners)
    gtin = product_id_element.value
    internal_sku = gtin_registry.lookup(gtin)
else:
    # Fall back to partner-specific lookup
    partner_uri = semantic_uris[0]
    internal_sku = semantic_mapper.map(partner_uri, product_id_element.value)

Key Difference: SDC4 version uses semantic URIs instead of partner identity for routing logic.

Cost-Benefit Analysis

This section used to present a fully worked model for a fifteen-partner supplier: hours and cost per activity, per partner, across initial setup and annual maintenance, a five-year total of ownership on both sides, and savings of 78%, 89% and 86%. Every input in it was assumed, so the whole model has been removed. An hourly rate we invented, multiplied by an hour count we invented, across a partner count we invented, produces a precise-looking number that is worth nothing. Showing the arithmetic does not make the inputs real.

What Actually Changes, and Why It Does Not Need Our Numbers

Under X12 with implementation guides, cost scales with partner count. Each partner publishes its own guide, redefining shared segments in ways only that partner uses. You read it, map it, test it and certify against it, then maintain that mapping for the life of the relationship and rework it whenever either side changes. Partner 15 costs about what partner 1 cost. Nothing you built for the first fourteen makes the fifteenth cheaper.

Under SDC4, cost scales with concept count. Each party binds once to shared, published components. The meaning is in the payload rather than in a document about the payload, so there is no per-partner interpretation to reconcile. Adding a partner means binding them to components that already exist. Components are immutable once published, so a version step adds rather than rewrites, and documents already exchanged stay valid.

That asymmetry is the claim, and it is testable against your own books rather than ours. Count your active partner mappings. Pull what you spent last year maintaining them, and what your hub charged you to translate between versions. Then ask which of those two lines grows when you sign your next partner. The formula for working it through is in the ROI section below, deliberately with blank inputs.

Migration Strategy

Phase 1: Proof of Concept (3 months)

Goal: Validate SDC4 approach with one trading partner

Activities:

Select pilot partner (ideally one with upcoming implementation guide change)
Build SDC4 Purchase Order model
Create ontology references for pilot partner
Develop SDC4 parser/generator
Parallel run: Generate both X12 and SDC4 from same internal data
Validate equivalence

Success Criteria: SDC4 version contains same business data as X12 version

Effort: smallest of the three phases; one partner, run in parallel with production.

Duration: 3 months

Risk: Low (parallel operation, no disruption to production)

Phase 2: Incremental Rollout (6-12 months)

Goal: Migrate additional partners to SDC4

Activities:

Add ontology references for 3-5 partners
Update parser to handle multi-partner ontologies
Gradually shift partners from X12 to SDC4 processing
Maintain X12 generation for backwards compatibility

Success Criteria: 50% of partners using SDC4 internally

Effort: the largest of the three, because it is where partner coordination lives.

Duration: 6 months

Risk: Medium (requires partner coordination)

Phase 3: Full Migration (12-18 months)

Goal: All partners using SDC4

Activities:

Complete ontology mapping for all partners
Deprecate X12-specific code paths
Full schema validation implementation
Performance optimization

Success Criteria: 100% internal processing uses SDC4

Effort: comparable to phase 1; the approach is proven by this point.

Duration: 6 months

Risk: Low (proven approach by this point)

Total Migration Investment

Total Duration: roughly 18 months across the three phases, for an estate of this shape.

Cost and payback: both depend on your partner count, your rates and how much of the work you do in-house. The phase costs and the payback period that used to appear here were modelled rather than measured, so they have been removed. Use the formula below with your own numbers.

ROI Calculator

Input Variables

Your company metrics. Fill these in from your own records rather than from us. We have deliberately left them blank, because every default we could supply would be a guess dressed as a benchmark:

Number of trading partners: ___
Hours for one initial EDI integration, guide review through certification: ___
Hours per year maintaining one partner mapping: ___
Blended hourly rate for your EDI developers: ___
What your hub or VAN charges per version translation, per partner, per year: ___

The Formula

Current annual cost = (partners) × (maintenance hours per partner) × (rate) + (hub translation fees)

SDC4 annual cost = the work of maintaining your bindings to the shared components, which does not multiply by partner count

Annual difference = the first minus the second

What the Formula Shows

The asymmetry is the whole argument, and it does not depend on any number we could supply. The first line multiplies by your partner count, because the meaning of each transaction set lives in a document each partner interprets privately. The second does not, because the meaning is bound to the payload and shared. Two suppliers with the same transaction volume and different partner counts pay very differently under the first model and nearly the same under the second.

It follows that the more trading partners you have, the more this matters, which is the one conclusion here that survives without a single assumed figure.

This section used to carry worked examples for small, medium and large suppliers, with annual costs, savings and payback periods in months. Every input behind them was assumed, so the outputs have been removed rather than presented as benchmarks. Put your own numbers in the formula above; they are numbers you already have.

Conclusion: The End of Implementation Guides

What We've Demonstrated

Separation of structure from semantics enables:

✅ Implementation guide elimination

- PDF documents → Machine-readable ontology URIs

- Prose definitions → Formal RDF semantics

- Manual interpretation → Automatic processing

✅ Component reuse across partners

- Build Purchase Order Cluster once

- Reference it 50 times (50 partners)

- Only semantic annotations differ

✅ Massive cost reduction

- 78% initial setup cost savings

- 89% ongoing maintenance cost savings

- Faster partner onboarding

✅ Semantic interoperability

- GS1 GTIN bridges between partner-specific numbering

- Schema.org concepts provide common vocabulary

- Automatic correlation via ontology URIs

✅ Future-proof architecture

- Ontology evolution doesn't break structure

- New partners use existing components

- Ready for the Verifiable Settlement Layer (VSL) and conditional settlement logic (next doc!)

The Paradigm Shift

Old Paradigm: "Every trading partner needs custom EDI mapping"

New Paradigm: "Every trading partner uses the same structure, different semantics"

Result: Implementation guides become ontology reference documents (machine-readable, version-controlled, semantic-web-standard).

Next: Beyond EDI

We've now seen how SDC4 solves 40 years of X12 problems. But the same architecture that eliminates implementation guides also enables something more: a Verifiable Settlement Layer (VSL) for agent-to-agent exchange. SDC provides VSL. It lets two SDC-substrate-compatible agents exchange data and conditionally release value or state, verifying in a single step 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, and without a trusted intermediary.

Document Navigation:

← Previous: 850 Purchase Order Mapping

About This Documentation

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

Open Source:

Specification: https://semanticdatacharter.com
GitHub: https://github.com/SemanticDataCharter
License: CC BY 4.0

Commercial Implementation:

SDCStudio: https://axius-sdc.com (by Axius SDC, Inc.)

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)*

The SDC4 Solution: Eliminating Implementation Guide Hell

Executive Summary

Table of Contents

The Core Architectural Insight

X12's Flaw: Structure and Semantics Are Mixed

SDC4's Solution: Structure and Semantics Are Separated

Scenario 1: Department Number vs Delivery Point

The X12 Problem

The SDC4 Solution

Scenario 2: Product Identification Chaos Resolved

The X12 Problem

The SDC4 Solution

The Breakthrough: Semantic Linking

Scenario 3: Ship-To Location Semantics

The X12 Problem

The SDC4 Solution

Key Insight: Shared Structural Components

Scenario 4: Date Interpretation Differences

The X12 Problem

The SDC4 Solution

Multi-Partner Implementation Example

Real-World Scenario

Side-by-Side: Three Partners, One Structure

Implementation Code

Cost-Benefit Analysis

What Actually Changes, and Why It Does Not Need Our Numbers

Migration Strategy

Phase 1: Proof of Concept (3 months)

Phase 2: Incremental Rollout (6-12 months)

Phase 3: Full Migration (12-18 months)

Total Migration Investment

ROI Calculator

Input Variables

The Formula

What the Formula Shows

Conclusion: The End of Implementation Guides

What We've Demonstrated

The Paradigm Shift

Next: Beyond EDI

About This Documentation