One thesis: custody does not change hands at the grain of a product or a shipment — it changes hands at the grain of a logistic unit, and the SSCC is the only identifier in the stack that names one. A GTIN names a product class; a tracking number names a carrier's billing object; a BOL names paper. This pallet, this case-load, the physical thing on dock 4 right now — that is the SSCC's grain, and everything that matters in a custody record hangs off it.
Eighteen digits, decomposed
The SSCC (Serial Shipping Container Code) travels as AI (00) and decomposes cleanly:
$ barcoding resolve '(00)106141412345678908' --json
{ "scheme": "gs1.sscc", "carrier": "gs1-128",
"canonical": "106141412345678908",
"extension": "1",
"companyPrefix": "0614141",
"serialRef": "234567890",
"check": "mod10 pass",
"epc": "urn:epc:id:sscc:0614141.1234567890" }
Extension digit (yours to assign — a serial-capacity expander, not a package-type code), your GS1 company prefix, a serial reference you allocate, and the same public mod-10 check digit as every GS1 key. The allocation discipline is the part that bites operationally: serial references must not repeat within GS1's minimum reuse window, so range management is a real bookkeeping obligation on whoever prints — which, on a multi-shipper dock, is sometimes you. Grammar and allocation rules: /schemes/sscc.
One SSCC through the whole stack
Follow those eighteen digits from the print room to the receiving scan — this is the join you currently maintain by hand, N shippers deep.
On the label. The GS1 logistic label carries (00)106141412345678908 in GS1-128 — generated locally, generate rendering symbol and check digit from your prefix and range, round-tripped through resolve before the print run so the label you print is provably the label you can read back.
In the ASN. The X12 856 announces the shipment hierarchically — shipment, order, pack, item — and at the pack level carries marks-and-numbers with the qualifier that declares an SSCC-18 plus its application identifier: the twenty characters 00106141412345678908, AI included, exactly what the label says. (Stedi's open X12 reference documents the 856's segments; linked, never copied.) The despatch advice is, structurally, a promise about which SSCCs will arrive carrying which GTINs — the trace carries its paperwork, in the family's phrase, and the paperwork lives at transactions.dev.
In the event. When the pallet is built, an EPCIS AggregationEvent records what physically contains what — and its parent is the SSCC:
{ "type": "AggregationEvent",
"parentID": "urn:epc:id:sscc:0614141.1234567890",
"childEPCs": ["urn:epc:id:sgtin:0614141.107346.2017", "..."],
"action": "ADD",
"bizStep": "packing" }
At receiving. Your dock scan of one GS1-128 resolves the SSCC, joins the ASN by those same eighteen digits, and inherits the entire declared contents — which is why case/each reconciliation is an SSCC problem before it is anything else. And because receiving is a custody handoff performed by a person or an agent, it is also where the record's Who question lands hardest — the two grains of Who is that post.
One identifier, four appearances, zero mapping tables. That is the SSCC working as designed.
The duality: one pallet, two names, no standing join
Now the landscape fact your integration backlog already knows. The moment a logistic unit enters a parcel or LTL network it acquires a second name — the carrier's tracking number — and the connector-by-connector survey of the parcel API tier (2026-07) verifies what happens next: the mainstream shipping APIs carry tracking_number plus carrier and no GTIN, GLN or SSCC anywhere in their schemas. The carriers split: FedEx Ground accepts SSCC-18 barcodes as package identification, while the UPS shipping API's schema carries the 1Z number only — no SSCC field at all. And no WMS in the surveyed set exposes SSCC either.
So the same physical pallet is urn:epc:id:sscc:0614141.1234567890 to the trace and 1Z… to the network that moved it, and no system of record holds the equivalence. The identity your shipper's ASN promised is severed at the label printer and re-derived — by you, from PDFs and portal lookups — at every claim, every OS&D dispute, every trace-back that crosses a carrier boundary. The parcel networks did not decide to discard product identity; their data models simply never had a place for it. The severance is structural, which is why it never gets fixed upstream and always lands on the integration desk.
That is the demand map for this layer in one paragraph: resolve reads both grammars today — SSCCs off labels and ASNs, tracking numbers in their carrier formats — locally and free, so at minimum your own systems can hold both names of one pallet side by side. Restoring the join at scale, with the evidence attached, is network-half territory; the access flow asks which carriers and shippers cross your dock, and provisioning follows the list.
The close, for the seat that owns the WMS integrations: every format war you fight is downstream of one grain error — systems that model shipments and products but not logistic units. The pallet is the thing that exists. The SSCC is its name. A custody record keyed on anything else is a record about abstractions, and abstractions don't sit on dock 4 with a temperature excursion at 2 a.m.
Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.