EPCIS 2.0 conformance for software vendors: embed the standards layer, don't maintain it forever

You didn't get into this business to maintain a standards implementation for the next three years. You got into it to ship the product your customers actually chose you for — the RFID deployment software, the FSMA record-keeping SaaS, the traceability workflow with your name on the renewal.

Then a customer asked: "Are you EPCIS 2.0 conformant?" And now there's a version-pinned obligation on your roadmap that will never ship a feature: translate a decade of vendor XML, stay welded to a schema that keeps revising, compute an event hash that has to byte-match what someone else computes, and be able to prove all of it to an auditor who wasn't in the room when you built it.

That's not a build problem. It's a maintenance-liability problem — a treadmill that consumes a squad forever and differentiates your product by exactly zero. This page is about getting off it: a shared, pinned, testable EPCIS 2.0 and CBV 2.0 conformance layer you can embed underneath your product, so your engineers go back to building the part that's actually yours.

We conform to GS1's standards; we do not stand above them. Everything below is either a public GS1 artifact you can check yourself, or a claim about our own code you can read and run. Read it before you talk to anyone.

How do I make my product EPCIS 2.0 conformant without staffing a squad for three years?

You separate the part that differentiates you from the part that doesn't. The workflow, the UI, the customer relationship, the domain logic — that's yours, and nobody should build it twice. EPCIS 2.0 capture, CBV 2.0 hashing, and XML-era translation are commodity infrastructure. They are deep, unglamorous, spec-pinned commitments where the correct answer is defined entirely by someone else's document — and where being almost conformant is worth nothing to an auditor.

The conformance surface is a gateway you point your product at, not a standard you re-implement:

• Every captured event is machine-checked against the official GS1 EPCIS 2.0 JSON schema before it is accepted. A capture that doesn't validate is refused as an RFC 7807 application/problem+json body carrying the standard's own exception types — not a vendor error string your customer's integration has to special-case. (A8, A11)
• The validators are precompiled over the pinned official GS1 schemas, with sha256 PINS.json provenance, at EPCIS 2.0.1. The version you conform to is a digest in a file, not a claim in a slide. When the standard revises, the pin moves once, in one place, for everyone embedding it — instead of in your codebase, on your maintenance budget. (A11)
• The conformant-projection law: the spine speaks a native What / Who / When / Where / Why / How event model, and EPCIS 2.0 is its lossy-down projection — project(event) must always validate against the official EPCIS 2.0 JSON schema, checked in CI. You don't inherit our model; you inherit a guarantee that what comes out the EPCIS side is conformant. (A8)

The operational return, stated as the thing your CFO already understands: every engineer you assign to the standard is a feature you didn't ship. Your roadmap is already committed. Conformance is table stakes your competitors also have to pay — it wins you no deals, it only loses you the ones where you can't demonstrate it. The cheapest conformance is the one you embed instead of staff.

Check it, don't take it — because it is the crux for you. POST /validate on this origin answers against the sha256-pinned official GS1 EPCIS 2.0.1 schema; /translate returns 2.0 JSON-LD with a per-job fidelity report; /hash returns CBV §8.9 digests — no key, no account. The conformance suite passes 683/683 against GS1's normative artefacts this build. No conformance attestation has ever been issued, and nothing here is resellable as certified; what is checkable is the pinned digests, the vector suite and the RFC 7807 behaviour. The write half opens with a capture key from /get-a-key/.

How do I translate a decade of EPCIS 1.1 / 1.2 XML into EPCIS 2.0 JSON-LD without data loss?

This is the file that broke your last importer: a real 1.1 or 1.2 XML export, extension-wrapped, namespace-salted, with the CBV vocabulary in the shape it was in eight years ago. The question your integration engineer actually cares about is narrow and correct: does it round-trip without loss, and can I prove it per job?

• EPCIS 1.1, 1.2 and 2.0 XML in; EPCIS 2.0 JSON-LD out — with a per-job round-trip fidelity report. The translation is something you review, not something you trust. Every job produces the artifact an auditor or a skeptical integration lead can read: what mapped, what was extension-unwrapped, what round-tripped clean. (A9)
• CBV migration and extension unwrapping are handled by a zero-dependency, namespace-aware parser — not a regex, not a best-effort XSLT you'll be patching at 2 a.m. when a supplier sends a dialect you've never seen.
• Your integration engineer evaluates this the only way that counts: by running it on the corpus, not by taking a meeting. That is exactly how it's meant to be evaluated.

Lead time, not deadline. Your customers are enterprise CPG brand owners, multi-unit QSR operators and grocery retailers — and they inherit both clocks. GS1's Sunrise 2027 programme expects retail point-of-sale to scan and process 2D barcodes by the end of December 2027 (A5); that is GS1's programme, and it is what puts your customers' vendor decisions on a 2026–2027 schedule. FSMA 204 supplies the record-keeping rationale, and it is a de-risking floor, not a gun to anyone's head: the January 2026 date moved toward July 20 2028, the extension was never finalised as a rule (it rests on the Continuing Appropriations Act of 2026 directing FDA not to enforce before then), and FDA is soliciting further flexibilities (A7). Anyone selling your customers the deadline is one search from being caught — which is exactly why a vendor who leads with conformance evidence instead of a countdown wins the evaluation. The timing pressure on you is real and it is derived: your customers lock vendors in on the Sunrise clock, and you need a conformance answer before they do.

How do I compute the CBV 2.0 event hash so it matches what my customer computes?

Because a hash that only matches your own implementation proves nothing. The whole point of the standardized event hash is that two parties who never coordinated compute the same digest for the same event — and a changed event is a different one.

• The standardized EPCIS event hash from CBV 2.0 §8.9, with GS1 Digital Link normalisation, checked against pinned reference vectors — and the vectors are OpenEPCIS's, not ours. That distinction is the entire value: our conformance claim is graded against someone else's reference implementation, so "we match" means "we match the thing your customer's auditor also matches," not "we agree with ourselves." (A10)
• The hash is gated in CI against those vectors on every change. Same event captured twice, same hash; one field altered, different hash. Deterministic, reviewable, and independently reproducible from a public standard and a public reference set.

For a vendor, this is the difference between "we implement the CBV hash" and "we compute the digest your counterparty computes, and here's the vector suite that proves it." Only the second one survives an interop test with a customer's other vendor.

Is there an open-source EPCIS 2.0 repository I can embed instead of building one?

The honest market read, phrased as the invitation it has to be: the EPCIS-native projects we know of — OpenEPCIS (Benelog), epcis.dev, and a small set of others — are a thin, mostly open-source or small-vendor layer. We have not found a scaled commercial EPCIS 2.0 repository serving QSR. If you know one, that is genuinely useful to us and we would like to hear it — you can tell us in the same field you'd use to get a key. (That is an unverifiable negative we hold at only medium-high confidence; we state it as our search result and an ask, never as a finding you should take on faith.)

What the spine is built to be embedded as:

• An EPCIS 2.0 capture and query gateway, built against GS1's official OpenAPI description, pinned by digest. The standard interfaces, not a proprietary API you'd have to wrap.
• Gateway-stamped attribution. recordTime, capturedBy and attestationGrade are applied at the door; whatever the caller sent in those fields is stripped. The scriber is not the part being scribed — which is what makes a captured record something a counterparty can rely on rather than something the sender asserted about themselves.
• Append-only storage; minimally scoped reads. No service identity holds an UPDATE or DELETE grant. Out-of-scope data is absent from a read, not redacted — a structural property, not a permission setting you can misconfigure.
• An MCP door — capture · query · get_event · trace_epc · translate exposed as tools, re-dispatched through the same worker fetch, with the same key a person would use. It is a door, not a second path: an agent doing your migration sweep gets the same conformance guarantees your HTTP client does. (A12)
• Open source, evaluated the engineer's way. npx epcis.dev runs translate, validate and hash on your own bench, and the same doors answer over HTTPS on this origin — point either at your own corpus, no account. Keys for the hosted capture spine are provisioned from the list at /get-a-key/, in order.

The structural fact worth ten minutes of your own reading

EPCIS 2.0 §7.2.2 defines five event dimensions — what, when, where, why, how — and no performer is among them. Party fields are organisation-grain (EPCIS §7.3.6.4; CBV §7.4.3; §8.7.1 PGLN). So the standard's Who is a company: a Company doing a Process is fully answered; a Worker — or an agent — doing a Task at the moment of the scan has no field of its own — the Who stops at the GLN.

That is why the spine carries a two-grain envelope over the conformant record: who is the attested observer (a human, an agent, or an embodied agent); capturedBy is the warrantor account whose key opened the door; party and org grain are derived from grant chains at read time, never stamped in. It projects down to conformant EPCIS 2.0 losslessly — the who rides in a namespaced user-extension field (EPCIS §6.3 / §9.1 / §10.1.3), exactly as the standard provides for. Don't take our word for any of it: §7.2.2 · §8.7.1 are public — ten minutes, and you'll see the gap yourself.

How do I demonstrate EPCIS 2.0 conformance to a customer's auditor?

Not with a support matrix that says "EPCIS: yes." With evidence a specific auditor accepts:

• An automated conformance suite over the GS1 test requirements, run in CI — a pass you can point at, not a claim you assert.
• The PINS.json provenance file — sha256 digests of the exact official GS1 schemas your validation ran against, at EPCIS 2.0.1. "Which version?" has a byte-level answer.
• RFC 7807 problem bodies carrying the standard's own exception types — so a rejection is legible to any EPCIS-literate reviewer, in the standard's vocabulary, without your documentation.
• The round-trip fidelity report per translation job, and the OpenEPCIS-gated §8.9 hash vectors — reproducible from public standards and public reference sets.

The demonstrability gap is the whole product for your Standards & Compliance PM: the difference isn't "we support EPCIS" versus "we don't." It's "we support EPCIS" versus "here is the pinned schema, the vector suite, the CI pass, and the RFC 7807 conformance behaviour your customer's auditor can verify without us in the room." One ticks the RFP box. The other survives the audit.

What we are not, stated plainly. No conformance attestation has ever been issued — so there is nothing you could resell as certified today, and we won't pretend otherwise. Our intent is that capture is $0 per event — recording an event never costs money and is never shown as a meter, with revenue attaching to answers on the executive side, not to capture. That is intent, until published terms bind it — when terms publish, this page carries them, or it says we changed our mind (canon §0.13).

The plan: three steps, no account, no conversation

1. Read the conformance surface. The PINS.json sha256 provenance, the OpenEPCIS vector gate, the round-trip test suite, the RFC 7807 exception behaviour, the append-only and minimally-scoped read laws. This is documented on what ships today — a dated ledger of built versus unbuilt, so you calibrate before you commit an engineer.
2. Line up your worst customer XML. The decade-old 1.1/1.2 file that broke your last importer is exactly the evaluation. POST it to /translate on this origin, or run npx epcis.dev translate on your own bench — either way the per-job fidelity report is your first-value test, no account, no key.
3. Get a capture key for conformance evaluation. The write half — hosted capture — opens with a key, and keys are provisioned from the list, in order. Leave an address and what you mean to point at the door.

What happens if you build it yourself instead

You staff the standard. You ship a partial implementation that passes your own tests. Eighteen months later, an engineer you can't spare is maintaining an EPCIS translator and chasing schema revisions instead of building the product your customers bought — and the conformance question still comes back, now with a customer's auditor attached, because "we support EPCIS 2.0" was never the same thing as "we can demonstrate it."

The other path: the standards layer is shared, pinned and testable; your conformance answer is a CI pass and a vector suite you can hand an auditor; and your squad is back on the part of the product that actually differentiates you. You went from "we're working toward EPCIS 2.0" to "the standards layer is embedded, provable, and not my maintenance problem."

Get a capture key — conformance evaluation

→ Get a capture key for conformance evaluation

You want to check capture against GS1's official schema and the CBV 2.0 §8.9 event hash. Say that on the list. Keys are provisioned from this list, in order. One email when yours is ready — one, not a drip campaign.

This is the one thing you leave: an address and what you mean to point at the door. One address, one row — no newsletter, no sequence, no call. The list lives on this origin and goes nowhere else. If we stop working on this, you get one message saying so and your address is deleted. Either way it is one message.

No account. No demo. No sequence. The read doors answer on this origin without any of that — and if you're the engineering leader making this call, you'd rather read the code and run the corpus anyway.

We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.

The same spine has an executive lens for the customers you sell to — the brand owners, QSR operators and grocery retailers carrying these clocks: visibility.cloud. epcis.dev is the developer and agent door; it conforms to EPCIS 2.0 and CBV 2.0 and makes no claim above them. GS1 has not reviewed or endorsed it.