The 856 is already an aggregation tree

Written for ED-3 — the in-house supply-chain platform team — the integration engineer who owns the trading-partner map.

One thesis, and it is structural: the X12 856's HL hierarchy is the same shape as an EPCIS aggregation tree, so compiling an ASN into AggregationEvents is a projection, not an interpretation. You are not inventing events from a document. You are reading a tree that was always there.

The shape that was always there

An 856 — the Advance Ship Notice — is built around the HL loop: a runtime parent-pointer hierarchy in which each HL segment names its own id, its parent's id, and a level code. In retail practice the levels run Shipment → Order → Tare → Pack → Item. The pallet (Tare) and case (Pack) levels carry SSCCs in their MAN segments; the Item level carries the GTIN in LIN and the quantity in SN1. We will not reproduce the segment dictionary here — X12's element detail is licensed content, and the canonical public reference is Stedi's 856 page, which we link rather than copy, deliberately.

Now put that beside EPCIS 2.0. An AggregationEvent says: this parent identifier (an SSCC), these children (EPCs or quantity elements), aggregated at this time, at this place, for this business step. A shipment's physical packing — pallet contains cases, case contains eaches — is exactly the HL tree with the paperwork removed.

So the compile is mechanical:

• Shipment HL → one ObjectEvent, bizStep shipping, disposition in_transit.
• Each Tare or Pack HL carrying an SSCC → one AggregationEvent whose parentID is that SSCC and whose children are the child HLs' identifiers.
• Each Item HL → childEPCs when serials are present, childQuantityList keyed by GTIN and lot when they are not.

transactions.dev join performs that projection and nothing else. No heuristics, no vendor schema: the output validates against the pinned official EPCIS 2.0 JSON schema before it leaves the tool — the same pinned artifacts epcis.dev publishes digests for. Superset where the document carries more than the standard asks, and conformant always: the projection validates, or the verb exits nonzero.

The proof artifact

Here is the worked example, end to end. One pallet, one case level, one line item, from a synthetic ASN in our own corpus (self-authored fixtures — the corpus never republishes a partner's guide):

$ npx transactions.dev join 856-one-pallet.edi --json

The middle of the output — the case-level AggregationEvent:

{
  "type": "AggregationEvent",
  "eventTime": "2026-07-28T16:04:11Z",
  "eventTimeZoneOffset": "-06:00",
  "parentID": "urn:epc:id:sscc:0614141.1234567890",
  "childQuantityList": [
    {
      "epcClass": "urn:epc:class:lgtin:0614141.107346.2026A",
      "quantity": 48,
      "uom": "EA"
    }
  ],
  "action": "ADD",
  "bizStep": "packing",
  "bizTransactionList": [
    { "type": "desadv", "bizTransaction": "urn:epc:id:gdti:0614141.00001.8560001" },
    { "type": "po", "bizTransaction": "urn:epc:id:gdti:0614141.00001.4500123" }
  ],
  "sourceList": [
    { "type": "owning_party", "source": "urn:epc:id:pgln:0614141.00001" }
  ],
  "destinationList": [
    { "type": "owning_party", "destination": "urn:epc:id:pgln:0012345.00001" }
  ]
}

Read the four joins off the fixture. The SSCC from the MAN segment became parentID. The LIN GTIN and SN1 quantity became childQuantityList. The BSN02 shipment identifier and the PRF purchase-order reference became bizTransactionList entries typed desadv and po — CBV 2.0 §7.3 defines both; its own words on desadv: "Also called an 'Advanced Shipment Notice,' but the value desadv is always used regardless of local nomenclature." And the N1 loops' GLNs became sourceList and destinationList owning_party entries per CBV §7.4. Every field the compile writes is core-spec machinery. No extension namespace appears in that document.

Why this lands on your desk

You are the platform team. Somewhere upstream of you there is an EDI provider, or a mapping tool, or a person who left; downstream there is a 2.0 mandate, an FSMA-shaped ask, or a partner who has started sending Digital Link URIs. The trap is treating those as two projects — "the EDI integration" and "the EPCIS integration" — staffed and budgeted twice.

The tree argument collapses them into one. The ASN you already receive is the aggregation structure the event mandate wants; what was missing was a compiler with a conformance gate on the exit. That is the whole scope of the join verb: documents in, events out, validated against the pinned schema, refused loudly when the document's tree is malformed (an HL that names a missing parent is a typed error, not a guess).

What join is not: an EDI network, a VAN, a mapping consultancy, or a place your partner relationships live. Your 850s and 856s keep flowing exactly as they do today. The compile is a read-side projection over documents you already possess — which is also why it composes with the capture door at epcis.dev instead of competing with it: the events join emits are the events that door accepts.

Where the difference shows up

Run the compile against last month's ASNs and you have an event history you never captured: every pallet's claimed contents, timestamped, party-attributed, queryable by SSCC. Then start comparing it with what your scanners actually saw — that is the reconcile verb, and it is where the executive story on visibility.cloud begins. The barcode side of that same join — what the scan resolves to before it becomes an event — is barcoding.dev's layer.

The 856 was never a flat file. It was a tree wearing one.

---

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