N1 loops are your sourceList: party GLNs land in core fields

Written for ED-1 — the supply-chain ISV / traceability-vendor engineering org — the integration engineer holding a party segment and four qualifier codes.

One thesis: CBV 2.0 §7.4 defines exactly three source/destination types — owning_party, possessing_party, location — and the party loops of an 856 or 850 map onto them with zero extensions: the who-owns and the where of a shipment land in core fields the standard already reserved.

Why exactly three types is a feature

Party modeling is where schemas go to sprawl. Any committee asked to enumerate supply-chain roles produces dozens — buyer, seller, consignee, freight payer, broker, mark-for. CBV 2.0 §7.4 refused the sprawl: an event's source and destination carry three types only. owning_party — whose goods these are, and become. possessing_party — who physically holds them. location — where the transfer runs from and to. Everything else a document says about parties is document detail, not event structure; the standard resists your org chart so the record stays queryable across organizations that do not share one. The N1 loop's dozen-plus role codes still exist and still matter — to the document. The compile's job is to project the few that assert event semantics onto the three types, and to leave the rest as document detail rather than inventing types the standard refused.

The machine form is in the pinned EPCIS 2.0 JSON-LD context (sha256 5056c65f…, digests at epcis.dev/conformance):

"owning_party": "cbv:SDT-owning_party",
"location":    "cbv:SDT-location"

The N1 mapping, direction decided by the qualifier

An 856's shipment level names its parties in N1 loops: a role qualifier in N101, a name, and — in a well-formed retail document — an identifier qualified UL in N103, meaning the value is a GLN. (N1 structure at element depth is the licensed reference's job — linked at Stedi's X12 reference, never republished.) The compile maps role to type and to direction:

N1*SF  ship-from  GLN → sourceList       { type: "location" }      AI 414
N1*ST  ship-to    GLN → destinationList  { type: "location" }      AI 414
N1*SE  seller     GLN → sourceList       { type: "owning_party" }  AI 417
N1*BY  buyer      GLN → destinationList  { type: "owning_party" }  AI 417

From the golden fixture 856-ship-notice-01.edi — four N1 lines in, four core-field entries out:

"sourceList": [
  { "type": "location",     "source": "https://id.gs1.org/414/0614141000012" },
  { "type": "owning_party", "source": "https://id.gs1.org/417/0614141000005" }
],
"destinationList": [
  { "type": "location",     "destination": "https://id.gs1.org/414/0724142000024" },
  { "type": "owning_party", "destination": "https://id.gs1.org/417/0724142000017" }
]

Two things carry the semantics. The SDT type says what kind of endpoint this is; the Digital Link AI agrees with it — party GLN rides AI 417, location GLN rides AI 414. The identifier syntax family is §8.7's; the golden-corpus reference shape transaction-event-po.json shows the equivalent EPC URN spelling (urn:epc:id:pgln:0614141.00001) for pipelines that carry a company-prefix split. Both are conformant; the GLN itself is barcoding.dev's layer.

Owning versus possessing: the 3PL case

The distinction §7.4 draws is the one your 3PL flow needs. When Acme's goods ship from a contract warehouse, the owner of record is Acme (owning_party), while the party with hands on the pallets is the 3PL — that is what possessing_party exists to say. The current mapping deliberately does not emit it from an 856: no segment of a despatch advice asserts possession honestly, and minting a possession claim from a routing role would put a guess in a core field. When a document class that genuinely asserts custody enters the pipeline, possessing_party has its type waiting — reserved by the standard, unused until it can be honest. The same honesty rules the failure paths: a party whose N103 is not UL (a DUNS number, a mutually-defined code) produces a typed warning and no source/destination entry — the pipeline never mints a fake GLN URI — and a GLN that fails its mod-10 check emits with a check-digit warning, because structure is validated, membership never.

What is deliberately not stamped

Read the emitted lists again and notice what is absent. No readPoint, no bizLocation: an EDI document names transaction parties, not observation read points, and both fields are optional in the pinned schema — omission is the honest emission. And no org-grain rollups: the event states its own endpoints, and any party-level or enterprise-level view is derived at read time — the trace the buyer reads aggregates events; the events never pre-aggregate themselves. A record that stamps derived conclusions into stored evidence cannot be re-derived when the org chart changes; this one can.

That is the whole party story: three types, four qualifier rules, two AIs, and a refusal to guess. It slots into the rest of the compile — the HL tree gives the events their what, the N1 loops give them their who and where, and the full worked run shows every field land, then validate against the pinned official schema.

If your partner map has parties that arrive as anything other than clean UL-qualified GLNs — most do — bring the mess to the door: the survey asks whether your parties carry GLNs today, and the answer decides what the compile does first.

---

823 words. The access flow is at /get-access/; the family's event door is epcis.dev.