# The 856 is a tree, a manifest, and a promise — anatomy of the ASN > transactions.dev · by visibility.cloud — 2026-07-31 > Written for the in-house supply-chain platform team — the platform engineer who needs the ASN mental model, not the segment dictionary. One thesis: **the 856 is best read as three simultaneous claims — a packing tree, a shipment manifest, and a promise against a purchase order — and an engineer who holds those three claims apart can read any partner's 856 variant, because the claims survive every variation the segment usage does not.** Segment-by-segment reading teaches you one partner's file. Claim-by-claim reading teaches you the document. A note on sourcing before the walkthrough: what follows is original prose over a self-authored, license-clean synthetic document. The element-level X12 dictionary is licensed content, linked at [its canonical reference](https://www.stedi.com/edi/x12-008010/856) and never republished here — [a constraint we state plainly](/blog/x12-licensing-stated-plainly/) because the reading below does not need the dictionary, which is rather the point. ## The specimen One shipment, one order, one pallet, two cases, annotated by claim — `[T]`ree, `[M]`anifest, `[P]`romise: ``` ST*856*0001~ BSN*00*ASN-4471*20260731*0915~ [M] this ASN's own identity + timestamps DTM*011*20260731~ [M] shipped date TD1*PLT*1~ [M] one pallet TD5*B*2*SCAC~ [M] carrier routing HL*1**S~ [T] node 1: Shipment, no parent HL*2*1*O~ [T] node 2: Order, parent = 1 PRF*PO-2026-0007~ [P] the promise: this fulfills that PO HL*3*2*P~ [T] node 3: Pack, parent = 2 MAN*GM*000614141000000106~ [T] the pallet's SSCC HL*4*3*I~ [T] node 4: Item, parent = 3 LIN**UP*061414110006~ [T] the GTIN at this node SN1**48*CA~ [T] 48 cases of it CTT*4~ SE*15*0001~ ``` ## Claim one: the tree The HL segments are the skeleton. Each carries its own id, its parent's id, and a level code — Shipment, Order, Tare, Pack, Item — forming a parent-pointer tree built at parse time, not declared in a grammar. The identifiers hang off the nodes: SSCCs in MAN segments at Tare or Pack level, GTINs in LIN qualifiers at Item level, quantities in SN1. This claim answers *what is inside what*, and it is the claim that compiles to EPCIS aggregation — the isomorphism is worked end-to-end in [the aggregation-tree post](/blog/the-856-is-already-an-aggregation-tree/), SSCC parents to `parentID`, item GTINs to `childEPCs` and `childQuantityList`, with the one genuinely non-derivable case (Tare versus Pack when both carry SSCCs) handled as a journaled ruling rather than a guess. Partner variation lives here as *structure profile*, not meaning: some hubs mandate Tare level, some forbid it; some want order-level packing, some shipment-level. The tree reading absorbs all of it, because a parent-pointer tree does not care how many levels its spine has. ## Claim two: the manifest Around the tree wraps a manifest: the BSN's ASN identity and timestamp, DTM dates, TD-segment carrier and equipment detail, weights and lading counts. This claim answers *what shipment this is and how it travels* — and it is the claim that feeds event context rather than event structure. The shipped DTM becomes the compiled shipping event's `eventTime`; the BSN02 identity becomes the record's [`desadv`](/blog/desadv-is-the-asn/) reference ([the naming rule](/blog/naming-the-document-itself/)); carrier detail stays what it is — corroborating transport evidence, deliberately *not* inflated into custody events, because a routing segment observes no objects and names no observer. The manifest is where partner guides are loudest — every hub's required DTM qualifiers and TD segments differ — and where the variation matters least to the record: context fields absorb optionality gracefully. ## Claim three: the promise The PRF segment inside the Order loop is one element long in spirit — a purchase-order number — and it is the highest-value line in the document. It asserts: *this shipment fulfills that order.* Compiled, it becomes the `po` entry beside the `desadv` on the events' `bizTransactionList` — [core CBV fields, zero extensions](/blog/biztransaction-is-a-core-field/) — and it is the join that makes three-way questions answerable at all: what was ordered versus [what was shipped versus what was seen](/blog/reconcile-is-a-verdict/), per item, on one spine. Which makes the failure mode worth pricing: an 856 *without* a PRF is legal, arrives, and parses — and severs the order join. Downstream, the receiving dock can still verify the pallet against the ASN, but nobody can mechanically answer "which PO did this fulfill" without a lookup through the buyer's ERP, which is exactly the side-system dependency the event record exists to remove. If you author partner guides for your own suppliers: mandate the PRF. It is the cheapest requirement with the largest downstream payoff in the whole document. ## Why this reading survives contact with real partners A thousand hubs constrain the 856 a thousand ways, but every variant still makes exactly these three claims — there is nothing else an ASN is *for*. So the compile pipeline is organized by claim, not by partner: the tree claim feeds the aggregation compile, the manifest claim feeds event time and context, the promise claim feeds the transaction references, and partner-specific segment rules live in a constraint overlay on the base grammar, applied at validation — never as a per-partner fork of the reading itself. The identifiers the tree hangs its claims on — SSCC, GTIN, and where they come from — are [barcoding.dev](https://barcoding.dev)'s layer; what the record they compile into looks like from the buyer's chair is [the executive twin](https://visibility.cloud/asn-po-context-in-traces/). Read your next unfamiliar 856 in this order — find the tree, then the manifest, then the promise — and the file explains itself in minutes. Then let the compiler do it: documents in, conformant events out, validated against the pinned official schema on the way. The door is [the access flow](/get-access/), and the first thing its EDI lane asks is which of these documents your partners already send. --- Access: https://transactions.dev/get-access/ · All posts: https://transactions.dev/blog/ · Machine face: https://transactions.dev/llms.txt