The standard already named your paperwork: a §7.3 close reading

Written for ED-1 — the supply-chain ISV / traceability-vendor engineering org — the standards-and-compliance PM who has to answer an RFP with a citation, not a claim.

One thesis: the CBV business-transaction vocabulary was explicitly written with EDI document types as first-class values, so attaching purchase-order and shipment context to events is core spec machinery — and an RFP answer that cites §7.3 needs no vendor's word for it.

Where the enumeration actually lives

CBV 2.0 §7.3 defines BusinessTransactionTypeID — the controlled list of values legal in the type position of a bizTransaction entry. The ratified PDF is freely downloadable from GS1 (ref.gs1.org), and the linked-data form of the list is published at ref.gs1.org/cbv/BTT. But the citation this post stands on is stricter than a link: the official EPCIS 2.0 JSON-LD context, vendored and pinned at sha256 5056c65f991425b1d3a35e35edf4f7d0c7ff56cf688c2912b930f93494713737, maps every value of the vocabulary to its CBV web URI in the bizTransactionList type sub-context. Verify the digest, open the file, and the enumeration is there — thirteen mappings, no vendor namespace among them:

"bol":       "cbv:BTT-bol",
"cert":      "cbv:BTT-cert",
"desadv":    "cbv:BTT-desadv",
"inv":       "cbv:BTT-inv",
"pedigree":  "cbv:BTT-pedigree",
"po":        "cbv:BTT-po",
"poc":       "cbv:BTT-poc",
"prodorder": "cbv:BTT-prodorder",
"recadv":    "cbv:BTT-recadv",
"rma":       "cbv:BTT-rma",
"testprd":   "cbv:BTT-testprd",
"testres":   "cbv:BTT-testres",
"upevt":     "cbv:BTT-upevt"

The list, read as what it is: an EDI catalog

Each value in one original sentence — read them and notice they were not invented by a traceability committee working from a whiteboard; they were transcribed from the paperwork businesses already exchange:

• po — the purchase order; the reference every later document in the cycle echoes.
• poc — the order confirmation; the seller's answer to the po.
• desadv — the despatch advice; the spec's own text adds "Also called an 'Advanced Shipment Notice'" — that sentence gets its own post.
• inv — the invoice; the money claim against the movement.
• recadv — the receiving advice; what the receiver says actually arrived — the least-sent, most-supported document in the cycle.
• bol — the bill of lading; the transport contract the shipment moves under.
• prodorder — the production order; the manufacturing counterpart of the commercial po.
• rma — the return authorization; the cycle running backwards.
• pedigree — the regulated chain-of-custody document of the pharma lane.
• cert, testprd, testres — certificate, test procedure, test results: the quality paperwork.
• upevt — a reference to an upstream event; the vocabulary's own nod to event-to-event linkage.

A purchase order, a ship notice, an invoice, a receiving advice, a BOL, a production order, a return. That is a supply-chain document catalog, written into a GS1 standard ratified in 2022, waiting for pipelines to use it.

Why a controlled vocabulary beats a free-text reference

Your product could store "documentType": "ASN" in its own namespace tomorrow. Here is what the controlled vocabulary buys that the free-text field cannot:

1. Equality across parties. desadv means the same thing in your emitted event and in the retailer's consuming system, because both sides resolve it to cbv:BTT-desadv. "ASN", "ship notice", and "despatch advice" do not string-compare equal; the CBV value does.
2. Hashability. CBV §8.9 event hashing canonicalizes vocabulary values to their web URIs. A typed reference participates in a stable, computable event identity; a free-text label poisons it.
3. Agent legibility. A machine consumer matching on a closed enumeration needs no prompt, no synonym table, and no confidence score.

The zero-extensions claim

Everything the transaction layer writes onto an event lands in exactly four spec-defined places, none of them custom: bizTransactionList (§7.3 values, §8.5 identifier syntax), sourceList and destinationList (§7.4's three types — the N1 post works those), and the item grain of epcList / quantityList (the GTIN join post). The emitted document is conformant always, and a superset only where a source document carries more than the standard models — never one without the other. Every event validates against the pinned official EPCIS 2.0 JSON schema (sha256 0f46ff69…) before it leaves the tool.

The golden corpus carries the ratified reference shape, transaction-event-po.json, whose operative lines are exactly what a conformance reviewer wants to see:

"bizTransactionList": [
  {
    "type": "po",
    "bizTransaction": "urn:epc:id:gdti:0614141.06012.1234"
  }
]

A bare-word type from the closed vocabulary; a URI-typed bizTransaction identifier. Nothing else is legal there, and nothing else is needed.

What "first-class" is worth in an RFP

The question arrives in procurement language: "Describe how your system associates business documents (PO, ASN, invoice) with traceability events." The losing answers describe metadata models. The winning answer is dated and cited: business documents are attached as CBV 2.0 §7.3 business-transaction references, using the §8.5 identifier syntax, on the bizTransactionList field EPCIS 2.0 defines on every event type; the vocabulary has carried EDI document types as first-class values since the standard's 2022 ratification.

That sentence is checkable by the customer's own auditor against GS1's own publications — which is the entire point. Demonstrability, not assertion: the same posture as the conformance page at epcis.dev, where the pinned artifacts and digests live.

When the checkbox needs to become a working pipeline — documents in, conformant references out — say what you compile and the onboarding flow routes you to the right door.

---

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