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

Written for ED-3 — 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 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; downloads at 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: 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:

{
  "vendor/untdid/d96a/edmd/DESADV.txt": {
    "source": "https://unece.org/trade/uncefact/unedifact/download",
    "release": "D.96A",
    "retrieved": "2026-07-31",
    "license": "UNTDID licence — 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, 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 licence 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 — the international ASN, and the flagship of this arc.
• ORDERS, the purchase order in its open dialect — where the po reference is born.
• INVOIC to inv — billing context without the AP workflow.
• RECADV in full — the discrepancy-bearing document the cycle usually skips.
• EANCOM versus GS1 XML, by the adoption numbers — 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 licence, 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 — 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 — 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.

---

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