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

> transactions.dev · by visibility.cloud — 2026-07-31
> Written for 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](https://epcis.dev/conformance/)):

```json
"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](https://www.stedi.com/edi/x12), never
republished.) The compile maps role to type and to direction:

```text
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:

```json
"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](https://barcoding.dev).

## 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](https://visibility.cloud/asn-po-context-in-traces) 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](/blog/hl-loop-to-aggregation-events/) gives the events their
what, the N1 loops give them their who and where, and [the full worked
run](/blog/from-856-to-epcis-document/) 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](/get-access/): the survey asks whether your parties carry GLNs
today, and the answer decides what the compile does first.

---
Access: https://transactions.dev/get-access/ · All posts: https://transactions.dev/blog/ · Machine face: https://transactions.dev/llms.txt