You are accountable for a mandate you did not negotiate, on a date you did not set, for a record consumed by someone else. Your customers' traceability requirements arrive through the commercial relationship and land on your plants as new capture obligations — new scans, new records, new audits. The emit-once architecture that answers those mandates without joining each customer's platform is worked in its own brief; this post is about a fact that should change the cost math of the next mandate response you draft: the hardest artifact those mandates ask for is one your plant already authors, thousands of times a week. You then throw it away after transmission.
What your ASN already says
Every despatch your plant ships is announced by an advance ship notice, and every ASN is not a flat document — it is a tree. In original terms (the X12 856's segment-level detail is Stedi's public reference, linked here rather than reproduced): the document nests shipment → order → pallet → case → item. The shipment level carries the despatch as a whole. Under it, the order level answers a customer PO. Under that, each pallet is identified by its SSCC — the serial shipping container code, the license plate your labelers already print (the identifier itself is worked at barcoding.dev, by visibility.cloud). Under each pallet, the cases; at the bottom, the items — GTIN and quantity, lot where you declare it.
Drawn as the structure it is:
Despatch SHIP-0731-009 (answers PO-4471) ├── Pallet SSCC …0000000101 │ ├── 48 cases · GTIN A · lot L221 │ └── 24 cases · GTIN B · lot L307 └── Pallet SSCC …0000000102 └── 60 cases · GTIN A · lot L221
Your plant computed every edge of that tree — which cases went on which pallet, which pallets serve which order — because physical despatch requires computing it. The document transmits, the customer's EDI stack consumes it, and the tree's working life ends. Total lifespan: one transmission.
The same tree, as custody events
Now put the ASN beside what a traceability record needs from your plant, and look at the shapes. An EPCIS custody record expresses packing structure as aggregation events: this pallet (parent, by SSCC) came to contain these cases (children) at this time and place. The despatch itself is an object event — shipped, in transit — carrying the document references on its bizTransactionList (desadv for the ASN, po for the order — core vocabulary, per po and desadv Are Core CBV). Node for node:
| The ASN's tree | The custody record |
|---|---|
| Shipment level (despatch, carrier, dates) | ObjectEvent — bizStep: shipping, the despatch's cases, desadv + po references |
| Order level (customer PO) | the po reference on the same bizTransactionList |
| Pallet level (SSCC) | AggregationEvent — parent SSCC …0101, children: the 72 cases |
| Case level (GTIN, lot, quantity) | the children themselves — lot-grain quantities, serialized where you serialize |
| Item level | each-grain children, where the pack level goes that deep |
Same tree. Same nodes, same edges, same identifiers — SSCC at the pallet, GTIN and lot at the case — because both artifacts describe the same physical act of building a despatch. The difference is lifespan and standing: the document version is a statement to one customer, consumed once; the event version is a record, queryable for the life of the product, carrying each event's attested observer (who — the line worker or machine that built the pallet) and warrantor account (capturedBy), two grains the document format never had room for and this record never collapses.
"You already author this" is therefore the exact cost claim, not a slogan: the marginal content of the custody tree your mandates demand is zero. The despatch hierarchy compiles into the aggregation-event tree — the same derivation whichever syntax the despatch advice wears, X12, EDIFACT, or an API's JSON, since the vocabulary is syntax-neutral. What was a transmission becomes a record. The developer door for that compilation is transactions.dev; the executive read across the whole document layer is the ASN/PO context brief.
What the tree does that the document cannot
The mandate's author — your customer's programme office — is not collecting documents for their own sake; their auditor needs to answer custody questions. A retained event tree answers what a transmitted document cannot:
- Recall scope, computed. Lot L221 goes bad: the tree names every pallet and despatch that carried it, across all customers, in one query — while the document version of the same answer is a search across a year of transmitted 856s, per customer, in the customer's format.
- The receiving join. Your customer's dock reconciles their receiving events against your declared tree — shipped versus seen, worked from the customer's side in Shipped vs. Seen. When your tree is a record rather than a transmission, discrepancies resolve against evidence you both hold, not against whichever party's archive is better.
- Audit without archaeology. "Show me what was on pallet …0101 and who built it" is a query with an attested answer, not a request that lands on your plant team the week of the audit.
And because the record is a conformant superset — the projection validates against GS1's official pinned EPCIS 2.0 schema — what your customer's auditor receives is the standard they already speak, with the performer dimension their standard lacks carried alongside, never instead.
One line for the next mandate response
Your next customer mandate will ask, in whatever clause language, for despatch-level traceability. The response that reframes the relationship is one sentence: "Our despatch hierarchy survives transmission — every ASN we send you exists as a queryable custody tree, pallet to case to lot, with an attested observer on every build event." That sentence costs you no new data. It is the tree you already grow, kept.
The door here is the get-started interview: your email first, then a short interview that branches on your answers — the manufacturer branch asks how you found out about your last quality problem and how long it took to know which lots, whether a retailer has sent you a 2D-readiness questionnaire, and what already sits on your 2026 or 2027 plan with a date. We answer in writing.