Conformance as a dependency.

31 July 2026 · the launch journal

Your product manages warehouses, or plants, or fleets, and a customer's RFP just asked whether it is EPCIS 2.0 conformant. You have three ways to make that question go away permanently, and only one of them is cheap next year too: build the standards layer (a quarter now, a tax forever), bolt on a conversion service (a dependency on someone's uptime and roadmap), or import the layer as a library and keep your brand on the surface.

What "demonstrable" means to your customer's auditor

First, the honest frame, because it wins the deal more reliably than the dishonest one. There is no conformance certification to buy: no conformance attestation has ever been issued — not to us, not to anyone — and any vendor implying otherwise is claiming a document that does not exist. What a technical evaluator actually accepts is demonstrable conformance: runnable artifacts. Validate a document and the verdict cites the exact schema it ran, from a real run:

{
  "valid": true,
  "schema": {
    "artefact": "epcis-json-schema.json",
    "version": "2.0.1",
    "sha256": "0f46ff694efffd8d8ce840a33dfde84228add11b516b8b258f3200740ae210af"
  },
  "errors": []
}

That digest matches the pin recorded in vendor/gs1/PINS.json — vendored in the tarball, published on the conformance page, retrieval date and source URL included, changed only by journaled human ruling. Your customer's auditor can re-hash the artifact against GS1's published original without asking you or us. That is the answer that survives evaluation, and it is importable.

The embed, shown

The package is epcis.dev on npm — MIT license, one library barrel, no service dependency, everything runs in your process. The integration that answers the RFP checkbox:

import {
  translate,        // EPCIS 1.1/1.2/2.0 XML -> 2.0 JSON-LD + FidelityReport
  validateEpcis,    // verdict against the pinned official 2.0.1 schema
  eventHash,        // CBV 2.0 §8.9, gated against OpenEPCIS reference vectors
  project,          // conformant projection of superset events
  PINS,             // the sha256 provenance record, importable
} from "epcis.dev";

const { document, fidelity } = await translate(legacyXml);
const verdict = validateEpcis(document);      // cites schema sha256 in the result
const ids = document.epcisBody.eventList.map(eventHash);

Ten lines, and your product now translates a customer's legacy corpus with per-job fidelity reports, validates every event against the pinned official schema, and computes the standardized event hash — under your brand, inside your process, with the spec-tracking labor on our side of the dependency boundary.

The diligence facts your vendor review needs

A VP Engineering does not adopt a dependency on vibes, so here is the review, pre-filled:

The acceptance gate is in the box too: the golden corpus's three tiers mean you can hold us to the claim — every valid-superset fixture must still validate as conformant against the pinned official schema, because superset without conformant is not the claim, and never will be here.

Version policy: how a spec update reaches you

When GS1 revises an artifact, the pin changes by journaled human ruling, the validators are regenerated from the new pinned bytes, and the change reaches you as a dependency bump with a changelog entry naming the old digest, the new digest, and the ruling. Your upgrade decision is a diff review, not a spec-reading project. Between bumps, nothing moves underneath you — that is what pinning is for. Meanwhile every event your product emits carries a computed §8.9 identity, so records produced under adjacent versions reconcile by hash across the boundary.

What you keep, what you shed

You keep the surface, the brand, the customer, and the domain layer that is actually yours — which events your systems emit, what your identifiers mean, how a trace answers your users' question. You shed the layer that is identical for you and your competitor: schema tracking, hash vectors, translation fidelity, error typing. The build-vs-buy arithmetic in full is the ISV pillar; the engineer's cut of the same argument is the capture/query article.

Prove it against your own data first: POST /validate and POST /translate answer on this origin with no key, and npx epcis.dev runs the same engine on your bench. When the question becomes commercial embed terms — redistribution at your scale, support, the hosted spine under your product — that conversation starts at the key list: your address, a short branching set of questions about your product and corpus, and it locks. Keys are provisioned from that list, in order — one email when yours is ready.