# Naming the document itself — GDTI, Digital Link, and the hash fallback

> transactions.dev · by visibility.cloud — 2026-07-31
> Written for the in-house supply-chain platform team — the security and architecture reviewer asking what exactly goes in that field.

One thesis: **a `bizTransaction` reference is only as good as the
identifier inside it, and CBV 2.0 already specifies a complete naming
scheme — GDTI EPC URIs and GS1 Digital Link URIs for documents with GS1
identity, and a hash-URI fallback for documents without one.** Your
architecture review does not need to design a document-naming convention.
It needs to check that the pipeline follows the one the standard wrote.

## Why the reference needs identity discipline

Two parties each stamp a purchase order onto their own event streams. If
they name the document differently — `PO-2026-0007` here, `4500012345`
there, a URL somewhere else — the cross-party join that
[bizTransactionList exists to enable](/blog/biztransaction-is-a-core-field/)
degrades into string matching. Idempotency has the same dependency: the
`join` verb must emit the same reference every time it compiles the same
document, or replays create phantom paperwork. Both properties reduce to
one rule the pipeline enforces mechanically: **one document, one
identifier, and every event that cites the document agrees on it.**

CBV 2.0 §8.5 — the same section that
[puts `bizTransactionList` on every event
type](/blog/the-why-dimension-rides-on-every-event/) — recommends the
identifier syntaxes. There are three, and they
cover the whole space.

## Case one — the document has a GDTI

The Global Document Type Identifier is GS1's identifier for documents. As
an EPC URI:

```
urn:epc:id:gdti:0614141.06012.1234
                ───┬─── ──┬── ──┬─
       GS1 company prefix │     serial (this document)
                document type
```

The company prefix names the issuer, the document type names the kind of
paperwork (this issuer's purchase-order series, say), and the serial names
the individual document. This is the form the family's golden corpus
exercises — `transaction-event-po.json` carries exactly
`"bizTransaction": "urn:epc:id:gdti:0614141.06012.1234"` — and it is the
strongest case: the identifier is issuer-assigned, globally unambiguous,
and resolvable to a party you can hold to it.

## Case two — the same GDTI as a GS1 Digital Link URI

CBV 2.0 also sanctions Digital Link URIs for the same identifier. The GDTI
travels under Application Identifier 253, as the 13-digit key (company
prefix + document type + check digit) followed by the serial:

```
https://id.gs1.org/253/06141410601221234
                       ──────┬────── ─┬──
                        GDTI-13      serial
```

The check digit is computable by anyone: weight the twelve digits
`061414106012` alternately 1 and 3, sum to 58, and the digit that lifts it
to the next multiple of ten is `2`. Same document, same issuer, same
serial — one syntax for EPC-native systems, one for the web-native systems
that resolve identifiers by HTTP. The grammar of Digital Link itself — AIs,
keys, qualifiers — is [barcoding.dev](https://barcoding.dev)'s layer of the
family; what matters at this layer is that both spellings name the same
document and the pipeline treats them as the same reference.

## Case three — the document has no GS1 identity at all

Most webhook payloads, portal CSVs, and legacy documents have no GDTI and
never will. CBV 2.0 §8.6 provides the fallback: a hash-based URI, computed
over the document bytes, so the identifier is deterministic rather than
assigned. Here is the fallback worked on a real fixture — a synthetic,
license-clean 850 from the corpus, 352 bytes:

```
$ shasum -a 256 po-2026-0007.edi
7dc70e6d265be4136c4130a31b97f7ecc0bdff39cdcd2f93b6c2a995a24faa40

ni:///sha-256;7dc70e6d265be4136c4130a31b97f7ecc0bdff39cdcd2f93b6c2a995a24faa40
```

Any party holding the same bytes computes the same identifier — no
registry, no coordination, no issuer. That property is what makes the
fallback safe for the reviewer to approve: the identity claim is
re-derivable from the artifact itself, which is the same posture the
family already takes with event identity (CBV §8.9 event hashes, the
`hash` verb on [epcis.dev](https://epcis.dev/conformance/), same
`ni:///sha-256;…` idiom) and with its own vendored artifacts (sha256 pins,
changed only by journaled ruling). Identity is computed, never assigned,
whenever computing it is possible.

The fallback's honest limitation is also worth stating in the review:
byte-identical is the criterion. Two renditions of the "same" purchase
order — the PDF and the EDI, or the 4010 and the re-released copy — hash
differently, because they are different artifacts. When a partner sends the
same commercial document in two forms, the ruling about which artifact
anchors the reference is recorded, not improvised; that is the same
journaled-ruling governance the pipeline applies to every mapping choice.

## What the pipeline enforces

The rule set the `join` and `enrich` verbs apply, in order:

1. If the source document carries a GDTI, the reference is the GDTI —
   EPC URI form on the record, Digital Link accepted on input and
   normalized to one spelling.
2. If the issuer assigned no GS1 identity, the reference is the §8.6 hash
   URI over the canonical document bytes.
3. One document, one identifier: recompiling the same bytes emits the same
   reference, and an event set in which two spellings of one document
   diverge is a typed error, not a warning.

Every emitted event then validates against the pinned official EPCIS 2.0
schema — the identifiers above are not a house convention riding on the
standard, they are the standard's own syntax, which is why the emitted
record stays a conformant superset rather than a dialect: conformant
always, superset only where the source document genuinely carries more.

## The questionnaire line, pre-answered

When the security review asks "what exactly goes in the `bizTransaction`
field, and who controls it" — the answer is one sentence: *a CBV 2.0 §8.5
identifier — an issuer-assigned GDTI in EPC URI or Digital Link form, or,
for documents without GS1 identity, the §8.6 hash URI computed over the
document bytes — enforced one-identifier-per-document at compile time.*
Nothing in that sentence is ours to define, which is precisely what makes
it approvable.

If your document population is mostly case three — no GDTIs anywhere, a
decade of ERP exports — that is a normal answer, not a disqualifying one.
Say so in [the access flow](/get-access/); the identifier questions in the
survey exist because the answer changes what the compile does first.

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