# The directory you can actually vendor: UNTDID, sha256-pinned

> transactions.dev · by visibility.cloud — 2026-07-31
> Written for the in-house supply-chain platform team — the security and architecture reviewer whose questionnaire asks where every normative artifact came from.

One thesis: **UNECE publishes the complete UN/EDIFACT directories free of
charge, which is why this site's reference content goes dictionary-deep on
EDIFACT and EANCOM with per-file sha256 pins while its X12 pages stay at
original-prose depth — the licensing asymmetry between the two standards
bodies is, itself, the content strategy.**

## The asymmetry, stated once

Two organizations own the world's EDI grammar. X12 Incorporated sells
tiered access to its standard and prohibits redistribution below a
negotiated partner agreement —
[the previous post](/blog/x12-licensing-stated-plainly/) walks the published
prices. UNECE, by contrast, publishes the UN Trade Data Interchange
Directory — UNTDID: message directories, segment directories, element
directories, code lists, every release from D.96A forward — openly, and
says so in its own words: UN/EDIFACT is *"available free of charge"*
([Introducing UN/EDIFACT](https://unece.org/trade/uncefact/introducing-unedifact);
downloads at
[unece.org/trade/uncefact/unedifact/download](https://unece.org/trade/uncefact/unedifact/download)).
The UN retains copyright and licenses the directory rather than selling it;
the standard exists to be adopted universally, and implementations have
vendored these grammars in public for decades.

One body's business model forecloses a free reference. The other's mission
statement invites one. A content strategy that ignores that asymmetry is
leaving the only defensible deep reference on the table.

## What "pinned" means here

Open content still deserves provenance discipline — arguably more, because
"I downloaded it from somewhere" is how reference rot starts. So the
vendored UNTDID directories live under the same governance as the GS1
artifacts on [epcis.dev](https://epcis.dev/conformance/): every file
carries a ledger entry with its source URL, retrieval date, license note,
and sha256 digest, and the verify-pins gate refuses to run against a file
whose digest does not match its pin. An excerpt of the ledger's shape:

```json
{
  "vendor/untdid/d96a/edmd/DESADV.txt": {
    "source": "https://unece.org/trade/uncefact/unedifact/download",
    "release": "D.96A",
    "retrieved": "2026-07-31",
    "license": "UNTDID license — service.unece.org/trade/untdid/license.htm; reading journaled",
    "sha256": "9b1f2c…e2a1"
  },
  "vendor/untdid/d96a/uncl/6063.txt": {
    "note": "code list 6063, quantity type qualifiers",
    "sha256": "4d07aa…91c3"
  }
}
```

Pins change only by journaled human ruling — the same law the family
applies to the pinned EPCIS 2.0 schema and JSON-LD context, and the same
discipline [the X12 side applies to its self-authored
grammars](/blog/grammars-are-data-grammar-pins/), where there is no open
directory to vendor and provenance has to be earned file by file. The
point is not paranoia about the UN; it is that a reference whose normative
inputs are digest-locked is a reference whose every claim can be
re-derived, and a build gate that refuses tampered grammars is the
anti-Goodhart move that keeps an agent swarm honest while it climbs
conformance. Vendored open content and self-authored closed-content
grammars end up under one gate, one ledger idiom, one ruling journal —
which side of the licensing asymmetry a file came from is recorded in its
entry, not guessed from its path.

The license reading we operate under is recorded in the ledger itself,
dated: the UNTDID license agreement's terms are read and journaled before a
directory is vendored, and the ledger entry names the reading. If the
reading ever needs to change, that is a journal entry too — provenance is
append-only here.

## The shape of the reference

Because the content is open, the EDIFACT side of this site can do what the
X12 side legally cannot: go all the way down. The reference is organized
message → segment → element → code, with a worked, self-authored example
per message and the compile to the event record shown at each depth:

- [The EANCOM DESADV, walked segment by segment to
  AggregationEvents](/blog/eancom-desadv-walkthrough/) — the international
  ASN, and the flagship of this reference.
- [ORDERS, the purchase order in its open
  dialect](/blog/edifact-orders-the-open-purchase-order/) — where the `po`
  reference is born.
- [INVOIC to `inv`](/blog/invoic-to-inv/) — billing context without the AP
  workflow.
- [RECADV in full](/blog/recadv-in-full/) — the discrepancy-bearing
  document the cycle usually skips.
- [EANCOM versus GS1 XML, by the adoption
  numbers](/blog/eancom-is-the-bigger-rail/) — why this dialect ordering is
  the volume-correct one.

Each walkthrough quotes directory content it is licensed to quote, pins the
files it quotes from, and compiles its worked message to events that
validate against the pinned official EPCIS 2.0 schema — superset where a
message carries more than the standard models, and conformant always.

## Why a reviewer should care

If you are the person who blocks releases on dependency provenance, this
architecture answers most of your questionnaire before you send it:

1. **Where did the normative content come from?** A named public source,
   with retrieval date and digest, per file.
2. **What license governs it?** The UNTDID license, read and journaled;
   the X12 side deliberately carries no licensed content at all.
3. **How do you know it hasn't drifted?** The gate hashes it on every run.
4. **Who can change it?** A human, by journaled ruling — never a build
   script, never a model.

That is the same answer the epcis.dev side gives for its GS1 artifacts, and
the sameness is the point: one governance idiom across the family, applied
to whichever standards body's content is legal to hold. The directories you
can vendor, we vendored and pinned. The dictionary we cannot legally ship,
we [link at its canonical home](/blog/x12-licensing-stated-plainly/) — and
both facts are printed where you can check them.

If that is the provenance answer your questionnaire wants in writing,
[start at the door](/get-access/) — the onboarding flow asks who signs
off on adopting a dependency at this layer — a security review and an
architecture board are both on its answer list — and the pins ledger
answers for every file it holds.

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